[PHP/MySQL] Character encoding doet vreemd

[Evilbee]

Ik weet het, er zijn over dit onderwerp al heel wat topic geweest. Maar daar kon ik geen antwoorden vinden op mijn probleem.

Ik heb de volgende situatie.
Een ontwikkel server met PHP 5.1.6, MySQL 5.0.27 en Apache/2.2.6
En een productie server bij xs4all met PHP 4.4.4, MySQL 5.0.32 en Apache/1.3.37.

Op beide server stuurt Apache een encoding van ISO-8859-1 mee.

Op beide MySQL servers wordt in de tabellen voor de collation latin1_swedish_ci gebruikt. En voor beide servers geld dat er voor de "MySQL charset" en voor " MySQL connection collation" UTF-8 Unicode wordt gebruikt.

Maar nu is het vreemde dat als ik op mijn ontwikkelserver in een html formulier een ë invoer, dit keurig netjes zo in de database wordt opgeslagen. Maar op de productie server dus niet, daar komt een vraagteken op die plaats te staan.

Ik heb op de productie server een UTF-8 header toegevoegd, maar dat bleek niet te helpen.

Ook heb ik gezien dat op de mysql ontwikkel server InnoDB wordt gebruikt en op de productie server MyISAM, maar dat heeft volgens mij niks met dit probleem te maken.

Hebben jullie enig idee waar het probleem ligt?

[Janoz]

Sowieso is het grootste probleem natuurlijk dat je ontwikkel omgeving compleet andere versies gebruikt dan je productie omgeving. Dat is uiteindelijk vragen om problemen. Versies gelijk trekken maakt het uitzoeken van het probleem iig een stuk makkelijker dus ik zou daar iig mee beginnen.

[Blackbird-ce]

Encoding die in de meta-tags in de HTML wordt gedefinieerd wil nog wel eens de apache-headers overrulen (browser-afhankelijk), maar ik neem aan dat die óók gelijk zijn tussen ontwikkeling en productie?

[Evilbee]

Blackbird-ce schreef op woensdag 23 januari 2008 @ 13:17:
Encoding die in de meta-tags in de HTML wordt gedefinieerd wil nog wel eens de apache-headers overrulen (browser-afhankelijk), maar ik neem aan dat die óók gelijk zijn tussen ontwikkeling en productie?

Die wordt niet in de meta-tags gedefinieerd, omdat apache al de goede header mee stuurt.

[Verwijderd]

Licht vermoeden dat het al fout gaat bij het posten van je html-formulier naar de server. Gebruik je bij beide dezelfde browser om te testen en staat je charset goed in je html gedefinieerd?

Test anders even met Firefox en bijv livehttpheaders om te kijken wat er naar de servers toe wordt gepost (en let dan vooral op de charset van de content-type).

[Patriot]

Evilbee schreef op woensdag 23 januari 2008 @ 16:53:
[...]

Die wordt niet in de meta-tags gedefinieerd, omdat apache al de goede header mee stuurt.

Weet je 100 procent zeker dat hij op beide servers wordt meegestuurd? Forceer je dit zelf met header(), of ga je daar gewoon van uit?

[Evilbee]

Patriot schreef op woensdag 23 januari 2008 @ 17:05:
[...]


Weet je 100 procent zeker dat hij op beide servers wordt meegestuurd? Forceer je dit zelf met header(), of ga je daar gewoon van uit?

Als ik via FireFox de page-info opvraag, geeft ie aan dat het ISO-8859-1 encoding is. En ik neem dus aan dat FireFox dit goed heeft.

[steffex]

ë opslaan in de database vind ik zelf al niet echt handig. gebruik de php functie htmlentities(), weet je zeker dat het er altijd op dezelfde manier weer uit komt! (niet vergeten om bij het weergeven de decode te gebruiken)

ps: alle browsers pakken een default als er geen wordt meegegeven! kan prima zijn dat ISO-8859-1 niet de juiste is!

[ Voor 21% gewijzigd door steffex op 24-01-2008 15:19 ]

[Blackbird-ce]

mySQL slaat het ding gewoon op als een zooitje bits toch? Dus ook al wordt hij anders verstuurd dan opgeslagen, als de preesntatie weer dezelfde charset gebruikt is er geen probleem afaik.
Overigens kan het geen kwaad om even burpproxy oid te gebruiken om de headers te checken voor beide servers (zowel van versturen als ontvangen berichten).

[Voutloos]

Blackbird-ce schreef op vrijdag 25 januari 2008 @ 12:59:
mySQL slaat het ding gewoon op als een zooitje bits toch? Dus ook al wordt hij anders verstuurd dan opgeslagen, als de preesntatie weer dezelfde charset gebruikt is er geen probleem afaik.

Fout, dit is een van de meest voorkomende denkfouten met character encoding. Op élk punt waar een string geinterpreteerd wordt moet de charset bekend en correct zijn, anders kan je gewoon niet weten wat de betekenis van de string is cq. een verkeerde conversie om je oren krijgen.

[AaroN]

Ik had laatst een soortgelijk probleem en toen bleek dat de pagina met het formulier dat ik gebruikte om waarden in te voeren een utf-8 encoding gebruikte en de pagina om het te tonen een iso8859-1 encoding. Toen kreeg ik ook het probleem dat de waarde al verkeerd werd getoond in phpmyadmin.

Als ik dan met phpmyadmin de waarde opnieuw invoerde kreeg ik hem wel correct op het scherm te zien, maar bij de eerst volgende update via het formulier ging het weer fout.

Oplossing: bekijk de encodings van alle pagina's die je gebruikt, deze moeten allemaal 8859-1 zijn.

[Evilbee]

stef-o schreef op donderdag 24 januari 2008 @ 15:18:
ë opslaan in de database vind ik zelf al niet echt handig. gebruik de php functie htmlentities(), weet je zeker dat het er altijd op dezelfde manier weer uit komt! (niet vergeten om bij het weergeven de decode te gebruiken)

Ten eerste vind ik dat je nooit geescaped tekst in de database moet zetten. Ten tweede zou dit ook niet kunnen aangezien er vanuit de data in de database een pdf wordt gegenereerd en die kan geen htmlentities lezen.

ps: alle browsers pakken een default als er geen wordt meegegeven! kan prima zijn dat ISO-8859-1 niet de juiste is!

Ik denk dat mijn probleem hier lag. Ik heb nu ook in de code gezet dat de encoding ISO-8859-1 moet zijn. En nu gaat het overal goed.

PHP:

header('Content-Type: text/html; charset=ISO-8859-1');

[ Voor 4% gewijzigd door Evilbee op 26-01-2008 13:24 . Reden: code bijgevoegd ]