CSV Import in database // Excel versus Google
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..
Hoe ga ik dit nu fixen? Iemand een wild guess?
- Ariën - op 17/02/2020 09:42:05:
En als je het via MySQL zelf importeert?
Gebeurt exact hetzelfde. de excel variant wordt afgebroken en de google variant niks aan het handje....
Het is ondoenlijk om alles eerst met handje in te lezen en als Google format weer op te slaan...
Toevoeging op 17/02/2020 10:16:21:
- 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 :-) )
Overigens bestaat er volgens mij niet iets van een 'Google-format'. Hoogstens dat die de encoding aanpast. (Via iets als 'iconv')
Gewijzigd op 17/02/2020 10:23:51 door - Ariën -
- Ariën - op 17/02/2020 10:17:12:
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
Gewijzigd op 17/02/2020 12:00:51 door - Ariën -
Toevoeging op 17/02/2020 10:29:08:
Zie ook: https://docs.microsoft.com/en-us/office/vba/api/excel.xlfileformat
Quote:
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?
Quote:
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??)?
Gewijzigd op 17/02/2020 15:48:01 door Thomas van den Heuvel
Dan is het per definitie All Bets Are Off.
iconv, Google Spreadsheets et cetera mogen dan werken, maar het zijn nog steeds alle workarounds. En omdat het blijkbaar ongewis is hoe data wordt aangeleverd, dan kan het op een dag mogelijk ook niet meer werken omdat er iets verandert of aanwezig is wat niet gerepareerd/geconverteerd kan worden, en omdat er (blijkbaar?) simpelweg geen afspraken over gemaakt zijn.
Dit alles is geboren uit onduidelijkheid over het bronmateriaal. Is het echt aan de afnemer om dit eerst helemaal te analyseren, dan mogelijk te converteren om het vervolgens te kunnen gebruiken? Dit klinkt niet echt als automatisering maar het simpelweg over de schutting gooien van een pakketje met de boodschap "zoek het maar uit".
Als die partij het echt niet kan/wil veranderen sja dan zullen die workarounds nodig blijven, maar ik zou dan de eerste gelegenheid zoeken om een alternatieve partij te zoeken waarmee wel afspraken te maken zijn en de huidige leverancier dan keihard laten vallen.
Je zou nooit op deze manier gedwongen moeten worden om voort te borduren op een slecht ontwerp, en dit zou je wat mij betreft ook nooit zomaar moeten/hoeven te accepteren. Als de IT'ers van deze partij ook maar een greintje verantwoordelijkheidsgevoel hebben dan zouden ze gewoon hun rotzooi moeten repareren.
EDIT: als daar dus daadwerkelijk sprake van is, dat staat nog even ter discussie :)
Gewijzigd op 17/02/2020 16:16:47 door Thomas van den Heuvel
Thomas van den Heuvel op 17/02/2020 15:46:44:
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?
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??)?
Quote:
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?
Quote:
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??)?
de database = utf8mb4_unicode_ci
de tabel = utf8mb4_unicode_ci
Wannner ik mijn connect.php anders dan de codering
$connection->set_charset('utf8') gebruik wordt de diakritische tekens niet juist weergegeven en krijg ik shizzel als "
Paul B?nziger" ipv Paul Bänziger. Daar ontkom ik dus niet aan.
De encodering in HeidiSQL staat op 'utf8: UTF-8 Unicode' maar kan ik eventueel instellen op 'utf8mb4: UTF-8 Unicode' echter dit maakt geen zak uit wanneer ik dan de Excel CSV inlees. De import wort afgekapt met de foutmelding:
SQL Fout (1300): Invalid utf8 character string: 'Hoogrecht extra goedkeurder ROLE:PROCES:Security co'
nu denk ik dat 'öordinator' afgekapt wordt.
Maar wanneer ik de Google CSV inlees gaat dit als een tierelier zonder ook maar ene foutmelding jast die de handel van 267992 regels in paar flutseconden naar binnen.
Toevoeging op 17/02/2020 20:05:30:
Thomas van den Heuvel op 17/02/2020 16:15:22:
Sja als die partij niet weet wat zij aan het doen is zijn we snel klaar :p.
Dan is het per definitie All Bets Are Off.
iconv, Google Spreadsheets et cetera mogen dan werken, maar het zijn nog steeds alle workarounds. En omdat het blijkbaar ongewis is hoe data wordt aangeleverd, dan kan het op een dag mogelijk ook niet meer werken omdat er iets verandert of aanwezig is wat niet gerepareerd/geconverteerd kan worden, en omdat er (blijkbaar?) simpelweg geen afspraken over gemaakt zijn.
Dit alles is geboren uit onduidelijkheid over het bronmateriaal. Is het echt aan de afnemer om dit eerst helemaal te analyseren, dan mogelijk te converteren om het vervolgens te kunnen gebruiken? Dit klinkt niet echt als automatisering maar het simpelweg over de schutting gooien van een pakketje met de boodschap "zoek het maar uit".
Als die partij het echt niet kan/wil veranderen sja dan zullen die workarounds nodig blijven, maar ik zou dan de eerste gelegenheid zoeken om een alternatieve partij te zoeken waarmee wel afspraken te maken zijn en de huidige leverancier dan keihard laten vallen.
Je zou nooit op deze manier gedwongen moeten worden om voort te borduren op een slecht ontwerp, en dit zou je wat mij betreft ook nooit zomaar moeten/hoeven te accepteren. Als de IT'ers van deze partij ook maar een greintje verantwoordelijkheidsgevoel hebben dan zouden ze gewoon hun rotzooi moeten repareren.
EDIT: als daar dus daadwerkelijk sprake van is, dat staat nog even ter discussie :)
Dan is het per definitie All Bets Are Off.
iconv, Google Spreadsheets et cetera mogen dan werken, maar het zijn nog steeds alle workarounds. En omdat het blijkbaar ongewis is hoe data wordt aangeleverd, dan kan het op een dag mogelijk ook niet meer werken omdat er iets verandert of aanwezig is wat niet gerepareerd/geconverteerd kan worden, en omdat er (blijkbaar?) simpelweg geen afspraken over gemaakt zijn.
Dit alles is geboren uit onduidelijkheid over het bronmateriaal. Is het echt aan de afnemer om dit eerst helemaal te analyseren, dan mogelijk te converteren om het vervolgens te kunnen gebruiken? Dit klinkt niet echt als automatisering maar het simpelweg over de schutting gooien van een pakketje met de boodschap "zoek het maar uit".
Als die partij het echt niet kan/wil veranderen sja dan zullen die workarounds nodig blijven, maar ik zou dan de eerste gelegenheid zoeken om een alternatieve partij te zoeken waarmee wel afspraken te maken zijn en de huidige leverancier dan keihard laten vallen.
Je zou nooit op deze manier gedwongen moeten worden om voort te borduren op een slecht ontwerp, en dit zou je wat mij betreft ook nooit zomaar moeten/hoeven te accepteren. Als de IT'ers van deze partij ook maar een greintje verantwoordelijkheidsgevoel hebben dan zouden ze gewoon hun rotzooi moeten repareren.
EDIT: als daar dus daadwerkelijk sprake van is, dat staat nog even ter discussie :)
De partij waar de data vandaan komt zit niet in een meewerkstand. Zij maken gebruik van SAP User interface waar de data te raadplegen en via GUI te muteren is. Meerder partijen die er mee moeten werken geven aan dat ze het op een andere manier willen. Daar wringt de schoen. Ik kan hier in dit forum over gaan discuseren. Ik wil daar discreet mee omgaan. Ze stellen hooghuit de extractiebestanden beschikbaar en dat is het dan.. niet meer. niet minder... Daar moeten we het mee doen.
Code (php)
1
<meta charset="UTF-8">
En dit:
Het zou mij niks verbazen dat Google dit via iconv converteert, en dat is ook de stap die jij kan overnemen.
Gewijzigd op 17/02/2020 20:22:46 door - Ariën -
het importeren is wat stuk loopt ongeacht hoe de de weergave dan is . Zo is er ook geen conversie met iconv aan de orde. Eerst de handel in een tabel zien te krijgen.
Indien het laatste: Zorg ervoor dat alles gelijk loopt. Er hoeft maar iets uit de pas te lopen, en je hebt allemaal troep.
Toevoeging op 17/02/2020 20:31:36:
Dirk Huizinga op 17/02/2020 20:27:37:
het importeren is wat stuk loopt ongeacht hoe de de weergave dan is . Zo is er ook geen conversie met iconv aan de orde.
En dus krijg je dan troep.
- Ariën - op 17/02/2020 20:30:35:
Wil je corrupte data in je database, of wil je alles fatsoenlijk hebben?
Indien het laatste: Zorg ervoor dat alles gelijk loopt. Er hoeft maar iets uit de pas te lopen, en je hebt allemaal troep.
Toevoeging op 17/02/2020 20:31:36:
En dus krijg je dan troep.
Indien het laatste: Zorg ervoor dat alles gelijk loopt. Er hoeft maar iets uit de pas te lopen, en je hebt allemaal troep.
Toevoeging op 17/02/2020 20:31:36:
Dirk Huizinga op 17/02/2020 20:27:37:
het importeren is wat stuk loopt ongeacht hoe de de weergave dan is . Zo is er ook geen conversie met iconv aan de orde.
En dus krijg je dan troep.
dat begrijp ik allemaal best hoor en je hebt daar gelijk in... maar het importeren is hier het vraagstuk en niet de encodering. Het ene heeft met de ander te maken. Maar het stuklopen staat los van van encodering.
heb je al gecontroleerd welke encoding de data van je leverancier is?
Gewijzigd op 17/02/2020 20:48:26 door - Ariën -
- Ariën - op 17/02/2020 20:44:16:
En als je wilt importeren, moet je wel schone data hebben. Importeren en encoderen zijn inderdaad verschillend.
heb je al gecontroleerd welke encoding de data van je leverancier is?
heb je al gecontroleerd welke encoding de data van je leverancier is?
heb ik geprobeerd... maar eerlijk gezegd weet ik niet hoe ik dat kan achterhalen
wanneer ik bestand wegschrijf maar dan als utf-8 raad je al wel zeker wat er gebeurt..
vlekkeloos......
Maar nu we weten waar het zit... de aanleverende partij niet in meewerkstandje staat .. hoe ga ik dit van het ene omvormen nar het andere?
Notepad vindt het niet heel leuk om 267992 in te moeten lezen... doet die wel 'n tijdje over...
het grote wijde wereld web eens gaan afstruinen of er ergens een convertertje bestaat die in een batch zo'n 30-tal bestanden kan converteren van ansi naar utf-8