[T.net] Turbotracker foutje?

[jelmervos]

(Ben ik weer met mijn turbotracker vragen! )

Naar aanleiding van dit topic heb ik besloten deze te openen, omdat er volgens mij (en nog een paar) een foutje zit in de Tweakers.net turbotracker.

Het gaat in het kort hierom: als ik met de PHP XML parser die turbotracker parse kom ik dit probleem tegen:

code:

  <id>18149</id> 
  <titel>nVidia Personal Cinema hands-on preview</titel> 
  <editor>Robin Evers</editor> 
  <categorie>Hardware</categorie> 
  <bron>GamePC</bron> 
  <link>http://www.gamepc.com/reviews/hardware_review.asp?review=personalcinema&page=1&mscssid=&tp=</link> 
  <tijd>28-08-2001 16:19</tijd> 
  <timestamp>999008370</timestamp> 
  <reacties>10</reacties>

Geeft mij:

code:

ID: 18149
TITEL: nVidia Personal Cinema hands-on preview
EDITOR: Robin Evers
CATEGORIE: Hardware
BRON: GamePC
LINK: http://www.gamepc.com/reviews/hardware_review.asp?review=personalcinema
LINK: &
LINK: page=1
LINK: &
LINK: mscssid=
LINK: &
LINK: tp=
TIJD: 28-08-2001 16:19
TIMESTAMP: 999008370
REACTIES: 10

Ik maak gewoon gebruik van de standaard XML functie's in PHP.

[mbravenboer]

Als ik de problemen met de tracker zo zie, vermoed ik dat hij niet gemaakt wordt door middel van een DOM, maar door het plakken van stringetjes. Misschien is het handig om dat te veranderen? Degelijke DOM implementaties houden met deze toestanden over het algemeen rekening .

[jelmervos]

Je hebt misschien gelijk, hetzelfde werkt namelijk onder Delphi goed (en daar maak ik gebruik van de MSXML parser). Maar het moet toch onder PHP ook kunnen werken.

Het hoofd onderdeel van mijn PHP code ziet er als volgt uit:

PHP:

<?
$xml_file = "http://www.tweakers.net/turbotracker.dsp";

$xml_parser = xml_parser_create("ISO-8859-1");
xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, true);
xml_parser_set_option($xml_parser, XML_OPTION_TARGET_ENCODING, "ISO-8859-1");
xml_set_element_handler($xml_parser, "startElement", "endElement");
xml_set_character_data_handler($xml_parser, "characterData");

if (!($fp = fopen($xml_file, "r"))) {
    die("Could not open $xml_file for parsing!\n");
}

while ($data = fread($fp, 4096)) {
    xml_parse($xml_parser, $data, feof($fp));
}

xml_parser_free($xml_parser);
?>

Niks mis mee toch?

[mbravenboer]

jelmervos: Niks mis mee toch?

Jouw implementatie is volgens mij prima. Ik bedoelde dat dee XML file van de turbotracker via een DOM aangemaakt zou moeten worden... Een DOM implementatie converteert strings over het algemeen zo dat zulke problemen worden opgevangen .

[jelmervos]

Aha, oke. We wachten af.

[mbravenboer]

jelmervos: en daar maak ik gebruik van de MSXML parser

Dan is de MSXML parser dus niet XML compatible en te vergevingsgezind. Het gaat weer in de richting van 'ach, ik snap wel wat die domme XML schrijver bedoelt...'. Totdat ik dat niet bedoelde gaat dat ook uitstekend .

[jelmervos]

Zoiets ja. Ik dacht dat XML altijd heel strak was. Alles zat vast aan bepaalde regels, en als je dit maar iets anders doet is het geen geldige XML meer.

[mbravenboer]

jelmervos: Zoiets ja. Ik dacht dat XML altijd heel strak was. Alles zat vast aan bepaalde regels, en als je dit maar iets anders doet is het geen geldige XML meer.

Precies . Dat is dus ook het directe voordeel van XML en XHTML. Het is veel makkelijker om er standaard tools voor te schrijven. Browsers zouden veel eenvoudiger kunnen zijn als ze alleen correcte XHTML zouden hoeven te accepteren. Helaas is alles op het web platte ongecompileerde tekst wat iedereen kan aanleveren/intikken. Dat klopt dus niet altijd...

[Femme]

De turbotracker wordt gewoon als een stuk XML-achtige tekst uitgepoept. Oorspronkelijk was het niet de bedoeling dat-ie XML compliant was totdat iemand er een XML headertje boven wilde hebben. Sindsdien is de ellende begonnen.

[mbravenboer]

Femme: Sindsdien is de ellende begonnen.

Ach, het is een kleine moeite om hem helemaal compatible te maken toch? Het komt bovendien iets professioneler over .

[Verwijderd]

Op dinsdag 28 augustus 2001 23:08 schreef mbravenboer het volgende:
Ach, het is een kleine moeite om hem helemaal compatible te maken toch? Het komt bovendien iets professioneler over .

Dat bedoel ik, blijven zeuren...

[tomato]

Op dinsdag 28 augustus 2001 23:08 schreef mbravenboer het volgende:
Ach, het is een kleine moeite om hem helemaal compatible te maken toch? Het komt bovendien iets professioneler over .

Inderdaad, op deze manier is het eigenlijk net niks...

[jelmervos]

Op dinsdag 28 augustus 2001 22:57 schreef Femme het volgende:
De turbotracker wordt gewoon als een stuk XML-achtige tekst uitgepoept. Oorspronkelijk was het niet de bedoeling dat-ie XML compliant was totdat iemand er een XML headertje boven wilde hebben. Sindsdien is de ellende begonnen.

Geeft het zoveel ellende?
Ik vind dat als je zo'n bestand bestempeld als XML dat ie dat dan ook volledig volgens de XML standaarden moet zijn.

Maar moet ik nou zelf een oplossing inbouwen, of wordt de zogenaamde XML een echte XML?

[Femme]

hmm ja, wat is de oplossing?

[GaMeOvEr]

De oplossing is om hem helemaal XML te maken.

[jelmervos]

Misschien es even doorlezen ergens (www.w3.org/xml?) hoe het precies zit met XML en dit soort 'vreemde' tekens, zodat de XML een echte XML wordt.

[mbravenboer]

Als je hem via een Document Object Model maakt worden speciale tekens meestal automatisch geescaped. Dat zou je dus kunnen doen. Je kan ook de & in urls vervangen door & die veroorkaken immers de problemen.

[Femme]

De & wordt in het script al vervangen door een & amp; dus ik vind 't erg vreemd dat die error hierboven voorkomt. Het lijkt me dat dit met & amp; niet zou moeten voorkomen.

[mbravenboer]

Femme: De & wordt in het script al vervangen door een & amp; dus ik vind 't erg vreemd dat die error hierboven voorkomt. Het lijkt me dat dit met & amp; niet zou moeten voorkomen.

Yep inderdaad! Ik verkeerde in de veronderstelling dat er een zuivere & in de file stond. Het probleem ligt nu dus duidelijk aan de gebruikte XML parser. Werd de & ook al vervangen toen Jelmervos het melde?

Hier kan je trouwens zien dat dat ding toch al niet echt lekker blijkt te werken.

Thanks voor je reply trouwens .

[mbravenboer]

Ik heb hem nog even door een (voor zover ik weet) betrouwbare XML parser gehaald met goede validatie: Xerces van Apache en die was het volledig met de file eens .

[Femme]

Op vrijdag 31 augustus 2001 03:30 schreef mbravenboer het volgende:

[..]

Yep inderdaad! Ik verkeerde in de veronderstelling dat er een zuivere & in de file stond. Het probleem ligt nu dus duidelijk aan de gebruikte XML parser. Werd de & ook al vervangen toen Jelmervos het melde?

Dat moet er al een hele tijd in hebben gezeten. Ik wilde het gaan fixen maar dat bleek niet nodig te zijn .

[mbravenboer]

Femme: Dat moet er al een hele tijd in hebben gezeten. Ik wilde het gaan fixen maar dat bleek niet nodig te zijn .

Hum suf zeg, voortaan dus niet de post maar de bron bekijken voordat ik ga zeuren .