Frage zu UTF8 < Sonstige < Schule < Informatik < Vorhilfe
|
| Status: |
(Frage) beantwortet  | | Datum: | 21:13 Sa 25.11.2006 | | Autor: | Phoney |
Hallo Leute.
Ich beschäfitge mich derzeit etwas mit UTF 8.
Habe da auch gleich mal einige Fragen, u. a. habe ich mir den Wikipedia-Artikel durchgelesen:
http://de.wikipedia.org/wiki/Utf8
Da steht dann nun für die Anzahl der Möglichkeiten (Kodierung), dass es für 1 Byte ^7 Möglichkeiten gibt,
2 Byte [mm] 2^{11}-2^7
[/mm]
3 byte [mm] 2^{16}-2^{11}
[/mm]
Ich dachte jetzt,a dass man immer guckt, was war die größte Zweierpotenz - vorher war es ja 2^11, dann zieht man beim nächsten byte eben [mm] 2^{11} [/mm] ab. Ausnahmsweise stimmt es, bei
1) 4Byte ist es aber [mm] 2^{20} [/mm] Möglichkeiten, warum?
2) Sind das eigentlich die Gesamtmöglichkeiten, weil da steht ja auch: In Klammern jeweils die theoretisch maximal möglichen.
Kann ich also bei 2 Byte jetzt [mm] 2^{11} [/mm] Möglichkeiten haben und bezieht sich diese [mm] 2^{11}-2^7 [/mm] nur auf die Anzahl der Möglichkeiten, die man zu der 1Byte Kodierung mehr hat?
Ich habe da auch gleich mal eine hypothetische Frage
3) Wenn in einer Datei, die UTF-8 kodierte Zeichen speichert, ein Byte durch eine fehlerhafte Festplatte ungültig wird, kann man dann den unbeschädigten Teil der Datei noch dekodieren?
Wahrscheinlich ja schon, nur ist mir der Grund dafür nicht ganz klar (und ich finde dazu auch leider nichts). Wenn man das noch dekodieren kann, dann vermutlich auch nur die bytes, die in Ordnug sind, oder?
Wäre sehr nett, wenn mir da jemand mal etwas zu erzählen würde.
Viele Grüße
Johann
|
|
| |
|
Hallo,
oft kann man diese Art von Fragen nur mit einem "so ist eben der Standard definiert" beantworten. Schauen wir mal genauer hin:
> Ausnahmsweise stimmt es, bei
> 1) 4Byte ist es aber [mm] 2^{20} [/mm] Möglichkeiten, warum?
Nun, es gäbe tatsächlich [mm] $2^{21} [/mm] - [mm] 2^{16}$ [/mm] Möglichkeiten, aber man hat den UTF-8-Raum beschränkt:
"... in seiner Verwendung als UTF-Kodierung ist er aber auf den gemeinsamen Coderaum aller Unicode-Kodierungen beschränkt, also von 0 bis 0010 FFFF (1.114.112 Möglichkeiten)..."
> Kann ich also bei 2 Byte jetzt [mm] 2^{11} [/mm] Möglichkeiten haben und bezieht
> sich diese [mm] 2^{11}-2^7 [/mm] nur auf die Anzahl der Möglichkeiten, die man zu
> der 1Byte Kodierung mehr hat?
Nun, wenn du dich an diesen Standard halten willst, dann kannst du nicht. Wenn du alle [mm] 2^{11} [/mm] Möglichkeiten nutzt, dann stößt du auf das Problem der mehrdeutigen Kodierung, das auch in der Quelle beschrieben ist. Als Beispiel:
In einer Datenbank sind alle Buchstaben "a" (fälschlicherweise) kodiert als 11000001 10100001. Nun liest ein Programm die Daten aus, verarbeitet sie, korrigiert dabei die Kodierung und schreibt sie wieder mit den richtigen "a"s (01100001) zurück. Nun vergleicht ein Prüfprogramm, ob die alten und die neuen Daten noch übereinstimmen und überschlägt sich, weil sich die alten und neuen "a"s unterscheiden! Katastrophe!
Also: Immer schön an den Standard halten, auch wenn dabei etwas Speicherplatz verloren geht. Es hat schon seinen Sinn.
> 3) Wenn in einer Datei, die UTF-8 kodierte Zeichen speichert, ein Byte
> durch eine fehlerhafte Festplatte ungültig wird, kann man dann den
> unbeschädigten Teil der Datei noch dekodieren?
Ja.
Wir können uns mal überlegen, was für Fehler typischerweise auftreten können.
1.) Es können einzelne Bytes verschwinden.
2.) Es können zufällige Bytes eingestreut werden.
3.) Es können einzelne Bytes verfälscht werden.
Dazu nehmen wir mal an, wir hätten folgende Daten in UTF-8 (größere Pausen zwischen einzelnen Zeichen):
11001101 10011101 11101101 10110101 10001010 00111010
1.)
a) Plöztlich verschwindet bei der Übertragung das erste Byte:
... 10011101 11101101 10110101 10001010 00111010
Das dekodierende Programm liest direkt zu Anfang ein mit 10 beginnendes Byte und weiß, dass das ein Folgebyte ist, zu dem anscheinend das Startbyte fehlt. Also wird dieses Byte übersprungen und das zweite Byte fängt mit 11 an, also ist dies ein Startbyte. Dieses Zeichen fängt also schon mal gültig an. Da es sogar mit 1110 anfängt, müssen zwei Bytes mit 10 am Anfang folgen. Sie tun es, alles ok. Dann fängt das letzte Byte mit 00 an, also muss dies ein ASCII-Zeichen sein. Das ist auch gültig. Also wurde als gültig gelesen:
11101101 10110101 10001010 00111010
b) Hier verschwindet das vierte Byte:
11001101 10011101 11101101 ... 10001010 00111010
Das erste 2-Byte-Zeichen wird korrekt gelesen. Nun fängt mit 1110 ein 3-Byte-Zeichen an. Das Programm liest das erste Byte, das zweite (eigentlich schon das dritte) Byte und erwartet ein drittes Byte, das mit 10 anfängt, findet aber ein Byte mit 00 am Anfang vor. Also verwirft es die eben gelesenen zwei Bytes und liest das aktuelle als gültiges ASCII-Zeichen. Ergebnis:
11001101 10011101 00111010
2.) Wenn ein Byte zufällig eingefügt wird, dann taucht an einer unpassenden Stelle ein falscher Code auf. Entweder erwartet das Programm ein Startbyte und findet ein Folgebyte. Dann überspringt es dieses Folgebyte, bis es ein Startbyte findet.
Oder aber es erwartet ein Folgebyte und findet ein Startbyte. Dann verwirft es die bereits gelesenen Bytes und fängt mit einem neuen Zeichen an.
3.) Wenn einzelnen Bytes verändert werden hat es je nach Fall ganz ähnliche Auswirkungen.
Jedenfalls können die "defekten" Zeichen immer übersprungen werden, weil sie als unvollständig erkannt werden. Oder sie werden falsch gelesen. Aber für die folgenden Zeichen hat dies keine Auswirkungen, weil sie alle ihre eigenen Startbytes haben, so dass ein verwirrtes Programm immer nur nach dem nächsten Startbyte suchen muss. Eine tolle Erfindung, auch wenn sie etwas Speicherplatz kostet.
Gruß
Martin
|
|
|
| |
|
| Status: |
(Mitteilung) Reaktion unnötig  | | Datum: | 18:40 So 26.11.2006 | | Autor: | Phoney |
Hallo Martin243!
Das war eine tolle Antwort. Super! Vielen dank dafür!
Viele Grüße v.
Johann
|
|
|
|
