Unicode и UTF-8

Unicode – единый каталог символов всех письменностей мира, в котором каждому символу присвоен свой постоянный номер – кодовая точка (code point).

Работа началась в 1988 году: черновик под названием «Unicode 88» опубликовал Джо Беккер из Xerox, параллельно над идеей работали Ли Коллинз и Марк Дэвис из Apple. Консорциум Unicode учредили в январе 1991-го, первый том стандарта вышел в октябре того же года. Сегодня в таблице почти 160 тысяч символов (версия 17.0), и каждый год добавляются новые.

Теперь самое важное, и это ровно тот момент, где обычно возникает путаница: Unicode – это не кодировка.

В уроке 7.2 кодировка отвечала сразу на два вопроса – какой у буквы номер и какими байтами её записать. Для однобайтовых таблиц это и правда один вопрос: номер 192, байт 192, разницы нет. Unicode отвечает только на первый: «буква Ж – это номер 1046». Как записать число 1046 в файл, если в байт оно не влезает, – задача отдельная, и решают её форматы преобразования, UTF (Unicode Transformation Format).

Аналогия: Unicode – это перепись населения, где у каждого жителя свой личный номер. UTF – правила, по которым этот номер печатают на бланке: в одну строчку, в две, с ведущими нулями. Житель один, а записей может быть несколько, и они не противоречат друг другу.

Кодовую точку записывают особым образом: буквы U+ и номер в шестнадцатеричном виде, минимум четыре цифры. U+0041 – латинская A, U+0416 – русская Ж, U+1F600 – 😀.

Почему шестнадцатеричный вид, а не привычный десятичный, – причина прямо из урока 2.3: одна шестнадцатеричная цифра это ровно четыре бита, поэтому по записи сразу видно и битовую структуру номера, и то, в какой части таблицы символ живёт.

Соседство в таблице не случайно – символы уложены блоками:

Задержитесь на первой строке: первые 128 кодовых точек Unicode намеренно совпадают с ASCII. Это не дань уважения предшественнику, а инженерное решение, которое выстрелит через два блока.

Про размер таблицы. Всё пространство поделено на 17 плоскостей по 65 536 позиций каждая: $17 \times 65\,536 = \mathbf{1\,114\,112}$ – та самая последняя строка таблицы из урока 7.1. Нулевая плоскость (U+0000–U+FFFF) называется основной, в ней лежит почти всё, чем пользуются каждый день. Верхний адрес – U+10FFFF, и чтобы его записать, нужен 21 бит.

Занято при этом меньше 15% позиций. Запас оставлен сознательно: новые письменности и знаки можно добавлять, ничего не перестраивая.

Номер у символа есть – пора класть его в файл. Способов три, и все три живы: UTF-32, UTF-8 и UTF-16. Начнём с самого прямолинейного.

Рассуждение простое: 21 бит не влезает ни в один, ни в два, ни в три байта? Возьмём четыре – и будем всегда писать номер целиком, дополняя ведущими нулями.

A  U+0041  →  00 00 00 41
Ж  U+0416  →  00 00 04 16
😀 U+1F600 →  00 01 F6 00

Плюс у такого решения ровно один, зато весомый: фиксированная длина. Пятый символ строки лежит по смещению $5 \times 4 = 20$ байтов, и чтобы туда попасть, ничего разбирать не нужно.

Минусы серьёзнее:

• объём. Английский текст раздувается вчетверо: было 41, стало 00 00 00 41. Три четверти файла – нули. Требование № 2 из начала урока провалено;
• нулевые байты ломают старые программы. В языке C строка кончается нулевым байтом; программа, наткнувшись на 00 в начале кода буквы A, решит, что текст закончился. Требование № 3 провалено;
• порядок байтов. Число 0x00000416 можно разложить в памяти начиная со старшего байта, а можно с младшего – получится 00 00 04 16 или 16 04 00 00. Про этот пункт нужен отдельный разговор – он всплывёт в уроке ещё дважды.

Порядок байтов (byte order, endianness) – договорённость о том, в какую сторону раскладывать по памяти число, которому одного байта мало.

Пока символ занимал один байт, вопроса не существовало. Но у числа 0x00000416 байтов четыре: старший 00, затем 00, затем 04, младший 16. Выкладывать их в файл можно с любого конца, и оба способа живут в железе прямо сейчас:

число  0x00000416

big-endian (BE)     00 00 04 16   – первым старший байт
little-endian (LE)  16 04 00 00   – первым младший байт

Big-endian – «как пишем мы»: старшее слева, как в числе 1946 сначала идут тысячи. Так устроены сетевые протоколы (поэтому BE называют ещё сетевым порядком) и процессоры Motorola 68k, SPARC, старые PowerPC.

Little-endian – наоборот, первым младший байт. Так работают процессоры Intel и AMD (архитектура x86) и в обычном режиме ARM, то есть практически любой компьютер и телефон, за которым вы сидите. Порядок выглядит вывернутым, но логика в нём есть: адрес числа указывает на его младший байт, поэтому одно и то же место в памяти можно прочитать и как четырёхбайтовое число, и как двухбайтовое – просто взяв меньше байтов, не сдвигая адрес.

Названия – инженерная шутка. В «Путешествиях Гулливера» Свифта два государства воюют из-за того, с какого конца разбивать варёное яйцо: с тупого (big end) или с острого (little end). В 1980 году Дэнни Коэн взял этот образ для статьи о спорах вокруг порядка байтов, намекая, что предмет спора тот же самый: важно не какой порядок выбран, а чтобы обе стороны выбрали одинаковый.

Отсюда и головная боль формата. Увидев в файле 16 04 00 00, программа сама по себе не знает, что это: буква Ж (U+0416), записанная little-endian, или несуществующий символ U+16040000. Договариваются двумя способами:

• назвать порядок в имени кодировки – UTF-32BE или UTF-32LE. Тогда он известен заранее и обсуждать нечего;
• поставить метку в начало файла – BOM (Byte Order Mark), кодовую точку U+FEFF. Хитрость в том, что зеркальная ей позиция U+FFFE в таблице Unicode намеренно оставлена пустой. Поэтому программа читает первые байты и сразу получает ответ: 00 00 FE FF в начале означает big-endian, FF FE 00 00 – little-endian. Сам BOM на экран не выводится, это служебная пометка.

Запомните этот пункт – ниже мы увидим, что UTF-8 от него избавлен вовсе, а UTF-16 наследует его целиком.

Как формат хранения UTF-32 почти не используют. Иногда он встречается внутри программ, когда важна скорость обращения к символу по номеру.

UTF-8 – способ записи кодовых точек Unicode байтами, при котором символ занимает от 1 до 4 байтов: чем меньше номер, тем короче запись.

Придумали его Кен Томпсон и Роб Пайк из Bell Labs в сентябре 1992 года – по известной истории, схему Томпсон набросал на салфетке в закусочной, а представили формат на конференции USENIX в январе 1993-го.

Идея: дешёвым символам – короткая запись. Латиница получает 1 байт (ровно как в ASCII), кириллица – 2, иероглифы – 3, эмодзи – 4.

Но тут же встаёт вопрос, которого не было у форматов фиксированной длины. Программа читает ленту байтов подряд – как ей понять, где кончается один символ и начинается следующий? Разделителей в ленте нет. Ответ спрятан в самих байтах: старшие биты каждого байта работают дорожным знаком.

1 байт   0xxxxxxx                             U+0000–U+007F      7 битов
2 байта  110xxxxx 10xxxxxx                    U+0080–U+07FF     11 битов
3 байта  1110xxxx 10xxxxxx 10xxxxxx           U+0800–U+FFFF     16 битов
4 байта  11110xxx 10xxxxxx 10xxxxxx 10xxxxxx  U+10000–U+10FFFF  21 бит

Читается таблица так:

• байт начинается с 0 – символ однобайтовый, и вся оставшаяся семёрка битов и есть его номер (то есть это в точности байт ASCII);
• байт начинается с 110, 1110 или 11110 – это ведущий байт, и число единиц до первого нуля равно длине символа в байтах;
• байт начинается с 10 – это продолжение, сам по себе он символом не является.

Крестики x – свободные места под биты номера, и считать их полезно: во втором варианте 5 + 6 = 11, в третьем 4 + 6 + 6 = 16, в четвёртом 3 + 6 + 6 + 6 = 21. Ровно столько, сколько нужно на верхний адрес U+10FFFF, – совпадение не случайное.

Историческая мелочь: исходная схема допускала до шести байтов, но в 2003 году документ RFC 3629 ограничил UTF-8 четырьмя. Больше и не требуется.

Разберём сборку по шагам.

1. Берём кодовую точку: Ж = U+0416 = 1046.
2. Смотрим в таблицу шаблонов: 1046 попадает в диапазон U+0080–U+07FF, значит, байтов будет два, а свободных мест под биты – 11.
3. Записываем 1046 в двоичном виде, дополняя до 11 битов: 10000010110.
4. Разрезаем на 5 + 6: 10000 и 010110.
5. Вставляем куски в шаблон:

      110 10000        10 010110
      ^^^              ^^
      метка:           метка:
      «2 байта»        «продолжение»

      11010000 = 0xD0  10010110 = 0x96

Итог: Ж → D0 96.

Проверим на 😀 = U+1F600 – это уже четырёхбайтовый случай. Двадцать один бит номера 000 011111 011000 000000 раскладываем по местам 3 + 6 + 6 + 6:

11110 000   10 011111   10 011000   10 000000
   F0          9F          98          80

И самый простой случай: латинская F = U+0046 = 70, это меньше 128, шаблон 0xxxxxxx, байт 46. Тот же самый байт, что и в ASCII шестьдесят лет назад.

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

1. Полная совместимость с ASCII. Любой файл, записанный в ASCII, уже является корректным файлом UTF-8 – байты те же самые, конвертировать нечего. Английский текст не потолстел ни на байт, а горы старых файлов не пришлось переписывать. Требование № 2 выполнено.

2. Внутри многобайтовых последовательностей нет «маленьких» байтов. Все байты составного символа имеют старший бит 1, то есть значение не меньше 0x80. Значит, байт 00 не может случайно оказаться внутри символа, и байт 2F (символ /) – тоже. Старая программа, которая ищет в пути слэш или ждёт нулевого байта в конце строки, работает как работала. Требование № 3 выполнено.

3. Самосинхронизация. По любому байту, не глядя на соседей, видно, ведущий он или продолжение. Отсюда два практических следствия: можно прыгнуть в середину огромного файла и за пару байтов найти границу символа; а если байт при передаче потерялся, испортится один символ, дальше текст восстановится сам. Сравните с кодом Бодо из урока 7.2, где потеря одного переключателя регистра превращала в мусор всю оставшуюся строку.

Бонусом – порядок байтов не имеет значения: последовательность задана самим форматом, поэтому UTF-8 не нуждается ни в BOM, ни в вариантах BE/LE. Впрочем, BOM в UTF-8 иногда всё же ставят: старые версии Блокнота Windows добавляли в начало файла три байта EF BB BF. Сегодня это скорее помеха, чем польза.

Результат виден в статистике: по данным W3Techs, UTF-8 используют 99% сайтов, у которых кодировка вообще определена. В Python 3 UTF-8 – кодировка исходного кода по умолчанию, в Linux и macOS – кодировка системы по умолчанию.

Всё имеет цену, и у UTF-8 она есть – платят её все, кто пишет не латиницей.

Русский текст в UTF-8 занимает ровно вдвое больше, чем в Windows-1251. Это не недосмотр, а осознанный размен: за то, что латиница осталась однобайтовой, платят все остальные письменности. Кириллице досталось 2 байта, иероглифам – 3, поэтому в Японии и Китае UTF-16 держался заметно дольше: там он экономнее.

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

Откуда взялся третий формат, если UTF-8 так хорош? Из хронологии.

Когда Unicode только появился, в нём было 65 536 позиций и все верили, что этого хватит навсегда. Под эту веру и строили системы: Windows NT, Java, чуть позже JavaScript – все они внутри хранят строки как последовательность двухбайтовых ячеек. А в 1996 году, с версией Unicode 2.0, таблицу расширили до 17 плоскостей – и оказалось, что символ в две ячейки больше не влезает.

Разберёмся спокойно, потому что штука хитрая.

Как UTF-16 работает в простом случае. Файл читается не побайтово, а парами байтов. Каждая пара – одно число от 0 до 65 535, и это число прямо и есть номер символа. Такую пару называют ячейкой (по-английски code unit):

A  U+0041  →  ячейка 0x0041  →  байты 00 41
Ж  U+0416  →  ячейка 0x0416  →  байты 04 16
你 U+4F60  →  ячейка 0x4F60  →  байты 4F 60

Пока символ из основной плоскости, всё честно: один символ – одна ячейка – два байта, никакой возни с шаблонами, как в UTF-8. Ради этого формат и создавался.

В чём загвоздка. У 😀 номер U+1F600, то есть 128 512. В ячейку помещаются числа только до 65 535 – символ не влезает. Значит, придётся занять две ячейки. И тут же встаёт тот же вопрос, что и в UTF-8: программа читает ячейки подряд, как ей отличить одну ячейку-символ от половинки двухъячеечного символа?

Решение: дырка в таблице. В Unicode специально выкусили 2048 номеров – диапазон U+D800–U+DFFF – и объявили, что там никогда, ни при каких версиях стандарта не будет ни одного символа. Позиции пустуют навсегда, и именно в этом весь смысл: если ячейка содержит число из этой дырки, она заведомо не символ, а служебный сигнал «я половинка, ищи вторую рядом». Дырку поделили пополам:

• D800–DBFF – старшая половинка (1024 значения);
• DC00–DFFF – младшая половинка (1024 значения).

Такие половинки и называются суррогатами: суррогат – это заменитель, подделка. Сама по себе одна половинка не значит ничего, символ появляется только когда они встали в суррогатную пару.

Арифметика тут сходится идеально: $1024 \times 1024 = 1\,048\,576$ – ровно столько позиций во всех 16 верхних плоскостях. Каждому символу верхних плоскостей хватает своей пары, ни одна не лишняя.

Как символ разрезают на две половинки. Разберём 😀 по шагам:

1. Берём номер и вычитаем 0x10000 – основную плоскость мы кодируем не парами, поэтому нумерацию начинаем заново: 0x1F600 - 0x10000 = 0xF600. Что осталось, гарантированно умещается в 20 битов.
2. Записываем эти 20 битов: 0000111101 1000000000.
3. Режем ровно пополам, по 10 битов: старшие 0000111101 = 61, младшие 1000000000 = 512.
4. Каждую половинку кладём в свой диапазон, прибавляя его начало:

старшая:  0xD800 + 61  = 0xD83D
младшая:  0xDC00 + 512 = 0xDE00

итог: две ячейки D83D DE00  →  байты D8 3D DE 00

Почему по 10 битов – видно из размера половины дырки: 1024 значения это ровно $2^{10}$, а 10 + 10 = 20 битов, как раз сколько осталось после вычитания.

Почему это читается однозначно. Программа смотрит на очередную ячейку и сразу знает её роль по одному лишь значению:

Это ровно та же идея, что и ведущий байт в UTF-8, только на уровне ячеек, а не байтов: по элементу ленты видно, сам он символ или часть чего-то большего.

Получился формат «2 или 4 байта»: вроде бы переменной длины, но без совместимости с ASCII (A в UTF-16 – это два байта 00 41, и нулевой байт на месте) и с зависимостью от порядка байтов, а значит, снова с BOM или пометкой BE/LE. То есть все минусы UTF-32 при части плюсов UTF-8.

Практическое следствие видно и сегодня: в JavaScript выражение "😀".length даёт 2. Язык считает не символы, а ячейки, а эмодзи занимает суррогатную пару. Хуже того, строку можно случайно разрезать прямо между половинками – и вместо смайлика на экране окажется пустой прямоугольник: половина пары символом не является. В Python 3 такой проблемы нет: там строка – последовательность кодовых точек, поэтому len('😀') равно 1.

Соберём сравнение в таблицу:

ord() и chr() переводят символ в его кодовую точку и обратно – и это операция внутри Unicode: никаких байтов и никаких кодировок здесь ещё нет. Байты появляются только в encode() – той самой паре методов из урока 7.2.

Отсюда важное про Python 3: строка str – это последовательность кодовых точек, а не байтов. len('Привет') равно шести, потому что символов шесть; сколько байтов они займут в файле, зависит от того, какую кодировку выбрать при записи. Тип bytes (литералы с префиксом b'...') – это уже готовая лента байтов, и между ним и строкой всегда стоит явно названная кодировка.

И обратите внимание на последнюю строку: попытка записать русский текст в ASCII не «портит» его молча, а честно падает с ошибкой. Символа в таблице нет – записывать нечего.

Есть кракозябры особого вида – те, что появились вместе с UTF-8. Выглядят они узнаваемо: Привет. Разберём этот случай побайтово.

Слово «Привет» записали в UTF-8 – на диск легли 12 байтов:

D0 9F  D1 80  D0 B8  D0 B2  D0 B5  D1 82
  П      р      и      в      е      т

Файл открыли программой, которая считает, что текст в Windows-1251. Она берёт каждый байт по отдельности – про пары она ничего не знает и знать не может – и ищет его в своей таблице: D0 → Р, 9F → џ, D1 → С, 80 → Ђ, B8 → ё, B2 → І, B5 → µ, 82 → ‚. Получается Привет.

Теперь понятно, почему у этих кракозябр такой узнаваемый вид:

• символов ровно вдвое больше, чем букв в исходном слове, – каждая русская буква распалась на свою пару байтов;
• через один стоит Р или С – это ведущие байты D0 и D1, одинаковые почти у всей кириллицы;
• вторыми идут разношёрстные знаки – это байты-продолжения, у каждой буквы свой.

Механика та же, что в уроке 7.2: байты целы, испортилась только интерпретация. Разница в том, что теперь границы символов разъехались с границами байтов – поэтому и счёт не сходится.

Обратный случай тоже встречается. Если байты Windows-1251 объявить кодировкой UTF-8, программа увидит байт CF – метку «начинается символ на четыре байта», – а следом F0, который вовсе не байт-продолжение. Последовательность недопустимая, и вместо букв появятся ромбики со знаком вопроса: �. Это специальный символ U+FFFD, которым помечают то, что декодировать не удалось.

Напоследок – предупреждение, чтобы не осталось ложного ощущения, будто «символ Unicode» и «буква, которую видит человек» – это всегда одно и то же.

• Букву й можно записать двумя способами: одной кодовой точкой U+0439 или двумя – и (U+0438) плюс отдельный значок краткости (U+0306). Выглядят они одинаково, а len() даёт 1 и 2.
• Эмодзи семьи 👨‍👩‍👦 – это три отдельных эмодзи, склеенные двумя невидимыми символами-соединителями; len() равен 5.
• Флаги стран собираются из пары букв-индикаторов, len() равен 2.

Вывод в одну фразу: len() в Python считает кодовые точки, и это не всегда совпадает с тем, что человек назвал бы «одним знаком». В обычных задачах разница не проявляется, но знать про неё стоит – иначе однажды строка из одного смайлика неожиданно окажется длиной пять.