分类读入、解析XML
程序员文章站
2022-03-01 17:54:14
...
在最近的一个项目,经常需要读取XML进行预处理,将处理后内容写入中间文件(xml),
现在出现的一个问题是,某些中间文件,在JDOM载入进行build时,报出如下错误:
打开此文件,发现其第一行内容为:
查看原文件,开头含有两字节FF FE;对比其他文件并不含。
此处需要插入BOM头的内容:
请参考:谈谈Unicode编码,简要解释UCS、UTF、BMP、BOM等名词
现在发现就是出错文件含有BOM头,而在读取时并没有使用相应encoding,
BufferedReader br = new BufferedReader(new FileReader(oldFile));
这样读取使用的话,应该是使用的eclipse默认编码(与当前Java文件编码相同?),还没想明白。
解决办法如下:
而在写入时,使用代码
这是没有问题的,前面出现问题是因为使用了错误的编码读取了6个错误字节而在写入前已经出现错误。
还有些东西、点没想通,再补充。
现在出现的一个问题是,某些中间文件,在JDOM载入进行build时,报出如下错误:
Error: Error on line 1 of document file:/C:/eclipse/workspace/Cmd/deleteme1.xml: Content is not allowed in prolog.
打开此文件,发现其第一行内容为:
<?xml version="1.0" encoding="UTF-8"?>通过UltraEdit查看其16进制,发现前面3个字符(6个字节)为: C3 AF C2 BB C2 BF;
查看原文件,开头含有两字节FF FE;对比其他文件并不含。
此处需要插入BOM头的内容:
引用
UTF的字节序和BOM
UTF -8以字节为编码单元,没有字节序的问题。UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的字节序。例如 “
奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是“奎”还是 “乙”?
Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表,而是Byte Order Mark。BOM是一个有点小聪明的想
法:
在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传
输中。UCS规范建议我们在传输字节流前,先传输字符"ZERO WIDTH NO-BREAK SPACE"。
这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH
NO-BREAK SPACE"又被称作BOM。
UTF -8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是 EF BB BF(读者可以
用我们前面介绍的编码方法验证一下)。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。
UTF -8以字节为编码单元,没有字节序的问题。UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的字节序。例如 “
奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是“奎”还是 “乙”?
Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表,而是Byte Order Mark。BOM是一个有点小聪明的想
法:
在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传
输中。UCS规范建议我们在传输字节流前,先传输字符"ZERO WIDTH NO-BREAK SPACE"。
这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH
NO-BREAK SPACE"又被称作BOM。
UTF -8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是 EF BB BF(读者可以
用我们前面介绍的编码方法验证一下)。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。
请参考:谈谈Unicode编码,简要解释UCS、UTF、BMP、BOM等名词
现在发现就是出错文件含有BOM头,而在读取时并没有使用相应encoding,
BufferedReader br = new BufferedReader(new FileReader(oldFile));
这样读取使用的话,应该是使用的eclipse默认编码(与当前Java文件编码相同?),还没想明白。
解决办法如下:
BufferedReader br = new BufferedReader(new FileReader(oldFile)); br.mark(10); int b1,b2,b3; String readEncoding = defaultReadEncoding; b1 = br.read(); b2 = br.read(); b3 = br.read(); if(b1==0xef && b2==0xbb && b3==0xbf){ readEncoding = "UTF8"; }else if(b1== 0xfe && b2==0xff){ readEncoding = "UnicodeBig"; }else if(b1== 0xff && b2==0xfe){ readEncoding = "UnicodeLittle"; } if(readEncoding==null){ br.reset(); }else{ br.close(); FileInputStream fis = new FileInputStream(oldFile); InputStreamReader isr = new InputStreamReader(fis, readEncoding); br = new BufferedReader(isr); }
而在写入时,使用代码
FileOutputStream fos = new FileOutputStream(newFile); BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(fos, "UTF8"));
这是没有问题的,前面出现问题是因为使用了错误的编码读取了6个错误字节而在写入前已经出现错误。
还有些东西、点没想通,再补充。