Unicode in SQL Server: Zeichen, Bytes und Datenverlust

Eine Umstellung auf nvarchar repariert keinen Text, der schon vor dem Einfügen in Fragezeichen umgewandelt wurde. Unicode-Korrektheit betrifft den gesamten Weg: Quelldekodierung, Anwendung, Treiberparameter, SQL-Ausdrücke, Spaltentyp und Exportkodierung müssen dieselben Zeichen erhalten.

Zeichen und Speicher unterscheiden

Bei nvarchar(n) bezeichnet n UTF-16-Bytepaare, nicht garantiert n sichtbare Zeichen. Ergänzende Zeichen können zwei Einheiten benötigen. Ein sichtbares Zeichen kann außerdem aus mehreren Codepunkten bestehen, beispielsweise Buchstabe plus kombinierender Akzent. Die sichtbare Anwendungsgrenze und die Speichergrenze der Datenbank sind deshalb nicht zwangsläufig gleich.

DECLARE @text nvarchar(20)=N'café ';
SELECT LEN(@text) AS LengthWithoutTrailingSpaces,
       DATALENGTH(@text) AS StorageBytes;
DECLARE @emoji nvarchar(2)=N'😀';
SELECT LEN(@emoji COLLATE Latin1_General_100_CI_AS_SC) AS Characters,
       DATALENGTH(@emoji) AS StorageBytes;

Die erste Messung zeigt, dass LEN nachgestellte Leerzeichen ignoriert, während DATALENGTH Speicherbytes misst. Für eine exakte Texterhaltung genügt LEN allein nicht. Die zweite Messung verwendet eine Kollation mit Unterstützung ergänzender Zeichen: Das Emoji zählt als ein Zeichen, belegt in nvarchar jedoch vier Bytes.

Das Präfix N erzeugt ein Unicode-Literal. Ohne N können Zeichen bereits beim Weg durch eine andere Codepage verloren gehen, bevor nvarchar zugewiesen wird. Auch parametrisierter Anwendungscode sollte den vorgesehenen Unicode-Typ ausdrücklich binden. Testen Sie echte nichtlateinische Texte, nicht ausschließlich ASCII-Namen.

nvarchar und UTF-8 gezielt vergleichen

SQL Server 2019 unterstützt UTF-8 für varchar mit passenden UTF-8-Kollationen. Dadurch werden bestehende varchar-Spalten nicht automatisch Unicode-fähig. Kollation und vollständiger Ausdruckspfad bleiben entscheidend. Bei varchar(n) ist n eine Bytegrenze; mehrbytige Zeichen reduzieren daher die mögliche Zeichenanzahl gegenüber ASCII.

UTF-8 kann bei überwiegend ASCII-Inhalt Platz sparen. Andere Schriftsysteme benötigen mehr Bytes pro Zeichen. Vergleichen Sie deshalb repräsentative Werte und Indexgrößen, statt pauschal eine Halbierung anzunehmen. Version, Spaltenlimits und Clientkompatibilität gehören zur Entscheidung.

Kodierung und Kollation können außerdem Eindeutigkeit beeinflussen. Vergleiche ohne Großschreibungs- oder Akzentunterscheidung können unterschiedliche Eingaben gleich behandeln. Umgekehrt können optisch gleiche Texte verschiedene Codepunktfolgen besitzen. Definieren Sie Normalisierung und Identität ausdrücklich; Unicode allein legt diese Fachregeln nicht fest.

Den vollständigen Weg prüfen

Erstellen Sie Testdaten mit Akzenten, Kyrillisch, CJK, Emoji, kombinierenden Zeichen, Anführungszeichen und relevanten Endleerzeichen. Senden Sie diese durch echte API, Parameterbindung, INSERT, SELECT, Serialisierung und Export. Vergleichen Sie die zurückgegebene Zeichenfolge mit dem Original und gegebenenfalls die Bytes. Ein erfolgreicher INSERT prüft nur einen Teil des Wegs.

Analysieren Sie vor einer Migration maximale Bytelängen und grenznahe Werte. Prüfen Sie abhängige Indizes, Constraints, berechnete Spalten und Integrationen mit alten varchar-Parametern. Eine Testkopie mit vollständigem Rückvergleich erkennt Kürzungen und Ersetzungen, die eine bloße Zeilenanzahl nicht zeigt.

Enthalten Altdaten bereits Ersatzzeichen, suchen Sie die ursprüngliche Quelle. Ein Typwechsel kann verlorenen Text nicht rekonstruieren. Stellen Sie ihn aus Originaldaten oder geprüften Backups wieder her und dokumentieren Sie nicht zuverlässig rekonstruierbare Zeilen.

Das Ziel ist eine überprüfbare Zusage: Unterstützte Eingaben kommen unverändert zurück, abgesehen von ausdrücklich vereinbarter Normalisierung. Prüfen Sie deshalb auch den Download und erneuten Import einer Datei, nicht nur die Weboberfläche. Treiber und Transformationsgrenzen sind ebenso wichtig wie die Spaltendefinition.

Vergleichen Sie bei einem Wechsel außerdem Sortierreihenfolge und bestehende eindeutige Schlüssel. Eine erfolgreiche Konvertierung aller Texte beweist nicht, dass dieselben Werte unter der neuen Kollation weiterhin unterschiedlich sind.

Technische Referenzen: Microsoft Learn: nvarchar · Microsoft Learn: Unicode and UTF-8 · Microsoft Learn: DATALENGTH.