War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Empfohlene Vorgehensweisen für die Verwendung von Zeichenfolgen in .NET Framework
Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

Empfohlene Vorgehensweisen für die Verwendung von Zeichenfolgen in .NET Framework

.NET Framework bietet umfangreiche Unterstützung für das Entwickeln von lokalisierten und globalisierten Anwendungen und erleichtert bei der Ausführung allgemeiner Operationen das Übernehmen von Konventionen der aktuellen oder einer anderen Kultur, beispielsweise bei der Sortierung und Anzeige von Zeichenfolgen. Das Sortieren oder Vergleichen von Zeichenfolgen stellt jedoch nicht immer eine kulturabhängige Operation dar. Beispielsweise sollten interne Zeichenfolgen von Anwendungen i. d. R. in allen Kulturen gleich behandelt werden. Wenn kulturabhängige Zeichenfolgendaten, z. B. XML-Tags, HTML-Tags, Benutzernamen, Dateipfade und Systemobjektnamen, kulturabhängig interpretiert werden, können Fehler im Anwendungscode auftreten, die Leistung kann sich verschlechtern, und in einigen Fällen kann es zu Sicherheitsproblemen kommen.

In diesem Thema werden die Methoden für die Sortierung, den Vergleich und die Schreibweise von Zeichenfolgen in .NET Framework untersucht. Darüber hinaus werden Empfehlungen zum Auswählen einer entsprechenden Zeichenfolgenbehandlungsmethode gegeben und weitere Informationen dazu bereitgestellt. Er wird außerdem untersucht, wie formatierte Daten, z. B. numerische Daten und Datums-/Uhrzeitdaten, für die Anzeige und Speicherung behandelt werden.

Dieses Thema enthält folgende Abschnitte:

Beachten Sie folgende grundlegende Empfehlungen zur Verwendung von Zeichenfolgen bei der Entwicklung mit .NET Framework:

Vermeiden Sie folgende Vorgehensweisen bei der Verwendung von Zeichenfolgen:

  • Verwenden Sie keine Überladungen, die die Regeln für Zeichenfolgenvergleiche in Zeichenfolgenoperationen nicht explizit oder implizit angeben.

  • Verwenden Sie keine Zeichenfolgenoperationen, die auf StringComparison.InvariantCulture basieren. Eine der wenigen Ausnahmen stellt dabei die Beibehaltung von Zeichenfolgen dar, die zwar linguistisch relevant, jedoch kulturunabhängig sind.

  • Verwenden Sie keine Überladung der String.Compare-Methode oder der CompareTo-Methode, und führen Sie eine Überprüfung mit einem Rückgabewert von 0 (null) durch, um zu bestimmten, ob zwei Zeichenfolgen übereinstimmen.

  • Verwenden Sie nicht kulturabhängige Formatierung, um numerische Daten oder Datums-/Uhrzeitdaten im Zeichenfolgenformat beizubehalten.

Zurück nach oben

Die Methoden zum Bearbeiten von Zeichenfolgen in .NET-Framework werden i. d. R. überladen. Während einige Überladungen normalerweise Standardwerte akzeptieren, geben andere Überladungen exakt an, wie Zeichenfolgen verglichen oder bearbeitet werden sollen. Methoden, die keine Standardwerte verwenden, enthalten i. d. R einen Parameter vom Typ StringComparison. Dabei handelt es sich um eine Enumeration, die explizit Regeln für Zeichenfolgenvergleiche anhand von Kultur und Schreibweise angibt. In der folgenden Tabelle werden die Member der StringComparison-Enumeration beschrieben.

StringComparison-Member

Beschreibung

[ F:System.StringComparison.CurrentCulture ]

Führt einen Vergleich mit der aktuellen Kultur unter Beachtung der Groß- und Kleinschreibung durch.

[ F:System.StringComparison.CurrentCultureIgnoreCase ]

Führt einen Vergleich mit der aktuellen Kultur ohne Beachtung der Groß- und Kleinschreibung durch.

[ F:System.StringComparison.InvariantCulture ]

Führt einen Vergleich mit der invarianten Kultur unter Beachtung der Groß- und Kleinschreibung durch.

[ F:System.StringComparison.InvariantCultureIgnoreCase ]

Führt einen Vergleich mit der invarianten Kultur ohne Beachtung der Groß- und Kleinschreibung durch.

[ F:System.StringComparison.Ordinal ]

Führt einen Ordinalvergleich durch.

[ F:System.StringComparison.OrdinalIgnoreCase ]

Führt einen Ordinalvergleich ohne Beachtung der Groß- und Kleinschreibung durch.

Die IndexOf-Methode, die den Index einer Teilzeichenfolge in einem String-Objekt zurückgibt, das einem Zeichen oder einer Zeichenfolge entspricht, weist beispielsweise neun Überladungen auf:

Aus den folgenden Gründen wird empfohlen, eine Überladung ohne Standardwerte auszuwählen:

  • Einige Überladungen mit Standardparametern (die in der Zeichenfolgeninstanz nach einem Char suchen) führen einen Ordinalvergleich durch, während andere Überladungen (die in der Zeichenfolgeninstanz nach einer Zeichenfolge suchen) kulturabhängig sind. Es ist nicht leicht, sich zu merken, welche Methode welchen Standardwert verwendet, und Überladungen können schnell verwechselt werden.

  • Der Zweck des Codes, der Standardwerte für Methodenaufrufe verwendet, ist nicht klar. Im folgenden Beispiel werden Standardwerte verwendet. Dabei ist nicht klar, ob der Entwickler tatsächlich einen ordinalen oder linguistischen Vergleich zweier Zeichenfolgen durchführen wollte oder ob der Unterschied in der Groß- und Kleinschreibung zwischen protocol und "http" möglicherweise dazu führt, dass bei einer Überprüfung auf Gleichheit false zurückgegeben wird.

    
    string protocol = GetProtocol(url);       
    if (String.Equals(protocol, "http")) {
       // ...Code to handle HTTP protocol.
    }
    else {
       throw new InvalidOperationException();
    }
    
    
    

Im Allgemeinen empfiehlt es sich, eine Methode aufzurufen, die keine Standardwerte verwendet, da der Zweck des Codes andernfalls möglicherweise nicht eindeutig ist. Dies erleichtert wiederum das Lesen, Verwalten und Debuggen des Codes. Im folgenden Beispiel wird auf die Fragen eingegangen, die sich zum vorherigen Beispiel stellen. Es wird deutlich gemacht, dass der Ordinalvergleich verwendet wird und dass Unterschiede in der Groß- und Kleinschreibung ignoriert werden.


string protocol = GetProtocol(url);       
if (String.Equals(protocol, "http", StringComparison.OrdinalIgnoreCase)) {
   // ...Code to handle HTTP protocol.
}
else {
   throw new InvalidOperationException();
}


Zurück nach oben

Zeichenfolgenvergleiche bilden den Kern zahlreicher Operationen, die sich auf Zeichenfolgen beziehen; dies gilt insbesondere für Sortierungen und Überprüfungen auf Gleichheit. Zeichenfolgen werden in einer bestimmten Reihenfolge sortiert: Wenn "my" in einer sortierten Zeichenfolgenliste vor "string" angezeigt wird, muss "my" bei einem Vergleich einen kleineren oder gleichen Wert wie "string" haben. Darüber hinaus wird beim Vergleich implizit Gleichheit definiert. Die Vergleichsoperation gibt 0 (null) für Zeichenfolgen zurück, die als gleich betrachtet werden. Dies kann so interpretiert werden, dass keine Zeichenfolge kleiner ist als die andere. Sinnvolle Operationen mit Zeichenfolgen schließen i. d. R. mindestens eines der folgenden Verfahren ein: Vergleich mit einer anderen Zeichenfolge und Ausführen eines genau definierten Sortiervorgangs.

Die Überprüfung der Sortierreihenfolge zweier Zeichenfolgen oder ihre Überprüfung auf Gleichheit ergibt jedoch nicht ein einzelnes richtiges Ergebnis. Das Ergebnis ist vielmehr abhängig von den Kriterien, die dem Zeichenfolgenvergleich zugrunde liegen. Insbesondere können Zeichenfolgenvergleiche zu unterschiedlichen Ergebnissen führen, die Ordinalvergleiche darstellen oder auf der Schreibweise und den Sortierungskonventionen der aktuellen oder der invarianten Kultur (eine auf der englischen Sprache basierende Kultur, die nicht von einem Gebietsschema abhängig ist) basieren.

Dd465121.collapse_all(de-de,VS.110).gifZeichenfolgenvergleiche mit der aktuellen Kultur

Ein Kriterium für Zeichenfolgenvergleiche stellt die Verwendung der Konventionen der aktuellen Kultur dar. Vergleiche, die auf der aktuellen Kultur basieren, verwenden die aktuelle Kultur oder das aktuelle Gebietsschema des Threads. Wenn die Kultur nicht vom Benutzer festgelegt wird, wird standardmäßig die Einstellung im Fenster Ländereinstellungen in der Systemsteuerung verwendet. Vergleiche, die auf der aktuellen Kultur basieren, sollten immer dann verwendet werden, wenn Daten linguistisch relevant sind und kulturabhängige Interaktionen von Benutzern widerspiegeln.

Das Verhalten im Hinblick auf Vergleiche und die Groß- und Kleinschreibung in .NET Framework ändert sich jedoch, wenn sich die Kultur ändert. Dies ist der Fall, wenn eine Anwendung auf einem Computer mit einer anderen Kultur ausgeführt wird, als der Computer, auf dem die Anwendung entwickelt wurde, oder wenn der ausführende Thread seine Kultur ändert. Dieses Verhalten ist beabsichtigt, für viele Entwickler jedoch nicht offensichtlich. Im folgenden Beispiel werden die Unterschiede zwischen den Sortierreihenfolgen in der englischen (amerikanisch, "en-US") und schwedischen ("sv-SE") Kultur herausgestellt. Beachten Sie, dass die Wörter "ångström", "Windows" und "Visual Studio" in den sortierten Zeichenfolgenarrays an unterschiedlichen Positionen angezeigt werden.


using System;
using System.Globalization;
using System.Threading;

public class Example
{
   public static void Main()
   {
      string[] values= { "able", "ångström", "apple", "Æble", 
                         "Windows", "Visual Studio" };
      Array.Sort(values);
      DisplayArray(values);

      // Change culture to Swedish (Sweden).
      string originalCulture = CultureInfo.CurrentCulture.Name;
      Thread.CurrentThread.CurrentCulture = new CultureInfo("sv-SE");
      Array.Sort(values);
      DisplayArray(values);

      // Restore the original culture.
      Thread.CurrentThread.CurrentCulture = new CultureInfo(originalCulture);
    }

    private static void DisplayArray(string[] values)
    {
      Console.WriteLine("Sorting using the {0} culture:",  
                        CultureInfo.CurrentCulture.Name);
      foreach (string value in values)
         Console.WriteLine("   {0}", value);

      Console.WriteLine();
    }
}
// The example displays the following output:
//       Sorting using the en-US culture:
//          able
//          Æble
//          ångström
//          apple
//          Visual Studio
//          Windows
//       
//       Sorting using the sv-SE culture:
//          able
//          Æble
//          apple
//          Windows
//          Visual Studio
//          ångström


Vergleiche mit der aktuellen Kultur, bei denen nicht zwischen Groß- und Kleinschreibung unterschieden wird, entsprechen kulturabhängigen Vergleichen, ignorieren jedoch die Schreibweise, die von der aktuellen Kultur des Threads vorgegeben wird. Dieses Verhalten zeigt sich möglicherweise auch bei Sortierreihenfolgen.

Vergleiche mit der Semantik der aktuellen Kultur werden standardmäßig für folgende Methoden verwendet:

In jedem Fall wird empfohlen, eine Überladung mit einem StringComparison-Parameter aufzurufen, um den Zweck des Methodenaufrufs eindeutig anzugeben.

Wenn nicht linguistische Zeichenfolgendaten linguistisch interpretiert werden, oder wenn Zeichenfolgendaten in einer bestimmten Kultur mit den Konventionen einer anderen Kultur interpretiert werden, können offensichtliche und nur schwer erkennbare Fehler auftreten. Kanonisches Beispiel ist das Problem mit dem Zeichen "I" im Türkischen.

In beinahe allen lateinischen Alphabetarten, einschließlich des englischen (USA) Alphabets, ist das Zeichen "i" (\u0069) die Kleinschreibungsvariante des Zeichens "I" (\u0049). Diese Regel zur Groß- und Kleinschreibung wird von Entwicklern, die in den entsprechenden Kulturen programmieren, leicht als Standard zugrunde gelegt. Das türkische Alphabet ("tr-TR") enthält jedoch ein "I" mit einem Punkt ("İ" bzw. \u0130), welches den Großbuchstaben des Zeichens "i" darstellt. Ferner verfügt Türkisch auch über ein kleines "i ohne Punkt ("ı" bzw. \u0131), dessen Entsprechung als Großbuchstabe das Zeichen "I" ist. Die Kultur Aserbaidschanisch (az-AZ) weist ein analoges Verhalten auf.

Annahmen über die Großschreibung von "i" oder die Kleinschreibung von "I" sind daher nicht für alle Kulturen gleichermaßen gültig. Wenn Sie die Standardüberladungen für Zeichenfolgenvergleichsroutinen verwenden, weisen diese je nach der zugrunde liegenden Kultur Unterschiede auf. Bei einem Vergleich nicht linguistischer Daten kann die Verwendung der Standardüberladungen zu unerwünschten Ergebnissen führen. Dies wird durch den folgenden Versuch veranschaulicht, einen Vergleich der Zeichenfolgen "file" und "FILE" ohne Beachtung der Groß- und Kleinschreibung durchzuführen.


using System;
using System.Globalization;
using System.Threading;

public class Example
{
   public static void Main()
   {
      string fileUrl = "file";
      Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
      Console.WriteLine("Culture = {0}",
                        Thread.CurrentThread.CurrentCulture.DisplayName);
      Console.WriteLine("(file == FILE) = {0}", 
                       fileUrl.StartsWith("FILE", true, null));
      Console.WriteLine();

      Thread.CurrentThread.CurrentCulture = new CultureInfo("tr-TR");
      Console.WriteLine("Culture = {0}",
                        Thread.CurrentThread.CurrentCulture.DisplayName);
      Console.WriteLine("(file == FILE) = {0}", 
                        fileUrl.StartsWith("FILE", true, null));
   }
}
// The example displays the following output:
//       Culture = English (United States)
//       (file == FILE) = True
//       
//       Culture = Turkish (Turkey)
//       (file == FILE) = False


Dieser Vergleich kann signifikante Probleme verursachen, wenn die Kultur versehentlich in sicherheitsrelevanten Einstellungen verwendet wird, wie im folgenden Beispiel veranschaulicht. Ein Methodenaufruf wie IsFileURI("file:") gibt true zurück, wenn die aktuelle Kultur "Englisch (USA)" ist und false, wenn die aktuelle Kultur "Türkisch" ist. In einem System mit der Kultur "Türkisch" wäre es daher vorstellbar, dass Sicherheitsvorkehrungen umgangen werden, die den Zugriff auf URIs blockieren, die mit "FILE:" beginnen und nicht zwischen Groß- und Kleinschreibung unterscheiden.


public static bool IsFileURI(String path) 
{
   return path.StartsWith("FILE:", true, null);
}


Stattdessen sollte der Code daher in diesem Fall wie im folgenden Beispiel geschrieben werden, da "file:" als nicht linguistischer und kulturunabhängiger Bezeichner interpretiert werden soll.


public static bool IsFileURI(string path) 
{
   return path.StartsWith("FILE:", StringComparison.OrdinalIgnoreCase);
}


Dd465121.collapse_all(de-de,VS.110).gifOrdinalzeichenfolgenoperationen

Der StringComparison.Ordinal-Wert oder der StringComparison.OrdinalIgnoreCase-Wert in einem Methodenaufruf kennzeichnen einen nicht linguistischen Vergleich, in dem die Funktionen von natürlichen Sprachen ignoriert werden. Bei Methoden, die mit diesen StringComparison-Werten aufgerufen werden, werden für Entscheidungen bezüglich Zeichenfolgenoperation einfache Bytevergleiche anstelle von Groß- und Kleinschreibung oder nach Kultur parametrisierten Entsprechungstabellen zugrunde gelegt. In aller Regel ist diese Vorgehensweise am besten für die beabsichtigte Interpretation von Zeichenfolgen geeignet und macht den Code sicherer und zuverlässiger.

Ordinalvergleiche sind Zeichenfolgenvergleiche, in denen die einzelnen Bytes einer Zeichenfolge ohne linguistische Interpretation verglichen werden, z. B. entspricht "windows" nicht "Windows". Dies stellt im Grunde einen Aufruf der C-Laufzeitfunktion strcmp dar. Verwenden Sie diesen Vergleich, wenn der Kontext eine exakte Entsprechung von Zeichenfolgen oder eine konservative Entsprechungsrichtlinie verlangt. Darüber hinaus werden Ordinalvergleiche am schnellsten durchgeführt, da beim Bestimmen eines Ergebnisses keine linguistischen Regeln verwendet werden.

Zeichenfolgen in .NET Framework können eingebettete NULL-Zeichen aufweisen. Einer der auffälligsten Unterschiede zwischen einem ordinalen und einem kulturabhängigen Vergleich (einschließlich Vergleichen, die die invariante Kultur verwenden) betrifft die Behandlung von eingebetteten NULL-Zeichen in einer Zeichenfolge. Wenn Sie die String.Compare-Methode und die String.Equals-Methode verwenden, um kulturabhängige Vergleiche (einschließlich Vergleichen, die die invariante Kultur verwenden) durchzuführen, werden diese Zeichen ignoriert. Bei kulturabhängigen Vergleichen können Zeichenfolgen mit eingebetteten NULL-Zeichen daher als gleichwertig mit Zeichenfolgen ohne diese Zeichen angesehen werden.

Wichtiger Hinweis Wichtig

Auch wenn eingebettete NULL-Zeichen von Zeichenfolgenvergleichsmethoden ignoriert werden, ist dies bei Zeichenfolgensuchmethoden wie String.Contains, String.EndsWith, String.IndexOf, String.LastIndexOf und String.StartsWith nicht der Fall.

Im folgenden Beispiel wird ein kulturabhängiger Vergleich der Zeichenfolge "Aa" mit einer ähnlichen Zeichenfolge durchgeführt, die mehrere eingebettete NULL-Zeichen zwischen "A" und "a" enthält, und es wird angezeigt, inwieweit die beiden Zeichenfolgen als gleich betrachtet werden.


using System;

public class Example
{
   public static void Main()
   {
      string str1 = "Aa";
      string str2 = "A" + new String('\u0000', 3) + "a";
      Console.WriteLine("Comparing '{0}' ({1}) and '{2}' ({3}):", 
                        str1, ShowBytes(str1), str2, ShowBytes(str2));
      Console.WriteLine("   With String.Compare:");
      Console.WriteLine("      Current Culture: {0}", 
                        String.Compare(str1, str2, StringComparison.CurrentCulture));
      Console.WriteLine("      Invariant Culture: {0}", 
                        String.Compare(str1, str2, StringComparison.InvariantCulture));

      Console.WriteLine("   With String.Equals:");
      Console.WriteLine("      Current Culture: {0}", 
                        String.Equals(str1, str2, StringComparison.CurrentCulture));
      Console.WriteLine("      Invariant Culture: {0}", 
                        String.Equals(str1, str2, StringComparison.InvariantCulture));
   }

   private static string ShowBytes(string str)
   {
      string hexString = String.Empty;
      for (int ctr = 0; ctr < str.Length; ctr++)
      {
         string result = String.Empty;
         result = Convert.ToInt32(str[ctr]).ToString("X4");
         result = " " + result.Substring(0,2) + " " + result.Substring(2, 2);
         hexString += result;
      }
      return hexString.Trim();
   }
}
// The example displays the following output:
//    Comparing 'Aa' (00 41 00 61) and 'A   a' (00 41 00 00 00 00 00 00 00 61):
//       With String.Compare:
//          Current Culture: 0
//          Invariant Culture: 0
//       With String.Equals:
//          Current Culture: True
//          Invariant Culture: True


Bei einem Ordinalvergleich werden die Zeichenfolgen jedoch nicht als gleich betrachtet, wie das folgende Beispiel zeigt.


Console.WriteLine("Comparing '{0}' ({1}) and '{2}' ({3}):", 
                  str1, ShowBytes(str1), str2, ShowBytes(str2));
Console.WriteLine("   With String.Compare:");
Console.WriteLine("      Ordinal: {0}", 
                  String.Compare(str1, str2, StringComparison.Ordinal));

Console.WriteLine("   With String.Equals:");
Console.WriteLine("      Ordinal: {0}", 
                  String.Equals(str1, str2, StringComparison.Ordinal));
// The example displays the following output:
//    Comparing 'Aa' (00 41 00 61) and 'A   a' (00 41 00 00 00 00 00 00 00 61):
//       With String.Compare:
//          Ordinal: 97
//       With String.Equals:
//          Ordinal: False


Ordinalvergleiche, bei denen die Groß- und Kleinschreibung nicht beachtet wird, folgen als nächster konservativer Ansatz. Diese Vergleichen ignorieren die Groß- und Kleinschreibung i. d. R.; "windows" entspricht dann beispielsweise "Windows". Im Hinblick auf ASCII-Zeichen entspricht diese Richtlinie StringComparison.Ordinal, mit der Ausnahme, dass die üblichen ASCII-Schreibungsregeln nicht beachtet wird. Ein beliebiges Zeichen in [A, Z] (\u0041-\u005A) entspricht daher dem zugehörigen Zeichen in [a,z] (\u0061-\007A). Die Groß- und Kleinschreibung außerhalb des ASCII-Bereichs verwendet die Tabellen der invarianten Kultur. Daher entspricht der folgende Vergleich


String.Compare(strA, strB, StringComparison.OrdinalIgnoreCase);


dem nachstehenden Vergleich (ist jedoch schneller):


String.Compare(strA.ToUpperInvariant(), strB.ToUpperInvariant(), 
               StringComparison.Ordinal);


Diese Vergleiche werden immer noch sehr schnell durchgeführt.

Hinweis Hinweis

Das Zeichenfolgenverhalten von Dateisystem, Registrierungsschlüsseln und -werten sowie Umgebungsvariablen wird am besten von StringComparison.OrdinalIgnoreCase dargestellt.

StringComparison.Ordinal und StringComparison.OrdinalIgnoreCase verwenden die Binärwerte direkt und eignen sich am besten für Vergleiche. Wenn Sie nicht sicher über die Vergleichseinstellungen sind, verwenden Sie einen dieser beiden Werte. Da hier jedoch ein Vergleich auf Byteebene durchgeführt wird, erfolgt die Sortierung nicht anhand einer linguistischen Sortierreihenfolge (analog zu einem englischen Wörterbuch), sondern anhand einer binären Rangfolge. Die Ergebnisse erscheinen Benutzern möglicherweise in den meisten Kontexten seltsam.

Ordinalemantik ist die Standardeinstellung für String.Equals-Überladungen, die kein StringComparison-Argument (einschließlich des Gleichheitsoperators) enthalten. In jedem Fall wird empfohlen, eine Überladung mit einem StringComparison-Parameter aufzurufen.

Dd465121.collapse_all(de-de,VS.110).gifZeichenfolgenoperationen mit der invarianten Kultur

Vergleiche mit der invarianten Kultur verwenden die CompareInfo-Eigenschaft, die von der statischen CultureInfo.InvariantCulture-Eigenschaft zurückgegeben wird. Dieses Verhalten ist in allen Systemen gleich: Zeichen außerhalb des Bereichs werden in Zeichen übersetzt, von denen angenommen wird, dass es sich um die invarianten Entsprechungen handelt. Diese Richtlinie kann für das kulturübergreifende Beibehalten eines Satzes von Zeichenfolgenverhalten hilfreich sein, führt jedoch oftmals zu unerwarteten Ergebnissen.

Vergleiche mit der invarianten Kultur, bei denen nicht zwischen Groß- und Kleinschreibung unterschieden wird, verwenden für Vergleichsinformationen ebenfalls die statische CompareInfo-Eigenschaft, die von der statischen CultureInfo.InvariantCulture-Eigenschaft zurückgegeben wird. Alle Unterschiede bezüglich der Groß- und Kleinschreibung in den übersetzten Zeichen werden ignoriert.

Vergleiche, die StringComparison.InvariantCulture verwenden, und StringComparison.Ordinal, werden analog für ASCII-Zeichenfolgen ausgeführt. StringComparison.InvariantCulture trifft jedoch linguistische Entscheidungen, die sich möglicherweise nicht für Zeichenfolgen eignen, die als Bytesatz interpretiert werden müssen. Das CultureInfo.InvariantCulture.CompareInfo-Objekt veranlasst die Compare-Methode, bestimmte Zeichensätze als äquivalent zu interpretieren. Die folgende Äquivalenz ist beispielsweise in der invarianten Kultur gültig:

InvariantCulture: a + ̊ = å

Der LATEINISCHE KLEINBUCHSTABE "a" (\u0061) wird, wenn er sich neben dem KOMBINIERENDEN ÜBERGESETZTEN RING "+ " ̊" (\u030a) befindet, als LATEINISCHER KLEINBUCHSTABE MIT ÜBERGESETZTEM RING interpretiert "å" (\u00e5). Wie das folgende Beispiel zeigt, unterscheidet sich dieses Verhalten vom Ordinalvergleich.


string separated = "\u0061\u030a";
string combined = "\u00e5";

Console.WriteLine("Equal sort weight of {0} and {1} using InvariantCulture: {2}",
                  separated, combined, 
                  String.Compare(separated, combined, 
                                 StringComparison.InvariantCulture) == 0);

Console.WriteLine("Equal sort weight of {0} and {1} using Ordinal: {2}",
                  separated, combined,
                  String.Compare(separated, combined, 
                                 StringComparison.Ordinal) == 0);
// The example displays the following output:
//    Equal sort weight of a° and å using InvariantCulture: True
//    Equal sort weight of a° and å using Ordinal: False      


Wenn sie Dateinamen, Cookies oder andere Elemente interpretieren, die eine Kombination wie "å" enthalten können, bieten Ordinalvergleiche immer noch das transparenteste und am besten geeignete Verhalten an.

Insgesamt verfügt die invariante Kultur nur über sehr wenige Eigenschaften, die für einen Vergleich hilfreich sind. Sie führt Vergleiche mit linguistischer Relevanz durch und kann daher keine vollständige symbolische Äquivalenz garantieren, eignet sich jedoch nicht unbedingt für die Anzeige in einer beliebigen Kultur. Einer der wenigen Gründe, StringComparison.InvariantCulture für Vergleiche zu verwenden, besteht darin, sortierte Daten für die kulturübergreifend einheitliche Anzeige beizubehalten. Wenn beispielsweise eine große Datendatei mit einer Liste sortierter Anzeigebezeichner einer Anwendung angehört, würde das Hinzufügen von Elementen zu dieser Liste einen Einfügevorgang mit invarianter Sortierung erfordern.

Zurück nach oben

In der folgenden Tabelle wird die Zuordnung von semantischem Zeichenfolgenkontext zu einem StringComparison-Enumerationsmember beschrieben.

Daten

Verhalten

System.StringComparison-Entsprechung

Wert

Interne Bezeichner, die die Groß- und Kleinschreibung beachten.

Bezeichner in Standards wie XML und HTTP, die die Groß- und Kleinschreibung beachten.

Sicherheitsbezogene Einstellungen, die die Groß- und Kleinschreibung beachten.

Ein nicht linguistischer Bezeichner mit exakt übereinstimmenden Bytes.

[ F:System.StringComparison.Ordinal ]

Interne Bezeichner, die die Groß- und Kleinschreibung nicht beachten.

Bezeichner in Standards wie XML und HTTP, die die Groß- und Kleinschreibung nicht beachten.

Dateipfade.

Registrierungsschlüssel und -werte.

Umgebungsvariablen.

Ressourcenbezeichner (z. B. Handlenamen).

Sicherheitsbezogene Einstellungen, die die Groß- und Kleinschreibung nicht beachten.

Ein nicht linguistischer Bezeichner, bei dem die Groß- und Kleinschreibung keine Rolle spielt; insbesondere für Daten, die in den meisten Systemdiensten von Windows gespeichert werden.

[ F:System.StringComparison.OrdinalIgnoreCase ]

Einige beibehaltene, linguistisch relevante Daten.

Anzeige von linguistischen Daten, die eine feste Sortierreihenfolge erfordern.

Kulturunabhängige Daten, die dennoch linguistisch relevant sind.

[ F:System.StringComparison.InvariantCulture ]

- oder -

[ F:System.StringComparison.InvariantCultureIgnoreCase ]

Daten, die dem Benutzer angezeigt werden.

Die meisten Benutzereingaben.

Daten, die lokale linguistische Regeln erfordern.

[ F:System.StringComparison.CurrentCulture ]

- oder -

[ F:System.StringComparison.CurrentCultureIgnoreCase ]

Zurück nach oben

In den folgenden Abschnitten werden die Methoden beschrieben, die am häufigsten für Zeichenfolgenvergleiche verwendet werden.

Dd465121.collapse_all(de-de,VS.110).gifString.Compare

Standardinterpretation: StringComparison.CurrentCulture.

Der Aufruf dieser Methode stellt die zentrale Operation für Zeichenfolgeninterpretation dar. Aus diesem Grund sollten alle Instanzen von Methodenaufrufen untersucht werden, um zu bestimmen, ob Zeichenfolgen anhand der aktuellen Kultur oder unabhängig von der Kultur (symbolisch) interpretiert werden sollen. Üblicherweise handelt es sich um eine symbolische Interpretation, und stattdessen sollte ein StringComparison.Ordinal-Vergleich verwendet werden.

Die System.Globalization.CompareInfo-Klasse, die von der CultureInfo.CompareInfo-Eigenschaft zurückgegeben wird, enthält auch eine Compare-Methode, die zahlreiche Vergleichsoptionen (ordinal, ohne Leerraumzeichen, ohne Zeichen vom Typ Kana usw.) über die CompareOptions-Flagenumeration zur Verfügung stellt.

Dd465121.collapse_all(de-de,VS.110).gifString.CompareTo

Standardinterpretation: StringComparison.CurrentCulture.

Diese Methode bietet derzeit keine Überladung an, die einen StringComparison-Typ angibt. Diese Methode kann normalerweise in das empfohlene String.Compare(String, String, StringComparison)-Format konvertiert werden.

Diese Methode wird von Typen implementiert, die die IComparable- und die IComparable<T>-Schnittstelle implementieren. Da der StringComparison-Parameter hier nicht verfügbar ist, ermöglichen implementierende Typen oftmals das Angeben eines StringComparer im entsprechenden Konstruktor. Im folgenden Beispiel wird eine FileName-Klasse definiert, deren Klassenkonstruktor einen StringComparer-Parameter enthält. Dieses StringComparer-Objekt wird dann in der FileName.CompareTo-Methode verwendet.


using System;

public class FileName : IComparable
{
   string fname;
   StringComparer comparer; 

   public FileName(string name, StringComparer comparer)
   {
      if (String.IsNullOrEmpty(name))
         throw new ArgumentNullException("name");

      this.fname = name;

      if (comparer != null)
         this.comparer = comparer;
      else
         this.comparer = StringComparer.OrdinalIgnoreCase;
   }

   public string Name
   {
      get { return fname; }
   }

   public int CompareTo(object obj)
   {
      if (obj == null) return 1;

      if (! (obj is FileName))
         return comparer.Compare(this.fname, obj.ToString());
      else
         return comparer.Compare(this.fname, ((FileName) obj).Name);
   }
}


Dd465121.collapse_all(de-de,VS.110).gifString.Equals

Standardinterpretation: StringComparison.Ordinal.

Mit der String-Klasse können Sie eine Überprüfung auf Gleichheit durchführen, indem Sie die Überladungen der statischen Equals-Methode oder der entsprechenden Instanzenmethode aufrufen, oder indem Sie den statischen Gleichheitsoperator verwenden. Die Überladungen und der Operator verwenden standardmäßig einen Ordinalvergleich . Unabhängig davon wird jedoch empfohlen, eine Überladung aufrufen, die den StringComparison-Typ explizit angibt; dies gilt auch, wenn Sie einen Ordinalvergleich ausführen möchten. Auf diese Weise können bestimmte Zeichenfolgeninterpretationen leichter in Code gefunden werden.

Dd465121.collapse_all(de-de,VS.110).gifString.ToUpper und String.ToLower

Standardinterpretation: StringComparison.CurrentCulture.

Diese Methoden sollten mit besonderer Sorgfalt verwendet werden, da das Erzwingen der Groß- oder Kleinschreibung einer Zeichenfolge oftmals unabhängig von der Schreibweise als kleine Normalisierung für Zeichenfolgenvergleiche verwendet wird. Wenn dies der Fall ist, sollten Sie einen Vergleich ohne Beachtung der Groß- und Kleinschreibung in Erwägung ziehen.

Die String.ToUpperInvariant-Methode und die String.ToLowerInvariant-Methode sind ebenfalls verfügbar. ToUpperInvariant wird standardmäßig zur Normalisierung der Schreibweise verwendet. Das Verhalten von Vergleichen mit StringComparison.OrdinalIgnoreCase setzt sich aus zwei Aufrufen zusammen: einem Aufruf von ToUpperInvariant für beide Zeichenfolgenargumente und einem Vergleich mithilfe von StringComparison.Ordinal.

Überladungen sind auch für die Konvertierung in Groß- und Kleinschreibung in einer bestimmten Kultur verfügbar. Dazu wird ein CultureInfo-Objekt übergeben, das die Kultur für die Methode darstellt.

Dd465121.collapse_all(de-de,VS.110).gifChar.ToUpper und Char.ToLower

Standardinterpretation: StringComparison.CurrentCulture.

Diese Methoden funktionieren ähnliche wie die String.ToUpper-Methode und die String.ToLower-Methode, die im vorherigen Abschnitt beschrieben werden.

Dd465121.collapse_all(de-de,VS.110).gifString.StartsWith und String.EndsWith

Standardinterpretation: StringComparison.CurrentCulture.

Standardmäßig führen beide Methoden einen kulturabhängigen Vergleich durch.

Dd465121.collapse_all(de-de,VS.110).gifString.IndexOf und String.LastIndexOf

Standardinterpretation: StringComparison.CurrentCulture.

Die Durchführung von Vergleichen durch die Standardüberladungen dieser Methoden ist nicht konsistent. Alle String.IndexOf- und String.LastIndexOf-Methoden mit einem Char-Parameter führen einen Ordinalvergleich durch. Die String.IndexOf- und die String.LastIndexOf-Standardmethode mit einem String-Parameter führen dagegen einen kulturabhängigen Vergleich durch.

Wenn Sie die String.IndexOf(String)-Methode oder die String.LastIndexOf(String)-Methode aufrufen und eine Zeichenfolge übergeben, die in der aktuellen Instanz gesucht werden soll, empfiehlt es sich, eine Überladung aufrufen, die den StringComparison-Typ explizit angibt. Mit den Überladungen, die ein Char-Argument enthalten, können Sie keinen StringComparison-Typ angeben.

Zurück nach oben

Einige Methoden, die keine Zeichenfolgenmethoden darstellen und deren zentrale Operation ein Zeichenfolgenvergleich ist, verwenden den StringComparer-Typ. Die StringComparer-Klasse enthält sechs statische Eigenschaften, die StringComparer-Instanzen zurückgeben, deren StringComparer.Compare-Methoden folgende Arten von Zeichenfolgenvergleichen durchführen:

Dd465121.collapse_all(de-de,VS.110).gifArray.Sort und Array.BinarySearch

Standardinterpretation: StringComparison.CurrentCulture.

Wenn Sie Daten in einer Auflistung speichern oder beibehaltene Daten aus einer Datei oder einer Datenbank in eine Auflistung lesen, können die Invarianten in der Auflistung durch einen Wechsel der aktuellen Kultur ungültig werden. Die Array.BinarySearch-Methode geht davon aus, dass die Elemente im zu durchsuchenden Array bereits sortiert wurden. Um die einzelnen Zeichenfolgenelemente im Array zu sortieren, ruft die Array.Sort-Methode die String.Compare-Methode auf. Kulturabhängige Vergleich bergen ein gewisses Risiko, falls sich die Kultur zwischen dem Zeitpunkt der Sortierung des Arrays und dem Durchsuchen des Inhalts ändert. Im folgenden Code wird das Speichern und Abrufen beispielsweise für den Comparer ausgeführt, der implizit von der Thread.CurrentThread.CurrentCulture-Eigenschaft bereitgestellt wird. Wenn sich die Kultur zwischen dem Aufruf von StoreNames und dem Aufruf von DoesNameExist möglicherweise ändert, kann bei der binären Suche ein Fehler auftreten; dies gilt insbesondere, wenn der Arrayinhalt zwischen den beiden Methodenaufrufen beibehalten wird.


// Incorrect.
string []storedNames;

public void StoreNames(string [] names)
{
   int index = 0;
   storedNames = new string[names.Length];

   foreach (string name in names)
   {
      this.storedNames[index++] = name;
   }

   Array.Sort(names); // Line A.
}

public bool DoesNameExist(string name)
{
   return (Array.BinarySearch(this.storedNames, name) >= 0);  // Line B.
}


Eine empfohlene Variante wird im folgenden Beispiel angezeigt, in dem die gleiche (kulturunabhängige) Ordinalvergleichsmethode verwendet wird, um das Array zu sortieren und zu durchsuchen. Der Änderungscode wird in den zwei Beispielen in den Zeilen mit der Bezeichnung Line A und Line B angezeigt.


// Correct.
string []storedNames;

public void StoreNames(string [] names)
{
   int index = 0;
   storedNames = new string[names.Length];

   foreach (string name in names)
   {
      this.storedNames[index++] = name;
   }

   Array.Sort(names, StringComparer.Ordinal);  // Line A.
}

public bool DoesNameExist(string name)
{
   return (Array.BinarySearch(this.storedNames, name, StringComparer.Ordinal) >= 0);  // Line B.
}


Wenn diese Daten beibehalten und zwischen Kulturen verschoben werden, und wenn eine Sortierung verwendet wird, um die Daten für den Benutzer anzuzeigen, können Sie StringComparison.InvariantCulture verwenden, da durch die linguistische Verarbeitung eine bessere Benutzerausgabe erzielt wird und Änderungen der Kultur keine Auswirkungen haben. Im folgenden Beispiel werden die zwei vorherigen Beispiele geändert, um die invariante Kultur zum Sortieren und Durchsuchen des Arrays zu verwenden.


// Correct.
string []storedNames;

public void StoreNames(string [] names)
{
   int index = 0;
   storedNames = new string[names.Length];

   foreach (string name in names)
   {
      this.storedNames[index++] = name;
   }

   Array.Sort(names, StringComparer.InvariantCulture);  // Line A.
}

public bool DoesNameExist(string name)
{
   return (Array.BinarySearch(this.storedNames, name, StringComparer.InvariantCulture) >= 0);  // Line B.
}


Dd465121.collapse_all(de-de,VS.110).gifBeispiel für Auflistungen: Hashtable-Konstruktor

Auch beim Hashen von Zeichenfolgen können sich, je nachdem, wie die Zeichenfolgen verglichen werden, Auswirkungen auf die Operation ergeben.

Im folgenden Beispiel wird ein Hashtable-Objekt instanziiert, indem das StringComparer-Objekt übergeben wird, das von der StringComparer.OrdinalIgnoreCase-Eigenschaft zurückgegeben wird. Da eine Klasse StringComparer, die von StringComparer abgeleitet wird, die IEqualityComparer-Schnittstelle implementiert, wird die GetHashCode-Methode verwendet, um den Hashcode von Zeichenfolgen in der Hashtabelle zu berechnen.


const int initialTableCapacity = 100;
Hashtable h;

public void PopulateFileTable(string directory)
{
   h = new Hashtable(initialTableCapacity, 
                     StringComparer.OrdinalIgnoreCase);

   foreach (string file in Directory.GetFiles(directory))
         h.Add(file, File.GetCreationTime(file));
}

public void PrintCreationTime(string targetFile)
{
   Object dt = h[targetFile];
   if (dt != null)
   {
      Console.WriteLine("File {0} was created at time {1}.",
         targetFile, 
         (DateTime) dt);
   }
   else
   {
      Console.WriteLine("File {0} does not exist.", targetFile);
   }
}


Zurück nach oben

Wenn Sie Benutzern Daten anzeigen, die keine Zeichenfolge sind, z. B. Zahlen sowie Datumsangaben und Zeitangaben, formatieren Sie diese den Kultureinstellungen des Benutzers entsprechend. Standardmäßig verwenden die String.Format-Methode und die ToString-Methoden der numerischen Typen und der Datums- und Uhrzeittypen die aktuelle Threadkultur für Formatierungsvorgänge. Um explizit anzugeben, dass die Formatierungsmethode die aktuelle Kultur verwenden soll, können Sie eine Überladung einer Formatierungsmethode mit einem provider-Parameter, z. B. String.Format(IFormatProvider, String, Object[]) oder DateTime.ToString(IFormatProvider), aufrufen und der Methode die CultureInfo.CurrentCulture-Eigenschaft übergeben.

Sie können Daten, die keine Zeichenfolge sind, entweder als Binärdaten oder als formatierte Daten beibehalten. Wenn Sie möchten, dass sie als formatierte Daten gespeichert werden, sollten Sie eine Überladung einer Formatierungsmethode aufrufen, die einen provider-Parameter einschließt, und dabei die CultureInfo.InvariantCulture-Eigenschaft übergeben. Die invariante Kultur stellt ein konsistentes Format für formatierte Daten bereit, das unabhängig von der Kultur und dem Computers ist. Im Gegensatz dazu bringt das Beibehalten von Daten, die mit anderen Kulturen als der invarianten Kultur formatiert werden, einige Einschränkungen mit sich:

  • Die Daten sind wahrscheinlich unbrauchbar, wenn sie auf einem System mit einer andere Kultur abgerufen werden oder wenn der Benutzer des aktuellen Systems die aktuelle Kultur ändert und versucht, die Daten abzurufen.

  • Die Eigenschaften einer Kultur auf einem bestimmten Computer können von den Standardwerten abweichen. Ein Benutzer kann kulturabhängige Anzeigeeinstellungen jederzeit anpassen. Aufgrund dessen können formatierte Daten, die in einem System gespeichert sind, möglicherweise nicht mehr gelesen werden, wenn der Benutzer die Kultureinstellungen anpasst. Die computerübergreifende Portabilität von formatierten Daten wird wahrscheinlich sogar noch eingeschränkter.

  • Internationale, regionale oder nationale Standards, die die Formatierung von Zahlen oder Datumsangaben und Uhrzeiten regeln, ändern sich mit der Zeit, und diese Änderungen werden in Windows-Betriebssystemupdates integriert. Wenn sich die Formatierungskonventionen ändern, können Daten, die anhand früherer Konventionen formatiert wurden, möglicherweise nicht mehr gelesen werden.

Das folgende Beispiel veranschaulicht die eingeschränkte Portabilität, die sich aus der Verwendung von kulturabhängiger Formatierung zum Beibehalten von Daten ergibt. In dem Beispiel wird ein Array von Daten- und Uhrzeitwerten in einer Datei gespeichert. Diese werden anhand der Konventionen der Kultur Englisch (USA) formatiert. Nachdem die aktuelle Threadkultur der Anwendung in Französisch (Schweiz) geändert wird, versucht die Anwendung, die gespeicherten Werte mithilfe der Formatierungskonventionen der aktuellen Kultur zu lesen. Der Versuch, zwei der Datenelemente zu lesen, löst eine FormatException-Ausnahme aus, und das Array von Datumsangaben enthält nun zwei falsche Elemente, die MinValue entsprechen.


using System;
using System.Globalization;
using System.IO;
using System.Text;
using System.Threading;

public class Example
{
   private static string filename = @".\dates.dat";

   public static void Main()
   {
      DateTime[] dates = { new DateTime(1758, 5, 6, 21, 26, 0), 
                           new DateTime(1818, 5, 5, 7, 19, 0), 
                           new DateTime(1870, 4, 22, 23, 54, 0),  
                           new DateTime(1890, 9, 8, 6, 47, 0), 
                           new DateTime(1905, 2, 18, 15, 12, 0) }; 
      // Write the data to a file using the current culture.
      WriteData(dates);
      // Change the current culture.
      Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("fr-CH");
      // Read the data using the current culture.
      DateTime[] newDates = ReadData();
      foreach (var newDate in newDates)
         Console.WriteLine(newDate.ToString("g"));
   }

   private static void WriteData(DateTime[] dates) 
   {
      StreamWriter sw = new StreamWriter(filename, false, Encoding.UTF8);    
      for (int ctr = 0; ctr < dates.Length; ctr++) {
         sw.Write("{0}", dates[ctr].ToString("g", CultureInfo.CurrentCulture));
         if (ctr < dates.Length - 1) sw.Write("|");   
      }      
      sw.Close();
   }

   private static DateTime[] ReadData() 
   {
      bool exceptionOccurred = false;

      // Read file contents as a single string, then split it.
      StreamReader sr = new StreamReader(filename, Encoding.UTF8);
      string output = sr.ReadToEnd();
      sr.Close();   

      string[] values = output.Split( new char[] { '|' } );
      DateTime[] newDates = new DateTime[values.Length]; 
      for (int ctr = 0; ctr < values.Length; ctr++) {
         try {
            newDates[ctr] = DateTime.Parse(values[ctr], CultureInfo.CurrentCulture);
         }
         catch (FormatException) {
            Console.WriteLine("Failed to parse {0}", values[ctr]);
            exceptionOccurred = true;
         }
      }      
      if (exceptionOccurred) Console.WriteLine();
      return newDates;
   }
}
// The example displays the following output:
//       Failed to parse 4/22/1870 11:54 PM
//       Failed to parse 2/18/1905 3:12 PM
//       
//       05.06.1758 21:26
//       05.05.1818 07:19
//       01.01.0001 00:00
//       09.08.1890 06:47
//       01.01.0001 00:00
//       01.01.0001 00:00


Wenn Sie jedoch die CultureInfo.CurrentCulture-Eigenschaft mit CultureInfo.InvariantCulture ersetzen in den Aufrufen von DateTime.ToString(String, IFormatProvider) und DateTime.Parse(String, IFormatProvider), werden die beibehaltenen Datums- und Uhrzeitdaten erfolgreich wiederhergestellt, wie die folgende Ausgabe zeigt.


06.05.1758 21:26
05.05.1818 07:19
22.04.1870 23:54
08.09.1890 06:47
18.02.1905 15:12

Anzeigen:
© 2015 Microsoft