Little Endian 与 Big Endian 架构
Little Endian vs. Big Endian architectures
我有一个问题，这是与一位大学教授关于 Endianness 的一种分歧，所以我没有找到任何方法来解决这个问题并找到正确的答案，而是在 Stack Overflow 社区中提问并展开讨论。
假设我们将这个数字 (hex)11FF1 定义为一个整数，例如在 C++ 中它将是这样的：int num = 0x11FF1，并且 我说 在 little endian 机器的内存中，数字将显示为 :
addr[0] is f1 addr[1] is 1f addr[2] is 01 addr[3] is 00
in binary : 1111 0001 0001 1111 0000 0001 0000 0000
因为编译器将 0x11ff1 视为 0x0001ff1 并且还将 00 视为 1st byte和01作为2nd byte等等，对于Big Endian 我相信它看起来像：
addr[0] is 00 addr[1] is 01 addr[2] is 1f addr[3] is f1
in binary : 0000 0000 0000 0001 0001 1111 1111 0001
但是他有另外的看法，他说:
小端
大端:
Actually I don't see anything logical in his representation, so I hope the developers Resolve this disagreement, Thanks in advance.
你的十六进制和二进制数是正确的。
little-endian 你的（教授的？）法语图像完全没有意义，3 个表示中的 none 与其他 2 个一致。
73713 是十六进制的 0x11ff1，因此没有任何 0xFF 字节（二进制 11111111）。
在 32 位 little-endian 中，字节是 F1 1F 01 00 按照内存地址递增的顺序。
您可以通过从完整十六进制值的低端获取成对的十六进制数字（字节/八位字节）来获得它，然后在您使用该值后用零填充。
看起来他们可能在十六进制值的错误一侧填充了 0 到 zero-extend 到 32 位 0x11ff1000，而不是 0x00011ff1.请注意，这些是整数的完整十六进制值，而不是试图以任何顺序将其分解为单独的十六进制字节。
但是十六进制和二进制不匹配；它们的二进制 以 all-ones 字节结束 ，因此它具有 FF 作为高字节，而不是第 3 个字节。我没有检查它是否与 PDP（混合）字节序中的十六进制匹配。
他们将十六进制列分成 4 个 byte-sized 组，这似乎表明它按内存顺序显示字节。但是那一列在他们的大图像和 little-endian 图像之间是相同的，所以显然这不是他们正在做的，他们确实只是通过左移将它扩展到 32 位（用低而不是高零填充） .
此外，大端与小端中的二进制字段并不是彼此相反的。要从大端翻转到小端，您需要反转整数中字节的顺序，保持每个字节值相同。 （比如 x86 bswap）。他们的 11111111 (FF) 字节在他们的 big-endian 版本中排在第二位，但在 little-endian.
中排在最后
TL:DR: 不幸的是，这些图像没有任何东西能让我看到 任何 感觉。
我有一个问题，这是与一位大学教授关于 Endianness 的一种分歧，所以我没有找到任何方法来解决这个问题并找到正确的答案，而是在 Stack Overflow 社区中提问并展开讨论。
假设我们将这个数字 (hex)11FF1 定义为一个整数，例如在 C++ 中它将是这样的：int num = 0x11FF1，并且 我说 在 little endian 机器的内存中，数字将显示为 :
addr[0] is f1 addr[1] is 1f addr[2] is 01 addr[3] is 00
in binary : 1111 0001 0001 1111 0000 0001 0000 0000
因为编译器将 0x11ff1 视为 0x0001ff1 并且还将 00 视为 1st byte和01作为2nd byte等等，对于Big Endian 我相信它看起来像：
addr[0] is 00 addr[1] is 01 addr[2] is 1f addr[3] is f1
in binary : 0000 0000 0000 0001 0001 1111 1111 0001
但是他有另外的看法，他说:
小端
大端:
Actually I don't see anything logical in his representation, so I hope the developers Resolve this disagreement, Thanks in advance.
你的十六进制和二进制数是正确的。
little-endian 你的（教授的？）法语图像完全没有意义，3 个表示中的 none 与其他 2 个一致。
73713 是十六进制的 0x11ff1，因此没有任何 0xFF 字节（二进制 11111111）。
在 32 位 little-endian 中，字节是 F1 1F 01 00 按照内存地址递增的顺序。
您可以通过从完整十六进制值的低端获取成对的十六进制数字（字节/八位字节）来获得它，然后在您使用该值后用零填充。
看起来他们可能在十六进制值的错误一侧填充了 0 到 zero-extend 到 32 位 0x11ff1000，而不是 0x00011ff1.请注意，这些是整数的完整十六进制值，而不是试图以任何顺序将其分解为单独的十六进制字节。
但是十六进制和二进制不匹配；它们的二进制 以 all-ones 字节结束 ，因此它具有 FF 作为高字节，而不是第 3 个字节。我没有检查它是否与 PDP（混合）字节序中的十六进制匹配。
他们将十六进制列分成 4 个 byte-sized 组，这似乎表明它按内存顺序显示字节。但是那一列在他们的大图像和 little-endian 图像之间是相同的，所以显然这不是他们正在做的，他们确实只是通过左移将它扩展到 32 位（用低而不是高零填充） .
此外，大端与小端中的二进制字段并不是彼此相反的。要从大端翻转到小端，您需要反转整数中字节的顺序，保持每个字节值相同。 （比如 x86 bswap）。他们的 11111111 (FF) 字节在他们的 big-endian 版本中排在第二位，但在 little-endian.
TL:DR: 不幸的是，这些图像没有任何东西能让我看到 任何 感觉。