问题：我无法理解IBM 文章摘录中的数字 256 (2^8) ：
另一方面，如果是大端系统，则高字节为 1，x 的值为 256。
假设数组中的每个元素消耗 4 位，那么处理器应该以某种方式读取：1000 0000。如果它是大端，则为 0001 0000，因为字节序不影响字节内的位。[2] 与文章中的256矛盾！？
问题：为什么数字是 256_dec (=1000 0000_bin) 而不是 32_dec (=0001 0000_bin)？
[2] 字节序问题不会影响具有单字节的序列，因为从存储的角度来看，“字节”被认为是一个原子单元。
因为一个字节是 8 位，而不是 4。无符号整数中的第 9 个最低有效位将具有值 2^(9-1)=256。（最不重要的值为 2^(1-1)=1）。
来自 IBM 文章：
unsigned char endian[2] = {1, 0};
short x;
x = *(short *) endian;
他们是正确的；在 big-endian 上的值为 (short)256，在 little-endian 上的值为 (short)1。
写出这些位，它是一个 {00000001_{base2}, 00000000_{base2}} 的数组。大端将解释从左到右读取的位数组；little endian 将交换两个字节。
回答您的后续问题：简而言之，大多数编程语言中没有“数组中元素的默认大小”。
在 C（可能是最流行的编程语言）中，数组元素的大小——或者任何东西，真的——取决于它的类型。对于 char 数组，元素通常为1 个字节。但对于其他类型，每个元素的大小是 sizeof() 运算符给出的任何值。例如，许多 C 实现给出 sizeof(short) == 2，所以如果你制作一个 short 数组，它将占用 2*N 字节的内存，其中 N 是元素的数量。
许多高级语言甚至不鼓励您尝试发现数组元素需要多少字节。提供固定数量的字节会使设计人员始终使用那么多字节，这有利于透明度和依赖其二进制表示的代码，但如果出现某种原因来更改表示，则不利于向后兼容性。
希望有帮助。（直到我写了第一个版本之后，我才看到其他评论。）
256 dec不是1000_0000bin，而是0000_0001_0000_0000bin。
使用交换字节（1 字节 = 8 位），这看起来像0000_0000_0000_0001bin，即 1 dec。