Problem mit CSV-Import in OpenOffice

[Sekundentakt]

Hallo Gemeinde,

ich konnte über die üblichen Suchmaschinen leider keine Informationen zum entsprechenden Thema finden.

Folgendes ist das SQL-Statement, mit dem die Datei erzeugt wird:

SELECT...
INTO OUTFILE "'../output"
				FIELDS 	TERMINATED BY "," ENCLOSED BY "'"
						LINES TERMINATED BY "\n"';

In OpenOffice stelle ich entsprechend Als Spaltentrenner "," und als Texttrenner ein einfaches Anführungszeichen ein.

Wenn ich das Ganze via SQL-Befehl wieder in eine Datenbank einspielen will, klappt das auch wunderbar. Die Daten werden richtig eingelesen.
In OpenOffice werden dagegen die Zeilen teilweise zerschossen.
In den Datensätzen der CSV-Datei kommen selbst auch Daten mit einfachen, wie auch doppelten Anführungszeichen vor.

Ich frage mich jetzt natürlich, ob die Datei falsch exportiert worden ist.
In die Datenbank wird sie schließlich mit der selben Datenbank-Software (MySQL) wieder eingespielt. MySQL könnte diesen Bug also selbst gefixed haben, ohne das es zu Inkompatibilitäten kommt.
Das das aber auf lange Sicht so geblieben wäre, kann ich mir nicht denken.

Die nächste Möglichkeit bestünde darin, dass OpenOffice hier die Daten falsch einliest und der Fehler bei Open Office liegt.

Das Problem entsteht genau dort, wo das letzte Zeichen eines Feldinhaltes ein einfaches Anführungszeichen ist. Ich vermute, dass sich dadurch beim Parsen irgendetwas verschiebt und erst dann wieder einrenkt, wenn die selbe Situation bei einem anderen Datensatz auftritt. Zumindest geht das aus meinen Beobachtungen hervor. Woher sollte OpenOffice auch wissen, dass das betroffene Zeichen noch zum Feldinhalt gehört?

Irgendeine Idee, wie man das via SQL lösen könnte?

ESCAPED BY hat bisher keine Wirkung gezeigt und möchte ich im Moment auch nicht verwenden, weil ich nicht weiß, wie ich es in SuperCSV einbringen soll.

Danke für jeden Ansatz!

Beste Grüße

EDIT: Zur Situation:
Die CSV-Datei wird aus der Datenbank exportiert und soll anschließend von einem Programm abgeholt und eingelesen werden.
Falls Dritte aber interessiert, wie die fertige CSV aussieht, warum auch immer, soll die Darstellung in Programmen wie OO korrekt laufen.
Da die Weiterverarbeitung zum ersten mal für mich mit SuperCSV erfolgt, will ich im Voraus sicherstellen, dass der Export auch korrekt funktioniert.
Ich will dadurch vermeiden, Fehler in SuperCSV-Code bzw. meiner Anwendung zu suchen, wenn diese Fehler von ganz anderen Stellen zu verantworten sind.

 

[ARadauer]

was passiert bei LINES TERMINATED BY "\r\n"';

?

 

[Sekundentakt]

Hi,

danke für Dein Feedback.
Ich hab's jetzt ausgiebig über verschiedene Wege getestet: Keine Veränderung.

 

[Sekundentakt]

So steht die vermeintliche Problemstelle in der CSV (Klartext, nicht OO-formatiert)

-Datamax-O\'Neil-

Die Bindestriche zu Beginn und Ende habe ich via SQL-Statement angeführt, weil ich wissen wollte, ob ein Problem mit dem einfachen Anführungsstrich am Ende der Zeile besteht. Dabei kam dann heraus, dass der Anführungsstrich gar nicht zum Datensatz gehört, sondern fälschlicherweise der Texttrenner angezeigt wird.

Interessanterweise wird in der OpenOffice Spalte folgendes angezeigt:

-Datamax-O\Neil-'

Die Zeile wird also nicht zerschossen, dafür aber nicht mehr richtig geparsed.

Eigentlich müsste es nämlich so aussehen:

-Datamax-O'Neil-

Kann es sein, dass das ein OO-Bug ist?

 

[ice-breaker]

poste doch mal die gesammte Zeile der CSV, die diesen Fehler verursacht.

 

[Sekundentakt]

Ich glaube, ich habe das Problem in OO gelöst. Zumindest für's erste.., wenn auch nicht zufriedenstellend.

FIELDS TERMINATED BY "^"
	LINES TERMINATED BY "\r\n"

Sobald ich spezifiziere, wie die Spalten "enclosed" werden sollen, gab es hier Fehler.

Nun werden die Spalten gar nicht mehr durch Zeichen umschlossen.

Der ENCLOSED BY - Befehl verursacht also Formatierungsfehler, da sowohl " als auch ' im Text vorkommen können.

Was mich wundert, ist, wie OO hier mit escpaten Werten umgeht.

Hier geht's wohl um ein ähnliches Problem.
csv files and text delimiter (View topic) • OpenOffice.org Community Forum

 

[Sekundentakt]

1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a \" quote",102.20
4,"a string containing a \", quote and comma",102.20

Ein Beispiel aus der offiziellen MySQL-Doku.

Wenn Du das in OO darstellen willst, wird's zerschossen.

 

[ice-breaker]

also ich hab eben mal mit PHP rumgespielt und dort den CSV-Export ausprobiert, folgendes wird von OO korrekt erkannt:

4,"a string containing a "", quote and comma",102.2

In der englischen Wikipedia finde ich dazu dann auch noch:

Fields with embedded double-quote characters must be enclosed within double-quote characters, and each of the embedded double-quote characters must be represented by a pair of double-quote characters.

also sieht das für mich nach fehlerhaftem Export durch MySQL aus oder Fehlbedienung.

 

[Sekundentakt]

Das habe ich schon fast befürchtet.

Ich möchte aber möglichst vermeiden, dass die Datei durch PHP oder Java selbst erstellt wird.
PHP, weil man da früher oder später in TimeOuts rennt und Java, weil es weniger verbreitet ist.

Bleibt also nur noch via replace im SQL-Statement einfache Anführungszeichen zu verdoppeln.
Oder?

EDIT: Soweit ich das sagen kann, funktioniert der Ansatz alle Spalten einem REPLACE zu unterziehen bisher ohne Probleme.

Der Outfile-Part der SQL-Anweisung enthält somit nur noch FIELDS TERMINATED BY und LINES TERMINATED BY. Alles andere funktionierte nicht fehlerfrei.