Excel lesen wie CSV

[OnDemand]

Hi! Wir lesen aktuell CSV Dateien mit Univocity ein. Gibt es iiirgendeine Libary mit der ich Excel Dateien genau so einfach einlesen kann, wie ich es mit CSV Dateien mache? Finde nur sehr komplizierte Frameworks, vermutlich ist es auch einfach kompliziert.

Hiermit kenne ist es, aber das ist zellenweise, nich zeilenweise https://www.baeldung.com/java-microsoft-excel

 

[Robert Zenz]

Apache POI ist glaube ich so ziemlich das einzige in der Java Welt das Microsoft Excel gut lesen kann. Die Eigenheiten vom Format schlagen halt doch durch, ganz so einfach wie eine CSV lesen wird es nicht werden.

Oder wenn du ganz, ganz, ganz mutig bist, ich glaube es gab einen ODBC Treiber mit dem man Excel Dateien wie Datenbanken ansprechen konnte.

 

[OnDemand]

Oder wenn du ganz, ganz, ganz mutig bist, ich glaube es gab einen ODBC Treiber mit dem man Excel Dateien wie Datenbanken ansprechen konnte.

Klingt nach "Fummelei" ne das ist echt murks. Dann schaue ich mal ob man die Excel nicht vorher als CSV speichern kann dann gehts einfacher

 

[KonradN]

Also ich kenne die Funnktionalität von Univocity nicht, aber CSV Dateien einlesen kann ein ganz schöner Murks sein und gerade wenn Du Excel Dateien konvertierst kann das problematisch werden.

a) CSV (comma separated values) baut Excel mit ; statt , - Du kannst also unterschiedliche Formate bekommen.
b) Du hast Strings in Quotes, aber was ist, wenn in dem Text ein Quote vorkommt?
c) Darstellung - was ist denn 2/3/2022 - ist das der Kommende 2. März oder der vergangene 3. Februar? Ist das 1.000 eine 1000 mit tausenderpunkt oder ist es ein 1,0 nur eben mit 3 Nachkommastellen. Ok, letzteres ist an den Haaren herbei gezogen, den bei Excel kommt das nicht vor - ersteres ist nur eine Darstellung und kein Bestandteil vom Wert und letzteres wäre einfach eine 1 ... Aber das ist Excel typisch. Das Datum wird nach regionalen Settings in die csv geschrieben meine ich. Der Fall bleibt also.

Ich hatte mir daher vor langer Zeit einmal einen eigenen CSV Reader geschrieben, der halt erst die Zeilen analsysiert hat um zu schauen, ob da , oder ; verwendet werden. Dann habe ich bei Feldern, die mit einem Quote anfangen, immer nach dem schließenden Quote gesucht (das ist ein Quote mit Trenner danach). Nicht perfekt aber hat die Einlesequote deutlich verbessert.
Aber gewisse Fälle durften nicht vorkommen wie z.B.: "Ich sagte "Tschüss", ging ich nach Hause und legte mich ins Bett."

Bei Datenübertragungen haben wir immer versucht eben auf CSV zu verzichten. Von Excel (Einem Format, dass Felder sauber trennt und Dir sogar den Typ sicher sagt!) hin zu einem reinen text Format.

(Und ja - mir ist bewusst, dass ich da mal wieder alleine stehen werde. Die Diskussionen hatten wir alle schon und man wird mir Unverständnis zeigen, da es ja eine CSV Standard gibt, der irgendwann lange nach Excel und Co geschrieben wurde und nur sehr wenig Leute interessiert. Aber ich hatte da diverse Erlebnisse in der Vergangenheit mit nicht auswertbaren Dateien und da war ich dann froh, dass da dann schnell nach Excel umgestellt wurde.)

Und wenn Du wirklich nur die Excel Datei wie eine CSV Datei auslesen willst, dann mach das doch einfach. Auch mit POI ist das keine wirkliche Fummelei sondern Code, der sehr einfach und schnell geschrieben werden kann. (Im Gegensatz zu der Fummelei bei CSV, die ich erlebt habe!)
Wobei das ja evtl. diese erwähnte Library ja schon für Dich macht.

 

[OnDemand]

HI, Univocity macht das mega einfach. Es erkennt Quotes und Trennzeichen automatisch, man kann es aber auch als Parameter übergeben usw. Wirklich extrem easy und zuverlässig. Habe zuvor auch immer per Hand geparsed aber das ist ne Katastrophe gewesen. Wir verarbeiten jeden Tag mindestens 10 verschiedene CSV Dateien und haben nie Probleme - ausser die CSV ist mal kaputt.
Excel muss ich mir mal ansehen mit POI, danke. Aber der Aufwand ist vermutlich zu hoch, da komm ich besser alle paar Wochen die Excel als CSV zu speichern und einzulesen.

Mit Datum hast du Recht, das ist murks. Aber brauchen wir zum Glück nicht.

 

[mihe7]

Aber der Aufwand ist vermutlich zu hoch, da komm ich besser alle paar Wochen die Excel als CSV zu speichern und einzulesen.

POI ist vom Aufwand her überschaubar. Das Beispiel unter 3.1 von Baeldung zeigt ja schon das Grundgerüst. Das Lesen der Zelle (switch) noch in eine Methode auslagern, dann sollte das schon sehr gut passen.

Allerdings muss man ein wenig aufpassen, was leere Zeilen und Spalten betrifft (s. auch https://www.baeldung.com/java-excel-find-last-row).

 

[mihe7]

Und ja - mir ist bewusst, dass ich da mal wieder alleine stehen werde. Die Diskussionen hatten wir alle schon und man wird mir Unverständnis zeigen, da es ja eine CSV Standard gibt, der irgendwann lange nach Excel und Co geschrieben wurde und nur sehr wenig Leute interessiert. Aber ich hatte da diverse Erlebnisse in der Vergangenheit mit nicht auswertbaren Dateien und da war ich dann froh, dass da dann schnell nach Excel umgestellt wurde.

Halt Dich fest: das beste ist XML.

Ja, ich weiß, XML ist "out" aber mir zeige mal einer ein Standardtextformat, das Schemadefinitionen à la XSD ermöglicht. JSON-Schema geht in die Richtung, ist aber in bestimmten Bereichen (Datentypen) nicht so stark wie XSD. Und XML kann man mit Java sehr schön verarbeiten, insbesondere wenn man sich die Klassen generieren lässt.

 

[KonradN]

Halt Dich fest: das beste ist XML.

Jaaaaaa!!!

Da rennst Du bei mir offene Türen ein. Wir haben mal ein Produkt entwickelt, das massiv mit XML und xslt gearbeitet hat. Da wurde in erster Linie aus mehr oder weniger beliebigen Quellen Daten in XML eingelesen und dann mit xslt verarbeitet. Um dann halt im Endeffekt Dinge umzusetzen.

Es gab dann schlicht etwas, das wir Policies genannt haben, was aber unter dem Strich ein xslt war, das Daten aus Quellen abgeglichen hat um dann etwas zu machen. Wenn also ein User existiert im AD, dann muss er gewisse Dinge haben ... teilweise in Abhängigkeit von Gruppen. Die User wurden also einfach abgeglichen mit einem Identity System und das, was dann in dem AD Umfeld gemacht werden musste, wurde automatisch gemacht. Wenn es da Probleme gab: Kein Thema - beim nächsten Durchlauf wurde es erneut probiert ...

Und das halt nicht als Script auf irgend einem System eines Admins, von dem außer ihm niemand etwas weiss oder so sondern zentral in einem System, das die Automatisierung gemacht hat.

Das nur als ein Beispiel, wobei sich sehr viele Policies um AD / User und deren Gruppen drehten. Das ist halt etwas, das große Firmen als Prozess haben: User braucht eine Gruppe oder muss da raus. Da gibt es die User Administration und den Passierschein A38 und damit geht alles. Und statt immer neue Prozesse zu erfinden hat man sich da einfach mit vielen Dingen drangehängt.

Ach ja - es gibt so Projekte, an die erinnert man sich gerne