шестнадцатеричная путаница

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

hexdump test.txt
0000000 b1c3
0000002

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

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

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

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


hexdump
person zedoo    schedule 17.05.2010    source источник
comment
en.wikipedia.org/wiki/Endianness   -  person Konerak    schedule 17.05.2010
comment
Кажется, это объясняет, почему xxd и hexdump показывают разные результаты!   -  person kvantour    schedule 18.12.2020

Ответы (2)


arrow_upward
50
arrow_downward

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

person Marcelo Cantos    schedule 17.05.2010
comment
Я думал, что это должно быть как-то связано с порядком байтов. - person zedoo; 17.05.2010
comment
но почему шестнадцатеричный дамп по умолчанию использует этот запутанный формат вывода? есть ли какая-то историческая причина? - person accuya; 01.03.2012
comment
Что сбивает с толку, так это склонность людей кодировать числа в обратном порядке. Little-endian более логичен, поэтому он используется во многих архитектурах ЦП, включая x86, несмотря на его неуклюжесть. - person Marcelo Cantos; 02.03.2012
comment
На самом деле у big-endian и little-endian есть свои сильные и слабые стороны. Ни то, ни другое не является более логичным в абсолютном смысле. - person Marko Topolnik; 15.04.2016
comment
@MarceloCantos, что сбивает с толку, так это то, что он предполагает 16-битные слова с прямым порядком байтов. Какова логика выбора 16-битных слов? Или любая другая длина слова? IMO имеет больше смысла по умолчанию использовать представление с обратным порядком байтов, которое будет выглядеть одинаково независимо от длины слова, что намного менее запутанно в этом случае использования. - person akostadinov; 29.12.2016
comment
Чисто предположение, но историческая причина почти наверняка заключается в том, что шестнадцатеричный дамп изначально был реализован на машине с прямым порядком байтов, которая использовала 16-битные слова, и это было вполне разумным значением по умолчанию. - person William Pursell; 01.06.2017

arrow_upward
3
arrow_downward

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

hexdump -C file

or

od -tx1 < file

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

person akostadinov    schedule 16.11.2016