XE（2009及以后） 里的 string 是 UnicodeString，采用的是 winnt 系列的系统内核字符集 utf-16（或称 ucs2）。和 utf-16 le 一样，utf-8 也是一种针对 unicode 字符集的编码，两者表达的范围是相同的。两者的差别主要就在于编码方式，前者基本上可以当作是定长的，而后者的长度是不定的：utf-16 中，一个字符至少两占2字节，还有一些非常偏的字符占4字节（只有2和4两种长度，后者一般人用不到，连支持的字体都不好找）；而 utf-8 中一个字符最少占1字节，查了一下10月份刚出的6.0（
http://www.unicode.org/Public/6.0.0/ucd/UnicodeData.txt），unicode 字符现在排到了 U+10FFFD，也就意味着目前最多占4字节（一般的汉字占3字节）。两者表达的都是 unicode 字符集，只是表达方式不同而已，不存在哪个比哪个更兼容。
由于 utf-8 的编码方式与机器的 endian 无关，并且容易检验完整性，因此在传输上 utf-8 有非常大的优势；另外，又由于许多文本中主要字符都是 ASCII 那些，所以在某些情况下的空间占用方面（尤其对美欧来说），utf-8 也有优势。
在 win 平台想要通过 winapi 显示字符的话，最终使用的都是 utf-16 的字符串（***A 版本在 api 内部转成 unicode）。因此一般情况下，可视化控件之类，直接使用 UnicodeString 是最方便的，只在储存和传输时转成 utf-8 就可以了。
在库中使用 UTF8String 肯定要仔细权衡的，而不是随随便便就说哪个一定比另外一个好。在一些情况下，核心处理功能在库内部，占用大量时间，迁移 unicode 版本的难度非常大，或者占用更多内存，但效果又不一定好。这时候不如保留原来的 ANSI 版本库，稍作修改就可以支持 utf-8，不但支持了 unicode，内存占用没什么变化，代码也没做多大修改。
最常见的应用就是字符串匹配，比如基于 B-M 算法的子串匹配，由其算法的原理决定，如果不采用 Integer*64k 的空间对 utf-16 进行匹配，对于纯 ASCII 字符的搜索，就无法保证每次移动都是最大可移动距离，算法自身的性能发挥不出来；但一次 256k 的空间占用又有点浪费内存，初始化的常数时间长，并且 CPU cache 装这么多数据也影响后面搜索时的性能。采用 utf-8 的话，空间复杂度还是 256*4，常数初始化时间不变，每次移动也基本上能保证较长的长度。所以比较复杂的字符串算法在支持 unicode 方面，直接采用 utf-16 的很少，而用 utf-8 的比较多。
再就是同时要考虑内存占用的场景，正常情况下绝大多数内容都是 ASCII 字符，使用 utf-16 过于浪费空间。常见的应用是词法处理，比如编译器或者 html、xml 等的词法扫描器。
正则表达式是符合上面所有描述的应用，自动机的构造和转换非常复杂（词法扫描也是用自动机），由 ANSI 迁移至 utf-16 的难度大，空间复杂度也大大增加了。