Java 文件解析工具包设计，快速文件编码完整性检查

Question

(免责声明:我在询问之前查看了此处的许多帖子，我发现 this one 特别有帮助，如果可能的话，我只是想从你们那里寻求一些理智检查)

大家好，

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

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

对于从我的工具包中每个阶段输出的所有文件，采用 UTF-16 的标准文件编码(我不排除将来加载双字节字符)

使用 JUniversalChardet或 jchardet嗅探输入文件编码

使用 Apache Commons IO 库为所有阶段创建一个标准的读取器和写入器(我认为这没有类似的编码嗅探 API 是对的吗？)

在我概述的方法中，您是否看到任何陷阱/有任何额外的智慧可以提供？

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

提前致谢，

-詹姆士

Answer 1

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

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

这里的另一个选择是使用某种形式的元数据(文件命名约定，如果没有其他更强大的选项)，让您的代码知道数据是根据 UTF-16 标准提供的并相应地进行操作，否则将其转换为UTF-16 标准，然后再继续。