情境
這是我的 StackOverflow 問題的重新發布，該問題被錯誤地提出，因為它與程式設計無關。
我正在 OverTheWire 上玩 Bandit，並且十三級需要在不知道檔案副檔名的情況下解壓縮各種壓縮檔案格式。為此，我一直在將十六進制轉儲與文件簽名進行比較加里·凱斯勒的網站。
然而我注意到十六進制簽名是向後顯示的。例如，採用此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。遇到的第一個檔案是存檔檔案 的十六進位轉儲，data.txt並且具有正確的簽章1f8b 0808（使用 找到head data.txt），它與簽章完全一致。然而，當我xxd -r data.txt | hexdump再次跑步時8b1f 0808。
對我的 StackOverflow 問題的評論似乎表明它與大/小字節序有關，並指出了-g1的標誌xxd，它代表分組。
這確實提供了正確的輸出，但我不明白分組是什麼或它是如何工作的。
答案1
分組是xxd指被視為（和顯示）為一個單元的位元組數。
預設情況下，xxd將其輸入視為以大端順序儲存的 2 個位元組/16 位元（四位十六進位數）群組。
這將產生這樣的效果：輸入中的每組兩個位元組將以相反的順序顯示（但實際上是大端系統的正確順序）。
即輸入的前兩個位元組18 8B將變成一個 16 位數8B18，這正是您所看到的。
當您xxd使用選項將分組更改為“1”-g1時，輸入中的所有位元組都將被解釋為單字節數字（顯然沒有“位元組順序”），並將按讀取順序顯示輸入。