UC知道hexdump查看的字节序与UltraEdit显示的不一样
来源：百度知道 编辑：UC知道 时间：2024/06/29 01:50:04
同一个txt配置文件。
在ARM Linux平台上用hexdump命令查看，显示如下：
0000000 7601 340e 0001 3200 0305 0100
000000c
FTP传送到PC侧（Intel x86平台），用UltraEdit打开显示为：
00000000h: 01 76 0E 34 01 00 00 32 05 03 00 01
无论是binary方式还是text方式传送，都是这样显示的。
x86都是Little-Endian字节序，ARM端可以是Little-Endian也可以是Big-Endian（由编译器控制）。基于此，是不是可以认为这里ARM侧用的是Big-Endian字节序？因为跟PC端显示的顺序不同。
但如果hexdump加上-b参数（One-byte octal display），显示的顺序就跟PC侧是一致的：
0000000 001 166 016 064 001 000 000 062 005 003 000 001
000000c
如何解释？
回答让我满意的话另有加分。
二楼的很绕啊，我本来就已经晕了。是就是，不是就不是，不喜欢“如果...”。而且，0xabcd以单字节显示时怎么回是:cd ba 呢？更晕了。。。
在ARM Linux平台上用hexdump命令查看，显示如下：
0000000 7601 340e 0001 3200 0305 0100
000000c
FTP传送到PC侧（Intel x86平台），用UltraEdit打开显示为：
00000000h: 01 76 0E 34 01 00 00 32 05 03 00 01
无论是binary方式还是text方式传送，都是这样显示的。
x86都是Little-Endian字节序，ARM端可以是Little-Endian也可以是Big-Endian（由编译器控制）。基于此，是不是可以认为这里ARM侧用的是Big-Endian字节序？因为跟PC端显示的顺序不同。
但如果hexdump加上-b参数（One-byte octal display），显示的顺序就跟PC侧是一致的：
0000000 001 166 016 064 001 000 000 062 005 003 000 001
000000c
如何解释？
回答让我满意的话另有加分。
二楼的很绕啊，我本来就已经晕了。是就是，不是就不是，不喜欢“如果...”。而且，0xabcd以单字节显示时怎么回是:cd ba 呢？更晕了。。。
本来就是这样的啊 在pc里 内存显示为01 76实际上就是7601H。
linux我不懂，但是我估计linux的显示方式是经过处理的，而加了-b参数则是兼容pc的显示习惯。
我想可能是这样:
Linux平台上的不加-b参数情况下是将两个字节一起显示的(short型的数据)
由于加上-b后显示和pc一样可以推测ARM和PC的字节序一样。
而UE是以单字节方式显示的,所以:
0xabcd以单字节显示时就是:cd ba,以双字节显示就是 abcd了.
如果(只是如果)pc侧是Big-Endian字节序,显示肯定是一样的。