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
Marco Casario is one of the most dynamic developers in the Adobe (formerly Macromedia) world. Flex and FlashLite certified Instructor, Flash and Dreamweaver certified, he intensively collaborates with Adobe Italy as a speaker and promoter of several events and roadshows. Marco has recently founded Comtaste S.r.l., a company dedicated to explore new frontiers in the Web 2.0 field, where the themes of accessibility and usability have added further importance to the PDF format and the relevant Acrobat application tools.
