此 Microsoft 文档中的字节/位顺序是什么？

Question

这是 Windows .lnk 快捷方式格式的文档：

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943

ShellLinkHeader 结构是这样描述的：

这是一个文件：

查看HeaderSize，字节为4c 00 00 00，应该表示十进制76。这是一个小端整数，这并不奇怪。

接下来是 LinkCLSID，其字节为 01 14 02 00 00 00 00 00 c0 00 00 00，表示值“00021401-0000-0000-C000-000000000046”。 This answer 似乎解释了为什么字节顺序会发生变化，因为最后 8 个字节是字节数组，而其他字节是 little-endian 数字。

我的问题是关于 LinkFlags 部分。

LinkFlags 部分是这样描述的：

我文件中的字节是9b 00 08 00，或者二进制：

9    b    0    0    0    8    0    0
1001 1011 0000 0000 0000 1000 0000 0000
 ^

通过比较不同的文件，我发现标记为^的位在文档中是位6/G（标记为红色）。

如何解释这个？字节的顺序与文档中的顺序相同，但每个字节的位都颠倒了？

Answer 1

这里的问题源于这些规范中显示的位列表根本不适合其下方的数字。它的目的是在其下方放置位列表，并且该列表从最低位到最高位，这与我们从左到右读取数字的方式完全相反。

该列表清楚地显示了从 0 到 31 编号的位，这意味着这确实是一个 32 位值，而不是四个字节。具体来说，这意味着在执行任何其他操作之前，需要将原始读取字节解释为单个 32 位整数。与所有其他值一样，这意味着它需要被读取为 little-endian 数字，其字节反转。

所以你的9b 00 08 00 变成了0008009b，或者二进制的0000 0000 0000 1000 0000 0000 1001 1011。

但是，正如我所说，规范中的列表显示了从最低到最高的位。所以为了适应它们，反转二进制版本：

0           1            2           3
0123 4567 8901 2345 6789 0123 4567 8901
ABCD EFGH IJKL MNOP QRST UVWX YZ@_ ____
---------------------------------------
1101 1001 0000 0000 0001 0000 0000 0000
       ^

所以第 6 位，在规范中表示为“G”，为 0。

不过，如果您颠倒规格，并按逻辑从最高到最低列出位，整个事情就会变得更有意义：

 3           2            1           0
1098 7654 3210 9876 5432 1098 7654 3210
____ _@ZY XWVU TSRQ PONM LKJI HGFE DCBA
---------------------------------------
0000 0000 0000 1000 0000 0000 1001 1011
                               ^
   0    0    0    8    0    0    9    b

这使得字母参考看起来不那么直观，但它完全适合下面的数字版本。该位与您的发现相匹配（您所拥有的值为“9”的第三位），您还可以清楚地看到最高 5 位未使用。