[php]Andere server, ander resultaat

[Tjolk]

Ik heb de volgende code:

PHP:

<?php
$data = implode("",@file("http://www.nl.bol.com/is-bin/INTERSHOP.enfinity/eCS/Store/nl/-/EUR/Endeca_BookBrowse-StartSearch?price=0&ISBN=9039520976"));
    preg_match_all('#Section=BOOK">(.*?)
      <table cellpadding="0" cellspacing="0" border="0">
        
          <tr><td colspan="2">#s',$data,$preboek);

    foreach ($preboek[1] as $tussenkey => $pre2boek)
        {
        preg_match ('#BOOK">(.*?)</a>#',$pre2boek, $boek);
        $titel = $boek[1];
        unset($boek);
        preg_match ('#\| (.*?)<br>#',$pre2boek, $boek);
        $auteur = $boek[1];
        unset($boek);
        }
        
    echo "Titel: $titel<br> Auteur: $auteur";
?>

Op mijn lokale XAMPP werkt dit perfect, ik krijg netjes de titel en auteur naar boven. Ik blij, uploaden naar host, krijg ik niets.
Dus maar even een print_r van $preboek gedaan. Lokaal gaat dat ook goed, maar op de server geeft het een lege array.

Ik dacht dat het misschien aan verschillende versies van PHP kon liggen, maar nee: beide draaien op 5.2.5 leert een phpinfo me.

Iemand een flauw idee waar dit aan kan liggen? Want mijn ideeën beginnen een beetje op te raken...

[djiwie]

Staat in de php.ini op je host allow_url_fopen wel op true?

[_Sunnyboy_]

idd, als het resultaat van file() leeg is dan levert die regexp natuurlijk ook een lege array op. Dump eens het resultaat van file()

[Tjolk]

Ja, die doet het wel. Bovenstaande is namelijk maar een brokje van de totale code, op dezelfde manier werk ik met DVD's en daar gaat het wel goed. Het resultaat van file() hier compleet dumpen weet ik niet of jullie daar blij van worden, da's 800 regels code...

Toch even gechecked: allow_url_fopen staat inderdaad aan.

Maar ik begrijp van jullie dat de code wel juist is? Want in dat geval moet ik hoe dan ook contact opnemen met de host.

[KabouterSuper]

ik zou eerst even je error_reporting aan zetten, en het apenstaartje voor "file" weghalen. Wellicht krijg je dan wat info in het geval van een fout.

[mjax]

Misschien zit het verschil in hoe regelovergangen gematched worden. Deze heb je nu nl. impliciet in je regexp opgenomen. Als je op Windows werkt met MS-DOS bestandsformaat (i.p.v. UNIX style), en je upload het bestand via FTP in ASCII mode, dan worden die regelovergangen op de server geconverteerd naar UNIX regelovergangen (\n). Windows regelovergangen zijn \n\r.

Je kunt daarom het best je regelovergangen in je regexp expliciet opnemen met \n. De output van file ontdoe je dan even met een str_replace() van eventuele \r.

[djiwie]

Hmm, dat lijkt mij ook het probleem te zijn (hier even getest en in Windows-formaat gaat het wel goed, in Unix-formaat niet).

[Tjolk]

mjax schreef op zaterdag 14 juni 2008 @ 11:40:
Misschien zit het verschil in hoe regelovergangen gematched worden. Deze heb je nu nl. impliciet in je regexp opgenomen. Als je op Windows werkt met MS-DOS bestandsformaat (i.p.v. UNIX style), en je upload het bestand via FTP in ASCII mode, dan worden die regelovergangen op de server geconverteerd naar UNIX regelovergangen (\n). Windows regelovergangen zijn \n\r.

Je kunt daarom het best je regelovergangen in je regexp expliciet opnemen met \n. De output van file ontdoe je dan even met een str_replace() van eventuele \r.

Ik snap je even niet. Ik zorg toch met de s-modifier dat de punt ook eventuele newlines matched?
Of bedoel je dat ik binnen het patroon de \n moet opnemen? Dat heb ik zo gedaan:

PHP:

    preg_match_all('#Section=BOOK">(.*?)\n
      <table cellpadding="0" cellspacing="0" border="0">\n
        \n
          <tr><td colspan="2">#s',$data,$preboek);

Maar dan doet-ie het zowel lokaal (idd Windows) als bij de host (idd Unix) niet.

Of begrijp ik gewoon verkeerd wat je bedoelt?

[user109731]

Hij bedoelt waarschijnlijk dat je het ook nog op 1 regel moet zetten (of de . operator gebruiken).

De regelovergangen in je regexp zijn idd verdacht. Kun je niet alles op 1 regel zetten en (.*?) ofzo gebruiken ipv de regelovergangen? Als dat werkt kun je het vervangen door een strakkere regexp voor het matchen van een newline, zoals \n.

[Voutloos]

Je hebt zelf een paar keer op enter geramd binnen die string. En welke chars bij die regelovergang horen verschil dus per OS. Zet dus zelf geen extra whitespace in die string en match whitespace gewoon op een flexibele manier.

mjax schreef op zaterdag 14 juni 2008 @ 11:40:
... Windows regelovergangen zijn \n\r.

Het is \r\n (en menig protocol rfc zegt duidelijk CRLF). 3 Varianten zuigt al genoeg, dus je hoeft niet je best te doen om met een 4e versie te komen. En dit is niet enkel tegen jou want er zijn hele volkstammen die steeds \n\r zeggen.

Je kunt daarom het best je regelovergangen in je regexp expliciet opnemen met \n. De output van file ontdoe je dan even met een str_replace() van eventuele \r.

Of je kijkt naar de context en ziet dat whitespace hier helemaal geen betekenis heeft en dus gewoon veel grover gematched kan worden.

Maar goed, als je naar de context kijkt, kan je ook zien dat hier een regex totaal onnodig is omdat er naar een setje constante strings gezocht moet worden. En als je geen keys nodig hebt in een foreach, kan je ook gewoon enkel for each($array as $value) schrijven, en als je de file niet als array wil hebben maar als enkel string kan je gewoon file_get_contents() doen.

[ Voor 36% gewijzigd door Voutloos op 14-06-2008 19:24 ]

[Tjolk]

Voutloos schreef op zaterdag 14 juni 2008 @ 19:17:
Je hebt zelf een paar keer op enter geramd binnen die string. En welke chars bij die regelovergang horen verschil dus per OS. Zet dus zelf geen extra whitespace in die string en match whitespace gewoon op een flexibele manier.

Ikke? Nee hoor... Komt zo uit de source van Bol.com. Was rechtstreeks Ctrl+c en Ctrl+v.

Maar goed, als je naar de context kijkt, kan je ook zien dat hier een regex totaal onnodig is omdat er naar een setje constante strings gezocht moet worden.

Da's wel nodig, aangezien het ingevulde ISBN-nummer in file() in de complete code variabel is (da's de input voor de gehele code welke 130 regels lang is maar ik jullie wilde besparen). Je komt dus afhankelijk van het ISBN-nummer op verschillende pagina's uit met andere auteurs en titels. Ik zou niet weten hoe ik dat er anders dan met regexps uit kan vissen.

Anywho: door de boel wat grover te matchen en een specifieker stuk als pattern te pakken, is de boel opgelost. Heb nu een fijn werkend systeem, en dat wilde ik nog even vertellen.

[ Voor 0% gewijzigd door Tjolk op 16-06-2008 12:01 . Reden: typo ]

[MueR]

offtopic:
heb je bol.com wel lief toestemming gevraagd om hun site leeg te trekken?

[Tjolk]

Nu niet specifiek, maar in het verleden (toen zowel Bol als wij nog een ander systeem hadden) hebben we wel contact hierover gehad. En het komt hun ook ten goede: de uiteindelijke output is een link (met referrel van het partnerprogramma van Bol) naar het boek of de dvd op Bol.com inclusief cover, titel en auteur/regisseur. Wat het script eigenlijk doet is het proces wat je handmatig via het partnerprogramma kunt uitvoeren automatiseren met een BBcode zodat de forumgebruikers het ook kunnen toepassen.

[ Voor 0% gewijzigd door Tjolk op 16-06-2008 12:01 . Reden: typo ]

[DataGhost]

SFB schreef op maandag 16 juni 2008 @ 11:37:
[...]
Ikke? Nee hoor... Komt zo uit de source van Bol.com. Was rechtstreeks Ctrl+c en Ctrl+v.

mjax schreef op zaterdag 14 juni 2008 @ 11:40:
Misschien zit het verschil in hoe regelovergangen gematched worden. Deze heb je nu nl. impliciet in je regexp opgenomen. Als je op Windows werkt met MS-DOS bestandsformaat (i.p.v. UNIX style), en je upload het bestand via FTP in ASCII mode, dan worden die regelovergangen op de server geconverteerd naar UNIX regelovergangen (\n). Windows regelovergangen zijn \n\r \r\n (red.).

Je kunt daarom het best je regelovergangen in je regexp expliciet opnemen met \n. De output van file ontdoe je dan even met een str_replace() van eventuele \r.

Daarom dus: geen harde regeleindes in je regex, pas ze aan in je invoer of match bijvoorbeeld op "\r?\n".

Edit: ah, al opgelost. Overheen gelezen

[Verwijderd]

Wellicht overvloedige opmerking, maar staat DNS wel aan op de nieuwe server? Dus kan hij Bol.com uberhaubt vinden?

[Tjolk]

Bedankt voor de suggesties, maar het was al opgelost, zie

SFB schreef op maandag 16 juni 2008 @ 11:37:
Anywho: door de boel wat grover te matchen en een specifieker stuk als pattern te pakken, is de boel opgelost. Heb nu een fijn werkend systeem, en dat wilde ik nog even vertellen.