关于字节存储顺序的问题
发表于 2010-04-21 | 来源：互联网 | 阅读：
情况是这样的:
有一个文档a.txt,里面只有一个字符"我";
我在linux下用hexdump查看a.txt的十六进制内容为: D2 CE
但在windows下用UltraEdit查看a.txt的十六进制内容却为 : CE D2
在硬盘中, 低地址存储CE还是D2?
读进内存后,在内存中 低地址存储CE还是D2?
又或是linux和windows各不相同?
我知道这里有一个字节顺序问题,但是我还是想不明白,希望有高人能分析一下…
这个跟机器采用的处理器大小端结构有关，一般intel和amd公司的产品都是小端的，看看你两台机器的配置吧按楼主说的情况，应该是一个大端、一个小端
我的机器是双系统…既有windows又有linux,我就是在这台机器上的windows和linux查看,得到两个不同的结果的cup是intel的,如果跟系统无关,为什么却不同呢?有人能回答我的问题吗?希望不要说些废话吧…要针对我帖子所提的问题…
这是一个所谓的高位先存和低位先存的问题。我刚用VC2003.net调试了一下，字符’我’的Unicode是CED2。在不同的操作系统里，当运行程序时，相同的字符在内存中的地址顺序可能是不同的。你遇到的刚好就是这种情况。你可以在Linux下用Gcc调试下’我’的内存分布，再用Windows下的Vc调试下，就明白了。还有，网络字符传输时一般也都是高位在前。另外，在硬盘中的物理存储和在内存中的调试运行期存储不是一个概念。我觉得硬盘中的存储顺序应该和操作系统是无关的。而你在Linux下运行的Hexdump显示的D2CE，就是Hexdump程序解析’我’的时候，读到的内存结构是高位先存，所以显示出来的也就是D2CE；同样，在Windows下的UltraEdit.exe显示的是其将’我’读入到内存后，内存结构是CED2。也就是说，Hexdump和UltraEdit显示的结果就是这两个程序在运行期间从内存中读到的’我’对应的字节分布。
个人理解是在内存中的存储方式是一样的，只不过显示的时候一个高位放在前面，一个高位放在后面显示。
google了一下，这是答案，希望对楼主有所帮助~~大小端的硬件是不能变的，如果重新编译内核，就是内核转换 直接调用/usr/include/linux/byteorder/little_endian.h里的宏进行转换 __cpu_to_be16s(x) /*cpu转大有效*/ __be16_to_cpus(x) /*大有效转cpu*/ …..
这是一个所谓的高位先存和低位先存的问题。我刚用VC2003.net调试了一下，字符’我’的Unicode是CED2。在不同的操作系统里，当运行程序时，相同的字符在内存中的地址顺序可能是不同的。你遇到的刚好就是这种情况。你可以在Linux下用Gcc调试下’我’的内存分布，再用Windows下的Vc调试下，就明白了。还有，网络字符传输时一般也都是高位在前。另外，在硬盘中的物理存储和在内……多谢你这么详细的回答,不过"我"字的真实unicode编码是D2CE,而不是不是你所说的CED2阿
一般在PC机上都是小端吧，有可能两个软件显示的方式不一样，还是要调试一下看看具体的内存字节
我说错了,不是unicode编码,而是gb18030编码,"我"字的gb18030编码是D2CE
那么，可以肯定的这样说吗? :在内存中的存储方式，与硬盘中的存储方式是一样的?要么同时小端,要么同时大端?
你愁的还不是想知道到底文档在硬盘最终是怎么一个一个字节的存储吗?你在linux下用hexdump -n num <filename>就行了,num表示显示filename文件的前num个字节的内容;你只要:hexdump -n 1 <filename>hexdump -n 2 <filename>hexdump -n 3 <filename>hexdump -n 4 <filename>hexdump -n 5 <filename>这样你就知道各个字节,从低地址到高地址,得十六进制内容是什么了!!!
既然大家讲到编码问题，我想问一下，如果将内存中的一个字符串以GBK编码保存到一个文本呢？
“我”的GB编码是CE D2，无论在什么系统下和字节顺序无关。只有多字节的数据类型才涉及到字节顺序的问题。比如“我”的UTF-16编码,在不同的系统下可能是6211或1162，而CE D2并不是一个两个字节长的数据类型，它是一个由两个单字节组成的。这和大家熟知的UTF-8的情况是一样的。你linux下用dumpbin看到了D2 CE,估计你参数用得不对，强制使用了双字节的查看模式。
hexdump -C什么都不加的hexdump如下 -x Two-byte hexadecimal display. Display the input offset in hexadecimal, followed by eight, space separated, four column, zero-filled, two-byte quantities of input data, in hexadeci- mal, per line.再加上小端，“我”是d2ce。
1. 内存存储方式和硬盘存储方式没有任何关系。这就是为什么在同一台电脑上，解析同一个字符’我’时，得到不同的字符顺序。运行期内存存储方式是和操作系统密切相关的。2. 我可以保证Windows下Vc环境显示的字节顺序就是典型的低位先存。也就是说’我’的编码就是CED2，而不是D2CE。而你在Linux下显示的如果是D2CE，那就是高位先存。一个字符的编码是固定的，只是显示的时候有所不同。另外还有一种办法，可以帮助你用来测验字符的真实编码，这适用于任何系统。代码如下：/////// begin. code by shrek ///////unsigned short nMyByte = 0xD2CE; —————– (1)char szTrueCode[3] = {0};memcpy(szTrueCode, (char *)&nMyByte, 2);/////// end. code by shrek ///////在以上的代码段中，当我们把nMyByte赋值为0xD2CE时，调试结果显示，szTrueCode就是"我"。而如果把nMyByte赋值为0xCED2时，调试结果是另一个字"椅".所以说’我’的编码就是CED2。
学习了
应该是软件显示方式的问题。