Javas und QTs Sources bezüglich Zeichen und Strings decken genau das auf. Ich finde es beispielsweise bemerkenswert, daß QT bewußt auf wchar_t als Unicode-Basis verzichtet und stattdessen uint16_t nimmt, weil wchar_t wieder unter dieser "Mindestens so breit wie char"-Definition leidet, also 16 Bit niemals garantiert werden. Ein Blick in den Source lohnt sich und man merkt, wie kompliziert doch ein Unicode-Character sein kann.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Unicode ist krank.
Abgesehen davon, dass ein Code Point aus mehreren Code Units (bei UTF-8 bytes, bei UTF-16 shorts) besteht (z.b. deutsche Umlaute bestehen in UTF-8 aus, gibt es auch noch "Zeichen" (also was auf dem Bildschirm als ein Zeichen dargestellt wird), die aus mehreren Code Points bestehen.. angeblich nennen die das "Grapheme".

Beispiel: "blâb" in UTF-8 wird mit folgenden Bytes dargestellt (kann man sich im Hexeditor so angucken):
Quellcode:62 6C 61 CC 82 62
b  l  a  .  .  b
In der zweiten Zeile sind die zugehörigen Unicode-Zeichen (die . sind alleine keine gültigen Zeichen, der Rest ist aus dem ASCII-Subset von UTF-8).
Also wird der UTF-8 Code Point 0x61 (== 'a') durch den zusätzlichen Codepoint "0xCC 0x82" zu nem a mit nem komischen Dach. Ersetzt man 0x61 durch 0x75 ('u') isses nen u mit nem Dach.

Also: Ein Unicode Code Point besteht aus einem oder mehreren Code-Units (außer bei UTF-32, da ist ein 32bit Integer gleichzeitig Code Point und Code Unit), und ein dargestelltes Zeichen besteht aus einem oder mehreren Code Points.
IMHO ziemlich beschissen zu handlen und gerade zweiteres ist eher unbekannt.

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.