Ligatury

Oto garść informacji o ligaturach.
http://pl.wikipedia.org/wiki/Ligatura_(pismo)

A poniżej (w języku ang.) krótkie streszczenie problemu który napotkałem w mojej pracy w związku z porównywaniem ciągów znakowych zawierających sekwencje znaków z których dana ligatura się składa. Problem polega na tym że klient chce aby litery składowe ligatury były traktowane jako ligatura, co nie jest jednoznaczne, ponieważ takie sekwencje znaków mogą równie dobrze nie tworzyć ligatury, tylko występować swobodnie.

Question: wcscoll does not see that "ß" is equal to "ss" as customer whants


[usr@serv ~]$ export LC_ALL="de_DE.UTF-8"
[usr@serv ~]$ echo "ä" | iconv -f ISO88592 -t ASCII//TRANSLIT
ae
[usr@serv ~]$ echo "ß" | iconv -f ISO88592 -t ASCII//TRANSLIT
ss


wcscoll will not tell that “ß” and “ss” are the same, because that are two different string (coded in UCS). The point is that you don’t know if "ss" means "ss" or "ß" in that place.

The matter of ä = ae ; ss = ß is that in ASCII you cannot code the ß without using special code page. And without special chatters you cannot code all ligatures that occur in specific language. So you use the “replacement” for those chars. Going from ligature into replacement is easy, but the reverse path is not!. It is the same if the “&” sign will be not in ASCII table and you will code it as “et” (that is really the source of & character anyway, combining ‘e’ and ‘t’ – creates a ligature). But no one wants to threat “et” to be equal & because that’s not make sense, they are two different strings.

Kilka przykladowych ligatur:
et & U+0026
At @ U+0040
ſs (lub ſz) ß U+00DF
AE, ae Æ, æ U+00E6, U+00C6
OE Œ, œ, ɶ U+0152, U+0153, U+276
IJ, ij IJ U+0132, U+0133
Ng, ng Ŋ, ŋ U+014A, U+14B
Hv (Hw), hv (hw) Ƕ, ƕ U+01F6, U+0195
DŽ, Dž, dž DŽ, Dž, dž U+01C4, U+01C5, U+01C6 (*)
LJ, Lj, lj LJ, Lj, lj U+01C7, U+01C8, U+01C9 (*)
NJ, Nj, nj NJ, Nj, nj U+01CA, U+01CB, U+01CC (*)
DZ, Dz, dz DZ, Dz, dz, ʣ U+01F1, U+01F2, U+01F3, U+02A3 (*)
lʒ ɮ U+026E
dʒ ʤ U+02A4
dʑ ʥ U+02A5
ts ʦ U+02A6