验证 XML 文档会导致“1 字节 UTF-8 序列的字节 1 无效”。

Posted 2023-02-16

【中文标题】验证 XML 文档会导致“1 字节 UTF-8 序列的字节 1 无效”。

【英文标题】：Validating XML doc results in "Invalid byte 1 of 1-byte UTF-8 sequence."

【发布时间】：2012-11-22 08:34:09

【问题描述】：

我正在使用Probatron4j 验证一些针对Schematron 样式表的XML 文件，它在内部使用Saxon。大多数情况下，这工作正常，但偶尔，处理崩溃并出现错误

org.xml.sax.SAXParseException：1 字节 UTF-8 序列的字节 1 无效。

我的研究表明，此消息通常表明（无特定顺序）

明显无效的数据（例如，试图像读取 XML 文件一样读取 ZIP 文件）； byte order marks 的存在； 存在 UTF-8 中不合法的字符；或 声称是 UTF-8 编码的文档是在撒谎。

这些都不适用于我正在处理的文档。我在程序执行期间检查了字节数组形式的输入，它不包含 BOM 或任何非 ASCII 字符。

在我的 30kb 文档中处理了大约五分之一，然后在一个不起眼的英文句子上崩溃（通过“不起眼”，我的意思是所有字节都在 32（空格）和 122（小写 z）之间；换句话说，标准键盘字符）。所谓的违规元素的字节在这篇文章的末尾。

奇怪的是，失败的文档是通过从由相同代码干净处理的较大文档中删除一些元素生成的。

我知道在实现org.xml.saxXMLReader 接口的对象的parse(InputSource input) 方法中引发了异常。根据the Javadoc，SAXException表示

任何 SAX 异常，可能包含另一个异常。

在调试器中检查异常表明没有包装异常。

什么可能导致这个错误？

编辑：

[60, 80, 97, 114, 97, 103, 114, 97, 112, 104, 62, 69, 120, 101, 99, 117, 116,
 105, 118, 101, 32, 83, 117, 109, 109, 97, 114, 121, 58, 32, 70, 114, 111, 109,
 32, 49, 55, 53, 52, 32, 116, 111, 32, 49, 55, 54, 51, 13, 10, 32, 32, 32, 32,
 32, 32, 32, 32, 32, 32, 32, 32, 69, 117, 114, 111, 112, 101, 32, 97, 110, 100,
 32, 116, 104, 101, 32, 65, 109, 101, 114, 105, 99, 97, 115, 32, 119, 101, 114,
 101, 32, 99, 97, 117, 103, 104, 116, 32, 117, 112, 32, 105, 110, 32, 97, 32, 99,
 111, 110, 102, 108, 105, 99, 116, 32, 98, 101, 116, 119, 101, 101, 110, 32, 69,
 110, 103, 108, 97, 110, 100, 44, 32, 117, 110, 100, 101, 114, 32, 75, 105, 110,
 103, 32, 71, 101, 111, 114, 103, 101, 32, 73, 73, 44, 32, 97, 110, 100, 32, 70,
 114, 97, 110, 99, 101, 44, 32, 117, 110, 100, 101, 114, 32, 75, 105, 110, 103,
 32, 76, 111, 117, 105, 115, 32, 88, 86, 46, 32, 73, 110, 32, 69, 117, 114, 111,
 112, 101, 13, 10, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 116, 104, 105,
 115, 32, 112, 101, 114, 105, 111, 100, 32, 119, 97, 115, 32, 107, 110, 111, 119,
 110, 32, 97, 115, 32, 116, 104, 101, 32, 83, 101, 118, 101, 110, 32, 89, 101,
 97, 114, 115, 39, 32, 87, 97, 114, 59, 32, 105, 110, 32, 78, 111, 114, 116, 104,
 32, 65, 109, 101, 114, 105, 99, 97, 32, 105, 116, 32, 99, 97, 109, 101, 32, 116,
 111, 32, 98, 101, 32, 99, 97, 108, 108, 101, 100, 32, 116, 104, 101, 32, 70,
 114, 101, 110, 99, 104, 32, 97, 110, 100, 32, 73, 110, 100, 105, 97, 110, 32,
 87, 97, 114, 46, 32, 73, 116, 32, 119, 97, 115, 32, 97, 32, 99, 111, 110, 102,
 108, 105, 99, 116, 32, 111, 118, 101, 114, 13, 10, 32, 32, 32, 32, 32, 32, 32,
 32, 32, 32, 32, 32, 116, 114, 97, 100, 101, 32, 97, 110, 100, 32, 108, 97, 110,
 100, 46, 60, 47, 80, 97, 114, 97, 103, 114, 97, 112, 104, 62]

109 第三次出现后抛出异常。

【问题讨论】：

您是否可以将该字节数组的内容编辑到您的帖子中？

只是最里面标签之间的部分，例如...<iamatag>This is where it crashes</iamatag>...

你知道它在这个数组中哪个字符上引发了异常吗？

【参考方案1】：

我已经解决了这个问题。即使 Java 在内部对其 String 对象使用 UTF-8，String 类的 getBytes() 方法也会以系统的默认编码生成字节，除非您明确指定您需要 UTF-8（或它所指定的其他编码方案）明白）。

我不完全确定这是如何或为什么解决问题的，因为抛出异常的位置附近的字节（问题末尾的字节）本身都是有效的 UTF-8 字节，但是它似乎确实有固定的东西。

我能想到的唯一可能的原因是我在文件的前面错过了一个无效字节，这把事情搞砸了，但没有导致立即崩溃。我正在从ByteArrayInputStream 读取字节，因此程序可能会同时从缓冲区中读取一大块，这会将pos 标记设置到假设坏字符所在位置之外的位置。

【参考方案2】：

在等待您的字节数组时，我做了一点谷歌搜索。

你说

奇怪的是，失败的文档是通过从由相同代码干净处理的较大文档中删除一些元素生成的。

From that, I suspect the problem in this thread is probably your problem

【讨论】：

啊，是的，我早些时候遇到过这个问题（虽然不是那个确切的 SO 帖子）。我的输入源由ByteArrayInputStream 支持，而不是Reader，所以不是这样，但它是一个好镜头。