nicht angemeldet
Zeichensatz im Editor - utf8 <->iso8859/8bit
Gunnar Bittersmann
Der MartinHellihello
wenn ich den Editor auf uft8 - Kodierung einstelle und Sonderzeichen eingebe und dannach auf 8bit umstelle, erhalte ich:
ä ä
Ä Ã„
ö ö
Ö Ã–
ü ü
Ü Ãœ
ß ÃŸ
geb ich die sonderzeichen in 8bit-codierung ein, wird bei Umstellung auf utf8 aus jedem Zeichen ein Kästchen, ausgenommen das große "Ä", da wird ein "Ã" draus.
Aus "Ä-" in 8bit wird aber dann "ĭ" in utf8.
Kann mir wer auf die Sprünge helfen. Wikipediaartikel hatte ich mir schon immer wieder und auch heute zu Gemüte geführt. Irgendwo aber ein draufgetretener Schlauch bei mir.
Dank und Gruß,
-
@@frankx:
wenn ich den Editor auf uft8 - Kodierung einstelle und Sonderzeichen eingebe und dannach auf 8bit umstelle
??
erhalte ich:
ä ähttp://forum.de.selfhtml.org/archiv/2006/4/t128167/#m827577
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.-
Hellihello Gunnar,
mercri,
wenn ich den Editor auf uft8 - Kodierung einstelle und Sonderzeichen eingebe und dannach auf 8bit umstelle
??
"... Zeichenkodierung im Editor ändere..."
erhalte ich:
ä äFein, will heißen: das utf-8-"ä" besteht aus 16 Bit, in 8Bit/Latin1/iso-8859-1 werden die 16 Bit als zwei mal 8-Bit verstanden.
Und umgekehrt? Fasst utf8 dann immer zwei Zeichen zusammen? Und wie ist es definiert, wenn nur 8bit in einer Zeile stehen? Absatz 8Bit-"ä" Absatz?
Dank und Gruß,
-
@@frankx:
??
"... Zeichenkodierung im Editor ändere..."
erhalte ich:
Was heißt „erhalte ich“? Wo erhältst du das? Im Editor? Oder wenn du die Webseite (Geht es um eine Webseite?) im Browser anzeigen lässt? In diesem Falle FAQ: Änderung der Zeichencodierung einer (X)HTML-Seite auf UTF-8 lesen und nicht bei Schritt 1 stehenbleiben.
Fein, will heißen: das utf-8-"ä" besteht aus 16 Bit, in 8Bit/Latin1/iso-8859-1 werden die 16 Bit als zwei mal 8-Bit verstanden.
So in etwa.
Und umgekehrt? Fasst utf8 dann immer zwei Zeichen zusammen?
Nein. Trenne dich zuerst von der Vorstellung, ein Oktett (Byte) stünde für ein Zeichen. In UTF-8 werden Zeichen je nach ihrem Zeichencode als ein, zwei, drei oder vier Oktetts codiert, wie im Wikipedia-Artikel zu UTF-8 zu lesen ist. An den HSB des ersten Oktetts ist zu erkennen, ob und wieviele folgende Oktetts noch zu dem betreffenden Zeichen gehören.
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort. -
Moin!
Fein, will heißen: das utf-8-"ä" besteht aus 16 Bit, in 8Bit/Latin1/iso-8859-1 werden die 16 Bit als zwei mal 8-Bit verstanden.
Ja und nein - deine Formulierung deutet an, dass du zwar wörtlich das Richtige sagst, aber dahinterstehend noch das Falsche verstehst.
Ein "ü" besteht in UTF-8 aus zwei Byte (= 2*8 Bit = 16 Bit), korrekt. Weil das das Ergebnis der Vorschrift ist, wie man den Unicode-Codepoint des "ü" in Bytes umzusetzen hat.
Und richtig ist auch, dass die Interpretation dieser zwei Bytes in ISO-8859-1 zu zwei Zeichen führt, die mit dem Original-"ü" nicht so wahnsinnig viel gemein haben.
Allerdings gibt es zwei Arten, wie man im Editor die Codierung der Zeichen "umschalten" kann. Der eine Fall, den du gerade siehst, ist diese: Der Editor liest die Bytes, und kriegt gesagt, nach welcher Vorschrift er die Bytes als Buchstaben auffassen soll. Änderst du die Vorschrift, dann ändert sich die Buchstabenanzeige, aber nicht die Bytes in der Datei.
Die alternative Methode ist, dass der Editor beim Umschalten den Buchstaben, der laut Vorschrift beim Lesen der Datei interpretiert wurde, beibehält, aber die Bytes ändert, weil für die andere Codiervorschrift eben andere Bytes notwendig sind, um dasselbe Zeichen darzustellen. Beim Speichern würde die Datei dann verändert werden.
Und umgekehrt? Fasst utf8 dann immer zwei Zeichen zusammen?
UTF-8 nutzt variabel viele Bytes, um ein Zeichen darzustellen. Es beginnt bei 1 Byte, und geht bis hin zu vier Bytes. Durch die geschickte Wahl der Codierung kann man jedem Byte ansehen, ob es für sich alleine steht, oder zu einem Multibyte-Zeichen gehört. Hat man es mit einem Multibyte-Zeichen zu tun, kann man feststellen, ob es das erste Zeichen einer Sequenz ist, oder eines der Folgezeichen. Hat man es mit einem Folgezeichen zu tun, befindet sich das erste Zeichen der Sequenz immer ein paar Bytes weiter vorne in der Bytefolge. Und das erste Zeichen einer Sequenz liefert immer die Anzahl der Folgebytes, die noch zu diesem Zeichen gehören, mit.
Um's mal konkret zu machen:
Ist das höchste Bit eines Bytes nicht gesetzt, handelt es sich um ein 1-Byte-UTF-8-Zeichen, das praktischerweise identisch ist mit den 7-Bit-ASCII-Zeichen.
Ist das höchste Bit gesetzt, handelt es sich um ein Byte eines Mehrbyte-Zeichens. Ist das zweithöchste Bit nicht gesetzt (also 10xx xxxx), handelt es sich um ein Folgebyte. Ist das zweithöchste Bit gesetzt (11xx xxxx), handelt es sich um das erste Byte eines Mehrbyte-Zeichens - wobei durch die Anzahl der hochwertigen 1-Bits definiert ist, wieviele Folgebytes noch kommen. Bei 110x xxxx kommt beispielsweise noch 1 Folgebyte (insgesamt 2 Bytes = 16 Bit), bei 1110 xxxx kommen zwei (insgesamt 3 Byte = 24 Bit), 1111 0xxx folgen noch drei Bytes (insgesamt 4 Byte = 32 Bit).
Siehe auch http://de.wikipedia.org/wiki/UTF-8.
Und wie ist es definiert, wenn nur 8bit in einer Zeile stehen? Absatz 8Bit-"ä" Absatz?
Der "Absatz" ist natürlich auch ein Zeichen, das als Byte codiert in der Datei steht. Es gibt in diesem Sinne also kein "Absätze" mit Zeichen als Bytes und Zeilenumbrüchen als ... nunja, was sollte man denn nutzen, um ohne Bytes einen Zeilenumbruch in eine Datei zu schreiben.
In deinem Betrachtungsfall hast du also drei Bytes:
1. Absatz-Byte.
2. "ä"-Byte.
3. Absatz-Byte.Das sind drei Bytes, die entsprechend der Regeln der Codierung betrachtet werden müssen. Wählst du ISO-8859-1, und das "ä" ist gemäß dieser Vorschrift codiert, wirst du ein vernünftiges "ä" sehen.
Wählst du UTF-8, und das "ä" ist dennoch laut ISO-8859-1 codiert, wirst du anstelle des "ä" ein Kästchen oder Fragezeichen als Indikator für "fehlerhaftes oder nicht darstellbares Zeichen" erhalten, weil das "ä"-Bytes das höchstwertige Bit gesetzt hat, von UTF-8 also als Mehrbyte-Zeichen betrachtet wird - das nachfolgende Absatz-Byte aber hat das höchstwertige Bit nicht gesetzt, also kann festgestellt werden, dass hier ein UTF-8-Fehler ist.
Alternativ kann es aber auch passieren, dass gemäß der Bit-Angabe des "ä"-Bytes einfach alle nachfolgenden Bytes als zugehörig zu diesem Multibyte-Zeichen gerechnet werden - und im Editor einfach verschwinden. Das Resultat ist dann, dass weder das (natürlich fehlerhafte und deshalb nicht darstellbare) Multibyte-Zeichen, noch die diesem Zeichen fälschlich zugerechneten Nachfolgezeichen dargestellt werden - es wird einfach ein Stückchen Text verschluckt, und der Editor wird vermutlich nach dem Ändern des Textes und beim Speichern das fehlerhafte UTF-8-Zeichen inklusive aller verschluckten Bytes herausfiltern und nicht wieder in die Datei schreiben.
Deshalb ist es immer extrem wichtig, dass man festlegt und mit angibt, nach welcher Codierungsvorschrift die Bytes eines Textes zu interpretieren sind. Leider bietet das lokale Dateisystem für nackte Textdateien keinen guten Ort, diese Information zu speichern - man muß es sich also irgendwie separat merken oder grundsätzlich nur eine einzige Codierung verwenden. Aber immerhin kann man in HTML-Dateien ein passendes <meta>-Element einfügen - und im Netz liefert HTTP diese Zusatzinformation in der Regel mit.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hellihello Sven,
UTF-8 nutzt variabel viele Bytes, um ein Zeichen darzustellen. Es beginnt bei 1 Byte, und geht bis hin zu vier Bytes. Durch die geschickte Wahl der Codierung kann man jedem Byte ansehen, ob es für sich alleine steht, oder zu einem Multibyte-Zeichen gehört. Hat man es mit einem Multibyte-Zeichen zu tun, kann man feststellen, ob es das erste Zeichen einer Sequenz ist, oder eines der Folgezeichen. Hat man es mit einem Folgezeichen zu tun, befindet sich das erste Zeichen der Sequenz immer ein paar Bytes weiter vorne in der Bytefolge. Und das erste Zeichen einer Sequenz liefert immer die Anzahl der Folgebytes, die noch zu diesem Zeichen gehören, mit.
In deinem Betrachtungsfall hast du also drei Bytes:
- Absatz-Byte.
- "ä"-Byte.
- Absatz-Byte.
LF+CR, einmal 00001010 einmal 00001101, jeweils das erste Bit nicht gesetzt, werden normal interpretiert.
ä ist 0xE4, also 11100100 (???), immerhin aber das erste Bit gesetzt, wie du sagst. Und die nächsten beiden, also müssten die nächsten beiden folgenden Bytes mit 10... beginnen? Das wäre eigentlich beim "§" der Fall (0xA7 entspr. 10100111). Aber die Folge "䧧" also 111001001010011110100111 bringt auch ein Kästchen.
»
Das sind drei Bytes, die entsprechend der Regeln der Codierung betrachtet werden müssen. Wählst du ISO-8859-1, und das "ä" ist gemäß dieser Vorschrift codiert, wirst du ein vernünftiges "ä" sehen.
Wählst du UTF-8, und das "ä" ist dennoch laut ISO-8859-1 codiert, wirst du anstelle des "ä" ein Kästchen oder Fragezeichen als Indikator für "fehlerhaftes oder nicht darstellbares Zeichen" erhalten...
Das mal ein entscheidender Schritt zu Verständnis: dass das Quadrat eben Platzhalter für ein nicht-darstellbares Zeichen ist.
Alternativ kann es aber auch passieren, dass gemäß der Bit-Angabe des "ä"-Bytes einfach alle nachfolgenden Bytes als zugehörig zu diesem Multibyte-Zeichen gerechnet werden - und im Editor einfach verschwinden.
Nein, das macht Scite dann schon ganz "clever".
Deshalb ist es immer extrem wichtig, dass man festlegt und mit angibt, nach welcher Codierungsvorschrift die Bytes eines Textes zu interpretieren sind.
Jau, das ja sowieso. Ich dachte halt, ich komme dem mal dem Grunde nach auf die Spur. Deine Zahlenwirbel da oben haben schon fast dazu geführt (;-).
Dank und Gruß,
-
@@frankx:
ä ist 0xE4, also 11100100 (???), immerhin aber das erste Bit gesetzt,
Nein. „Erstes Bit gesetzt“ bezieht sich nicht auf den Zeichencode, sondern auf die Oktetts bei Codierung in UTF-8. Und da ergibt 'ä' U+00E4 die Oktettsequenz C3 A4: 11000011 10100100. Das erste Bit ist also 1, das zweite auch, das dritte 0.
Beim Decodieren gehört also das dem Oktett C3 folgende A4 noch zum selben Zeichen.
Das mal ein entscheidender Schritt zu Verständnis: dass das Quadrat eben Platzhalter für ein nicht-darstellbares Zeichen ist.
Browserabhängig, siehe Thread Was bedeutet dieses Zeichen? �
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.-
Hellihello Gunnar,
mein "Experiment" habe ich im SciTE unternommen. Der/die/das spuckt das Quadrat aus. Anfangs dachte ich, es wäre die Interpretation eines utf-8-zeichencodes. Nicht die "Fehlermeldung".
ä ist 0xE4, also 11100100 (???), immerhin aber das erste Bit gesetzt,
Nein. „Erstes Bit gesetzt“ bezieht sich nicht auf den Zeichencode, sondern auf die Oktetts bei Codierung in UTF-8. Und da ergibt 'ä' U+00E4 die Oktettsequenz C3 A4: 11000011 10100100. Das erste Bit ist also 1, das zweite auch, das dritte 0.
Ich dachte jetzt so: wenn Latin1-"ä" (Hexal E4) binär durch 11100100 dargestellt wird, dann würde ein uft8-interpreter jetzt meinen: es folgen noch zwei Byte, die zu interpretieren sind. Diese müssen mit 10.. beginnen. Im Latin1-Editor wäre also ein Latin-1-Zeichen einzugeben, was binär mit 10... kodiert wird. (Nicht LF oder CR., die beide mit 0.... beginnen).
In Latin1 wird das "§" binär mit 10100111 dargestellt (hexa A7 in der Latin1-Tabelle). Also würde im Latin1-Editor die Folge "䧧" die Binärnotation 11100100 10100111 10100111. Bei einer utf-8-Interpretation würden die ersten drei einsen definieren, dass noch zwei Oktetts folgen, die jeweils per Definition mit 10.. beginnen müssen. Ich dachte, so müsste dann irgendein uft-8-Zeichen rauskommen, es sei denn das o.g. ist nicht definiert, und gibt einen Fehler, weil es das nicht gibt und nicht weil das falsch binär kodiert wäre.
Browserabhängig, siehe Thread Was bedeutet dieses Zeichen? �
Bzw. editorabhängig (;-), s.o..
Dank und Gruß,
-
@@frankx:
Ich dachte jetzt so: […]
Ach, sowas dachtest du. Durchaus möglich, dass es stimmt. Hab grad nicht die Muße, das nachzurechnen. Wozu auch?
Tip: Arbeite immer auf Zeichen-Ebene; niemals auf Byte-Ebene. Letztere ist irrelevant; es ist lediglich auf richtige Angabe der Zeichencodierung zu achten.
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.-
Hallo Gunnar,
Tip: Arbeite immer auf Zeichen-Ebene; niemals auf Byte-Ebene. Letztere ist irrelevant;
nur für die Konsumenten von Fertiggerichten. ;-)
Für die Köch^WProgrammierer ist dagegen die "Byte-Ebene", wie du sie so schön nennst, unbedingt relevant!es ist lediglich auf richtige Angabe der Zeichencodierung zu achten.
Die ist natürlich unabdingbar, vor allem wenn man etwas so Kompliziertes wie UTF-8 servieren möchte.
Schönen Abend noch,
Martin--
Mir geht es gut. Ich mag die kleinen Pillen, die sie mir dauernd geben.
Aber warum bin ich ans Bett gefesselt?-
@@Der Martin:
Tip: Arbeite immer auf Zeichen-Ebene; niemals auf Byte-Ebene. Letztere ist irrelevant;
nur für die Konsumenten von Fertiggerichten. ;-)
Für die Köch^WProgrammierer ist dagegen die "Byte-Ebene", wie du sie so schön nennst, unbedingt relevant!Warum sollte? Von Schichtenarchitektur hast du doch schon gehört?
Die Byte-Ebene ist dann relevant, wenn man die Schnittstelle zwischen beiden Schichten implementiert, danach nicht mehr ...
Die ist natürlich unabdingbar, vor allem wenn man etwas so Kompliziertes wie UTF-8 servieren möchte.
... und wenn sie einmal fertig ist, ist auch egal, wie (ob?) kompliziert die Schnittstelle erscheinen mag.
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.
-
-
-
-
-
-
-