Ik loopt tegen het volgende feit aan.. Wekelijks lees ik een 30-tal CSV bestanden in mijn database. Dit doe ik mbv de tool HeidiSQL.
Maar het zijn CSV die zijn gegenereed met Microsoft Excel. Wanneer ik deze importeer dan lukt dat niet met de Encodering UTF-8. Het importproces wordt dan afgekapt ivm de diakritische tekens.
Nu kom er bij toeval achter dat wanneer ik eerste het CSV bestand open met Google Spreadheets en vervolgens als CSV opsla en vervolgens deze importeer dan is geen vuiltje aan de lucht. Met twee vingers in de neus worden dan de bestanden met diakritsche tekens goed ingelezen..
Wanneer ik HeidiSQL de optie meegeef dat tijdens het importproces de tool de Encodering zelf laat bepalen dan wordt de Ecodering "latin1: cp1252 West European" gedecteerd. Met alle gevolgen van dien.
Het is ondoenlijk om alles eerst met handje in te lezen en als Google format weer op te slaan...
[size=xsmall]Toevoeging op 17/02/2020 10:16:21:[/size]
- Ariën - op 17/02/2020 10:12:59
Dan moet excel ze ook in UTF-8 wegschrijven. En dat gebeurt blijkbaar niet.
Dit zou natuurljk kunnen... (geen idee) maar op dat wegschrijfproces heb ik helaas geen invloed.. (voel de bui al aankomen :-) )
De bron ligt bij Excel, lijkt mij. Als die meteen alles in UTF-8 opslaat, moet alles prima gaan. Geen idee welke versie je hebt, maar het is mogelijk. Waarschijnlijk in het 'Save aa...' dialoogvenster via een knop.
Overigens bestaat er volgens mij niet iets van een 'Google-format'. Hoogstens dat die de encoding aanpast. (Via iets als 'iconv')
De bron ligt bij Excel, lijkt mij. Als die meteen alles in UTF-8 opslaat, moet alles prima gaan. Geen idee welke versie je hebt, maar het is mogelijk. Waarschijnlijk in het 'Save aa...' dialoogvenster via een knop.
ik ben niet de partij die de bestand in csv wegschrijft... dat gebeurt deels in Turkije en deels in Portugal
Misschien iets voor hun om de procedures aan te passen, of je moet tussentijds voor importeren aan de slag gaan met iconv. Eigenlijk wordt alles haast al aangeleverd in UTF-8. Zelf vele API's die ik gebruik doen dat.
Het importproces wordt dan afgekapt ivm de diakritische tekens.
Okay duidelijk... maar ook weer niet :p. Wat voor foutmeldingen krijg je precies?
Enne, UTF-8 is niet gelijkwaardig aan utf8 he, mogelijk kun je beter -als je dit al niet deed- utf8mb4 gebruiken voor ondersteuning van langere multibyte karakters?
Hoe ga ik dit nu fixen?
Ik denk dat de eerste stap is identificeren welke encodering nu precies wordt gebruikt en dat je tevens nagaat of jouw importproces wel helemaal klopt.
Als blijkt dat het laatste in orde is en er het e.e.a. schort aan het eerste dan zou de ideale oplossing zijn dat de partij die de bronbestanden beheert dit repareert.
Het probleem daarvan is dat dat mogelijk andere imports, waar inmiddels waarschijnlijk ook workarounds worden gebruikt, dan ook weer breken.
Maar wat dat betreft valt er weinig anders te doen dan gewoon zorg dragen dat als je zegt dat je UTF-8 materiaal aanlevert, dat dat dan ook daadwerkelijk gebeurt. Speaking of which: wat zegt deze partij er zelf over? Is het bekend in wat voor encodering ze alles aanleveren of aan zouden moeten leveren? Normaal zijn er voor dit soort dingen specificaties. En dus wat hierboven staat: wat voor database/tabellen gebruik je voor het wegschrijven en hoe communiceer je met de desbetreffende database (set_charset??)?
