Конвертер текста в шестнадцатеричный код

Переводите текст в шестнадцатеричный код — его байты в UTF-8 или UTF-16, через пробел, массивом, экранированной строкой или дампом — и обратно в текст.

Ввод
Вывод
D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82

Строка как байты, в которых она хранится

Любая строка, с которой работает программа, внутри — это ряд байтов, и эта страница выписывает их в шестнадцатеричном виде, по две цифры на байт. Введите Hello, и вы получите 48 65 6C 6C 6F — по байту на букву, с пробелом после каждого, кроме последнего. Если же переключить направление на «Шестнадцатеричный код в текст» и вставить шестнадцатеричный код из журнала, базы данных или отладчика, вы получите обратно текст, который хранят эти байты.

Один и тот же текст даёт разные байты в разных кодировках, и единица определяет, чем являются цифры на этой странице. Она начинается с UTF-8, кодировки веба, где H — это байт 48, а א — байты D7 90. UTF-16 LE и UTF-16 BE тратят на каждый из этих символов по два байта, в противоположном порядке — 48 00 или 00 48 для H, — а «Кодовые точки» вовсе обходятся без байтов и записывают число, которое присваивает Unicode, U+05D0 для א. Какая бы единица ни была выбрана, она действует на шестнадцатеричный код, который вы читаете, так же, как на текст, который вы пишете, и остаётся выбранной: если вставленный код похож на код другой единицы, страница может предложить её, но переключает единицу только ваш щелчок.

Две шестнадцатеричные цифры на каждый байт

Байт хранит одно из 256 значений, от 0 до 255. В шестнадцатеричной системе счёт идёт шестнадцатками, цифрами от 0 до 9, а затем буквами от A до F для значений от десяти до пятнадцати, а шестнадцать раз по шестнадцать — это 256, поэтому двух шестнадцатеричных цифр хватает, чтобы назвать любой байт, и третья никогда не нужна: 00 — это 0, 7F — 127, а FF — 255. H — это 72, то есть четыре раза по шестнадцать и ещё восемь, поэтому её байт — 48.

Каждая шестнадцатеричная цифра обозначает ровно четыре бита, половину байта: 4 из 48 — это 0100, а 8 — это 1000, и рядом они дают восемь бит H, 01001000. Страница сохраняет обе цифры каждого байта, так что перевод строки — это 0A, а пробел — 20, и поскольку каждый байт занимает одинаковую ширину, шестнадцатеричный код можно прочитать обратно без чего-либо между байтами: 4869 — это Hi.

Буквы в шестнадцатеричном коде значат одно и то же в любом регистре. Страница пишет прописные, если вы не выберете «строчные», так что é — это C3 A9 или c3 a9, и читает она и то и другое, даже вперемешку в одной вставке.

Пять стилей, каждый под то место, куда его вставят

В шестнадцатеричном коде переключатель «Стиль» раскладывает одни и те же байты пятью способами, каждый — для того места, куда шестнадцатеричный код отправится дальше. Для Hi, то есть двух байтов 48 и 69:

  • «Через пробел» даёт 48 69, с пробелом между байтами: так легче всего читать и считать, и именно с этим стилем открывается страница.
  • «Слитно» даёт 4869, цифры подряд, — для поля или параметра, который принимает значение одной строкой шестнадцатеричных цифр.
  • «Массив» даёт 0x48, 0x69 — каждый байт числом с 0x впереди и запятой между байтами, и это можно сразу вставить в массив байтов на C, C#, JavaScript, Python или Go.
  • «Экранированный» даёт \x48\x69 — каждый байт как \x и его две цифры, так байт записывают внутри строки C или байтового литерала Python, например b'\x48\x69'.
  • «Дамп» раскладывает байты по строкам, указывая, где начинается каждая строка, и показывая рядом те же байты в виде текста: следующий раздел читает такой дамп.

При чтении принимаются все пять, а также другое форматирование, которое не трогает байты: двоеточия, как в 48:69, дефисы, которые пишет BitConverter.ToString из .NET, как в 48-69, 0x или 0X перед каждым байтом и однократная обёртка всей вставки в круглые, квадратные или фигурные скобки или в кавычки. Стиль и регистр важны только при записи, поэтому оба переключателя исчезают, когда выбрано направление «Шестнадцатеричный код в текст».

В стиле «Экранированный» кроется одна ловушка. В строке JavaScript или в обычной строке Python, а не в байтовом литерале, \x обозначает символ, а не байт, поэтому \xD7\x90 там — это два символа, а не א, чьи байты в UTF-8 — D7 90. За пределами ASCII передавайте байты тому, что принимает байты.

Чтение дампа, столбец за столбцом

Дамп раскладывает байты по шестнадцать на строку, со столбцом с каждой стороны, который помогает их найти. В стиле «Дамп» Hello, World! и перевод строки заполняют одну строку: сначала 00000000 — смещение, то есть место первого байта строки при счёте с нуля, восемью шестнадцатеричными цифрами; затем четырнадцать байтов, восемь и потом шесть, с более широким промежутком между половинами; затем |Hello, World!.| — те же байты в виде символов, где каждый байт, не являющийся печатным символом ASCII, показан точкой, в том числе перевод строки. Последняя строка содержит только 0000000E, то есть четырнадцать: место, где стоял бы следующий байт, а значит, длину. Именно в таком формате печатает hexdump -C.

  • Если выбрано «Шестнадцатеричный код в текст» и любая единица, кроме «Кодовые точки», вставленный дамп читается только ради его байтов: столбец текста в чтение не входит, ни одно смещение не читается как байт, а замечание под результатом говорит, что ввод был прочитан как дамп, и называет формат.
  • Так читаются два формата: формат hexdump -C и то, что печатает xxd без параметров, где после каждого смещения стоит двоеточие, а байты стоят группами по четыре цифры. Простой шестнадцатеричный код, который печатает xxd -p, в формате не нуждается и читается как любой другой шестнадцатеричный код.
  • hexdump -C печатает строку, где стоит только *, вместо строк, повторяющих строку над ними, и страница восстанавливает эти строки по смещению ниже, так что байты возвращаются полностью.
  • Каждое смещение после первого должно следовать из байтов над ним, включая длину в последней строке hexdump -C, и строка, смещение которой из них не следует, отклоняется на месте, а не читается неправильно: именно там обнаруживается пропущенная строка, потерянный байт или опечатка в смещении. То, после чего не идёт ни одного смещения, проверить нельзя, поэтому дамп без первых строк или конец дампа без строки длины после него — а xxd такой строки не пишет — читается как то, что осталось.

UTF-16 LE и почему каждый второй байт — 00

Windows хранит текст в UTF-16 с младшим байтом впереди, то есть в UTF-16 LE; в .NET это Encoding.Unicode, и SQL Server хранит значение NVARCHAR так же. UTF-16 отдаёт каждому символу до U+FFFF по два байта, и у всего до U+00FF — английских букв, цифр, é и остального Latin-1 — старший байт равен 00. Когда младший байт идёт первым, этот ноль оказывается после каждой буквы: Hi — это 48 00 69 00.

SQL Server показывает значение VARBINARY как 0x и его шестнадцатеричные цифры, поэтому NVARCHAR, содержащий Hi, после приведения к VARBINARY показывается как 0x48006900. Вставьте это сюда, когда выбран UTF-8, и текст выйдет как H, NUL, i и NUL, а замечание под ним скажет, что каждый второй байт — 00, как бывает, когда текст латиницей записан в UTF-16, а не в UTF-8, и рядом будет кнопка «Переключить на UTF-16 LE». Нажмите её, и те же байты прочитаются как Hi.

UTF-16 BE, напротив, ставит первым старший байт, поэтому Hi там — 00 48 00 69, а א, которая в UTF-16 LE — D0 05, там — 05 D0. Нули на первом месте каждой пары заставляют замечание предложить UTF-16 BE. Оно молчит, как только в тексте появляется символ дальше U+00FF, потому что старший байт такого символа не 00, и говорит только там, где каждый второй байт — 00.

Метка порядка байтов в начале

Текст может начинаться с U+FEFF — символа, который ничего не показывает и нужен для того, чтобы быть меткой порядка байтов. В UTF-16 его два байта задают порядок каждой пары после них: FF FE для UTF-16 LE и FE FF для UTF-16 BE, а в UTF-8 это три байта EF BB BF — сигнатура того, что текст записан в UTF-8, у которого только один порядок.

Страница сохраняет метку, а не отбрасывает её. Шестнадцатеричный код, который начинается с собственной метки выбранной единицы, читается как текст, начинающийся с U+FEFF, и замечание говорит, что метка сохранена, так что повторная запись этого текста даёт те же байты вместе с меткой. Шестнадцатеричный код, который начинается с метки другого порядка UTF-16 или с метки UTF-16, когда выбран UTF-8, получает замечание о том, что байты начинаются с метки другой единицы, рядом с кнопкой, переключающей на порядок, который называет метка. В любом месте после начала U+FEFF — обычный символ и замечания не вызывает.

Байты, которые не являются текстом, показаны как U+FFFD

Не всякая последовательность байтов — текст в выбранной единице: символ без последнего байта, случайный байт вроде E9, которым старые кодовые страницы записывают é, и лишний байт, оставшийся в конце UTF-16, ничего не означают. Но одна плохая последовательность не губит всю вставку: каждая заменяется на U+FFFD, символ замены, а всё остальное читается как обычно.

Затем замечание называет их количество, а первую — по её месту среди байтов, по цифрам, которыми вы её записали, и по её строке и столбцу. Café, сохранённое в Windows-1252, кодовой странице Windows для западноевропейского текста, — это 43 61 66 E9, где é — один байт E9; прочитанное как UTF-8, оно возвращается как Caf и U+FFFD, а замечание называет байт 4, записанный как E9, — строка 1, столбец 10. В UTF-8 это слово — 43 61 66 C3 A9.

Оно считает последовательности, а не байты: F0 9F 98, три из четырёх байтов 😀, — это один U+FFFD. А U+FFFD, который действительно есть в тексте, байты EF BF BD, читается как текст и вообще не считается, так что замечание всегда касается только тех байтов, которые не прочитались.

Как превратить шестнадцатеричный код обратно в файл

Чтение отдаёт не только текст, но и байты. Когда выбрано направление «Шестнадцатеричный код в текст» и UTF-8, UTF-16 LE или UTF-16 BE, кнопка «Скачать» сохраняет в файл с именем bytes.bin ровно те байты, которые были прочитаны, включая те, что не были текстом, и до того, как какой-либо из них был заменён: это та работа, которую xxd -r делает с дампом. Для кодовых точек, которые не являются байтами, «Скачать» нет, как нет и при записи, когда то, что вы уносите, — это цифры.

Так что шестнадцатеричный код того, что никогда не было текстом, всё равно возвращается целиком. Любое изображение PNG начинается с восьми байтов 89 50 4E 47 0D 0A 1A 0A; прочитанные как UTF-8, они показываются как U+FFFD, буквы PNG и четыре управляющих символа, с замечанием об одной последовательности, которая не является текстом, а «Скачать» сохраняет все восемь в точности. Файл всегда называется bytes.bin, потому что у байтов нет имени, так что дайте ему собственное, например image.png, когда он будет сохранён.

Куда идти за символом, его битами или числом

Чтобы узнать, что это за символ — его имя, категорию и не относится ли он к невидимым, — Инспектор символов Unicode разбирает текст по одной кодовой точке за раз и показывает также байты UTF-8 каждой из них.

Конвертер текста в двоичный код — это та же самая страница, открывающаяся на двоичном коде, где схему, которой следует UTF-8, можно прочитать в первых битах каждого байта. А число — не текст: 255, введённое здесь, — это цифры 2, 5 и 5, а значит, байты 32 35 35, тогда как Конвертер систем счисления принимает 255 как величину и записывает её в шестнадцатеричном виде как ff.

Частые вопросы

Как превратить шестнадцатеричный код в текст?
Выберите «Шестнадцатеричный код в текст», вставьте код и выставьте единицу в соответствии с кодировкой, в которой он записан: UTF-8 для большинства текстов, UTF-16 LE для кода, взятого из строки Windows или .NET или из столбца NVARCHAR. Пробелы, запятые, двоеточия и дефисы между байтами, 0x или \x перед ними и одна обёртка вокруг всего чтению не мешают, как и любой регистр.
Почему между каждыми двумя буквами моего текста стоит NUL?
Скорее всего, это UTF-16 LE, прочитанный как UTF-8. UTF-16 LE записывает каждую английскую букву двумя байтами — её значением в ASCII и затем 00, а UTF-8 читает каждый из этих нулей как отдельный символ, NUL. Выберите UTF-16 LE или нажмите кнопку переключения, если страница предлагает её рядом со своим замечанием, и буквы сомкнутся.
Почему буквы с диакритикой в моём шестнадцатеричном коде выходят как U+FFFD?
Скорее всего, код был записан в старой кодовой странице вроде Windows-1252, где é — это один байт E9, тогда как в UTF-8 é — это C3 A9, а одинокий E9 текстом не является. Страница читает UTF-8 и UTF-16 и не читает старых кодовых страниц, поэтому вместо того, чтобы угадывать, какая имелась в виду, показывает каждую такую последовательность как U+FFFD и говорит, где находится первая. Кнопка «Скачать» всё равно отдаст вам байты такими, какими они были.
Можно ли вставить то, что напечатал xxd или hexdump -C?
Да: формат hexdump -C — его же записывает и стиль «Дамп» — и то, что печатает xxd без параметров. Столбец текста отбрасывается, ни одно смещение не читается как байт, строка с * восстанавливается, а замечание говорит, какой из двух форматов был прочитан; смещение, которое не следует из байтов перед ним, останавливает чтение на своей строке, потому что строки уже не согласуются друг с другом. Простой шестнадцатеричный код xxd -p тоже читается, как любой другой, без замечания.
Важно ли, прописными или строчными буквами записан шестнадцатеричный код?
Для байтов — нет: 4A и 4a — один и тот же байт, J. Страница пишет прописные, если вы не выберете «строчные», и этот выбор касается смещений дампа так же, как его байтов; при чтении принимается любой вариант, даже вперемешку в одной вставке.
Как получить файл обратно из шестнадцатеричного дампа?
Выберите «Шестнадцатеричный код в текст» и UTF-8 или любой из двух UTF-16, вставьте дамп или простой шестнадцатеричный код и нажмите «Скачать». Файл, который сохраняет кнопка, bytes.bin, содержит ровно те байты, что прочитаны из вставленного, текст это или нет, так что он делает работу xxd -r; дайте ему то имя, которое у него было.
Безопасно ли вставлять шестнадцатеричный код из базы данных в продакшене или из журнала?
Да, насколько это касается преобразования. Оно происходит на вашем собственном устройстве, в какую бы сторону ни шло: шестнадцатеричный код, который вы вставляете, текст, в который он превращается, и любой файл, который сохраняет «Скачать», никуда не отправляются.

Похожие инструменты

  • Конвертер текста в двоичный код

    В двоичном коде байт записан своими восемью битами, и там читается схема UTF-8: é здесь C3 A9, а там 11000011 10101001 — первый байт начинается с 110, потому что буква занимает два, а второй с 10, потому что продолжает её. Двоичный код есть и на этой странице; та открывается на нём.

  • Инспектор символов Unicode

    Узнайте, из каких именно символов состоит строка.

  • Конвертер систем счисления

    Введите здесь 255, и вы получите три байта, по одному на каждый символ: 32 35 35. Та страница читает 255 как число и переводит само значение, а в шестнадцатеричном коде это ff.

  • Base64

    Кодирует и декодирует Base64 — полная поддержка UTF-8.