[PHP] htmlentities bij ajax call

[Verwijderd]

Het probleem is dat bij ajax calls de tekst formatting corrupt raakt bij het terugzenden van de gegevens.
Ik probeerde daarom met de functie htmlentities() de tekst te strippen.

code:

function tekstOmzetten($tekst){
    $tekst = htmlentities($tekst, ENT_QUOTES);
    return $tekst;
}

Maar als ik dat doe geeft hij een lege string terug.

Als ik echter deze functie gebruik, lukt het wel:

code:

function tekstOmzetten($tekst){
    $tekst = str_replace('€','€',$tekst);  
    $tekst = str_replace('*','*',$tekst);
    $tekst = str_replace('+','+',$tekst);
    $tekst = str_replace('/','/',$tekst);
    $tekst = str_replace('%','%',$tekst);
    $tekst = str_replace('-','-',$tekst);
    $tekst = str_replace('©','©',$tekst);
    $tekst = str_replace('Ø','Ø',$tekst);
    $tekst = str_replace('–','–',$tekst);
    $tekst = str_replace('º','º',$tekst);
    $tekst = str_replace('®','®',$tekst);
    $tekst = str_replace('°','°',$tekst);
    $tekst = str_replace('•','•',$tekst);
    $tekst = str_replace('™','™',$tekst);
    $tekst = str_replace('ë','ë',$tekst);
    $tekst = str_replace('’','´',$tekst);
    $tekst = str_replace('“','“',$tekst);
    $tekst = str_replace('„','„',$tekst);
    $tekst = str_replace('"','"',$tekst);
    $tekst = str_replace('”','”',$tekst);
    $tekst = str_replace('ï','ï',$tekst);
    $tekst = str_replace('·','·',$tekst);
    $tekst = str_replace('²','²',$tekst);
    $tekst = str_replace('³','³',$tekst);
    $tekst = str_replace('×','×',$tekst);
    $tekst = str_replace('é','é',$tekst);
    $tekst = str_replace('É','É',$tekst);
    return $tekst;
}

Maar dat is erg omslachtig. Ik moet nu voor elk tekentje zo'n lijn toevoegen.
Daarom dat htmlentities() mij een veel eenvoudigere oplossing leek?

Weet er iemand wat ik kan doen om die functie htmlentities() toch aan de praat te krijgen?

[ Voor 5% gewijzigd door Verwijderd op 05-07-2007 15:22 ]

[crisp]

Verwijderd schreef op donderdag 05 juli 2007 @ 15:20:
Het probleem is dat bij ajax calls de tekst formatting corrupt raakt bij het terugzenden van de gegevens.

Waarom probeer je dan niet eerst te achterhalen waarom dat het geval is, in plaats van het symptoom proberen te bestrijden met dergelijke ranzige workarounds?

[BasieP]

htmlentities werkt gewoon goed. Dat je je request via ajax doet of niet.
* BasieP verdenkt je JS of character settings ervan dat ze je tekst te mollen.

[ Voor 9% gewijzigd door BasieP op 05-07-2007 15:24 ]

[DataGhost]

En ook al is het de verkeerde aanpak van het probleem wil ik toch even reageren op die gigantische lading str_replace calls... je kan str_replace aanroepen met 2 arrays, dat scheelt een heleboel calls.

[Megamind]

Dit probleem heb ik ook als ik met ajax bv een redirect doe naar

code:

page.php?a=1&b=2

dan werkt het ook niet. Ik denk dat je met JS ná het verzenden van de string moet decoden.

[ Voor 6% gewijzigd door Megamind op 05-07-2007 15:40 ]

[Verwijderd]

crisp schreef op donderdag 05 juli 2007 @ 15:23:
[...]

Waarom probeer je dan niet eerst te achterhalen waarom dat het geval is, in plaats van het symptoom proberen te bestrijden met dergelijke ranzige workarounds?

Dat heb ik gedaan door die ranzige methode te proberen.

BasieP schreef op donderdag 05 juli 2007 @ 15:23:
htmlentities werkt gewoon goed. Dat je je request via ajax doet of niet.
* BasieP verdenkt je JS of character settings ervan dat ze je tekst te mollen.

Mja inderdaad, want de functie op zich voert hij nu succesvol uit.

DataGhost schreef op donderdag 05 juli 2007 @ 15:29:
En ook al is het de verkeerde aanpak van het probleem wil ik toch even reageren op die gigantische lading str_replace calls... je kan str_replace aanroepen met 2 arrays, dat scheelt een heleboel calls.

Inderdaad, maar dat was sowiso een tijdelijke oplossing.
Copy/paste werkt dan even snel

[ Voor 7% gewijzigd door Verwijderd op 05-07-2007 15:49 ]

[Verwijderd]

Ik ben collega van de TS. We gebruiken Dojo.io.bind in combinatie met mimetype text/html.

code:

dojo.io.bind({
    url: "assets/modules/loginAjax.php?vergeten="+waarde,
    load: function(type, data, evt){ vervang(data); },
    mimetype: "text/html"
});

Het zou natuurlijk beter zijn als we niets zouden moeten encoden maar in de Dojo documentatie worden mimetypes nauwelijks uitgediept.

[Verwijderd]

OK het werkt nu min of meer, maar toch doet hij sommige HTML-chars NIET...
Het ™-teken skipt hij bijvoorbeeld, terwijl het ï-teken wel geconverteerd wordt.

[crisp]

Verwijderd schreef op donderdag 05 juli 2007 @ 15:44:
Ik ben collega van de TS. We gebruiken Dojo.io.bind in combinatie met mimetype text/html.

code:

dojo.io.bind({
    url: "assets/modules/loginAjax.php?vergeten="+waarde,
    load: function(type, data, evt){ vervang(data); },
    mimetype: "text/html"
});

Het zou natuurlijk beter zijn als we niets zouden moeten encoden maar in de Dojo documentatie worden mimetypes nauwelijks uitgediept.

Het gaat hier niet om mimetype maar om een character-encoding mismatch ergens tussen client en server. Met welke encoding worden de pagina's geserveerd? Welke encoding wordt er eventueel in de database gebruikt? Met welke encoding worden Ajax-responses geserveerd?

[Alex)]

Je hebt niets te maken met mimetypes, je hebt te maken met charsets, dat is iets heel anders...

Hmm, crisp was ietsjes sneller

[ Voor 16% gewijzigd door Alex) op 05-07-2007 15:57 ]

[BasieP]

Megamind schreef op donderdag 05 juli 2007 @ 15:39:
Dit probleem heb ik ook als ik met ajax bv een redirect doe naar

code:

page.php?a=1&b=2

dan werkt het ook niet. Ik denk dat je met JS ná het verzenden van de string moet decoden.

dit is ook gewoon fout.
dwz, & is een html teken, en hoort niet in een url. Wanneer jij in je browser blaat.nl/?p=1&i=3 doet dan zal hij ook fout gaan

[crisp]

BasieP schreef op donderdag 05 juli 2007 @ 16:00:
[...]

dit is ook gewoon fout.
dwz, & is een html teken, en hoort niet in een url. Wanneer jij in je browser blaat.nl/?p=1&i=3 doet dan zal hij ook fout gaan

Inderdaad; HTML-encoding hoef je enkel te doen in een HTML-serialisatie.

[Verwijderd]

Probeer dit eens nadat je script het resultaat binnen heeft.

JavaScript:

alert(xmlhttprequest.getAllResponseHeaders());

Oh, schiet me net te binnen kijk eens welke charset het script dat je opvraagt heeft.

[ Voor 25% gewijzigd door Verwijderd op 05-07-2007 16:11 ]

[Megamind]

BasieP schreef op donderdag 05 juli 2007 @ 16:00:
[...]

dit is ook gewoon fout.
dwz, & is een html teken, en hoort niet in een url. Wanneer jij in je browser blaat.nl/?p=1&i=3 doet dan zal hij ook fout gaan

Ja en nee, een url moet het idd niet instaan, maar ik heb gezien dat een valide XHTML pagina een href moet bevatten met &amp

[Cartman!]

Klopt niet helemaal, je bedoelt t alleen wel goed.

Een & in een url kan best, anders kun je de pagina die je bouwt niet valid xhtml krijgen omdat een & niet geldig is. Als je echter vanuit javascript een call doet naar een server moet je die & niet gebruiken en toch gewoon & nemen. Dat zou moeten werken.

[Verwijderd]

crisp schreef op donderdag 05 juli 2007 @ 15:57:
[...]

Het gaat hier niet om mimetype maar om een character-encoding mismatch ergens tussen client en server. Met welke encoding worden de pagina's geserveerd? Welke encoding wordt er eventueel in de database gebruikt? Met welke encoding worden Ajax-responses geserveerd?

Hartelijk bedankt.

code:

header("Content-Type: text/html;charset=utf8");

Loste het probleem volledig op.

[BasieP]

Cartman! schreef op donderdag 05 juli 2007 @ 16:13:
Klopt niet helemaal, je bedoelt t alleen wel goed.

Een & in een url kan best, anders kun je de pagina die je bouwt niet valid xhtml krijgen omdat een & niet geldig is. Als je echter vanuit javascript een call doet naar een server moet je die & niet gebruiken en toch gewoon & nemen. Dat zou moeten werken.

pssst dit forum heeft de 'handige' functie om html chars (dus &) om te zetten naar de betekenis ervan (dus &)
je verhaal slaat nu echt als een tang op een varken

[ Voor 4% gewijzigd door BasieP op 05-07-2007 19:15 ]