去掉Adodb.Stream输出UTF-8的BOM

通过Adodb.Stream，可以很方便的读写二进制及及文本流，可读写文件，并可指定文本流的字符集编码。
可是Adodb.Stream输出UTF-8编码的文本流时，会在流的最前端加上BOM。
BOM是什么：Byte Order Mark, UTF-8编码特有的标记，在文件流的开始中占用3个字节“EF BB BF”。
BOM有什么用处：这里不做讨论，这里要讨论的是如何在Adodb.Stream(以下简化为stream或“流”)中去掉这3个字节的BOM，因为很多时候我们都不希望输出的文件开头包含这3个字节。

 

最直接简单的做法可以这样：
我们已经知道BOM占用3个字节，那么我们可以在stream中写入UTF-8字符串之后，将stream转换为二进制类型，然后跳过头3个字节，并将剩下的字节用CopyTo()方法拷贝到一个新的stream中去。
不过这样好像有潜在的很严重的性能问题，如果这个文本流比较大，会不会因为处理这个流而耗费双倍的资源？

 

那我们将上面的方案优化一下。
经过测试发现，stream在“UTF-8”编码的Text方式下首次调用WriteText()方法时，会自动在stream的最开始加入3个字节。
更严格的说，在以下状态下(JS code)：
stream.Position = 0; // 流的位置在最开始时
stream.Type = 2; // adTypeText
stream.Charset = 'UTF-8';
调用stream.WriteText()方法时，stream会自动先在流的最开始插入3个字节的BOM。

 

而stream.Position在任何非0值的情况下，调用WriteText()方法都不会再插入BOM了，可以利用这一点来避免自动插入BOM。
假如我们需要朝stream中写入10个UTF-8字符，我们先按照通常方式在一个刚创建的stream中只写入第一个UTF-8字符。
之后将stream转换为二进制类型(adTypeBinary)，跳过stream开始的3个BOM字节，并读出剩余的字节（这些字节应该只包含刚刚一个字符的数据，不含其它杂质）。
再回到流的开始，将刚刚读出的字节重新写入流，写完后立即调用SetEOS()方法将当前位置设为流末尾。
然后将stream重新转换回文本类型(adTypeText)，并将流当前位置移到流末尾。
此时继续写入剩余的9个UTF-8字符，stream会将其编码后的字节数据直接添加到尾部，而不会再插入BOM了。
此后若需要继续往stream中写入文本，直接调用WriteText()方法即可。

 

通过测试可以发现，如上方式写入的UTF-8字符串通过ReadText()方法也能正常读出，但是stream.Size却比传统方式直