2 Replies Latest reply on Dec 2, 2010 12:52 PM by Xygar32

    Flash Player 10 removes HTML encoding in CDATA when parsing XML


      I have an application that was written with Flash Professional 8/AS2 and it parses XML for rendering dynamic media content. The XML pulls text with HTML markup out of CDATA sections and places them into an html enabled text field. Everything has worked wonderfully until Flash Player 10.


      Now, if we use html escape characters for greater than or less than symbols, they are being decoded by the xml parser.


      Here's my example CDATA section:


      Here <u>we</u> go: This &#60;node&#62; &lt;works&gt;


      when I grab its value using nodeValue or toString, the results are different from Flash Player 9 to 10. Here's what I'm getting:


      node.nodeValue (Flash Player 9):

      Here <u>we</u> go: This &#60;node&#62; <works>


      node.nodeValue (Flash Player 10):

      Here <u>we</u> go: This <node> <works>


      node.toString (Flash Player 9):

      Here <u>we</u> go: This &#60;node&#62; &lt;works&gt;


      node.toString (Flash Player 10):

      Here <u>we</u> go: This <node> <works>



      In Flash 10, if I escape the ampersand, it will work, but this doesn't work in 9. for example, the following works in 10:


      <![CDATA[Here <u>we</u> go: This &amp;#60;node&amp;#62; &amp;lt;works&amp;gt;]]>


      This all happens before I assign it to a text field. How do I keep the parser from destroying my escaped characters in Flash 10? Do I just need to drop support for Flash Player 9 and go for what works in 10, or is there a solution for both?



      Message was edited by: Xygar

        • 1. Re: Flash Player 10 removes HTML encoding in CDATA when parsing XML
          Xygar Level 1

          I'm not an action script programmer. I'm just trying to fix some code written like 3 years ago. So I think I am wrong about where this problem is coming from.


          The original developer actually set up a class to load a remote xml file via sendAndLoad on a LoadVars object. It passes an object with an onData delegate set that passes the event object to an xml parsing method.


          the parsing method looks like this:


               private function parseXml(eventObj:Object){
                    if(eventObj != undefined) 
                              //ExternalInterface.call("logMessage", eventObj.toString());
                              _xmlDoc.loaded = true;


          I added the ExternalInterface call so that I could log the stuff out in javascript (since I'm not sure how to debug this app).


          _xmlDoc is defined as: private var _xmlDoc:XML;


          The eventObj receives the xml string and then passes it to the parseXML thing. Here's the odd part. In Flash Player 10, if I comment out my ExternalInterface call, the xml string has the escaped character decoded before it gets to the parser.


          However, if I uncomment my ExternalInterface call, it logs the escaped strings as i would expect, but the parser gets the correct formatting this time! Suddenly it all works.


          I really wish I had an AS2 programmer on campus still....

          • 2. Re: Flash Player 10 removes HTML encoding in CDATA when parsing XML

            For anyone who is curious, I believe I have discovered what is going on.


            It turns out, that ActionScript doesn't really distinguish between a text node and a CDATA node when parsing XML.


            In Flash Player 10.1, Flash was automatically converting all illegal characters found in a text node to their html escape sequences. In my particular example, I wanted to preserve the html format tags AS WELL AS preserve any escaped characters. The reason I needed this was that we display math content on screen, parsed from XML and would need to display a formula such as 5x < 15, inside of an HTML label. Flash Player 10.1 was making this extremely cumbersome.


            It turns out that the Flash Player 10.2 Beta does not suffer from the same problem. Flash Player 9x didn't have the problem either.