这是“没问题太愚蠢”的部门：
嗯，正如主题所说：有影响吗？如果是这样，多少钱？我的代码和DFM资源中的所有字符串文字现在占用了编译二进制文件中的两倍空间吗？如何编译应用程序的运行时内存使用？现在所有的字符串变量都会占用两倍的RAM吗？我应该打扰吗？
我记得在早期发布的早期网络广播中有人问这个问题，但我记不起答案了。由于试用期只有14天，我不会在我需要的第三方图书馆更新之前自己尝试一下（假设大约一个月）。
答案 0 :(得分：1)
D2009使用UTF-16作为默认字符串类型，但如果需要，可以使用UTF-8变量。
Jan Goyvaerts discusses the size/speed tradeoff在一篇好文章中。
DFM中的字符串文字至少是D7，因此是UTF-8。因此，由于DMC9的DFM中的字符串，不会增加大小。
答案 1 :(得分：0)
我现在终于掌握了Delphi 2009，在进行了必要的调整后，我的项目现在编译并运行得很好。 ：）
为了快速获得结果，我最初不得不评论一个稍微复杂一点的应用程序模块，因此它不是100％可比较但是它已经足够安全地预测尽管我们的源代码中有大量的字符串文字（过多调试日志消息）使用Delphi 2009编译的二进制文件的大小可能与以前大致相同 - 如果不是真的更少！
我想知道，Delphi编译器是否实际上以任何方式对二进制文件或至少其资源部分执行任何类型的压缩？我真的希望改变UTF-16字符串文字在这个特定的应用程序中产生更大的影响。文字是否真的存储为（未压缩的）UTF-16在二进制文件中？
我还没有时间研究内存占用的差异。
编辑：不直接与Unicode相关，但绝对相关：Andreas Hausladen最近发布了一篇关于{$STRINGCHECKS}编译器选项（重大）影响的有趣信息（BTW：默认打开） ）编译后的可执行文件大小：http://andy.jgknet.de/blog/?p=487
答案 2 :(得分：-1)
我已经等了很多年的Unicode VCL了，最后我们看到了。我不认为大多数应用程序需要担心大小问题，因为他们无论如何都没有那么多字符串文字或者在内存中存储大量数据。
可用性问题更加重要，以尽可能证明Unicode的使用。
如果某个开发人员想要创建一个小的exes，他们可以使用AnsiString进行手动优化（如果i18n不是问题）。
答案 3 :(得分：-2)
我多年没有使用Delphi，但可能取决于他们使用的Unicode编码。对于常规ASCII字符集，UTF8将完全相同（当您进入异国情调的字符时，它只使用多个字节）。 UTF16可能有点臃肿。