十六进制转储输出顺序

Question

我正在使用Unix的hexdump实用程序进行操作。我的输入文件是UTF-8编码，包含一个单独的字符ñ，它在十六进制UTF-8中表示为C3 B1。

hexdump test.txt
0000000 b1c3
0000002

咦？这显示的是 B1 C3 - 与我预期的相反！有人能解释一下吗？

要得到预期输出，我需要：

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

我曾经认为自己理解编码系统。

- zedoo

---

http://en.wikipedia.org/wiki/Endianness - Konerak

这似乎解释了为什么xxd和hexdump显示不同的结果！ - kvantour

Answer 1

这是因为hexdump默认使用16位字，并且您正在运行的是小端架构。因此，字节序列b1 c3被解释为十六进制字c3b1。使用-C选项可以强制hexdump使用字节而不是字。

- Marcelo Cantos

---

我在想这一定与字节序有关。 - zedoo

为什么hexdump默认使用这种令人困惑的输出格式？是否有历史原因？ - accuya

人类倾向于按大端序方式编码数字，这是令人困惑的。小端序更为合理，这就是为什么许多 CPU 架构（包括 x86）使用它，尽管有些不太方便。 - Marcelo Cantos

实际上，大端序和小端序各有优势和劣势。从绝对意义上来说，没有哪一种是“更合理”的。 - Marko Topolnik

@MarceloCantos，令人困惑的是它假定了16位字节小端序。选择16位字节的逻辑是什么？或者任何其他字节长度？在我看来，默认使用大端序表示更有意义，这样无论字节长度如何，它都会看起来相同，在这种情况下更少令人困惑。 - akostadinov

纯属猜测，但历史原因几乎可以确定的是，hexdump最初是在使用16位字的小端机器上实现的，并且这是一个完全合理的默认值。 - William Pursell

Answer 2

我找到了两种避免这种情况的方法：

hexdump -C file

或者

od -tx1 < file

我认为hexdump认为文件通常是16位字节小端的做法很愚蠢。在我看来，这非常令人困惑。

- akostadinov

---

虽然hexdump默认使用16位字，但我认为它的字节序取决于它运行的架构 - undefined

@erwaman，没错。我尝试使用podman run --rm -ti --arch s390x --entrypoint /bin/sh quay.io/centos/centos:stream9命令，并安装util-linux来获取hexdump。在没有标志的情况下，它显示了大端格式。 - undefined