Considering the byte order mark (UTF-BOM) when reading a text file using the readUTF() method in AIR

Working with Adobe AIR's d ead and write methods, we encountered  some strange behaviors when using the readUTF() method to read text files (TXT or RTF).
In fact if the text file we're opening has not been created by Adobe AIR,  we got a runtime error (number #2030 line ending ....) from the Flash Player. Investigating we discovered that the readUTF() method won't find a couple of bytes embedded into the file that it needs.

From the Adobe AIR  documentation :

The readUTF() and the writeUTF() methods (not to be confused with readUTFBytes() and writeUTFBytes()) also read and write the text data to a file, but they assume that the text data is preceded by data specifying the length of the text data, which is not a common practice in standard text files.

Some UTF-encoded text files begin with a "UTF-BOM" (byte order mark) character that defines the endianness as well as the encoding format (such as UTF-16 or UTF-32).

Instead, reading the file using the writeUTFBytes() everything works well.
I'm trying to understand if the IDataInput and IDataOutput objects are responsible for the serialization/deserialization.

Anyone had the same problem ?

when