这是"毫无疑问的太愚蠢"部门的一个：

好吧，正如受试者所说：有影响吗？如果是这样，多少钱？现在，我在代码和DFM资源中拥有的​​所有字符串文字会占用编译后的二进制文件中两倍的空间吗？编译后的应用程序的运行时内存使用情况如何？现在所有的字符串变量都将占用两倍的RAM吗？我还要打扰吗？

我记得在早期的预发布网络广播中有人问过类似的问题，但我不记得答案了。而且由于试用只有14天，因此我不会在需要更新的第三方库(大概在一个月之内)之前自己尝试一下。

解决方案

回答

我已经好几年没有使用Delphi了，但这可能取决于他们使用什么Unicode编码。 UTF8与常规ASCII字符集完全相同(进入异类字符时，它仅使用一个以上的字节)。 UTF16可能有点肿。

回答

尽管我们可以根据需要将变量设置为UTF-8，但D2009使用默认字符串类型为UTF-16.

Jan Goyvaerts在一篇不错的博客文章中讨论了尺寸/速度的权衡。

至少从D7开始，DFM中的字符串文字一直是UTF-8. 因此，D2009中带有DFM的字符串不会增加大小。

回答

我一直在等待Unicode VCL多年，终于看到了。我认为大多数应用程序不必担心大小问题，因为它们无论如何都没有那么多的字符串文字或者在内存中存储大量数据。

可用性问题更受重视，以尽可能证明使用Unicode是合理的。

如果某些开发人员想要创建一个微小的exe，则可以使用AnsiString进行手动优化(如果i18n不是问题)。

回答

现在，我终于接触到了Delphi 2009，并进行了必要的调整后，我的项目现在可以编译并正常运行了。 :)

为了快速获得结果，我最初不得不注释掉该应用程序的一个稍微复杂的模块，因此尚不能100％地比较，但是尽管我们的源代码中有大量字符串文字(调试日志消息过多，但似乎已经足够安全) )用Delphi 2009编译的二进制文件的大小可能实际上与以前大致相同！

我想知道，Delphi编译器是否实际上以任何方式对二进制文件或者至少其资源部分执行了任何形式的压缩？我真的希望更改UTF-16字符串文字会对这个特定应用产生更大的影响。这些文字是否真的以(未压缩的)UTF-16格式存储在二进制文件中？

我还没有时间研究内存占用的差异。

编辑：与Unicode不直接相关，但绝对相关：Andreas Hausladen最近发布了有关{{STRINGCHECKS}`编译器选项(BTW：默认为打开)对已编译的可执行文件大小(显着)的影响的有趣信息。 /andy.jgknet.de/blog/?p=487