Flex：即使XML格式正确，也会出现有关“格式正确”标记的错误消息

Question

I am reading attempting to load XML from a ByteArray as follows:

var xmlString:String = myByteArray.readUTFBytes(numBytes);
var myXML:XML = new XML(xmlString);

When I do that, I receive the following runtime error on the XML constructor when I run in Flash Player 9:

TypeError: Error #1088: The markup in the document following the root element must be well-formed.

This error message doesn't occur in Flash Player 10. I can use the debugger to verify that the XML looks well-formed. The XML is in UTF-8.

Answer 1

The solution to this particular problem for me was that there was an unnecessary Byte Order Mark at the very beginning of the file, which I had to remove. Upon inspecting the file with a hex editor, I saw the following as the leading bytes in the file:

EF BB BF

The Flash Player 9 runtime apparently has a problem with this Byte Order Mark on a UTF-8 file, which is unnecessary since there is no byte ordering in UTF-8, as opposed to UTF-16 and UTF-32. Flash Player 10 has no problem with this leading Byte Order Mark.

That explains, why this other blog entry documents that the following solution worked for them:

xmlString = xmlString.substr(1);

That particular solution didn't quite work for me, since it shifted the runtime error to Flash Player 10 users, instead of Flash Player 9 users. Since we had control of the XML input, we could simply modify that, but if the XML came from a source we didn't control, I suppose we could have tested the ByteArray for the leading BOM, and skipped it as shown above.

Several blog entries were helpful in confirming that the BOM was the problem, such as this entry , in which a commenter states that his solution to the same 1088 runtime error was:

For me the problem was XML saved in UTF with BOM.

Also, this other blog entry provided more confirmation of the same problem occurring in Java:

When dealing with a UTF-8 encoded RSS feed, this three-byte pattern (0xEF 0xBB 0xBF) in >the prolog can cause all sorts of interesting XML parsing problems