[ChrisKam]

[JohnnyCage]

Ich versteh das Problem nicht. Ich kenne kaum einen einfacheren Zusammenhang.
Code->Zeichenkodierungsspezifikation->Zeichen.

Wenn euch irgendwas daran stört oder Probleme bereitet sind die Anlaufstellen die Zeichen und die Zeichenkodierungsspezifikation und nicht die schicken Knöpfchen in euren Browsern.

Es wurde eigentlich alles auf den ersten beiden Seiten gesagt. Über eure Browser-UIs philosophieren könnt ihr doch auch woanders.

[JohnnyCage]

[JohnnyCage]

[bacon]

Hier werden zwei Dinge durcheinandergeworfen. Die Renderengine des Browsers "ändert" respektive bereinigt natürlich den gelieferten HTML-Quellcode, heraus kommt der DOM-Tree, die interne Repräsentation des gelieferten Codes. Der DOM-Tree ist aber wiederum kein "HTML", sondern ein sogenannter "Abstract Syntax Tree" (AST), eine abstrakte Repräsentation der HTML-(oder XML-)Quelle. Das betrifft meines Wissens nach aber "nur" den Code, also das HTML, ausgenommen der mitgelieferten Inhalte (Text).

Laienhaft erklärt:
Zur Darstellung zweier Zeichen anstatt einer. Ein Zeichen (ein "a" oder auch eine Ziffer, "1"), wird in einem Byte codiert, das sind 8 bit (00000000 - 11111111). Das ermöglicht prinzipiell die Darstellung von 256 unterschiedlichen Zeichen, Ziffern und Steuersymbolen (Tab, Enter): 0000 = 0, 1111 = 1+2+4+8+16+32+64+128 = 255; 0..255 <=> 256 Möglichkeiten.

(fast) jeder Nummer zwischen 0 und 255 wird nun ein Zeichen zugeordnet.

Das ist nur eine Konvention (nennt man dann "Kodierung"), einfache 1-Byte-Kodierungen ist bspw. ASCII.

Da das aber nicht ausreicht, um länderspezifische Sonderzeichen wie bspw. ein "ä" darzustellen, nimmt man pro Zeichen einfach ein oder mehrere "Octets" also Bytes (das sind jeweils Abfolgen von 8 bit) dazu. UTF-8 nutzt bspw. bis zu 4 Byte und ist ASCII-abwärtskompatibel.

So kann nun nicht mehr nur jeder Nummer zwischen 0 und 255 ein Zeichen zugeordnet werden, sondern jeder Nummer zwischen 0 und 65535, wenn man nur ein zusätzliches Byte nutzt.

Jeder UTF-8-Fähige Browser stellt nun, sobald ein Dokument mit der entsprechenden Information "das ist ein UTF-8-Codiertes Dokument" geliefert wird, 2Byte-Zeichen eben als ein Zeichen dar, einfache ein-Byte-ASCII-Zeichen weiterhin ebenfalls als "normales" Zeichen dar. D.h., für die "normalen" Zeichen ist weiterhin nur ein Byte erforderlich.

Ist die Software NICHT UTF-8-fähig, oder der Zeichensatz unterstützt die 2-Byte-Zeichen nicht, oder aber sogar die Seite wurde nicht mit einem entsprechenden UTF-8-Header oder BOM ausgeliefert, werden 2-Byte Zeichen eben als das dargestellt, was der Browser interpretiert: Als 2 "falsch" codierte 1-Byte-Zeichen.

[JohnnyCage]

Der erste Part ist super und sollte ChrisKam ein wenig auf die Sprünge helfen können, der zweite geht aber, wobei das natürlich auch alles korrekt ist, am TE-Topic vorbei.

Es sind ganz einfach zwei Zeichen, ein Basiszeichen und ein Combining-Zeichen, welche in manchen Browser-Schriftkombinationen falsch dargestellt werden. Das es falsch dargestellt wird liegt mit Sicherheit an der Schriftdatei.

Combining-Zeichen sind Zeichen die mit ihrem Vorgänger kombiniert werden. Man kann z.B. über ein u ein ^ stellen. Oder eine Tilde. Oder beides. Oder eben ein Doppelpunkt über ein a damit daraus ein ä wird.

Es gibt aber für manche Kombinationen auch die Precomposed-Zeichen, als eigenes Zeichen. Wie eben das ä. In dieser Form als Precomposed-Zeichen wird das ä auch korrekt dargestellt während gleichzeitig das ä als Kombination aus Basis-Zeichen und Combining-Zeichen falsch dargestellt wird.

[bacon]

Du gibst dem Kind nur n anderen Namen: http://de.wikipedia.org/wiki/Diakritisches_Zeichen#Unicode
Unterm Strich () sind auch das zwei Oktette hintereinander.

Du hast insofern Recht, dass das Problem sicher im unterstützenden Schriftsatz zu suchen ist, die Ursache allerdings ist letztlich eine falsche Codieren. Wenn direkt auf den passenden Unicode des Zeichens "ä" zurückgegriffen würde, könnte man den Schlamassel vermeiden.

[JohnnyCage]