LINUX.ORG.RU

C && unicode


0

0

Здравствуйте,

насколько мне известно, тип wchar_t определенный стандартом не предназначен (и не может?) хранить строковые значения представленные в unicode. Хотелось бы узнать, как тогда (сторонние библиотеки?) хранить юникодные строки в программах на C и работать с ними? Спасибо.

anonymous

>насколько мне известно, тип wchar_t определенный стандартом не предназначен (и не может?) хранить строковые значения представленные в unicode.

Просто фиксированная размерность wchar_t не определена стандартом. В винде он, вроде, равен 16 байтам, в юниксах 32 (или наоборот, не важно). Т.е. в одном случае он может хранить UCS-2/UTF-16, а в другом UCS-4/UTF-32, а unsigned char UTF-8.

>Хотелось бы узнать, как тогда (сторонние библиотеки?) хранить юникодные строки в программах на C и работать с ними?

uint8, uint16, uint32 :) А работать по-разному. Для начала RTFM: http://en.wikipedia.org/wiki/Unicode ; потом google.it: http://library.gnome.org/devel/glib/2.14/glib-Unicode-Manipulation.html , http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1ustring... , http://doc.trolltech.com/4.3/qstring.html#details и т.д.

anonymous
()
Ответ на: комментарий от anonymous

>равен 16 байтам

Тьфу, битам. Пардон.

anonymous
()
Ответ на: комментарий от anonymous

> Забыть про wchar_t и прочитать про utf8.

В некоторых случаях это неприемлемо по производительности, ибо в utf-8 коды переменной длины. Хотя, в определенных случаях эту проблему не решает даже 32-битный wchar_t.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

>ибо в utf-8 коды переменной длины

Ага, а ещё суррогаты в UTF-16 и декомпозированные глифы. Один фиг на самом деле.

anonymous
()
Ответ на: комментарий от anonymous

> Ага, а ещё суррогаты в UTF-16 и декомпозированные глифы. Один фиг на самом деле.

Ну, для 99% применений достаточно UCS-2, который вполне себе фиксированной длины. Или у вас программы занимаются исторической лингвистикой?

anonymous
()

Спасибо за комментарии, почитал некоторые маны -- ситуация несколько прояснилась. wchar_t вполне подходит для моей задачи. Ибо таскать GLib для консольного приложения, imho, overhead :).

Есть, правда, еще один вопрос:

Возможно ли преобразование без потерь wchar_t* -> char*. Ибо мне надо сформировать некоторую команду с аргументами (юникодным текстом) и отдавать её exec*() на выполнение. В ``man 3 iconv'' упоминается только char*.

anonymous
()
Ответ на: комментарий от anonymous

> для 99% применений достаточно UCS-2, который вполне себе фиксированной длины.

Смотря что фиксированной длины. В Unicode есть combining characters, которые могут образовывать композиты, поэтому глифы даже в UTF-32 имеют переменную длину.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от anonymous

> В ``man 3 iconv'' упоминается только char*.

А iconv "пофиг" - он, можно сказать, только с байтами и работает :)

yyk ★★★★★
()
Ответ на: комментарий от Legioner

> нормализация - наше всё!

Любопытно было бы узнать, что есть "нормализация" по отношению к данному контексту.

anonymous
()
Ответ на: комментарий от Reset

> А для какого же приложения надо glib таскать ? :)

А неужели каждая система должна иметь предустановленный GLib? Звучит сомнительно :).

anonymous
()

Кстати, а имеет ли значения для работы с wchar_t текущая установленная локаль?

anonymous
()
Ответ на: комментарий от anonymous

тогда нужно все полностью свое писать, в том числе и упомянутый тут iconv

Reset ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.