Абсолютный минимум об Unicode на 2023 год (всё ещё — никаких оправданий!)

И вот именно поэтому для строки, с которой выполняются какие-либо операции помимо "получить от пользователя - сохранить - загрузить - вывести на экран" лучше задуматься об отказе от Юникода. Просто потому что иначе мы получаем одиноково выглядящие строки, которые кодируются по-разному, и одинаково кодирующиеся строки, которые выглядят по-разному, и нет этому конца...

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

Интересно, а ни у кого не было идей сделать стандарт Unicode2, в котором все эти ошибки и странности были бы исправлены?

Спасибо, отличная статья, но на C#

>> "🤦‍♂️".Length

возвращает 5, а не 7

Одна графема может состоять из нескольких кодовых точек

А есть ограничение на количество кодовых точек в одной графеме?

Создатели Unicode считали, что 65 536 символов будет достаточно для всех человеческих языков.

Вот ещё в детстве меня это удивило — я знал что только китайских иероглифов где-то 60 тысяч, т.е. для остального места могло и не хватить 🤷 (а про всякие UTF-16 я узнал уже потом)

Стандарт юникода на мой взгляд слишком сложен, причем некоторые усложнения вроде ежегодного добавления эмодзи явно излишни. Впрочем и без эмодзи чудес хватает. Например на iOS 16 в некоторых локалях при неких мне неизвестных дополнительных условиях японские канзи начинали странно отображаться: некоторые радикалы в канзи менялись на другие. В iOS 17 наколько мне известно, это поправили.

Странно, что для четкого определения длины многоточечной графемы не ввели что-то типа спец символов (невидимых) для указания на начало графемы и ее длины. Наверняка там длина графем не больше 32х элементов, хватило бы 32 кодовых точек - маркеров графем.

Сначала мелкая придирка по тексту.

Область Unicode, выделенная под частное использование, содержит, в основном, шрифты, состоящие из значков.

Наверно, лучше сказать «покрывается шрифтами»? (Для понимания разницы читать про font fallback).

А по сути, автор раскрыл глаза людям, считающим, что UTF-8 — дерьмо, на страшную правду: это не UTF-8 — дерьмо, это Юникод — дерьмо. Надо же, какое невероятное удобство: теперь цвет лица в смайлике можно кодировать разными отдельными кодепоинтами, в то время как волшебная шляпа и плащ™ всегда кодируются одним и тем же! И вот РАДИ ЭТОГО у нас теперь нет возможности выделять память на стеке под строку заданного размера? РАДИ ЭТОГО создание шрифтов теперь больше напоминает разработку программы? РАДИ ЭТОГО мы потеряли O(1) в строковых алгоритмах? РАДИ ЭТОГО в процессе груповой работы (и, в частности, разработки) у нас периодически отлетает BOM? Остановите Землю, я схожу.

Вы только вдумайтесь. При использовании UTF-32 минимальное число байтов для хранения одного символа — четыре. Это четыре миллиарда значений. Этого МАЛО?! Туда влезут все живые и мёртвые языки, все смайлики из «Идиократии» на тыщу лет вперёд, и со всеми диакритическими вариациями. Но нет. Юникод просто автоматически означает UTF-8, так что, нечего удивляться, что он почти на 100% используется в веб-страницах. А как же ещё? Когда у нас имеется плавающее число кодепоинтов на один семантический символ, плавающее число байтов на один кодепоинт — это просто неизбежное зло. UTF-8 в Юникоде, это как формулировка в условиях тендера на госзакупках: «производитель компьютера любой, операционная система — macOS». Конечно, блин, можно извратиться, но это именно что извращения. Как и UTF-32.

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

Насчёт неделимости графемных кластеров — не соглашусь. Решительно считаю возможность стирать диакритику у букв фичей, а не багом.

Вот сделали бы простую и удобную систему, как в телеграфе. 127-символьная (ну или 255-символьная) кодовая страница, и управляющие последовательности, эти страницы переключающие. И хоть древнеегипетские иероглифы пихай, хоть смайлики.

Ну и да -- диакритика хорошо бы была отдельной сущностью, как и буквы хангыли и других нелинейных систем письма.

Правда, появляется риск появления иНЖАЛИД дЕЖИЦЕ, если переключение где-нибудь потеряется, ну и тут можно что-нибудь предусмотреть.

grapheme_strlen("🤦‍♂️")

PHP вернет 1

Сейчас с популяризацией ChatGpt и других LLM, довольно интересна тема токенов, Уже сейчас на английском языке все популярные слова и графемы выделены в токены, думаю что если обучать генератор токенов на всех мировых языках в равной мере то должен получится UniToken в котором будут все используемые графемы и слова на всех языках.
Думаю что под капотом все еще будет UTF8 со всем наследием но можно будет выбирать уровень представления который удобен для нейронных сетей, людей и компьютеров: Токены слов -> Токены графем -> UTF8

В случае с PostgreSQL, varchar(255) - это тоже не количество графем, поэтому валидировать строку нужно по количеству юникод-точек, а не графем. А вот что выводить пользователю, вопрос.

ASCII: строка в 1024 символа потребует 1 кб памяти

UTF-16: строка в 1024 символа потребует 2 кб памяти

UTF-8 раньше: строка в 1024 символа потребует от 1 до 4 кб памяти

UTF-8 сейчас: строка в 1024 символа потребует... а фиг его знает, может и мегабайта не хватить!

Автор недооценивает возможности современного Javascript:

function calcGraphemeCount(s, lang = 'en') {
	const segmenter = new Intl.Segmenter(lang, {granularity: 'grapheme'});
	return [...segmenter.segment(s)].length;
}

console.log(calcGraphemeCount('🤦‍♂️'));  //Выдаёт 1

Оптимизированная версия:

class MyString() {
	static segmenter_en_grapheme = new Intl.Segmenter('en', {granularity: 'grapheme'});
	
	static calcGraphemeCount(s) {
		let count = 0;
		
		for (const segment of MyString.segmenter_en_grapheme.segment(s))
			count++;
		
		return count;
	}
}

console.log(MyString.calcGraphemeCount('🤦‍♂️'));  //Выдаёт 1

Что здесь происходит:

1. Создаём экземпляр класса Intl.Segmenter, который служит для разбиения текста на графемы, слова или предложения. В данном случае выбираем графемы.

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

Если нужно, можно получить графему и её позицию по индексу в строке:

const segmenter_en_grapheme = new Intl.Segmenter('en', {granularity: 'grapheme'}),
      segmentObjs   = segmenter_en_grapheme.segment('abc🤦‍♂️def'),
      segmentObjAt5 = segmentObjs.containing(5);  //{segment: '🤦‍♂️', index: 3}

const grapheme    = segmentObjAt5.segment,                 //🤦‍♂️
      index_start = segmentObjAt5.index,                   //3
      index_end   = segmentObjAt5.index + grapheme.length; //8

Класс Intl.Segmenter можно использовать и для других целей, например, чтобы разбить японский или китайский текст, в котором нет пробелов, на слова. Правда сейчас пока в японском разбивает ну очень плохо, например, слово 間違う успешно считается за одно слово, но если поменять форму, например, на 間違えてる, то считается аж целых 5 слов (間+違+え+てる) вместо одного слова (間違えてる) или хотя бы двух слов (間違えて+る).

Впрочем, соглашусь, что, возможно, было бы интересно увидеть в JS свойство вида String.prototype.graphemeCount, чтобы можно было написать как-то так:

'🤦‍♂️'.graphemeCount;  //1

В исходной статье, кстати, был применён символ "🤦🏼‍♂️" (5 кодовых точек Unicode), а в переводе стал символ "🤦‍♂️" (4 кодовых точки Unicode). Из-за этого, если запустить примеры, то получится не тот результат, который написан в этих же примерах, т. к. в примерах указан символ 🤦‍♂️, а длина строки посчитана для символа из исходной статьи.

• В тёмной теме Хабра часть картинок выглядит как "серое и чёрное на чёрном", ничего не разобрать

• В главе "Я живу в US/UK. Надо ли мне вообще о таком задумываться?" потеряли выделение не-ASCII символов прямо в тексте главы, которое есть в оригинальной статье

• Перевод низкокачественный, читается плохо

Лучше прочитать оригинал