Natuurlijk sorteren: waarom item10 steeds voor item2 landt
Alfabetisch sorteren vergelijkt teken voor teken. item10 en item2 zijn vier tekens gelijk, en dan verliest 1 van 2, dus landt item10 eerst. Elke bestandslijst, versienummer en genummerd hoofdstuk loopt hier tegenaan.
Natuurlijk sorteren leest een rij cijfers als één getal, dus 10 wordt als getal tegen 2 gelegd. Windows Verkenner en de Finder van macOS doen dit, en daarom ziet een mapoverzicht er goed uit en een gesorteerd tekstbestand niet. Gebruik het voor bestandsnamen, versienummers als v1.9.0 en v1.10.0, en factuurnummers.
Waarom een kale vergelijking je lijst verkeerd sorteert
De array.sort() van JavaScript zonder comparator vergelijkt UTF-16 code-eenheden, geen letters. Elke hoofdletter sorteert voor elke kleine letter, dus Zebra wint van appel, en elke letter met een accent sorteert na z, dus ä landt voorbij zulu. Allebei zijn ze in elke menselijke taal fout.
Deze tool gebruikt Intl.Collator, dat het Unicode Collation Algorithm tegen de CLDR-data per taal uitvoert, want er is geen enkel juist antwoord. Duits sorteert ö bij o; Zweeds zet hem achteraan het alfabet; Tsjechisch behandelt ch als één letter tussen h en i; Turks heeft een i met en een i zonder punt, i. Hoofdletters zijn alleen een tiebreak en nooit een terugval op de volgorde van code-eenheden: appel blijft hoe dan ook voor Zebra.
Numeriek sorteren en schudden
Numeriek leest het getal aan het begin van elke regel, teken, decimaalpunt en exponentnotatie inbegrepen; wat erachter staat rijdt mee. Een decimale komma wordt niet als decimaalpunt gelezen, want 1,5 is anderhalf in het Nederlands en vijftienhonderd in het Engels. Regels zonder getal vooraan verzamelen zich achteraan in de volgorde waarin je ze schreef, in beide richtingen, en dat is wat een totaalregel wil.
Schudden gebruikt Fisher-Yates, dus elke volgorde is even waarschijnlijk. De oneliner waar mensen naar grijpen, sort(() => Math.random() - 0.5), geeft de sortering een inconsistente comparator en laat het resultaat scheef staan richting de oorspronkelijke volgorde. Trek je een winnaar of deel je een startvolgorde uit, dan is die scheefheid het probleem.
Veelvoorkomende problemen
- Een regel staat één plek verkeerd. Kijk naar een spatie vooraan: een teken dat voor elke letter sorteert en onzichtbaar is. Regels worden hier niet getrimd, want een tool die zegt te herordenen hoort niet ook te bewerken.
- De sortering lijkt fout voor jouw taal. De taalkeuze staat standaard op de taal van deze pagina, niet op de taal van je lijst.
Veelgestelde vragen
Verwijdert sorteren dubbele regels?
Nee. Wat er aan regels in gaat komt eruit. Dubbele regels verwijderen is een aparte tool, hieronder gelinkt.
Kan het een genummerde lijst of opsomming sorteren?
Een bestaand voorvoegsel 1. of - doet mee in de vergelijking en houdt de oude volgorde vast. Haal de nummers weg met de tool voor regelnummering, sorteer, en nummer daarna opnieuw.
Blijven de regeleindes behouden?
Ze doen nooit mee in de vergelijking, en een bestand dat helemaal LF of helemaal CRLF is komt zo terug. Een bestand dat de twee door elkaar gebruikt komt volledig als CRLF terug, want een regel die verplaatst is hoort niet meer bij het regeleinde waarmee hij aankwam. Modus, richting, hoofdlettergevoeligheid en taal gaan de URL in; de tekst niet.
Waarom sorteert mijn lijst hier anders dan in een spreadsheet?
Vrijwel altijd de locale. Een kale sortering op codepunten zet elke hoofdletter voor elke kleine letter en zet letters met accenten na de z, terwijl een vergelijking die de locale kent ze zet waar een lezer van die taal ze verwacht. Deze pagina gebruikt Intl.Collator, en daarom staat a naast a met een accent.