Ik ben bezig met een webapplicatie, waarmee ik met preg_replace speciale characters probeer te vervangen. Nu heb ik dit voor elkaar als ik het test op een test pagina.
Nu probeer ik het toe te voegen aan de applicatie zelf, maar zonder het resultaat wat ik verwacht. Om te testen ben ik het aantal characters gaan tellen van de informatie ik verstuur en het aantal characters wat het zou moeten zijn. In het voorbeeld verstuur ik als input 'tést'.
Waarbij de é in de correct weergeven tést niet wordt aangepast naar de ascii code. Bij de preg_match geeft hij ook een 0/false resultaat terug.
De code van het formulier is als volgt:
Wat is het doel? Wanneer je overal keurig dezelfde character set gebruikt, bij voorkeur UTF-8, dan hoef je nergens iets te gaan vervangen en kan bovenstaande code zo weer richting afvalbak.
Verder is echo geen functie, al die overbodige haakjes () zijn dan ook echt overbodig.
Welkom in de wereld van UTF-8. Vanaf hier wordt het alleen maar vervelender :(
Heel simpel gezegd gaat het fout omdat je browser de POST-data waarschijnlijk als UTF8-tekst opstuurt. UTF-8 heeft de eigenschap dat alle karakters 1 of meerdere bytes kunnen gebruiken. Alle standaard-karakters, [a-z0-9] en wat speciale karakters krijgen 1 byte toegewezen, en die bytes zijn gelijk aan die van ISO-8859-1. ISO-8859-1 is de character-set waar PHP nog in denkt. Karakters als é krijgen twee bytes toegewezen, en in ISO-8859-1 is ieder karakter altijd één byte. Resultaat: PHP ziet twee tekens waar je maar 1 bedoelde. Voorbeeldje (ervan uitgaande dat je je PHP-bestanden als UTF-8 opslaat)
<?php
echo strlen('é'); // geeft 2 terug
?>
Gelukkig zijn er een paar hulpmiddelen om UTF-8 en PHP toch enigszins een beetje te herenigen (iemand moet hier eens een lekker dikke tutorial over schrijven)
<?php
echo htmlentities('é', ENT_QUOTES, 'UTF-8');
?>
Ik denk dat de reden dat in jouw code de aanroep naar preg_replace wel werkt, en de aanroep naar parse_char_to_ascii is dat die laatste in een bestand is opgeslagen dat is opgeslagen als ISO-8859-1, terwijl je code andere code als UTF-8 is opgeslagen. Wanneer PHP dan het ISO-bestand include, leest het het als UTF-8 waardoor jouw é niet als é gezien wordt (ISO é is immers maar 1 byte, é in UTF-8 2) waardoor je functie naar het verkeerde karakter zoekt.
edit: ik raad je overigens aan, net zoals Frank op een wat te directe manier probeert te zeggen dat je eigenlijk gewoon overal UTF-8 moet gebruiken. Sla je PHP bestanden op als UTF-8, zorg ervoor dat je MySQL tabellen UTF-8 als karakterset gebruiken en stuur Content-Type: text/html;charset=utf-8 headers terug met je HTML. Op die manier is de kans het kleinst dat je foutjes tegenkomt. En bedenk je even dat [php]strlen[/php] en veel andere PHP functies nu nog wel eens vreemde antwoorden kunnen geven, maar die zijn te vervangen door de [php]mbstring[/php] varianten. Tegen de tijd dat PHP 6 uitkomt zou dit alles verholpen moeten zijn.
Het doel is dat de data in een mysql database wordt opgeslagen met ascii code.
En wat is daar het doel van? Data sla je op zoals je hem ontvangt, dan kun je er later eenvoudig van alles en nog wat mee gaan doen.
Anno 2008 kun je gewoon met UTF-8 (en andere charsets) werken en gaat het vanzelf goed met de diverse tekens. Let er wel op dat je overal dezelfde set gebruikt, anders gaat het goed fout. Dat lijkt nu overigens ook al jouw probleem te zijn, zie de bijzondere resultaten.
Ps.
<?php
echo("<br />");
// of
echo "<br />";
?>
Zonder haakjes maak je toch echt minder tikfouten.
Bedankt voor je hulp en uitleg, dat bleek het probleem idd te zijn!! :)
@pgFrank:
De data die ik ontvang via het formulier is geen utf8 meer, waardoor er rare tekens kwamen. Deze ging ik vervangen via preg_replace. Maar zoals Jelmer heeft uitgelegd, kwam dit doordat PHP standaard een andere charset pakt.
In de headers van mijn pagina's staat het volgende:
Als het goed is sturen alle browsers de data die je in een form-element stopt op in dezelfde character-set als dat de pagina geserveerd werd. Als jij die Content-type "header" in je pagina had staan, dan is dat de reden waarom de browser data als UTF-8 aan PHP gaf.
Kortom, wanneer alles als UTF-8 staat ingesteld en wordt opgeslagen, heb je nergens last van en hoef je nergens iets te converteren. Gaat bij mij, wellicht per ongeluk, al jaren goed.
