Foute karakters
In de database is het nog steeds okee, althans voor zover ik kan inschatten. Een select van de tabel, vanuit een ascii terminal (putty) geeft dit:
MariaDB [vaarweginfo]> select distinct land from vaarweginfo;
land
+-----------+
Nederland
België
Frankrijk
(als ik code tags hier omheen zet verdwijnt de ë compleet??)
De webpagina haalt het land op uit een tabel en toont België dan als België
Heeft onder MySQL en php5 tot dan toe goed gewerkt. Waar moet ik dit zoeken?
Gewijzigd op 02/12/2019 12:20:38 door Aad B
Hoe heb je dit ingesteld in je site?
Gewijzigd op 02/12/2019 12:25:00 door - Ariën -
Gewijzigd op 02/12/2019 12:34:07 door Aad B
Ik neem aan dat je daar ook netjes UTF-8 afdwingt? Of gebruik je nog het beperkte iso-8859-X? En hoe staan de collaties van je databasetabellen?
Gewijzigd op 02/12/2019 13:04:22 door - Ariën -
Als ik jouw was zou ik het toch even goed uitzoeken voordat je allemaal rotzooi in je database staat te pompen en je nog verder van huis bent....
Gewijzigd op 02/12/2019 13:54:45 door - Ariën -
NB: het volgende verhaal gaat uit van een database(tabel) met een utf8(mb4) encodering. Idealiter lopen alle character encoderingen (HTML document, database-connectie, database, database-tabel, database-kolom en last but not least de encodering van de data in deze kolom zelf) alle in de pas. GA DIT NA. Je kunt niet zomaar ergens "UTF-8" neerzetten in plaats van "ISO-whatever" en dan doen alsof daarmee de kous af is :p. Dit is echt het onheil over je afroepen.
---
De makkelijkste manier om na te gaan of alles ok is is door een check te doen hoe dit op byteniveau staat opgeslagen. Dit is namelijk een test die niet afhankelijk is van een specifieke character encoding en onafhankelijk van een ingestelde character encodering altijd hetzelfde resultaat oplevert. Dit stelt je dus in staat afwijkingen te constateren op het moment dat er op verschillende plekken verschillende encoderingen worden gebruikt. Dit is onwenselijk.
In MySQL doe je dit met de functie HEX() en in PHP is dit bin2hex().
Het is zaak dat je dit zowel in MySQL als PHP controleert. Het kan namelijk zo zijn dat je niet op de goede manier met de database communiceert. MySQL compenseert dit achter de schermen, maar dit kan dus inderdaad wel resulteren in het wegschrijven van verkeerd geëncodeerde data. Dit komt dan pas naar buiten op het moment dat er wijzigingen (die mogelijk reparaties zijn omdat je dus voorheen op een verkeerde manier met je database sprak) worden aangebracht in de communicatie met je database. Of wanneer je je tabellen exporteert/migreert.
Om dit alles goed te simuleren is het dus ook zaak dat als je deze tests aan de PHP-kant uitvoert dat je op dezelfde manier een verbinding maakt met je database zoals je dat ook in je applicatie/website zou doen.
Wat je doet is het volgende: haal de kolom waarin de landnaam België staat opgeslagen als volgt op:
Code (php)
1
2
2
SELECT land, HEX(land) AS hex_land
FROM <tabelnaam>
FROM <tabelnaam>
Vervolgens controleer je de waarden in PHP. Hierbij geef je de hex-waarde uit de database weer en tevens het aan de PHP-kant gegenereerde equivalent met de oorspronkelijke land-kolom. Als het goed is komen deze twee waarden overeen. Indien dit niet het geval is houdt dit in dat de database zich genoodzaakt zag om vertalingen uit te voeren omdat de character encoding van de connectie afweek van de character encoding van de database-, tabel- of kolom-definitie.
Als $row het (associatief) record bevat toon je dit als volgt:
Code (php)
1
2
3
4
2
3
4
<?php
echo 'waarde in MySQL: '.$row['land_hex'].'<br>';
echo 'waarde in PHP: '.strtoupper(bin2hex($row['land']));
?>
echo 'waarde in MySQL: '.$row['land_hex'].'<br>';
echo 'waarde in PHP: '.strtoupper(bin2hex($row['land']));
?>
Beide waarde zouden -met een utf8(mb4) encodering- gelijk moeten zijn aan:
Code (php)
1
42656C6769C3AB
Hierbij gaat het eigenlijk uitsluiten om de laatste 4 karakters.
Mochten de waarden die uit worden gespuugd hiervan verschillen, of als de waarden onderling afwijken, dan zou ik je met klem aanraden om wat verder te graven om te zien waar deze verschillen vandaan komen.
En misschien loont het ook de moeite om de tabel "vaarweginfo" verder uit te normaliseren. Het lijkt mij beter om één landentabel aan te houden en hier middels id's aan te refereren, in plaats van letterlijke landnamen in de vaarweginfo-tabel op te slaan.
Aad B op 02/12/2019 12:12:34:
(als ik code tags hier omheen zet verdwijnt de ë compleet??)
Dit is waarschijnlijk een bug in deze website (interne link).
**snip**
Gewijzigd op 05/12/2019 08:31:27 door - Ariën -
Als je dit vervolgens encodeert als UTF-8 dan resulteert dit in België.
Het is waarschijnlijk interessant om deze import verder onder de loep te nemen. Vraag is wat de character encoding is van de aangeleverde data (A), wat de charset is van de tabel(len) waarin je deze data wegschrijft (B), en welke character encoding wordt verondersteld bij het maken van de connectie (C).
Stel dat je doel is om alles weg te schrijven als UTF-8 (utf8(mb4) in MySQL) omdat je applicatie en tabeldefinities (B) van UTF-8 gebruik maken. Maar tegelijkertijd weet je dat de aangeleverde data (A) een of andere ISO-encodering heeft. Dit kun je dan automatisch laten vertalen naar UTF-8 door bij het maken van de verbinding aan te geven (C) dat er data met een ISO-encodering over de lijn dient te gaan. Dit doe je met set_charset().
set_charset() vormt in wezen een contract tussen jouw applicatie en de database. Dit contract valt in twee delen uiteen:
- jij moet er voor zorgen dat alle data die je aanlevert aan de database van deze character encoding is
- de database draagt er zorg voor dat deze, naar beste vermogen, data teruggeeft in deze voorgeschreven character encoding
En dit staat los van de character encoding die wordt gebruikt in de database, tabel of kolom van deze data. Dit houdt in dat als er een discrepantie bestaat tussen de ingestelde character encoding van de verbinding en de definities van de database MySQL zelf vertalingen uitvoert. Dit geldt zowel voor het uitlezen als het wegschrijven. Dit kun je bij een import in jouw voordeel gebruiken.
Maar wat dus heel belangrijk is is dat je weet (met name bij het wegschrijven dus) welke character encoding deze data heeft (en deze wat mij betreft altijd expliciet instelt, om geen enkele ruimte open te laten voor een andere interpretatie). Als de data ISO-whatever is (is min of meer equivalent met latin1) en je middels set_charset() utf8 of equivalent instelt, en de tabel waarin je dit wegschrijft dezelfde charset heeft als in de connectie is ingesteld, dan gaat MySQL dus geen vertalingen uitvoeren en wordt je data weggeschreven als latin1 in een utf8 tabel.
Dit is ook hetgene wat waarschijnlijk is veranderd. Voorheen had je mogelijk geen set_charset() ingesteld, de default van MySQL (en zelfs MariaDB) was een hele tijd -en is dit misschien nog steeds- latin1. Dus de hierboven beschreven automatische vertaling verliep automatisch. De default character encoderingen in Debian zijn mogelijk al utf8(mb4), dus dan worden die vertalingen dus niet meer uitgevoerd omdat die al gelijk lopen met je database. Dit zou een verklaring kunnen zijn voor wat er nu gebeurt.
Dus omdat de defaults zijn veranderd werkt dit niet meer. Dit onderstreept wat mij betreft het belang om altijd expliciet een character encoding in te stellen bij het maken van een database-connectie.
Gewijzigd op 04/12/2019 16:36:40 door Thomas van den Heuvel
In het huidige script, dat overigens geheel naar wens werkt, kan ik geen set_charset() doen. Het ophaalscript is geen php. De methode van ophalen van de data via de Rijksawaterstaat API is in een bash script, een eenvoudige wget met wat parameters in .wgetrc
Wellicht kan ik daar nog een parameter opgeven zoals --header='Accept-Charset:
Ik ontvang een .csv file en als ik in linux in vi of cat de file bekijk zie ik netjes: België
Lokaal ben ik nu alles aan het afstemmen op UTF-8 (utf8(mb4)
De presentatie, een middels php gegenereerde web pagina, is sinds gisteren al in orde nadat ik de tip van SanThe en Arien kreeg om de header aan te passen.
Gewijzigd op 04/12/2019 21:17:21 door Aad B
Quote:
If the contents of the input file use a character set that differs from the default (noot: die van de server), it is usually preferable to specify the character set of the file by using the CHARACTER SET clause.
*knip*
Edit:
Zo, en hier stopt de discussie over deze site. Dit is dus geen aanwinst voor andermans topic. Dat iets niet werkt kan je melden op de juiste plek, maar een hele discussie of negatieve off-topic hierover hoort hier NIET!
Gewijzigd op 05/12/2019 08:30:31 door - Ariën -
@Ariën: De "knip" en edit????
Gewijzigd op 05/12/2019 09:40:27 door Aad B