andreasamsler
commented
2 years ago Wir haben herausgefunden, dass es in 5 von 11 CSV-Ressourcen der Personal- & Lohnstatistik (https://www.zh.ch/de/politik-staat/statistik-daten/datenkatalog.html#/datasets/1321@personalamt-kanton-zuerich) kryptisch angezeigte Sonderzeichen hat, wenn die CSVs mit Excel geöffnet werden.
Das Problem liess sich beheben, indem wir die CSVs mit UTF-8 with BOM anstatt wie - gemäss OGD-Leitlinien - mit UTF-8 enkodiert haben.
stadlaur
@stadlaur : soweit ich weiss, würden wir im Datenkatalog gerne mittelfristig eine Funktion einbauen, die einem erlaubt die csvs direkt als excel downzuloaden. Dafür wäre dann eine einheitliche UTF-8-Codierung sinnvoller.
@tlorusso : Ich bin kein encodings-Profi, aber soweit ich beurteilen kann wird BOM v.a. von Microsoft-Software benötigt um UTF 8 korrekt zu interpretieren. Da viele Leute die Daten in Excel öffnen ist das sicher ein wichtiger Use-case und man könnte es in der Hinsicht mit BOM publizieren. Aber ich habe schon mehrfach gelesen, das BOM eben auch Probleme verursachen kann ---, Stadt Zürich publiziert auch mit BOM:
@wadoli : Excel ist halt auch nicht konsistent zwischen den Versionen für verschiedene Sprachen, darum haben wir uns damals für Semikolon/Latin 1 entschieden, das wird dann zwar ohne Nachfrage geöffnet mit dem deutschsprachigen Excel auf unseren Client-Geräten beim Kanton (Baudirektion), aber führende Nullen (wichtig bei den GVZ-Nummern als Teil der Verwaltungseinheit) gehen z. B. trotzdem verloren :offener_mund::sausen:. Mit der englischsprachigen Version von Excel ist der Assistent notwendig. Nur LibreOffice macht Freude und schaltet immer unkompliziert einen Dialog vor.
@simgraworldwide : Merci für die Inputs. Ich lass das jetzt noch einen Moment stehen und schau, ob da noch etwas kommt, tendiere aber momentan dazu, die Files mit BOM zu publizieren, da ich davon ausgehe, dass die Mehrheit der Nutzenden die Daten wohl lediglich mit Excel verwendet. Und falls sich dann Nutzende melden, die das lieber ohne BOM hätten, wäre das ja leicht zu liefern... Allenfalls kommt aber auch noch eine Excel-Aufbereitung für Menschen in Frage, obwohl die in Frage kommenden Daten nicht sonderlich kompliziert zu lesen sind.
Peter (?) : Meine Erfahrung: UTF-8 mit BOM macht z.B. mit den R-base import funktionen z.B. read.table Probleme (nicht aber z.b. mit fread aus data.table). Andererseits scheint mir aber auch zentral, dass man sie auf der hierzulande üblichen Excel-Version problemlos öffnen kann. Eine Produktion von Excel auf der Grundlage von UTF-8 csv on the fly wäre natürlich optimal.