I understand that svgs are fragile (now.), but I don't have a backup copy for my backup copy. However I used peazip on my svg and the xml just happens to still be there. Is there any way I can feed that data into Inkscape to get my image back?
SVG files are XML documents. Saying "the XML is still there" is the same as saying "the SVG is still there", so the fact that the file won't load suggests the XML is corrupted in some way. Most commonly this is because only part of the file is present, so some of the elements and closing tags are likely to be missing. If the XML doesn't end in </svg> then that's likely to be the case.
If you are in that situation then it's possible to manually close the partial tags that are present in order to recover some of the file. But this could be anywhere between 0% and 100% of the useful content, depending on how much of the file was truncated. As TD says, feel free to share the file, as someone here will pretty quickly be able to determine if there's much chance of saving any useful content.
BTW, why do you say that SVGs are fragile? They should be no more fragile than any other XML document - and in some respects a lot less fragile than some. It's true that Inkscape isn't very good at recovering a malformed file, but that's a limitation of Inkscape, not of the SVG format.
Looking at your link, I can understand why you might be left thinking SVG files are fragile, but I would argue for the complete opposite. SVG, as a base format, is very well defined and understood. Plain SVG files are well supported by a number of programs, and have good support across all major browsers.
But SVG is an XML language. That means it follows strict definitions of what is considered a valid or "well-formed" document. If the file becomes corrupted in some way such that it's no longer well-formed, the XML specs pretty much say that programs should reject it outright. Yet because it's just plain text, and because the allowed structures are well understood, it's often possible to recover a lot of the content via a manual process of fixing the content and closing the tags to make it well-formed again. I would argue that this makes it very robust: if there is a problem with the file, there's a good chance that some of the content can be recovered. This isn't the case for a lot of file types.
The link you supplied deals mainly with another issue: proprietary extensions to the SVG format. These are allowed - even encouraged - as a core part of XML (the X standing for "eXtensible", after all). They allow authoring programs to add their own metadata to XML files, while still allowing them to remain well-formed. The issue is that not all programs use the same proprietary tags and attributes, so the extra features of one program don't usually survive the transfer to another.
As a concrete example, SVG has no concept of layers, so Inkscape implements them as a proprietary attribute on the <g> (group) tag. This approach means that viewing the file in a web browser, for example, still results in all the content appearing, since it just sees the layers as groups. But load such a file into another vector editor (e.g. Illustrator), and the layers are not likely to be reproduced in the program's own Layers dialog since they're defined in a format that it doesn't understand.
A program should preserve any elements or attributes it doesn't understand in the XML. So you should be able to save a layered file from Inkscape, make some small tweaks in Illustrator (where the Inkscape layers appear as groups), then re-load the modified file in Inkscape and find that the layers are intact. But this relies on Illustrator not stripping out the Inkscape-proprietary attributes that it doesn't understand, and not every program does a good job of that. FWIW I believe Inkscape is pretty good in this regard. So SVG should be fairly robust when round-tripping between different applications; where that proves not to be the case, it's a problem with the applications, not the format.
The XML world even has a solution to this: XSLT. This is a mechanism by which a set of rules can be defined that detail how to map one XML file to another. In theory you could create an XSLT file to convert Inkscape SVG into Illustrator SVG, or vice versa. But XML never gained the reach or popularity it deserved, so such forward-thinking features are hardly known about, and the tooling around them is developer focused, rather than user friendly. But again it speaks to the robustness of XML formats that there even is a standard mechanism for mapping between them.
So, in summary, pure SVG is pretty robust, and pretty recoverable if there is a problem (assuming a large enough portion of the file still exists). It has a robust extension mechanism, and potentially benefits from the ecosystem of other XML tools. Any suggestions of fragility are more often a side-effect of either badly written applications, or users' assumptions about how applications, and the SVG format, should work (e.g. an assumption that layers in one program will appear in another, without understanding that layers are not actually part of the SVG standard).
Sorry for waffling a bit, but I think it's worth putting the record straight on this as it's the kind of misunderstanding that can otherwise lead to users avoiding a format that is often the right tool for the job.
(None of which is to say that I think SVG is perfect, or couldn't use improvement. I'd love to see layers implemented as part of the standard - plus many other features - but as has been shown by the lack of enthusiasm around SVG 2.0, there's a distinct lack of political will that could result in further improvements)
Beginners' Questions Can the xml of my svg rebuild my image?
Inkscape.org
I understand that svgs are fragile (now.), but I don't have a backup copy for my backup copy. However I used peazip on my svg and the xml just happens to still be there. Is there any way I can feed that data into Inkscape to get my image back?
No "Autosave" enabled yet?
I would try pasting the xml into a text editor and saving the file as .svg.
Feel free to share the file or the xml.
SVG files are XML documents. Saying "the XML is still there" is the same as saying "the SVG is still there", so the fact that the file won't load suggests the XML is corrupted in some way. Most commonly this is because only part of the file is present, so some of the elements and closing tags are likely to be missing. If the XML doesn't end in </svg> then that's likely to be the case.
If you are in that situation then it's possible to manually close the partial tags that are present in order to recover some of the file. But this could be anywhere between 0% and 100% of the useful content, depending on how much of the file was truncated. As TD says, feel free to share the file, as someone here will pretty quickly be able to determine if there's much chance of saving any useful content.
BTW, why do you say that SVGs are fragile? They should be no more fragile than any other XML document - and in some respects a lot less fragile than some. It's true that Inkscape isn't very good at recovering a malformed file, but that's a limitation of Inkscape, not of the SVG format.
@TylerDurden - I don't mind if I do then.
The File: https://drive.google.com/file/d/1tCRnLYWDNB82MwxOq10FzfOXDWUrSRUf/view?usp=sharing
A folder with the still-there xml contents: https://drive.google.com/drive/folders/10lXy2RjPtALLb44FathEvT8evT0Jb-X3?usp=sharing
@Xav: This link is to a cave mapping software website. I'm linking to the information I got the idea of fragility from.
https://fountainware.com/compass/HTML_Help/SVG_Exporter/repair.htm
Some of the svg can be recovered. There may have been other elements that were corrupted or binary data from another program..
Deliberately blurred to protect the content.
By what sorcery is that done?
My robots need teams if I'm ever going to complete my quake style Boomer shooter in the Jetsons future.
Looking at your link, I can understand why you might be left thinking SVG files are fragile, but I would argue for the complete opposite. SVG, as a base format, is very well defined and understood. Plain SVG files are well supported by a number of programs, and have good support across all major browsers.
But SVG is an XML language. That means it follows strict definitions of what is considered a valid or "well-formed" document. If the file becomes corrupted in some way such that it's no longer well-formed, the XML specs pretty much say that programs should reject it outright. Yet because it's just plain text, and because the allowed structures are well understood, it's often possible to recover a lot of the content via a manual process of fixing the content and closing the tags to make it well-formed again. I would argue that this makes it very robust: if there is a problem with the file, there's a good chance that some of the content can be recovered. This isn't the case for a lot of file types.
The link you supplied deals mainly with another issue: proprietary extensions to the SVG format. These are allowed - even encouraged - as a core part of XML (the X standing for "eXtensible", after all). They allow authoring programs to add their own metadata to XML files, while still allowing them to remain well-formed. The issue is that not all programs use the same proprietary tags and attributes, so the extra features of one program don't usually survive the transfer to another.
As a concrete example, SVG has no concept of layers, so Inkscape implements them as a proprietary attribute on the <g> (group) tag. This approach means that viewing the file in a web browser, for example, still results in all the content appearing, since it just sees the layers as groups. But load such a file into another vector editor (e.g. Illustrator), and the layers are not likely to be reproduced in the program's own Layers dialog since they're defined in a format that it doesn't understand.
A program should preserve any elements or attributes it doesn't understand in the XML. So you should be able to save a layered file from Inkscape, make some small tweaks in Illustrator (where the Inkscape layers appear as groups), then re-load the modified file in Inkscape and find that the layers are intact. But this relies on Illustrator not stripping out the Inkscape-proprietary attributes that it doesn't understand, and not every program does a good job of that. FWIW I believe Inkscape is pretty good in this regard. So SVG should be fairly robust when round-tripping between different applications; where that proves not to be the case, it's a problem with the applications, not the format.
The XML world even has a solution to this: XSLT. This is a mechanism by which a set of rules can be defined that detail how to map one XML file to another. In theory you could create an XSLT file to convert Inkscape SVG into Illustrator SVG, or vice versa. But XML never gained the reach or popularity it deserved, so such forward-thinking features are hardly known about, and the tooling around them is developer focused, rather than user friendly. But again it speaks to the robustness of XML formats that there even is a standard mechanism for mapping between them.
So, in summary, pure SVG is pretty robust, and pretty recoverable if there is a problem (assuming a large enough portion of the file still exists). It has a robust extension mechanism, and potentially benefits from the ecosystem of other XML tools. Any suggestions of fragility are more often a side-effect of either badly written applications, or users' assumptions about how applications, and the SVG format, should work (e.g. an assumption that layers in one program will appear in another, without understanding that layers are not actually part of the SVG standard).
Sorry for waffling a bit, but I think it's worth putting the record straight on this as it's the kind of misunderstanding that can otherwise lead to users avoiding a format that is often the right tool for the job.
(None of which is to say that I think SVG is perfect, or couldn't use improvement. I'd love to see layers implemented as part of the standard - plus many other features - but as has been shown by the lack of enthusiasm around SVG 2.0, there's a distinct lack of political will that could result in further improvements)
Using a text editor, the binary data (gibberish) can be removed.
Something that looks familiar?
Its sad that that looks like a file of my creation, and worse that it doesn't look like the file I made.
Isn´t the file you´re sharing? I´m confused.
Well, you know now how I feel.
So that's a different file that corrupted on me, maybe around the same time.
I'm also confused as to how I got open office and youtube(?) data in my file.