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..
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 :)
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??)?
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.
[size=xsmall]Toevoeging op 17/02/2020 20:05:30:[/size]
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 :)
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.
ik kom toch niet eens toe aan al die coderingen die we hier allemaal aan het opsommen zijn... .om iets weer te kunnen geven dan zal ik eerst iets geimporteerd moeten hebben.. Dat is dus het punt... Dat gaat dus niet.
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.
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.
[size=xsmall]Toevoeging op 17/02/2020 20:31:36:[/size]
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.
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.
[size=xsmall]Toevoeging op 17/02/2020 20:31:36:[/size]
[quote="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.
[/quote]
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.
Je kan het in het old-skoel Notepad inladen, en kiezen voor 'Save as..', en dan zie je onderin of het ANSI of UTF-8 is. Eventueel kan je hier proberen het naar UTF-8 om te zetten. of het lukt weet ik niet, maar je kan het proberen en het scheelt je de stap van Google. En anders moet je toch eens kijken of het geautomatiseerd via iconv kan.
Nu gaan we ergens komen -) .... Notepad geeft aan dat het om ANSI gaat.... duh!!!
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
