处理文本文件的应用程序转换为 Unicode答案

【问题标题】：Transition to Unicode for an application that handles text files处理文本文件的应用程序转换为 Unicode
【发布时间】：2010-11-03 12:58:02
【问题描述】：

我的 Win32 Delphi 应用程序分析由不支持 Unicode 的其他应用程序生成的文本文件。因此，我的应用程序需要读取和写入 ansi 字符串，但我想通过在 GUI 中使用 Unicode 来提供更好的本地化用户体验。该应用程序对源自 TList 的对象中的字符串进行了一些非常繁重的逐字符分析。

在从 Delphi 2006 到 Delphi 2009 过渡到 Unicode GUI 时，我应该计划：

在我的应用程序中完全使用 Unicode，除了 ansistring 文件 I/O？
从其他 Unicode 应用程序封装处理 ansistrings 的代码（即继续在内部将它们作为 ansistrings 处理）。

我意识到真正详细的响应需要我的大量代码 - 我只是询问那些已经完成此转换并且仍然必须使用纯文本文件的人的印象。 ansistrings 和 Unicode 之间的障碍在哪里？

编辑：如果#1，对映射 Unicode 字符串以进行 ansistring 输出有什么建议吗？我猜想输入字符串的转换将使用 tstringlist.loadfromfile 自动进行（例如）。

【问题讨论】：

标签： delphi unicode delphi-2009 ansistring

【解决方案1】：

没有像 AnsiString 输出这样的东西 - 每个文本文件都有一个 character encoding。当您的文件包含 ASCII 范围之外的字符时，您必须考虑编码，因为即使在不同国家/地区加载这些文件也会产生不同的结果 - 除非您碰巧使用 Unicode 编码。

如果你加载一个文本文件，你需要知道它的编码。对于像 xml 或 html 这样的格式，信息是文本的一部分，对于 Unicode，有 BOM，尽管对于 UTF-8 编码的文件并不是绝对必要的。

将应用程序转换为 Delphi 2009 是一个思考文本文件编码和纠正过去错误的机会。应用程序的数据文件通常比应用程序本身具有更长的生命周期，因此考虑如何使它们具有前瞻性和通用性是值得的。我建议将 UTF-8 作为所有新应用程序的文本文件编码，这样将应用程序移植到不同的平台很容易。 UTF-8 是用于数据交换的最佳编码，对于 ASCII 或 ISO8859-1 范围内的字符，它创建的文件甚至比 UTF-16 或 UTF-32 小得多。

如果您的数据文件只包含 ASCII 字符，那么您就已经设置好了，因为它们也是有效的 UTF-8 编码文件。如果您的数据文件采用 ISO8859-1 编码（或任何其他固定编码），则在将它们加载到字符串列表并保存回来时使用匹配转换。如果您事先不知道他们将使用什么编码，请在加载时询问用户，或为默认编码提供应用程序设置。

在内部使用 Unicode 字符串。根据您需要处理的数据量，您可能会使用 UTF-8 编码的字符串。

【讨论】：

非常好 - 您解释这一点的方式有很大帮助。根据我的理解，输入确实是 UTF-8 文本文件（纯 ASCII），现在我可以在内部使用 UTF-8 编码的 Unicode 字符串。
在内部使用 UTF-8 编码的字符串并不是那么简单，所以我不建议将此作为策略。你会发现，一旦你开始使用Stringlists和更有用的VCL字符串函数，你需要的函数要么不存在，要么使用它会涉及到两次编码转换。
@frogb：确实，作为一项政策，这将是一个坏主意。这需要根据具体情况来决定。但是，如果不知道代码做了什么，就不可能说需要哪些 VCL 字符串函数，以及这会导致哪些编码转换。

【解决方案2】：

如果值得付出努力和要求，我建议使用完整的 unicode。并将 ANSI 文件 I/O 与其他文件分开。但这很大程度上取决于您的应用程序。

【讨论】：

【解决方案3】：

你说：

“该应用程序执行了一些相当繁重的任务逐字分析对象中的字符串 TList。”

由于 Windows 本身运行 Unicode，如果您在内部将文本文件加载为 Unicode，您可能会发现字符分析运行得更快。

另一方面，如果它是一个大文件，你也会发现它需要两倍的内存。

有关此的更多信息，请参阅 Jan Goyvaert 的文章："Speed Benefits of Using the Native Win32 String Type"

所以这是你必须做出的权衡。

【讨论】：

感谢您的链接。文本文件不是很大（一兆字节左右）。我是 JGSoft 程序的长期快乐注册用户，所以我非常感谢这个链接 - 我没有阅读 Jan 的博客文章。
您可能还会找到我之前发布的对您有用的问题的一些答案。请参阅以下方面的优秀答案：stackoverflow.com/questions/312118/…，包括 Jan 的答案。
如果输入仅包含 ASCII 字符，并且字符分析不使用任何包装 Windows API 的 RTL 函数（如链接文章中所述），而仅使用比较和诸如 Pos() 之类的东西UnicodeString 会比 AnsiString 慢。

【解决方案4】：

如果您要从 GUI 获取 Unicode 输入，将其转换为 ASCII 输出的策略是什么？（这是一个假设，因为您提到写回 Ansi 文本，假设对于这些基于非 Unicode 的应用程序，您不会重写并且假设没有源代码。）我建议在整个应用程序中使用 AnsiString直到这些其他应用程序启用 Unicode。如果您的应用程序的主要工作是分析非 Unicode ASCII 类型文件，那么为什么要在内部切换到 Unicode？如果您的应用程序的主要工作涉及拥有更好的支持 Unicode 的 GUI，那么请使用 Unicode。我不相信有足够的信息来决定一个正确的选择。

如果没有机会为这些非 Unicode 应用程序写回不易翻译的字符，那么建议使用 UTF-8 可能是可行的方法。但是，如果有机会，那么非 Unicode 应用程序将如何处理多字节字符？你将如何转换为（假设）基本的 ASCII 字符集？

【讨论】：

将文本输出限制为 UTF-8/ASCII 并不困难（如果我计划得当的话），因为它是从输入中派生的（在这方面，mghie 的答案特别适用）。 GUI 用于生成图形输出（以矢量格式保存 - 一个单独的问题）。感谢您的回答 - 警告语气对思考文本输出非常有帮助。