 Moderator |
|
Inmiddels heb ik al even zitten zoeken naar dit onderwerp op internet. In de meeste artikelen die ik tegenkwam werden allerlei doemscenario's geschetst en ingewikkelde procedures uiteengezet om deze conversie voor elkaar te krijgen.
Hierbij werd er echter volgens mij in bijna alle gevallen vanuit gegaan dat er al utf-8 data in latin1 tabellen terecht was gekomen en dus (eigenlijk) al verkeerd geëncodeerd was.
EDIT: of, misschien waarschijnlijker, er zit latin1-encoded utf8-data in een utf8-tabel, bijvoorbeeld doordat je bij het inserten/editten van de data was vergeten om een character set in te stellen bij het connecten naar je database.
Ik kan mij voorstellen dat als je dan niet op een goede manier deze tabellen omzet de ramp niet te overzien is, je maakt van troep (data die eigenlijk al "corrupt" is) een nog grotere troep.
Daartoe gooit men vervolgens allerlei middelen in de strijd om de latin1-data-die-mogelijk-utf-8-content-bevat maar niet verder te corrumperen bij de omzetting. De meest gebruikte methode lijkt het omzetten van kolommen naar een BLOB (binary) variant, omdat deze blijkbaar niet character-set-aware zijn (en er dus ook geen omzetting plaatsvindt). Vervolgens, na het "redden" van deze kolommen, wordt de tabel omgezet naar utf-8 en daarna krijgen de kolommen weer hun oorspronkelijke type terug. Operatie geslaagd.
Maar wat als je nu geen utf-8 data in je latin1 tabellen hebt? Wat als je een latin1 database hebt, waar je met latin1 mee communiceert en alleen maar vult met latin1 data (dit is (bijna) gelijk aan iso-8859-1 maar wordt vaak als hetzelfde beschouwd)? De karakters die "ondersteund" worden door latin1 vormen zelf toch een subset van de karakters die door utf-8 worden ondersteund [1]? Oftewel, er hoeft in dat geval toch geen omzetting plaats te vinden? Oftewel, in dat geval is de conversie latin1 > utf8 simpelweg het aanpassen van de character sets van de tabellen (en van de database, als je slim bent). Of mis ik nu iets? In alle artikelen die ik tegenkwam werd dit onderwerp altijd als iets complex benaderd, maar als je je aan de spelregels had gehouden lijkt mij dit eenvoudig?
Wel zul je na afloop volledig moeten overschakelen naar utf-8, dat snap ik [2]. Je bent dus niet klaar met het simpelweg omzetten van je tabellen. Je moet je pagina's serveren met de utf-8 charset en de connectie met je database moet verlopen via utf8. PHP-, CSS en HTML-bestanden hoeven eigenlijk niet eens te worden opgeslagen met utf-8 encodering (als ik het goed begrijp). Hier is immers dezelfde stelregel van toepassing als bij de database-data: als het latin1 compliant is, is het eveneens utf-8 compliant.
Klopt dit een beetje zo? Ik denk dat dit onderwerp wat moeilijker wordt gebracht dan het daadwerkelijk is, zolang je op het fietspad blijft en de regels omtrent character encoding in acht neemt.
EDIT:
[1] Blijkbaar niet helemaal. Als de karakters buiten US-ASCII vallen (zoals ë (e met trema), ï (i met trema) en € (euro-teken)) dan worden deze als multibyte chars opgeslagen in utf8 (bron). Het euro-teken maakt eigenlijk ook deel uit van ISO-8859-15, en niet van ISO-8859-1 (bron) maar wordt inmiddels stilzwijgend geaccepteerd in ISO-8859-1?
[2] Dit is dus ook niet helemaal waar, MySQL kan achter de schermen vertalingen uitvoeren, zie EDIT3.
EDIT2:
Ondanks het feit dat de karakters die utf8 ondersteunen een superset vormen van de karakters die ISO-8859-1(5) ondersteunt, wil dit niet zeggen dat deze karakters op dezelfde wijze geëncodeerd worden. Dit heb ik inmiddels getest met twee testscripts: een waarbij alles ISO-8859-15 / latin1 is en een waarbij alles UTF-8 / utf8 is. Hieruit blijkt bijvoorbeeld dat de encodering van de string "éëïî€" in beide varianten sterk uiteen loopt. Deze lijkt echter hetzelfde als je via de DOS-prompt in je database kijkt maar is dat niet. Los van het feit dat Windows nogal wat probleempjes heeft met UTF-8 / speciale karakters in het algemeen en deze daardoor in een DOS-venster door de vleesmolen gaan moet je het volgende niet vergeten: je connectie gaat ook uit van een character encoding (ook als je deze niet opgeeft). Oftewel, als je data van een utf8-encoded tabel bekijkt met een latin1-connectie, probeert MySQL dit (waarschijnlijk) voor je te vertalen:
mysql> SELECT * FROM test_latin1 WHERE id = 1;
+----+-------+
| id | tekst |
+----+-------+
| 1 | éëïî? |
+----+-------+
1 row in set (0.00 sec)
mysql> SELECT * FROM test_latin1 WHERE id = 1; +----+-------+ | id | tekst | +----+-------+ | 1 | éëïî? | +----+-------+ 1 row IN SET (0.00 sec)
versus
mysql> SELECT * FROM test_utf8 WHERE id = 1;
+----+-------+
| id | tekst |
+----+-------+
| 1 | éëïî? |
+----+-------+
1 row in set (0.05 sec)
mysql> SELECT * FROM test_utf8 WHERE id = 1; +----+-------+ | id | tekst | +----+-------+ | 1 | éëïî? | +----+-------+ 1 row IN SET (0.05 sec)
In het tweede geval (dit betreft een utf8-tabel met utf8-data) wordt de string hetzelfde weergegeven als in de eerste tabel (latin1-tabel met dezelfde data, maar dan in latin1-encoding). Overigens gaat het tonen van een euro-teken in de DOS-box mis  .
Je kunt alsnog de encoding controleren door de data in binaire vorm weer te geven, dit doe je met HEX(). Deze data ziet er compleet verschillend uit (en dit toont ook min of meer aan dat MySQL automatisch vertalingen uitvoert):
mysql> SELECT *, HEX(tekst) FROM test_latin1 WHERE id = 1;
+----+-------+------------+
| id | tekst | HEX(tekst) |
+----+-------+------------+
| 1 | éëïî? | E9EBEFEE80 |
+----+-------+------------+
1 row in set (0.00 sec)
mysql> SELECT *, HEX(tekst) FROM test_latin1 WHERE id = 1; +----+-------+------------+ | id | tekst | HEX(tekst) | +----+-------+------------+ | 1 | éëïî? | E9EBEFEE80 | +----+-------+------------+ 1 row IN SET (0.00 sec)
versus
mysql> SELECT *, HEX(tekst) FROM test_utf8 WHERE id = 1;
+----+-------+------------------------+
| id | tekst | HEX(tekst) |
+----+-------+------------------------+
| 1 | éëïî? | C3A9C3ABC3AFC3AEE282AC |
+----+-------+------------------------+
1 row in set (0.00 sec)
mysql> SELECT *, HEX(tekst) FROM test_utf8 WHERE id = 1; +----+-------+------------------------+ | id | tekst | HEX(tekst) | +----+-------+------------------------+ | 1 | éëïî? | C3A9C3ABC3AFC3AEE282AC | +----+-------+------------------------+ 1 row IN SET (0.00 sec)
EDIT3: Als je latin1-tabel al utf8-encoded is, zet je dus alles weg (zet je alles om) in een binary kolom, dan pas je je tabel-definitie aan naar utf8 (mogelijk met een afwijkende collation (oeh nog een leuk onderwerp)), en dan verander je je kolom weer terug naar het oorspronkelijke type. Effectief verandert je data dan inhoudelijk niet. Als je deze truuk toepast op latin1-data dan worden je kolommen helemaal leeggegooid  . Als je je kolom dan namelijk terugverandert krijg je de volgende warning (zou dit niet een error moeten zijn?):
Level: Warning
Code: 1366
Message: Incorrect string value: '\xE9\xEB\xEF\xEE\x80' for column 'tekst' at row 1
Level: Warning Code: 1366 Message: Incorrect string value: '\xE9\xEB\xEF\xEE\x80' FOR COLUMN 'tekst' at row 1
Stackoverflow gaf mij toen de oplossing: laat MySQL de omzetting voor je doen. Het volgende werkt wel:
mysql> ALTER TABLE test_latin1 CONVERT TO CHARACTER SET utf8;
Query OK, 1 row affected (0.06 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> ALTER TABLE test_latin1 CONVERT TO CHARACTER SET utf8; Query OK, 1 row affected (0.06 sec) Records: 1 Duplicates: 0 Warnings: 0
en de controle:
mysql> SELECT *, HEX(tekst) FROM test_latin1 WHERE id = 1;
+----+-------+------------------------+
| id | tekst | HEX(tekst) |
+----+-------+------------------------+
| 1 | éëïî? | C3A9C3ABC3AFC3AEE282AC |
+----+-------+------------------------+
1 row in set (0.00 sec)
mysql> SELECT *, HEX(tekst) FROM test_latin1 WHERE id = 1; +----+-------+------------------------+ | id | tekst | HEX(tekst) | +----+-------+------------------------+ | 1 | éëïî? | C3A9C3ABC3AFC3AEE282AC | +----+-------+------------------------+ 1 row IN SET (0.00 sec)
MySQL heeft de data dus echt omgezet naar utf8. MySQL is dus best intelligent en regelt veel achter de schermen. Zo kon ik nog steeds met het latin1-script de (inmiddels naar utf8 geconverteerde) latin1-tabel (test_latin1) uitlezen en correct weergeven in ISO-8859-1. Dit komt (waarschijnlijk) omdat MySQL ziet dat je met latin1 connect en de tabel (inmiddels) utf8 is. Deze probeert dan (in ieder geval) de (bekende) karakters terug te vertalen naar latin1. Voor latin1 onbekende (multibyte) karakters worden dan weergegeven als een (enkel) vraagteken ("?").
Ondanks het feit dat je zelf een zooi maakt van welke character sets je hanteert, zolang je data in je database van de encodering is overeenkomstig met de tabel of kolom kan MySQL hiermee overweg. Wel moet $charset in de _set_charset($charset) aanroep overeenkomen met de charset waarin je een en ander wilt tonen, anders gaat het alsnog mis.
EDIT4: Je kunt nagaan of MySQL data heeft vertaald door na het ophalen van het resultaat (wat dus mogelijk vertaald is) hier bin2hex() op uit te voeren. De HEX in de bovenstaande queries is de HEX zoals deze in de database geldt. Deze is dus mogelijk anders dan de hex-waarde (te bepalen met bin2hex()) van de opgehaalde data. Je kunt dit natuurlijk alleen bepalen als de tekst speciale karakters bevat, gewone (ASCII) teksten zonder speciale karakters geven hier geen uitsluitsel over, daar zal de HEX-waarde altijd gelijk zijn aan de bin2hex()-waarde van het opgehaalde resultaat.
gotcha: HEX() retourneert letters in UPPERCASE, bin2hex in LOWERCASE.
|
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
