Eine aktualisierte Antwort (Oktober 2014)
Ich war wirklich verärgert über diese natürliche Sortierreihenfolge der Zeichenketten und habe mir viel Zeit genommen, um dieses Problem zu untersuchen. Ich hoffe, das hilft.
Lange Rede kurzer Sinn
localeCompare()
Charakterunterstützung ist knallhart, benutze sie einfach. Wie bereits erwähnt von Shog9
lautet die Antwort auf Ihre Frage:
return item1.attr.localeCompare(item2.attr);
Fehler in allen benutzerdefinierten Javascript-Implementierungen der "natürlichen String-Sortierreihenfolge" gefunden
Es gibt eine ganze Reihe von benutzerdefinierten Implementierungen, die versuchen, String-Vergleiche durchzuführen, genauer gesagt "natürliche String-Sortierreihenfolge".
Beim "Spielen" mit diesen Implementierungen fielen mir immer wieder seltsame "natürliche Sortierreihenfolgen" auf, oder vielmehr Fehler (oder Auslassungen in den besten Fällen).
In der Regel werden Sonderzeichen (Leerzeichen, Bindestriche, kaufmännische Zeichen, Klammern usw.) nicht korrekt verarbeitet.
Sie erscheinen dann an verschiedenen Stellen durcheinander, was typischerweise der Fall ist:
- einige werden zwischen dem großen 'Z' und dem kleinen 'a' stehen
- einige werden zwischen der '9' und dem Großbuchstaben 'A' stehen
- einige werden nach dem Kleinbuchstaben 'z' stehen
Wenn man erwartet hätte, dass Sonderzeichen alle an einer Stelle "gruppiert" sind, außer vielleicht dem Sonderzeichen Leerzeichen (das immer das erste Zeichen ist). Das heißt, entweder alle vor den Zahlen, oder alle zwischen Zahlen und Buchstaben (Klein- und Großbuchstaben nacheinander "zusammen"), oder alle nach den Buchstaben.
Meine Schlussfolgerung ist, dass sie alle keine konsistente Reihenfolge liefern, wenn ich anfange, kaum ungewöhnliche Zeichen hinzuzufügen (d. h. Zeichen mit diakritischen Zeichen oder Zeichen wie Bindestrich, Ausrufezeichen usw.).
Forschung zu den benutzerdefinierten Implementierungen:
Browser-eigene Implementierungen der "natürlichen Stringsortierung" über localeCompare()
localeCompare()
älteste Implementierung (ohne die Argumente locales und options) wird von IE6+ unterstützt, siehe http://msdn.microsoft.com/en-us/library/ie/s4esdbwz(v=vs.94).aspx (scrollen Sie nach unten zur Methode localeCompare()). Die eingebaute localeCompare()
Methode sortiert viel besser, auch bei internationalen und Sonderzeichen. Das einzige Problem bei der Verwendung der localeCompare()
Methode ist, dass "das verwendete Gebietsschema und die Sortierreihenfolge sind vollständig von der Implementierung abhängig". Mit anderen Worten, bei Verwendung von localeCompare wie stringOne.localeCompare(stringTwo): Firefox, Safari, Chrome und IE haben eine andere Sortierreihenfolge für Strings.
Forschung zu den browserbasierten Implementierungen:
Schwierigkeit der "natürlichen Sortierreihenfolge"
Die Implementierung eines soliden Algorithmus (d.h. konsistent, aber auch eine breite Palette von Zeichen abdeckend) ist eine sehr schwierige Aufgabe. UTF8 enthält mehr als 2000 Zeichen & umfasst mehr als 120 Skripte (Sprachen) . Schließlich gibt es eine Spezifikation für diese Aufgaben, den sogenannten "Unicode Collation Algorithm", der unter folgender Adresse zu finden ist http://www.unicode.org/reports/tr10/ . Weitere Informationen hierzu finden Sie in dieser von mir gestellten Frage https://softwareengineering.stackexchange.com/questions/257286/is-there-any-language-agnostic-specification-for-string-natural-sorting-order
Endgültige Schlussfolgerung
Also in Anbetracht der aktuellen Ebene der Unterstützung durch die Javascript benutzerdefinierte Implementierungen, die ich kam über, werden wir wahrscheinlich nie sehen, etwas immer in der Nähe der Unterstützung all dieser Zeichen und Skripte (Sprachen). Daher würde ich lieber die Browser 'native localeCompare() Methode verwenden. Ja, es hat den Nachteil des Seins nicht konsistent zwischen den Browsern, aber grundlegende Tests zeigt es deckt eine viel breitere Palette von Zeichen, so dass solide und sinnvolle Sortierreihenfolgen.
Wie also von Shog9
lautet die Antwort auf Ihre Frage:
return item1.attr.localeCompare(item2.attr);
Lesen Sie weiter:
Dank der netten Antwort von Shog9, die mich in die "richtige" Richtung gebracht hat, glaube ich