Unterstützung von Sortierungen und Unicode
Gilt für: 
SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) SQL Analytics-Endpunkt in Microsoft Fabric Warehouse in Microsoft Fabric
Sortierungen in SQL Server bieten Sortierregeln und die Berücksichtigung von Groß-/Kleinschreibung und Akzenten für die Daten. Sortierungen, die mit Zeichendatentypen wie char und varchar verwendet werden, geben die Codeseite und die entsprechenden Zeichen vor, die für den jeweiligen Datentyp dargestellt werden können.
Bei der Installation einer neuen Instanz von SQL Server, bei der Wiederherstellung einer Datenbanksicherung oder bei der Verbindung von Servern mit Clientdatenbanken ist es wichtig, dass Sie die Gebietsschemaanforderungen, die Sortierreihenfolge und das Verhalten in Bezug auf die Groß-/Kleinschreibung und Akzente der Daten kennen, mit denen Sie arbeiten. Informationen zum Auflisten der Sortierungen, die in Ihrer SQL Server-Instanz verfügbar sind, finden Sie unter sys.fn_helpcollations (Transact-SQL).
Wenn Sie eine Sortierung für Ihren Server, Ihre Datenbank, Ihre Spalte oder Ihren Ausdruck auswählen, weisen Sie Ihren Daten bestimmte Merkmale zu. Diese Merkmale wirken sich auf die Ergebnisse vieler Vorgänge in der Datenbank aus. Wenn Sie beispielsweise eine Abfrage mit ORDER BY erstellen, kann die Sortierreihenfolge des Resultsets von der Sortierung abhängen, die auf die Datenbank angewendet wurde oder die auf Ausdrucksebene in einer COLLATE-Klausel der Abfrage vorgegeben ist.
Für die optimale Nutzung der Sortierungsunterstützung in SQL Server, sollten Sie die in diesem Artikel definierten Begriffe und ihre Verbindung mit den Eigenschaften Ihrer Daten verstehen.
Sortierungsbegriffe
Sortierung
Eine Sortierung gibt die Bitmuster an, die die jeweiligen Zeichen in einem Dataset darstellen. Sortierungen legen außerdem die Regeln fest, nach denen Daten sortiert und verglichen werden. SQL Server unterstützt das Speichern von Objekten mit verschiedenen Sortierungen in einer Datenbank. Bei Nicht-Unicode-Spalten gibt die Sortierungseinstellung die Codepage für die Daten und die Zeichen an, die dargestellt werden können. Die Daten, die Sie zwischen Nicht-Unicode-Spalten verschieben, müssen von der Quellcodepage in die Zielcodepage konvertiert werden.
Transact-SQL-Anweisungsergebnisse können unterschiedlich sein, wenn die Anweisung im Kontext verschiedener Datenbanken ausgeführt wird, die jeweils andere Sortierungseinstellungen haben. Wenn möglich, sollte in Unternehmen eine standardisierte Sortierung verwendet werden. Auf diese Weise müssen Sie die Sortierung nicht für jedes Zeichen oder jeden Unicode-Ausdruck angeben. Bei Objekten mit abweichenden Sortierungs- oder Codepageeinstellungen codieren Sie Ihre Abfragen so, dass diese den Regeln der Sortierungspriorität entsprechen. Weitere Informationen finden Sie unter Rangfolge der Sortierungen (Transact-SQL).
Die einer Sortierung zugeordneten Optionen sind die Berücksichtigung von Groß-/Kleinschreibung, Akzenten, Kana, Breite und Variierungsauswahlzeichen. SQL Server 2019 (15.x) führt eine zusätzliche Option für die UTF-8-Codierung ein.
Sie können diese Optionen festlegen, indem Sie sie an den Namen der Sortierung anfügen. Beispiel: Bei der Sortierung Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 wird nach Groß-/Kleinschreibung, Akzenten, Kana und Breite unterschieden und die UTF-8-Codierung verwendet. Im Gegensatz dazu berücksichtigt die Sortierung Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS beispielsweise die Groß-/Kleinschreibung und Akzente nicht, dafür aber Kana, Breite und Variierungsauswahlzeichen, und sie verwendet eine Nicht-Unicode-Codierung.
In der folgenden Tabelle wird das den verschiedenen Optionen zugeordnete Verhalten beschrieben:
| Option | BESCHREIBUNG |
|---|---|
| Unterscheidung nach Groß-/Kleinschreibung (_CS) | Unterscheidet zwischen Groß- und Kleinbuchstaben. Wenn diese Option aktiviert wird, stehen Kleinbuchstaben in der Sortierreihenfolge vor ihren entsprechenden Großbuchstaben. Wenn diese Option nicht aktiviert wird, wird die Groß- und Kleinschreibung bei der Sortierung nicht berücksichtigt. SQL Server betrachtet also beim Sortieren die groß- und die kleingeschriebenen Versionen von Buchstaben als identisch. Sie können die Nichtunterscheidung nach Groß-/Kleinbuchstaben durch Angeben von "_CI" explizit auswählen. |
| Unterscheidung nach Akzent (_AS) | Unterscheidet zwischen Zeichen mit Akzent und Zeichen ohne Akzent. Beispielsweise entspricht „a“ nicht „ấ“. Wenn diese Option nicht aktiviert wird, wird bei der Sortierung nicht nach Akzenten unterschieden. SQL Server betrachtet also beim Sortieren die Versionen von Buchstaben mit und ohne Akzent als identisch. Sie können die Nichtunterscheidung nach Akzent durch Angeben von "_AI" explizit auswählen. |
| Unterscheidung nach Kana (_KS) | Unterscheidet zwischen zwei japanischen Kana-Zeichen: Hiragana und Katakana. Wenn diese Option nicht aktiviert wird, wird bei der Sortierung nicht nach Kana unterschieden. SQL Server betrachtet also beim Sortieren Hiragana- und Katakana-Zeichen als identisch. Das Auslassen dieser Option ist die einzige Möglichkeit, die Nichtbeachtung von Kana anzugeben. |
| Unterscheidung nach Breite (_WS) | Unterscheidet zwischen Zeichen halber Breite und Zeichen normaler Breite. Wenn diese Option nicht aktiviert wird, betrachtet SQL Server beim Sortieren die Darstellung in halber Breite und in normaler Breite desselben Zeichens als identisch. Das Weglassen dieser Option ist die einzige Möglichkeit, die Nichtbeachtung der Breite anzugeben. |
| Mit Unterscheidung nach Variierungsauswahlzeichen (_VSS) | Unterscheidet zwischen verschiedenen Variierungsauswahlzeichen für Ideogramme in den japanischen Sortierungen Japanese_Bushu_Kakusu_140 und Japanese_XJIS_140, die erstmals in SQL Server 2017 (14.x) eingeführt wurden. Eine Variierungssequenz besteht aus einem Basiszeichen plus einem Variierungsauswahlzeichen. Wenn diese _VSS-Option nicht aktiviert ist, berücksichtigt die Sortierung die Variierung nicht, und das Variierungsauswahlzeichen wird im Vergleich nicht berücksichtigt. Das bedeutet, dass SQL Server Zeichen, die auf dem gleichen Basiszeichen aufbauen, aber verschiedene Variierungsauswahlzeichen aufweisen, für Sortierungszwecke als identisch betrachtet werden. Weitere Informationen finden Sie in der Unicode Ideographic Variation Database (Unicode-Datenbank für Ideogrammvariationen). Variierungsauswahlzeichen unterstützende Sortierungen (_VSS) werden in Indizes für die Volltextsuche nicht unterstützt. Indizes für die Volltextsuche unterstützen nur Optionen für die Unterscheidung nach Akzent (_AS), Kana (_KS) und Breite (_WS). XML- und CLR-Engines von SQL Server unterstützen Variierungsauswahlzeichen (_VSS) nicht. |
| Binär (_BIN) 1 | Sortiert und vergleicht Daten in SQL Server-Tabellen basierend auf den für jedes Zeichen definierten Bitmustern. Die binäre Sortierreihenfolge unterscheidet nach Groß- und Kleinschreibung und nach Akzent. Die Option Binär ist zudem die schnellste Sortierreihenfolge. Weitere Informationen finden Sie im Abschnitt Binäre Sortierungen dieses Artikels. |
| Binärcodepunkt (_BIN2)1 | Sortiert und vergleicht Daten in SQL Server-Tabellen basierend auf Unicode-Codepunkten für Unicode-Daten. Für Nicht-Unicode-Daten verwendet der Binärcodepunkt Vergleiche, die mit denen für binäre Sortierungen identisch sind. Der Vorteil beim Verwenden einer Binär-Codepunkt-Sortierreihenfolge liegt darin, dass in Anwendungen, die sortierte SQL Server-Daten vergleichen, eine Neusortierung der Daten nicht erforderlich ist. Folglich ermöglicht eine Binär-Codepunkt-Sortierreihenfolge eine einfachere Entwicklung von Anwendungen und eine Steigerung der Leistung. Weitere Informationen finden Sie im Abschnitt Binäre Sortierungen dieses Artikels. |
| UTF-8 (_UTF8) | Ermöglicht das Speichern von mit UTF-8 codierten Daten in SQL Server. Wenn diese Option nicht aktiviert ist, verwendet SQL Server das standardmäßige Nicht-Unicode-Codierungsformat für die entsprechenden Datentypen. Weitere Informationen finden Sie im Abschnitt Unterstützung für UTF-8 dieses Artikels. |
1 Wenn „Binär“ oder der Binär-Codepunkt ausgewählt ist, sind die Optionen für Unterscheidung nach Groß-/Kleinschreibung (_CS), Unterscheidung nach Akzent (_AS), Unterscheidung nach Kana (_KS) und Unterscheidung nach Breite (_WS) nicht verfügbar.
Beispiele für Sortierungsoptionen
Jede Sortierung setzt sich aus einer Kombination von Suffixen zur Festlegung der Unterscheidung nach Groß-/Kleinschreibung, Akzenten, Breite oder Kana zusammen. Die folgenden Beispiele beschreiben das Verhalten der Sortierreihenfolge bei verschiedenen Suffixkombinationen.
| Suffix der Windows-Sortierung | Beschreibung der Sortierreihenfolge |
|---|---|
| _BIN1 | Binäre Sortierung. |
| _BIN21, 2 | Binärcodepunkt-Sortierreihenfolge. |
| _CI_AI2 | Keine Unterscheidung nach Groß-/Kleinschreibung, Akzenten, Kana und Breite. |
| _CI_AI_KS2 | Keine Unterscheidung nach Groß-/Kleinschreibung, Akzent und Breite. Unterscheidung nach Kana. |
| _CI_AI_KS_WS2 | Keine Unterscheidung nach Groß-/Kleinschreibung und Akzent. Unterscheidung nach Kana und Breite |
| _CI_AI_WS2 | Keine Unterscheidung nach Groß-/Kleinschreibung, Akzent und Kana. Unterscheidung nach Breite. |
| _CI_AS2 | Keine Unterscheidung nach Groß-/Kleinschreibung, Kana und Breite. Unterscheidung nach Akzent. |
| _CI_AS_KS2 | Keine Unterscheidung nach Groß-/Kleinschreibung und Breite. Unterscheidung nach Akzent und Kana. |
| _CI_AS_KS_WS2 | Keine Unterscheidung nach Groß-/Kleinschreibung. Unterscheidung nach Akzent, Kana und Breite. |
| _CI_AS_WS2 | Keine Unterscheidung nach Groß-/Kleinschreibung und Kana. Unterscheidung nach Akzent und Breite. |
| _CS_AI2 | Keine Unterscheidung nach Akzent, Kana und Breite. Unterscheidung nach Groß-/Kleinschreibung. |
| _CS_AI_KS2 | Keine Unterscheidung nach Akzent und Breite. Unterscheidung nach Groß-/Kleinschreibung und Kana. |
| _CS_AI_KS_WS2 | Keine Unterscheidung nach Akzent. Unterscheidung nach Groß-/Kleinschreibung, Kana und Breite. |
| _CS_AI_WS2 | Keine Unterscheidung nach Akzent und Kana. Unterscheidung nach Groß-/Kleinschreibung und Breite. |
| _CS_AS2 | Keine Unterscheidung nach Kana und Breite. Unterscheidung nach Groß-/Kleinschreibung und Akzent. |
| _CS_AS_KS2 | Keine Unterscheidung nach Breite. Unterscheidung nach Groß-/Kleinschreibung, Akzent und Kana. |
| _CS_AS_KS_WS2 | Unterscheidung nach Groß-/Kleinschreibung, Akzent, Kana und Breite. |
| _CS_AS_WS2 | Keine Unterscheidung nach Kana. Unterscheidung nach Groß-/Kleinschreibung, Akzent und Breite. |
1 Wenn „Binär“ oder der Binär-Codepunkt ausgewählt ist, sind die Optionen für Unterscheidung nach Groß-/Kleinschreibung (_CS), Unterscheidung nach Akzent (_AS), Unterscheidung nach Kana (_KS) und Unterscheidung nach Breite (_WS) nicht verfügbar.
2 Durch Hinzufügen der UTF-8-Option (_UTF8) können Sie Unicode-Daten mit UTF-8 codieren. Weitere Informationen finden Sie im Abschnitt Unterstützung für UTF-8 dieses Artikels.
Sortierungssätze
SQL Server unterstützt die folgenden Sortierungssätze:
Windows-Sortierungen
Windows-Sortierungen definieren Regeln zum Speichern von Zeichendaten, die auf dem zugehörigen Windows-Systemgebietsschema basieren. Bei einer Windows-Sortierung können Sie mithilfe desselben Algorithmus wie für Unicode-Daten einen Vergleich von Nicht-Unicode-Daten implementieren. Die grundlegenden Regeln für die Windows-Sortierung geben vor, welches Alphabet oder welche Sprache verwendet wird, wenn Wörterbuchsortierung angewendet wird. Die Regeln geben auch die Codepage vor, die zum Speichern von Nicht-Unicode-Zeichendaten verwendet wird. Sowohl die Unicode- als auch die Nicht-Unicode-Sortierung sind kompatibel mit Zeichenfolgenvergleichen in einer bestimmten Version von Windows. Dadurch wird die Konsistenz der Datentypen in SQL Server ermöglicht, und Entwickler erhalten so die Möglichkeit, Zeichenfolgen in ihren Anwendungen mithilfe der gleichen Regeln zu sortieren, die auch in SQL Server verwendet werden. Weitere Informationen finden Sie unter Name der Windows-Sortierung (Transact-SQL).
Binäre Sortierungen
Binäre Sortierungen sortieren Daten basierend auf der Reihenfolge codierter Werte, die vom Gebietsschema und Datentyp definiert werden. Sie beachten die Groß-/Kleinschreibung. Eine binäre Sortierung in SQL Server definiert das zu verwendende Gebietsschema sowie die zu verwendende ANSI-Codepage. Dies erzwingt eine binäre Sortierreihenfolge. Da binäre Sortierungen relativ einfach sind, tragen sie dazu bei, die Anwendungsleistung zu verbessern. Bei Nicht-Unicode-Datentypen basieren Datenvergleiche auf den in der ANSI-Codepage definierten Codepunkten. Bei Unicode-Datentypen basieren Datenvergleiche auf den Unicode-Codepunkten. Bei binären Sortierungen von Unicode-Datentypen wird das Gebietsschema bei Datensortierungen nicht berücksichtigt. Beispielsweise führen Latin_1_General_BIN und Japanese_BIN bei Unicode-Daten zu den gleichen Sortierergebnissen. Weitere Informationen finden Sie unter Name der Windows-Sortierung (Transact-SQL).
In SQL Servergibt es zwei Arten von binären Sortierungen:
Frühere BIN-Sortierungen, die für Unicode-Daten einen unvollständigen Codepunkt-zu-Codepunkt-Vergleich ausführten. Die früheren binären Sortierungen verglichen die ersten Zeichen als WCHAR und die folgenden byteweise. In einer BIN-Sortierung wird nur der erste Buchstabe nach dem Codepunkt sortiert, die verbleibenden Zeichen werden entsprechend ihren Bytewerten sortiert.
Die neueren BIN2-Sortierungen, die einen reinen Vergleich nach Codepunkt implementieren. In einer BIN2-Sortierung werden alle Zeichen entsprechend ihren Codepunkten sortiert. Da die Intel Plattform eine Little-Endian-Architektur aufweist, werden Unicode-Zeichen immer mit vertauschten Bytes gespeichert.
SQL Server-Sortierungen
SQL Server-Sortierungen (SQL_*) sind hinsichtlich der Sortierreihenfolge mit älteren Versionen von SQL Server kompatibel. Die Wörterbuch-Sortierungsregeln für Nicht-Unicode-Daten sind nicht kompatibel mit den von Windows-Betriebssystem bereitgestellten Sortierroutinen. Das Sortieren von Unicode-Daten ist jedoch kompatibel mit einer bestimmten Version der Windows-Sortierregeln. Da SQL Server-Sortierungen unterschiedliche Vergleichsregeln für Nicht-Unicode- und Unicode-Daten verwenden, werden bei Vergleichen derselben Daten, je nach dem zugrunde liegenden Datentyp, unterschiedliche Ergebnisse angezeigt.
Wenn Sie z. B. die SQL-Sortierung SQL_Latin1_General_CP1_CI_AS verwenden, ist die nicht-Unicode-Zeichenfolge 'a-c' kleiner als die Zeichenfolge 'ab', da der Bindestrich (-) als separates Zeichen sortiert wird, das vorkommt b. Wenn Sie diese Zeichenfolgen jedoch in Unicode konvertieren und denselben Vergleich ausführen, gilt die Unicode-Zeichenfolge N'a-c' als größer als N'ab', da die Unicode-Sortierregeln eine Wortsortierung verwenden, die den Bindestrich ignoriert.
Weitere Informationen finden Sie unter Name der SQL Server-Sortierung (Transact-SQL).
Die Standardinstallationseinstellung wird während des SQL Server-Setups durch das Gebietsschema des Betriebssystems bestimmt. Sie können die Sortierung auf Serverebene entweder während des Setups ändern oder, indem Sie das Gebietsschema des Betriebssystems vor der Installation ändern. Aus Gründen der Abwärtskompatibilität ist die Standardsortierung auf die älteste verfügbare Version festgelegt, die einem jeweiligen Gebietsschema zugeordnet ist. Aus diesem Grund wird diese Sortierung nicht immer empfohlen. Um die SQL Server-Funktionen optimal zu können, ändern Sie die Standardinstallationseinstellungen für die Verwendung von Windows-Sortierungen. Beispielsweise ist für das Betriebssystem-Gebietsschema „Englisch (USA)“ (Codepage 1252) die Standardsortierung während des Setups SQL_Latin1_General_CP1_CI_AS, welche in die nächste entsprechende Windows-Sortierung Latin1_General_100_CI_AS_SC geändert werden kann.
Hinweis
Wenn Sie ein Upgrade für eine englischsprachige Instanz von SQL Server durchführen, können Sie SQL Server-Sortierungen (SQL_*) festlegen, die mit vorhandenen Instanzen von SQL Server kompatibel sind. Da die Standardsortierung einer Instanz von SQL Server während des Setups festgelegt wird, geben Sie unbedingt die Sortierungseinstellungen sorgfältig an, wenn folgende Bedingungen vorliegen:
- Der Anwendungscode ist abhängig vom Verhalten der vorherigen SQL Server -Sortierungen.
- Sie müssen Zeichendaten speichern, die mehrere Sprachen wiedergeben.
Sortierungsebenen
Das Festlegen von Sortierungen wird bei einer Instanz von SQL Serverfür die folgenden Ebenen unterstützt:
- Sortierungen auf Serverebene
- Sortierungen auf Datenbankebene
- Sortierungen auf Spaltenebene
- Sortierungen auf Ausdrucksebene
Sortierungen auf Serverebene
Die Standardserversortierung wird während des SQL Server-Setups festgelegt und als Standardsortierung der Systemdatenbanken und aller Benutzerdatenbanken vorgegeben.
In der folgenden Tabelle werden die standardmäßig verwendeten Sortierbezeichnungen angezeigt, die vom Gebietsschema des Betriebssystems bestimmt werden, einschließlich der entsprechenden Windows- und SQL-Sprachcode-IDs (LCID):
| Windows-Gebietsschema | Windows-LCID | SQL-LCID | Standardsortierung |
|---|---|---|---|
| Afrikaans (Südafrika) | 0x0436 | 0x0409 | Latin1_General_CI_AS |
| Albanisch (Albanien) | 0x041c | 0x041c | Albanian_CI_AS |
| Elsässisch (Frankreich) | 0x0484 | 0x0409 | Latin1_General_CI_AS |
| Amharisch (Äthiopien) | 0x045e | 0x0409 | Latin1_General_CI_AS |
| Arabisch (Algerien) | 0x1401 | 0x0401 | Arabic_CI_AS |
| Arabisch (Bahrain) | 0x3c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (Ägypten) | 0x0c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (Irak) | 0x0801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Jordanien) | 0x2c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (Kuwait) | 0x3401 | 0x0401 | Arabic_CI_AS |
| Arabisch (Libanon) | 0x3001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Libyen) | 0x1001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Marokko) | 0x1801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Oman) | 0x2001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Katar) | 0x4001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Saudi-Arabien) | 0x0401 | 0x0401 | Arabic_CI_AS |
| Arabisch (Syrien) | 0x2801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Tunesien) | 0x1c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (Vereinigte Arabische Emirate) | 0x3801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Jemen) | 0x2401 | 0x0401 | Arabic_CI_AS |
| Armenisch (Armenien) | 0x042b | 0x0419 | Latin1_General_CI_AS |
| Assamisch (Indien) | 0x044d | 0x044d | Auf Serverebene nicht verfügbar |
| Aserbaidschanisch (Aserbaidschan, kyrillisch) | 0x082c | 0x082c | Veraltet, auf Serverebene nicht verfügbar |
| Aserbaidschanisch (Aserbaidschan, lateinisch) | 0x042c | 0x042c | Veraltet, auf Serverebene nicht verfügbar |
| Baschkirisch (Russische Föderation) | 0x046d | 0x046d | Latin1_General_CI_AI |
| Baskisch (Baskisch) | 0x042d | 0x0409 | Latin1_General_CI_AS |
| Belarussisch (Belarus) | 0x0423 | 0x0419 | Cyrillic_General_CI_AS |
| Bangla (Bangladesch) | 0x0845 | 0x0445 | Auf Serverebene nicht verfügbar |
| Bangla (Indien) | 0x0445 | 0x0439 | Auf Serverebene nicht verfügbar |
| Bosnisch (Bosnien und Herzegowina, kyrillisch) | 0x201a | 0x201a | Latin1_General_CI_AI |
| Bosnisch (Bosnien und Herzegowina, lateinisch) | 0x141a | 0x141a | Latin1_General_CI_AI |
| Bretonisch (Frankreich) | 0x047e | 0x047e | Latin1_General_CI_AI |
| Bulgarisch (Bulgarien) | 0x0402 | 0x0419 | Cyrillic_General_CI_AS |
| Katalanisch (Katalanisch) | 0x0403 | 0x0409 | Latin1_General_CI_AS |
| Chinesisch (Hongkong SAR, VR China) | 0x0c04 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Chinesisch (Macao SAR) | 0x1404 | 0x1404 | Latin1_General_CI_AI |
| Chinesisch (Macao SAR) | 0x21404 | 0x21404 | Latin1_General_CI_AI |
| Chinesisch (VRC) | 0x0804 | 0x0804 | Chinese_PRC_CI_AS |
| Chinesisch (VRC) | 0x20804 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Chinesisch (Singapur) | 0x1004 | 0x0804 | Chinese_PRC_CI_AS |
| Chinesisch (Singapur) | 0x21004 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Chinesisch (Taiwan) | 0x30404 | 0x30404 | Chinese_Taiwan_Bopomofo_CI_AS |
| Chinesisch (Taiwan) | 0x0404 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Korsisch (Frankreich) | 0x0483 | 0x0483 | Latin1_General_CI_AI |
| Kroatisch (Bosnien und Herzegowina, lateinisch) | 0x101a | 0x041a | Croatian_CI_AS |
| Kroatisch (Kroatien) | 0x041a | 0x041a | Croatian_CI_AS |
| Tschechisch (Tschechische Republik) | 0x0405 | 0x0405 | Czech_CI_AS |
| Dänisch (Dänemark) | 0x0406 | 0x0406 | Danish_Norwegian_CI_AS |
| Dari (Afghanistan) | 0x048c | 0x048c | Latin1_General_CI_AI |
| Divehi (Malediven) | 0x0465 | 0x0465 | Auf Serverebene nicht verfügbar |
| Niederländisch (Belgien) | 0x0813 | 0x0409 | Latin1_General_CI_AS |
| Niederländisch (Niederlande) | 0x0413 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Australien) | 0x0c09 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Belize) | 0x2809 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Kanada) | 0x1009 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Karibik) | 0x2409 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Indien) | 0x4009 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Irland) | 0x1809 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Jamaika) | 0x2009 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Malaysia) | 0x4409 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Neuseeland) | 0x1409 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Philippinen) | 0x3409 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Singapur) | 0x4809 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Südafrika) | 0x1c09 | 0x0409 | Latin1_General_CI_AS |
| Englisch (Trinidad und Tobago) | 0x2c09 | 0x0409 | Latin1_General_CI_AS |
| Walisisch (Großbritannien) | 0x0809 | 0x0409 | Latin1_General_CI_AS |
| Englisch (USA) | 0x0409 | 0x0409 | SQL_Latin1_General_CP1_CI_AS |
| Englisch (Zimbabwe) | 0x3009 | 0x0409 | Latin1_General_CI_AS |
| Estnisch (Estland) | 0x0425 | 0x0425 | Estonian_CI_AS |
| Färöisch (Färöer-Inseln) | 0x0438 | 0x0409 | Latin1_General_CI_AS |
| Philippinisch (Philippinen) | 0x0464 | 0x0409 | Latin1_General_CI_AS |
| Finnisch (Finnland) | 0x040b | 0x040b | Finnish_Swedish_CI_AS |
| Französisch (Belgien) | 0x080c | 0x040c | French_CI_AS |
| Französisch (Kanada) | 0x0c0c | 0x040c | French_CI_AS |
| Französisch (Frankreich) | 0x040c | 0x040c | French_CI_AS |
| Französisch (Luxemburg) | 0x140c | 0x040c | French_CI_AS |
| Französisch (Monaco) | 0x180c | 0x040c | French_CI_AS |
| Französisch (Schweiz) | 0x100c | 0x040c | French_CI_AS |
| Friesisch (Niederlande) | 0x0462 | 0x0462 | Latin1_General_CI_AI |
| Galizisch | 0x0456 | 0x0409 | Latin1_General_CI_AS |
| Georgisch (Georgien) | 0x10437 | 0x10437 | Georgian_Modern_Sort_CI_AS |
| Georgisch (Georgien) | 0x0437 | 0x0419 | Latin1_General_CI_AS |
| Deutsch (Telefonbuchsortierung DIN) | 0x10407 | 0x10407 | German_PhoneBook_CI_AS |
| Deutsch (Österreich) | 0x0c07 | 0x0409 | Latin1_General_CI_AS |
| Deutsch (Deutschland) | 0x0407 | 0x0409 | Latin1_General_CI_AS |
| Deutsch (Liechtenstein) | 0x1407 | 0x0409 | Latin1_General_CI_AS |
| Deutsch (Luxemburg) | 0x1007 | 0x0409 | Latin1_General_CI_AS |
| Deutsch (Schweiz) | 0x0807 | 0x0409 | Latin1_General_CI_AS |
| Griechisch (Griechenland) | 0x0408 | 0x0408 | Greek_CI_AS |
| Grönländisch (Grönland) | 0x046f | 0x0406 | Danish_Norwegian_CI_AS |
| Gujarati (Indien) | 0x0447 | 0x0439 | Auf Serverebene nicht verfügbar |
| Hausa (Nigeria, lateinisch) | 0x0468 | 0x0409 | Latin1_General_CI_AS |
| Hebräisch (Israel) | 0x040d | 0x040d | Hebrew_CI_AS |
| Hindi (Indien) | 0x0439 | 0x0439 | Auf Serverebene nicht verfügbar |
| Ungarisch (Ungarn) | 0x040e | 0x040e | Hungarian_CI_AS |
| Ungarisch (Technische Sortierung) | 0x1040e | 0x1040e | Hungarian_Technical_CI_AS |
| Isländisch (Island) | 0x040f | 0x040f | Icelandic_CI_AS |
| Igbo (Nigeria) | 0x0470 | 0x0409 | Latin1_General_CI_AS |
| Indonesisch (Indonesien) | 0x0421 | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Kanada, lateinisch) | 0x085d | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Syllabics) Kanada | 0x045d | 0x045d | Latin1_General_CI_AI |
| Irisch (Irland) | 0x083c | 0x0409 | Latin1_General_CI_AS |
| Italienisch (Italien) | 0x0410 | 0x0409 | Latin1_General_CI_AS |
| Italienisch (Schweiz) | 0x0810 | 0x0409 | Latin1_General_CI_AS |
| Japanisch (Japan XJIS) | 0x0411 | 0x0411 | Japanese_CI_AS |
| Japanisch (Japan) | 0x040411 | 0x40411 | Latin1_General_CI_AI |
| Kannada (Indien) | 0x044b | 0x0439 | Auf Serverebene nicht verfügbar |
| Kasachisch (Kasachstan) | 0x043f | 0x043f | Kazakh_90_CI_AS |
| Khmer (Kambodscha) | 0x0453 | 0x0453 | Auf Serverebene nicht verfügbar |
| K'iche (Guatemala) | 0x0486 | 0x0c0a | Modern_Spanish_CI_AS |
| Kinyarwanda (Ruanda) | 0x0487 | 0x0409 | Latin1_General_CI_AS |
| Konkani (Indien) | 0x0457 | 0x0439 | Auf Serverebene nicht verfügbar |
| Koreanisch (koreanische Wörterbuchsortierung) | 0x0412 | 0x0412 | Korean_Wansung_CI_AS |
| Kirgisisch (Kirgisistan) | 0x0440 | 0x0419 | Cyrillic_General_CI_AS |
| Lao (Volksrepublik Laos) | 0x0454 | 0x0454 | Auf Serverebene nicht verfügbar |
| Lettisch (Lettland) | 0x0426 | 0x0426 | Latvian_CI_AS |
| Litauisch (Litauen) | 0x0427 | 0x0427 | Lithuanian_CI_AS |
| Niedersorbisch (Deutschland) | 0x082e | 0x0409 | Latin1_General_CI_AS |
| Luxemburgisch (Luxemburg) | 0x046e | 0x0409 | Latin1_General_CI_AS |
| Mazedonisch (Nordmazedonien) | 0x042f | 0x042f | Macedonian_FYROM_90_CI_AS |
| Malaiisch (Brunei Darussalam) | 0x083e | 0x0409 | Latin1_General_CI_AS |
| Malaiisch (Malaysia) | 0x043e | 0x0409 | Latin1_General_CI_AS |
| Malayalam (Indien) | 0x044c | 0x0439 | Auf Serverebene nicht verfügbar |
| Maltesisch (Malta) | 0x043a | 0x043a | Latin1_General_CI_AI |
| Maori (Neuseeland) | 0x0481 | 0x0481 | Latin1_General_CI_AI |
| Mapudungun (Chile) | 0x047a | 0x047a | Latin1_General_CI_AI |
| Marathi (Indien) | 0x044e | 0x0439 | Auf Serverebene nicht verfügbar |
| Mohawk (Kanada) | 0x047c | 0x047c | Latin1_General_CI_AI |
| Mongolisch (Mongolei) | 0x0450 | 0x0419 | Cyrillic_General_CI_AS |
| Mongolisch (VRC) | 0x0850 | 0x0419 | Cyrillic_General_CI_AS |
| Nepalesisch (Nepal) | 0x0461 | 0x0461 | Auf Serverebene nicht verfügbar |
| Norwegisch, Bokmål (Norwegen) | 0x0414 | 0x0414 | Latin1_General_CI_AI |
| Norwegisch (Nynorsk, Norwegen) | 0x0814 | 0x0414 | Latin1_General_CI_AI |
| Okzitanisch (Frankreich) | 0x0482 | 0x040c | French_CI_AS |
| Odia (Indien) | 0x0448 | 0x0439 | Auf Serverebene nicht verfügbar |
| Paschtu (Afghanistan) | 0x0463 | 0x0463 | Auf Serverebene nicht verfügbar |
| Persisch (Iran) | 0x0429 | 0x0429 | Latin1_General_CI_AI |
| Polnisch (Polen) | 0x0415 | 0x0415 | Polish_CI_AS |
| Portugiesisch (Brasilien) | 0x0416 | 0x0409 | Latin1_General_CI_AS |
| Portugiesisch (Portugal) | 0x0816 | 0x0409 | Latin1_General_CI_AS |
| Punjabi (Indien) | 0x0446 | 0x0439 | Auf Serverebene nicht verfügbar |
| Quechua (Bolivien) | 0x046b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Ecuador) | 0x086b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Peru) | 0x0c6b | 0x0409 | Latin1_General_CI_AS |
| Rumänisch (Rumänien) | 0x0418 | 0x0418 | Romanian_CI_AS |
| Rätoromanisch (Schweiz) | 0x0417 | 0x0417 | Latin1_General_CI_AI |
| Russisch (Russische Föderation) | 0x0419 | 0x0419 | Cyrillic_General_CI_AS |
| Sacha (Russische Föderation) | 0x0485 | 0x0485 | Latin1_General_CI_AI |
| Inari-Sami (Finnland) | 0x243b | 0x083b | Latin1_General_CI_AI |
| Lule-Sami (Norwegen) | 0x103b | 0x043b | Latin1_General_CI_AI |
| Lule-Sami (Schweden) | 0x143b | 0x083b | Latin1_General_CI_AI |
| Nord-Sami (Finnland) | 0x0c3b | 0x083b | Latin1_General_CI_AI |
| Nord-Sami (Norwegen) | 0x043b | 0x043b | Latin1_General_CI_AI |
| Nord-Sami (Schweden) | 0x083b | 0x083b | Latin1_General_CI_AI |
| Skolt-Sami (Finnland) | 0x203b | 0x083b | Latin1_General_CI_AI |
| Süd-Sami (Norwegen) | 0x183b | 0x043b | Latin1_General_CI_AI |
| Süd-Sami (Schweden) | 0x1c3b | 0x083b | Latin1_General_CI_AI |
| Sanskrit (Indien) | 0x044f | 0x0439 | Auf Serverebene nicht verfügbar |
| Serbisch (Bosnien und Herzegowina, kyrillisch) | 0x1c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbisch (Bosnien und Herzegowina, lateinisch) | 0x181a | 0x081a | Latin1_General_CI_AI |
| Serbisch (Serbien, kyrillisch) | 0x0c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbisch (Serbien, lateinisch) | 0x081a | 0x081a | Latin1_General_CI_AI |
| Sesotho sa Leboa/Nord-Sotho (Südafrika) | 0x046c | 0x0409 | Latin1_General_CI_AS |
| Setswana/Tswana (Südafrika) | 0x0432 | 0x0409 | Latin1_General_CI_AS |
| Sinhala (Sri Lanka) | 0x045b | 0x0439 | Auf Serverebene nicht verfügbar |
| Slowakisch (Slowakei) | 0x041b | 0x041b | Slovak_CI_AS |
| Slowenisch (Slowenien) | 0x0424 | 0x0424 | Slovenian_CI_AS |
| Spanisch (Argentinien) | 0x2c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Bolivien) | 0x400a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Chile) | 0x340a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Kolumbien) | 0x240a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Costa Rica) | 0x140a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Dominikanische Republik) | 0x1c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Ecuador) | 0x300a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (El Salvador) | 0x440a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Guatemala) | 0x100a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Honduras) | 0x480a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Mexiko) | 0x080a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Nicaragua) | 0x4c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Panama) | 0x180a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Paraguay) | 0x3c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Peru) | 0x280a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Puerto Rico) | 0x500a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Spanien) | 0x0c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Spanien, traditionelle Sortierung) | 0x040a | 0x040a | Traditional_Spanish_CI_AS |
| Spanisch (USA) | 0x540a | 0x0409 | Latin1_General_CI_AS |
| Spanisch (Uruguay) | 0x380a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanisch (Venezuela) | 0x200a | 0x0c0a | Modern_Spanish_CI_AS |
| Suaheli (Kenia) | 0x0441 | 0x0409 | Latin1_General_CI_AS |
| Schwedisch (Finnland) | 0x081d | 0x040b | Finnish_Swedish_CI_AS |
| Schwedisch (Schweden) | 0x041d | 0x040b | Finnish_Swedish_CI_AS |
| Syrisch (Syrien) | 0x045a | 0x045a | Auf Serverebene nicht verfügbar |
| Tadschikisch (Tadschikistan) | 0x0428 | 0x0419 | Cyrillic_General_CI_AS |
| Tamazight (Algerien, lateinisch) | 0x085f | 0x085f | Latin1_General_CI_AI |
| Tamil (Indien) | 0x0449 | 0x0439 | Auf Serverebene nicht verfügbar |
| Tatarisch (Russische Föderation) | 0x0444 | 0x0444 | Cyrillic_General_CI_AS |
| Telugu (Indien) | 0x044a | 0x0439 | Auf Serverebene nicht verfügbar |
| Thai (Thailand) | 0x041e | 0x041e | Thai_CI_AS |
| Tibetisch (VRC) | 0x0451 | 0x0451 | Auf Serverebene nicht verfügbar |
| Türkisch (Türkiye) | 0x041f | 0x041f | Turkish_CI_AS |
| Turkmenisch (Turkmenistan) | 0x0442 | 0x0442 | Latin1_General_CI_AI |
| Uighurisch (VRC) | 0x0480 | 0x0480 | Latin1_General_CI_AI |
| Ukrainisch (Ukraine) | 0x0422 | 0x0422 | Ukrainian_CI_AS |
| Obersorbisch (Deutschland) | 0x042e | 0x042e | Latin1_General_CI_AI |
| Urdu (Pakistan) | 0x0420 | 0x0420 | Latin1_General_CI_AI |
| Usbekisch (Usbekistan, kyrillisch) | 0x0843 | 0x0419 | Cyrillic_General_CI_AS |
| Usbekisch (Usbekistan, lateinisch) | 0x0443 | 0x0443 | Uzbek_Latin_90_CI_AS |
| Vietnamesisch (Vietnam) | 0x042a | 0x042a | Vietnamese_CI_AS |
| Walisisch (Großbritannien) | 0x0452 | 0x0452 | Latin1_General_CI_AI |
| Wolof (Senegal) | 0x0488 | 0x040c | French_CI_AS |
| Xhosa/isiXhosa (Südafrika) | 0x0434 | 0x0409 | Latin1_General_CI_AS |
| Yi (VRC) | 0x0478 | 0x0409 | Latin1_General_CI_AS |
| Yoruba (Nigeria) | 0x046a | 0x0409 | Latin1_General_CI_AS |
| Zulu/isiZulu (Südafrika) | 0x0435 | 0x0409 | Latin1_General_CI_AS |
Nachdem Sie dem Server eine Sortierung zugewiesen haben, können Sie diese nur ändern, indem Sie alle Datenbankobjekte und Daten exportieren, die master Datenbank neu erstellen und alle Datenbankobjekte und Daten wieder importieren. Anstatt die Standardsortierung einer Instanz von SQL Server zu ändern, können Sie die gewünschte Sortierung beim Erstellen einer neuen Datenbank oder Datenbankspalte festlegen.
Zum Abfragen der Serversortierung einer Instanz von SQL Server verwenden Sie die SERVERPROPERTY-Funktion:
SELECT CONVERT(nvarchar(128), SERVERPROPERTY('collation'));
Verwenden Sie die folgende integrierte fn_helpcollations()-Funktion, um alle verfügbaren Sortierungen vom Server abzufragen.
SELECT * FROM sys.fn_helpcollations();
Sortierung in Azure SQL-Datenbank
Sie können die logische Serversortierung in der Azure SQL-Datenbank nicht ändern oder festlegen, aber die Sortierungen jeder Datenbank sowohl für Daten als auch für den Katalog konfigurieren. Die Katalogsortierung bestimmt die Sortierung für Systemmetadaten, z. B. Objektbezeichner. Beide Sortierungen können unabhängig angegeben werden, wenn Sie die Datenbank im Azure-Portal, in T-SQL mit CREATE DATABASE, in PowerShell mit New-AzSqlDatabase erstellen.
Sortierungen in verwalteter Azure SQL-Instanz
Die Sortierung auf Serverebene in der verwalteten Azure SQL-Instanz kann beim Erstellen der Instanz festgelegt werden. Sie kann später nicht mehr geändert werden.
Weitere Informationen finden Sie unter Festlegen oder Ändern der Serversortierung.
Sortierungen auf Datenbankebene
Beim Erstellen oder Ändern einer Datenbank können Sie die COLLATE-Klausel der CREATE DATABASE- oder ALTER DATABASE-Anweisung verwenden, um die Standardsortierung für die Datenbank festzulegen. Wenn keine Sortierung angegeben wird, wird die Datenbank der Serversortierung zugeordnet.
Sie können die Sortierung von Systemdatenbanken nicht ändern, es sei denn, Sie ändern die Sortierung für den Server.
- In SQL Server und Azure SQL Managed Instance, wird die Datenbanksortierung für alle Metadaten in der Datenbank verwendet und ist der Standard für alle Zeichenfolgenspalten, temporären Objekte, Variablennamen und anderen in der Datenbank verwendeten Zeichenfolgen.
- In der Azure SQL-Datenbank gibt es keine Serversortierung, sodass jede Datenbank eine Sortierung für Daten und eine Sortierung für den Katalog aufweist. Die CATALOG_COLLATION wird für alle Metadaten in der Datenbank verwendet und ist der Standard für alle Zeichenfolgenspalten, temporären Objekte, Variablennamen und anderen in der Datenbank verwendeten Zeichenfolgen. Die CATALOG_COLLATION wird beim Erstellen festgelegt und kann nicht geändert werden.
Wenn Sie die Sortierung einer Benutzerdatenbank ändern, treten möglicherweise Sortierungskonflikte auf, wenn Abfragen in der Datenbank auf temporäre Tabellen zugreifen. Temporäre Tabellen werden immer in der tempdb-Systemdatenbank tempdb gespeichert, die die Sortierung für die Instanz verwendet. Abfragen, die Zeichendaten aus der Benutzerdatenbank und tempdb vergleichen, können fehlschlagen, wenn die Sortierungen einen Konflikt beim Auswerten der Zeichendaten verursachen. Sie können dieses Problem beheben, indem Sie die COLLATE-Klausel in der Abfrage angeben. Weitere Informationen finden Sie unter COLLATE (Transact-SQL).
Sie können die Sortierung einer Benutzerdatenbank ändern, indem Sie eine ALTER DATABASE-Anweisung wie das folgende Codebeispiel verwenden:
ALTER DATABASE myDB COLLATE Greek_CS_AI;
Wichtig
Das Ändern der Sortierung auf Datenbankebene hat keinen Einfluss auf Sortierungen auf Spalten- oder Ausdrucksebene. Es wirkt sich nicht auf Daten in vorhandenen Spalten aus.
Sie können die aktuelle Sortierung einer Datenbank abrufen, indem Sie eine Anweisung wie das folgende Codebeispiel verwenden:
SELECT CONVERT (nvarchar(128), DATABASEPROPERTYEX('database_name', 'collation'));
Sortierungen auf Spaltenebene
Wenn Sie eine Tabelle erstellen oder ändern, können Sie mithilfe der COLLATE-Klausel Sortierungen für alle Zeichenfolgenspalten festlegen. Wenn Sie keine Sortierung festlegen, wird der Spalte die Standardsortierung der Datenbank zugewiesen.
Sie können die Sortierung einer Spalte ändern, indem Sie eine ALTER TABLE-Anweisung wie das folgende Codebeispiel verwenden:
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI;
Sortierungen auf Ausdrucksebene
Sortierungen auf Ausdrucksebene werden zum Zeitpunkt der Ausführung einer Anweisung festgelegt. Sie haben Auswirkungen auf die Art und Weise, wie ein Resultset zurückgegeben wird. Dadurch können ORDER BY-Sortierergebnisse gebietsschemaspezifisch sein. Verwenden Sie eine COLLATE-Klausel wie das folgende Codebeispiel, um Sortierungen auf Ausdrucksebene zu implementieren:
SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;
Gebietsschema
Ein Gebietsschema besteht aus Informationen, die zu einem Ort oder einer Kultur gehören. Diese Informationen können den Namen und Bezeichner der gesprochenen Sprache, die Schrift zum Schreiben der Sprache und kulturelle Konventionen umfassen. Sortierungen können einem oder mehreren Gebietsschemas zugeordnet sein. Weitere Informationen finden Sie unter Von Microsoft zugewiesene Gebietsschemabezeichner (LCIDs).
Codepage
Eine Codepage ist ein geordneter Satz von Zeichen in einem vorgegebenen Skript, in dem ein numerischer Index, oder Codepunktwert, mit jedem Zeichen verbunden ist. Eine Windows-Codepage wird in der Regal als Zeichensatz oder charset bezeichnet. Codepages werden zur Unterstützung der Zeichensätze und Tastaturlayouts verschiedener Windows-Systemgebietsschemas verwendet.
Sortierreihenfolge
Die Sortierreihenfolge gibt an, wie Datenwerte sortiert werden. Die Reihenfolge wirkt sich auf die Ergebnisse von Datenvergleichen aus. Daten werden mithilfe von Sortierungen sortiert, die mit Indizes optimiert werden können.
Unicode-Unterstützung
Unicode ist ein Standard zum Zuordnen von Codepunkten zu Zeichen. Da dieser Standard entwickelt wurde, um alle Zeichen aus allen Sprachen der Welt zu unterstützen, benötigen Sie keine unterschiedlichen Codepages zur Verarbeitung von verschiedenen Zeichensätzen.
Grundlagen zu Unicode
Das Speichern von Daten in mehreren Sprachen innerhalb einer Datenbank ist schwierig zu verwalten, wenn nur Zeichendaten und Codepages verwendet werden. Es ist außerdem schwierig, eine Codepage für die Datenbank zu finden, die alle erforderlichen sprachenspezifischen Zeichen speichern kann. Außerdem ist es schwierig, die richtige Übersetzung von Sonderzeichen zu gewährleisten, wenn sie von verschiedenen Clients gelesen oder geändert werden, die verschiedene Codepages ausführen. Datenbanken, die internationale Clients unterstützen, sollten immer Unicode-Datentypen anstelle von Nicht-Unicode-Datentypen verwenden.
Eine Datenbank für Kunden in Nordamerika muss z. B. drei Hauptsprachen verarbeiten:
- Spanische Namen und Adressen für Mexiko.
- Französische Namen und Adressen für Quebec.
- Englische Namen und Adressen für den übrigen Teil Kanadas und die USA.
Wenn Sie nur Zeichenspalten und Codepages verwenden, müssen Sie sicherstellen, dass die Datenbank mit einer Codepage installiert wird, die die Zeichen aller drei Sprachen verarbeiten kann. Außerdem müssen Sie darauf achten, dass die ordnungsgemäße Übersetzung von Zeichen aus einer der Sprachen sichergestellt ist, wenn die Zeichen von Clients gelesen werden, die eine Codepage für eine andere Sprache ausführen.
Hinweis
Die Codepages, die ein Client verwendet, werden durch die Einstellungen des Betriebssystems (OS) bestimmt. Verwenden Sie zum Festlegen von Clientcodepages unter Windows die Option Ländereinstellungen in der Systemsteuerung.
Es wäre schwierig, eine Codepage für Zeichendatentypen auszuwählen, die alle Zeichen unterstützt, die weltweit verwendet werden. Die einfachste Möglichkeit, Zeichendaten in internationalen Datenbanken zu verwalten, besteht darin, immer einen Datentyp zu verwenden, der Unicode unterstützt.
Unicode-Datentypen
Wenn Sie Zeichendaten speichern, die mehrere Sprachen in SQL Server widerspiegeln (SQL Server 2005 (9.x) und höher), verwenden Sie Unicode-Datentypen (nchar, nvarchar und ntext) anstelle von Nicht-Unicode-Datentypen (char, varchar und text).
Hinweis
Bei Unicode-Datentypen kann Datenbank-Engine bis zu 65.536 Zeichen (UCS-2) oder den gesamten Unicode-Bereich (1.114.112 Zeichen) darstellen, wenn ergänzende Zeichen verwendet werden. Weitere Informationen zum Aktivieren von ergänzenden Zeichen finden Sie unter Ergänzende Zeichen.
Alternativ dazu gilt ab SQL Server 2019 (15.x) Folgendes: Wenn eine für UTF-8 aktivierte Sortierung (_UTF8) verwendet wird, werden Datentypen, die zuvor kein Unicode waren (char und varchar) zu Unicode-Datentypen mit UTF-8-Codierung. SQL Server 2019 (15.x) ändert das Verhalten der bereits vorhandenen Unicode-Datentypen (nchar, nvarchar und ntext) nicht, die weiterhin USC-2- oder UTF-16-Codierung verwenden. Weitere Informationen finden Sie unter Speicherunterschiede zwischen UTF-8 und UTF-16.
Weitere Überlegungen
Nicht-Unicode-Datentypen verfügen über umfassende Einschränkungen. Das liegt daran, dass ein Nicht-Unicode-Computer auf die Verwendung einer einzelnen Codepage beschränkt ist. Es kann sein, dass Sie mit Unicode eine bessere Systemleistung erzielen, da weniger Codepagekonvertierungen erforderlich sind. Unicode-Sortierungen müssen auf der Datenbank-, Spalten- oder Ausdrucksebene einzeln ausgewählt werden, weil sie auf Serverebene nicht unterstützt werden.
Wenn Sie Daten von einem Server auf einen Client verschieben, wird die Serversortierung von älteren Clienttreibern möglicherweise nicht erkannt. Dies kann passieren, wenn Sie Daten von einem Unicode-Server auf einen Nicht-Unicode-Client verschieben. Die beste Möglichkeit, dieses Problem zu beheben, besteht in einem Update des Clientbetriebssystems, wobei die zugrunde liegenden Systemsortierungen aktualisiert werden. Wenn auf dem Client Datenbankclient-Software installiert ist, sollten Sie ein Serviceupdate der Datenbankclient-Software in Erwägung ziehen.
Tipp
Sie können auch versuchen, eine andere Sortierung für die Daten auf dem Server zu verwenden. Wählen Sie eine Sortierung aus, die einer Codepage auf dem Client zugeordnet werden kann.
Sie können eine der Sortierungen mit ergänzenden Zeichen (_SC) oder eine der Version-140-Sortierungen auswählen, um die in SQL Server verfügbaren UTF-16-Sortierungen (SQL Server 2012 (11.x) und höher) zu verwenden, um die Suche und die Sortierung einiger Unicode-Zeichen (nur Windows-Sortierungen) zu verbessern.
Sie müssen Sortierungen mit UTF-8-Codierung (_UTF8) auswählen, um die in SQL Server 2019 (15.x) verfügbaren UTF-8-Sortierungen verwenden zu können und die Suche und Sortierung einiger Unicode-Zeichen (nur Windows-Sortierungen) zu verbessern.
Das UTF8-Flag kann auf folgende Sortierungen angewendet werden:
- Linguistische Sortierungen, die bereits ergänzende Zeichen (_SC) oder Variierungsauswahlzeichen (_VSS) unterstützen
- Die binäre Sortierung BIN2
Das UTF8-Flag kann auf folgende Sortierungen nicht angewendet werden:
- Linguistische Sortierungen, die keine ergänzenden Zeichen (_SC) oder Variierungsauswahlzeichen (_VSS) unterstützen
- Die binären BIN-Sortierungen
- Die SQL_*-Sortierungen
Zum Abwägen der Vor- und Nachteile von Unicode- und Nicht-Unicode-Datentypen müssen Sie das Szenario testen und die Leistungsunterschiede in Ihrer Umgebung messen. Es wird empfohlen, die Sortierung zu standardisieren, die auf Systemen in Ihrem Unternehmen verwendet wird, und nach Möglichkeit Unicode-Server und -Clients bereitzustellen.
In vielen Fällen interagiert SQL Server mit anderen Servern oder Clients, und Ihr Unternehmen verwendet möglicherweise mehrere Standards für den Datenzugriff zwischen Anwendungen und Serverinstanzen. SQL Server -Clients stellen einen der beiden Haupttypen dar:
- Unicode-Clients, die OLE DB und Open Database Connectivity (ODBC) Version 3.7 oder höher verwenden.
- Nicht-Unicode-Clients, die DB Library und ODBC Version 3.6 oder früher verwenden.
Die folgende Tabelle enthält Informationen zur Verwendung mehrsprachiger Daten mit verschiedenen Kombinationen von Unicode- und Nicht-Unicode-Servern:
| Server | Client | Vorteile oder Einschränkungen |
|---|---|---|
| Unicode | Unicode | Da Unicode-Daten im gesamten System verwendet werden, verfügt dieses Szenario über die beste Systemleistung und den besten Schutz vor Beschädigung der abgerufenen Daten. Dies ist der Fall bei ActiveX Data Objects (ADO), OLE DB und ODBC Version 3.7 oder höher. |
| Unicode | Nicht-Unicode | In diesem Szenario sind Einschränkungen oder Fehler beim Verschieben von Daten auf einen Clientcomputer möglich. Dies gilt besonders für Verbindungen zwischen einem Server, auf dem ein neueres Betriebssystem ausgeführt wird, und einem Client, auf dem eine ältere Version von SQL Server oder ein älteres Betriebssystem installiert ist. Die Unicode-Daten auf dem Server versuchen, eine Zuordnung zu einer entsprechenden Codeseite auf dem Nicht-Unicode-Client zu erstellen, um die Daten zu konvertieren. |
| Nicht-Unicode | Unicode | Dies ist keine gute Konfiguration für die Verwendung mehrsprachiger Daten. Sie können keine Unicode-Daten auf den Nicht-Unicode-Server schreiben. Es ist wahrscheinlich, dass Probleme auftreten, wenn Daten an Server gesendet werden, die von der Codepage des Servers nicht erfasst werden. |
| Nicht-Unicode | Nicht-Unicode | Dieses Szenario ist bei mehrsprachigen Daten mit zahlreichen Beschränkungen verbunden. Sie können nur eine Codepage verwenden. |
Ergänzende Zeichen
Das Unicode Consortium hat jedem Zeichen einen eindeutigen Codepunkt zugeordnet, der einem Wert im Bereich von 000000 bis 10FFFF entspricht. Die am häufigsten verwendeten Zeichen weisen Codepunktwerte im Bereich von 000000 bis 00FFFF (65.536 Zeichen) auf, die in ein 8-Bit- oder 16-Bit-Wort im Arbeitsspeicher und auf dem Datenträger passen. Dieser Bereich wird in der Regel als der Basic Multilingual Plane (BMP) festgelegt.
Aber das Unicode Consortium hat 16 zusätzliche „Ebenen“ von Zeichen eingerichtet, die jeweils genauso groß sind wie die BMP. Durch diese Definition kann Unicode 1.114.112 Zeichen (d. h. 216 × 17 Zeichen) innerhalb des Codepunktbereichs von 000000 bis 10FFFF darstellen. Zeichen mit einem Codepunktwert größer als 00FFFF benötigen zwei bis vier aufeinanderfolgende 8-Bit-Wörter (UTF-8) oder zwei aufeinanderfolgende 16-Bit-Wörter (UTF-16). Diese Zeichen, die sich außerhalb der BMP befinden, werden als ergänzende Zeichenbezeichnet, und die zusätzlichen aufeinanderfolgenden 8-Bit- oder 16-Bit-Wörter werden als Ersatzzeichenpaarebezeichnet. Weitere Informationen über Zusatzzeichen, Surrogate und Surrogatpaare finden Sie im Unicode-Standard.
SQL Server bietet Datentypen wie nchar und nvarchar zur Speicherung von Unicode-Daten im BMP-Bereich (000000-00FFFF), die von der Datenbank-Engine mit UCS-2 kodiert werden.
Mit SQL Server 2012 (11.x) wurde eine neue Gruppe von Sortierungen von ergänzenden Zeichen (_SC) eingeführt, die nur mit den Datentypen nchar, nvarchar und sql_variant verwendet werden können, um den gesamten Unicode-Zeichenbereich (000000 bis 10FFFF) darzustellen. Beispiel: Latin1_General_100_CI_AS_SC oder Japanese_Bushu_Kakusu_100_CI_AS_SC, wenn Sie eine japanische Sortierung verwenden.
Mit SQL Server 2019 (15.x) wurde die Unterstützung für ergänzende Zeichen mit den neuen UTF-8-fähigen Sortierungen (_UTF8) auf die Datentypen char und varchar erweitert. Diese Datentypen können auch den gesamten Unicode-Zeichenbereich darstellen.
Hinweis
Ab SQL Server 2017 (14.x) unterstützen werden ergänzende Zeichen automatisch in allen neuen Sortierungen unterstützt.
Bei Verwendung ergänzender Zeichen:
Ergänzende Zeichen können bei Sortier- und Vergleichsvorgängen für Sortierungsversionen ab 90 verwendet werden.
Alle Sortierungen von Version 100 unterstützen die linguistische Sortierung mit ergänzenden Zeichen.
Die Verwendung von ergänzenden Zeichen wird in Metadaten nicht unterstützt, z. B. in Namen von Datenbankobjekten.
Das SC-Flag kann in folgenden Versionen angewendet werden:
- Sortierungen von Version 90
- Sortierungen von Version 100
Das SC-Flag auf folgende Sortierungen nicht angewendet werden:
- Nicht versionierte Windows-Sortierungen der Version 80
- Die binären Sortierungen BIN und BIN2
- Die SQL*-Sortierungen
- Sortierungen der Version 140 (sie benötigen das SC-Flag nicht, da sie ergänzende Zeichen bereits unterstützen)
In der folgenden Tabelle wird das Verhalten einiger Zeichenfolgenfunktionen und Zeichenfolgenoperatoren verglichen, wenn diese ergänzende Zeichen mit und ohne SCA-Sortierung (supplementary character-aware) verwenden:
| Zeichenfolgenfunktion oder Operator | Mit SCA-Sortierung | Ohne SCA-Sortierung |
|---|---|---|
| CHARINDEX LEN PATINDEX |
Das UTF-16-Ersatzzeichenpaar wird als einzelner Codepunkt betrachtet. | Das UTF-16-Ersatzzeichenpaar wird als zwei Codepunkte betrachtet. |
| LEFT REPLACE REVERSE RIGHT SUBSTRING STUFF |
Diese Funktionen behandeln jedes Ersatzzeichenpaar als einzelnen Codepunkt und funktionieren wie erwartet. | Diese Funktionen können Ersatzzeichenpaare möglicherweise aufteilen und zu unerwarteten Ergebnissen führen. |
| NCHAR | Gibt das Zeichen zurück, das dem angegebenen Unicode-Codepunktwert im Bereich von 0 bis 0x10FFFF entspricht. Wenn der angegebene Wert im Bereich von 0 bis 0xFFFF liegt, wird ein Zeichen zurückgegeben. Bei höheren Werten wird das entsprechende Ersatzzeichenpaar zurückgegeben. | Ein Wert größer als 0xFFFF gibt anstelle des entsprechenden Ersatzzeichens NULL zurück. |
| UNICODE | Gibt einen UTF-16-Codepunkt im Bereich von 0 bis 0x10FFFF zurück. | Gibt einen UCS-2-Codepunkt im Bereich von 0 bis 0xFFFF zurück. |
| Einzelnes zu suchendes Zeichen Platzhalterzeichen - nicht zu suchende(s) Zeichen |
Ergänzende Zeichen werden für alle Platzhaltervorgänge unterstützt. | Ergänzende Zeichen werden für diese Platzhaltervorgänge nicht unterstützt. Andere Platzhalteroperatoren werden unterstützt. |
GB18030-Unterstützung
GB18030 ist ein separater Standard, der in der Volksrepublik China zur Codierung von chinesischen Schriftzeichen verwendet wird. In GB18030 können Zeichen 1, 2 oder 4 Bytes lang sein. SQL Server bietet Unterstützung für GB18030-codierte Zeichen, indem diese erkannt werden, wenn Sie den Server von einer clientseitigen Anwendung erreichen, und in systemeigene Unicode-Zeichen konvertiert und als solche gespeichert werden. Nachdem sie auf dem Server gespeichert werden, werden sie in darauffolgenden Vorgängen als Unicode-Zeichen behandelt.
Sie können eine beliebige chinesische Sortierung verwenden. Empfohlen wird die aktuelle Version 100. Alle Sortierungen der Version 100 unterstützen die linguistische Sortierung mit GB18030-Zeichen. Wenn die Daten ergänzende Zeichen (Ersatzzeichenpaare) enthalten, können Sie Such- und Sortiervorgänge mithilfe der in SQL Server verfügbaren SC-Sortierungen optimieren.
Hinweis
Stellen Sie sicher, dass Ihre Clienttools wie SQL Server Management Studio die Schriftart Dengxian verwenden, um Zeichenfolgen mit GB18030-codierten Zeichen richtig anzuzeigen.
Unterstützung komplexer Skripts
SQL Server kann das Eingeben, Speichern, Ändern und Anzeigen komplexer Skripts unterstützen. Zu komplexen Skripts gehören folgende Typen:
- Skripts, die sowohl die Kombination von Text von rechts nach links und Text von links nach rechts enthalten, als auch die Kombination von arabischem und englischem Text.
- Skripts, deren Zeichen die Form abhängig von ihrer Position ändern, oder abhängig davon, ob sie mit anderen Zeichen kombiniert werden, wie beispielsweise arabische, indische und thailändische Zeichen.
- Sprachen, wie beispielsweise Thailändisch, die ein internes Wörterbuch zum Erkennen von Wörtern erfordern, da keine Abstände zwischen den Wörtern vorhanden sind.
Datenbankanwendungen, die mit SQL Server interagieren, müssen über Steuerelemente verfügen, die komplexe Skripts unterstützen. Standardmäßige Windows-Formularsteuerelemente, die in verwaltetem Code erstellt werden, sind für komplexe Skripts aktiviert.
In SQL Server 2017 (14.x) hinzugefügte japanische Sortierungen
Ab SQL Server 2017 (14.x) werden neue japanische Sortierfamilien unterstützt, mit den Permutationen verschiedener Optionen (_CS, _AS, _KS, _WS, und _VSS), sowie _BIN und _BIN2.
Um diese Sortierungen aufzulisten, können Sie die SQL Server-Datenbank-Engine abfragen:
SELECT name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
Alle neuen Sortierungen verfügen über integrierte Unterstützung ergänzender Zeichen, sodass keine der neuen 140-Sortierungen ein SC-Flag benötigt (oder besitzt).
Diese Sortierungen werden in Indizes der Datenbank-Engine, in für den Arbeitsspeicher optimierten Tabellen, in Columnstore-Indizes und in nativ kompilierten Modulen unterstützt.
Unterstützung für UTF-8
Mit SQL Server 2019 (15.x) wird die vollständige Unterstützung für die weit verbreitete Zeichencodierung UTF-8 als Import- oder Exportcodierung oder als Sortierung für Zeichenfolgedaten auf Datenbank- und Spaltenebene eingeführt. UTF-8 ist für die Datentypen char and varchar zulässig und aktiviert, wenn Sie die Sortierung eines Objekts erstellen oder in eine Sortierung ändern, die ein UTF8-Suffix aufweist. Ein Beispiel hierfür ist das Ändern von LATIN1_GENERAL_100_CI_AS_SC in LATIN1_GENERAL_100_CI_AS_SC_UTF8.
UTF-8 ist nur für Windows-Sortierungen verfügbar, die ergänzende Zeichen gemäß der Einführung in SQL Server 2012 (11.x) unterstützen. Die Datentypen nchar und nvarchar ermöglichen nur die UCS-2- oder UTF-16-Codierung und bleiben unverändert.
Azure SQL Database und Azure SQL Managed Instance unterstützen auch UTF-8 auf Datenbank- und Spaltenebene, während SQL Managed Instance dies auch auf Serverebene unterstützt.
Speicherunterschiede zwischen UTF-8 und UTF-16
Das Unicode Consortium hat jedem Zeichen einen eindeutigen Codepunkt zugeordnet, der einem Wert im Bereich von 000000 bis 10FFFF entspricht. Mit SQL Server 2019 (15.x) stehen sowohl UTF-8- als auch UTF-16-Codierungen zur Darstellung des gesamten Bereichs zur Verfügung:
- Bei der UTF-8-Codierung benötigen Zeichen im ASCII-Bereich (000000 bis 00007F) 1 Byte, die Codepunkte von 000080 bis 0007FF 2 Bytes, die Codepunkte von 000800 bis 00FFFF 3 Bytes und die Codepunkte von 0010000 bis 0010FFFFFF 4 Bytes.
- Bei der UTF-16-Codierung benötigen die Codepunkte von 000000 bis 00FFFF 2 Bytes und die Codepunkte von 0010000 bis 0010FFFF 4 Bytes.
In der folgenden Tabelle werden die Codierungsspeicherbytes für jeden Zeichenbereich und Codierungstyp aufgeführt:
| Codebereich (hexadezimal) | Codebereich (dezimal) | Speicherplatz in Bytes1 mit UTF-8 | Speicherplatz in Bytes1 mit UTF-16 |
|---|---|---|---|
| 000000–00007F | 0–127 | 1 | 2 |
| 000080–00009F 0000A0–0003FF 000400–0007FF |
128–159 160–1,023 1,024–2,047 |
2 | 2 |
| 000800–003FFF 004000–00FFFF |
2,048–16,383 16,384–65,535 |
3 | 2 |
| 010000–03FFFF2 040000–10FFFF2 |
65,536–262,1432 262,144–1,114,1112 |
4 | 4 |
1 Die Speicherbytes beziehen sich auf die codierte Bytelänge, nicht auf die Datentypgröße beim Speichern auf dem Datenträger. Weitere Informationen zu den Speichergrößen auf dem Datenträger finden Sie unter nchar und nvarchar und char und varchar.
2 Der Codepunktbereich für ergänzende Zeichen.
Tipp
Üblicherweise denkt man in CHAR(n) und VARCHAR(n) oder in NCHAR(n) und NVARCHAR(n), wobei n für die Anzahl von Zeichen steht. Das liegt daran, dass in einer CHAR(10)-Spalte beispielsweise 10 ASCII-Zeichen im Bereich von 0 bis 127 gespeichert werden können, indem eine Sortierung wie Latin1_General_100_CI_AI angewendet wird, da jedes Zeichen in diesem Bereich nur 1 Byte nutzt.
Allerdings definiert n die Zeichenfolgenlänge bei CHAR(n) und VARCHAR(n) in Bytes (0–8,000) und bei NCHAR(n) und NVARCHAR(n) definiert n die Zeichenfolgenlänge in Bytepaaren (0–4,000). n definiert niemals die Anzahl von Zeichen, die gespeichert werden können.
Wie bereits erwähnt, kann die Wahl der geeigneten Unicode-Codierung und des geeigneten Datentyps je nach verwendetem Zeichensatz zu erheblichen Einsparungen beim Speicherplatz führen oder den aktuellen Speicherbedarf erhöhen. Wenn Sie beispielsweise eine UTF-8-fähige lateinische Sortierung wie Latin1_General_100_CI_AI_SC_UTF8 verwenden, speichert eine CHAR(10)-Spalte 10 Bytes und kann 10 ASCII-Zeichen im Bereich von 0 bis 127 enthalten. Er kann jedoch nur fünf Zeichen im Bereich 128-2047 und nur drei Zeichen im Bereich 2048-65535 speichern. Im Gegensatz dazu kann eine NCHAR(10)-Spalte, weil sie 10 Bytepaare (20 Bytes) speichert, 10 Zeichen im Bereich von 0 bis 65535 enthalten.
Bevor Sie entscheiden, ob Sie UTF-8- oder UTF-16-Codierung für eine Datenbank oder Spalte verwenden, sollten Sie die Verteilung der Zeichenfolgendaten berücksichtigen, die gespeichert werden:
- Wenn sie sich hauptsächlich im ASCII-Bereich von 0 bis 127 befinden (z. B. Englisch), erfordert jedes Zeichen 1 Byte bei UTF-8 und 2 Bytes bei UTF-16. Die Verwendung von UTF-8 hat Speichervorteile. Die Änderung eines vorhandenen Spaltendatentyps mit ASCII-Zeichen im Bereich von 0 bis 127 von
NCHAR(10)inCHAR(10)bei Verwendung einer UTF-8-fähigen Sortierung führt zu einer Verringerung der Speicheranforderungen von 50 %. Diese Verringerung ist darauf zurückzuführen, dassNCHAR(10)20 Byte für den Speicher erfordert, wohingegenCHAR(10)10 Byte für die Darstellung der gleichen Unicode-Zeichenfolge erfordert. - Oberhalb des ASCII-Bereichs benötigen fast alle lateinischen Schriftzeichen sowie Griechisch, Kyrillisch, Koptisch, Armenisch, Hebräisch, Arabisch, Syrisch, Tāna und N'Ko jeweils 2 Byte pro Zeichen in UTF-8 und UTF-16. In diesen Fällen gibt es für vergleichbare Datentypen keine signifikanten Speicherunterschiede (z. B. zwischen der Verwendung von char oder nchar).
- Wenn es sich hauptsächlich um ostasiatische Schriftzeichen handelt (z. B. Koreanisch, Chinesisch und Japanisch), benötigt jedes Zeichen 3 Byte mit UTF-8 und 2 Byte mit UTF-16. Die Verwendung von UTF-16 hat Speichervorteile.
- Zeichen im Bereich von 010000 bis 10FFFFFF benötigen jeweils 4 Byte in UTF-8 und UTF-16. In diesen Fällen gibt es keine Speicherunterschiede für vergleichbare Datentypen (z. B. zwischen der Verwendung von char oder nchar).
Weitere Überlegungen zur finden Sie unter Schreiben internationaler Transact-SQL-Anweisungen.
Konvertieren in UTF-8
Da das n in CHAR(n) und VARCHAR(n) oder in NCHAR(n) und NVARCHAR(n) die Größe des Bytespeichers und nicht die Anzahl der Zeichen definiert, die gespeichert werden können, ist es wichtig, die Größe des Datentyps zu ermitteln, in den konvertiert werden soll, um das Abschneiden von Daten zu verhindern.
Nehmen wir zum Beispiel eine Spalte, die als NVARCHAR(100) definiert ist und in der 180 Bytes japanischer Zeichen gespeichert werden. In diesem Beispiel werden die Spaltendaten derzeit mithilfe von UCS-2 oder UTF-16 codiert, wobei 2 Bytes pro Zeichen verwendet werden. Die Umstellung des Spaltentyps auf VARCHAR(200) reicht nicht aus, um das Abschneiden von Daten zu verhindern, da der neue Datentyp nur 200 Byte speichern kann, japanische Zeichen aber 3 Byte benötigen, wenn sie in UTF-8 kodiert sind. Daher muss die Spalte als VARCHAR(270) definiert werden, um Datenverluste durch das Abschneiden von Daten zu vermeiden.
Deshalb müssen Sie die voraussichtliche Bytegröße für die Spaltendefinition wissen, bevor Sie die vorhandenen Daten in UTF-8 konvertieren, und die Größe des neuen Datentyps entsprechend anpassen. Weitere Informationen finden Sie im Transact-SQL-Skript oder im SQL-Notebook in den GitHub-Datensätzen, die die Funktion DATALENGTH und die Anweisung COLLATE verwenden, um die Anforderungen an die richtige Datenlänge für UTF-8-Konvertierungsvorgänge in einer vorhandenen Datenbank zu bestimmen.
Verwenden Sie eine der in Festlegen oder Ändern der Spaltensortierung beschriebenen Methoden, um die Spaltensortierung und den Datentyp in einer vorhandenen Tabelle zu ändern.
Informationen zum Ändern der Datenbanksortierung, sodass neue Objekte die Datenbanksortierung standardmäßig erben können, oder zum Ändern der Serversortierung, sodass neue Datenbanken die Systemsortierung standardmäßig erben können, finden Sie im Abschnitt Verwandte Aufgaben in diesem Artikel.
Zugehörige Aufgaben
| Aufgabe | Artikel |
|---|---|
| Beschreibt, wie die Sortierung der Instanz von SQL Server festgelegt oder geändert wird. Die Änderung der Serversortierung ändert nichts an der Sortierung der vorhandenen Datenbanken. | Festlegen oder Ändern der Serversortierung |
| Beschreibt, wie die Sortierung einer Benutzerdatenbank festgelegt oder geändert wird. Das Ändern einer Datenbank-Sortierreihenfolge ändert nicht die Sortierreihenfolge der vorhandenen Tabellenspalten. | Festlegen oder Ändern der Datenbanksortierung |
| Beschreibt, wie die Sortierung einer Spalte in der Datenbank festgelegt oder geändert wird. | Festlegen oder Ändern der Spaltensortierung |
| Beschreibt, wie Sortierungsinformationen auf Server-, Datenbank- oder Spaltenebene zurückgegeben werden. | Anzeigen von Sortierungsinformationen |
| Beschreibt, wie Transact-SQL-Anweisungen geschrieben werden, die die Übertragung von einer Sprache in eine andere verbessern, oder wie mehrere Sprachen einfacher unterstützt werden. | Schreiben internationaler Transact-SQL-Anweisungen |
| Beschreibt, wie die Sprache von Fehlermeldungen und die bevorzugte Verwendung und Anzeige von Datums-, Zeit- und Währungsdaten geändert werden. | Festlegen einer Sitzungssprache |
Verwandte Inhalte
Weitere Informationen finden Sie in folgenden verwandten Inhalten:
- Bewährte Vorgehensweisen zur Sortierungsänderung bei SQL Server
- Verwenden des Unicode-Zeichenformats zum Importieren und Exportieren von Daten (SQL Server)
- Schreiben internationaler Transact-SQL-Anweisungen
- Bewährte Methode für die Migration zu Unicode in SQL Server (wird nicht mehr aktualisiert)
- Unicode Consortium
- Unicode Standard
- UTF-8-Unterstützung im OLE DB-Treiber für SQL Server
- SQL Server-Sortierungsname (Transact-SQL)
- Name der Windows-Sortierung (Transact-SQL)
- Einführung der UTF-8-Unterstützung für SQL Server
- COLLATE (Transact-SQL)
- Rangfolge von Sortierungen