Thanks penpen.
I don't need the BOM values, I just need to know that there is a BOM, and the size. It wasn't too hard to modify the strategy a bit.
I manage all ADO stream IO through a custom ADOStream object that emulates a TextStream object. I handle removal of the BOM in two steps.
First in the ADOStream constructor that opens the ADO stream, I added a NoBOM boolean parameter, defaulting to FALSE. The constructor determines if the stream is for output, and what the BOM length is, (if any) using the following:
Code: Select all
var bomSize = 0;
stream.Open();
if (mode !== _g.ForReading && noBom) {
stream.WriteText("");
stream.Position = bomSize = stream.Size;
}
Then my close routine that actually writes to file does some extra work if there is a BOM that needs to be removed:
Code: Select all
Close = function() {
if (mode!==_g.ForReading){
if (bomSize) {
var noBomStream = WScript.CreateObject("ADODB.Stream");
noBomStream.Type = 1;
noBomStream.Mode = 3;
noBomStream.Open();
stream.Position = bomSize;
stream.CopyTo(noBomStream);
noBomStream.SaveToFile( name, 2 );
noBomStream.Flush();
noBomStream.Close();
noBomStream = null;
} else stream.SaveToFile( name, 2 );
}
stream.Close();
stream=null;
}
The above works well, but I don't like the fact that the entire output must be stored in memory twice if the BOM is to be removed. I fear this could cause problems with large output files. But this seems to be the accepted norm for how to remove the BOM from ADO output.
I'm getting ready to post JREPL v7.10 with the ability to remove the BOM from ADO Unicode output.
Dave Benham