为什么在little-endian系统中生成的tar文件可以在big-endian的系统中被正确读取？

flw2

namtso 说的就是我想说的。
文件就是字节流。1 2 3 4，想象一个sockfd,read(sockfd),write(2)对方open (file),write(sockfd) 你考虑了字节序吗？显然没有.不需要考虑是不是要把第4个字节放第一个字节的位置。

gnap说的和文件无关。举个例子 比如tar文件内容是啊abcd
char buf[4];
fd=open(file)
read(fd,buf,4)
那么, buf[0]=a... buf[3]=d   不管在什么机器上都是这样的结果。

然后处理，没有看出区别来吧

langue

原帖由 flw2 于 2006-12-1 21:21 发表
namtso 说的就是我想说的。
文件就是字节流。1 2 3 4，想象一个sockfd,read(sockfd),write(2)对方open (file),write(sockfd) 你考虑了字节序吗？显然没有.不需要考虑是不是要把第4个字节放第一个字节的位置。

gnap说的和文件无关。举个例子 比如tar文件内容是啊abcd
char buf[4];
fd=open(file)
read(fd,buf,4)
那么, buf[0]=a... buf[3]=d   不管在什么机器上都是这样的结果。

然后处理，没有看出区别来吧

听说，把一个整数，比如 0xaabbccddUL，memcpy() 到一个四子节数组，就可以判断字节顺序了？
当然，直接按字节流抽取，也是一种方法。

geel

网络字节流有区别吧？要不utf8的bom还有什么意义呢

langue

比如我定义 a = (c[0] + c[1]<<8 + c[2]<<16 + c[3]<<24) & 0xffffffffUL，就不用担心了吧

醉卧水云间

原帖由 geel 于 2006-12-1 21:55 发表
网络字节流有区别吧？要不utf8的bom还有什么意义呢

utf8是不需要bom的，ucs-2需要。

geel

ucs只管编码，他才不管存储和传输

steedhorse

跨平台的文件格式，办法有好多，但实质上都不外乎两种：
（1）一切都通过字节来，不采用任何多字节类型。
（2）不管CPU如何，我文件中只用一种字节序，然后找开文件时通过字节序无关的操作恢复数据。

比如所有int按高位在前存储——这就要求，不管是读，还是写，都要通过位运算一步一步来，不能图省事，把整个int的4个字节一下子全写出去或者全读进来。

geel

那升64位就郁闷去吧，哈哈

langue

原帖由 geel 于 2006-12-2 09:45 发表
那升64位就郁闷去吧，哈哈

强制使用内部 32 位变量类型

[ 本帖最后由 langue 于 2006-12-2 11:54 编辑 ]

haiyan_qi

原帖由 flw2 于 2006-12-1 21:21 发表
namtso 说的就是我想说的。
文件就是字节流。1 2 3 4，想象一个sockfd,read(sockfd),write(2)对方open (file),write(sockfd) 你考虑了字节序吗？显然没有.不需要考虑是不是要把第4个字节放第一个字节的位置。

...

记得怎么指定连接的PORT吗？ htons(port)。

按你的说法，ntoh,hton这类函数都没用了。并不是所有的程序都是一位一位来读的。
我只是想知道tar程序是用什么方式，是一位一位来读的，还是用固定字节序存储的。