支持以BOM开头的UTF-8 XML

Question

能够解析以BOM字节顺序标记符开头的UTF-8编码文件将是一件好事，因为它将更好地支持野生的XML。

目前，我遇到了几个这些XML文件会抛出“在处理文件头不支持的“内容””异常
http://stackoverflow.com/questions/4569123/content-is-not-allowed-in-prolog-saxparserexception

Answer 1

评论者：bendlas

根据您提供的Stack Overflow链接，这似乎与几个已标记为不会修复的Java漏洞有关，因为这些漏洞是由于期望现有工具和推荐在缺陷报告中自行处理BOM。

由于data.xml承诺从原始字节处理XML（因为它接受InputStream），所以有一个选择：或者不再使用InputStream接口，并要求用户传递正确处理其输入的Readers（例如，https://commons.apache.org/proper/commons-io/javadocs/api-2.2/org/apache/commons/io/input/XmlStreamReader.html），或者在创建输入源时使用可执行此操作的Reader实现。

由于易于维护，我们倾向于去掉基于字节的处理接口，但我也愿意听取为什么data.xml应该处理此问题的论点。

Answer 2

评论者：featheredtoast

这更多是一个建议——在阅读关于输入和输入流的相关内容后，我可以理解为什么这可能在范围之外。

我曾经天真地以为，通过 clojure.java.io/reader 处理输入能够正确解析 XML 文件，因为我直到遇到异常之前都不知道有 BOM (字节顺序标记) 问题。即使 JVM 对 BOM 的相关修复会破坏向后兼容性，因此被拒绝，但如果底层的解析库可以处理输入和 BOM，那就仍然很有帮助。

至少可以为不熟悉 Java XML 解析的开发人员添加一个推荐阅读器列表。对于像我这样的对 BOM、阅读器和 XML 不太了解的开发人员来说，很难预料到这些陷阱，尤其是在其他语言中相同的文件能够通过验证。

Answer 3

评论者：bendlas

我只是在留在这里，这可能是当在文档化/更改此内容时一个好提及，以下链接：https://github.com/jimpil/clj-bom

Answer 4

参考资料：https://clojure.atlassian.net/browse/DXML-45 (由 alex+import 报告)