Komma geht beim Schreiben ins csv verloren.

[Suppe]

Ich will einige Daten in eine CSV schreiben. Ich erwarten double Werte zwischen 3 und 1. Erhalten tute ich das hier:

durchschnittliche Abschnitte pro Rolle

2.0

19.705.882.352.941.100

2.193.548.387.096.770

2.206.896.551.724.130

18.823.529.411.764.700

Feb.25

21.785.714.285.714.200

2.0

23.448.275.862.068.900

215.625

Als erstes habe ich gedacht es liegt nur daran, dass Eclipse die amerikanische Notation verwende(Punkte trennen ganze Zahlen von Nachkommazahlen) und Excel die Mitteleuropäische Notation. Aber dass erklärt nicht die Celle Feb.25. Der Eigentliche Wert in dieser Zelle ist 01.02.2025. Excel macht daraus dann Feb.25.


Weis jemand woran das liegt?


Mein Code:

         FileWriter ausgabe;
         try {
      
             boolean ueberschreiben= false;  // ture um die Datei zu überschreiben, false um weiter zu schreiben
      
             ausgabe =new FileWriter("c:\\working\\loesungsMethadaten.csv",!ueberschreiben);  // true wird zum weiterschreiben genutzt
              
                ausgabe.write("\n");
      
              
             ausgabe.write(gesFlaeche + " ;" + (gesVerschnitt/gesFlaeche) + ";" + auswertung.durschnittlicheAbschnitte + ";" + auswertung.druchschnittlicheBahnen + ";" + auswertung.durchschnittlicheRollenLaenge + ";" );      
              
      
      
             for(int i=0; i<auswertung.hoechsterRollenVerschnitt.length;i++)
             {
                 ausgabe.write(auswertung.hoechsterRollenVerschnitt[i] + ";");
             }
      
             for(int i=0; i<auswertung.meisteAbschnitte.length;i++)
             {
                 ausgabe.write(auswertung.meisteAbschnitte[i] + ";");
             }
      
             for(int i=0; i< auswertung.verschnittNachNWuerfen.size();i++)
             {
                 ausgabe.write(auswertung.verschnittNachNWuerfen.get(i) + ";");
             }
      
      
      
             System.out.println(gesVerschnitt);
             System.out.println("????");
      
             ausgabe.close();
         }catch (IOException e){
             System.out.println("fehler");
             System.out.println(e.getMessage());
             System.out.println(e.getStackTrace());
      
         }

Ich öffne und schieße den Writer im Zuge des Programms mehrfach. Nur falls das ein Problem ist.

gruß
Suppe

 

[javampir]

hi,
was ist deine ausgabe? ist das das was du in excel siehst? mich irritieren die vielen punkte in einer zeile und dass die werte bestimmt nicht zwischen 1 und 3 sind. kannst du in excel das trennzeichen der csv angeben?
die datumskonvertierung liegt einfach mit der formatierung der einzelnen zelle zusammen.
du kannst ja die csv mal im texteditor öffnen, ob da alles stimmt.

 

[Harry Kane]

Ich will einige Daten in eine CSV schreiben. Ich erwarten double Werte zwischen 3 und 1. Erhalten tute ich das hier:

In welchem programm erhältst du den beschriebenen Output?
a) In einem Texteditor. Dann passiert in der Tat irgendwo etwas sehr komisches
oder b) Nach öffnen der CSV Datei in Excel. Dann hat das ganze aber nix mit Java zu tun! Meiner Erfahrung nach ist Excel manchmal sehr kreativ, wenn es darum geht, eine CSV-Datei zu importieren und den Spalten Formate zuzuordnen.

 

[Suppe]

Ich habe mir jetzt die Werte nochmal in WordPad angesehen. Da sehen genau die Gleichen Werte nur dass jeweils nach der ersten Ziffer ein Punkt kommt um von den Nachkommazahlen zu trennen. Offenbar erwartet Excel, dass ganze Zahlen und Nachkommazahlen durch ein komma getrennt sind. interpretiert den Punkt als Tausenderpunkt und ignoriert ihn.

Nur in der Zeile Feb.25 passiert etwas anderes da steht in Wordpad : 2.25. Aus irgendeinem Grund hat Excel da die 01. Dazu erfunden.

Demnach ist das Problem Excel-seitig. Wahrscheinlich gibt es dann bessere Orte an denen ich fragen kann.

 

[Harry Kane]

Ich vermute, die Excel-Importlogik sieht ungefär so aus:
Die Zahl enthält einen Dezimalpunkt, also wird erstmal versucht, sie als Datum zu interpretieren. Und bei der Zahl 2.25 ist die wahrscheinlichste Datums-Interpretation nun mal der Februar 2025.
Wenn die Zahl offensichtlich kein Datum ist, wird versucht, sie als Zahl zu interpretieren. Der Dezimalpunkt wird als Tausender-Trennzeichen interpretiert. Da dieser auf den Wert der Zahl keinen Einfluss hat, sondern es nur für den Benutzer leichter macht, die Zahl zu interpretieren, wird er zunächst mal ignoriert. Die Tatsache, dass der Dezimalpunkt eigentlich nicht als Tausender-Trennzeichen gemeint sein kann, weil er nicht oft genug vorkommt und ausserdem an der flaschen Stelle steht, wird stillschweigend ignoriere. Da der Benutzer durch den Dezimalpunkt angezeigt hat, dass er auf das Tausender-Trennzeichen Wert legt, passe ich das Zelleformat so an, dass das Tausender-Trennzeichen nach dem Import wieder angezeigt wird.

 

[eldrior]

Eine CSV Datei ist dahingehend vllt. nicht ganz so primitiv, wie sich das einige vorstellen. Excel arbeitet da nach einem Standard. Den kannst du bspw. hier lesen.
Ich würde dir empfehlen die CSV Datei mit einem bereits bestehenden Tool zu erzeugen bzw. einzulesen. Ich nutze dazu immer Apache Commons. Ist gut dokumentiert und auch nicht wirklich schwer zu nutzen.

Und nein, wenn Excel an der Stelle ein Problem hätte, hätten andere das bereits gemeldet und es wäre durch die Presse gegangen. Etwas wie CSV sollte auch MS fehlerfrei implementieren können. Wenn man aber ein Standardformat mit einem Standardprogramm öffnen möchte, die Datei aber nicht nach dem Standard erstellt, darf man sich nicht wundern, dass es nicht funktioniert

 

[JStein52]

Ich denke dass es genau so ist wie Harry Kane das beschreibt. Und das ist ja kein Fehler von Excel sondern ein ganz normales Feature. Warum sollte das durch die Presse gehen Eine CSV-Datei enthält nun mal keine Formatinformationen und dann hat Excel halt so seine Strategien was es damit veranstaltet.