这是“毫无疑问太愚蠢”部门的一个：
好吧，正如主题所说：有影响吗？如果有，多少钱？我的代码和 DFM 资源中的所有字符串文字现在是否会在已编译的二进制文件中占用两倍的空间？已编译应用程序的运行时内存使用情况如何？现在所有的字符串变量会占用两倍的 RAM 吗？我应该打扰吗？
我记得在早期的预发布网络广播中有人问过类似的问题，但我不记得答案了。而且由于试用期只有 14 天，我不会在我需要的第三方库更新之前自己尝试（预计大约一个月）。
Oliver Giesen
问问题
1284 次
4 回答
1
D2009 使用 UTF-16 作为默认字符串类型，但如果需要，您可以将变量设为 UTF-8。
Jan Goyvaerts在一篇不错的博客文章中讨论了大小/速度的权衡。
DFM 中的字符串文字至少从 D7 开始就是 UTF-8。因此，D2009 的 DFM 中的字符串不会增加大小。
于 2008-09-17T13:01:42.753 回答
0
我现在终于掌握了 Delphi 2009，在进行了必要的调整之后，我的项目现在可以编译并运行得很好。:)
为了快速获得结果，我最初不得不注释掉应用程序的一个稍微复杂的模块，因此它还不是 100% 可比的，但它似乎已经足够安全，可以预测尽管我们的源代码中有大量的字符串文字（过多的调试日志消息) 使用 Delphi 2009 编译的二进制文件的大小可能与以前大致相同——如果不是实际上更少的话！
我想知道，Delphi 编译器实际上是否以任何方式对二进制文件或至少其资源部分执行任何类型的压缩？我真的希望对 UTF-16 字符串文字的更改会对这个特定的应用程序产生更大的影响。文字是否真的在二进制文件中存储为（未压缩的）UTF-16？
我还没有时间研究内存占用的差异。
编辑：不直接与 Unicode 相关，但绝对相关：Andreas Hausladen 最近发布了一个有趣的关于{$STRINGCHECKS}编译器选项（顺便说一句：默认打开）对编译的可执行文件大小的（显着）影响：http: //andy.jgknet.de /博客/?p=487
于 2008-12-06T00:19:27.670 回答
-1
我一直在等待一个 Unicode VCL 太多年了，终于我们看到了。我认为大多数应用程序不需要担心大小问题，因为它们无论如何都没有那么多字符串文字或在内存中存储大量数据。
可用性问题更加重要，以证明尽可能多地使用 Unicode。
如果某些开发人员想要创建一个小型 exe，他们可以使用 AnsiString 手动优化（如果 i18n 不是问题）。
于 2008-09-17T17:26:52.430 回答
-2
我已经很多年没有使用过 Delphi，但这可能取决于他们使用的 Unicode 编码。UTF8 与常规 ASCII 字符集完全相同（当您进入外来字符时，它只使用一个以上的字节）。UTF16 可能有点臃肿。
于 2008-09-17T12:35:49.307 回答