na enkele uren zoeken zowel hier als elders...
Ik ben op het moment bezig met een webapplicatie dat een adressenbestand moet verzorgen. Informatie hierin is betrekkelijk eenvoudig: Naam en adres, land (aantal contacten buiten Nederland), telefoongegevens, e-mail en de mogelijkheid om een of meer notities aan het record toe te voegen.
Gisteren heb ik de applicatie van m'n eigen testomgeving verhuisd naar de machine waar de applicatie uiteindelijk moet draaien. Relevante specificaties van beide omgevingen:
(Windows XP is geen server OS, ben ik me van bewust, maar omdat er geen residente webserver beschikbaar is, is gekozen de applicatie op de machine van de gebruiker te draaien.)
Ontwikkelomgeving
Bekend probleem op zich, karakterset moet ergens verkeerd ingesteld staan, vermoedde ik.
Echter lijkt dat niet het geval te zijn, alle encoding staat in alle gevallen ingesteld op UTF-8.
Om het probleem te lokaliseren heb ik het een en ander aan m'n ontwikkelomgeving veranderd, deze is nu van dezelfde PHP versie voorzien als de server (5.2.0) en nu heb ik hetzelfde probleem in beide omgevingen, het lijkt het dus sterk op dat PHP in dit geval de boosdoener is.
Om een en ander netjes te kunnen testen heb ik:
1) Een export (SQL, UTF-8) gemaakt van m'n database en deze opnieuw aangemaakt (utf8_general_ci).
2) De export gecontroleerd op encoding (utf-8 is de enige encoding waarin de inhoud klopt, accenten en al)
3) Vervolgens de database-export opnieuw geimporteerd (en utf-8 aangegeven als karakterset bij import).
Dit zou moeten betekenen dat de inhoud van de database nu zeker weten utf-8 is en geen bastaard (latere controle mbv mb_detect_encoding() (op een string met een karakter dat -wel- verkeerd wordt weergegeven) verifiëert dit)
4) http-headers, html-output en browser-instellingen gecontroleerd - alledrie utf-8
Tijdens dit instellen blijkt dat het in de browser (Firefox 2.0, maar ook IE6) dat het instellen van zowel US-ASCII als ISO-8859-1 als karakterset tot juiste rendering leidt van de karakters. Echter, de output van de pagina is overal utf-8, en wordt ook alszodanig gedetecteerd (dus een override is verre van wenselijk omdat het de rendering van andere websites in de weg gaat zitten).
Uit de search kwam aan de hand van een soortgelijk probleem de suggestie om de output in utf8_encode() te hullen, maar dat was juist omdat php4 en de toenmalige MySQL versie -geen- (unicode) utf-8 support gaven. (terwijl mijn probleem voortkomt uit een upgrade van PHP4 naar PHP5.)
Bovendien is utf8_encode() er om een string te vertalen naar utf-8, terwijl mb_detect_encoding() aangeeft dat het reeds een string in utf-8 is.
de output door de utf8_encode() functie voeren is een optie, maar als de input van die functie al utf-8 gecodeerd is wordt die door deze functie juist gronding om zeep geholpen, iets dat ik liever vermijd.
Hopelijk is het geheel overzichtelijk (genoeg) en is het probleem duidelijk. Wie heeft een antwoord / suggestie, of kan me van het dwaalspoor helpen waar ik me (mogelijk) op begeef?
Ik ben op het moment bezig met een webapplicatie dat een adressenbestand moet verzorgen. Informatie hierin is betrekkelijk eenvoudig: Naam en adres, land (aantal contacten buiten Nederland), telefoongegevens, e-mail en de mogelijkheid om een of meer notities aan het record toe te voegen.
Gisteren heb ik de applicatie van m'n eigen testomgeving verhuisd naar de machine waar de applicatie uiteindelijk moet draaien. Relevante specificaties van beide omgevingen:
(Windows XP is geen server OS, ben ik me van bewust, maar omdat er geen residente webserver beschikbaar is, is gekozen de applicatie op de machine van de gebruiker te draaien.)
Ontwikkelomgeving
- Windows XP
- Apache 2.0
- PHP 4.3.9 (zonder extensions, MySQL connector geintegreerd)
- MySQL 5.0.18
- Windows XP
- Apache 2.2
- PHP 5.2.0 (met MySQL extension, als enige)
- MySQL 5.0.27
Bekend probleem op zich, karakterset moet ergens verkeerd ingesteld staan, vermoedde ik.
Echter lijkt dat niet het geval te zijn, alle encoding staat in alle gevallen ingesteld op UTF-8.
Om het probleem te lokaliseren heb ik het een en ander aan m'n ontwikkelomgeving veranderd, deze is nu van dezelfde PHP versie voorzien als de server (5.2.0) en nu heb ik hetzelfde probleem in beide omgevingen, het lijkt het dus sterk op dat PHP in dit geval de boosdoener is.
Om een en ander netjes te kunnen testen heb ik:
1) Een export (SQL, UTF-8) gemaakt van m'n database en deze opnieuw aangemaakt (utf8_general_ci).
2) De export gecontroleerd op encoding (utf-8 is de enige encoding waarin de inhoud klopt, accenten en al)
3) Vervolgens de database-export opnieuw geimporteerd (en utf-8 aangegeven als karakterset bij import).
Dit zou moeten betekenen dat de inhoud van de database nu zeker weten utf-8 is en geen bastaard (latere controle mbv mb_detect_encoding() (op een string met een karakter dat -wel- verkeerd wordt weergegeven) verifiëert dit)
4) http-headers, html-output en browser-instellingen gecontroleerd - alledrie utf-8
Tijdens dit instellen blijkt dat het in de browser (Firefox 2.0, maar ook IE6) dat het instellen van zowel US-ASCII als ISO-8859-1 als karakterset tot juiste rendering leidt van de karakters. Echter, de output van de pagina is overal utf-8, en wordt ook alszodanig gedetecteerd (dus een override is verre van wenselijk omdat het de rendering van andere websites in de weg gaat zitten).
Uit de search kwam aan de hand van een soortgelijk probleem de suggestie om de output in utf8_encode() te hullen, maar dat was juist omdat php4 en de toenmalige MySQL versie -geen- (unicode) utf-8 support gaven. (terwijl mijn probleem voortkomt uit een upgrade van PHP4 naar PHP5.)
Bovendien is utf8_encode() er om een string te vertalen naar utf-8, terwijl mb_detect_encoding() aangeeft dat het reeds een string in utf-8 is.
de output door de utf8_encode() functie voeren is een optie, maar als de input van die functie al utf-8 gecodeerd is wordt die door deze functie juist gronding om zeep geholpen, iets dat ik liever vermijd.
Hopelijk is het geheel overzichtelijk (genoeg) en is het probleem duidelijk. Wie heeft een antwoord / suggestie, of kan me van het dwaalspoor helpen waar ik me (mogelijk) op begeef?
