文本文件编码带来的困境

      昨天，同事的一个文本导出出现乱码的问题终于找到原因了。弄了整整一天，居然是文本文件编码识别的问题。
        问题是这样，我们的项目当前使用的是老版本的PB，导出的文件是ASCII（GB2312）码的文本文件。有时导出的时候是没有问题的，有时导出的文件用记事本、UE（UitraEdit）或notepad++打开时中文就变成方块。
        本来以为是PB在文件输出中的BUG，由于通过UE打开的时候看到了两个字节的文件头FF FE，就以为PB输出时会不确定的选择文件编码。后来我尝试用C语言编写DLL文件来写文件，问题仍然存在。甚至将这段文本拷贝到记事本中使用ASCII吗保存，再次打开时也有问题。最后通过使用NOTEPAD++查看16进制查看文件，确定文件输出时是正确的，问题在于这些文本编辑器打开文本时对编码的判定。
        先说明一下文本文件的编码问题。对于ASCII码的文件，包括各种变种（GB2312，BIG5），保存的文件中就是内容的二进制数据，没有其他的描述数据。比如保存“中国”到文件中，就只有4个字节。对于unicode标准，unincode的文本文件必须有BOM头，用来说明字节序，也可以用来判定文本编码。下面是unicode的BOM码：

Bytes	Encoding Form
00 00 FE FF	UTF-32, big-endian
FF FE 00 00	UTF-32, little-endian
FE FF	UTF-16, big-endian
FF FE	UTF-16, little-endian
EF BB BF	UTF-8

        比如一个UTF-8的文本文件包含一个字符"A"，并且有BOM的话就是4个字节大。
        但是根据标准UTF-8的文件可以无BOM，这样编辑器无法通过BOM来判定文件的编码。这种情况下，文本编辑器会根据文件内容（二进制）的一些特点来判断编码。所以及时我使用ASCII编码保存特定内容的文件，这些编译器还是根据某种算法判断成了无BOM的UTF-8文件，所以显示不正确。
        如果不相信，可以尝试一下，在记事本中保存“元”或“联通”，保存为ASCII编码，然后打开，你就会认识到此问题。在网上还有一些情况是无BOM的UTF-8文本被误认为ASCII码文件。还有如果你保存"this sentences are notreadable"，你会发现记事本打开时出现的是奇怪的中文，这是这段文字被误认为Unicode编码了。
       在DOS和win98 的记事本中打开就不会有此问题，因为它们只知道ASCII文本。
       顺便提一下，UE在打开没有BOM的UTF-8文件时，会转换为UNICODE文件，所以查看是会多出FF FE的两个字节。