Question

先向文件中写入5个0xFF，再读取刚写的数据，将读取到的再次写到文件，文件却变成了3个0x3F, 数值变

，接上：个数也减半。请教这是为什么？
有个任务就是要不断在文件中将特定字节的0变成0xFF以作为该条记录是删除还是正常的标记。请问该如何解决这个问题？谢谢。

package testf;
import java.io.*;
public class DataStreamTest {
public static void main(String[] args) {
File file1 = new File("e:/testff.txt");
File file2 = new File("e:/testff.txt");
FileInputStream fis = null;
FileOutputStream fos = null;
DataInputStream dis = null;
DataOutputStream dos = null;
try {
fis = new FileInputStream(file1);
dis = new DataInputStream(fis);
int n = 0;
byte[] buff = new byte[1024];
String data = "";
int i = 0;
while((n=dis.read(buff))!=-1){
data += new String(buff,0,n);
}
fos = new FileOutputStream(file2);
dos = new DataOutputStream(fos);
dos.write(data.getBytes());
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
} finally {
try {
if(dis!=null)dis.close();
if(fis!=null)fis.close();
if(dis!=null)dis.close();
if(dos!=null)dos.close();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
data += new String(buff,0,n,"US-ASCII");

后来发现，将编码方式改成"US-ASCII"，结果是：之前是6个FF的，现在是6个3F。

Answer 1

File file1 = new File("e:/testff.txt");
File file2 = new File("e:/testff.txt");
这里是对同一个文件两个引用打开同时进行读写吗？如果是这样的话，是有问题的

追问

应该不是这个原因，如果file2指向一个新文件“E:/testff1.txt”，把从testff.txt中读到的数据写入新文件时，结果只显示一个3F。
谢谢。

追答

有个任务就是要不断在文件中将特定字节的0变成0xFF以作为该条记录是删除还是正常的标记

你这个应该是用的二进制文件吧，注意区分一下二进制文件和文本文件
如果还是不行，你把你那个生成源数据文件的程序贴出来看看

我看见你写入的时候好像是直接用的write(-1)这里-1不会是一个字节的吧

追问

这里write(-1)的方法是自动取低8位数据的，所以可以确定只写一个字节。
第一次就是用6个dos.write(-1)写入6个0xFF，第二次先读入刚写的6个0xFF，然后打开dos.write(data.getBytes())再次写入，结果变成3个或者更少，一个0x3F.
我下面做了个截图。thx。

http://hi.baidu.com/wuweizhu/blog/item/2ecb8002e47279104afb515c.html

追答

我发现代码的问题是这样的：
while((n=dis.read(buff))!=-1){
System.out.println(n); 这里读出来是6个byte，没问题

data = new String(buff,0,n);
System.out.println(data.length()); 这里打印出来这个String的长度是3，就是说读出来的是6个byte，在构造String的时候，丢失了。

你用
dos.write(buff, 0, n);
直接把读出来的n个buff写入，不要去构造String，这样我测试是OK的
最终while里面是这样的：
while((n=dis.read(buff))!=-1){
dos.write(buff, 0, n);
}

追问

你说的有道理。应该是构造的时候把两个字节当作一个字符来处理了吧。这样还面临一个问题，文本文件里可能有多个（百十个）记录是要标记为删除的。在读取数据出来修改之后，回写回去的时候，是不是就得分成很多段字符串与字节，分别写入呢。我也再试试。
我实际遇到的问题是，在标记第二个或者第三个删除标记时，另外一个或两个标记会自动变成0x3F，并且文件字节位置错位，导致后面读出的数据混乱了。

追答

这样的设计应该来说就是存在问题的，二进制（byte标记）和文本（记录的内容）混合使用，本来就潜在很大的隐患，因为写入一个byte的时候，如果这个byte是可以显示的，那就会成为一个文本。
因此，这里建议你要么都使用二进制方式，就是用二进制文件来存储你的数据，读出和写入都是使用二进制方式，其中有一位就是标记是否删除。
另外一种方式，就是标记是否删除也是使用文本，可以类似一行一个记录的纯文本文件，第一个字符标记是否删除（或者删除了的直接就从文件中删除了），比如：
0 xxx
1 yyy
……

追问

之前我也考虑修改设计，不用0xFF代表删除，用0x3F以内的任意一个整数都是可以的。目标用户应该是设定为只用US-ASCII编码的老美，新程序是要兼容人家之前的数据文本格式的。所以最好是继续用0xFF。
不知道从编码方式入手能不能解决。

追答

问题的根本就是在byte构建String的时候，产生的原因就是因为每个byte都是0xFF，而String判断内容是否是汉字（或者其他国家的需要双字节表示的文字）的时候就会用 byte & 0x80 进行判定，而0xFF是满足条件的，因此String会当成汉字来处理，汉字占用两个byte，因此6个byte最终转换成汉字变成了长度为3的String。而0xFFFF这样的汉字（或者其他国家的需要双字节表示的文字）是不存在的，当一个文字不存在的时候，会用'?'替换，而'?'的编码值就是0x3F。所以最后你看到的就是3个0x3F了。
无论你用什么样的编码，都是不可能解决这个问题的，因为0xFF或者0xFFFF都没有对应的文字，一旦用String去构造，就会出现上面所说的错误。
如果你希望继续用现有的设计（二进制和文本混合的方式），那么就直接用byte判断吧（或者其他不要转换为String对象的办法）。

追问

恩，的确该认真考虑换一个标记值。
原数据文件据说用的是8 bit US ASCII编码。用的应该就是按字节逐个读取。因为原来的就是很老旧的程序。人家也提到可以牺牲效率以换取兼容性。我回头再试试逐个读取吧。

追答

那就逐个byte判断了，去掉为0xFF特殊标记的byte，其他的就应该可以正常转换为String了。

Answer 2

可否给出原 :/testff.txt 的原始数据。
我用 0xFF0xFF0xFF0xFF0xFF 测试
生成的还是 0xFF0xFF0xFF0xFF0xFF

data += new String(buff,0,n,"US-ASCII");

也试过，结果一样的，没出现减半现象。

追问

:/testff.txt 就是一个新建的文件，写入5个0xFF.
...
// dos.write(data.getBytes());
dos.write(-1);
dos.write(-1);
dos.write(-1);
dos.write(-1);
dos.write(-1);
dos.write(-1);
...
先这样写了六个，文件当中是

再换成这样，
...
dos.write(data.getBytes());
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
// dos.write(-1);
...

追答

你的方法挺怪的。

dos.write(-1);
dos.write(-1);
dos.write(-1);
dos.write(-1);
dos.write(-1);
dos.write(-1);

这样做完了以后，
还能保证文件中的内容与原来一样吗？

你用这个方法生成的文件，又 dos.write(data.getBytes());

为什么还希望文件的内容与最初的相同呢？

你的目的是什么？

追问

先写6个0xFF是为了证明他后面有数据减半的情况发生呀。读入再回写时，肯定要把这六个注释掉呀。哥哥。目的是为了让新程序能够兼容目标客户的US-ASCII编码方式的数据文件。假设人家之前的数据都是用0xFF代表删除。你能做出来他就买，做不出来就不买。问这个钱要不要赚。这就是目的。哈哈。
谢谢。

追答

明白你的意思了，也看了你和上边的问答
我这里不会出现减半的现象。

现在真不知道具体问题出在哪里。

Answer 3

文件的打开方式不应该是文本的，而应该是二进制的。

追问

谢谢。能指明下该用哪个方法吗？