CSV Mailreport kann nicht mehr in Excel importiert werden

Hallo,

seid wir von Matomo 3 auf jetzt Version 4.3.1 umgestiegen sind, können unsere Mailreportempfänger die CSV Datei nicht mehr in Excel importieren. In Version 3 wurde das Komma als Trennzeichen ohne Probleme erkannt. Jetzt bei Version 4 erkennt Excel einen Doppelpunkt als Trennzeichen. Stellt man auf Komma um, werden alle Daten ab der zweiten Spalte abgeschnitten.

Wurde hier etwas am Format geändert? Hängt das evtl damit zusammen, dass wir die Datenbanktabellen noch nicht auf den utf8mb4 Zeichensatz konvertiert haben?

Gruß
Pete

Hallo,

Ich wüsste nicht, dass sich dazu in letzter Zeit irgendetwas geändert hat.

Die einzige Änderung ist, dass seit 4.3.0 Matomo auch TSV (also Tab-getrennte) Dateien im E-Mail Report verschicken kann.

CSV-Dateien in Excel ist ein wirklich seltsames Thema (und ich habe auch kein Excel um es testen zu können), aber Matomo sollte schon immer die Dateien in dem seltsamen Format, welches Excel erwartet (mit BOM am Dateianfang), generieren.
Du könntest vielleicht eine alte CSV-Datei aus einem alten Report mit einer neuen vergleichen, indem du sie in einem Texteditor öffnest. Dann sollte ja recht schnell auffallen, wenn etwas anders ist.

Hallo Lukas,

vielen Dank für die schnelle Antwort!

Das mit dem Vergleich in einem Texteditor habe ich schon gemacht. Die Dateien sehen absolut gleich aus. Außer, dass es bei manchen Reports jetzt zusätzliche Datenfelder gibt, hat sich nichts geändert.
Deshalb verstehe ich nicht warum der Import nicht mehr klappt :frowning_face:

Einen Gedanken für ein sehr spezifisches Problem habe ich noch:

Kannst du schauen, ob es nur die CSVs in E-Mails betrifft? Wenn die von der API noch funktioniert, könnte es einen anderen Grund haben:
Seit Matomo 4 wird anstelle von der alten E-Mail library, phpmailer zum Versenden von E-Mails verwendet. Vielleicht geht irgendwo im Prozess aus der CSV einen Anhang zu machen die UTF-16LE mit BOM Kodierung verloren und die CSV im Anhang ist nur mehr eine “normale” UTF-8 Datei, welche Excel sich weigert richtig zu interpretieren.

Tatsächlich ist die CSV-Datei, die Matomo im Anhang des E-Mail reports schickt eine normale UTF-8 Textdatei.

Die Frage ist nur, ob das vorher anders war. Ich habe leider keine Matomo 3 instanz gerade in der Nähe um es zu testen.

Ich habe jetzt noch ein bisschen rum probiert. Folgende Fakten:

  1. CSV Dateien aus Mailreports aus der Version 3 waren im ANSI-Format (1252) und werden von Excel eindeutig als kommasepariert erkannt und einwandfrei importiert.

  2. CSV Dateien, welche per API in der Version 3 exportiert wurden, sind in UTF-8. Diese werden von Excel nicht als UTF-8 erkannt, aber als kommasepariert und nach der Umstellung auf ANSI (1252) auch einwandfrei importiert.

  3. CSV Dateien für die Mailberichte in der Version 4, egal ob per Mail versendet oder über die API geladen, sind in UTF-8. Diese werden von Excel nicht als UTF-8 erkannt sondern als ANSI. Wenn man in Excel UTF-8 auswählt, werden alle Zeichen korrekt dargestellt. Als Trennzeichen erkennt Excel den Doppelpunkt. Stellt man auf das Komma als Trennzeichen um, werden alle Daten ab der zweiten Spalte abgeschnitten.

Ich bin etwas ratlos.

Hallo,

Ich bin mir ziemlich sicher, dass die Matomo API (ohne &convertToUnicode=0) nicht UTF-8 CSVs sondern nur UTF-16 CSVs ausgibt (um eben mit Excel kompatibel zu sein)

Siehe zum Beispiel hier:

➜  ~/tmp curl "https://demo.matomo.cloud/index.php?date=yesterday&expanded=1&filter_limit=100&format=CSV&idSite=1&language=en&method=Actions.getPageUrls&module=API&period=day&segment=&token_auth=anonymous&translateColumnNames=1" -o output.csv
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 27590    0 27590    0     0  75177      0 --:--:-- --:--:-- --:--:-- 75177
➜  ~/tmp file -kr output.csv
output.csv: CSV text
- , Little-endian UTF-16 Unicode text, with very long lines
➜  ~/tmp hexdump output.csv -n 16
0000000 feff 004c 0061 0062 0065 006c 002c 0055
0000010