我终于升级到了Delphi XE。我有一个单元库，我使用字符串来存储普通的ANSI字符（A和U之间的字符）。我101％肯定我永远不会在那些地方使用UNICODE字符。
我想将所有其他库转换为Unicode，但对于这个特定的库，我认为坚持使用ANSI会更好。优点是内存要求，因为在某些情况下我加载了非常大的TXT文件（仅包含Ansi字符）。缺点可能是当我使这些库与普通（unicode）库交互时，我必须做很多很多的类型转换。
有一些通用指南可以说明什么时候可以转换为Unicode以及何时坚持使用Ansi？
答案 0 :(得分：11)
一般指导方针的问题在于，这样的事情可能非常特定于某人的情况。你的例子就是其中之一。
然而，对于谷歌搜索和到达这里的人来说，一些一般性的指导方针是：
是的，转换为Unicode。不要试图使用AnsiString完全保留旧应用程序。原因是整个VCL都是Unicode，你不应该试图将两者混合，因为每次将Unicode字符串分配给ANSI字符串时都会进行转换，这是一种有损转换。试图保持旧的方式，因为它的工作量较少（或类似的原因）将导致你的痛苦;只需拥抱新的string类型，转换并使用它。
而不是随机混合两者，显式执行您需要的任何转换，例如，如果您从程序的旧版本加载数据，您知道它将是ANSI，那么请将其读入那里有一个Unicode字符串，就是这样。从那以后，它将是Unicode。
您不需要更改string变量的类型 - string前D2009是ANSI，而在D2009中，alter是Unicode。相反，请关注compiler warnings并观察您使用的字符串方法 - 有些仍采用AnsiString参数，我发现这一切都令人困惑。编译器会告诉你。
如果使用字符串来保存字节（换句话说，将它们用作字节数组，因为字符是一个字节），请切换到TBytes。
您可能会遇到加密等问题的特定问题（字符串不再是字节/字符，因此'字符'的'字符'可能会得到不同的输出）;读取文本文件（使用流类和TEncoding）;而且，坦率地说，杂项。在这里搜索，之前已经提出了大部分事情。
评论者，请添加更多建议......我主要使用的是C ++ Builder，而不是Delphi，对于Delphi，我可能还有不少具体的东西我不知道。
现在针对您的具体问题：您应该转换此库吗？
如果：
然后不转换为Unicode，而是将string切换为AnsiString，这是有道理的。
请注意：
UTF8String，这是AnsiString的特定类型，在转换时不会有损，并且仍会将大多数文本（罗马字符）存储在一个字节中string的所有实例更改为AnsiString可能有点工作，您需要检查所有使用它们调用的方法，以查看是否执行了太多的隐式转换（对于表演）等。if 'S' in MySet？）won't work。从你对字符A到U的描述，我猜你想使用这种语法。我的推荐？就个人而言，我从你提供的信息中做到这一点的唯一原因就是内存的使用，以及可能的性能取决于你对这么多的{ {1}}秒。 如果真的很重要，它既是驱动程序又是约束，你应该转换为ANSI。
答案 1 :(得分：4)
您应该能够在本机与其客户端之间的接口处完成转换。在内部使用AnsiString，在其他地方使用字符串，你应该没问题。
答案 2 :(得分：3)
一般情况下，如果Chars是单个字节很重要，则只使用AnsiString，否则使用string确保将来与Unicode兼容。
答案 3 :(得分：0)
你需要检查所有的库，因为Delphi XE中的所有Windows API函数都被它们的unicode类似物等取代。如果你永远不会使用UNICODE，你需要使用Delphi 7。
答案 4 :(得分：0)
在本机的任何地方显式使用AnsiString，如果你碰巧错误地访问例程，你会得到编译器警告错误（你永远不应该忽略），因为String到AnsiString转换错误。
或者，也许最好根据您的情况，只需将所有内容转换为UTF8。
答案 5 :(得分：0)
如果您没有时间正确转换代码，请坚持使用Ansi字符串。使用Ansi字符串实际上只是为了向后兼容 - 据我所知，C＃没有与Ansi字符串相等的。否则使用标准Unicode字符串。如果您查看我的网站，我有一个完整的字符串例程单元（大约5,000 LOC），它与Delphi 2007（非Uniocde）和XE（Unicode）一起使用，只有“字符串”接口，几乎包含所有的您可能面临的转换问题。