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

Question

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

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

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

我意识到真正详细的回复需要大量的代码 - 我只是询问那些进行过这种转换并仍然需要使用纯文本文件的人的印象。在ansistrings和Unicode之间放置屏障的位置？

编辑：如果＃1，为ansistring输出映射Unicode字符串的任何建议？我猜想输入字符串的转换将使用tstringlist.loadfromfile自动转换（例如）。

Answer 1

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

Answer 2

没有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编码的字符串。

Answer 3

你说：

  

“该应用程序确实很重   逐字符分析   来自的对象中的字符串   从TList。“

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

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

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

所以这是你需要做出的权衡。

Answer 4

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

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