Natürliche Sortierung (Natural Sorting) für C#

Ich hab mich jetzt doch dazu entschieden, das selbst zu implementieren, nachdem ich genug darüber gelesen hab, wie es funktioniert. Dabei hab ich mich vom ersten Artikel aus meiner obigen Liste, dem CodeProject-Ansatz, inspirieren lassen, ohne ihn direkt als Vorlage zu nehmen.

Meine Funktion unterstützt jetzt
* Zeichenkettenvergleiche
* ohne Berücksichtigung der Groß-/Kleinschreibung
* ignoriert dabei ' und " (Liste leicht erweiterbar, auch um ganze Unicode-Kategorien)
* verwendet eine korrekte Sortierung für regionale Sonderzeichen (deutsch: Umlaute)
* sortiert Zahlen an jeder Position nach ihrem Wert
* wobei mehr führende Nullen bei gleichem Wert zuerst kommen
* negative Zahlen werden korrekt einsortiert, aber nur am Anfang der Zeichenkette (Aufwand einer Erweiterung unbekannt, ich hab es von Anfang an konzeptionell auf den Anfang begrenzt)
* bei gleichen Ergebnissen werden unterwegs gesammelte Präferenzen (Großschreibung vor Kleinschreibung, oben erwähnte ignorierte Sonderzeichen, Anzahl führender Nullen usw.) als Entscheidungsgrundlage verwendet, sodass das Ergebnis deterministisch ist

Bevor ich das Ganze auf .NET-Snippets veröffentliche, werd ich es noch ein wenig testen. Bislang hat der Entwurf und die Implementierung ca. eine Stunde gedauert, Unterstützung für negative Zahlen und Ignorieren von Sonderzeichen nochmal eine Stunde. Benchmarks gibt's noch keine, ich weiß also nicht, wie schnell mein Code ist. Mit 30 Zeilen in Verwendung als SQLite-Sortierfunktion merk ich zumindest keine Verzögerung. 🙂 Ohne die zahlreichen Kommentare sind es ca. 90 Code-Zeilen in einer einzigen Funktion. Am Wochenende bin ich aber erstmal offline. 😉 Mehr gibt's dann also nächste Woche.

Nachdem sich das mit .NET-Snippets ja mittlerweile erledigt hat, liegt der Code wie gewohnt zuerst auf meiner Seite:

http://beta.unclassified.de/code/dotnet/naturalsort/

Dort gibt's auch eine ausführlichere Beschreibung, worum es geht, was mein Code kann, was nicht und wie schnell er ist. Kurz gefasst braucht er im Vergleich zum einfachen Zeichenkettenvergleich etwa 6,7-mal so lange, was der CodeProject-Version sehr ähnlich ist (die hab ich gleich mit gemessen).

Ich bitte um Feedback und ggf. Fehlerberichte, sollte jemand diese Funktion verwenden.

Hallo LonelyPixel,

damit dein Code nicht untergeht, habe ich ich mal die entscheidenden zwei Beiträge hier nach .NET-Komponentensammlung abgeteilt und den aktuellen Stand des Codes als Datei angehängt. Ich denke, das ist in deinem Sinne.

herbivore

Geht in Ordnung.

Ich habe mittlerweile noch eine kleine Optimierung am Code vorgenommen. Anstatt zu Beginn nur zu prüfen, ob beide Strings gleich null sind, prüfe ich einfach, ob sie gleich sind (also s1 == s2). Der null-Fall ist dabei mitinbegriffen, und exakt gleiche Zeichenketten können so sehr viel schneller als gleich behandelt werden. In meinem Dateinamen-Benchmark hat das eine deutliche Beschleunigung gebracht (150 ms statt 200 ms), da ein Dateiname öfter vorkam; in anderen Szenarien können die Ergebnisse unterschiedlich sein, da es eigentlich geringfügig länger dauern sollte, wenn keine identischen Zeichenketten vorkommen.

Da ich momentan nicht dazu komme, weitere Tests durchzuführen, erwähne ich hier schonmal die mögliche Änderung, vielleicht nutzt sie derweil ja jemandem.