过渡到处理文本文件的应用程序的Unicode

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

在作出准备从2006年德尔福德尔福2009年过渡到Unicode的图形用户界面，我应该计划：

去完全支持Unicode我的应用程序中，与AnsiString类型文件I/O的例外呢？
将来自其他Unicode应用程序的处理ansistrings的代码封装起来（即继续将它们作为内部ansistrings处理）。

我意识到，一个真正的详细答复，将需要我的代码大量的 - 我只是问那些谁做了这种转变，谁仍然有纯文本文件的工作印象。在ansistrings和Unicode之间放置屏障的地方在哪里？

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

来源

2009-06-17 Argalatyr

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

来源

2009-06-17 04:13:55 mghie

非常好 - 你解释这个的方式有很大的帮助。根据我的理解，输入将确实是UTF-8文本文件（直接ASCII），现在我可以在内部使用UTF-8编码的Unicode字符串。 – Argalatyr 2009-06-17 04:32:35

在内部使用UTF-8编码的字符串并不是那么简单，所以我不建议将其作为策略。你会发现，一旦你开始使用Stringlists和更有用的VCL字符串函数，你需要的函数将不存在或使用它将涉及两个编码转换。 – frogb 2009-06-17 09:39:19

@frogb：的确，作为一项政策，这将是一个坏主意。这需要根据具体情况来决定。不知道代码是做什么的，但是不可能说出需要哪些VCL字符串函数，以及这会导致哪些编码转换。 – mghie 2009-06-17 10:27:50

我建议去完整的unicode，如果它是值得的努力和要求。保持ANSI文件I/O与其余部分分开。但是这取决于你的应用程序。

来源

2009-06-17 02:45:48 jitter

你说：

“的应用程序做字符串的对象一些相当沉重字符一个字符分析从从TList的后裔。”

由于Windows本地运行Unicode，因此如果将内部文本文件作为Unicode加载，则可能会发现您的字符分析运行速度更快。

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

想了解更多，请参阅扬Goyvaert的文章："Speed Benefits of Using the Native Win32 String Type"

所以这是你必须决定一个权衡。

来源

2009-06-17 04:26:51 lkessler

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

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

来源

2009-06-17 05:02:11

过渡到处理文本文件的应用程序的Unicode

回答

相关问题