Wie werden Wörter in Textfeldern gespeichert?

[.nils]

Hallo,

Ich habe einmal ein Html-Dokument mit der Meta-Angabe
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
und einmal eines mit der Angabe
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
Beide enthalten ein Textfeld.

Ich gebe nun beispielsweise den Buchstaben "ü" in das Textfeld ein. Hängt das nun von der im meta-tag angegebenen Zeichenkodierung ab, wie der Buchstabe binär im Textfeld gespeichert wird? Wenn nein, liege ich da richtig, das der Buchstabe immer in der Unicode-Codierung (in diesem Fall 0000 0000 1111 1100)gespeichert wird??

Gruß, Nils

[Christoph Schnauß]

hallo .nils,

Ich gebe nun beispielsweise den Buchstaben "ü" in das Textfeld ein. Hängt das nun von der im meta-tag angegebenen Zeichenkodierung ab, wie der Buchstabe binär im Textfeld gespeichert wird?

Nein. Vermutlich hast du da noch ein paar theoretische Mißverständnisse. Dein Textfeld speichert zum Beispiel überhaupt nichts. Und was in <meta>-Tags steht, interessiert allenfalls deinen Browser, sobald die Seite bei dir angekommen ist. _Vorher_ allerdings können ein paar dieser Angaben auch noch den Webserver interessieren und gegebenenfalls ein paar Dienste im Internet. Siehe SELFHTML.

Wenn nein, liege ich da richtig, das der Buchstabe immer in der Unicode-Codierung (in diesem Fall 0000 0000 1111 1100)gespeichert wird?

Wenns geht, versuche bitte, deine Frage etwas zu präzisieren. Erkläre bitte, was du mit "Textfeld" meinst, und wann wie wo eine entsprechende Eingabe deiner Ansicht nach "gespeichert" werden soll. Wenn es dir um die Frage geht, wie Eingaben in ein <input>-Feld übermittelt werden, so kannst du einiges dazu in SELFHTML nachlesen.

Grüße aus Berlin

Christoph S.

[.nils]

Hallo Christoph,

Ich gebe nun beispielsweise den Buchstaben "ü" in das Textfeld ein. Hängt das nun von der im meta-tag angegebenen Zeichenkodierung ab, wie der Buchstabe binär im Textfeld gespeichert wird?

Nein. Vermutlich hast du da noch ein paar theoretische Mißverständnisse.

Das kann gut sein. Irgendwie will das nicht in mein Hirn rein mit der Zeichenkodierung...

Wenn nein, liege ich da richtig, das der Buchstabe immer in der Unicode-Codierung (in diesem Fall 0000 0000 1111 1100)gespeichert wird?

Das scheint wohl doch nicht der Fall zu sein.

Wenns geht, versuche bitte, deine Frage etwas zu präzisieren. Erkläre bitte, was du mit "Textfeld" meinst, und wann wie wo eine entsprechende Eingabe deiner Ansicht nach "gespeichert" werden soll.

Es geht mir zuerst um Abfragen per javascript, und wie ich hier keine Probleme mit der Kodierung bekomme. siehe mein Beispiel

Wenn es dir um die Frage geht, wie Eingaben in ein <input>-Feld übermittelt werden, so kannst du einiges dazu in SELFHTML nachlesen.

Ah, danke, etwas in der Art habe ich gesucht. Bleibt die Frage, wie Zeichen jenseits von Ascii-Zeichen Nummer 256 umschrieben werden?

Ich lese gerade den Artikel von Tobias Kieslich. Könnte das eine Antwort sein?

Gruß, Nils

[Christoph Schnauß]

hallo .nils,

Ich lese gerade den Artikel von Tobias Kieslich. Könnte das eine Antwort sein?

Öhm ... ich werde mich hüten, hier öffentlich irgendeine Bewertung von Artikeln, die im SELF-Raum veröffentlicht wurden, abzugeben. Es sei denn, es handelte sich um sehr alte und nicht mehr ganz zeitgemäße Artikel.

Allerdings würde ich dir empfehlen, hier überhaupt nicht auf Javascript zu setzen, sondern dich darum zu kümmern, was der Server zu erledigen hat.

Grüße aus Berlin

Christoph S.

[wahsaga]

hi,

Ich gebe nun beispielsweise den Buchstaben "ü" in das Textfeld ein. Hängt das nun von der im meta-tag angegebenen Zeichenkodierung ab, wie der Buchstabe binär im Textfeld gespeichert wird?

Was meinst du mit "gespeichert"?
Der Browser merkt sich diesen Wert irgendwo im RAM, mehr nicht. elche Kodierung er dabei wählt, ist für dich vollkommen uninteressant (auch wenn es vermutungsweise die des Dokuments sein dürfte).

Was dich ggf. interessieren könnte wäre, wie der Wert beim Abschicken des Formulars an den Server übertragen wird.
Neben der Kodierung des Dokumentes hat darauf noch eine eventuelle accept-charset Angabe im Formular Einfluss.

Wenn nein, liege ich da richtig, das der Buchstabe immer in der Unicode-Codierung (in diesem Fall 0000 0000 1111 1100)gespeichert wird??

Das glaube ich nicht, Tim.
(Ich kann mir keinen Grund vorstellen, warum das so sein sollte.)

gruß,
wahsaga

[Ashura]

Hallo wahsaga.

Ich gebe nun beispielsweise den Buchstaben "ü" in das Textfeld ein. Hängt das nun von der im meta-tag angegebenen Zeichenkodierung ab, wie der Buchstabe binär im Textfeld gespeichert wird?

Was meinst du mit "gespeichert"?
Der Browser merkt sich diesen Wert irgendwo im RAM, mehr nicht. elche Kodierung er dabei wählt, ist für dich vollkommen uninteressant (auch wenn es vermutungsweise die des Dokuments sein dürfte).

Interessanterweise ist dem offenbar nicht so. Ich habe einmal diese Textarea gänzlich geleert¹, ein „Ä“ eingegeben und folgendes in der Adressleiste ausgeführt:

javascript:alert(escape(document.getElementsByTagName('textarea')[0].value));

Sowohl Opera als auch Firefox als auch IE geben einstimmig „%C4“ aus. Die Kodierung des Forums ist UTF-8, meine Systemkodierung ist ebenfalls UTF-8 und dennoch wird das Sonderzeichen nicht UTF-8-kodiert abgelegt.

Welcher Teil der Browser nun aber diese „temporäre Zeichenkodierung“ festlegt ist mir nicht bekannt.

Einen schönen Samstag noch.

Gruß, Ashura

[Ashura]

Hallo Gunnar™.

Ich habe einmal diese Textarea gänzlich geleert¹, […]

¹ Ist den Nutzern von Opera 9 unter GNU/Linux ebenfalls das Problem bekannt, dass die Tastenkombination [Strg]+[A] nicht mehr den gesamten Text markiert? Im normalen Dokument passiert rein garnichts, in Eingabefeldern springt der Cursor nur an den Anfang …

Einen schönen Samstag noch.

Gruß, Ashura

[Ashura]

Hallo Gunnar™.

Ich habe einmal diese Textarea gänzlich geleert¹, […]

¹ Ist den Nutzern von Opera 9 unter GNU/Linux ebenfalls das Problem bekannt, dass die Tastenkombination [Strg]+[A] nicht mehr den gesamten Text markiert?

OK, ich habe nun unter „Document Window“ und unter „Advanced/Edit Widget“ die betreffenden Tastaturkombinationen wieder korrigiert. Welcher Idiot ist auf die glorreiche Idee gekommen, [Strg]+[A] zu verwenden, um den Cursor am Anfang der Zeile zu platzieren?

Einen schönen Samstag noch.

Gruß, Ashura

[Axel Richter]

Hallo,

Ich habe einmal diese Textarea gänzlich geleert¹, ein „Ä“ eingegeben und folgendes in der Adressleiste ausgeführt:

javascript:alert(escape(document.getElementsByTagName('textarea')[0].value));

Sowohl Opera als auch Firefox als auch IE geben einstimmig „%C4“ aus.

The escape function returns the hexadecimal encoding of an argument in the ISO Latin character set.

Works as designed ;-).

viele Grüße

Axel

[Ashura]

Hallo Axel.

The escape function returns the hexadecimal encoding of an argument in the ISO Latin character set.

Works as designed ;-).

OK, vergessen wir dies.

Einen schönen Samstag noch.

Gruß, Ashura

[.nils]

Hallo,

Was meinst du mit "gespeichert"?

Die naive Sichtweise des Laien :-)

Der Browser merkt sich diesen Wert irgendwo im RAM, mehr nicht. elche Kodierung er dabei wählt, ist für dich vollkommen uninteressant (auch wenn es vermutungsweise die des Dokuments sein dürfte).

Das scheint der Fall zu sein:
folgendes Dokument (in Eclipse mit der Codierung US-Ascii gespeichert) gibt als alert dreimal "63" und einmal "???" aus, wenn ich "äöü" in das Textfeld eingebe:

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">  
<html>  
<head>  
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">  
<title>ascii</title>  
</head>  
<body>  
<script type="text/javascript">  

~~~~~~javascript
  
function asciitest(a){  
x=a;  
for(i=0;i<x.length;i++){alert(x.charCodeAt(i));}  
alert(x);  
}
~~~~~~html
  
</script>  
<form action="">  
<input type="text" onblur="asciitest(this.value);">  
</form>  
</body>  
</html>  

Folgendes, in utf-8 abgespeicherte Dokument gibt "228", "246", "252" und "äöü" aus:

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">  
<html>  
<head>  
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">  
<title>utf-8</title>  
</head>  
<body>  
<script type="text/javascript">  

~~~~~~javascript
  
function utf8test(a){  
x=a;  
for(i=0;i<x.length;i++){alert(x.charCodeAt(i));}  
alert(x);  
}
~~~~~~html
  
</script>  
<form action="">  
<input type="text" onblur="utf8test(this.value);">  
</form>  
</body>  
</html>  

Was dich ggf. interessieren könnte wäre, wie der Wert beim Abschicken des Formulars an den Server übertragen wird.
Neben der Kodierung des Dokumentes hat darauf noch eine eventuelle accept-charset Angabe im Formular Einfluss.

Aha, die Suche in Selfhtml zu accept-charset ergab folgende Seite
Muß ich mal bei meinem Provider nachfragen, welche Zeichenkodierung die verwenden...hoffentlich utf-8

Das glaube ich nicht, Tim.

Wer ist Tim?
Gruß, Nils

[.nils]

???

Auf einmal gibt es bei beiden das richtige aus... Ich schwöre, vor fünf Minuten wars bei Ascii noch "63" und "???"

???

Gruß, Nils

[Axel Richter]

Hallo,

Auf einmal gibt es bei beiden das richtige aus... Ich schwöre, vor fünf Minuten wars bei Ascii noch "63" und "???"

Wo, in welchem Browser, wurde das ausgegeben?

String.charCodeAt() gibt Unicode oder ISO-Latin-1 zurück, was bei "äöü" aber das selbe ist.

Du musst Dir über die systeminterne Speicherung der Zeichen im RAM nicht den Kopf zerbrechen. Wichtig ist die Zeichenkodierung nur, wenn die Zeichen übertragen oder in einer Datei gespeichert werden sollen. Dann muss die Kodierung angegeben werden und das kann man dann auch. Wie das System intern das "ü" auf den Bildschirm zaubert, welche fonts es dafür verwendet und wie die interne Kodierung der Zeichentabelle dieser fonts aussieht, ist hierfür völlig nebensächlich.

viele Grüße

Axel

[.nils]

Hallo,

Auf einmal gibt es bei beiden das richtige aus... Ich schwöre, vor fünf Minuten wars bei Ascii noch "63" und "???"
Wo, in welchem Browser, wurde das ausgegeben?

Im Firefox. Auf anderen Broiwsern habe ich es nicht getestet.

String.charCodeAt() gibt Unicode oder ISO-Latin-1 zurück, was bei "äöü" aber das selbe ist.

Du musst Dir über die systeminterne Speicherung der Zeichen im RAM nicht den Kopf zerbrechen. Wichtig ist die Zeichenkodierung nur, wenn die Zeichen übertragen oder in einer Datei gespeichert werden sollen.

Es geht dabei erstens um Html-Quelltext-Schnipsel, die zwecks späterer Ausgabe in demselben Textfeld in Dateien zwischengespeichert werden sollen. Daraus sollen dann per Perl oder Php automatisch die fertigen Html-Seiten erstellt und abgespeichert werden.

Zweitens arbeite ich gerade wegen dem Problem mit Schriftarten, die nicht überall installiert sind (ich verwende zum Beispiel gerne die Windows-Schriftart "Palantino Linotype", die aber meines Wissens auf z.B. Linux-Systemen nicht standardmäßig installiert ist) an einem (java)Script, das, nachdem die Seite geladen ist, dynamisch die Texte aus Überschriften und aus ausgesuchten Links (im Menü) durch Buchstabenbilder ersetzt (also jeden Buchstaben durch ein entsprechendes Bild). Das sollte ohne eine serverseitige Scriptsprache funktionieren. Ich bin mir natürlich über die Nachteile im klaren (kein Copy&Paste, Probleme, wenn Grafiken nicht angezeigt werden und Probleme bei Browsern für blinde Menschen etc.).

Dann muss die Kodierung angegeben werden und das kann man dann auch.

Wie geht das zum Beispiel in Perl ?!

Viele Grüße, Nils

[Der Martin]

Hi,

ich verwende zum Beispiel gerne die Windows-Schriftart "Palantino Linotype", die aber meines Wissens auf z.B. Linux-Systemen nicht standardmäßig installiert ist

auf Windows-Systemen auch nicht. Ich habe sie auf keinem der vier Windows-PCs, die ich im Moment erreichen kann und die alle sehr unterschiedlich mit Software bestückt sind.
Zum regulären Lieferumfang gehört sie also nicht; ich tippe mal, dass irgendeine Anwendung, die du im Lauf der Zeit installiert hast, diese Schrift mitgebracht hat.

Schönen Abend noch,
 Martin

[wahsaga]

hi,

Zweitens arbeite ich gerade [...] an einem (java)Script, das, nachdem die Seite geladen ist, dynamisch die Texte aus Überschriften und aus ausgesuchten Links (im Menü) durch Buchstabenbilder ersetzt (also jeden Buchstaben durch ein entsprechendes Bild). Das sollte ohne eine serverseitige Scriptsprache funktionieren. Ich bin mir natürlich über die Nachteile im klaren (kein Copy&Paste, Probleme, wenn Grafiken nicht angezeigt werden und Probleme bei Browsern für blinde Menschen etc.).

Wenn keine Grafiken angezeigt werden oder für Menschen, die keine Grafiken sehen, sollte das weniger ein Problem sein - schließlich hat jedes Bild ein alt-Attribut, in das du auch per Javascript jeweils den entsprechenden Buchstaben reinschreiben kannst.

Den großen Nachteil sehe ich ganz woanders - im Traffic. Wenn du für jedes neue Zeichen jedesmal eine Bilddatei vom Server anfordern lässt, kostet das natürlich - schon allein die HTTP-Header für den reinen Transport dürften jeweils ca. 1KB betragen, und da sind die Bilddaten noch nicht mal mit drin.
Klar, nach dem ersten Einsatz können die Bilder gecached werden - aber trotzdem finde ich diese Methode nicht sonderlich elegant.

Vielleicht wäre da ein Blick auf sIFR einen Blick wert (aktuell in Version 2.0.2 vorliegend, die 3er-Version ist im Alpha-Stadium).
Dabei werden Textteile wie Überschriften o.ä. nach dem laden des Dokumentes per Javascript durch Flash-Objekte ersetzt, die den Text in der jeweiligen Schriftart darstellen. Markieren, Kopieren stellt damit inzwischen auch kein Problem mehr dar, und es skaliert auch mit der jeweiligen Schriftgröße (was bei deiner Javascript-Lösung ein weiterer Nachteil wäre, die Schriftgröße bliebe immer die, die du beim Erstellen der Bilder benutzt hast [sofern du die Bilder nicht ebenfalls skalierst, was aber optische eher dürftige Effekte bringen dürfte]).

gruß,
wahsaga

[.nils]

Hallo wieder,

Den großen Nachteil sehe ich ganz woanders - im Traffic. Wenn du für jedes neue Zeichen jedesmal eine Bilddatei vom Server anfordern lässt, kostet das natürlich - schon allein die HTTP-Header für den reinen Transport dürften jeweils ca. 1KB betragen, und da sind die Bilddaten noch nicht mal mit drin.

Das ist allerdings ein schlagendes Argument, was mir garnicht eingefallen ist. Das wären dann bei ~200 Zeichen so Circa 1 MB - Für eine Schriftsorte. Macht bei sechs Überschriften und einer Schriftsorte fürs Menü 7 MB. Damit ist die Idee gestorben :-)

Vielleicht wäre da ein Blick auf sIFR einen Blick wert (aktuell in Version 2.0.2 vorliegend, die 3er-Version ist im Alpha-Stadium).

Danke, das schaue ich mir mal an. Wenn das nichts an Kosten verursacht (Was Macro- äh Adobe für das Flash/etc haben will, ist ja der reinste Witz).. ist natürlich (wie bei javascript) auch nicht der reine Weg. Das mit den Schriftarten ist echt ätzend :-/ Wenn Pdf ein freies Format wäre...

Gruß, Nils

[Der Martin]

Hallo Nils,

Wenn Pdf ein freies Format wäre...

das ist es doch quasi. Die Spezifikation ist offengelegt und für jedermann zugänglich, sogar der Entwurf für PDF/1.5 ist schon veröffentlicht (wenn auch weite Teile der Adobe-Website momentan nicht erreichbar sind).

So long,
 Martin

[.nils]

Hallo,

das ist es doch quasi. Die Spezifikation ist offengelegt und für jedermann zugänglich, sogar der Entwurf für PDF/1.5 ist schon veröffentlicht (..)

Das ist natürlich toll. Aber wenn ich das abschreibe (vielleicht gar verbessere) und es beispielsweise dann .pdx nenne, habe ich mit Sicherheit bald Adobes Anwälte am Hals. Htmx zu "erfinden" wäre hingegen kein Problem (wenngleich sinnfrei).

Gruß, Nils

[Axel Richter]

Hallo,

Du musst Dir über die systeminterne Speicherung der Zeichen im RAM nicht den Kopf zerbrechen. Wichtig ist die Zeichenkodierung nur, wenn die Zeichen übertragen oder in einer Datei gespeichert werden sollen.
Es geht dabei erstens um Html-Quelltext-Schnipsel, die zwecks späterer Ausgabe in demselben Textfeld in Dateien zwischengespeichert werden sollen.

Dann muss das Programm, welches zwischenspeichert, die Kodierung beachten.

Daraus sollen dann per Perl oder Php automatisch die fertigen Html-Seiten erstellt und abgespeichert werden.

Dann muss PHP bzw. Perl beim Lesen der Files die Kodierung beachten.

... an einem (java)Script, das, nachdem die Seite geladen ist, dynamisch die Texte aus Überschriften und aus ausgesuchten Links (im Menü) durch Buchstabenbilder ersetzt (also jeden Buchstaben durch ein entsprechendes Bild).

JavaScript arbeitet in den in aktuellen Browsern verwendeten Versionen _immer_ mit Unicode, siehe meine Links zur Core JavaScript Reference.

Wie geht das zum Beispiel in Perl ?!

Keine Ahnung, aber das Modul Encode sieht hierfür ganz gut aus.

viele Grüße

Axel

[.nils]

Hallo,

Wie geht das zum Beispiel in Perl ?!
Keine Ahnung, aber das Modul Encode sieht hierfür ganz gut aus.

Danke Axel

Ich hatte eben viel Spaß, als ich die Seite mal durch den Babelfisch jagte

Viele Grüße, Nils

[wahsaga]

hi,

Aha, die Suche in Selfhtml zu accept-charset ergab folgende Seite

Da steht doch, dass _du_ diese Angabe in deinem Dokument machst.

Muß ich mal bei meinem Provider nachfragen, welche Zeichenkodierung die verwenden...hoffentlich utf-8

Dein Provider hat höchstens den Webserver so konfiguriert, dass Dokumente standardmäßig mit einem bestimmten Charset im Content-Type-Header ausgeliefert werden.
Allerdings solltest du deine Entscheidung nach der Koiderung, die du verwendest, nicht davon abhängig machen - sonfern von dem, was du brauchst.
Der vom Provider gesetzte Default sollte sich überschreiben lassen - entweder durch Konfugiration des Webservers (beim Apachen über .htaccess), oder spätestens in einem serverseitigen Script.

gruß,
wahsaga

[.nils]

Hallo,

Der vom Provider gesetzte Default sollte sich überschreiben lassen - entweder durch Konfugiration des Webservers (beim Apachen über .htaccess), oder spätestens in einem serverseitigen Script.

Ich kann mir ja nicht mal ein typo3+ImageMagick installieren, geschweige denn einen Apache - und das bei 20 Euro im Monat...

Gruß, Nils

[Tim Tepaße]

Hallo Nils,

Ich gebe nun beispielsweise den Buchstaben "ü" in das Textfeld ein. Hängt das nun von der im meta-tag angegebenen Zeichenkodierung ab, wie der Buchstabe binär im Textfeld gespeichert wird?

Wie Dir schon gesagt wurde, ist es völlig wurst, wie die Browser so etwas intern speichern. Tatsächlich verwenden die meisten aber anscheinend wirklich eine Unicode-Kodierung für Strings, soweit ich weiss.

Wenn nein, liege ich da richtig, das der Buchstabe immer in der Unicode-Codierung (in diesem Fall 0000 0000 1111 1100)gespeichert wird??

Nein.

Du hast hier eine Umrechnungsfehler. Hier mal ein kleiner Crashkurs in der Unicode-Kodierung UTF-8. Die ja nur eine von mehreren binären Kodierungen von Unicode Zeichen ist.

Das kleine Ü hat im Unicode Zeichensatz folgenden Code-Point: U+FC. So ein Code-Point ist eigentlich nur eine Indexnummer, an welcher Stelle im Zeichensatz sich ein Zeichen (Buchstabe) befindet. Traditionell wird die Nummer in hexadezimaler Notation benutzt (dezimal wäre sie 252), davor wird dann das "U+" gesetzt.

Nun könnte man diese Code-Point einfach in Binärschreibweise umrechnen, das hast Du ja auch getan, die hexadezimale Zahl FC ist 11111100 in Binärschreibweise. Hier sind das praktischerweise acht Bits, also das üblicherweise benutzte klassische Byte. Nur: Bei höheren Code-Points wird die Binärschreibweise natürlich immer länger. Und Bytes haben eine feste Länge, sonst kommt man ja durcheinander und weiss nicht, wo das eine Zeichen aufhört und das andere anfängt. Du hast jetzt einfach acht binäre Nullen davor gesetzt: 00000000 11111100, hast also zwei Bytes.  Das ist aber die Kodierung UTF-16, nicht die Kodierung UTF-8. Unicode definiert mehrere, verschiedene Kodierungen, um aus einer Zahl tatsächliche Bytes zu kriegen. Die langweiligste ist UTF-32, da wird jeder Code-Point eines Buchstabens in vier Bytes (= 32 Bit) kodiert, für das kleine Ü sieht das dann so aus:

00000000 00000000 00000000 11111100

Ganz viele Nullen im Speicher oder im Kabel also. UTF-16 ist mit dem Platzverbrauch etwas geschickter. Da werden Code-Points, die mit nur 16 Bit, also zwei Byte kodiert werden können, auch nur mit zwei Bytes kodiert. Praktischerweise betrifft das so gut wie den meisten Text, der da draussen existiert. Code-Points, die sich nicht durch 16 Bit binär kodieren lassen, werden dann mit zwei mal zwei Bytes kodiert. Durch ein geschicktes Verfahren werden die 16+ Bits so in 32 Bit untergebracht, dass sie nicht mit normalen 16 Bit großen binären Kodierungen von Code-Points verwechselt werden können. Das heisst: In UTF-16 kodierte Code-Points von Zeichen sind immer zwei Bytes groß – es sei denn, sie sind vier Bytes groß. Stressig, oder?

Ich weiche nur so lange vom eigentlichen Thema ab, weil ein ähnliches Prinzip bei der Kodierung UTF-8 benutzt wird, nur viel intensiver. Und UTF-8 war die Kodierung, die Du eigentlich angegeben hast. Fangen wir am Anfang an: Das Zeichen des kleinen Üs hat den Code-Point U+FC. In Binärschreibweise ist das die Zahl 11111100. Das sind acht Bit, das erste Bit ist eine Eins. UTF-8 wurde aber mit genau dem Ziel geschaffen, dass die bisherigen Bytes, die Zeichen im ASCII-Zeichensatz darstellen auch die gleichen Zeichen im Unicode-Zeichensatz ergeben.

Zur Erinnerung: Der ASCII-Zeichensatz hat nur 128 Zeichen, die sich in Binärschreibweise durch sieben Bit kodieren lassen. Als Byte ist dann das erste Bit eine Null. Sinnigerweise sind die ersten 128 Zeichen im Unicode Zeichensatz gleich den 128 Zeichen des ASCII-Zeichensatzes. Für diese gilt in der Kodierung UTF-8 also die Regel: „In die Binärschreibweise umrechnen, ein Nullbit davor setzen“. Das Problem kommt dann bei den anderen 1.113.986 Zeichen des Unicode Zeichensatzes. Wandelt man die in Binärschreibweise um, sprengt man wieder die Grenzen eines Bytes. Damit man weiss, wo ein Zeichen beginnt und endet, braucht man wieder eine Regel, um zu wissen, welche Bytes zusammen ein Zeichen bestimmen. Dazu muss man seine Bits der Binärschreibweise des Code-Points richtig in Bytes umwandeln. UTF-8 macht das vereinfacht dargestellt im wesentlichen mit vier Regeln:

(1) Wenn sich der Code-Point des zu kodierenden Zeichens zwischen 0 und 1111111 (hexadezimal: 0–7F) befindet, füge die Bits in dieses Byte ein: 0xxxxxxx

Das ist unsere ASCII-Kompabilitätsregel. Mal exemplarisch am Beispiel des Plus-Zeichens durchgeführt: Das Plus-Zeichen hat den Code-Point U+2B, in Binärschreibweise lautet die Zahl 101011. Diese wird nun in obiges Byte eingefügt, der überschüssige Platz davor wird mit Nullen (hier nur einer) aufgefüllt:

0xxxxxxx
    101011
   0
  --------
  00101011

Damit haben wir unser Byte für das Zeichen "+". Die anderen drei Regeln gehen genauso, nur dass sie statt einem zu füllenden Byte mehrere benutzen:

(2) Wenn sich der Code-Point des zu kodierenden Zeichens zwischen 10000000 und 11111111111 (hexadezimal: 80–7FF) befindet, füge die Bits in diese zwei Bytes ein: 110xxxxx 10xxxxxx

(3) Wenn sich der Code-Point des zu kodierenden Zeichens zwischen 100000000000 und 1111111111111111 (hexadezimal: 800–FFFF) befindet, füge die Bits in diese drei Bytes ein: 1110xxxx 10xxxxxx 10xxxxxx

(4) Wenn sich der Code-Point des zu kodierenden Zeichens zwischen 10000000000000000 und 100001111111111111111 (hexadezimal: 10000–10FFFF ) befindet, füge die Bits in diese vier Bytes ein: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

(Theoretisch geht bei Regel (4) noch mehr, der aktuelle Standard begrenzt die Menge jedoch)

UTF-8 ist also noch komplizierter als UTF-16, denn hier lautet die Faustregel „Ein mit UTF-8 kodiertes Zeichen hat ein Byte, es sei denn, es hat zwei. Oder drei. Oder vier Bytes.“

Aber das Gute ist: man kann immer erkennen, wozu ein Byte gehört. Alle in den Regeln (2) bis (4) angegebenen aufzufüllenden Bytes beginnen mit einer Eins als erstem Bit. So können sie nicht mit Bytes aus Regel (1) verwechselt werden. Bytes, die als zweites, drittes oder viertes Byte eines Zeichens dienen, beginnen immer mit "10", also einer Eins als erstem Bit und einer Null als zweitem Bit. Ein beginnendes Byte eines mit zwei Bytes kodierten Zeichens beginnt immer mit "110", ein beginnendes Byte eines mit drei Bytes kodierten Zeichens beginnt immer mit "1110" und ein beginnendes Byte eines mit vier Bytes kodierten Zeichens beginnt immer mit "11110". Geschickt, geschickt.

UTF-8 hat noch mehr Geschicktheiten, wie zum Beispiel das Byte Order Mark, das einem anzeigt, in welcher Reihenfolge die Bytes ankommen, aber das geht hier zu weit.

Rechnen wir noch eben den Code-Points (Hexadezimal: 0xFC, Binär: 0b11111100) des kleinen Üs in UTF-8 um:

0xFC liegt eindeutig zwischen 0x80 und 0x7FF, also kommt Regel (2) zum Einsatz:

110xxxxx 10xxxxxx     |  Die aufzufüllenden Bytes aus Regel (2)
        11   111100     |  0xFC in binär, an die Stellen der x gesetzt
     000                |  Mit Nullen auffüllen
  -----------------
  11000011 10111100

Also sind die hexadezimal notierten Bytes C3 BC die in UTF-8 kodierte Binärdarstellung des Zeichens "ü".

Tim