Es gibt mehrere JS-Bibliotheken, die den Export nach Excel ermöglichen. Was aber, wenn wir einen minimalistischen Ansatz verfolgen und zusätzliche Abhängigkeiten vermeiden möchten?

Der einfachste Ansatz wäre, eine CSV-Datei aus JSON zu erstellen, die problemlos in Excel geöffnet werden kann.

Aber bevor ich die Konvertierungslogik zeige, wollen wir verstehen, was CSV ist und welche Codierung wir beim Erstellen einer CSV-Datei verwenden sollen.

CSV-Format

Dieses allgemeine RFC 4180-Format und der MIME-Typ für CSV-Dateien (Comma-Separated Values) legen die Definition des CSV-Formats fest. Beachten Sie, dass dies nur eine Notiz ist, da das CSV-Format nicht offiziell standardisiert ist.

Hauptdefinitionen

1. Jeder Datensatz befindet sich in einer separaten Zeile, getrennt durch einen Zeilenumbruch (CRLF).
2. Der letzte Datensatz in der Datei kann einen Zeilenumbruch am Ende haben oder auch nicht.
3. Der Header sollte in der gesamten Datei die gleiche Anzahl von Feldern enthalten.
4. Jedes Feld kann in doppelte Anführungszeichen gesetzt werden oder auch nicht.
5. Felder, die Zeilenumbrüche (CRLF), doppelte Anführungszeichen und Kommas enthalten, sollten in doppelte Anführungszeichen eingeschlossen werden.
6. Wenn doppelte Anführungszeichen zum Einschließen von Feldern verwendet werden, muss ein doppeltes Anführungszeichen, das innerhalb eines Felds erscheint, durch ein vorangehendes weiteres doppeltes Anführungszeichen maskiert werden.

Codierung

In meinen JSON-Daten habe ich Zeichen æ å ø aus dem Zeichensatz ISO Latin-1 (ISO/IEC 8859-1), die beim Erstellen einer CSV-Datei berücksichtigt werden müssen.

Einige Auszüge aus der Unicode®-Standardversion 15.0, die Sie berücksichtigen sollten.

Unicode vs. UTF-8/16/32

Aus der Unicode®-Standardversion 15.0:

• Unicode ist der universelle Zeichenkodierungsstandard für geschriebene Zeichen und Texte und enthält 149.186 Zeichen aus den Skripten der Welt.
• Unicode-Zeichen werden in einer von drei Codierungsformen dargestellt: einer 32-Bit-Form (UTF-32), einer 16-Bit-Form (UTF-16) und einer 8-Bit-Form (UTF-8).
• Das Unicode-Konsortium befürwortet uneingeschränkt die Verwendung einer der drei Unicode-Codierungsformen als konforme Methode zur Implementierung des Unicode-Standards. Es ist wichtig, nicht in die Falle zu tappen und beispielsweise zu versuchen, zwischen „UTF-8 und Unicode“ zu unterscheiden. UTF-8, UTF-16 und UTF-32 sind alle gleichermaßen gültige und konforme Methoden zur Implementierung der codierten Zeichen des Unicode-Standards.

Byte Order Mark (BOM)

• Das für die Bytereihenfolgemarkierung verwendete Zeichen U FEFF (UTF-8 EF BB BF) wird als No-Break-Leerzeichen mit der Breite Null bezeichnet.
• Die UTF-16- und UTF-32-Codierungsformen von Unicode-Klartext reagieren empfindlich auf die Bytereihenfolge, die beim Schreiben von Daten in eine Datei verwendet wird.
• Identifizierung der Bytesequenz am Anfang von a Der Datenstrom kann als nahezu sicherer Hinweis darauf gewertet werden, dass der Datenstrom das UTF-8-Codierungsschema verwendet.

Kurz gesagt: Durch das Hinzufügen eines ununterbrochenen Leerzeichens mit der Breite Null vor der CSV-Zeichenfolge wird Excel dazu gezwungen, die UTF-8-Kodierung anstelle von 1252 anzuwenden: Westeuropäisch (Windows) oder eine andere Kodierung, die Excel wählt, wenn das U-FEFF-Zeichen lautet nicht bereitgestellt.

Ich werde den Unterschied zwischen der Erstellung einer CSV-Datei mit Null-Breite-No-Break-Leerzeichen und ohne Leerzeichen im nächsten Beitrag dieser Serie zeigen...