Door
Jan te Pas
op 11-10-2018 19:04
gewijzigd op 11-10-2018 19:05
2.587 views
Ik heb een database overgezet. Draaide op PHP 7 en gaat naar PHP 7. Ik heb de data geimporteerd. In de myPHPmanager zie ik de tekst goed in het veld staan. De codering van het veld is utf8mb4_bin. Nu roep ik de inhoud op in een pagina. En dan krijg ik ge�nventariseerd te zien ipv geïnventariseerd.
De codering in de pagina is utf-8.
Weet iemand hoe ik dit rechtzet, of wat er gebeurd is?
@Thomas,
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.
Als je tussentijd dus een set_charset() gebruikt, en je dus 'je data mee om zeept helpt'. 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.
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.
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.
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.
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
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.
