Hex / ASCII / Unicode

Что такое конвертер hex / ASCII / Unicode?#

Один и тот же кусок текста можно записать тремя существенно разными способами, и этот инструмент позволяет увидеть все три одновременно:

• Текст — литеральные символы, как вы их набираете и читаете (Hello 世界 🌍).
• Hex-байты — «сырая» UTF-8-байтовую последовательность в шестнадцатеричном виде, по байту на пару (48 65 6C 6C 6F 20 ...). Именно это реально travelling по сети или лежит в файле.
• Кодовые точки — скалярные значения Unicode, одно U+XXXX на символ (U+0048 U+0065 ... U+1F30D). Так сам Unicode нумерует символы, независимо от байтовой кодировки.

Эти три представления важны тем, что их длины не совпадают, как только вы выходите за ASCII, — и это единственный источник большей части путаницы с кодировками текста. Символ — одна кодовая точка, но в UTF-8 он может занимать от одного до четырёх байт. Глобус-эмодзи 🌍 — один символ (U+1F30D), но в UTF-8 это четыре байта (F0 9F 8C 8D). Если вы когда-нибудь ошибались в подсчёте длины строки, видели, как база данных отвергала строку как «слишком длинную», или наблюдали, как срез подстроки попадает в середину символа, вы уже встречались с этим разрывом.

Отредактируйте любое из трёх представлений, и два других выведутся мгновенно. Парсер толерантный: hex-ввод принимает пробелы, двоеточия, дефисы, префиксы 0x; ввод кодовых точек принимает U+, \u, 0x или «голый» hex, разделённые пробелами, запятыми или точками с запятой.

Как пользоваться#

1. Селектором режима над полем ввода объявите, что вы набираете: Текст, Hex-байты или Коды.
2. Вставьте или отредактируйте в поле ввода. Два других представления заполняются автоматически справа.
3. Используйте Копировать у любого из трёх полей результата, чтобы забрать это представление.
4. Пример загружает Hello 世界 🌍, чтобы видеть, как ASCII, CJK и эмодзи отображаются по-разному. Очистить всё опустошает.

Ключевые возможности#

• Три представления, один источник истины. Редактируйте то представление, которое у вас есть; остальные вычисляются, их не нужно поддерживать вручную.
• UTF-8-байты, а не Latin-1. Hex-вывод — настоящая «проводная» UTF-8-последовательность, которую использует почти каждая современная система, а не унаследованное предположение «байт на символ».
• С учётом кодовых точек, включая астральные. Итерация for...of означает, что эмодзи считается одной кодовой точкой, а не двумя половинками суррогатов, поэтому вы видите U+1F30D, и никогда D83C DF0D.
• Строго на обратном пути. Hex-байты, не образующие корректный UTF-8 (строка нечётной длины или висячий байт-продолжение), сообщаются ясной ошибкой, а не декодируются в «кракозябры». Кодовые точки вне допустимого диапазона и одиночные суррогаты (U+D800–U+DFFF) отвергаются.

Разбор примера#

Загрузите Пример, чтобы получить Hello 世界 🌍, и три выведенных представления:

Text:       Hello 世界 🌍
Hex bytes:  48 65 6C 6C 6F 20 E4 B8 96 E7 95 8C 20 F0 9F 8C 8D
Code points: U+0048 U+0065 U+006C U+006C U+006F U+0020 U+4E16 U+754C U+0020 U+1F30D

ASCII-буквы H e l l o — скучная часть: по байту на каждую, кодовые точки с U+0048 по U+006F. Интересно всё остальное:

• 世 (U+4E16) — три UTF-8-байта: E4 B8 96. 界 (U+754C) — тоже три байта: E7 95 8C. Один символ, но не один байт.
• 🌍 (U+1F30D) — четыре UTF-8-байта: F0 9F 8C 8D. Кодовая точка выше U+FFFF, поэтому она живёт в астральной плоскости Unicode и требует 4-байтной UTF-8-последовательности — но это всё ещё один символ, одна запись в списке кодовых точек.

Проведите эксперимент в обратную сторону: переключите режим на Коды, вставьте U+1F600 U+1F604 и наблюдайте, как появится и текст (эмодзи семейства 😄 😄), и UTF-8-hex. Этот обратный путь — именно способ убедиться, какие байты соответствуют какому символу.

FAQ#

Почему мой эмодзи занимает четыре hex-байта, но только одну кодовую точку?#

Потому что UTF-8 — кодировка переменной ширины. Кодовые точки ниже U+0080 помещаются в один байт; U+0080–U+07FF — два; U+0800–U+FFFF — три; а всё от U+10000 и выше (большинство эмодзи, исторические письменности, музыкальные символы) — четыре. Кодовая точка — имя символа в Unicode; байты — то, как UTF-8 его хранит. Один символ, два разных числа.

В чём разница между U+XXXX и \uXXXX?#

Они указывают на одну кодовую точку, но из разных миров. U+0041 — собственная нотация Unicode. A — escape, используемый в строковых литералах JavaScript, Java и C. Подвох: \uXXXX вмещает лишь четыре hex-цифры, поэтому напрямую выразить астральную кодовую точку вроде U+1F30D нельзя — языки с \u требуют либо суррогатной пары, либо расширенного синтаксиса вроде \u{1F30D}. Ввод кодовых точек этого инструмента принимает любую форму.

Я вставил hex-байты и получил «invalid UTF-8». Что это значит?#

Вставленные байты не образуют корректную UTF-8-последовательность — чаще всего потому, что hex-строка нечётной длины (не хватает половинки байта), лидирующий байт заявляет многобайтовую последовательность, которую следующие байты не завершают, либо данные на самом деле закодированы не в UTF-8 (GBK, Shift-JIS, «голый» Latin-1). Декодер использует строгий режим, поэтому проблема сообщается, а не молча выдаёт символы замены.

Можно ли этим посчитать «настоящие» символы в строке?#

Да — подсчёт по кодовым точкам даёт то число, которое имел в виду пользователь, и то, по которому большинство UI должны ограничивать ввод. Заметьте, что Hello 世界 🌍 — 10 символов по кодовым точкам, хотя это 17 байт в UTF-8 и 11 UTF-16-кодовых единиц в JavaScript (string.length). Если у вас бюджет символов для твита или поля формы, считайте кодовые точки, а не байты и не string.length.