ge�nventariseerd ipv geïnventariseerd
De codering in de pagina is utf-8.
Weet iemand hoe ik dit rechtzet, of wat er gebeurd is?
Gewijzigd op 11/10/2018 19:05:17 door Jan te Pas
Gewijzigd op 11/10/2018 19:08:24 door - Ariën -
$servername = "localhost";
$username = "xxxxx";
$password = "xxxxxx";
$dbname = "xxxxxxx";
$servername = "localhost";
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}
Jan te Pas op 11/10/2018 19:04:16:
Weet iemand hoe ik dit rechtzet, of wat er gebeurd is?
Je zult eerst een inventarisatie moeten maken van wat er precies aan de hand is, dit kan een kwestie zijn van het document voorzien van een Content-Type header of meta-tag, maar aan de bovenstaande code te zien selecteerde je bij het maken van een database geen character encoding dus mogelijk is de data in je database "corrupt". Dit komt dan vaak pas naar boven als je een export doet en dan in een nieuwe opzet vervolgens wel op de goede manier een verbinding maakt met je database.
Maar eerst zul je dus de situatie moeten hercreëren om precies na te gaan hoe je data verkeerd geëncodeerd in je database zit om vervolgens een eenmalige omzetting te doen. Maar dat is niet bepaald een sinecure en vereist wel wat kennis van zaken.
Ik had de data geïmporteerd. En toen zag ik het. Gelukkig alleen testdata. Ik heb content-type en mega wel goed staan. Ik gooi het een keer leeg en ga nieuwe testdata inoeren. Dank.
Thomas van den Heuvel op 11/10/2018 19:32:03:
....dus mogelijk is de data in je database "corrupt". Dit komt dan vaak pas naar boven als je een export doet en dan in een nieuwe opzet vervolgens wel op de goede manier een verbinding maakt met je database.
Maar eerst zul je dus de situatie moeten hercreëren om precies na te gaan hoe je data verkeerd geëncodeerd in je database zit om vervolgens een eenmalige omzetting te doen. Maar dat is niet bepaald een sinecure en vereist wel wat kennis van zaken.
Maar eerst zul je dus de situatie moeten hercreëren om precies na te gaan hoe je data verkeerd geëncodeerd in je database zit om vervolgens een eenmalige omzetting te doen. Maar dat is niet bepaald een sinecure en vereist wel wat kennis van zaken.
Dus met een export en import trek je dat weer recht, wil je zeggen?
Ik ga binnenkort een omzetting doen van iso-8859-1 naar UTF-8, maar ik heb geen idee of de data corrupt kan zijn. 40 MB aan data die 12 jaar lang is toegevoegd. Toen hield ik mij net als velen nog niet bezig met encoding.
Heb je misschien tips en trucs? En ja, backups staat heel dikgedrukt op mijn lijstje. ;-)
Gewijzigd op 11/10/2018 19:42:38 door - Ariën -
Code (php)
1
2
3
4
2
3
4
<?php
$conn = new mysqli($servername, $username, $password, $dbname);
$conn->set_charset("utf8mb4");
?>
$conn = new mysqli($servername, $username, $password, $dbname);
$conn->set_charset("utf8mb4");
?>
- Ariën - op 11/10/2018 19:41:38:
Dus met een export en import trek je dat weer recht, wil je zeggen?
Nee.
Hier zijn al meerdere topics over geweest.
EDIT: een ALTER TABLE statement kun/zou je alleen moeten uitvoeren als de DATA ook echt van de voorgeschreven character encoding is, anders kan MySQL dit met geen fatsoen omzetten.
EDIT: het zomaar toevoegen van een set_charset() statement is een heel slecht idee, en wel om de volgende reden. Op dit moment is er mogelijk data verkeerd weggeschreven naar de database. Dit is -nadat je bent nagegaan wat het euvel precies is- waarschijnlijk toch redelijk eenvoudig te herstellen met een eenmalige (handmatige) conversie. Maar wat gebeurt er nu als je een set_charset() statement toevoegt en vervolgens vrolijk verdergaat met het vullen van data? De kans bestaat dan dat je dadelijk een mix van data met kloppende en niet-kloppende character encoderigen hebt, wat het praktisch onmogelijk (of in ieder geval een stuk moeilijker) maakt om alles in één keer recht te trekken.
Nogmaals, het is éérst zaak dat je uitzoekt wat er aan de hand is, en hoe je dat oplost, voordat je allerlei toverformules in je code zet waarvan je de impact niet kunt overzien...
EDIT: het belangrijkste is eigenlijk (nog steeds) het expliciet instellen van een character encoding bij het maken van een verbinding. Dit vormt in wezen een tweezijdig contract met jouw database. Enerzijds dien jij er zorg voor te dragen dat jij DATA aanlevert in die character encoding en anderzijds doet MySQL haar best om DATA in die character encoding vanuit de database terug te geven. Hierbij mag de character encoding die je wilt gebruiken en de character encoding waarmee de DATA is opgeslagen best van elkaar afwijken (al is dit niet aan te raden, MySQL zal de omzettingen onder water weliswaar prima kunnen verzorgen, maar dit is in principe overhead). Wat je hiervan moet onthouden is: de character encoding die je instelt bij/na het maken van een verbinding is de character encoding waarin je vervolgens communiceert/dient te communiceren met je database.
Gewijzigd op 13/10/2018 14:23:44 door Thomas van den Heuvel
Helder. Ik ga de tabel in ieder geval opnieuw opzetten en er op letten de character encoding uniform te maken. Ik loop morgen de code voor ze zekerheid nog eens door. Dankallen voor de informatie.
En hoe kom je vooraf te weet dat je 'om zeep geholpen' data in je database hebt?
Daar ben ik vooral benieuwd naar, omdat ik niet kan garanderen of er sprake van is.
- Ariën - op 12/10/2018 10:20:24:
En hoe kom je vooraf te weet dat je 'om zeep geholpen' data in je database hebt?
Hier loop je meestal -in ieder geval de eerste keer :)- op een gegeven moment gewoon tegenaan, vaak omdat je in het begin nog niet alle spelregels en interacties kent.
Dit is waarschijnlijk niet iets wat je van tevoren kunt afvangen, tenzij je voor het wegschrijven al een soort van character encoding controle verricht op de DATA die de database in gaat. Maar zelfs dan, als dit "verkeerd" geëncodeerd zou zijn (op een manier die er voor zorgt dat je tekst niet wordt weergegeven zoals je zou verwachten), dan kan een machine dat mogelijk niet detecteren want die zou de data dan ook echt moeten interpreteren. De bytereeksen kunnen namelijk best legaal zijn voor de gebruikte character encoding. In tegenstelling tot een machine kunnen wij direct op ons scherm zien wanneer een tekst door de vleesmolen is gegaan :).
- Ariën - op 12/10/2018 10:20:24:
Wat zijn dan de stappen om het te kunnen analyseren en te debuggen. Ik vind het zonde van mijn tijd om 10.000 records aan berichten door te spitten.
Je hebt geen 10.000 records nodig, maar slechts één of enkele instanties waar het misgaat om te kunnen hercontrueren wat er gebeurt.
Dit heb ik ook al min of meer eerder uitgelegd, maar ik zal nogmaals een poging ondernemen.
Gegeven een tekstpassage waar iets mis mee is, deze staat waarschijnlijk ergens in een kolom in een databasetabel. Noem dit opzet A.
Wat je nu vervolgens doet is deze situatie opnieuw creëren maar dan op de goede manier door alle character encoderingen in de pas te laten lopen en expliciet in te stellen. Dus alles van het opbouwen van de pagina tot het weergeven van de data zorg je gewoon dat dit van begin tot eind klopt. Dat kan redelijk eenvoudig. Nu heb je dus een (minimale) kloppende opzet B.
Vervolgens kun je deze situaties met elkaar gaan vergelijken. Dit zonder de werking van opzet A te veranderen, we hebben immers nog niet vastgesteld wat er mis is!
Wat we hier concreet doen is kijken naar de wijze waarop de tekst daadwerkelijk staat opgeslagen in het geheugen. Dit doen we met de PHP-functie bin2hex(), hiermee kun je binaire data hexadecimaal representeren. Het equivalent in MySQL is HEX(). Bijkomend voordeel is dat deze hexadecimale representatie ongevoelig is voor nuances tussen character encoderingen.
Nu kunnen we dus:
- met HEX() aan de database-zijde kijken (in zowel opzet A als B) hoe de oorspronkelijke organisatie is
- met bin2hex() aan de PHP-zijde kijken (in zowel opzet A als B) hoe het uiteindelijk de database uitkomt
In opzet B zou de HEX() waarde van de tekstkolom in de database hetzelfde moeten zijn als de bin2hex() waarde van de uitgespuugde tekst omdat er nergens in dat hele verhaal onder water vertalingen uitgevoerd zouden moeten zijn, alle character encoderingen waren immers gelijk geschakeld.
Dan kun je dat dus vergelijken met opzet A en na kunnen gaan waar er een verandering plaatsvindt, en hoe deze afwijkt van opzet B.
Daarna is het zaak om de "foute" vertaling van B naar A opnieuw te creëren waarmee je in principe bewijst hoe het precies fout is gelopen. En dit kun je controleren aan de hand van de hexadecimale waarden.
Tot slot verzin je iets waarin je de omgekeerde vertaalslag (van A naar B) bewerkstelligt. Dit is dan de eenmalige conversie die je uitvoert.
En dan moet je er natuurlijk voor zorgen dat vanaf dat moment de DATA op de goede manier de database in gaat door het repareren van set_charset(), meta-tag of header(), accept-charset in formulieren et cetera (dus in wezen wat je in opzet B deed).
Nota bene: als er na al deze tests uitrolt dat er niets fout gaat dan betekent dat dus dat er op een andere plek iets (grandioos) misgaat.
Enne, dit is nog steeds actueel (2003):
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Gewijzigd op 13/10/2018 15:20:31 door Thomas van den Heuvel
Gewijzigd op 13/10/2018 14:34:25 door Thomas van den Heuvel
- Ariën - op 13/10/2018 15:20:14:
Inmiddels heb ik gezien dat ik nog geen character-encoding meegeef aan mijn data, en dat deze in MySQL als latin1-collatie opgeslagen staat. Volgens mij moet de stap naar UTF-8 niet zo heel groot zijn, als ik mij niet vergis na alles door te hebben gelezen.
Niet helemaal. Als je geen character encoding meegeeft na het maken van een verbinding, dan wordt een default character encoding verondersteld, dit is doorgaans latin1, tenzij anders geconfigureerd. Omdat je niet uit kunt gaan van een "standaard" default is het eigenlijk bijna altijd beter om deze expliciet in te stellen.
Dit heeft wel een aantal consequenties.
Indien je tabellen gedefinieerd zijn als utf8 (of equivalent) dan zal MySQL automatisch alle data die zij binnen krijgt voor wegschrijven converteren naar utf8. Immers: MySQL gaat er vanuit dat jij alles in latin1 aanlevert. Gevolg: alle data staat dubbel utf8-geëncodeerd in de database. Nu heb je daar op heden mogelijk geen last van gehad omdat als jij data opvraagt uit je database MySQL ziet dat je wilt communiceren middels latin1. De dubbele encoding wordt dan weer ongedaan gemaakt omdat er een eenmalige vertaling terug plaatsvindt van "utf8" naar "latin1".
Daarnaast werkt je escaping-functionaliteit mogelijk niet goed, omdat deze latin1 veronderstelt terwijl je met (dubbel geëncodeerde) utf8-data werkt.
Als je nu klakkeloos een set_charset() statement toevoegt kom je in de situatie terecht waarin je data op den duur mogelijk deels verkeerd en deels juist geëncodeerd is waardoor het een hels karwei wordt om alles recht te trekken. Het is daarom zaak de goede volgorde aan te houden:
1. identificeer het precieze probleem
2. voer een eenmalige conversie uit en tegelijkertijd
3. repareer je code zodat alles vanaf dat moment juist wordt weggeschreven
Een collatie is trouwens iets compleets anders als een character encoding. (interne link)
EDIT: MySQL werkt eigenlijk best vlekkeloos MITS jij er zorg voor draagt dat je communiceert volgens de ingestelde character encoding. Als deze niet klopt, dan kan MySQL op geen enkele manier haar werk goed verrichten, en ben je in principe zelf diegene die alle stront veroorzaakt.
Gewijzigd op 13/10/2018 16:56:07 door Thomas van den Heuvel