Написал статью «Как жить если у вас юникод»

Тема про юникод в 2023 году, йопт.

Я больше скажу - мне бы очень было интересно посмотреть на эффективную реализацию без поддержки со стороны ядра…

Смотри исходники Erlang.

php > $x = "suffix";
php > echo grapheme_strlen($x);
4

Всё равно неправильно считает. Должно быть 6.

Должно быть 6.

С чего 6? Тут 4 графемы, всё правильно.

А букв 6.

От того, что три буквы выведены лигатурой, их количество не должно уменьшатся. И первые 4 буквы от этой строки должны быть «suff» или хотя бы «suff».

Собственно, речь о том, что в юникоде нет адекватного способа посчитать буквы или получить первые N букв (например, для словаря нужны страницы с заголовками вида «{первые две буквы первого слова}..{первые две буквы последнего слова}» и легко можно получить вместо «af» что-то вроде «affi» или «aff».

Зато есть пара десятков пробельных символов, и куча символов с идентичным начертанием:

https://cs12.pikabu.ru/post_img/2021/05/09/9/1620575498165418027.webp

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

Это ненастоящая лигатура. Для работы с устаревшими символами нужно применять нормализацию.

В качестве бонуса перечислю два новшества Си, которые стали доступны в последнее время:
Наряду с префиксом 0x для шестнадцатеричных чисел появился префикс 0b для двоичных чисел

Могу ошибаться, но «в последнее время» в данном контексте — это как бы не C99…

Тема про юникод для программистов. Это несколько иное. Тут в C и C++ до недавнего времени было не так шоколадно.

Другое дело, что в 2023 году, говоря на эту тему, надо бы упомянуть std::u8string. Но он появился только в C++20, и как текущие компиляторы его поддерживают — вопрос очень интересный. И примеры его употребления, которые я видел, походили на лютейшее вырвиглазие, кутешники не зря в своё время сделали QString, в котором гарантируется работа с распакованным юникодом (для линукса - 32-разрядный).

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

При чём тут буквы? Лигатура это один глиф, одно знакоместо. Хоть там 100500 букв.

В С все хорошо, про icu тут уже написали.

При том, что ветка началась с того, что wstring не умеет считать буквы. В качестве решения кто-то предложил считать графемы, мол это «буквы». Я показываю, что считать графемы тоже не очень осмысленно.

Это ненастоящая лигатура.

А как выглядит настоящая?

Для работы с устаревшими символами нужно применять нормализацию.

Какую? Обе, которые умеют разбивать лигатуры, из 2⁵ делают 25 и ещё портят строку по мелочи.

тоже не очень осмысленно

Ещё раз для тупых, смысл в том, чтобы посчитать сколько знакомест занимает текст при отображении. Философские рассуждения о том, является ли лигатура самостоятельной «буквой» никого не интересуют.

ветка началась с того, что wstring не умеет считать буквы

С каких пор рожа является стала буквой?

С буквами в wchar_t* всё OK. И уж для len() в Python'е это вообще не проблема. Тот пример выше иллюстрировал другое:

• В юникоде есть составные из нескольких кодепоинтов глифы.
• В юникоде есть и модификаторы, которые нужно отсеивать при подсчёте графем.

И вот эти вот моменты массив кодепоинтов сам по себе не решает. Но если каждый кодепоинт в нём соответствует конкретной букве, то проблем в этом случае, собственно, никаких и нет. Проблемы (которые, собственно, являются таковыми если нужно работать с рандомными юникодными строками и поддерживать 100% совместимость со всем юникодом) возникают именно из-за составных глифов и модификаторов.

качать компилятор Паскаля

Компиляторы и интерпретаторы и так должны быть установлены. Это же первое дело после установки дистрибутива доустановить интерпретаторы и компиляторы.

Да даже если и докачать. Зачем вообще нужен такой дистрибутив если у юзера проблемы с установкой его пакетов?

С каких пор рожа является стала буквой?

Так он в wstring и другие буквы не умеет.

В слове «описа́л» сколько букв? Кстати, нормализация здесь не спасает.

Проблемы (которые, собственно, являются таковыми если нужно работать с рандомными юникодными строками и поддерживать 100% совместимость со всем юникодом) возникают именно из-за составных глифов и модификаторов.

Я именно про это и пишу. В юникоде, фактически, с одной стороны, ликвидировали понятие «буквы», так как местами один кодпоинт является несколькими буквами, местами несколько кодпоинтов собираются в одну букву, причём, в отличие от графем, общего правила здесь нет.

В юникоде есть отдельные символы для для i, і, ｉ, 𝚒, 𝗶, 𝗂, 𝔦, ⅰ или ; и ; и при этом не различаются китайские иероглифы и кандзи. Юникод позволяет изменять направление ввода внутри строки для любых символов…

Проблемы (которые, собственно, являются таковыми если нужно работать с рандомными юникодными строками и поддерживать 100% совместимость со всем юникодом) возникают именно из-за составных глифов и модификаторов.

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

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

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

Да все можно, просто не через O(1).

Да все можно, просто не через O(1).

Как получить первые две буквы строки?

Ещё одна проблема юникода: сколько байтов надо зарезервировать для назначения платежа, если по закону в нём может быть не более 210 символов? Как посчитать?

Вызвать функцию которая тебе вернет офсет и длину.

сколько букв

А зачем это знать? При выводе это занимает 6 знакомест. Сколько там букв вопрос не технический, иди обсуждай с филологами.

В этом году я это, внезапно, осилил.

Будь ты проклят! Ты всех нас предал!!1

Вызвать функцию которая тебе вернет офсет и длину.

Какую? И как мне это позволит из «affine» (61ef ac83 6e65) получить «af» (6166)?

А зачем это знать?

Я же тебе привёл пример. Нужен, например, индекс по тэгам с кнопками типа «Ab..Af», «Af..Al», …, «Ba..Fa», …

А если «буквой» считать лигатуру, то будет «Аffi..Al» а для арабского может вообще попасть ﷺ. Буква, понимаешь, такая.

Какую? И как мне это позволит из «affine» (61ef ac83 6e65) получить «af» (6166)?

const char *str = "залупа коня";
const char *g1, *g2;
size_t &g1_len, &g2_len;

grapheme(str, 1, &g1, &g1_len);
grapheme(str, 2, &g2, &g2_len);

И вот у тебя есть две графемы. То, что в юникоде соотвествует «читаемой букве».

char *g1, *g2 конечно же. Интересно, почему я не править свои же сообщения, лол.

И вот у тебя есть две графемы. То, что в юникоде соотвествует «читаемой букве».

В том-то и дело, что графема не буква. Там вообще может быть целая фраза. Потому что лигатуры являются допустимой частью юникода.

Не, пажжи. Вот нам цитата из юникода:

This annex describes guidelines for determining default segmentation boundaries between certain significant text elements: grapheme clusters (“user-perceived characters”), words, and sentences. For line boundaries, see [UAX14] .

grapheme cluster («user-perceived characters»). То есть, это должно быть минимальной человекочитаемой единицей.

Так я про то же. Но при этом в Юникоде есть лигатуры.

Именно. Графема одна. А в ней четыре слова и в каждом несколько букв.

Именно. Графема одна. А в ней четыре слова и в каждом несколько букв.

Именно. Графема одна. А в ней четыре слова и в каждом несколько букв.

А их разделить можно? Скажем, убрать последнее слово?

Конечно. Без последнего слова будет صَلَّى ٱللَّٰهُ عَلَيْهِ.

Но вместе они собираются в халяльного трансфомера по правилам языка?

А вместе есть специальная лигатура Юникода. В которую записана вся фраза.

А вместе есть специальная лигатура Юникода. В которую записана вся фраза.

Мм… я к чему: это не тот случай, когда нормализация с декомпозицией должна это разбивать?

Декомпозиция разбивает, но портит строки. Вместо 10 в пятой степени получается число 105. Нужна ещё одна декомпозиция, которая бы разбивала только лигатуры.

Нужен, например, индекс

И что? Тебя наверное не смущает что есть заглавные буквы и строчные и для индекса это тоже важно. Очевидно чтобы делать индекс нужно данные нормализовать так, как требует логика индекса. При чём тут именно юникод вообще не понятно, проблема возникает независимо от кодировки.

В любой другой кодировке можно выделить буквы. Если бы Юникод делался весь по принципу кодпоинт = буква, в нëм тоже 90% проблем бы не было.

Но воткнули модификаторы и лигатуры, хотя по-нормальному это всё должно быть уровнем выше (странно, что весь TeX не утрамбовали).

Декомпозиция разбивает, но портит строки. Вместо 10 в пятой степени получается число 105.

Это же баг, нет? Вся идея нормализации была в том чтобы она была без потерь.

Нет. Так написан стандарт. Это баг самого Юникода.

Нет. Так написан стандарт. Это баг самого Юникода.

Руст, к слову, NFD форму не портит, но и лигатуру не разбивает :(

В любой другой кодировке можно выделить буквы

Нет, формально нельзя. То что на практике это где-то работает, то это совпадение и костыль.

Так и я про то же. NFC и NFD не разбивают лигатуры. NFKD и NFC портят строку.