Short answer:
Take a look at MySQL and different character-collations. Choose one and follow its rules. Or as @RHa and @cbeleites suggest find a library that provides locale-dependent sorting.
Long answer:
There are 3 different solutions for your problem (actually there are 4, but believe me, you don't want to realize the 4th ;) )
Rewrite every Umlaut to its base (German dictionary rules - DIN 5007-1 var. 1)
Every Umlaut and Diacritic results in the same char.
e.g.
áàâäã = a
ß = ss
and so on.
Sort them.
Rewrite every Umlaut by adding an e, diacritics are removed (German phone book rules - DIN 5007-1 var. 2)
ä = ae
áàâã = a
ü = ue
ß = ss
Sort them.
Umlaute are new chars added to the alphabet (Swedish/Finnish collation rules)
Every Umlaut and å are treated like new chars, which are added after the z of the alphabet. Other chars with diacretics are converted to their base.
So sort like
aáàâãbcd [...] xyzåäü
Umlaute are new chars added to the alphabet (Austrian phone book order - kudos to @rexkogitans from the comments)
It's as 3.1., but Umlaute and chars with Diacretics are appended to their base characters.
aäáà [...] bcdeèé [...] uü ...
But watch out, wiki says this is true for the Austrian White Pages, but the Austrian Yellow Pages are sorted like DIN 5007-1 var. 1.
In addition. According to EN 13710 the order of diacritics is
- Acute accent (á)
- Grave accent (à)
- Breve (ă)
- Circumflex (â)
- Hacek (háček) (š)
- Ring (å)
- Trema (ä)
- Double acute accent (ő)
- Tilde (ã)
- Dot (ż)
- Cedilla (ş)
- Ogonek (ą)
- Macron (ā)
- With stroke through (ø)
- Modified letter(s) (æ)
For further information take a look at
One very last comment:
There are a lot of countries and there are a lot of different languages and a lot of different characters. Some are frequently used in one country, but unknown in another.
Therefore there are a lot of different standards how to compare strings alphabetically. Even though there are international standards, you have to choose which one to follow.
How? Well, there's a saying: When in Rome, do as the Romans do.
Take a look at your target group and their expectations. Then choose the collation most of them will accept.
Spanish people? Well, ñ is an independent character sorted in
between n and o.
Germans? Take a look above.
Russians and western europeans? Oh boy, you are in trouble sorting
all these cyrillic and latin characters ;)
Or choose the one you are most comfortable with.
Also ... one of my professors once said: "The first thing I do before coding is searching the internet if there is already a solution." And as @RHa and @cbeleites said in the comments there are solutions (C, Java, PHP, etc.), so unless you insist ... use one of them and you only have to worry about choosing the right locale (and looking up which sorting rules they follow).
Last and least: The 4th sorting method
As I mentioned ealier there is a 4th (horrible) solution. German Wikipedia describes it as
Gleichordnung von Grundbuchstaben, Doppelbuchstaben und Umlaut, wenn Doppelbuchstabe wie Umlaut gesprochen wird. Mull wird wie Muell oder Müll sortiert. Duell dagegen zwischen Duden und Dugast.
To explain it in English I would like to quote @FabioTurati from the comments
It says that an approach is treating plain letters, double letters and Umlauts the same way, but only when the double letters are pronounced as an Umlaut. For example, "Mull", "Muell" and "Müll" are treated the same way (note that Mull and Müll are different words!), and the "ue" in Muell here is a way to avoid typing "ü". In other cases, the letters "ue" are pronounced separately: a "u" followed by an "e", for example in "Duell", which is why Duell is placed between Duden and Dugast.
Why is this a problem?
Consider it from the other point of view: if you find a word containing "ue", how do you treat it? For Muell you should pretend the "e" is not there, and treat it as "Mull". For "Duell", doing it would lead to "Dull", which would be sorted after "Dugast", which would be wrong. So, to know how to sort words you need to have some more info (that is, how they are pronounced), which a sorting algorithm normally doesn't have. That's why this approach is troublesome!
strxfrm()
to convert your user-visible strings into encoded strings that can be compared usingstrcmp()
. If you're sorting user records, say, and each has a "name" field, you'd have to then create a "nameSortable" field and usestrxfrm
to populate it. That resulting field may or may not look much like the ASCII you put in but is guaranteed to sort in the right order for the current locale. And since you do the transformation once, it should then sort quickly.strcoll()
to compare. This may be slower because in effect it's internally creating buffers, calling strxfrm to get comperable strings, comparing them, and throwing away the results of the conversion, only leaving the result.strxform()
requires you to manage the caches, but pays you back by allowing far faster compares.