[xml] quote probleem met parsen

[killercow]

Ik heb een leuke XML parser gebouwd die (xml/(x)html) en allerlei ranzige afwijkingen moet kunnen parsen,

Nu kan hij vreselijk veel wazige dingen wel redelijk oplossen, maar ik zit met een vrij groot probleem.

Als ik een document parse met een tag die een argument heeft die tussen de quotes per ongeluk nog een quote heeft kan ik niet zinnig bepalen wat ik moet doen.

Mozilla en IE kunnen het, dus er moet een soort van "regeltje" voor zijn.

De kapotte xml is bijvoorbeeld:

code:

<tag argument="value" argument_two="value with " an extra quote" />

Of natuurlijk een van de "valide" vormen waarin de tag niet self closing is, de laatste quote ook nog eens een = als voorlopend character heeft, of waar er maar een woord voor de laatste quote staat.

Wat is een zinnige oplossing om alsnog de tag juist te kunnen afsluiten?
Ik loop er al een tijdje mijn hoofd op te breken, en de quotes beginnen met nu toch wel behoorlijk te irriteren

Een van de oplossing is denk ik een soort van sanity check bijhouden, die bij het vinden van hele vreemde zooi (argumenten zonder =, of value), hele lange argument values, met daarin /> of > chars, de boel probeert op de lossen door een of quote terug de quote te escapen, en zo een betere resultaat probeert te krijgen.

Een andere oplossing is tot het einde van het document parsen, en dan besluiten in welke tag de nesting mis is gegaag (geen end-tag voor die tag,maar wel end-tags voor de parents van die tag.)

Beide zijn mij eigenlijk veel te fuzzy, en het implementeren ervan lijkt me dan ook geen goed doen voor de parser (zowel qua code, of als resultaat)

[André]

Ik denk dat je gewoon de 2de " moet gebruiken als afsluitende ". Dan hou je dit over an extra quote" en die negeer je dan maar of laat je een foutmelding geven na het parsen.

[ Voor 16% gewijzigd door André op 03-02-2006 17:02 ]

[RM-rf]

wat dacht je van de speciale characters in een attribuut escapen:

XML:

<tag argument="value" argument_two="value with " an extra quote" />

code:

Character   Predeclared Entity
   &           &
   <           <
   >           >
   "           "
   '           '

http://www.xmlnews.org/docs/xml-basics.html

edit
of ik begrijp het misschien verkeerd... je wilt juist een custom parser om juist niet validerende en slechte xml toch te kunnen parsen?
Tja, volgens mij is dat gewoon niet mogelijk, en dat moet je _juist_ niet willen, het is een bewuste keuze om niet validerende XML _niet_ te parsen, juist om te voorkomen dat er ruimte is voor allerlei wver doowerkende 'interpretatie-fouten' en 'loose' data

[ Voor 81% gewijzigd door RM-rf op 03-02-2006 17:11 ]

[grhmpf]

Het concept van een parser die een standaard formaat wat niet aan de standaard voldoet moet parsen vind ik persoonlijk al erg eng hoor

[crisp]

Als XML is dat niet te parsen en zal je een mallformed error moeten geven, als HTML wel, 'an', 'extra' en 'quote' worden dan als attributen gezien zonder value

Mozilla en IE kunnen het, dus er moet een soort van "regeltje" voor zijn.

De meeste XHTML pagina's worden gewoon als text/html geserveerd en dus door browsers ook als HTML behandeld

[ Voor 39% gewijzigd door crisp op 03-02-2006 17:47 ]

[MBV]

Wat je zou moeten doen is vrij lastig, lijkt me:

code:

<tag attribute_1=" blaat "foutje " attribute_2="nog erger =" >

je ziet natuurlijk het begin van een tag. Wat je zou kunnen doen, is tellen hoeveel quotes je tegenkomt tussen < en >. Vervolgens moet je proberen om alle attribute-tags te vinden,+ dus alles wat niet tussen " staat en gevolgd word door een = zonder andere tekens dan een spatie. Als je hebt gevonden dat het aantal " klopt, dan hoef je je geen zorgen te maken. Klopt dat niet, dan kan je de moeilijkere regex starten .
Bij mijn voorbeeld zou je als volgt kunnen zoeken: tag gevonden, 1e attribuut gevonden. So far so good. Daarna 3 quotes zonder een =-teken: dat zal de fout wel zijn. Notification geven, en verder gaan

[Bint]

maar wat nou als dit de code is?

code:

<tag attribute_1=" song  "foutje " attribute_2="tag team  - whoomp there it is=" >

dan zal ie die 2e tag ook als een tag herkennen, terwijl het geen tag is..

(bedenk me net wat voor lekkere keuze ik heb gemaakt )

[ Voor 9% gewijzigd door Bint op 03-02-2006 18:42 ]

[killercow]

tjah, inderdaad dat zijn nu precies mijn problemen, wat als de code van Bintje de juiste code is.

De heel tag skippen is ook geen probleem, maar ja, waar vindt ik het einde?

Want ook een /> of > kan in een argument value staan.

Ik wil inderdaad een parser hebben die 99% van de beschikbare paginas op het internet kan parsen.

Hij heeft bjina nergens echt problemen mee, maar dit is gewoon een theorietisch moeilijk probleem.

Ik dacht zelf aan een hint systeem waarbij ik kijk welke argumenten er volgens een bepaalde DTD beschkbaar zijn in een tag, als er dan een " gevonden wordt, en hij daarna een niet valide argument tegen komt (of malformed code), dan ignoren we die quote in de hoop nog in de argument value te zitten.

(ik gok dat IE en Gecko zo iets doen., zal eens testjes doen met custom DTD's)

[crisp]

Ik wil inderdaad een parser hebben die 99% van de beschikbare paginas op het internet kan parsen.

Waarom staat er dan XML in de topictitel? je hebt het blijkbaar gewoon over een HTML/SGML parser...
En waarom zou je dan zelf zo'n parser willen bouwen als de meeste talen zelf al een optie hebben om vanuit HTML een DOM-tree te bouwen?

Overigens halen browsers de DTD niet op (zijn geen validating parsers wat dat betreft); meestal zit dat soort informatie al hardcoded ingebakken. Het enige wat een browser doet met de DTD is beslissen of het in quirksmode of standards compliant mode moet renderen.
Welke parser er gebruikt wordt (een XML-parser of HTML-parser) wordt bepaalt adhv het mime-type.

Note dat HTML geen defined error-correction heeft, maar er wordt wel op een bepaalde manier error-correction gedaan. Daar is dus geen standaard voor maar browser-vendors nemen het over het algemeen redelijk conform van elkaar over (komt er op neer dat de manier van IE wordt geimiteerd en dat is meestal reverse-engineering werk).
HTML 5 zal hoogstwaarschijnlijk wel error-correction gaan definieren.

[ Voor 63% gewijzigd door crisp op 04-02-2006 18:25 ]

[MBV]

Wat doet het mozilla-team eigenlijk? Waarschijnlijk vinden ze het niet erg om het goede stukje code aan te wijzen, als je ze uitlegt wat je zoekt

[killercow]

Crisp, yup inderdaad, een sgml parser, maar de basis hiervan lijkt me een robuuste xml parser.

De quotes zijn inmiddels opgelost, en ik heb nog een bugje in firefox gevonden.
(de source view parsed de quotes anders dan de dom viewer aangeeft.)

Het enige wat nog een probleem geeft s het volgende:

code:

<tag argument="value with an evil " quote=" />

Maar ja dan vraag je er ook om
Heb gister enkele duizenden sites gespiderd, en geen noemenswaardige parser problemen gevonden. Parsen gaat ook lekker snel, dus ik denk dat ik er wel zo'n beetje ben.

Het zelf bouwen is om de volgende redenen, hij is nu in php geimplementeerd, zodat hij precies kan doen wat er nodig is, (en niet crachst op lompe veelvoorkomende probs).
Als hij dan werkt gaat hij over naar c++ of c, zonder dat ik meteen ruzie krijg met andere libs met nieuwe problemen.
Daarnaast is het atijd goed om te leren van dit soort problemen,

Het mozilla team heeft de gecko repository een beetje een puinhoop gemaakt, ik kan iig hun implementatie niet vinden, (zelfde geld voor khtml), en eerlijk gezegt denk ik niet dat zij nog precies weten wat welke IF doet.

Nu nog een javascript parser en CSS parser bouwen, en ik hij's af

[ZroBioNe]

Ben wel benieuwd wat je er van wilt gaan maken?

[Justice]

Grappig, hopelijk ben je over 5 jaar klaar

[killercow]

Het is een stukje van de spider van GreenTides.net

Het doet 2 dingen,
1) Spideren van het web zodat ik een goede dataset heb als benchmark
2) Spideren van adverterende sites zodat ik on-the-fly kan bepalen welke stukken van de website echt tekst zijn, welke relevant zijn, en welke keywords er gelinkt moet worden.
Om te bepalen welke keyword er relvant zijn wil ik natuurlijk een enorme bult tekst hebben, zodat ik kan bepalen welke woorden tot clustertjes horen, en welke er dus wel relevant zijn tot een bepaald domein/pagina, en welke er alleen vanwege de hoge opbrengsten op gedumpt zijn.

De css en javascript support moet er komen zodat ik kan zien wat de uiteindelijke DOM is, en niet voor het lapje gehouden kan worden door stukken invisible text te spideren of juist weg te halen voor de bezoeker.

[killercow]

Oke,

Weer behoorlijk wat stapjes opgelost.

Ik kan hem helaas nog niet online zetten (want er zou best nog een hardnekkige endless loop geriggerd kunnen worden), maar ik zou graag wat testjes doen, ik heb er gister via een spider weer 30.000 docs doorheen getrokken, en dat ging bijna helemaal vlekkeloos.

maar omdat er genoeg parsers geschreven zijn door mede-gotters, de volgende vraag: hebben jullie toevallig nog test files? (gewoon stukjes semi-brakke html/xml) welke bij jullie parsers problemen gaven?

[killercow]

oke, geen files van GOt dus, maar ik heb de volgende files geprobeerd:

http://www.xml.com/pub/a/Benchmark/exec.html

En deze worden zonder problemen geparst, de rec.xml (155.6kb) doet er op mijn mp2200 (singlethreaded) zo'n 3.06 seconden over. (de grotere files doen er gewoon x aantal maal langer over)
Nu zijn dit valid xml bestanden, met wel voldoende enge stukjes erin, maar ze zijn valid.
Als iemand alsnog typische foute xml contructies kent waardoor de gemiddelde parser z'n nekje breekt, let me know.

[ Voor 4% gewijzigd door killercow op 28-02-2006 11:44 ]