I’ve got a situation where I need to read in multiple xml files and build a single model from it. Sadly, the files are generated by a legacy system that I absolutely cannot alter.
One of the XML files that’s giving me trouble looks more or less like this (altered to remove proprietary data):
<resource lang="en" dataId="900">
numbered content here, 900-919 ...
<string name="920-name">Document Shredder</string>
<string name="920-desc">A machine ideal for destroying documents that deserve it. It can cross-shred anything from tissue paper to small netbooks with minimal noise. Remember, hackers can't access the documents if you've shredded the drives.</string>
<string name="920-cat">office,appliance</string>
<string name="921-name">Plastic Ladle</string>
<string name="921-desc">This is a big plastic ladle, ideal for soups and sauces.</string>
<string name="921-cat">kitchen,utensils</string>
... similar numbered content here, 922-934 ...
<string name="935-name">Green Laser Pointer</string>
<string name="935-desc">A High-Powered green laser pointer, ideal for irritating cats.</string>
<string name="935-cat">office,tool</string>
<string name="936-name">Black Metal Filing Cabinet</string>
<string name="936-desc">A large, metal cabinet (black) built to store hanging file folders.</string>
<string name="936-cat">office,storage</string>
... similar numbered content here, 937-994
</resource>
which I parse into a List<CString>, where CString.java is:
public class CString {
public String name;
public String desc;
@Override
public String toString() {
return "CString {!name: " + name + " !body: " + body + "}\n";
}
}
I’ve tried using a DocumentBuilder, and, when that didn’t work right, just a plain SaxParser. No matter how I go about it, though, when I go back through my CStrings, I have a few where the body actually contains unparsed tags of different parts of the document. For example, printing out my aforementioned List<CString> might yield something like:
[ CStrings for 900-919 ...
, CString {!name: 920-name !body: Document Shredder}
, CString {!name: 920-desc !body: irritating cats.</string>
<string name="935-cat">office,tool</string>
<string name="936-name">Black Metal Filing Cabinet</e. Remember, hackers can't access the documents if you've shredded the drives.}
, CString {!name: 920-cat !body: office,appliance}
, CString {!name: 921-name !body: Plastic Ladle}
, CString {!name: 921-desc !body: This is a big plastic ladle, ideal for soups and sauces.}
, CString {!name: 921-cat !body: kitchen,utensils}
... CStrings for 922-934 ...
, CString {!name: 935-name !body: Green Laser Pointer}
, CString {!name: 935-desc !body: A High-Powered green laser pointer, ideal for irritating cats.}
, CString {!name: 935-cat !body: office,tool}
, CString {!name: 936-name !body: Black Metal Filing Cabinet}
, CString {!name: 936-desc !body: A large, metal cabinet (black) built to store hanging file folders.}
, CString {!name: 936-cat !body: office,storage}
... CStrings for 937-994
]
In the SaxParser version of my code, I had the following characters method in my DefaultHandler:
public void characters(char ch[], int start, int length) throws SAXException {
String value = new String(ch, start, length).trim();
switch(currentQName.toString()) { // currentQName is a StringBuilder that holds just the current xml element's name
case "string":
if (value.contains("</string")) {
System.err.println("!!! Parse Error !!! " + value);
}
}
which, as you might have guessed, yields:
!!! Parse Error !!! irritating cats.</string>
<string name="935-cat">office,tool</string>
<string name="936-name">Black Metal Filing Cabinet</e. Remember, hackers can't access the documents if you've shredded the drives.
I wouldn’t normally ask a question this esoteric, especially when I can’t provide the concrete data and code, but no amount of Googling seems to yield anything that I’ve been able to nail down, and of course the code is not throwing (or suppressing) any exceptions.
The one thing I have noticed is that when there’s wrong data, as seen in the above CString for 920-desc, the wrong data in this case was 138 characters long and, not coincidentally, the good data picks up exactly 139 characters into what it should be. Which makes me think it’s some kind of buffer problem. However, whether I let DocumentBuilder manage the buffers, or I try to manage them more manually with a straight SaxParser, I still get the exact same wrong text in the same places every single time. Finally, I don’t ever notice any wrong text when dealing with the shorter strings, name and cat, which I think points to char buffer issues, too.
Any ideas would be helpful!
Almost certainly, you don’t have well-formed XML (your comments about absolutely not being allowed to change the source system are a bad omen, but you’re hardly alone in that predicament.)
Have a look at this question How to parse badly formed XML in Java?
If I were you, I’d use raw string manipulation and/or regular expressions to either extract the data directly or fix it up to be well formed XML. JAXB is much nicer for handling XML in Java by the way (but still needs it to be well formed)