关于fasetreport设计器乱码和运行期静态文本乱码的问题道歉

Question

不好意思，是我自己搞错了。
新的4.8.5版本的fastreport在d2010下已经能比较好的运行了，当然我只是用了fastreport最表浅的报表功能，没有深入使用。
在常规的报表开发设计和使用中，已经没有明显的中文问题了。在4.8.5版本上新设计的报表，在设计器和运行期，无论是静态文本，还是动态产生的问题，都没有发现乱码。4.8.5版本加载4.6.X版本的报表，那些设计器输入好的静态文本的确存在乱码，经检查发现，应该是4.6.X的一个bug。
我打开4.6.X版本的fr3文件查看(fr3是ut8格式的xml),静态文本是正确的utf8格式，但是每个memo的字体名称仍然是ansi格式的，也就是说，直接用ansi格式打开4.6.X的fr3文件，字体名称是正确的，文本是乱码，以utf8格式打开fr3文件，字体名称是乱码，文本是正确的。应该说这个是4.6.X版本存盘上的一个bug到了4.7.X和4.8.X版本，fr3文件里面的中文，无论是静态文本，还是字体名称，都是用utf8格式表示，导致了4.7.X以后的版本调用4.6.X版本的fr3文件后，每个memo的字体名称丢失，引起设计期的静态文字乱码。我不知道是我当时用4.6.X存盘不正确，还是的确是一个bug，如果是，这个bug怎么修正，难道用正则表达式把所有的老版本的fr3文件的字体名称从ansi格式替换为utf8格式，这样才能正确，该怎么处理好呢，大家给点意见。

Answer 1

难道用正则表达式把所有的老版本的fr3文件的字体名称从ansi格式替换为utf8格式，这样才能正确恩，用VBS编写吧，快一点

Answer 2

闪亮登场的 UnicodeString 类型Tiburon 中，新的、默认的 string 就是 UnicodeString。这个类型既可以包含 ANSI 字符，也可以包含 Unicode 字符。下面是 UnicodeString 类型的结构：Format of UnicodeString Data Type  CodePage   Element Size   Reference Count    Length    String Data (element sized)    Null Term  
-12    -10    -8    -4    0    Length * elementsize   
UnicodeString 和 AnsiString 都是如上的结构，尽管 UnicodeString 包含是双字节数据，AnsiString 包含的是单字节的。用 Object Pascal 语言来描述 UnicodeString 的结构，应该是这样：type
StrRec = record
    CodePage: Word;
    ElemSize: Word;
    refCount: Integer;
    Len: Integer;
    case Integer of
      1: array[0..0] of AnsiChar;
      2: array[0..0] of WideChar;
end;UnicodeString 增加了 code page 字段和 element size 来描述字符串内容，这使得 UnicodeString 和其它类型的字符串可以很好的相兼容，所以 AnsiString 和 UnicodeString 可以很方便的互相转换，唯一要注意的是，当把 UnicodeString 向下转型到 AnsiString 的时候，可能会丢失数据，因此强烈建议你不要这么做。UnicodeString 保存的是 UTF-16 字符。在旧的环境下，可以使用编译标志 Unicode 来判断编译环境是否支持 UnicodeString，以便您可以在同一套代码中维护不同版本的字符支持环境。编译指令如下：Delphi 使用：
     {$IFDEF Unicode}
C++ Builder 使用：
     #ifdef _DELPHI_STRING_UNICODE