Why Your Sorted List Is in the Wrong Order

Almost every surprising sort result comes from the same gap. A computer sorts by comparing the numeric codes behind characters. A person sorts by a set of cultural rules they were taught and have never had to state out loud. The two agree often enough that the disagreements look like bugs.

Uppercase before lowercase

In the character table every language inherited, uppercase A is 65 and lowercase a is 97. All twenty-six capitals come before any lowercase letter. A naive sort therefore produces Zebra before apple, which looks broken and is arithmetically correct.

by character code        what a person expects
  Apple                    Apple
  Zebra                    apple
  apple                    Banana
  banana                   banana
                           Zebra

The fix is a case-insensitive comparison, which is what almost everyone actually wants from a visible list. Note that it makes the sort unstable between items differing only in case, so a tie-break is worth defining if the order has to be reproducible.

item10 before item2

Text comparison works character by character, left to right, and stops at the first difference. Comparing item10 with item2 reaches the digit 1 against the digit 2, finds 1 is smaller, and puts item10 first. It never gets far enough to notice these are numbers at all.

What people expect here is called natural sort: a comparison that recognises runs of digits and compares them numerically. It is not the default anywhere, because it is ambiguous the moment a string contains something that looks like a number but is not — a version, a date, a product code with leading zeros.

If you control how the values are generated, zero-padding sidesteps the whole problem: item002 and item010 sort correctly under plain text comparison, permanently and in every system that will ever touch them.

Digits, symbols and where they land

Digits sit below letters in the character table, so anything starting with a number sorts before everything alphabetic. Most punctuation sits below the digits, which is why a line beginning with a hyphen or a quotation mark ends up at the very top. Again, correct by the rules, and rarely what anyone wanted.

Accents, and why they go to the end

Accented characters live far above the plain Latin alphabet in the character table, so é sorts after z rather than beside e. Every language with accents has a rule for this, and the rules differ: in Spanish ñ is a separate letter following n, in Swedish å ä ö come after z, and in French accents are compared only when the base letters are otherwise identical.

There is no universal alphabetical order. There is only the order of a particular language, which is why the comparison has to be told which one.

This is what locale-aware collation is for. Every modern platform ships a comparator that takes a language and applies its actual rules — including case handling and, optionally, numeric ordering. It is slower than comparing codes, which matters for sorting a million rows and not at all for sorting a list a person will read.

The invisible causes

• Leading or trailing whitespace, which sorts below every printable character and pushes a line to the top.
• A non-breaking space pasted from a document, which looks identical to a space and has a different code entirely.
• Windows line endings leaving a stray carriage return at the end of every line.
• Two visually identical strings using different Unicode normalisations — one accented character versus a letter plus a combining mark.

When one line refuses to sort where it obviously belongs, the cause is nearly always one of these rather than the comparison. Trimming the input first removes most of them, and normalising the text removes the rest.