2

（免责声明：我在询问之前查看了这里的一些帖子，我发现这个特别有帮助，如果可能的话，我只是在寻找你们的一些理智检查）

大家好，

我有一个内部 Java 产品，用于处理加载到数据库中的数据文件（又名 ETL 工具）。我为 XSLT 转换准备了阶段，并在原始文件中进行了模式替换等操作。输入文件可以是任何格式，它们可以是平面数据文件或 XML 数据文件，您可以配置加载特定数据馈送所需的阶段。

到目前为止，我一直忽略文件编码的问题（我知道这是一个错误），因为一切正常（主要）。但是，我现在遇到了文件编码问题，长话短说，由于阶段可以一起配置的方式的性质，我需要检测输入文件的文件编码并创建一个 Java Reader 对象适当的论据。在我深入研究我无法声称完全理解的事情之前，我只是想和你们一起做一个快速的理智检查：

  1. 对从我的工具包中每个阶段输出的所有文件采用 UTF-16 的标准文件编码（我不排除将来加载双字节字符）
  2. 使用JUniversalChardet或jchardet嗅探输入文件编码
  3. 使用 Apache Commons IO 库为所有阶段创建标准读取器和写入器（我是否认为这没有类似的编码嗅探 API？）

您在我概述的方法中看到任何陷阱/有任何额外的智慧吗？

有什么方法可以保证与使用我现有的让 Java 运行时决定 windows-1252 编码的方法加载的任何数据的向后兼容性？

提前致谢，

-詹姆士

4

2 回答 2

2

对于平面字符数据文件，任何编码检测都需要依赖统计数据和启发式方法（例如BOM的存在，或字符/模式频率），因为在不止一种编码中存在合法的字节序列，但映射到不同的编码人物。

XML编码检测应该更直接，但肯定有可能创建模糊编码的 XML（例如，通过省略标头中的编码）。

使用编码检测 API 向用户指示错误概率而不是依赖他们作为决策者可能更有意义。

当您在 Java 中将数据从bytes 转换为s 时，您正在从编码 X转码为 UTF-16(BE)。发送到数据库的内容取决于您的数据库、其 JDBC 驱动程序以及您如何配置该列。这可能涉及从 UTF-16 转码为其他内容。假设您没有更改数据库，现有的字符数据应该是安全的；如果您打算解析 BLOB，您可能会遇到问题。如果您已经解析了以不同编码编写的文件，但将它们视为另一种编码，则损坏已经发生 - 没有解决此问题的灵丹妙药。如果您需要将数据库的字符集从“ANSI”更改为 Unicode，那可能会很痛苦。char

Adoption of Unicode wherever possible is a good idea. It may not be possible, but prefer file formats where you can make encoding unambiguous - things like XML (which makes it easy) or JSON (which mandates UTF-8).

于 2010-02-02T17:55:41.817 回答
1

选项 1 让我印象深刻，因为它破坏了向后兼容性（当然从长远来看），尽管“正确的方式”（正确的方式选项通常会破坏向后兼容性）可能还有关于 UTF-8 是否是一个好的选择的额外想法。

如果你有一组有限的、已知的编码，你测试知道你的嗅探器正确区分和识别，那么嗅探编码是合理的。

这里的另一个选项是使用某种形式的元数据（文件命名约定，如果没有其他更强大的选项），让您的代码知道数据是根据 UTF-16 标准提供的并相应地表现，否则将其转换为前进之前的 UTF-16 标准。

于 2010-02-02T17:01:21.737 回答