Как посимвольно работать с кириллицей в Си

Причём странно, почему из всего этого цирка уродов он предпочёл именно кои8, цп1251 более соответствует современным (пятнадцатилетней давности, но всё же) реалиям.

Тут уже понаписали, но я с этим разобрался, используя std::basic_string<unsigned int32_t>.

вы его как-то неправильно используете :)

Допускаю, что я не правильно его использую. Но как мне в wchar_t для Android уместить символ с кодом больше 255?

bit representation that fits in an object of type wchar_t, capable of representing any character in the current locale

Увы, в текущей реализации ни Windows, ни Android не могут умеситить в wchar_t любой символ.

man encoding. тред не читал.

Неправильно говоришь. Внутрь этого типа своими грязными ручонками лазить не след в кроссплатформенных приложениях. А использовать его можно и нужно.

Ну и как мне на Android в однобайтовый wchar_t (а там он именно один байт) впихнуть любой символ?

то же зависит от того, кто тулчейн портировал на андроид, если там заявлена поддержка c99, то всё ок для кода, который придерживается c99 и posix.2001 по-моему.

Вот гугель и спросите, они sdk и ndk выдают.

конечно, если разрабатывать в стиле - я в вищуал студии(эклипсе) проект открыл, ф9 нажал, через дебаггер отладил, какие ещё линкер, отладочная печать, консоль и прочее устаревшее posix. то так ничего не получится

Вы слишком долго общаетесь с идиотами. Не стоит считать, что все вокруг вас такие же.

А что, гугл стал позиционировать NDK не как средство для написания ошмётков кода, критичных по времени исполнения, а как штуку, с помощью которой от начала до конца под андроид можно написать приложение на сишечке?

Есть пропатченный ndk, с толстым вчаром и експепшенами.

Есть пропатченный ndk, с толстым вчаром и експепшенами.

Есть, вы его юзали? Как вы в нем со строками в wchar_t работать собрались?

Можно сто раз рассказывать, какой в теории wchar_t замечательный, но кроссплатформы с ним не получить. Надеюсь, вы не предлагаете половину кода в #ifdef оборачивать?

Я предлагаю работать со строками на ведроиде в жабе.

Есть пропатченный ndk, с толстым вчаром и експепшенами.

И как быть с виндой, у которой wchar_t два байта?

Я очень, очень плохо знаю си, но неужели там нет библиотеки, которая позволяет полностью абстрагироваться от всей этой побайтовой шелухи и работать со строкой как с символами?

Я предлагаю работать со строками на ведроиде в жабе.

Охрененное предложение. Спасибо, обойдусь своей реализацией. Ваш совет отправил в топку.

Я очень, очень плохо знаю си, но неужели там нет библиотеки, которая позволяет полностью абстрагироваться от всей этой побайтовой шелухи и работать со строкой как с символами?

Я не совсем вас понимаю. Я сказал, что wchar_t говно. Сказал почему. Вы сказали, что я не прав. Предложили мне вначале яву, а теперь и какую то абстрактную библиотеку. Где логика?

большинства

CP1251

4.2, за пределами этой страны про CP1251 не слышали.

Я нигде не утверждал, что вчар — не говно. А предложил я вполне логичные пути решения.

Держать юникод только из-за символа «евро» — маразм!

вот, именно поэтому и нужно применять как раз UTF-8

Если ты юзаешь UTF-8, то ты юзаешь юникод. Со всеми вытекающими.

Держать юникод только из-за символа «евро» — маразм!

Лично я за юникод лишь ради символа 卐.

Если ты юзаешь UTF-8, то ты юзаешь юникод. Со всеми вытекающими.

какими вытекающими? UTF-8 - самый человечный юникод из всех юникодов :)

А предложил я вполне логичные пути решения.

Сменить язык разработки? Ну для вас это вероятно и логичное решение. Но не для меня.

какими вытекающими? UTF-8 - самый человечный юникод из всех юникодов :)

Я с вами согласен, но до той поры, пока не понадобится работа со строками - вставка, удаление, etc. подстроки.

значит используйте библиотеки в которых работа с UTF-8 реализована нормально

значит используйте библиотеки в которых работа с UTF-8 реализована нормально

Да вся эта нормальность будет либо в идексации символа, внутреннем предствлении строки в 4 байта на символ, или тупой поиск символа.
Ну не предназначен utf-8 для быстрой вставки/удаления подстроки. Но это не значит, что не стоит использовать utf-8.

Вы слишком долго общаетесь с идиотами. Не стоит считать, что все вокруг вас такие же.

то я утрировал и никого идиотом не считаю.

то я утрировал и никого идиотом не считаю.

Ок, тогда прошу меня простить.

Кстати C++98 даёт близкое определение в разделе 3.9.1:

Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest extended character set specified among the supported locales

Учитывая, что символы в UTF-16, которая является стандартной для Windows кодировкой, могут состоять из 2 или из 4 байт — очень странно, что Microsoft используют wchar_t размером всего 2 байта.

Кстати C++98 даёт близкое определение в разделе 3.9.1:

Угу, спасибо.

Учитывая, что символы в UTF-16, которая является стандартной для Windows кодировкой, могут состоять из 2 или из 4 байт — очень странно, что Microsoft используют wchar_t размером всего 2 байта.

Угу, странно.

меня получилось, может кому будет полезным

а теперь возьми строку с русскими буквами через argv замени все о на Ё и выведи на печать.

храни в UTF-8 - конвертируй и работай с другими типами строк - проблема-то в чем? :)

храни в UTF-8 - конвертируй и работай с другими типами строк - проблема-то в чем? :)

Да у меня нет проблем с utf-8. Я использую ее. Если нужно работать со строками (редактирование имени пользователя, к примеру), то перекодирую в unsigned int.

Просто перегоняешь строку при помощи mbstowcs в wchar_t, а дальше также как было у sadavod

  if (setlocale(LC_CTYPE, "") == 0) {
    fprintf(stderr, "Can't set the specified locale! Check LANG, LC_CTYPE, LC_ALL.\n");
    exit(EXIT_FAILURE);
  }
  
#define SZ 20
  wchar_t wchar_text[SZ];
  int length = mbstowcs(wchar_text, (const char *) argv[1], SZ);
  if (length == (size_t) -1) {
    perror("Invalid first argument");
    exit(EXIT_FAILURE);
  }
  for (wchar_t *p = wchar_text; *p != L'\0'; p++) {
    if (*p == L'щ') *p = L'Ё';
  }
  printf("%ls\n",wchar_text);

Я фигею, дорогие товарищи! Каких только извращений не понавыдумывают, лишь бы однобайтной кодировкой не пользоваться!

Ну и как мне на Android в однобайтовый wchar_t (а там он именно один байт) впихнуть любой символ?

А ты и так во wchar_t любой символ не впихнешь. И дело тут не в размере.

И вообще, какого тебе в твоем кроссплатформенном приложении тебе сдалось работать с массивом кодпойнтов?

А ты и так во wchar_t любой символ не впихнешь. И дело тут не в размере.

В sizeof(wchar_t) == четыре байта впихну.

И вообще, какого тебе в твоем кроссплатформенном приложении тебе сдалось работать с массивом кодпойнтов?

Если вам это не нужно, значит и мне не нужно?

может вообще предполагается, что строки из whchar_t символов закодированы в UTF-8?

может вообще предполагается, что строки из whchar_t символов закодированы в UTF-8?

Что то я вашего мыслеизвержения понять не могу.

короче, покажи кусочек своего кода, работающий со строками, чтоб более предметно рассуждать

И как быть с виндой, у которой wchar_t два байта?

wchar32_t же

UTF-8 - самый наркоманский юникод из всех юникодов :)

// f-ed

Каких только извращений не понавыдумывают, лишь бы однобайтной кодировкой не пользоваться!

здравствуй дорогой дятел, спешу рассказать тебе во письме о чудесах что нынче во лесу творятся...

В sizeof(wchar_t) == четыре байта впихну.

Не впихнешь. Дело не в размере.

Если вам это не нужно, значит и мне не нужно?

Произвольный глиф не сводится к одному произвольному кодпоинту.

Так что процедура копания в массиве - жутко нетривиальная. А уж если на входе строка не нормализованная, то вплоть до сегфолтов.

Просто перегоняешь строку при помощи mbstowcs в wchar_t, а дальше также как было у sadavod

да я ьак примерно и делаю, это я предложил для того, чтобы тс понял, что есть мультибайтовые символы и широкие.

вот ещё интересная ссылка по теме http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Streams-and-I...

только надо помнить, что это glibc, а никакой не bionic или микрософтофская библиотека

может вообще предполагается, что строки из whchar_t символов закодированы в UTF-8?

предполагается что это UCS-2/UCS-4

вот ещё интересная ссылка по теме

А вот комментарий на сколько оно переносимо: http://www.gnu.org/software/libunistring/manual/html_node/The-wchar_005ft-mes...

И это ещё не говорится, что, вообще говоря (стандарт C99 говорит, что мол Compiler Specific), L'ё' может давать разные битовые представления в зависимости от локали и, соответственно, ломаться в случае когда при компиляции и при исполнении используются разные локали. А ещё стандартная библиотека языка C не знает, что кроме uppercase и lowercase есть ещё и titlecase, например. Да и вообще стандартная библиотека слабо подходит для адекватной работы со строками.

предполагается что это UCS-2

Вот, кстати. Microsoft закладывались именно на UCS-2, а не на UTF-16, когда вводили у себя wchar_t, по этому всё и ломается с иероглифическими письменностями.

L'ё' может давать разные битовые представления в зависимости от локали

насколько я понимаю, после преобразование в wchar_t это будет одинаковое представление. преобразование будет сделано с помощью таблиц, заданных для конкретной локали.

только надо помнить, что это glibc, а никакой не bionic или микрософтофская библиотека

Вообще говоря fwide это C99 и POSIX.1-2001, так что можно и позакладываться на то, что оно будет работать.

насколько я понимаю, после преобразование в wchar_t это будет одинаковое представление

Вот я этого из текста C99 не вынес.

преобразование будет сделано с помощью таблиц, заданных для конкретной локали

Такое там есть, но вот гарантий что в разных локалях один и тот же символ будет мапится в одно и тоже wide представление (Особенно со всякой диакритикой, которая в разных локалях может представляться как одним, так и двумя или тремя самостоятельными символами) я не увидел.

L'ё' может давать разные битовые представления в зависимости от локали

Дык, это не интересно. Интереснее другое. Юникодовские строки могут быть в 4-х нормальных формах или без оной. Это безотносительно собственно кодировки. Так что в исходниках лучше пользоваться ASCII.