SQL Server 2005/2008 UTF-8-Kollatierung / Zeichensatz

16

Ich kann keine Option (en) finden, die in SQL Server 2005/2008 direkt festgelegt werden UTF-8können Collations/Charsets, wie dies auch in anderen SQL- Modulen möglich ist, aber in SQL Server 2005/2008 gibt es nur lateinische und SQL-Sortierungen.

Gibt es eine Option zum Erzwingen / Installieren dieser Kollatierungen / Zeichensätze in der SQL Server-Engine (für beide Versionen) 2005/2008 unter Win2008

— mKorbel
quelle

13

Nein, das gibt es nicht. SQL Server unterstützt UTF-8 nicht.

Sie müssen Ihre Spalten als nvarchar / nchar definieren, wenn Sie Unicode-Daten möchten. Beachten Sie, dass SQL Server dies intern als UCS-2 speichert.

Beachten Sie, dass dies bei MS on Connect angefordert wurde und es einen älteren KB-Artikel gibt . Und ein paar Infos auch in diesem Blog

— gbn
quelle

6

Wenn Sie in einem nvarchar Text mit fremden Zeichen abgleichen möchten, müssen Sie außerdem eine Zeichenfolge verwenden, die mit einem N vor der Zeichenfolge formatiert ist (z. B. N'οἰκονόμον ').

— Swasheck

Hat sich dieses Verhalten in einer neueren Version von SQL Server geändert?

— Seiyria

@Seiyria: nein, dasselbe Verhalten

— gbn

Jeder, der den Weg zu dieser Antwort findet, besucht bitte die MS Connect-Seite und stimmt ab, dass MS UTF-8 unter SQL Server unterstützt. Danke: D

— DarcyThomas

@DarcyThomas Dies wird in SQL Server 2019 Realität, obwohl es immer noch nichts ist, was man verwenden sollte, es sei denn, man benötigt es ausdrücklich. Bitte beachten Sie meine Antwort für Details.

— Solomon Rutzky

2

Sie können UTF-8 nicht als Zeichensatz installieren, da es sich nicht um einen Zeichensatz handelt, sondern um eine Kodierung.

Wenn Sie Unicode-Text speichern möchten, verwenden Sie den nvarcharDatentyp.

Wenn Sie mit UTF-8 codierten Text speichern möchten, speichern Sie ihn als Binärdaten ( varbinary).

— Guffa
quelle

1

Ab SQL Server 2019 (derzeit in der Beta-Version / "Community Tech Preview") wird UTF-8 über eine neue Reihe von UTF-8-Kollatierungen nativ unterstützt. JEDOCH die Fähigkeit, UTF-8 Verwendung mit sich nicht bedeuten , dass Sie sollten. Es gibt bestimmte Nachteile bei der Verwendung von UTF-8, wie zum Beispiel:

Nur die ersten 128 Codepunkte sind 1 Byte (dh der Standard-7-Bit-ASCII-Satz).
Die nächsten fast 2000 Codepunkte sind 2 Byte, daher keine Platzersparnis gegenüber UTF-16 / NVARCHAR
Die verbleibenden 63k-Codepunkte im BMP (dh der Bereich U + 0800 - U + FFFF) sind alle 3 Byte, also 1 Byte größer als dasselbe Zeichen in UTF-16 / NVARCHAR.
Habe nur gesagt: Zusatzzeichen sind 4 Bytes in beiden Kodierungen, also kein Raumunterschied da
Mit UTF-8 können Sie zwar Speicherplatz sparen, es besteht jedoch eine sehr gute Chance, dass die Leistung dadurch beeinträchtigt wird.

Worauf es wirklich ankommt, ist Folgendes: UTF-8 ist ein Speicherformatdesign, mit dem 8-Bit-Systeme (die normalerweise für ASCII und ASCII Extended - Codepages entwickelt wurden) Unicode verwenden können, ohne dass etwas beschädigt oder Änderungen an vorhandenen vorgenommen werden müssen Dateien, um die Dinge am Laufen zu halten. UTF-8 eignet sich hervorragend für Dateisysteme und Netzwerke, Daten, die in SQL Server gespeichert sind , jedoch nicht. Die Tatsache, dass Daten, die sich zufällig größtenteils (oder vollständig) im Standard-ASCII-Bereich befinden, weniger Speicherplatz benötigen als dieselben Daten, wenn sie als UTF-16 / gespeichert werden, NVARCHARist ein Nebeneffekt. Sicher, es ist ein Nebeneffekt, der sich als nützlich erweisen kann, aber diese Entscheidung muss von jemandem getroffen werden, der sowohl die Daten als auch die Konsequenzen / Nachteile dieser Entscheidung versteht. Das istkeine Funktion für den allgemeinen Gebrauch.

Der Hauptanwendungsfall für UTF-8 (in SQL Server) ist auch für App-Code, der bereits UTF-8 verwendet, möglicherweise bereits mit einem anderen RDBMS, das dies unterstützt, und es besteht kein Bedarf oder keine Möglichkeit, das App-Code / DB-Schema zu aktualisieren Verwenden von NVARCHARDatentypen (für Tabellen, Variablen, Parameter usw.) oder Präfixieren von Zeichenfolgenliteralen mit einem Großbuchstaben "N". Das Ziel ist dasselbe wie der Grund für das Vorhandensein von UTF-8: Aktivieren Sie den Anwendungscode, um Unicode zu verwenden, ohne die Gesamtstruktur zu ändern oder vorhandene Daten ungültig zu machen. Wenn dies Ihre Situation beschreibt, verwenden Sie UTF-8, aber beachten Sie, dass es immer noch einige Bugs / Probleme gibt.

Wenn Sie eine explizite Notwendigkeit für Unicode nicht arbeiten , müssen ohne Verwendung NVARCHARoder Großbuchstaben „N“ als Präfix Stringliterale, dann ist das einzige andere Szenario , in dem UTF-8 ist ein Vorteil ist , wenn man von A LOT hat meist Standard - ASCII - Daten , die Bedürfnisse zu ermöglichen Sie verwenden Unicode-Zeichen NVARCHAR(MAX)(was bedeutet, dass die Datenkomprimierung nicht funktioniert) und die Tabelle wird häufig aktualisiert (daher wird der Clustered Columnstore-Index wahrscheinlich nicht wirklich hilfreich sein).

Ausführliche Informationen finden Sie in meinem Beitrag:

Native UTF-8-Unterstützung in SQL Server 2019: Retter oder falscher Prophet?

— Solomon Rutzky
quelle

0

In meinem Fall musste ich arabische Zeichen anzeigen und meine Entwicklungsdatenbank war im Jahr 2014, hier hat es gut geklappt. Hier konnte ich in der Abfrage arabische Zeichen sehen und meine Kollatierung war SQL_Latin1_General_CP1256_CI_AS

Aber meine Produktion war in SQL Server 2008 und schließlich wird der UTF-8-Zeichensatz nicht unterstützt. Hier konnte ich alles sehen ??????????? da UTF-8 in SQL 2008 nicht unterstützt wird.

Was ich getan habe, ist, alle varchar in nvarchar zu ändern, und ich konnte arabische char richtig sehen. Außerdem ändere ich meine 2008-Datenbanksortierung in SQL_Latin1_General_CP1256_CI_AS

— Halim
quelle