BOM问题

unicode网站上介绍BOM如下：

 详见：http://www.unicode.org/faq/utf_bom.html#BOM这是网上的另一段说明：

Byte Order Mark (BOM) FAQ
Q: What is a BOM?

A: A byte order mark (BOM) consists of the character code U+FEFF at the beginning of a data stream, where it can be used as a signature defining the byte order and encoding form, primarily of unmarked plaintext files. Under some higher level protocols, use of a BOM may be mandatory (or prohibited) in the Unicode data stream defined in that protocol. [AF]

Q: Where is a BOM useful?

A: A BOM is useful at the beginning of files that are typed as text, but for which it is not known whether they are in big or little endian format—it can also serve as a hint indicating that the file is in Unicode, as opposed to in a legacy encoding and furthermore, it act as a signature for the specific encoding form used . [MD] & [AF] 

Q: What does ‘endian’ mean?

A: Data types longer than a byte can be stored in computer memory with the most significant byte (MSB) first or last. The former is called big-endian, the latter little-endian. When data are exchange in the same byte order as they were in the memory of the originating system, they may appear to be in the wrong byte order on the receiving system. In that situation, a BOM would look like 0xFFFE which is a noncharacter, allowing the receiving system to apply byte reversal before processing the data. UTF-8 is byte oriented and therefore does not have that issue. Nevertheless, an initial BOM might be useful to identify the datastream as UTF-8. [AF] 

 

在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来标记文本文件的编码方式的。

言归正传！

今天在使用IBM DB2的Net Search Extender的时候发现，英文、德文都没有问题，只要DEF文件中一旦有中文字符，就会说无法使用db2extth编译。直到插手册的时候，我的Partner给我写了这么一段话：

Wichtig!: Die UTF8 BOM muss vor der Kompilierung aus dem Definitionsdatei entfernt werden. Die "db2extth" kann die BOM nicht verarbeiten und meldet es als Fehler in der Eingabe.

原来如此！
然后又在网上查BOM的资料，得到以上的那些引文。好，下面开始实战：

将DEF文件重新编写，使用UltraEdit将文件保存为“UTF-8不含BOM”，然后编译==通过！使用NSE的Thesaurus，得出检索结果！
后来我又想，如果我的DEF文件内的中文字符是用JDBC从DB2中取出来的，那么会不会有问题呢？还需要经过什么无BOM的UTF8转换之类的吗？于是，试了一下，结果完全没问题！然后又查BOM的相关说明，发现了以下的话：

Q: Why wouldn’t I always use a protocol that requires a BOM?

A: Where the data is typed, such as a field in a database, a BOM is unnecessary. In particular, if a text data stream is marked as UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE, a BOM is neither necessary nor permitted. Any FEFF would be interpreted as a ZWNBSP.

Do not tag every string in a database or set of fields with a BOM, since it wastes space and complicates string concatenation. Moreover, it also means two data fields may have precisely the same content, but not be binary-equal (where one is prefaced by a BOM). [MD]

呵呵，又是豁然开朗！

完毕！