Behandeln der Sortierung in Ihren Anwendungen
Einige Anwendungen, z. B. Microsoft Active Directory, Microsoft Exchange und Microsoft Access, verwalten eine sortierbare Datenbank mit Gebietsschema- und Sprachzeichenfolgen, die nach Namen (UTF-16-Zeichenfolge) indiziert sind, und deren zugeordneten Sortiergewichtungen.
Die Sortierung ist für Benutzer in ihren eigenen Gebietsschemas in der Regel intuitiv. Es kann jedoch für Anwendungsentwickler nicht intuitiv sein. In diesem Thema werden Überlegungen zur Behandlung der Sortierung in Ihren Anwendungen erläutert. Die Sortierung kann entweder linguistische oder ordinale (nicht linguistische) Sein.
Sortierfunktionen
Sie können eine Vielzahl von Sortierfunktionen in Ihren Anwendungen verwenden:
- NLS-Zeichenfolgenvergleichsfunktionen. Beispiele sind CompareString und CompareStringEx, CompareStringOrdinal, LCMapString, LCMapStringEx, FindNLSString,FindNLSStringEx und FindStringOrdinal. Weitere Informationen zu Sicherheitsproblemen im Zusammenhang mit den Zeichenfolgenvergleichsfunktionen finden Sie unter Sicherheitsüberlegungen: Internationale Features .
- Wrapperfunktionen, die intern die Zeichenfolgenvergleichsfunktionen aufrufen. Die gängigsten Funktionen sind lstrcmp und lstrcmpi, die CompareString aufrufen.
In der Regel werten die Sortierfunktionen Zeichenfolgen Zeichen für Zeichen aus. Viele Sprachen weisen jedoch mehrere Zeichenelemente auf, z. B. das zweistellige Paar "CH" im traditionellen Spanischen. CompareString und CompareStringEx verwenden den von der Anwendung bereitgestellten Gebietsschemabezeichner oder -namen, um elemente mit mehreren Zeichen zu identifizieren. Im Gegensatz dazu verwenden lstrcmp und lstrcmpi das Gebietsschema des Benutzers.
Ein weiteres Beispiel ist Vietnamesisch, das viele zweistellige Elemente enthält, z. B. die gültigen Groß-, Titel-, und Kleinbuchstaben-Formen von "GI", die jeweils "GI", "Gi" und "gi" sind. Jedes dieser Formulare wird als einzelnes Sortierelement behandelt und, wenn die Groß- und Kleinschreibung ignoriert wird, als gleich verglichen. Da "gI" jedoch nicht als einzelnes Element gültig ist, behandeln CompareString, CompareStringEx, lstrcmp und lstrcmpi "gI" als zwei separate Elemente.
Die Funktionen CompareString, CompareStringEx, lstrcmp, lstrcmpi, LCMapString, LCMapStringEx, FindNLSString und FindNLSStringEx verwenden standardmäßig eine "Wortsortierung"-Technik. Bei dieser Art von Art kommen alle Interpunktionszeichen und andere nichtalphanumerische Zeichen, mit Ausnahme des Bindestrichs und des Apostrophs, vor jedem alphanumerischen Zeichen. Der Bindestrich und der Apostroph werden anders behandelt als die anderen nichtalphanumerischen Zeichen, um sicherzustellen, dass Wörter wie "coop" und "co-op" in einer sortierten Liste zusammenbleiben.
Anstelle einer Wortsortierung kann die Anwendung eine "Zeichenfolgensortierung"-Technik von den Sortierfunktionen anfordern, indem sie das flag SORT_STRINGSORT angibt. Eine Zeichenfolgensortierung behandelt den Bindestrich und das Apostroph wie jedes andere nichtalphanumerische Zeichen. Ihre Positionen in der Sortiersequenz liegen vor den alphanumerischen Zeichen.
In der folgenden Tabelle werden die Ergebnisse einer Wortsortierung mit den Ergebnissen einer Zeichenfolgensortierung verglichen.
| Word Sortieren | Zeichenfolgensortierung |
|---|---|
| Billet | Rechnung |
| Rechnungen | Billet |
| Rechnung | Rechnungen |
| nicht | Nicht |
| Cant | nicht |
| Nicht | Cant |
| Con | Co-Op |
| Coop | Con |
| Co-Op | Coop |
Zeichenfolgen linguistisch sortieren
Die Funktionen CompareString und CompareStringEx testen auf linguistische Gleichheit. Ihre Anwendungen sollten diese Funktionen mit dem richtigen Gebietsschema verwenden, um Zeichenfolgen sprachlich zu sortieren.
Hinweis
Aus Gründen der Kompatibilität mit Unicode sollte eine Anwendung CompareStringEx oder die Unicode-Version von CompareString bevorzugen. Ein weiterer Grund für die Bevorzugung von CompareStringEx ist, dass Microsoft aus Gründen der Interoperabilität zur Verwendung von Gebietsschemanamen anstelle von Gebietsschemabezeichnern für neue Gebietsschemas migriert. Jede Anwendung, die nur unter Windows Vista und höher ausgeführt wird, sollte CompareStringEx verwenden.
Eine weitere Möglichkeit zum Testen der linguistischen Gleichheit ist die Verwendung von lstrcmp oder lstrcmpi, die immer eine Wortsortierung verwenden. Die lstrcmpi-Funktion ruft CompareString mit dem NORM_IGNORECASE-Flag auf, während lstrcmp es ohne dieses Flag aufruft. Eine Übersicht über die Verwendung der Wrapperfunktionen finden Sie unter Zeichenfolgen.
Die Funktionen rufen linguistisch geeignete Ergebnisse für alle Gebietsschemas ab. Die Erwartungen der Benutzer an unterschiedliche Gebietsschemas können sich im Sortierverhalten erheblich unterscheiden, wie in den folgenden Beispielen gezeigt.
- Viele Gebietsschemas setzen die Ae-Ligatur (æ) mit den Buchstaben ae gleich. Isländisch (Island) betrachtet es jedoch als separaten Buchstaben und platziert ihn nach Z in der Sortierreihenfolge.
- Der A-Ring (Å) sortiert normalerweise nur mit einem diakritischen Unterschied von A. Allerdings platziert Schwedisch (Schweden) den A Ring nach Z in der Sortierreihenfolge.
Die Funktionen versuchen, streng zu überprüfen, ob code points, die im Unicode-Standard definiert sind, kanonisch gleich einer Zeichenfolge mit entsprechenden Codepunkten sind. Beispielsweise ist der Codepunkt, der ein klein geschriebenes "u" mit einer Dieresis (ü) darstellt, kanonisch gleich einem kleingeschriebenen "u" in Kombination mit der Dieresis ( ̈). Beachten Sie jedoch, dass die kanonische Äquivalenz nicht immer möglich ist.
Da fast alle Daten, die mit Windows-Tastaturen und Eingabemethoden-Editoren (IMEs) eingegeben werden, der im Unicode-Standard definierten Normalisierungsform C entsprechen, liefert die Konvertierung eingehender Daten von anderen Plattformen mithilfe der NLS-Unicode-Normalisierungsfunktionen die konsistentsten Ergebnisse, insbesondere für Gebietsschemas, die das tibetische Skript oder das Hangul-Skript für moderne Hangul verwenden. Weitere Informationen zur Unterstützung der Unicode-Normalisierung in Windows Vista und höher finden Sie unter Verwenden der Unicode-Normalisierung zum Darstellen von Zeichenfolgen.
Wenn der Zeichenfolgenvergleich den Spracheinstellungen des Benutzers folgt, z. B. beim Sortieren von Elementen für ein geordnetes ListView-Steuerelement, kann die Anwendung eine der folgenden Aktionen ausführen:
- Rufen Sie lstrcmp oder lstrcmpi mit dem Gebietsschema des Benutzers auf.
- Rufen Sie CompareString oder CompareStringEx auf, um ein Gebietsschema für den Vergleich zu definieren, zusätzliche Flags zu übergeben, NULL-Zeichen einzubetten oder explizite Längen an Teile einer Zeichenfolge zu übergeben.
Wenn die Ergebnisse des Vergleichs unabhängig vom Gebietsschema konsistent sein sollen, z. B. wenn abgerufene Daten mit einer vordefinierten Liste oder einem internen Wert verglichen werden, sollte die Anwendung CompareString oder CompareStringEx verwenden, wobei der Locale-Parameter auf LOCALE_INVARIANT festgelegt ist. Für CompareString stimmt jeder der folgenden Aufrufe überein, auch wenn mystr "INLAP" ist. In diesem Fall schlägt ein gebietsschemabezogener Aufruf von lstrcmpi fehl, wenn das aktuelle Gebietsschema Vietnamesisch ist.
Unter Windows XP:
int iReturn = CompareString(LOCALE_INVARIANT, NORM_IGNORECASE, mystr, -1, _T("InLap"), -1);
Unter früheren Betriebssystemen:
DWORD lcid = MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT);
int iReturn = CompareString(lcid, NORM_IGNORECASE, mystr, -1, _T("InLap"), -1);
Ordinal sortieren von Zeichenfolgen
Für die ordinale (nicht linguistische) Sortierung sollten Ihre Anwendungen immer die CompareStringOrdinal-Funktion verwenden.
Hinweis
Diese Funktion ist nur für Windows Vista und höher verfügbar.
CompareStringOrdinal vergleicht zwei Unicode-Zeichenfolgen , um auf binäre Gleichheit und nicht auf linguistische Gleichheit zu testen. Beispiele für solche nicht linguistischen Zeichenfolgen sind NTFS-Dateinamen, Umgebungsvariablen und die Namen von Mutexes, Named Pipes oder Mailslots. Mit Ausnahme der Option ohne Berücksichtigung der Groß-/Kleinschreibung ignoriert diese Funktion alle nicht binären Äquivalenzen. Im Gegensatz zu einigen anderen Sortierfunktionen werden alle Codepunkte auf Gleichheit überprüft, einschließlich derer, die in linguistischen Sortierschemas keine Gewichtung erhalten.
Alle folgenden Anweisungen gelten für CompareStringOrdinal in binären Vergleichen, jedoch nicht für CompareString, CompareStringEx, lstrcmp oder lstrcmpi.
- Kanonisch äquivalente Sequenzen in Unicode, z. B. LATIN SMALL LETTER A WITH RING ABOVE (U+00e5) und LATIN SMALL LETTER A + COMBINING RING ABOVE (U+0061 U+030a), sind nicht gleich, obwohl sie identisch ("å") sind.
- Kanonisch ähnliche Zeichenfolgen in Unicode, wie z. B. LATIN LETTER SMALL CAPITAL Y (U+028f) und LATIN CAPITAL LETTER Y (U+0059), die sehr ähnlich aussehen ("ʏ" und "Y") und sich nur durch einige Sonderfallgewichtungen in den linguistischen Tabellen unterscheiden, werden als völlig unähnlich angesehen. Selbst wenn die Anwendung bIgnoreCase auf TRUE festlegt, werden diese Zeichenfolgen als unterschiedlich verglichen.
- Codepunkte, die definiert sind, aber keine linguistische Sortiergewichtung haben, z. B. ZERO WIDTH JOINER (U+200d), werden als mit ihren Codepunktgewichtungen behandelt.
- Codepunkte, die in späteren Unicode-Versionen definiert sind, in aktuellen linguistischen Tabellen jedoch keine Gewichtung aufweisen, werden als codepunktgewichtet behandelt.
- Codepunkte, die von Unicode nicht definiert sind, werden mit ihrer Codepunktgewichtung behandelt.
- Wenn die Anwendung bIgnoreCase auf TRUE festlegt, ordnet die Funktion die Groß- und Kleinschreibung mithilfe der Uppercasingtabelle des Betriebssystems anstelle der Informationen in den linguistischen Sortiertabellen zu. Somit ist die Zuordnung unabhängig vom Gebietsschema.
Weitere Informationen zu kanonisch äquivalenten Sequenzen in Unicode und kanonisch ähnlichen Zeichenfolgen in Unicode finden Sie unter Verwenden der Unicode-Normalisierung zum Darstellen von Zeichenfolgen.
Sortieren von Codepunkten
Einige Unicode-Codepunkte haben keine Gewichtung, z. B. ZERO WIDTH NON JOINER, U+200c. Die Sortierfunktionen werten die Codepunkte ohne Gewichtung absichtlich als gleichwertig aus, da sie bei der Sortierung keine Gewichtung haben. Unter Windows Vista und höher kann die Anwendung diese Codepunkte sortieren, indem sie die NLS-Zeichenfolgenvergleichsfunktionen aufruft, insbesondere CompareStringOrdinal, um alle Codepunkte im literalen, binären Sinne zu bewerten, z. B. bei der Kennwortvalidierung. Bei Betriebssystemen vor Windows Vista sollte die Anwendung die C-Laufzeitfunktion strcmp oder wcscmp verwenden.
Sortierfunktionen ignorieren diakritische Zeichen, z. B. NON SPACING BREVE, U+0306, wenn die Anwendung das flag hlink_NONSPACE angibt. Ebenso ignorieren diese Funktionen Symbole, z. B. EQUALS SIGN, U+003d , wenn das flag hlink_SYMBOLS angegeben wird. Unter Windows Vista und höher ruft die Anwendung CompareStringOrdinal für die Auswertung von diakritischen Und Symbolcodepunkten im literalen, binären Sinne auf. Bei Betriebssystemen vor Windows Vista sollte die Anwendung strcmp oder wcscmp verwenden.
Einige Codepunkte, z. B. 0xFFFF und 0x058b, sind derzeit nicht in Unicode zugewiesen. Diese Codepunkte erhalten keine Gewichtung bei der Sortierung und sollten niemals an die Sortierfunktionen übergeben werden. Die Anwendung sollte IsNLSDefinedString verwenden, um Nicht-Unicode-Codepunkte in einem Datenstrom zu erkennen.
Hinweis
Die Ergebnisse von IsNLSDefinedString können abhängig von der übergebenen Unicode-Version variieren, wenn ein Zeichen in einer höheren Version zu Unicode hinzugefügt und anschließend den Windows-Sortiertabellen hinzugefügt wird. Weitere Informationen finden Sie unter Verwenden der Sortierversionsverwaltung.
Sortieren von Ziffern als Zahlen
Unter Windows 7 und höher kann die Anwendung CompareString, CompareStringEx, LCMapString oder LCMapStringEx mit dem flag SORT_DIGITSASNUMBERS aufrufen. Dieses Flag unterstützt die Sortierung, die Ziffern als Zahlen behandelt, z. B. die Sortierung von "2" vor "10".
Beachten Sie, dass die Verwendung dieses Flags für Hexadezimalstellen wie die folgenden nicht geeignet ist.
- 01AF
1BCD
002A
12FA
AB1C
AB02
AB12
In diesem Fall werden die "Zahlen" in der Reihenfolge sortiert, aber der Benutzer erkennt eine schlecht sortierte Hexadezimalliste.
Zuordnen von Zeichenfolgen
Die Anwendung verwendet die LCMapString - oder LCMapStringEx-Funktion , um Zeichenfolgen zuzuordnen, wenn LCMAP_SORTKEY nicht angegeben ist. Eine zugeordnete Zeichenfolge ist NULL-endend, wenn die Quellzeichenfolge null-terminated ist.
Bei der Transformation zwischen Groß- und Kleinbuchstaben garantiert die Funktion nicht, dass ein einzelnes Zeichen einem einzelnen Zeichen zugeordnet wird. Beispielsweise können die LCMAP_LOWERCASE- und LCMAP_UPPERCASE-Flags das deutsche Sharp S ("ß") sich selbst zuordnen. Alternativ kann das LCMAP_UPPERCASE Flag "ß" zu "SS" zuordnen, und das LCMAP_LOWERCASE Flag kann "SS" zu "ß" zuordnen. Das Verhalten hängt von der NLS-Version ab.
Bei der Transformation zwischen Groß- und Kleinbuchstaben ist die Funktion kontextabhängig. Während z. B. das flag LCMAP_UPPERCASE sowohl das griechische Kleinbuchstaben-Sigma ("σ") als auch das griechische endgär geschriebene Sigma ("σ") korrekt dem griechischen Großbuchstaben sigma ("Σ") zuordnet, ordnet das LCMAP_LOWERCASE Flag "Σ" immer "σ" zu, niemals "").
Standardmäßig ordnet die Funktion das Kleinbuchstabe "i" dem Großbuchstaben "I" zu, auch wenn der Locale-Parameter türkisch oder aserbaidschanisch angibt. Um dieses Verhalten für Türkisch oder Aserbaidschanisch außer Kraft zu setzen, sollte die Anwendung LCMAP_LINGUISTIC_CASING angeben. Wenn dieses Flag mit dem entsprechenden Gebietsschema angegeben wird, ist "ı" (kleingeschriebenes punktloses I) die Kleinbuchstabenform von "I" (großgeschriebenes punktloses I) und "i" (Kleinbuchstaben gepunktetes I) die Kleinbuchstabenform von "İ" (Großbuchstaben gepunktete I).
Wenn das flag LCMAP_HIRAGANA angegeben ist, um Katakanazeichen hiragana-Zeichen zuzuordnen, und LCMAP_FULLWIDTH nicht angegeben ist, ordnet LCMapString oder LCMapStringEx nur Zeichen voller Breite hiragana zu. In diesem Fall werden katakana-Zeichen mit halber Breite wie in der Zielzeichenfolge ohne Zuordnung zu hiragana platziert. Die Anwendung muss LCMAP_FULLWIDTH angeben, um Katakanazeichen mit halber Breite hiragana zuzuordnen. Der Grund für diese Einschränkung ist, dass alle Hiragana-Zeichen Zeichen voller Breite sind.
Wenn die Anwendung Zeichen aus der Quellzeichenfolge entfernen muss, kann sie die Zuordnungsfunktion aufrufen, wobei die flags NORM_IGNORESYMBOLS und NORM_IGNORENONSPACE festgelegt sind und alle anderen Flags deaktiviert sind. Wenn die Anwendung dies mit einer Quellzeichenfolge ausführt, die nicht mit NULL beendet ist, kann die Funktion eine leere Zeichenfolge zurückgeben und keinen Fehler zurückgeben.
Erstellen von Sortierschlüsseln
Wenn die Anwendung LCMAP_SORTKEY angibt, generiert LCMapString oder LCMapStringEx einen Sortierschlüssel, ein binäres Array von Bytewerten. Der Sortierschlüssel ist keine echte Zeichenfolge, und seine Werte stellen das Sortierverhalten der Quellzeichenfolge dar, sind aber keine aussagekräftigen Anzeigewerte.
Hinweis
Die Funktion ignoriert die arabische Kashida während der Generierung eines Sortierschlüssels. Wenn eine Anwendung die Funktion aufruft, um einen Sortierschlüssel für eine Zeichenfolge zu erstellen, die eine arabische Kashida enthält, erstellt die Funktion keinen Sortierschlüsselwert.
Der Sortierschlüssel kann eine ungerade Anzahl von Bytes enthalten. Das flag LCMAP_BYTEREV kehrt nur eine gerade Anzahl von Bytes um. Das letzte Byte (ungerade Position) im Sortierschlüssel wird nicht umgekehrt. Wenn das beendende 0x00 Byte ein Byte mit ungerader Position ist, bleibt es das letzte Byte im Sortierschlüssel. Wenn das beendende 0x00 Byte ein byte mit gerader Position ist, tauscht es Positionen mit dem byte aus, das ihm vorangestellt ist.
Beim Generieren des Sortierschlüssels behandelt die Funktion den Bindestrich und den Apostroph anders als andere Interpunktionssymbole, sodass Wörter wie "coop" und "co-op" in einer Liste zusammenbleiben. Alle Interpunktionssymbole außer Bindestrich und Apostroph sortieren vor alphanumerischen Zeichen. Die Anwendung kann dieses Verhalten ändern, indem sie das SORT_STRINGSORT-Flag festlegt, wie unter Sortieren von Funktionen beschrieben.
Bei Verwendung in memcmp erzeugt der Sortierschlüssel dieselbe Reihenfolge wie bei verwendung der Quellzeichenfolge in CompareString oder CompareStringEx. Die memcmp-Funktion sollte anstelle von strcmp verwendet werden, da der Sortierschlüssel eingebettete NULL-Bytes enthalten kann.
Verwenden der Sortierversionsverwaltung
Eine Sortiertabelle weist zwei Zahlen auf, die ihre Version identifizieren: die definierte Version und die NLS-Version. Beide Zahlen sind DWORD-Werte, die aus einem Hauptwert und einem Nebenwert bestehen. Das erste Byte eines Werts ist reserviert, die nächsten beiden Bytes stellen die Hauptversion dar, und das letzte Byte stellt die Nebenversion dar. Hexadezimal ausgedrückt, ist das Muster 0xRRMMMMmm, wobei R gleich Reserviert, M gleich Haupt und m gleich Minor ist. Beispielsweise wird eine Hauptversion von 3 mit einer Nebenversion von 4 als 0x304 dargestellt.
Die definierte Version identifiziert das Repertoire der Codepunkte und ist für alle Gebietsschemas identisch. Die Hauptversion inkrementiert, um Änderungen an vorhandenen Codepunkten anzugeben. Die Nebenversion inkrementiert, um anzugeben, dass Codepunkte hinzugefügt wurden, aber keine zuvor vorhandenen Codepunkte geändert wurden.
Die NLS-Version ist spezifisch für einen Gebietsschemabezeichner oder Gebietsschemanamen und verfolgt Änderungen an Codepunktgewichtungen für das betroffene Gebietsschema nach. Die Hauptversion erhöht sich, wenn die Gewichtung für Codepunkte geändert wird, die bereits sortierbar waren. Die Nebenversion wird erhöht, wenn neuen Codepunkten Gewichtungen zugewiesen werden, aber alle anderen zuvor sortierbaren Codepunktgewichtungen bleiben unverändert.
Hinweis
Bei einer Hauptversion werden mindestens ein Codepunkt geändert, sodass die Anwendung alle Daten neu indizieren muss, damit Vergleiche gültig sind. Bei einer Nebenversion wird nichts verschoben, aber Codepunkte werden hinzugefügt. Für diesen Versionstyp muss die Anwendung nur Zeichenfolgen mit zuvor nichtortierbaren Werten neu indizieren.
Wichtig
Die Hauptversion wurde in Windows 8 geändert. Daten, die unter früheren Versionen von Windows erstellt wurden, müssen neu indiziert werden.
Sowohl die definierte Version als auch die NLS-Version gelten für sortierbare Codepunkte, die mithilfe der LCMapString - oder LCMapStringEx-Funktion mit dem LCMAP_SORTKEY-Flag abgerufen und auch von den Funktionen CompareString, CompareStringEx, FindNLSString und FindNLSStringEx verwendet werden. Wenn ein oder mehrere Codepunkte in einer Zeichenfolge unsortierbar sind, gibt die IsNLSDefinedString-FunktionFALSE zurück, wenn diese Zeichenfolge als Parameter an sie übergeben wird.
Die Anwendung kann entweder GetNLSVersion oder GetNLSVersionEx aufrufen, um sowohl die definierte Version als auch die NLS-Version für eine Sortiertabelle abzurufen.
Indizen der Datenbank
Aus Leistungsgründen sollte die Anwendung dieses Verfahren beim Indizieren der Datenbank befolgen.
So indizieren Sie die Datenbank ordnungsgemäß
- Speichern Sie für jede Funktion die NLS-Version, die Sortierschlüssel dieser Version und einen Hinweis auf die Sortierbarkeit für jede indizierte Zeichenfolge.
- Wenn die Nebenversion inkrementiert wird, indizieren Sie die zuvor nicht abortierbaren Zeichenfolgen erneut. Die in diesem Update betroffenen Zeichenfolgen sollten auf die Zeichenfolgen beschränkt werden, für die IsNLSDefinedString zuvor FALSE zurückgegeben hat.
- Wenn die Hauptversion inkrementiert wird, indizieren Sie alle Zeichenfolgen erneut, da die aktualisierten Gewichtungen das Verhalten einer beliebigen Zeichenfolge ändern können. Hauptversionen von Versionen sind sehr selten.
Probleme bei der Datenbankindizierung können aus folgenden Gründen auftreten:
- Ein späteres Betriebssystem kann Codepunkte definieren, die für ein früheres Betriebssystem nicht definiert sind, wodurch die Sortierung geändert wird.
- Codepunkte können aufgrund von Korrekturen in der Sprachunterstützung in verschiedenen Betriebssystemen unterschiedliche Sortiergewichtungen aufweisen.
Um die Notwendigkeit einer erneuten Indizierung der Datenbank unter diesen Umständen zu minimieren, kann die Anwendung IsNLSDefinedString verwenden, um definierte Zeichenfolgen von nicht definierten Zeichenfolgen zu unterscheiden, sodass die Anwendung Zeichenfolgen mit nicht definierten Codepunkten ablehnen kann. Mithilfe von GetNLSVersion oder GetNLSVersionEx kann die Anwendung ermitteln, ob sich eine NLS-Änderung auf das gebietsschema auswirkt, das für eine bestimmte Indextabelle verwendet wird. Wenn die Änderung keine Auswirkungen auf das Gebietsschema hat, muss die Anwendung die Tabelle nicht erneut indizieren.
Beispiele
Die folgende Tabelle veranschaulicht die Auswirkungen bestimmter Flags, die mit den Sortierfunktionen verwendet werden. In jedem Fall bestimmt die Auswahl von Flags, ob zwei unterschiedliche Zeichen zu Sortierungszwecken gleich sind.
| Zeichen 1 | Zeichen 2 | Standard | NORM_IGNOREWIDTH | NORM_IGNOREKANA | NORM_IGNOREWIDTH| NORMIGNOREKANA |
|---|---|---|---|---|---|
| "あ" U+3042 HIRAGANA BUCHSTABE A |
"ガ" U+30A2 KATAKANA BUCHSTABE A |
Ungleiche | Ungleiche | Gleich | Gleich |
| "ｵ" U+FF75 HALBWIDTH KATAKANA BUCHSTABE O |
"オ" U+30AA KATAKANA LETTER O |
Ungleiche | Gleich | Ungleiche | Gleich |
| "B" U+FF22 FULLWIDTH LATIN CAPITAL LETTER B |
„B“ U+0042 LATEINISCHER GROßBUCHSTABE B |
Ungleiche | Gleich | Ungleiche | Gleich |
Zugehörige Themen