也谈UTF8编码问题

        今天碰到UTF8汉字编码的问题。原因是帮公司写了一个小的应用系统，后台数据是通过客户提供的文本型（TXT）数据（格式固定），文件较大，接近47M，数据记录条数接近100万，我们这边将这种文本数据导入我司应用系统数据库。去年的数据导入没问题，今年导入时，出现汉字乱码。仅从TXT文本浏览角度，无差别。但查看文件编码时发现去年的还是ansi编码，现在的编码却是UTF8了。最直接的办法就是另存副本为ansi编码的文本，简单可行。只是由于文本较多，操作人员提出修改程序，直接导入。

         在delphi2010环境下，通过系统自带编码转换函数，失败！在调试过程中，发现只要将源文件另存一下副本（还是保持UTF8编码格式），副本文件大小比源文件大3个字节。程序调试正常通过！从这个角度来看，delphi2010的编码转换函数是可用的。但是问题出在哪里？

      通过TEncoding.UTF8.GetBytes这个函数测试，发现读取一条内容相同记录后，UTF8字节数组二者存在明显差异。在非汉字字符这块，值是相同的，但是在汉字这块，源文件与副本两者完全是面目全非。首先，源文件记录读取后，字节比副本多了一倍（副本是6个，源文件是12个），此外每个值都不一样——就像源文件是被加密了一样。

上面是副本读取记录的。黄色部分是调试时u8s1的即时内容。

上面是源文件读取后的。变量u8s1为Tbytes类型。也就是说客户提供的TXT文本，隐藏有其他信息。当然解决的办法简单实用的就是另存一下。

       奇怪的是，为什么变化只发生在汉字上面——2个图片里，u8s1变量前面双数字节内容就是英文的，后面3个数字节内容是汉字的。就整体文件而言，副本原本是要比源文件大3个字节。而读取每一条记录，反倒是源文件导致读取的内容要多出（汉字）一倍的字节内容，这么想来，源文件里面的确是存在某种隐含机制，控制着汉字数据区的读取结果。UTF8有点烧脑！