ge�nventariseerd ipv geïnventariseerd

Is de encoding van de bestanden ook op UTF-8 ingesteld, en gebruikt de verbinding naar de database ook het kenmerk dat er UTF-8 wordt gebruikt? Enkel een collatie aanpassen is niet voldoende.

Hoi Ariën, dank alvast, maar zou ik dat moeten doen? Voordat ik de data wegschrijf? Welke opdracht moet ik DNA meegeven? Svp jouw hulp.

Hoe connect je nu met je database?

Dit is mijn connectie:

$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.

Hoi Thomas,
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.

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. ;-)

Ik gebruik dit :

<?php
$conn = new mysqli($servername, $username, $password, $dbname);
$conn->set_charset("utf8mb4");
?>

Hier leer ik van. Dank.

- 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.