你能否告诉我使用时是否有一些优势(减少空间,增加速度等):
resourcestring
MsgErrInvalidInputRange = 'Invalid Message Here!';
代替
const
MsgErrInvalidInputRange : String = 'Invalid Message Here!';
Arn*_*hez 13
const选项将比resourcestring更快,因为后者将调用Windows API来获取资源文本.您可以通过使用一些缓存机制使其更快.这就是我们在增强型Delphi RTL中所做的工作.
如果您必须多次访问resourcestring内容,那么首先将resourcestring加载到字符串中是个好主意.
资源字符串的要点是允许程序的i18n(国际化).
你有一些版本的Delphi IDE翻译管理器.但它依赖于外部DLL.
您可以使用来自Linux世界的gettext系统,它来自http://dxgettext.po.dk,它依赖于外部.po文件.
我们在我们的框架中包含了我们自己的i18n机制,它转换和缓存资源字符串文本,并依赖于外部.txt文件(您可以使用UTF-8或Unicode文本文件,从Delphi 6到XE).缓存使其与const使用速度一样快.见http://synopse.info/fossil/finfo?name=SQLite3/SQLite3i18n.pas
还有其他开源或商业解决方案.
关于大小存储,resourcestring存储为UC2缓冲区.所以resourcestring将使用比Delphi 2009更多的内存.自Delphi 2009以来,所有字符串都是unicodestring即UCS2,所以你不会有更多的存储空间.在所有情况下,文本的存储大小不是应用程序的较大大小参数(位图和代码大小对最终exe具有更大的影响).
资源字符串在exe资源中存储为STRINGTABLE条目,consts存储为固定数据段的一部分.由于它们是资源部分的一部分,因此您可以提取它们和DFM,转换它们,并将它们存储在资源模块(仅数据DLL)中.当Delphi应用程序启动时,它会查找该DLL并使用其中的字符串而不是EXE中包含的字符串来加载翻译.
Embarcadero docwiki涵盖了使用翻译管理器,但许多其他Delphi翻译工具也使用资源字符串.
正如其他人所提到的，资源字符串字符串将包含在您的 exe 中的单独资源中，因此当您需要在应用程序的 UI 中满足多种语言时具有优势。
正如一些人所提到的，const 字符串包含在您的应用程序的数据部分中。
直到 D2007
在D2007 之前的Delphi 版本中，const 字符串存储为 Ansi 字符串，每个字符需要一个字节，而资源字符串将以 UTF-16 存储：Windows 默认编码（尽管可能不适用于 Win9x）。IIRC D2007 和之前的版本不支持 UTF-8 编码的单元文件。因此，在您的源代码中编码的任何字符串都必须得到 ANSI 代码页的支持，因此可能不会超出 Unicode 基本多语言平面。这意味着将仅使用 UTF-16 的 UCS-2 部分，并且所有字符串都可以每个字符存储在两个字节中。
简而言之：最多 D2007 常量字符串每个字符占用一个字节，资源字符串每个字符占用两个字节。
D2009 及以上
Delphi 在 D2009 版本中启用了 unicode。从那时起，情况就有些不同了。资源字符串字符串仍以 UTF-16 格式存储。这里没有其他选择，因为它们由 Windows“管理”。
然而，常量字符串是一个完全不同的故事。由于 D2009 Delphi 在您的 exe 中存储了每个 const 字符串的多个版本。每个版本采用不同的编码。Const 可以存储为 Ansi 字符串、UTF-8 字符串和 UTF-16 字符串。
存储哪些编码取决于 const 的使用。默认情况下将使用 UTf-16，因为这是默认的内部 Delphi 编码。将相同的常量分配给“正常”（UTF-16）字符串以及 AnsiString 变量，常量将存储在 UTF-16 和 Ansi 编码的 exe 中...
去重
从它的外观来看（使用 D5 和 D2009 进行实验），Delphi 对常量字符串进行了“去重”，而对于资源字符串字符串却没有这样做。