我的 Win32 Delphi 应用程序分析由不支持 Unicode 的其他应用程序生成的文本文件。因此，我的应用程序需要读取和写入 ansi 字符串，但我想通过在 GUI 中使用 Unicode 来提供更好的本地化用户体验。该应用程序对源自 TList 的对象中的字符串进行了一些非常繁重的逐字符分析。
在从 Delphi 2006 到 Delphi 2009 过渡到 Unicode GUI 时，我应该计划：
我意识到真正详细的响应需要我的大量代码 - 我只是询问那些已经完成此转换并且仍然必须使用纯文本文件的人的印象。ansistrings 和 Unicode 之间的障碍在哪里？
编辑：如果#1，有什么建议可以为 ansistring 输出映射 Unicode 字符串？我猜想输入字符串的转换将使用 tstringlist.loadfromfile 自动进行（例如）。
如果值得付出努力和要求，我建议使用完整的 unicode。并将 ANSI 文件 I/O 与其他文件分开。但这在很大程度上取决于您的应用程序。
没有 AnsiString 输出之类的东西 - 每个文本文件都有一个字符编码。当您的文件包含 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 编码的字符串。
你说：
“该应用程序对源自 TList 的对象中的字符串进行了一些非常繁重的逐字符分析。”
由于 Windows 本机运行 Unicode，如果您在内部将文本文件加载为 Unicode，您可能会发现字符分析运行得更快。
另一方面，如果它是一个大文件，你也会发现它需要两倍的内存。
有关这方面的更多信息，请参阅 Jan Goyvaert 的文章：“使用本机 Win32 字符串类型的速度优势”
所以这是一个你必须决定的权衡。
如果您要从 GUI 获取 Unicode 输入，将其转换为 ASCII 输出的策略是什么？（这是一个假设，因为您提到写回 Ansi 文本，假设您不会重写这些基于非 Unicode 的应用程序，并且假设没有源代码。）我建议在整个应用程序中使用 AnsiString直到这些其他应用程序启用 Unicode。如果您的应用程序的主要工作是分析非 Unicode ASCII 类型文件，那么为什么要在内部切换到 Unicode？如果您的应用程序的主要工作涉及拥有更好的支持 Unicode 的 GUI，那么请使用 Unicode。我不相信有足够的信息来决定一个正确的选择。
如果没有机会为这些非 Unicode 应用程序写回不易翻译的字符，那么建议使用 UTF-8 可能是可行的方法。但是，如果有机会，那么非 Unicode 应用程序将如何处理多字节字符？你将如何转换为（假设）基本的 ASCII 字符集？