Door
- Ariën -
op 06-06-2018 00:35
gewijzigd op 06-06-2018 00:43
9.622 views
Het wordt nu toch eens de tijd dat ik de overstap ga maken van iso-8859-1 naar UTF-8.
Nu weet ik dat ik er aan aantal randvoorwaarden zijn waaraan een site moet voldoen:
- Bestanden opslaan als UTF-8 encoding.
- Gebruik metatag met: <meta charset="UTF-8">
- Gebruik PHP-header header('Content-Type: text/html; charset=utf-8');
- Gebruik de juiste characterencoding in de DB-connectie: $mysqli->set_charset("utf8");
- Gebruik de juiste collatie: utf8_unicode_ci
Nu heb ik nog de latin1_swedish_ci collatie voor mijn site (tja, waarom Zweeds?) en dat moet dus utf8_unicode_ci worden. Is dat nog steeds het beste? En hoe converter ik de boel van de oude collatie naar de nieuwe?
Iemand goede tips & tricks, of eventuele andere dignen waar ik op moet letten, of tips wat een handig hulpmiddel kan zijn. Het is geen sinecure om deze overstap te maken, heb ik het idee, maar het moet toch eens een keer gebeuren. Ik zag ook iets over dit script: https://github.com/nicjansma/mysql-convert-latin1-to-utf8/blob/master/mysql-convert-latin1-to-utf8.php
Volgens mij kan ik het goed gebruiken, of kleven er nog wat nadelen aan?
Dus anybody tips and tricks voor een makkelijke overstap?
Uiteraard ga ik alles natuurlijk testen!
Maar ik neem aan dat ik dan beter set_charset('utf8mb4') moet gebruiken
Je bedoelt wellicht dat je alle tabellen converteert naar utf8mb4, en dan een verbinding maakt m.b.v. set_charset('utf8mb4');? In dat geval: ja.
- Ariën - op 08/06/2018 17:23:22
of is utf8mb4 meer een dingetje voor de collation van MySQL/MariaDB zelf, en dat PHP zich prima uit de voeten kan met UTF-8?
Collation is niet hetzelfde als character encoding (interne link). Je zult dus ook een collation moeten instellen als je de tabellen converteert (bijvoorbeeld utf8mb4_general_ci) of in ieder geval moeten controleren of deze klopt / automatisch meeverandert. PHP kent maar één variant van UTF-8 (althans de functies die CE-aware zijn :p). MySQL kent meerdere varianten. De vraag is trouwens of je utf8mb4 echt nodig hebt, je zou ook eerst een conversie naar utf8 kunnen doen.
- Ariën - op 08/06/2018 17:23:22
Rest mij enkel nu eventjes de vragen:
- Wat is de ervaring en mening over het in de startpost aangehaald conversie-script op GitHub? Een geautomatiseerde conversie met behoud van de FULLTEXT velden is nog niet direct mogelijk zie ik.
Als ik het begeleidend schrijven er op nasla is dat script bedoeld om incorrecte latin1 data (wss utf8) om te zetten naar kloppende data in een utf8 tabel. Dat is min of meer exact hetzelfde wat ik deed in het tweede deel van mijn eerder gelinkte artikel. Echter is daar in jouw geval geen sprake van? Je hebt toch geen niet-kloppende latin1 data? Volgens mij is het dan nog steeds enkel een kwestie van het simpele ALTER TABLE statement uitvoeren wat eerder in dit draadje stond, misschien met toevoeging van een collation.
- Ariën - op 08/06/2018 17:23:22
- Iemand goede ervaringen met het omzetten van de character encoding van de bestanden zelf in batch? Windows PowerShell to the rescue? Of is er iets wat NetBeans ook in een handomdraai kan doen?
Over hoeveel databases/tabellen/data gaat het? Meestal is het verstandig om eerst een kleine analyse te maken van de tabellen en de data. Waarbij eigenlijk het belangrijkste is dat je vaststelt dat de initiële data de goede encoding heeft. In mijn artikel (en hierboven) staat (weliswaar in een notedop) beschreven hoe je dit vaststelt.
Maak ook altijd eerst een backup voordat je begint. En zorg ervoor dat tijdens dit conversieproces niemand data kan toevoegen of kan wijzigen.
Je hebt toch geen niet-kloppende latin1 data? Volgens mij is het dan nog steeds enkel een kwestie van het simpele ALTER TABLE statement uitvoeren wat eerder in dit draadje stond, misschien met toevoeging van een collation.
Dat ga ik niet voor 100% van uit. Ik neem aan dat alles nu netjes latin-1 is, maar met data van ruim 10 jaar oud, en de vroegere tijd dat character-encoding niet interessant genoeg was kan je niks uitsluiten. Wel weet ik dat ik geen vreemde 'encoding-probleem'-tekens gezien heb. Dus ik ga er van uit dat het netjes altijd latin-1 is geweest.
Over hoeveel databases/tabellen/data gaat het? Meestal is het verstandig om eerst een kleine analyse te maken van de tabellen en de data. Waarbij eigenlijk het belangrijkste is dat je vaststelt dat de initiële data de goede encoding heeft. In mijn artikel (en hierboven) staat (weliswaar in een notedop) beschreven hoe je dit vaststelt.
Maak ook altijd eerst een backup voordat je begint. En zorg ervoor dat tijdens dit conversieproces niemand data kan toevoegen of kan wijzigen.
Stuk of 20 tabellen en 50 MB.
Uiteraard maak ik een backup en test ik het op een geisoleerde locatie uit op dezelfde server waar de site ook in productie draait.
Eerst maar uittesten dan, en dan kijken waar de bottlenecks zitten.
