字节顺序——为什么字符要向后放入 Int16 打印？
以下 C 代码在 XCode 中编译并运行：
UInt16 chars = 'ab';
printf("\nchars: %2.2s", (char*)&chars);
打印“ba”，而不是“ab”。
为什么？
The following C code, compiled and run in XCode:
UInt16 chars = 'ab';
printf("\nchars: %2.2s", (char*)&chars);
prints 'ba', rather than 'ab'.
Why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
该特定实现似乎以小端格式存储多字符常量。在常量
'ab'中，字符'b'是最低有效字节（小端），字符'a'是最高有效字节。如果您将chars视为数组，则为chars[0] = 'b'和chars[1] = 'a'，因此 printf 将被视为"ba"。另外，我不确定您认为维基百科有多准确，但关于 C 语法 它有本节：
因此，看来一般应避免使用
'ab'多字符常量格式。That particular implementation seems to store multi-character constants in little-endian format. In the constant
'ab'the character'b'is the least significant byte (the little end) and the character'a'is the most significant byte. If you viewedcharsas an array, it'd bechars[0] = 'b'andchars[1] = 'a', and thus would be treated by printf as"ba".Also, I'm not sure how accurate you consider Wikipedia, but regarding C syntax it has this section:
So it appears the
'ab'multi-character constant format should be avoided in general.这取决于您正在编译/运行程序的系统。
显然，在您的系统上，短值以 0x6261 (ba) 的形式存储在内存中：小端方式。
当您要求解码字符串时，printf 将逐字节读取您存储在内存中的值，实际上是“b”，然后是“a”。因此你的结果。
It depends on the system you're compiling/running your program on.
Obviously on your system, the short value is stored in memory as 0x6261 (ba): the little endian way.
When you ask to decode a string, printf will read byte by byte the value you have stored in memory, which actually is 'b', then 'a'. Thus your result.
多字符字符文字是实现定义的：
gcc 和 icl 在 Windows 7 上打印
ba。 tcc 打印a并完全删除第二个字母...Multicharacter character literals are implementation-defined:
gcc and icl print
baon Windows 7. tcc printsaand drops the second letter altogether...您的问题的答案可以在您的标签中找到：Endianness。在小端机器上，首先存储最低有效字节。这是约定，完全不影响效率。
当然，这意味着您不能简单地将其转换为字符串，因为字符的顺序是错误的，因为字符串中没有有效的字节，而只是一个序列。
如果您想查看变量中的字节，我建议使用可以读取实际字节的调试器。
The answer to your question can be found in your tags: Endianness. On a little endian machine the least significant byte is stored first. This is a convention and does not affect efficiency at all.
Of course, this means that you cannot simply cast it to a character string, since the order of characters is wrong, because there are no significant bytes in a character string, but just a sequence.
If you want to view the bytes within your variable, I suggest using a debugger that can read the actual bytes.