I was dealing with this for awlile, and it looks like converting old cs4 projects to cs4 creates what im calling "null" nodes sometimes in xml. Go through your xml files that make up your flash project (either by saving as xfl uncompressed, or unzipping the fla).
Do a search for <frames/>
<DOMLayer name="Layer 2" color="#9933CC">
I found about 4 of those cases in a large fla file. I deleted the whole DOMlayer node as listed above, and that cleaned up everything! In general though this version of flash seems really buggy, and there are some projects im still unable to compile due to TBD reasons . . .
I came across this error today when I tried to open a .fla file that I had been working on. It has taken me about an hour to fix it but I think that I am happy enough now. Here is my solution so that maybe it can help others:
- Make a copy of your .fla so that you can work on it and change the extension from .fla to .zip
- Open it with winRAR, extract the contents to a folder somewhere and you will see all the various things that make up your project in this folder.
- Now, open flash and make a completely new project (just a blank project) and go File> Save as.. and instead of saving this new project as a .fla save it as a Flash CS5 Uncompressed Document (*.xfl)
What you need to do next is tedious BUT it might just save your bacon. One by one copy the various elements (XML, Library, bin etc) from the corrupt version to the blank folder (overwriting the new blank versions folders/files). Each time you move another piece into the folder open the .XFL and make sure that it works each time...(tedious but each time you open it you'll see the original project coming back to life) Keep doing this until it doesn't open and hey presto you've now found the corrupt file.
What you do next is your guess. For me the corrupt file was an xml file and I'm sure your corrupt file will be an XML file too (it is a parsing error after all). I simply deleted this XML file because it wasn't anything major. It'll take me a minute to re-do this movieclip within flash. If you can do this too then that would be a small sacrifice to get the project up and running again. I'm sure Adobe will sort this out soon and I hope my solution helps someone else.
I was able to find out that there is actually an ETX character in that empty node that might be causing this issue, I did a write up on it complete with wbfreek26 as the source of the solution! http://www.sosuke.com/index.php/2010/08/11/flash-cannot-parse-this-document-adobe-flash-cs 5/
Sorry but this thread is not 'answered' as it says at the top. I've just come across this problem with a file I was working on happily last night, and this morning it won't open - "cannot parse". I've tried all the suggestions above, to no avail... And I've tried the Adobe Flash update (http://www.adobe.com/support/flash/downloads.html) but that won't let me install it - I get another error message saying 'Error loading Updater worklflow'. Adobe - what are you doing about this problem?
Hi, my name is Pablo from Argentina. So i also encountered this error when trying to save my project in CS4 and then back to CS5 by mistake. I hope I can clear the doubts to the ones suffering from the hands of dreadful developers and testers. This is what i did to bring my project back to life. I assume we are using a test.fla file
- Rename your file from test.fla to test.zip
- Unzip it
- Inside your unzipped folder you should have a similar structure to this:
- Create a new fresh folder, maybe called Test2 and copy te contents of the unzipped folder.
- Delete all the items from the Library Folder
- Copy the xml files from the Test>Library to Test2>Library from 10 to 10, opening the test.xfl y test2 folder, every 10 files till the error comes up. So then you'll know the file getting the error is in that last 10 files you copied.
- Then keep copying inside those 10 files, one by one, till Flash cannot open the file. So you will know which one is the file giving you the error.
At this stage you'll probably be thinking that a company like Adobe couldn't miss this error in a mega development like CS5, but they did, until the update, so this brief tutorial is for the ones like me that missed the patch, or have a project damaged by the software.
- When you narrowed the search and identified the file giving the error, open it.
- I discovered that the xml structure for the library item (represented in this xml file) would be something like this
// Here should be the content of the frame
/// the objects in the stage
- So, maybe this should be the approximate structure of the xml file, i don't know how exact is this, i didn't developed the application, the geniuses of Adobe did. I discovered that in my error xml file, this structure was truncated, yes truncated, there were things like this for example:
///some actionscript content
<elements/> (WTF??!! No opening tag, and a truncated closing tag)
- So after burning my head trying to identify this not opening, not closing tags, and deleting or correcting each one of them, i managed to recover my agonizing file, it's back again! At this stage i was tearing my hair off and swearing to all of the talented developers working against the clock to bring us a version that could have waited 2 more months to be shipped in a full version, not beta.
There is also a couple of more errors other people encountered, i recommend keep searching for your exact error.
Hope this helps
The solution that I'm suggesting is for those who plan to save their work as CS5 but are not sure whether the FLA will be saved properly or not.
I came up with this plan, since I too faced the same issue and had to find a solution, if I had to migrate loads of apps across to CS5.
the main reason for this issue to crop up is due to a blank layer within the library, due to which the FLA when saved as CS5 on re-opening will throw the "Flash can not parse this document" error in the output window.
So before you save your FLA to CS5 just run the below JSFL code so the it checks and reports for any library elements with blank layers.
// Find Layers with no frames in the library
// @author chetan
// clear the output panel
var nonRepeatClassArray = new Array();
// this function searches for a layers with 0 frame length
fl.trace("<<---The classes linked are--->> ");
for (var i=0;i<fl.getDocumentDOM().library.items.length;i++)
if(fl.getDocumentDOM().library.items[i].itemType == "movie clip")
var layers = fl.getDocumentDOM().library.items[i].timeline.layers;
var layerLen = fl.getDocumentDOM().library.items[i].timeline.layers.length;
if(layers[k].frames.length == 0)
fl.trace("frame length is ::"+ layers[k].frames.length);
once you run the jsfl you will find the details of the movieclips with layers of 0 framelength, now find those layers in your FLA and delete it or just have a blank key frame.
now you will be able to save your FLA in CS5 format without any issues.
I've just experienced the same problem, but fortunately, becasue of you guys i had solved it and back up and running with my project!
I am really grateful for all the altruistic people out there who have a minute to help others. *Cries from happiness*
There is what I did:
1. followed exactly what stephenhayden(#41) said (your corrupted file will most probably be in LIBRARY subdirectory of unzipped fla) except i didnt even have to redo a corrupted movieclip, because
2. what naipemarcado said in #45 fixed my corrupted "someLibraryMovieClip.xml" file.
What you do is open corrupted .xml file in any text editor or even Dreamweaver
and look for stand-alone tags like <element/> or <frame/>
Here is my corrupted code (2 layers without frames):
<DOMLayer name="Layer 28" color="#FF4FFF">
<DOMLayer name="preview" color="#FFFF4F" autoNamed="false">
And here how it is supposed to be:
<DOMLayer name="Layer 28" color="#FF4FFF">
<DOMFrame index="0" keyMode="9728">
<DOMLayer name="preview" color="#FFFF4F" autoNamed="false">
<DOMFrame index="0" keyMode="9728">
Voila! save and overwrite the corrupted file and finally move on with your project!
P.S. chetana's JSFL code (post #46) is very useful too! Run it every time in the end of your worksession before saving.
here is how:
1. Create new JSFL project in Flash and insert the code provided by chetana
2. Save under any name and in any location
3. to run: before saving your project in Flash go to [ Commands > Run Command ... ] find the JSFL file you just saved
4. if the Output window returns anything along the lines "frame length is :: 0" go to that movie clip and layer and add blank keyframe, as people said before. Repeat until JSFL Output is clean
5. Finally save.....
Yeah, this is pretty big messup on Adobe's part ... And its a shame that its so easy to fix... lol
I hate to be the bearer of bad news, but the problem does not appear to have been corrected with the latest version-- it just happened to me.
I had restored to an earlier version in my source control 3 times before I realized the issue could be fixed through the method described here. In the end it was my UILoader component that was causing the problem. Thanks to those who provided assistance!
Whoa, this is complete BS. I can't believe a bug like this exists. I tried the steps previously posted and successfully fixed my corrupted file. I changed .fla to .zip then looked for the corrupted XML. Unfortunately for me the corrupted XML was the main one (DOMDocument.xml) so it wasn't as easy as deleting a library item and re-saving as a cs4 file. I had to manually parse the XML looking for any syntax errors, and what I did was basically delete all the XML blocks that are layers in the flash documents:
<DOMLayer name="slide6" color="#9933CC" autoNamed="false">
<DOMFrame index="0" keyMode="9728">
<DOMSymbolInstance libraryItemName="people" name="people" centerPoint3DX="71" centerPoint3DY="101">
<Matrix a="0.400802612304688" d="0.400802612304688" tx="23.5" ty="53.5"/>
<Point x="118.5" y="118.5"/>
And I added them one by one, checking the .xfl each time. I was able to narrow the error down to ONE CHARACTER inside a text layer. That's right, not a syntax error or an empty frame or a corrupted library item. One single character caused the error and made me waste hours of time looking through XML : (looks like an empty space, it might get stripped by the forum editor too). I'm lucky my project was small enough but I wonder how many people have had to redo huge projects because of one character since they probably didn't want to look through hundreds of xml files.
I'm lucky my project was small enough but I wonder how many people have had to redo huge projects because of one character since they probably didn't want to look through hundreds of xml files.
I encountered this error as well.
I changed extension to ZIP.
Opened in WinRAR - rebuilt it under the menu "options"
Opened the DOMDocument.xml file
Copied it's contents and then went to:
Pasted via "direct input"
Checked it - 2 errors.
Turns out in one my text fields I had invalid characters. They showed up as "ETX" ( white text on a black background )
Deleted them in the XML file. Saved.
Zipped the contents back up and renamed the extension ".fla"
quickly saved as a CS4 file hahaha.
( i also had seen some ambiguous references to flash.ai assets - deleted those layers and removed the xml entry out of the top symbols list too - this combination didn't really seem to do much... did the above and it finally worked )
This problem is still occuring (An earlier post said it might be fixed with the update but it is still happening - sorry) I was using Flash CS5 exclusively (not switching form CS4) when my fla file would no longer work when trying to open the project today.
Though, following the steps that some of you presented (i.e. the fla to zip solution) fixed my problem file. Thanks!!!
I think my problem came about when duplicating a symbol to make another symbol with the same attributes but different content. I recommend just making new symbols until there is an Adobe update to really fix this problem.
I can't get the fixes to work. For some reason, the flash file saved fine and all, and then when I opened it two days later, it said that it couldn't parse the document. Same with the older .fla I had from a month ago. I tried the .zip fixes but they wouldn't work (I'm on a mac, maybe that's why?). Anyway, It's rather important as it's a large file and it would take days to try to recreate what I had.
Hey, I just had this problem, freaked out, and then was able to solve it thanks to all the great suggestions here. I'm on a Mac too, so here's what I did, in case it helps.
1. Saved a copy of my .fla file and changed the extension to .zip
2. Double-clicked the .zip file, which automatically uncompressed into a folder full of files.
3. Based on earlier advice, I made a copy of the uncompressed folder and deleted everything in its Library folder.
4. Moved files from the first Library folder into the now-empty Library folder 10 at a time, opening the .xfl after each transfer to see if it would work.
5. When the .xfl file finally started throwing the error again, I zeroed in on the 10 files in the last Library transfer. I deleted them one by one until the .xfl file would open again.
6. Took the contents of the one .xml file that seemed to be the trouble and ran it through the validator (http://validator.w3.org/check) to see if it had any suggestions.
7. Surprise! Turned out to be a single special characted after a period that looked like an empty space. I deleted it, reassembled the Library contents, and my file was good to go (knock wood).
Hopefully this helps someone! Thanks for helping me.
When I tried to unzip it though, it just turned into another flash file for some reason. I kept on trying to unzip it and it would just turn into filename2.zip filename3.zip, etc. Really bizarre. I thought it was just because I was on a mac or something, but maybe it's because the file is around 130 MB? Anyway, yeah, that method didn't work for me. I pretty much tried everything. I'm now rebuilding most of the file.
Thus again, this problem with CS5 is still prevalent! This error is very serious as I've read many complaints about it in numerous forums, and countless individuals have lost hours upon hours of work. I created my file in CS5 and worked on this project for close to a week, and after a recent save, discovered I could not open it again. I received the error that it could not be parsed.
I decompiled the file by following the steps provided in these and other forums by copying, changing to zip, reviewing the xml files, etc, etc., and discovered that in DOMDocument.xml file, well over half of the code was missing, so I was unable to save any of my work or rescue the file.
I don't want to experience this in the future, or with an even larger project! I would like to downgrade somehow to CS4, or Adobe, if you have a fix that we can download for this nasty bug in CS5. I would like to resolve this before starting anymore projects. Is the only answer to save our projects multiple times under different names and in different folders?
Please describe the steps which leaded to this issue, if you remember them
It will also be good to know your OS and hardware configuration, and whether your Flash was updated when the file was corrupted (look for the number in About screen -- should start with 11-- and plase writhe it down with the rest of the info).
Unfortunately, there are still some serious issues about XFL files getting corrupted while editign - in my case. (yes, I'm using version 220.127.116.119 on a Windows 7, 64 Bit machine)
I think, it has also something to do with the rendering of 9-slice items and drawing object (like those with round edges).
Even touching them, moving them around can easily corrupt the XFL in memory in just a few seconds.
The symptoms are: massive duplicating of symbol items and timelines (like there's an endless loop somewhere when re-building the DOM structure)
The XFL file format is currently a nightmare for our game project. I can only make about 1 or 2 changes to that file until it begins to corrupt itself.
9-slice items are very rare, so I think that's the reason I didn't find other people out there who have this problem.
And this problem doesn't occur in all the other XFL files I have, only in the big one with all this 9-slice items.
I also noticed even selecting such a 9-slice item triggers a complete export of that symbol, just for drawing it (it appears on my render-history with about 400+/- bytes).
I think, there is something buggy in that area. So everyone please try that out if you have the time (this may only happen in a bit more complex setting with nested symbols containing 9-slice items)
I already filed a bug report and have mailed with a staff member about this who couldn't reproduce the bug unfortunately.
This issue makes XFL unusable for our game project. And always having to select "save as..." to save it as a CS4 file is quite tedious.
So, th elast post on this was in May but I'm hoping someone still has a clue how to resolve this issue. I've got a file with hundreds of man hours invested and neither it or three weeks of back-ups will open. "Flash can not parse this document."
This is a file that I was working with and creating SWF files from on Friday.
I'm using CS5 18.104.22.1689
I updated to OS X Lion a few weeks ago but have opened and closed this file without issue since then.
I need help urgently as I'm up against a deadline.
My file also got corupted!!!!! .
Is this fixed in 5.5? Because Chetana said that this was fixed in update 22.214.171.1249 and that isnt true because I have that version!
My company already purchased CS5.5. Can i also mail my document so Adobe can fix it for me? please.
I am trying to fix it myself but this is a lot of work and I dont know if it will work for sure!
I'm experiencing this issue as well, running Flash CS5 126.96.36.1999 on win7 x64. I've tracked it down to a single, reproducible action that causes the file to become corrupt on saving:
I have a custom swc component in the root of my library. If I drag that component into a folder, any folder, and save the file, the resulting file will be corrupted (CS5 fla or xfl).
It doesn't matter which folder I put the component into. I have plenty of other components in the file which I move around without killing it. No empty frames are in the file, this is not a CS4 import, and it has no weird AS3 empty or extended text chars as some others have reported as a cause for them.
The bin and library folders and files are identical between the pre-corrupt and the corrupted version. The main difference in the DOMDocument.xml file is the swcPath change to the moved component (both the corrupt and pre-corrupt refer to a non-existant xml file with the same name as the component -- which appears to be the norm for components in the DOMDocument.xml file). There do not appear to be any other significant differences between the folders or files.
It seems like there's something about the component that's tripping it up, but I can't find out what that might be. I checked the publish settings, rebuilt the swc and re-imported (replaced) the offending component, but it did not help (new component still works in the root, corrupts in a folder). If I export the component under a different name, re-import it without replacing the old one, then I can move the new one into a folder without causing corruption (leaving the original in the root). However, moving the original into a folder will still corrupt the file.
The file is NOT corrupted if I save it as a CS4.fla. If I then take the CS4 file, close and reopen it in CS5, then re-save it as a CS5 file (fla or xfl), it will not be corrupted (even with the original component in a folder). The workaround appears to be to stick with CS4 format.
I experienced exactly the same thing in my fully updated CS5.
After spending my entire day searching my huge project for empty tags in the xml-files, I found that 3 of my movieclips were "bad guys" and the answer to why my project was corrupted.
I then realised that they were all using components, and the last time I worked on the project, I was cleaning up my library and putting all the components in a seperat folder, which I have done so often before in other fla files, but never will du again.
Putting the components back into the root of the library, and everything is running again... What a drag, but I'm happy to get my project back again, as my backup to was corrupted!
I would just like to say thanks you to chetana
You are legend. that script fixed my file wich is due in the morning. this is my last chance aswell as this is the late submission deadline.
I would never of even had a website to hand in!
But as i say this its a joke that this problem even excists in flash. Adobe would want to get the finger out and get it sorted. if a simple script like this can find the file that will cause a problem why can they not just make this script run every time you try to save. then this problem could be avoided me and the many others would not have to go through the stress and madness i had to go through the last few days!
Please read the following blog post for a solution to the Unexpected File Format Error: