If the RDF content sink loads an RDF/XML file from a URL that contains UTF-8 characters, or if any of the "ID" or "about" attributes in the file contain non-ASCII characters, it will generate an incorrect graph. In the former case, it will incorrectly treat the UTF-8 encoded URL as ASCII. In the latter case, it will (apparently, by design) just ignore the ID or about attribute altogether an "make one up". (What was I thinking?) I'll attach a patch that fixes these issues. I discovered them while trying to debug some other random I18n bug.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
nhotta, momoi: another data point for I18n-lame RDF. Found this last night while working on that other AIM bug.
Looks dandy, r=rjc
Does your fix assume that RDF documents are always in UTF-8?
No. It assumes that by the time the document has reached the content sink, it has been promoted to UCS-2 from whatever character set encoding it was originally provided in. But, it *does* assume that the document's base URL is encoded in UTF-8. This is what we do now with all document, IIRC.
simple enough, sr=alecf
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified: 6/27/01 builds winNT 4, Linux rh6, Mac os9
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.