it-swarm-eu.dev

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

Ich kann keine Option (en) direkt finden, um UTF-8 Rellated Collations/Charsets In SQL Server 2005/2008 festzulegen, wie dies in anderen SQL-Engines möglich ist, jedoch in SQL Server 2005/2008 Gibt es nur lateinische und SQL-Kollatierungen?.

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

16
mKorbel

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

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

Beachten Sie, dass dies von MS on Connect angefordert wurde und es einen älterer KB-Artikel gibt. Und einige Infos auch in diesem Blog

13
gbn

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

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

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

2
Guffa

Ab SQL Server 2019 (derzeit in der Beta/"Community Tech Preview") wird UTF-8 über eine neue Reihe von UTF-8-Kollatierungen nativ unterstützt. JEDOCH die Fähigkeit, UTF-8 zu verwenden, bedeutet nicht das Du solltest. Die Verwendung von UTF-8 weist bestimmte Nachteile auf, z.

  1. Nur die ersten 128 Codepunkte sind 1 Byte (d. H. Das Standard-7-Bit ASCII set)
  2. Die nächsten fast 2000 Codepunkte sind 2 Bytes, daher keine Platzersparnis gegenüber UTF-16/NVARCHAR
  3. Die verbleibenden 63.000 Codepunkte im Bereich BMP (dh der Bereich U + 0800 - U + FFFF)) sind alle 3 Bytes, daher 1 Byte größer als gleich Zeichen in UTF-16/NVARCHAR.
  4. Habe es nur gesagt: Zusätzliche Zeichen sind 4 Bytes in beiden Codierungen, also kein Platzunterschied
  5. Während Sie mit UTF-8 möglicherweise Platz sparen, besteht eine sehr gute Chance, dass Sie dadurch die Leistung beeinträchtigen.

Worauf es wirklich ankommt, ist Folgendes: UTF-8 ist ein Speicherformatdesign, um 8-Bit-Systeme zu ermöglichen (die normalerweise um ASCII und ASCII) entwickelt wurden Erweitert - Codepages), um Unicode zu verwenden, ohne irgendetwas zu beschädigen oder vorhandene Dateien zu ändern, um den Betrieb aufrechtzuerhalten. UTF-8 ist wunderbar für Dateisysteme und Netzwerke, aber gespeicherte Daten inside SQL Server ist beides nicht. Die Tatsache, dass Daten, die zufällig meistens (oder vollständig) innerhalb des Standardbereichs ASCII) liegen, weniger Speicherplatz benötigen als dieselben Daten, wenn Als UTF-16/NVARCHAR gespeichert ist ein Nebeneffekt. Sicher, es ist ein Nebeneffekt, der sich als nützlich erweisen kann, aber diese Entscheidung muss von jemandem getroffen werden, der beide Daten versteht und die Konsequenzen/Nachteile dieser Entscheidung. Dies ist nicht eine Funktion für den allgemeinen Gebrauch.

Der Hauptanwendungsfall für UTF-8 (in SQL Server) ist App-Code, der bereits UTF-8 verwendet, möglicherweise bereits mit einem anderen RDBMS, das dies unterstützt, und es besteht kein Wunsch oder keine Möglichkeit, den App-Code/das DB-Schema zu aktualisieren um NVARCHAR -Datentypen (für Tabellen, Variablen, Parameter usw.) zu verwenden oder Zeichenfolgenliteralen ein Großbuchstaben "N" voranzustellen. Das Ziel ist das gleiche wie der Grund für das Vorhandensein von UTF-8: Aktivieren Sie den App-Code für die Verwendung von Unicode, 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 Fehler/Probleme gibt.

Wenn Sie nicht ausdrücklich benötigen, dass Unicode ohne Verwendung von Zeichenfolgenliteralen mit NVARCHAR oder Großbuchstaben "N" funktioniert, ist das einzige andere Szenario, in dem UTF-8 von Vorteil ist, wenn Sie VIEL haben -mostly standard ASCII Daten, die Unicode-Zeichen zulassen müssen, und Sie verwenden 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 helfen).

Ausführliche Informationen finden Sie in meinem Beitrag:

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

1
Solomon Rutzky

In meinem Fall musste ich arabische Zeichen anzeigen und meine Entwicklungsdatenbank war im Jahr 2014, hier lief es gut. Hier konnte ich in der Abfrage arabische Zeichen sehen und meine Sortierung 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 alle sehen ??????????? da UTF-8 in SQL 2008 nicht unterstützt wird.

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

0
Halim