Warum string.Compare scheinen akzentuierte Zeichen inkonsequent zu behandeln?

Question

Wenn ich die folgende Anweisung ausführen:

string.Compare("mun", "mün", true, CultureInfo.InvariantCulture)

Das Ergebnis ist '-1', was darauf hinweist, dass 'mun' hat einen niedrigeren numerischen Wert als 'Mün'.

Allerdings, wenn ich diese Anweisung ausführen:

string.Compare("Muntelier, Schweiz", "München, Deutschland", true, CultureInfo.InvariantCulture)

ich '1', was darauf hinweist, dass 'Muntelier, Schewiz' last gehen sollte.

Ist das ein Bug im Vergleich? Oder, was wahrscheinlicher ist, ist es eine Regel sollte ich in Betracht nehmen, wenn Strings Sortierung enthält akzentuierte

---

Der Grund ist dies ein Problem ist, ich bin eine Liste sortieren und dann einen manuellen Binärfilter tun, die jeden String zu erhalten, beginnend mit ‚xxx‘ gemeint sind.

Früher war ich mit der Linq ‚Wo‘ Methode, aber jetzt muß ich diese benutzerdefinierte Funktion von einer anderen Person geschrieben verwenden, weil er sagt, dass es besser abschneidet.

Aber die benutzerdefinierte Funktion scheint nicht zu berücksichtigen, was auch immer ‚Unicode‘ Regeln .NET hat. Also, wenn ich ihm Filter von ‚Mün‘ sagen, es hat keine Artikel finden, obwohl es Elemente in der Liste, beginnend mit ‚mun‘.

Dies scheint aufgrund der inkonsistenten Bestellung von akzentuierten Zeichen zu sein, je nachdem, welchen Zeichen nach dem akzentuierte Zeichen gehen.

---

OK, ich glaube, ich habe das Problem behoben haben.

Vor dem Filter, kann ich eine Art basierend auf dem ersten n Buchstaben jeden Zeichenfolge, wobei n ist die Länge des Suchbegriffs.

Answer 1

Es ist ein Tie-Bruch-Algorithmus bei der Arbeit finden Sie unter http://unicode.org/reports/tr10/

  

Um die Komplexität des   sprachsensitiven Sortierung, eine   Multi-Level-Vergleichsalgorithmus ist   beschäftigt. Im Vergleich von zwei Worten, für   Beispiel ist das wichtigste Merkmal ist   das Basiszeichen: wie die   Differenz zwischen einer A- und einer B   typischerweise Accent Unterschiede   ignoriert, wenn es irgendwelche Unterschiede   in den Basisbuchstaben. Groß- und Kleinschreibung   (Groß- Vergleich Kleinbuchstaben) sind   Regel ignoriert, falls vorhanden   Unterschiede in der Basis oder Akzenten.   Interpunktion ist variabel. In einigen   Situationen ein Satzzeichen ist   wie ein Basiszeichen behandelt. Im   andere Situationen sollte es ignoriert   wenn es irgendeine Base, Akzent oder Fall   Unterschiede. Es kann auch sein, ein   Finale, tie-breaking Ebene, wobei, wenn   gibt es keine weiteren Unterschiede bei allen   in der Zeichenfolge, der Code (normalisiert)   Punkt um verwendet wird.

Also "Munt ..." und "Münc ..." sind alphabetisch anders und sortieren basierend auf dem "t" und "c".

Während "mun" und "Mün" sind alphabetisch gleich sind ( "u" equivelent zu "ü" in verlorenen Sprachen), so dass die Zeichencodes verglichen werden

Answer 2

Es sieht aus wie das akzentuierte Zeichen nur in einer Art „Tie-Break“ Situation benutzt wird -. In anderen Worten, wenn die Saiten sonst gleich sind

Hier ist ein Beispielcode zu demonstrieren:

using System;
using System.Globalization;

class Test
{
    static void Main()
    {
        Compare("mun", "mün");
        Compare("muna", "münb");
        Compare("munb", "müna");
    }

    static void Compare(string x, string y)
    {
        int result = string.Compare(x, y, true, 
                                   CultureInfo.InvariantCulture));

        Console.WriteLine("{0}; {1}; {2}", x, y, result);
    }
}

(Ich habe versucht, einen Raum nach dem „n“ als auch dem Hinzufügen, um zu sehen, ob es auf Wortgrenzen getan wurde -. Es ist nicht)

Ergebnisse:

mun; mün; -1
muna; münb; -1
munb; müna; 1

Ich vermute, dies durch verschiedene komplizierte Unicode-Regeln korrekt ist - aber ich weiß nicht über sie genug

.

Als ob Sie müssen dies berücksichtigen, ... würde ich nicht so erwartet. Was tun Sie, dass durch diese ausgelöst wird?

Answer 3

Wie ich das verstehe, ist es immer noch ein wenig konsistent. Bei der Verwendung von CultureInfo.InvariantCulture des Umlaut Vergleich ü ist wie die nicht-akzentuierte Zeichen u behandelt.

Wie die Saiten in Ihrem ersten Beispiel gleich sind offensichtlich nicht das Ergebnis nicht 0 sein wird, aber -1 (was ein Standardwert zu sein scheint). Im zweiten Beispiel Muntelier geht zuletzt, weil t folgt c im Alphabet.

Ich konnte keine klare Dokumentation in MSDN finden diese Regeln zu erklären, aber ich fand, dass

string.Compare("mun", "mün", CultureInfo.InvariantCulture,  
    CompareOptions.StringSort);

und

string.Compare("Muntelier, Schweiz", "München, Deutschland", 
    CultureInfo.InvariantCulture, CompareOptions.StringSort);

gibt das gewünschte Ergebnis.

Wie auch immer, ich glaube, Sie wäre besser Sie Ihre Sortierung auf einer bestimmten Kultur wie des aktuellen Benutzers Kultur zu stützen (wenn möglich).