语境
这是我的 StackOverflow 问题的重新发布，该问题被错误地提出，因为它与编程无关。
我在 OverTheWire 上玩 Bandit，第十三关需要在不知道文件扩展名的情况下解压缩各种压缩文件格式。为此，我一直在将 hexdump 与Gary Kessler 网站上的文件签名进行比较。
然而，我注意到的是十六进制签名向后出现。例如，以这个gz, tgz gzip存档文件为例：
0000000 8b1f 0808 5006 5eb4 0302 6164 6174 2e32
0000010 6962 006e 3d01 c202 42fd 685a 3139 5941
0000020 5326 8e59 1c4f 00c8 1e00 ff7f f9fb da7f
...
8b1f 0808与Gary Kessler 的网站所显示的相比，签名是向后的：
1F 8B 08 .‹. GZ, TGZ GZIP archive file
VLT VLC Player Skin file
问题
为什么签名是反的？1F 8B 08与8b1f 0808。遇到的第一个文件是存档文件的 hexdump data.txt，并且具有正确的签名1f8b 0808（使用 找到head data.txt），它与签名完全一致。但是，当我xxd -r data.txt | hexdump再次跑步时8b1f 0808。
对我的 StackOverflow 问题的评论似乎表明它与大/小字节序有关，并将我指向代表分组的-g1标志。xxd
这确实提供了正确的输出，但我不明白分组是什么或它是如何工作的。
分组是
xxd指作为一个单元处理（和显示）的字节数。默认情况下，
xxd将其输入视为以大端顺序存储的 2 字节/16 位（四位十六进制数）组。这将产生来自输入的每组两个字节将以相反的顺序显示（但实际上是大端系统的正确顺序）。
即输入的前两个字节
18 8B将变成一个 16 位数字8B18，这正是您所看到的。当您
xxd使用 option 将分组更改为“1”时-g1，输入中的所有字节都将被解释为单字节数字（显然没有“endian-ness”），并将按照读取它们的顺序显示输入。