EF BB BF的问题

     今天我在做MSMQ消息发送的时候，发现收到的消息老是说反序列化失败；于是我用另外的MSMQ测试工具把要发送的报文贴进去，再发送到MSMQ，在MSMQ里面发现2种方式接收到的同一个消息居然长度不一致；

     于是我采用了beyondcompare的2进制比较模式打开消息模板文件（.txt），发现在<?xml 之前果然多了3个16进制符号；联想起以前遇到过的一个问题，才晓得是UTF-8的标志符号；

     于是我将TXT另存为ANSI格式，这个标志就去掉了，消息也可以正常使用了。

     还是不甘心，在网上搜了一些资料，贴在下面，便于以后提醒自己：

    

Unicode规范中有一个BOM的概念。BOM——Byte Order Mark，就是字节序标记。在这里找到一段关于BOM的说明：

在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little- Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的ef bb bf了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。

如果想去掉bom，如果只包含英文字符(或者说ASCII编码内的字符)，就把文件存成ASCII码方式吧。用UE等编辑器的话，点文件->转换 ->UTF-8转ASCII，或者在另存为里选择ASCII编码。如果是DOS格式的行尾符，可以用记事本打开，点另存为，选ASCII编码。如果包含中文字符的话，可以用UE的另存为功能，选择“UTF-8 无 BOM”即可。

根据Bo-Blog的wiki的说明：Editplus需要先另存为gb，再另存为UTF-8。不过这样做要小心，所有GBK编码中不包含的字符就会都丢了。如果有一些非中文的字符在文件里的话还是不要用这种办法了。(从这一个小方面来看，UE——UltraEdite-32确实比Editplus 好很多，Editplus太轻量级了)

另外我发现了一个办法，就是利用Wordpress提供的文件编辑器。这个办法不受限制，不需要去下载专门的编辑器，毕竟大家都在用 Wordpress嘛。先在ftp里把要编辑的文件的写入权限打开，然后进入Wordpress后台->管理->文件编辑器，输入要编辑文件的路径，点编辑文件。在显示出来的编辑界面中，你是看不到开头的那三个字符的，不过没关系，把光标定位在整个文件的第一个字符前，按一下 Backspace键。OK了，点更新文件吧，在ftp里刷新一下，可以看到文件小了3字节，大功告成。