Ik krijg data vanuit een Oracle database aangeleverd als:
Angélique, Samão, Tümos.
Deze plaats ik 1 : 1 in de MySQL database. Deze namen zoals hierboven staan ook letterlijk in MySQL database.
Vervolgens wil ik die presenteren middels HTML, met htmlentities. (De andere method htmlspecialchars heb ik ook geprobeerd.)
Zonder deze functie krijg ik vreemde karakters.
Maar met deze functie gaan de namen als Angélique, Samão correct, echter de naam Tümos wordt T�mos!!???
Ik heb gegoogled, met verschillende character sets gespeeld, niets helpt.
Heeft iemand een idee waar dit aan zou kunnen liggen.
mysqli in combinatie met mysql? Hmmz. Dan gaat dit beter denk ik:
<?php
function fr_mysql_connection($user,$pass,$db,$host) {
if($link=mysql_connect($host,$user,$pass)) {
mysql_set_charset('utf8', $link);
if (mysql_select_db($db,$link)) {
return($link);
}
}
return(FALSE);
}
Wanneer de data niet goed geïmporteerd is maakt het niet uit wat je doet. MySQL gaat er immers vanuit dat deze correct geëncodeerd is. Hier een ALTER TABLE overheen gooien gaat je probleem niet oplossen. De collation heeft hier helemaal niets mee te maken - collation gaat over sorteren en matching, niet over de character encodering zelf.
De enige remedie is de data correct importeren of repareren.
En vervolgens is het zaak dat je deze op de juiste manier weergeeft, anders zie je nog steeds wiebertjes, vraagtekens en andere vreemde karakters op je scherm, maar dat heeft dan dus weer niets met het wel of niet juist geëncodeerd zijn te maken...
Nota Bene: utf8 is een subset van UTF-8 dus uit oogpunt van maximale compatibiliteit is het misschien beter om alle tabellen op te zetten als utf8mb4.
@Thomas wanneer is de data niet goed geïmporteerd? Ik bedoel ik haal de data op vanuit een Oracle database. Daarin staat het op deze wijze é, ü, ã. Zo heb ik het nu ook letterlijk in mijn MySQL database nu staan weliswaar mbv. de functie 'mysql_real_escape_string'.
Dus denk ik nu: het staat letterlijk hetzelfde in twee dBsen en dus is het goed, of...?
Nu wil ik het presenteren op het scherm en dan gaat het fout...
Of bedoel je nu te zeggen dat ik het met 'wiebertjes/vraagtekens' in de MySQL database moet weg schrijven?
Overigens wat is nu de beste of meest geschikte:
- collatie?
- karakterset?
- database engine?
En wat zet je dan in je HTML page, zodat het altijd werkt?
Afhankelijk van character encoding is de ene é de andere niet op byte-niveau.
Ook jouw Oracle database houdt een bepaalde character encoding aan. Een eerste stap voor correcte import zou het uitvogelen van de character encoding zijn.
Dan set_charset(X). Je moet set_charset(X) zien als het contract tussen jou en je MySQL-database. Hiermee leg je vast dat:
- jij data aanlevert met character encoding X
- MySQL haar best doet om alle data terug te geven met character encoding X
Wanneer jij geen character encoding instelt bij het maken van een connectie veronderstelt MySQL waarschijnlijk de default character encoding "latin1". MySQL is zelf best slim. Als deze ziet dat jij dus wilt communiceren in "latin1" maar de data in jouw tabellen zijn utf8 dan zal MySQL:
- als deze data ontvangt omzetten naar utf8
- als deze data uitgeeft weer terug vertalen naar latin1
MySQL gaat hier verder wel uit van correct geëncodeerde data. Als deze niet klopt kun je ook niet verwachten dat MySQL dit voor je rechtbuigt (al dan niet met vertalingen tussen verschillende character encoderingen). Het is beter om dingen altijd expliciet in te stellen in plaats van uit te gaan van mogelijk afwijkende defaults.
Hiernaast is het handig om dus alles in de pas te laten lopen:
- de connectie met je database
- de databasetabellen
- de DATA in de tabellen :p
- Content-Type header en/of meta tag
