CSV Import in database // Excel versus Google

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

- DHU -

- DHU -

17/02/2020 09:35:00
Quote Anchor link
Goedemorgen allemaal,

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?
 
PHP hulp

PHP hulp

02/02/2023 03:18:24
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 09:42:05
Quote Anchor link
En als je het via MySQL zelf importeert?
 
- DHU -

- DHU -

17/02/2020 10:10:34
Quote Anchor link
- 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....
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 10:12:59
Quote Anchor link
Dan moet excel ze ook in UTF-8 wegschrijven. En dat gebeurt blijkbaar niet.
 
- DHU -

- DHU -

17/02/2020 10:15:13
Quote Anchor link
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...

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 :-) )
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 10:17:12
Quote Anchor link
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')
Gewijzigd op 17/02/2020 10:23:51 door - Ariën -
 
- DHU -

- DHU -

17/02/2020 10:23:50
Quote Anchor link
- 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
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 10:25:31
Quote Anchor link
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.
Gewijzigd op 17/02/2020 12:00:51 door - Ariën -
 
Jan R

Jan R

17/02/2020 10:28:00
Quote Anchor link
Bij mij staat er nogtans in Excel "csv UTF-8(door komma's gescheiden)(*.csv)"

Toevoeging op 17/02/2020 10:29:08:

Zie ook: https://docs.microsoft.com/en-us/office/vba/api/excel.xlfileformat
 
Thomas van den Heuvel

Thomas van den Heuvel

17/02/2020 15:46:44
Quote Anchor link
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
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 15:49:09
Quote Anchor link
@Thomas: Maar stel dat die partij geen know-how heeft en dit niet in UTF-8 kan aanleveren. Dan voldoet een tussentijdse conversie met iconv toch ook?
 
Thomas van den Heuvel

Thomas van den Heuvel

17/02/2020 16:15:22
Quote Anchor link
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 :)
Gewijzigd op 17/02/2020 16:16:47 door Thomas van den Heuvel
 
- DHU -

- DHU -

17/02/2020 20:01:06
Quote Anchor link
Thomas van den Heuvel op 17/02/2020 15:46:44:
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 :)



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.
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 20:20:15
Quote Anchor link
Ik neem aan dat je ook in PHP de UTF-8 header meegeeft, en dat je dit ook in je meta-tag meegeeft?
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<meta charset="UTF-8">


En dit:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
header('Content-Type: text/html; charset=utf-8');
?>


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 -
 
- DHU -

- DHU -

17/02/2020 20:27:37
Quote Anchor link
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.
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 20:30:35
Quote Anchor link
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:

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.
 
- DHU -

- DHU -

17/02/2020 20:36:54
Quote Anchor link
- 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:

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.
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 20:44:16
Quote Anchor link
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?
Gewijzigd op 17/02/2020 20:48:26 door - Ariën -
 
- DHU -

- DHU -

17/02/2020 21:11:22
Quote Anchor link
- 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 ik geprobeerd... maar eerlijk gezegd weet ik niet hoe ik dat kan achterhalen
 
- Ariën  -
Beheerder

- Ariën -

17/02/2020 21:16:55
Quote Anchor link
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.
 
- DHU -

- DHU -

17/02/2020 21:26:30
Quote Anchor link
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
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.