[PHP/XML] XML header?

[xilent_xage]

Hoi,

Mijn website (LAMP) genereert XML bestanden, om te gebruiken in een andere applicatie. Helaas accepteert de applicatie mijn XML-bestanden niet en crasht bij importeren.

Om te debuggen heb ik een XML gegenereerd die 100% dezelfde XML genereert als een aangeleverd referentiebestand. En toch wil de applicatie mijn XML bestand nog steeds niet importeren. De inhoud van beide bestanden is dus exact gelijk, maar wel valt me op dat het voorbeeldbestand 2kb groter is dan mijn gegenereerde bestand.

Ik vermoed dus dat er sprake is van een header oid in het referentiebestand, die mijn gegenereerde XML niet heeft. Ik genereer mijn XML met de volgende code:

PHP:

header('Content-Type: text/xml; charset=utf-8');
header('Content-disposition: attachment; filename=' . $filename);
header('Content-Length: ' . strlen($output));
print_r($output);

Omdat ik de output exact hetzelfde wou hebben als het referentiebestand heb ik de XML content met een custom functie gegenereerd, is dus gewoon een string incl \t en \n.

Iemand een idee wat ik nog fout doe of hoe ik dit verder kan debuggen?

[RobIII]

99% zeker een BOM en/of incorrecte encoding (UTF8/16 zoiets). Haal je file(s) eens door een hex editor dan zie je het vast.

[ Voor 52% gewijzigd door RobIII op 12-11-2021 09:15 ]

[xilent_xage]

donders, volgens mij is dit al de 2e keer dat ik daarin trap. Ik had regels moeten aangeven met \r\n ipv \n en nu werkt het! bedankt.

[RobIII]

xilent_xage schreef op vrijdag 12 november 2021 @ 09:24:
donders, volgens mij is dit al de 2e keer dat ik daarin trap. Ik had regels moeten aangeven met \r\n ipv \n en nu werkt het! bedankt.

Ik weet niet wat je aan de ontvangende kant dan voor XML parser gebruikt maar... dit klinkt vrij gaar...

[xilent_xage]

klopt is ook een legacy applicatie

[thlst]

Waarom

PHP:

print_r($output);

ipv

PHP:

echo $output;

[Hydra]

Je moet sowieso nooit met de hand XML opbouwen maar daar netjes een bestaande library voor gebruiken. Heb in m'n carriere al twee keer enorm hard moeten lopen pushen bij leveranciers omdat ze invalid XML aanleverden. En waarom? Omdat een dev dacht dat je gewoon een beetje strings aan elkaar kon plakken tussen XML tags.

Dan heb je dit soort geneuzel ook niet.

[downtime]

Hydra schreef op zaterdag 13 november 2021 @ 13:49:
Je moet sowieso nooit met de hand XML opbouwen maar daar netjes een bestaande library voor gebruiken. Heb in m'n carriere al twee keer enorm hard moeten lopen pushen bij leveranciers omdat ze invalid XML aanleverden. En waarom? Omdat een dev dacht dat je gewoon een beetje strings aan elkaar kon plakken tussen XML tags.

Dan heb je dit soort geneuzel ook niet.

Het probleem is waarschijnlijk dat de applicatie die de bestanden moet lezen niet door TS is geschreven. En dan kun je nog zo mooi valide XML door een library laten maken maar als de ontvangende applicatie die valide XML niet "vreet" dan zul je moeten improviseren.

[Hydra]

downtime schreef op zaterdag 13 november 2021 @ 15:41:
Het probleem is waarschijnlijk dat de applicatie die de bestanden moet lezen niet door TS is geschreven. En dan kun je nog zo mooi valide XML door een library laten maken maar als de ontvangende applicatie die valide XML niet "vreet" dan zul je moeten improviseren.

HIj heeft het over het genereren van XML, niet lezen?

En ik heb het nooit meegemaakt dat een applicatie valid XML niet wil. Meestal is het omgekeerd omdat applicaties XML parsers gebruiken en die slikken invalid XML meestal gewoon niet. In theorie kan het, in de praktijk vind ik het wel wat onlogisch.

[downtime]

Hydra schreef op zaterdag 13 november 2021 @ 15:55:
[...]


HIj heeft het over het genereren van XML, niet lezen?

En ik heb het nooit meegemaakt dat een applicatie valid XML niet wil. Meestal is het omgekeerd omdat applicaties XML parsers gebruiken en die slikken invalid XML meestal gewoon niet. In theorie kan het, in de praktijk vind ik het wel wat onlogisch.

Hij heeft het over "een andere applicatie" die crasht bij het importeren van de XML berichten die zijn applicatie genereert.
Zoals ik het lees wil de ontvangende applicatie persé \r\n en niet \n als regeleinde zien. Beide mogelijkheden leveren valide XML op maar de ontvangende applicatie slikt maar één van die twee smaakjes. Als jouw XML library toevallig wel \n als regeleinde gebruikt heb je dus valide XML die toch niet wordt geslikt.

[Hydra]

downtime schreef op zaterdag 13 november 2021 @ 16:02:
Hij heeft het over "een andere applicatie" die crasht bij het importeren van de XML berichten die zijn applicatie genereert.

Ja, dan is het vrij logisch dat zijn XML invalid is toch?

Zoals ik het lees wil de ontvangende applicatie persé \r\n en niet \n als regeleinde zien.

Wat hij schrijft en wat er daadwerkelijk aan de hand is, zijn waarschijnlijk twee hele aparate zaken. Sowieso was dit een non-issue geweest als hij het niet met de hand zou doen. CR+LF en alleen LF is beiden gewoon toegestaan in XML dus de kans dat dit echt het issue is, is nihil.

[ Voor 40% gewijzigd door Hydra op 13-11-2021 16:07 ]

[downtime]

Hydra schreef op zaterdag 13 november 2021 @ 16:04:
[...]


Ja, dan is het vrij logisch dat zijn XML invalid is toch?

Als hij het probleem kan oplossen door Windows regeleindes door UNIX te vervangen dan is het probleem dus niet dat zijn XML invalid is want beide is valid XML.

[Hydra]

downtime schreef op zaterdag 13 november 2021 @ 16:11:
Als hij het probleem kan oplossen door Windows regeleindes door UNIX te vervangen dan is het probleem dus niet dat zijn XML invalid is want beide is valid XML.

Je kijkt te oppervlakkig. Het is veel waarschijnlijker dat hij een aanpassing heeft gedaan die perongelijk het echte probleem gefixt heeft, bijvoorbeeld die byte order mark waar Rob het over heeft.

Maar als jij het waarschijnlijker vindt dat het die CR+LF was: be my guest. Punt staat; het is beter dit soort shit niet met de hand te doen.