порядок вывода шестнадцатеричного дампа

#python #python-3.8

#шестнадцатеричный дамп

Вопрос:

Я играю с утилитой шестнадцатеричного дампа Unix. Мой входной файл закодирован в формате UTF-8 и содержит один символ ñ C3 B1 в шестнадцатеричном формате UTF-8.

 hexdump test.txt
0000000 b1c3
0000002

А? Это показывает B1 C3 — обратное тому, что я ожидал! Может кто-нибудь объяснить?

Для получения ожидаемого результата я делаю:

 hexdump -C test.txt
00000000  c3 b1                                             |..|
00000002

Я думал, что понимаю системы кодирования.

Ответ №1:

Это связано с тем, что в шестнадцатеричном дампе по умолчанию используются 16-разрядные слова, и вы используете архитектуру с малым порядком. Таким образом, последовательность байтов b1 c3 интерпретируется как шестнадцатеричное слово c3b1 . -C Опция заставляет шестнадцатеричный дамп работать с байтами вместо слов.

1. Я думал, что это должно быть как-то связано с порядком байтов.

2. но почему hexdump по умолчанию использует этот запутанный формат вывода? есть ли какая-либо историческая причина?

3. Что сбивает с толку, так это склонность людей кодировать числа в порядке возрастания. Порядок с малым порядком более логичен, поэтому он используется на многих архитектурах ЦП, включая x86, несмотря на неудобство.

4. На самом деле у каждого из них есть свои сильные и слабые стороны. Ни один из них не является «более логичным» в абсолютном смысле.

5. Чисто гипотеза, но историческая причина почти наверняка заключается в том, что hexdump изначально был реализован на маленькой конечной машине, которая использовала 16-битные слова, и это было вполне разумное значение по умолчанию.

Ответ №2:

Я нашел два способа избежать этого:

 hexdump -C file

или

 od -tx1 < file

Я думаю, что глупо, что шестнадцатеричный дамп решил, что файлы обычно имеют 16-битный порядковый номер. Очень запутанный IMO.