encoding-Deklaration für Teilbereich
luti
- html
Hallo,
eine kurze Frage, auf die ich leider keine Antwort finden konnte ...
Ich möchte einen bestimmten Textblock (einen DIV) als UFT-8 ausweisen, der Rest der Webseite sollte davon nicht betroffen sein. wie mache ich das?
Hintergrund ist folgender: Ich möchte für eine Webseite anderen Webmastern anbiete, diesen DIV auf deren Seite einzubinden (mittels iFrame und PHP). Für die iFrame-Lösung bietet es sich ja an, das encoding in den iFrame zu schreiben (<iframe ... encoding="utf-8">
). Aber bei einem include() funktioniert das nicht. Wie mache ich es dort?
Ist so etwas erlaubt? <div encoding="uft-8"></div>
Dank & Gruß,
luti
Hallo,
eine kurze Frage, auf die ich leider keine Antwort finden konnte ...
doch, ich hätte eine, aber sie wird dir nicht gefallen ...
Ich möchte einen bestimmten Textblock (einen DIV) als UFT-8 ausweisen, der Rest der Webseite sollte davon nicht betroffen sein. wie mache ich das?
Gar nicht. Die Textcodierung gilt immer für das *gesamte* Dokument. Abschnittsweise ändern geht nicht.
Hintergrund ist folgender: Ich möchte für eine Webseite anderen Webmastern anbiete, diesen DIV auf deren Seite einzubinden (mittels iFrame und PHP).
Ein iframe lädt ein unabhängiges, eigenständiges Dokument, das auch ein eigenes Encoding haben kann. Das hat aber mit dem gruppierenden Element <div> nichts zu tun.
Für die iFrame-Lösung bietet es sich ja an, das encoding in den iFrame zu schreiben (
<iframe ... encoding="utf-8">
).
Das ist Unsinn - das Encoding muss im HTTP-Header des im iframe geladenen Dokuments mitgeteilt werden, ersatzweise in einem meta-Element *innerhalb* des Dokuments im iframe.
Ist so etwas erlaubt?
<div encoding="uft-8"></div>
Es ist weder gültiges HTML, noch ergibt es einen Sinn.
So long,
Martin
PS: Es heißt UTF, nicht UFT.
Hi,
Ich möchte einen bestimmten Textblock (einen DIV) als UFT-8 ausweisen, der Rest der Webseite sollte davon nicht betroffen sein. wie mache ich das?
Gar nicht.
*Ein* Dokument liegt in *einer* Kodierung vor.
Hintergrund ist folgender: Ich möchte für eine Webseite anderen Webmastern anbiete, diesen DIV auf deren Seite einzubinden (mittels iFrame und PHP). Für die iFrame-Lösung bietet es sich ja an, das encoding in den iFrame zu schreiben (
<iframe ... encoding="utf-8">
).
Wie kommst du denn auf die Idee, dass es eine solche Möglichkeit gäbe, die Kodierung eines Dokumentes in einem Iframe anzugeben?
Das ist ja schon deshalb unsinnig, weil es nicht mehr zutrifft, sobald das Dokument im Iframe auf ein weiteres verweist, welches in einer anderen Kodierung vorliegt.
Das Dokument selber sagt, in welcher Kodierung es vorliegt.
Aber bei einem include() funktioniert das nicht. Wie mache ich es dort?
Wenn du wirklich Leute findest, die so leichtsinnig sein sollten, externe Ressourcen per Include einzubinden - dann kannst du entweder mit einer "friss oder stirb"-Mentalität sagen, das gibt es in UTF-8 und basta (dann könnte zur Not der Empfänger selber umkodieren, wenn er eine andere Möglichkeit des Abrufs als das extrem leichtsinnige include nutzt); oder du erlaubst die Angabe einer gewünschten Kodierung über einen GET-Parameter, den dein Script auswertet, und daraufhin ggf. eine Umkodierung vornimmt, bevor es die Daten ausliefert. (Dass das verlustbehaftet sein kann, ist hoffentlich klar.)
Ist so etwas erlaubt?
<div encoding="uft-8"></div>
Nein, genauso wenig wie beim Iframe.
MfG ChrisB
Hallo,
danke für die deutlichen Antworten ;)
Mit der Einbindung per include() hatte ich wohl etwas kurz gedacht ... Zumal mein Server das standardmäßig gar nicht erlaubt. Ist also ad acta gelegt.
Ok, ich hatte das mit den iFrames wohl noch nicht so ganz verstanden. Da werden also eigenständige, komplette Webseiten oder andere Resourcen eingebunden (ich dachte bisher das wären nur Blöcke ...). Dann ist die Sache natürlich einfach und klar. Das einzubindende Objekt wird einfach als UFT-8 deklariert, fertig.
Dank & Gruß,
luti
Hi!
danke für die deutlichen Antworten ;)
<div encoding="Y">foobar</div>
X.................Y.....??????
Du musst dir nur mal vorstellen, wie das beim Lesen funktionieren soll. Das Dokument selbst ist in Kodierung X verfasst. Dann steht da mitten im Text, dass etwas in Kodierung Y folge. Soweit noch kein Problem. Doch jetzt stell dir mal die Frage, woran nun ein Lesender (immer als Programm gemeint) erkennt, dass das Einfügsel in der anderen Kodierung endet? Folgt nun plötzlich wieder X-Kodierung? Woran erkennt das der Leser? Wie unterscheidet er, ob das noch Y ist oder schon wieder X? Muss der Dekodiermechanismus Kenntnis vom Sinn des Inhalts haben, um ihn richtig dekodieren zu können? Oder steht die Endemarkierung noch in Y? Was machen Client-Systeme, die Y nicht interpretieren können? Unter HTML ist es üblich, dass nicht bekannte Elemente ignoriert werden dürfen. Das muss auch für Kodierungen gelten, mit denen ein Leser nicht umgehen kann. Wenn er aber nicht weiß, wo der Inhalt endet?
Das Ganze muss übrigens für beliebige Kodierungen funktionieren, nicht nur für die von ASCII abstammenden.
Lo!
Moin!
Hintergrund ist folgender: Ich möchte für eine Webseite anderen Webmastern anbiete, diesen DIV auf deren Seite einzubinden (mittels iFrame und PHP). Für die iFrame-Lösung bietet es sich ja an, das encoding in den iFrame zu schreiben (
<iframe ... encoding="utf-8">
). Aber bei einem include() funktioniert das nicht. Wie mache ich es dort?
Die einzige Chance, universell einbindbaren HTML-Code unabhängig von irgendeinem Encoding zu produzieren, ist durch Verwendung von reinem ASCII-Ending kombiniert mit Entities bzw. numerischen Zeichenreferenzen für sämtliche Zeichen außerhalb von ASCII (also alles mit Unicode-Codepoints größer als 127).
Die numerischen Zeichenreferenzen sind immer der Unicode-Codepoint des jeweiligen Zeichens, und die Entities werden aufgrund der verwendeten DTD in die passenden Zeichen aufgelöst. Beide Verfahrensweisen sind äquivalent nutzbar und kompatibel mit sämtlichen Clients.
In PHP würde sich htmlentities() anbieten - du musst zwingend den Parameter für das Encoding mit angeben, sonst kriegst du Müll, wenn dein String nicht ISO-8859-1 enthält, aber ich würde den Encoding-Parameter grundsätzlich verwenden.
- Sven Rautenberg