[XML] Tool om XML te controleren op illegale karakters

[Phoolie]

Ik zit met een probleem dat ik in mijn XML´s soms illegale karakters krijg, bijvoorbeeld de • & de ♂, wanneer ik deze aan een applicatie aanlever stopt deze er mee.

Nu zoek ik iets van een scriptje, het liefst via de commandline, die ik kan draaien voordat ik de bestanden aan de applicatie aanlever.

Ik ben wel een aantal online tooltjes tegen gekomen, maar daar moet je de bestanden (en/of de code) bestand voor bestand aanleveren, niet echt wenselijk aangezien het vaak meer dan 100 bestanden zijn.

[pedorus]

Ehm, dat zijn valide unicode characters, kennelijk voldoet de applicatie waar het naar toe moet niet aan de XML standaard - zie hier. Dus je moet dan uitvogelen wat er niet is toegestaan door die applicatie, en daar op zoeken in de bestanden. En dat kan gewoon met een tooltje als grep als je daar eenmaal uit bent.

[Hydra]

Geef je wel de juiste charset mee in je XML? Veel "zelfbouw" XML producten doen dat niet en sturen unicode mee terwijl de charset niet op utf-8 staat.

[Phoolie]

pedorus schreef op donderdag 12 december 2013 @ 12:56:
Ehm, dat zijn valide unicode characters, kennelijk voldoet de applicatie waar het naar toe moet niet aan de XML standaard - zie hier. Dus je moet dan uitvogelen wat er niet is toegestaan door die applicatie, en daar op zoeken in de bestanden. En dat kan gewoon met een tooltje als grep als je daar eenmaal uit bent.

Ik heb een "foute" XML even online laten valideren.

Bij http://www.xmlvalidation.com/ krijg ik de melding:

An invalid XML character (Unicode: 0xb) was found in the element content of the document.

En bij http://validator.w3.org/ krijg ik:

non SGML character number 11

Beide sites geven dus wel degelijk aan dat dit teken niet toegestaan is.

Hydra schreef op donderdag 12 december 2013 @ 13:05:
Geef je wel de juiste charset mee in je XML? Veel "zelfbouw" XML producten doen dat niet en sturen unicode mee terwijl de charset niet op utf-8 staat.

Ik ben zelf geen programmeur, ik kan een beetje code lezen en daar stopt het eigenlijk wel. Het betreft hier ook geen zelbouw applicatie, maar gewoon een betaalde applicatie die de XML genereert. Wanneer ik die XML open zie ik meteen op de eerste regel:

code:

<?xml version="1.0" encoding="utf-8" ?>

Die encoding is toch wat je bedoelde? Die staat iig op utf-8.

[pedorus]

Phoolie schreef op donderdag 12 december 2013 @ 13:18:
Ik heb een "foute" XML even online laten valideren.

Bij http://www.xmlvalidation.com/ krijg ik de melding:

[...]

En bij http://validator.w3.org/ krijg ik:

[...]

Beide sites geven dus wel degelijk aan dat dit teken niet toegestaan is.

Dat is een ander karakter dan die in de TS. Karakter 0xB, oftewel unicode karakter 11 (vertical tab) komt niet voor in de TS. Maar dit karakter is inderdaad niet toegestaan, dus dan ligt het aan de applicatie die de "xml" (wat dus eigenlijk geen xml is) genereert. Je kunt met een tooltje als sed deze karakters veranderen/verwijderen op de command line, of met grep kijken of dit specifieke karakter aanwezig is (grep -P "\v").

[Janoz]

Dan moet je de leverancier van die applicatie maar even een schop onder de kont geven. In UTF-8 is het Male teken niet 0X0B, maar 0xE2 0x99 0x82.

[Hydra]

Oftewel: de header staat goed maar de content is gewoon geen valid utf-8. Gebeurt enorm vaak en ik zou ook, in plaats van dit proberen op te lossen aan jouw kant, de leverancier van de data vertellen dat hun XML gewoon niet valid is.

Als je dit aan jouw kant gaat fixen blijf je bezig; ze hebben zelf niet door dat wat ze sturen meuk is.

[pedorus]

Omg, inderdaad, die gasten gebruiken een wel erg oude encoding (Wikipedia: Code page 437) en doen vervolgens alsof het utf-8 is..

[Hydra]

Waarschijnlijk zut die al in de DB stond die ze gewoon aan elkaar plakken tussen tags met een stringbuilder en het dan maar XML noemen. Heb ik al ZO vaak m'n hoofd aan gestoten dat ik daar heel rechtlijnig in ben geworden: als een XML parser ervan over z'n nek gaat is de oorzaak de source.

[Phoolie]

pedorus schreef op donderdag 12 december 2013 @ 13:42:
[...]

Dat is een ander karakter dan die in de TS. Karakter 0xB, oftewel unicode karakter 11 (vertical tab) komt niet voor in de TS. Maar dit karakter is inderdaad niet toegestaan, dus dan ligt het aan de applicatie die de "xml" (wat dus eigenlijk geen xml is) genereert.

Ok, sorry, ik had het bestand geopend met notepad en daar was het iig een ♂, ik had van de leverancier van de applicatie waar de xml's naar toe gaan ook doorgekregen dat het unicode karakter 11 was, maar aangezien het in die xml als ♂ stond ging ik er vanuit dat het dat teken betrof, foute aanname dus.

Je kunt met een tooltje als sed deze karakters veranderen/verwijderen op de command line, of met grep kijken of dit specifieke karakter aanwezig is (grep -P "\v").

Bedankt, ik ga eens kijken of ik daar verder mee kom. In jouw grep voorbeeld, daar is de "\v" de unicode karakter 11? Het andere karakter wat problemen geeft is unicode karakter 7, weet je daar ook de "code" voor? Of kan je me aangeven waar ik dit eventueel zelf kan vinden

Janoz schreef op donderdag 12 december 2013 @ 13:42:
Dan moet je de leverancier van die applicatie maar even een schop onder de kont geven. In UTF-8 is het Male teken niet 0X0B, maar 0xE2 0x99 0x82.

Volgens mij doen ze het wel goed, alleen nemen ze dat teken mee in de XML wat niet is toegestaan. De tekst komt namelijk over uit een Word document. In de applicatie zelf wordt dit dan weergegeven als een ♂ en die komt dan ook weer in de XML.

Hydra schreef op donderdag 12 december 2013 @ 13:44:
Oftewel: de header staat goed maar de content is gewoon geen valid utf-8. Gebeurt enorm vaak en ik zou ook, in plaats van dit proberen op te lossen aan jouw kant, de leverancier van de data vertellen dat hun XML gewoon niet valid is.

Als je dit aan jouw kant gaat fixen blijf je bezig; ze hebben zelf niet door dat wat ze sturen meuk is.

Je hebt ook helemaal gelijk, mijn oplossing moet ook een tijdelijke zijn. Aangezien we nu "op goed geluk" die bestanden aan moeten leveren en hopen dat het goed gaat en dan wanneer het fout gaat alle xml's nalopen. Dat is gewoon geen doen. Maar ik ga dit ook zeker doorgeven aan de leverancier.

[Phoolie]

pedorus schreef op donderdag 12 december 2013 @ 14:06:
Omg, inderdaad, die gasten gebruiken een wel erg oude encoding (Wikipedia: Code page 437) en doen vervolgens alsof het utf-8 is..

Kijk, dit is informatie waar ik iets mee kan. Maar dan toch nog even een vraagje. De waarde komt vanuit een Word document, wordt overgehaald uit een bladwijzer en in de applicatie gevuld, dan staat het karakter al foutief. De database is utf-8, dus daar zou het dan toch goed staan of kan ik dat niet zomaar aannemen?

[pedorus]

Het kan prima dat het in een van de eerdere stappen al mis is gegaan met encodings, en het dus ook fout in de database staat. De database kan veelal niet controleren of dit goed gaat, en doet dit dus ook niet.

Phoolie schreef op donderdag 12 december 2013 @ 14:19:
Bedankt, ik ga eens kijken of ik daar verder mee kom. In jouw grep voorbeeld, daar is de "\v" de unicode karakter 11? Het andere karakter wat problemen geeft is unicode karakter 7, weet je daar ook de "code" voor? Of kan je me aangeven waar ik dit eventueel zelf kan vinden

Dat is \a (komt van http://perldoc.perl.org/perlre.html , ik weet uit mijn hoofd dat 7 het bell karakter is).

Maar ik denk dat iets als de command line util iconv (encodinglijst) handiger is, dan kun je het gewoon omzetten. Even er van uitgegaan dat het inderdaad CP437 is, wat niet met zekerheid kan worden gezegd, het kan prima een van de andere zijn. Het is zelfs prima mogelijk dat het niet goed te krijgen is, omdat er 2 dingen naar hetzelfde gemapt zijn, wat niet ongedaan te maken is. Klassieker: http://www.joelonsoftware.com/articles/Unicode.html

[Janoz]

Phoolie schreef op donderdag 12 december 2013 @ 14:19:
Volgens mij doen ze het wel goed, alleen nemen ze dat teken mee in de XML wat niet is toegestaan. De tekst komt namelijk over uit een Word document. In de applicatie zelf wordt dit dan weergegeven als een ♂ en die komt dan ook weer in de XML.

Als de applicatie het als een ♂ weergeeft en het in het word document ook als een ♂ staat dan is het toch echt een probleem van de applicatie dat dit vervolgens als een 0x0B wordt weggeschreven. Zal wel weer 1 van de vele applicaties zijn die 'UTF-8 in name only' is. Wat de applicatie wel had moeten doen was bij de import van het word document de juiste conversie toepassen, of de input niet accepteren.

Ik zou heel voorzichtig zijn met dit op proberen te lossen met vervangscriptjes. Zolang de applciatie daadwerkelijk met een vaste encoding werkt is het nog te doen (door achteraf die transformatie te doen die de applciatie eigenlijk vooraf zou moeten doen), maar als de applicatie maar wat doet (ie de inhoud inlezen zonder encoding, intern werken met een encoding waarbij de VT als het Male symbool weergegeven wordt, en bij de output net doet alsof het UTF-8 is) dan is het onbegonnen werk.

[ Voor 24% gewijzigd door Janoz op 12-12-2013 15:40 ]

[Janoz]

Sorry, ik had per ongeluk op de verkeerde knop gedrukt.

[Phoolie]

Janoz schreef op donderdag 12 december 2013 @ 15:36:
[...]

Als de applicatie het als een ♂ weergeeft en het in het word document ook als een ♂ staat dan is het toch echt een probleem van de applicatie dat dit vervolgens als een 0x0B wordt weggeschreven.

Nee, ik heb het vast verkeerd uitgelegd, maar dat ♂ teken staat niet in het Word document. Daar is het gewoon een (ik dacht) regeleinde. Het probleem is alleen dat het originele document (op een later tijdstip) corrupt is geraakt en dat dit de enige keer was dat het voorkwam met het ♂ teken. Maar ik ga dat nog proberen na te bootsen.

Voor het bell teken, deze is in het Word document het eindteken van een cell en dit wordt in de applicatie na het overhalen getoond als een •.

[RobIII]

Phoolie schreef op donderdag 12 december 2013 @ 13:18:
Ik ben zelf geen programmeur, ik kan een beetje code lezen en daar stopt het eigenlijk wel.

Phoolie schreef op donderdag 12 december 2013 @ 16:07:
Nee, ik heb het vast verkeerd uitgelegd

With all due respect, en ik zeg dit écht niet om je af te katten, maar laat hier alsjeblieft een wél-programmeur naar kijken. Zoals je in de, reeds eerder aangehaalde, The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) kunt lezen komt er wel wat meer bij kijken en dan hebben we 't nog niet gehad over collaties van databases en allerlei andere "tussenlagen" die in 't hele proces (mogelijk) betrokken zijn.

Met jouw uitleg (hoewel je zeker weten je best doet!) in dit topic gaat er nogal 't een-en-ander "lost in translation" en uiteindelijk heb je dan (vette) kans dat je 't alleen maar erger maakt dan beter. Als ik je dus een persoonlijk, welgemeend, advies mag geven: drop de zaak en handig 't over aan iemand die hier meer kennis van heeft; doe je dat niet dan lijkt 't straks voor dit specifieke probleem dat je nu tegenkomt mogelijk opgelost maar blijkt "down the road" over een maand of 6 opeens dat je al die tijd al met de verkeerde encoding je zakies aan 't importeren bent en dat al je data sinds die "fix" die je mogelijk ontdekt m.b.v. dit topic FUBAR is.

Je ziet in dit topic al hoe snel 't fout kan gaan.

Alternatief is dat je je écht inleest in de materie (en dat konijnenhol gaat diep, er zijn zat programmeurs die 't niet eens (goed) begrijpen ) waardoor er minder "lost in translation" gaat in dit topic en zodat je gericht kunt zoeken naar de oorzaak/probleem en onderbouwd een goede keuze voor de juiste oplossing kunt maken.

[ Voor 13% gewijzigd door RobIII op 12-12-2013 17:06 ]

[Gomez12]

In wezen heb je 2 problemen waarbij probleem 1 een gevolg is van probleem 2.
1 : Je hebt invalid xml
2 : Iemand zit te kl*ten met character sets.

In wezen is optie 1 wel te testen met een tool als xmlstarlet (en een xsd oid wil je het echt goed doen) of een simpele sax-parser die gewoon door het bestand loopt, maar daarna begint het gezeur. Dan heb je na enige tijd wellicht een valide xml (met wat tekens vervangen etc), maar of de data dan goed is of dat er enkel wat replaces zijn uitgevoerd op de invalid xml-tekens,tja dat is dan even de grote vraag.

Ik zou zeggen : Voer sowieso stap 1 door (dan kan je in ieder geval het probleem pinpointen) en zeg tegen je leverancier dat hij gewoon een xmlwriter moet gebruiken ipv stringconcatenation zodat het opgelost wordt (zeg tegen je leverancier dus ook niet : Dit of dat teken is fout, zeg gewoon : Je xml is invalid fix it!!!)

[RobIII]

Gomez12 schreef op donderdag 12 december 2013 @ 23:31:
1 : Je hebt invalid xml
[...]
Dan heb je na enige tijd wellicht een valide xml (met wat tekens vervangen etc)

Dat betwijfel ik dus...

[pedorus]

Het probleem is dat een valide xml-bestand niet hoeft te betekenen dat de inhoud van de tekens ook klopt. Het kan prima zijn dat er bepaalde karakters stuk zijn geraakt in de stappen daarvoor, waardoor je eigenlijk toch troep hebt. Een test hiervoor is een set karakters door alle stappen te halen met daarin veel bijzondere tekens. Denk hierbij aan !Iñtërnâtiônàlizætiøn¡, maar vergeet ook het € teken en eventuele symbolen als ♂ en ╪ niet, en eventueel karakters als 𪛖, 形 en 𫠝. Dan kun je kijken of die testdata goed in de database en vervolgens in het xml-bestand komt. (Zo is deze post ook al gelijk een test voor de karakterhandling van dit forum..)

[Gomez12]

RobIII schreef op donderdag 12 december 2013 @ 23:34:
[...]

Dat betwijfel ik dus...

Ach, gooi hem door een xml-parser heen. Replace alle tekens in de meldingen met spaties (oid) en herhaal dit totdat je uiteindelijk een valide xml hebt.

Een xml valide maken is nou niet echt rocketscience hoor.

[Sebazzz]

Is preprocessen geen optie? XML Tekst inlezen alszijnde charset X en opslaan als Y.

[Phoolie]

RobIII schreef op donderdag 12 december 2013 @ 16:58:
[...]


[...]


With all due respect, en ik zeg dit écht niet om je af te katten, maar laat hier alsjeblieft een wél-programmeur naar kijken.
[..]

Ik was ook zeker niet van plan om het in de software zelf op te gaan lossen, ik probeer alleen zelf een klein stukje probleem analyse te doen, aangezien ik uit ervaring weet dat wanneer je dat niet doet, dan gaat er een eeuwigheid overheen voordat ze er überhaupt mee beginnen en gaan ze eerst 100 keer uitsluiten dat het geen gebruikersfout is.

Gomez12 schreef op vrijdag 13 december 2013 @ 10:27:
[...]

Ach, gooi hem door een xml-parser heen. Replace alle tekens in de meldingen met spaties (oid) en herhaal dit totdat je uiteindelijk een valide xml hebt.

Een xml valide maken is nou niet echt rocketscience hoor.

Dat is idd wat ik wil doen, puur als tijdelijke oplossing.

[pedorus]

Ik bedenk me trouwens dat het foutdetectietooltje xmllint nog ontbreekt in dit topic, kijk bijvoorbeeld naar de optie --recover. Enkel dan hou je dus beroerde input omdat bepaalde karakters stuk gaan.

[Phoolie]

Ja, maar de illegale karakters mogen ook gewoon verwijderd worden uit de xml, dus dat is geen probleem.

Ik ga vanmiddag eens even kijken welk van de tooltjes het best te gebruiken is. Het is iig de bedoeling dat ik het tooltje gewoon aan het huidige export script (cmd file) toe kan voegen voordat de bestanden op de juiste locatie neergezet worden.

[RobIII]

Gomez12 schreef op vrijdag 13 december 2013 @ 10:27:
Ach, gooi hem door een xml-parser heen. Replace alle tekens in de meldingen met spaties (oid) en herhaal dit totdat je uiteindelijk een valide xml hebt.

Een xml valide maken is nou niet echt rocketscience hoor.

Behalve dat dit natuurlijk een last-resort oplossing paardenmiddel is (dat mogelijk wel werkt, dat beweer ik ook niet) en mogelijk zaken alleen maar erger maakt: ik betwijfel dus of de XML wel invalid is. Wie zegt dat TS niet gewoon de file opent met een editor die de verkeerde encoding aanneemt ofzo? Ik zou beginnen bij 't begin en éérst zorgen dat er geen (als in: nul) misverstanden zijn over welke encoding 't zou moeten zijn, welke encoding dan (mogelijk foutief) gebruikt zou zijn om op te slaan en van daar uit verder werken. Er zijn, naar mijn zin, gewoon teveel onbekende of onduidelijk variabelen in 't spel.

[ Voor 6% gewijzigd door RobIII op 13-12-2013 11:14 ]

[Gomez12]

Phoolie schreef op vrijdag 13 december 2013 @ 11:08:
Ja, maar de illegale karakters mogen ook gewoon verwijderd worden uit de xml, dus dat is geen probleem.

Ik ga vanmiddag eens even kijken welk van de tooltjes het best te gebruiken is. Het is iig de bedoeling dat ik het tooltje gewoon aan het huidige export script (cmd file) toe kan voegen voordat de bestanden op de juiste locatie neergezet worden.

Let er wel op dat je nu simpelweg onbekende data gaat genereren.

Je data is verkeerd en door een kleine subset van de verkeerde gegevens is je xml invalid. Fix je deze gegevens dan heb je dus wel een valide xml, maar je data bevat 99% zeker gewoon nog steeds fouten omdat je niet alles gefixed hebt.

[Phoolie]

RobIII schreef op vrijdag 13 december 2013 @ 11:12:
[...]

Behalve dat dit natuurlijk een last-resort oplossing paardenmiddel is (dat mogelijk wel werkt, dat beweer ik ook niet) en mogelijk zaken alleen maar erger maakt: ik betwijfel dus of de XML wel invalid is. Wie zegt dat TS niet gewoon de file opent met een editor die de verkeerde encoding aanneemt ofzo?

Daar mag je over twijfelen, maar mag ik er dan ook aan twijfelen of jij wel al mijn reacties hebt gelezen? En dan bedoel ik de volgende:
Phoolie in "[XML] Tool om XML te controleren op illegale karakters"

Daar staat dus dat ze invalid zijn. Tevens is dit mij ook verteld door de leverancier van de applicatie waar de XML's aan aangeleverd worden en mijn contactpersoon daar is wel een programmeur.

Gomez12 schreef op vrijdag 13 december 2013 @ 11:56:
[...]

Let er wel op dat je nu simpelweg onbekende data gaat genereren.

Je data is verkeerd en door een kleine subset van de verkeerde gegevens is je xml invalid. Fix je deze gegevens dan heb je dus wel een valide xml, maar je data bevat 99% zeker gewoon nog steeds fouten omdat je niet alles gefixed hebt.

Ja, dat weet ik, maar het zal dan ook een tijdelijke workaround zijn. De leverancier van de applicatie die de XML's genereert zal het probleem echt op moeten lossen.

[Gomez12]

Phoolie schreef op vrijdag 13 december 2013 @ 12:08:
[...]
Ja, dat weet ik, maar het zal dan ook een tijdelijke workaround zijn. De leverancier van de applicatie die de XML's genereert zal het probleem echt op moeten lossen.

Ik zou de tijdelijke workaround nog niet eens doen, gewoon invalid xml's detecteren en die niet inlezen.

Mijn ervaring is dat bedrijven die invalid xml's genereren veelal denken dat ze het wel even met wat replaces kunnen fixen en dat het dan goed lijkt, totdat iemand een jaar later bij 1 artikel oid een vreemd teken ziet wat gewoon verkeerde data is

[RobIII]

Phoolie schreef op vrijdag 13 december 2013 @ 12:08:
Daar mag je over twijfelen, maar mag ik er dan ook aan twijfelen of jij wel al mijn reacties hebt gelezen? En dan bedoel ik de volgende:
Phoolie in "[XML] Tool om XML te controleren op illegale karakters"

Daar staat dus dat ze invalid zijn.

Je laat alleen even achterwege dat je mogelijk al met de verkeerde encoding hebt ge-upload naar die sites (zij zullen ook een bepaalde encoding "aannemen", dat je file mogelijk al 1 of 2 keer met de verkeerde encoding is gelezen en daarna onder een andere encoding is opgeslagen etc.). Zoals ik al zei: er zijn nogal wat onbekende variabelen (en daarbij: wie zegt dat die sites alle encodings ondersteunen, of niet "blind" uitgaan van encoding X?)

Phoolie schreef op vrijdag 13 december 2013 @ 12:08:
Tevens is dit mij ook verteld door de leverancier van de applicatie waar de XML's aan aangeleverd worden

Wat is je verteld? Waar doel je op met "dit"? En je beseft ook dat elke keer als je zo'n bestand mailed of weet-ik-wat de inhoud (mogelijk) aangetast wordt wegens "interpretatieverschillen" in encodings e.d.?

Phoolie schreef op vrijdag 13 december 2013 @ 12:08:
mijn contactpersoon daar is wel een programmeur.

Ik zou ze niet graag de kost geven welke programmeurs geen benul hebben van encoding of alleen maar een klok-klepel verhaal kunnen ophangen. Daarmee zeg ik niet dat deze programmeur dat niet snapt, maar er zijn er zat.

Nogmaals: ik zeg niet dat je 't verkeerd hebt (noch die leverancier of programmeur daar) maar ik probeer paardenmiddel-workarounds te voorkomen en wat Gomez12 hierboven (en ik eerder ook al eens) aanhaalt: meten == weten, je kunt nu wel een fix vinden voor probleem X maar over 6 maanden blijkt dat daardoor Y fout gaat en ben je (mogelijk) nog verder van huis. Je kunt dan die paardenmiddelen natuurlijk niet blijven stapelen.

[pedorus]

RobIII schreef op vrijdag 13 december 2013 @ 12:18:
Je laat alleen even achterwege dat je mogelijk al met de verkeerde encoding hebt ge-upload naar die sites (zij zullen ook een bepaalde encoding "aannemen", dat je file mogelijk al 1 of 2 keer met de verkeerde encoding is gelezen en daarna onder een andere encoding is opgeslagen etc.). Zoals ik al zei: er zijn nogal wat onbekende variabelen (en daarbij: wie zegt dat die sites alle encodings ondersteunen, of niet "blind" uitgaan van encoding X?)

Toch is dat is zeer onwaarschijnlijk. Er is namelijk geen gangbare encoding conversion die een 0xB byte kan produceren uit een utf-8 bestand dat er geen bevat, aangezien er niet naar 0xB gemapt wordt in gangbare conversies, en 0xB ook geen continuation byte kan zijn geweest omdat daarvan de eerste bit altijd 1 is. Ok, er zijn wel gangbare encoding conversions die dit wel kunnen veroorzaken, maar die zouden ook strings als "<?xml version="1.0" encoding="utf-8" ?>" zelf hebben aangetast, en dat was dan opgevallen. Het is daarom vrijwel zeker dat het originele bestand al geen valide utf-8 xml was.

[RobIII]

pedorus schreef op vrijdag 13 december 2013 @ 13:56:
[...]

Toch is dat is zeer onwaarschijnlijk. Er is namelijk geen gangbare encoding conversion die een 0xB byte kan produceren uit een utf-8 bestand dat er geen bevat, aangezien er niet naar 0xB gemapt wordt in gangbare conversies, en 0xB ook geen continuation byte kan zijn geweest omdat daarvan de eerste bit altijd 1 is. Ok, er zijn wel gangbare encoding conversions die dit wel kunnen veroorzaken, maar die zouden ook strings als "<?xml version="1.0" encoding="utf-8" ?>" zelf hebben aangetast, en dat was dan opgevallen. Het is daarom vrijwel zeker dat het originele bestand al geen valide utf-8 xml was.

Misschien dat ik er langs lees ofzo, maar 0xB kan toch goed onderdeel zijn geweest van een multi-byte char en dus verkeerd geïnterpreteerd worden als single-byte char 0xB? En daarbij weet ik niet hoe goed "Theano GmbH" (xmlvalidation.com, waar die melding volgens TS vandaan komt) z'n zakies op orde heeft (hoewel ik w3.org daarentegen wel ken/vertrouw ) of dat de originele file geupload is geweest of dat er is ge-copy/paste (en dan heb je dus te maken met de encoding van de browser/pagina, je clipboard, de editor waaruit je copy/paste etc.). Maar goed, misschien mis ik wel de helft...

[ Voor 4% gewijzigd door RobIII op 13-12-2013 14:10 ]

[pedorus]

0xB kan geen multi-byte char (continuation byte) zijn geweest in de originele utf-8 byte stream, aangezien die altijd boven de 0X80 zitten. Er zijn wel gangbare encodings waarbij die 0xB byte wel een deel van een multi-byte character kan zijn, maar daar zou je dan niet "<?xml version="1.0" encoding="utf-8" ?>" als tekst terug in zien. En het lijkt mij ook sterk dat zo'n site opeens een exotische conversie doet.

Edit/NB: Dit verhaal gaat uit van een versimpeling met character=code point, je kunt in unicode ook een character van meer dan 1 code point hebben, zie hier bijvoorbeeld.

[ Voor 20% gewijzigd door pedorus op 13-12-2013 14:57 ]

[RobIII]

pedorus schreef op vrijdag 13 december 2013 @ 14:27:
0xB kan geen multi-byte char (continuation byte) zijn geweest in de originele utf-8 byte stream, aangezien die altijd boven de 0X80 zitten.

Goeiemorgen My bad. U heeft gelijk. Geen idee waarom dat even niet doordrong Ik heb 't denk ik gelezen als 0xXB waarbij X dus >= 8 is geweest in mijn hoofd

[ Voor 15% gewijzigd door RobIII op 13-12-2013 15:14 ]

[Phoolie]

Gomez12 schreef op vrijdag 13 december 2013 @ 12:16:
[...]

Ik zou de tijdelijke workaround nog niet eens doen, gewoon invalid xml's detecteren en die niet inlezen.

Mijn ervaring is dat bedrijven die invalid xml's genereren veelal denken dat ze het wel even met wat replaces kunnen fixen en dat het dan goed lijkt, totdat iemand een jaar later bij 1 artikel oid een vreemd teken ziet wat gewoon verkeerde data is

Ik heb het nu ongeveer op deze manier "opgelost", ik gebruik xmlstarlet om alle xmls's te vallideren, de invalid xml's laat ik naar een tekst bestandje schrijven en op basis van dat tekstbestandje laat ik dan al die invalid xml's verplaatsen naar een error directory.

Daarnaast heb ik bij de leverancier van de software van de invalid xml's een melding gemaakt.