linux读2进制的文件出现问题,windows没问题.

Question

本帖最后由 chichenzhe 于 2010-10-09 16:04:03 编辑

Answer 1

文件是以byte流的方式写入,非文本文件.

Answer 2

两个系统下的文件行结束，文件结束符有区别造成的？
你的这个文件，应该可以按行读取会更方便一些，不要使用二进制的形式。
可以使用
BufferedReader reader = new BufferedReader(new FileReader(new File(..));
String line;
while ((line = reader.readLine()) != null) {
      handle(line);
}

Answer 3

谢谢 3楼回复.
问题是我 这个东西 并非文本文件. 没有所谓行的概念.写进去的都是按byte写的. 
每个byte都有特殊的含义. 不是常规意义的 aaa.txt 这样简单的文件.  而且. 我这个2进制文件根本就不会掺杂换行符.
如果我要写一个字符串进去的话,我会 先把字符串化为byte数组,然后 取len, 然后再存储len以及byte[]  读的时候也是这样依据订立好的 文件读写 协议进行读写.

Answer 4

比如 我要创建  byte,byte,byte,int,byte,string,byte 这样的一个格式的文件.
可能其含义只是:
1,120,3,1,3000,5,"abcde",99 这些各值我要写进一个后缀为 .xxx的文件里. (其实后缀不代表什么,这个大家都明白)
然后我下一个程序B会在某台服务器上读取这个 .xxx 的文件. 逐个 FileInputStream.read 出来.
然后赋给我需要变量.现在问题是:
windows上程序B很正常.
linux上程序B在读取部分文件的时候就不正常了

Answer 5

你不清楚 我的写入协议规范 怎么读呢.比如我按这一个格式写入:  byte,byte,byte,int而你读的时候按其他格式读的话 你的程序就会报错.

Answer 6

回9L.Exception贴出来真的煤油什么意义.凡是Exception能够查出来的问题还需要贴在这吗. 我举个简单例子:
java.lang.NullPointerException这个你以为就是对象为空 这么简单吗? 很有可能问题只出在 一个数值上面,后面代码运行的时候因为数值问题从而导致给某对象赋值为NULL,而后面 又使用了这个为NULL成员的变量而导致java.lang.NullPointerException.你说这么个问题,我贴exception给你有意义吗?
FileInputStream.read 上面并未产生异常.而我会把FileInputStream.read的值赋给一些对象的成员.  在linux下, FileInputStream.read获得的值是错的. 从而导致 我的这个对象发生诸如数组索引越界 等等系列问题.这个问题我单贴exception没有任何意义,可能你看了exception会说这就是个 数组索引越界问题.
可是你又是否明白为什么windows下为什么不越界呢?  难道 win32和 linux的数据类型都不同吗?朋友,简单问题确实可以看exception. 但是这样的问题我是羞于在这提问的.

Answer 7

你这样讲下。是不知道问题到底出在何处的
可以参考3楼的。用BufferedReader读取应该不会有问题

Answer 8

没有换行符,哪来的reader.readLine().注意审题.

Answer 9

要我用 reader.readLine() 方式读文件的朋友 先请仔细看懂我6楼的回复. 谢谢

Answer 10

movePathNodeNums 是啥意思，你做的什么操作，这个该告诉我们吧，不然我们怎么知道异同在哪里

Answer 11

movePathNodeNums=0 带表怪物行走路线为0.
这这个数据上 等于0是合理的.因为这个地图没有怪物.movePathNodeNums=3 不解释了.
这个错了,因为没有怪物. 所有后面判断 movePathNodeNums > 0 就要进行for循环了. 循环的时候必然报错.因为这个地图上没有所谓的怪物.但前提问题是:linux为什么会读出3这个值
而windows为什么读的是正常值 0 .

Answer 12

movePathNodeNums=3 检查这个读取出来的byte是否有多余的字符。PS:楼主你不给代码让我们测试，咱们只能说，这样能找到问题的解答吗。楼主如果真的想获得答案，还是建议你把部分测试代码贴出来吧。

Answer 13

多余的字符 windows 系统读不出来? 只有linux能读出来?
代码上解析地图的方法 五六百行代码,没有所谓的关键代码.
按伪码来解释的话也不过就是 实例化FileInputStream对象.
然后从FileInputStream对象里1个byte 1个byte的把值取出来而已.就分析问题而言我需要把6百多行全贴出来才可以达到所谓贴关键代码的目的.但这可能吗,我贴出来有意义吗,论坛可以允许我发600行代码吗, 即便万幸,我发出来了.  这位大哥你又有这个闲心去读吗?这是一个系统级别问题,我就想问问有没碰过这样跨平台问题的人.
windows正常. linux异常.
==================================
再补充一点:
后来我又验证了一下是否我猜测是对的. (java跨平台问题)我把当初生成这个地图文件的程序A 也部署到linux上. 让这个程序去加载自己生成的地图...  结果很符合我想象:果然也读不出来.
也就是说. 我在windows上完全没问题的程序移植到linux上就出了这个问题. 

Answer 14

可以看出来你应该是个JAVA高手，如果你都无法解决，我也无能为力了。
如果你完全确定不是自己代码或者读取方式上面的问题（建议你别这么自信），也许你真的碰到JDK的BUG了，多写几个测试代码，用排除发来推测问题所在，证实你的推测，如果果真是你的猜想正确，建议你去google去搜索下国外的资料看看有人是否解决了这个问题。
本人技术有限，没有遇到过，不能解答你的问题。只能提点建议，抱歉。

Answer 15

你用A程序在Windows上和Linux上生成相同的地图，然后用BeyondCompare之类的工具比较下生成的地图二进制文件， 看看哪里有不同。（或者再写个工具把文件2进制数转换成 0xXX的格式，作为文本比较）
基本上，你应该能找出是哪个属性写入的时候，在Windows和Linux上不同
如果是特定的一两个属性总是出错的话，检查一下这些属性的序列化部分的代码。
既然你说是自己一个字节一个字节的编码的，所以不应该是JDK序列化导致的问题。
另外，查查是不是字节序的问题，这个比较一下很快就能发现。
还有就是，确定你的编解码方案和JDK版本无关。
比较常犯的错误是，因为大量的手工编码，在处理数据的时候，编码和解码的属性顺序不匹配。简单的读写，Java不会出现跨平台的问题的，通常都是自己代码的问题。我们也碰到过，有时很诡异的问题，一直以为是平台出了问题，最后都发现是自己代码导致的。 

Answer 16

感谢回复,windows和linux的字节序应该是相同的,都是Little Endian的系统
不过我可以查查是不是 这个问题.编码和解码的顺序不同的话 windows 不出问题比较奇怪.我也查查吧.

Answer 17

在java api中有写到：FileInputStream 从文件系统中的某个文件中获得输入字节。哪些文件可用取决于主机环境；文件输出流是用于将数据写入 File 或 FileDescriptor 的输出流。文件是否可用或能否可以被创建取决于基础平台。特别是某些平台一次只允许一个 FileOutputStream（或其他文件写入对象）打开文件进行写入。在这种情况下，如果所涉及的文件已经打开，则此类中的构造方法将失败。因此，我认为你输出结果不同是很正常的，这个是系统的底层问题，不太好解决。我认为可以这样处理一下： 文件在哪个系统上创建，就在哪个系统上读取，如果一定要到某个系统上去读取，那就将那个文件放到某个系统上去创建。

Answer 18

这个不现实,我们只是遵照JAVA基本特性来 使用: 一处编译,处处运行.
某地方生成好文件, FTP放到linux上 运行.另外我查了下纠正下21楼观点, 字节序和系统无关,和CPU有关. 但我LINUX服务器用的是常规CPU也是Little Endian的.

Answer 19

应该是大小端的问题，我记得没错的话，java的流默认是以大端读的。还是改用filechannel加ByteBuffer试试吧。