Comments 47
хвост перекладывается в буфер и проверяется за 1 раз
https://github.com/simdjson/simdjson/blob/master/src/generic/stage1/utf8_validator.h#L18
Да и вопрос с memory wall и текстом достаточно некорректен — именно текста там практически нет. У вас одни формы для отрисовки занимают несравнимо больше данных.
Издеваетесь? Ваш комментарий прям под научной статьёй про валидацию таких строк
Статья про валидацию (то что строчка пришла действительно utf8), а не про разбор строки для дальнейшей работы и дальнейшей работы с этой строчкой.
Вы в своей программе для работы с пришедшей строкой либо перекодируете уже в формат строки с которым удобно и быстро работать(после валидации что это utf8), либо будете для каждой операции с данной строкой парсить всю строку заново.
При входном потоке который не требует валидации что это utf8 и дальнейшей перекодировки для работы — большая часть проблем для вас исчезает. И оборудованию становится сильно проще.
wchar_t практически не используется. Везде UTF-8.
Не используется он в GTK и компания, а нормальные системы используют штатные локали со стандартными mbtowc/mbstowcs и преобразуют любые локали в wchar_t для работы, а не только UTF-8.
И снова приведу в пример японцев: у них до сих пор Unicode практически не используется — у них несколько JIS локалей, старого доброго доюникодного ISO 646.
wchar_t в мире Linux, и кучу примеров с UTF-8.Есть Qt с
QString с UTF-16, но это вообще ни туда, ни сюда.Дак вы сами можете множество из них найти. Например, GNU gettext:
gettext-0.18$ grep -nr wchar_t | wc -l
1298— В общем-то, практически все, кто локализует сообщения в *nix, используют ту или иную реализацию gettext.
Если мы говорим об Unicode, то наметилась тенденция использования libunistring для его поддержки:
libunistring-0.9.10-4-r2$ grep -nr wchar_t | wc -l
1065Ну и далее:
- libxml2 — 18;
- libxslt — 6;
- libidn2 — 190;
- GLIB — 261;
- ncurses — 914;
- openldap — 156;
- perl — 34 (это очень старый perl);
- pam — 8.
Это то, что под рукой из известных было, список можно продолжать и продолжать.
wchar_t-совместимые интерфейсы — это хорошо. Но используются ли они в конечных программах?Да и я вот посмотрел немного gettext, и там
wchar_t как будто для Windows. Я не нашел ни одного вхождения wchar_t в хедерах, которые установлены gettext в моем линуксе.В libxml2 тоже не нашел
wchar_t в публичном интерфейсе.ncurses действительно поддерживает параллельно
char и wchar_t интерфейсы, это правда. Посмтрел несколько программ, которые зависят от ncurses — ncdu, htop — они используют char> Если мы говорим об Unicode, то наметилась тенденция использования libunistring для его поддержки.
В документации libunistring есть такой занятный раздел: www.gnu.org/software/libunistring/manual/libunistring.html#The-wchar_005ft-mess
Я тоже накидаю примеров:
* CPython —
wchar_t иногда используется для внутреннего представления юникодных строк. www.python.org/dev/peps/pep-0393* Go — строки содержает произвольные байты, чаще всего UTF-8, изредка бинарные данные. blog.golang.org/strings. Выделенного юникодного типа нет.
* Rust — строки UTF-8. doc.rust-lang.org/std/primitive.str.html
* Linux (ядро) — все системные вызовы, принимающие строки, принимают нуль-терминированные строки
char*, обычно семибитный ASCII или UTF-8 (хотя ядро никогда не знает, что это UTF-8, и никак с юникодом не работает (или очень редко)).* libcurl —
char* во всех интерфейсах.
А как быть с нулевыми байтами? Одна из целей utf8 — поддержка сишных 0-терминированных строк. К тому же, когда его придумывали, юникод умещался в 2 байта на кодпойнт.
Utf-32 тоже не панацея, т.к. потенциально надо работать с символами, состоящими из нескольких кодпойнтов. Так что учитывая, что в подавляющем количестве языков сейчас есть итераторы, utf-8 для внутреннего представления может оказаться вполне нормальным вариантом. В т.ч. в rodata. Любые строки (в т.ч. 8-битные) — это нетривиальность работы с памятью.
Юникод устроен намного сложнее, чем кажется. Например, буква Ё может быть представлена как комбинация двух кодпоинтов — Е и комбинирующего диерезиса. И нет, нормализация не решит эту проблему, так как не для всех комбинаций комбинирующих (извините за тавтологию) символов есть отдельный глиф. Взять хотя бы те же смайлики.
Как по-вашему должен работать поиск в таких условиях?
Поиск как раз хорошо будет работать, так как "Е" и "Ё" всегда будут просто "Е". А всякие точки и черточки можно и проигнорировать.
Что-то я не понял вашу позицию. Ведь сами русские пишут одно и то же слово, то через ё, то через "е". Например "ёлка" и "елка" это одно и то же.
И конечно, если в поиске я напишу "елка", ожидаю что "ёлка" тоже будет найдено. И наоборот.
ПП: И кстати, я не русский, я болгар. И мне было бы очень удобно, если "Э" и "Е" тоже были бы эквивалентны в поиске. Ведь в болгарском есть по сути только "Э" и иногда, я не знаю э или е нужно писать в некие слова.
Такая ситуация называется «бардак»
Я бы с вами согласился, если бы в мире были только русский и английский. И только буквы и цифры. Системы письменности очень сложны, и вообще очень здорово, что есть стандарт.
И это я не затронул тему букв, которые выглядят по-разному в зависимости от позиции в слове, разных порядков одних и тех же букв в алфавите, разного преобразования к верхнему или нижнему регистру в зависимости от локали, RTL. Да даже просто разбиение слова на буквы — это не такая тривиальная задача иногда.
Да, Юникод кажется переусложнённым иногда, но это отражение сложности систем письменности.
Символ по-хорошему должен всегда умещаться в один «атом» строки. Если это не так, то смысла в длинном кодировании просто нет, и тут utf8 достаточно.
Перефразирую ваше утверждение: слово должно всегда умещаться в один «атом» строки. Если это не так, то смысла в длинном кодировании просто нет.
(Японцы, кстати, до сих пор не перешли на UTF, у них всё ещё главенствует JIS в нескольких кодировках.)
Ваше утверждение сродни утверждению «нет языка кроме английского».
Если мы даже возьмём русский без диакритических знаков (ё и й — самостоятельные буквы в русском), то есть знак ударения, который необходим для однозначного прочтения слова, и вы предлагаете ввести в UTF кодовые точки для всех гласных русского языка, которые могут быть ударными?
А что с арабским? А с хинди?
А дизайнерам шрифта вы предлагаете явно описать все символы вместо автоматической композиции сложных символов из ряда простых?
В UTF, кстати, сначала пытались впихнуть все символы, но столкнулись с реальностью и добавили композицию.
Не нужно передергивать.
Неделимым элементом письменного языка является именно буква, а не слово.
Носители неалфавитных языков не согласны. И в следующем параграфе приведён пример-отсылка: почему вы его проигнорировали?
Знак ударения не является символом с точки зрения языка. Это как подчеркивание в word — элемент метаданых. Вы же не жалуетесь, что подчеркивание не вставляется в любое поле ввода? Вот и ударение туда же.
Использование ударения обязательно для передачи слова при наличии форм, отличающихся только ударением (особенно там, где нет контекста для идентификации конкретного слова).
Ну это вообще не аргумент. Все надизайненное по-отдельности, автоматически может быть слито воедино.
Зачем вы хотите увеличить объём данных там, где данные могут быть вычислены достаточно быстро из меньшего объёма? У нас вот уже три десятилетия проблемы со скоростью доступа к данным: вычислить быстрее часто.
Максимальная длина символа в utf8 все равно ограничена.
Она гораздо менее ограничена, чем пространство Unicode на данный момент.
Почему бы не ввести что-то типа aligned utf8, в котором на каждое знакоместо будет зарезервировано максимально возможное количество байт.
Всё давно придумано: это называется UCS-4. UTF-8 появился после UCS-2 и UCS-4 для целей экономии. UTF-кодировки — это сжатые варианты первых.
Сейчас ведь нет ни одной юникодной кодировки, где можно просто обратиться к символу по индексу, не боясь нарваться на отдельные точечки от «ё».
И это, ведь, не просто так: о чём я упомянул в самом конце своего комментария. Выйдите за пределы европейской цивилизации с её простым алфавитным письмом: за её пределами огромный мир с другими правилами.
При разработке Unicode произведено множество исследований, тексты их доступны: почитайте некоторые из них — будет понятнее. Там есть обоснования того выбора, который сделан.
И вы не указали, зачем вам атомарность символов?
P.S. Я не поклонник Unicode (ISO 10646), мне больше импонирует подход ISO 646. Например, имея набор строк в любой юникодной кодировке, вы не сможете произвести их сортировку: правила сортировки в разных языках разные. Далеко за примерами ходить не нужно: взять, хотя бы, символы с акцентами в немецком и шведском. В ISO 646 же у нас есть информация о языке текста.
..., то есть знак ударения, ...
Вот, кстати, пример неоднозначного прочтения без ударения: «то́ есть» vs «то е́сть» — с указанием фразового ударения проще прочитать правильно. Первый вариант употребляется чаще — можно продолжать писать без ударения, а вот во втором случае (что имеет место быть в цитируемом тексте) лучше писать с ударением, тем более в компьютерную эру, когда это сделать довольно просто.
Hint для пользователей *nix: <compose> + <апостроф> + <буква> — после ввода апострофа можно переключать раскладку.
Длину строки без полного парсинга определить невозможно.
А что такое длина строки? Число символов в строке? А зачем они вам? В человеческих языках символы, часто, совсем не одной и той же ширины: и вот, вам снова нужно разобрать всю строку, чтобы вычислить её отображаемую длину, независимо от кодирования — что UTF-8, что UCS-4.
Исключительно быстрая валидация UTF-8