Unicode Darstellung von Webpages

[Markus Dillander]

Hi

Ich moechte meine Webpage mit Unicode UTF-8 codieren. Damit nun mein Browser die korrekte Codierung erkennt fuege ich folgenden Metatag in der Header Datei hinzu:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Das funktioniert soweit ganz gut bei IE und FFox, bei Opera bleibt jedoch die Auswahl weiterhin auf view->enconding->automatic selection. Wieso ist hier der hacken nicht bei UTF-8 gesetzt?

Und meine zweite Frage: Ich benutze Dreamweaver MX2004 fuer die Seitengestaltung. Laut

http://tlt.its.psu.edu/suggestions/international/web/tips/dreamweaver.html

ist eine Option man benutzt Windows Notepage, speichert die Textdatei als UTF-8 codierung und kopiert dann den Inhalt einfach in die Dreamweaver Datei und man hat die gewuenschte UTF-8 Codierung. Klingt fuer mich alles ein bisschen zu einfach. Haut das wirklich ohne Probleme so hin? Gibt es andere Wege mit Dreamweaver UTF-8 codierte wegpages zu gestalten?

Gruss
Markus

[Der Martin]

Hallo Markus,

Ich moechte meine Webpage mit Unicode UTF-8 codieren. Damit nun mein Browser die korrekte Codierung erkennt fuege ich folgenden Metatag in der Header Datei hinzu:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Das ist in Ordnung. Wichtig ist aber auch, dass dein Server die Ressource dann auch als utf-8 ausliefert, denn die Angabe im HTTP-Header hat Vorrang. Heißt: Auch im HTTP-Header muss der obige Content-Type inclusive Charset angegeben werden.

Das funktioniert soweit ganz gut bei IE und FFox, bei Opera bleibt jedoch die Auswahl weiterhin auf view->enconding->automatic selection.

Ich vermute, dass dein Server die Ressource in Wirklichkeit mit einem anderen Charset ausliefert, ich tippe auf iso-8859-1. Dass der IE sich nicht so pingelig an die Vorgaben hält und die Parameter lieber selbst errät (in diesem Fall sogar richtig rät), ist bekannt; vom Firefox hätte ich ein solches Verhalten allerdings nicht erwartet.
Gib doch mal eine URL an, damit man sich das "live" ansehen kann.

So long,

Martin

[Naseweis]

Hallo,

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Das ist in Ordnung. Wichtig ist aber auch, dass dein Server die Ressource dann auch als utf-8 ausliefert, denn die Angabe im HTTP-Header hat Vorrang. Heißt: Auch im HTTP-Header muss der obige Content-Type inclusive Charset angegeben werden.

das ist aber nicht so ganz sinnvoll. Der Hinweis ist schon korrekt, aber entweder gibt er die Kodierung mit HTTP an oder er benutzt die meta-Zeile, aber nicht beides. Doppelte Angaben bringen nichts außer Verwirrung.

Das funktioniert soweit ganz gut bei IE und FFox, bei Opera bleibt jedoch die Auswahl weiterhin auf view->enconding->automatic selection.

Ich vermute, dass dein Server die Ressource in Wirklichkeit mit einem anderen Charset ausliefert, ich tippe auf iso-8859-1.

Nein, warum sollte der Haken (Hacken sind was anderes, Markus :-) bei iso-8859-1 auf Automatik stehen bleiben, wenn ihr doch erwartet, dass er bei utf-8 auf utf-8 springt? Wenn überhaupt, dann dürfte Opera überhaupt keine Zeichenkodierung erkannt haben. Das kann aber nicht sein, weil Markus' meta-Zeile korrekt vorhanden ist.

Also eine andere Erklärung: Wer mal ein Auto mit Automatikgetriebe gefahren ist, weiß, dass der Schaltknüppel da auch nicht bei jedem Gangwechsel des Getriebes hin und her wackelt. Genauso beim Opera-Menü, es dient zur Einstellung, nicht zur Anzeige (ja, Firefox verhält sich anders, nein, ich finde das Verhalten von Firefox nicht sinnvoll).

Die Vermutung bestätigt sich, lädt man mit Opera diese, mit utf-8 kodierten Forumsseiten. Das Menü zeigt weiterhin "Automatik" und die Nicht-ASCII-Zeichen werden trotzdem korrekt angezeigt. Markus kann das analog mit seinen eigenen Seiten ausprobieren, einfach eine eigene Seiten mit definitiv utf-8-kodierten deutschen Umlauten laden. Wenn's nicht passt, erscheinen statt eines Umlauts garantiert zwei merkwürdige Zeichen, Verwechslungen wie bei iso-8859-1 / windows-1252 sind ausgeschlossen.

Einen schönen Abend, Naseweis.

[Der Martin]

Hallo Naseweis,

das ist aber nicht so ganz sinnvoll. Der Hinweis ist schon korrekt, aber entweder gibt er die Kodierung mit HTTP an oder er benutzt die meta-Zeile, aber nicht beides.

Doch, es ist sogar die Regel. Ein HTTP-Server gibt normalerweise im Response-Header einen Content-Type an, und dazu gehört auch das dazu passende Charset.
Nur wenn der HTTP-Kontext nicht gegeben ist, z.B. weil die Seite mit einem anderen Protokoll übertragen oder von der lokalen Platte geladen wird, sollte die META-Angabe zum Zug kommen. Sozusagen als Fallback, wenn keine andere Information verfügbar ist.

Doppelte Angaben bringen nichts außer Verwirrung.

Ja klar - und genau die haben wir schon.  ;-)

Nein, warum sollte der Haken (Hacken sind was anderes, Markus :-) bei iso-8859-1 auf Automatik stehen bleiben, wenn ihr doch erwartet, dass er bei utf-8 auf utf-8 springt? Wenn überhaupt, dann dürfte Opera überhaupt keine Zeichenkodierung erkannt haben. Das kann aber nicht sein, weil Markus' meta-Zeile korrekt vorhanden ist.

Sie wird aber ignoriert, wenn -was ich voraussetzen muss- der Server im HTTP-Dialog einen Content-Type angibt. Unicode hat sich noch nicht wirklich auf breiter Front durchgesetzt, und ein Großteil der Webserver benutzen immer noch iso-8859-1 (oder gar windows-1252) als Defaulteinstellung.

So long,

Martin

[Ashura]

Hallo Martin.

Unicode hat sich noch nicht wirklich auf breiter Front durchgesetzt,

Ich denke schon. Alles ist Unicode.

und ein Großteil der Webserver benutzen immer noch iso-8859-1 (oder gar windows-1252) als Defaulteinstellung.

Was ebenfalls Unicode ist. Meinst du UTF-(8|16|32)?

Einen schönen Donnerstag noch.

Gruß, Ashura

[Markus Dillander]

Hallo alle zusammen

Danke fuer die unzaehligen Antworten. Also zusammenfassend kann gesagt werden dass Opera das Metatag korrekt interpretiert, jedoch dieses vom HTTP Content Header ueberschrieben wird. Soweit sogut!

Was nun fuer mich aber noch sehr interessant waere: Ein eleganter Weg meinen Text UTF-8 zu codieren ;) Das mit dem Notepad in UTF abspeichern und dann in den Dreamweaver zu kopieren klingt doch nicht so vertrauenswuerdig ;)

Gruss
Markus

[Jens Holzkämper]

Tach,

Was nun fuer mich aber noch sehr interessant waere: Ein eleganter Weg meinen Text UTF-8 zu codieren ;) Das mit dem Notepad in UTF abspeichern und dann in den Dreamweaver zu kopieren klingt doch nicht so vertrauenswuerdig ;)

der eleganteste Weg ist sicherlich gleich einen Editor zu nutzen, der UTF-8 kann.

mfg
Woodfighter

[Naseweis]

Hallo,

das ist aber nicht so ganz sinnvoll. Der Hinweis ist schon korrekt, aber entweder gibt er die Kodierung mit HTTP an oder er benutzt die meta-Zeile, aber nicht beides.

Doch, es ist sogar die Regel.

Schön blöd,...

Doppelte Angaben bringen nichts außer Verwirrung.

Ja klar - und genau die haben wir schon.  ;-)

...wie man sieht :-) Also ich empfehle generell, nur die meta-Zeile zu benutzen, weil die Angabe per HTTP beim Abspeichern auf der Festplatte verloren geht (schriebst du ja bereits). Ist es aber per meta geregelt, braucht man die HTTP-Angabe nicht mehr (zur Zeichenkodierung, der Inhaltstyp steht nicht zur Debatte).

Nein, warum sollte der Haken (Hacken sind was anderes, Markus :-) bei iso-8859-1 auf Automatik stehen bleiben, wenn ihr doch erwartet, dass er bei utf-8 auf utf-8 springt? Wenn überhaupt, dann dürfte Opera überhaupt keine Zeichenkodierung erkannt haben. Das kann aber nicht sein, weil Markus' meta-Zeile korrekt vorhanden ist.

Sie wird aber ignoriert, wenn -was ich voraussetzen muss- der Server im HTTP-Dialog einen Content-Type angibt.

Das ist richtig, aber das ist nicht sein Problem :-) Er hat nur gefragt, warum sein Opera-Menü Automatik statt utf-8 anzeigt. Das kann nichts mit dem Überschreiben der meta-Angabe utf-8 durch HTTP iso-8859-1 zu tun haben, denn dann würde im Menü iso-8859-1 statt Automatik stehen. Tut's aber nicht, also ist es normal, das Opera im Menü immer die vom Browsernutzer gewählte Option anzeigt (in diesem Fall Automatik) und nicht die vom Browser erkannte Kodierung.

Dass die Schriftzeichen falsch angezeigt werden, was in deinem Szenario sich widersprechender HTTP- und Meta-Angaben der Fall sein müsste, hat er nicht gesagt (noch nicht, aber da es beim IE und Firefox funktioniert, wird er es auch nicht).

Lieben Gruß, Naseweis

[Markus Dillander]

Hallo alle zusammen

Danke fuer die unzaehligen Antworten. Also zusammenfassend kann gesagt werden dass Opera das Metatag korrekt interpretiert, jedoch dieses vom HTTP Content Header ueberschrieben wird. Soweit sogut!

Was nun fuer mich aber noch sehr interessant waere: Ein eleganter Weg meinen Text UTF-8 zu codieren ;) Das mit dem Notepad in UTF abspeichern und dann in den Dreamweaver zu kopieren klingt doch nicht so vertrauenswuerdig ;)

Gruss
Markus

[wahsaga]

hi,

das ist aber nicht so ganz sinnvoll. Der Hinweis ist schon korrekt, aber entweder gibt er die Kodierung mit HTTP an oder er benutzt die meta-Zeile, aber nicht beides. Doppelte Angaben bringen nichts außer Verwirrung.

so ein quark.
es wird ausdrücklich empfohlen, beide angaben zu machen.
außerdem _muss_ er eine vom server idR. per default gemachte, anderslautende angabe überschreiben - ansonsten hat diese vorrang.

Das funktioniert soweit ganz gut bei IE und FFox, bei Opera bleibt jedoch die Auswahl weiterhin auf view->enconding->automatic selection.

warum sollte der haken überhaupt irgendwo "hinspringen"?

automatik heißt nun mal, wähle automatisch - bspw. an hand von angabe im response header oder meta-tag.

wenn man den haken irgendwo anders hinsetzt, dann heißt das im gegenteil: egal was server und meta-tag sagen - interpretiere die daten in der gewählten codierung.

Also eine andere Erklärung: Wer mal ein Auto mit Automatikgetriebe gefahren ist, weiß, dass der Schaltknüppel da auch nicht bei jedem Gangwechsel des Getriebes hin und her wackelt. Genauso beim Opera-Menü, es dient zur Einstellung, nicht zur Anzeige (ja, Firefox verhält sich anders, nein, ich finde das Verhalten von Firefox nicht sinnvoll).

geanu.

Die Vermutung bestätigt sich, lädt man mit Opera diese, mit utf-8 kodierten Forumsseiten. Das Menü zeigt weiterhin "Automatik" und die Nicht-ASCII-Zeichen werden trotzdem korrekt angezeigt. Markus kann das analog mit seinen eigenen Seiten ausprobieren, einfach eine eigene Seiten mit definitiv utf-8-kodierten deutschen Umlauten laden. Wenn's nicht passt, erscheinen statt eines Umlauts garantiert zwei merkwürdige Zeichen, Verwechslungen wie bei iso-8859-1 / windows-1252 sind ausgeschlossen.

und wer's genau wissen will, der schaut ins info-panel des opera - dort findet sich nämlich ein punkt "Encoding from server (used by Opera): UTF-8 (UTF-8)"

gruß,
wahsaga

[Ashura]

Hallo wahsaga.

und wer's genau wissen will, der schaut ins info-panel des opera - dort findet sich nämlich ein punkt "Encoding from server (used by Opera): UTF-8 (UTF-8)"

Ich frage mich gerade, warum die Kodierung hier immer zwei Mal aufgeführt wird...

Einen schönen Donnerstag noch.

Gruß, Ashura

[Der Martin]

Hallo,

"Encoding from server (used by Opera): UTF-8 (UTF-8)"
Ich frage mich gerade, warum die Kodierung hier immer zwei Mal aufgeführt wird...

Steht doch da: Einmal das, was der Server behauptet, (und dann das, was Opera -ggf. per Manual Override- tatsächlich benutzt).

Jetzt klar?
So long,

Martin

[Ashura]

Hallo Martin.

"Encoding from server (used by Opera): UTF-8 (UTF-8)"
Ich frage mich gerade, warum die Kodierung hier immer zwei Mal aufgeführt wird...

Steht doch da: Einmal das, was der Server behauptet, (und dann das, was Opera -ggf. per Manual Override- tatsächlich benutzt).

Damit würde das (bei mir) stehende „Angegebene Kodierung (von Opera verwendet)“ und obiges überhaupt erst ein Mal einen Sinn ergeben, du hast Recht.

Jetzt klar?

Ja, ich danke dir für die Entfernung der hölzernen Denkblockade.

Einen schönen Donnerstag noch.

Gruß, Ashura

[MudGuard]

Hi,

und wer's genau wissen will, der schaut ins info-panel des opera - dort findet sich nämlich ein punkt "Encoding from server (used by Opera): UTF-8 (UTF-8)"

Ich frage mich gerade, warum die Kodierung hier immer zwei Mal aufgeführt wird...

Steht doch drüber:

Encoding from server (used by Opera):
ISO-8859-1 (windows-1252)

Das eine ist das, was vom Server kommt, und das andere (in Klammern) das, was Opera tatsächlich nutzt.

(frag mich nicht, warum er bei meiner Testseite was anderes als vom Server vorgegeben benutzt - selbst wenn ich explizit statt Automatic auf ISO-8859-1 schalte, bleibt es bei obiger Anzeige, bei Umschaltung auf ISO-8859-2 schreibt er auch ISO-8859-2 in die Klammer)
Seltsamer Browser ...

cu,
Andreas

[Gunnar Bittersmann]

Encoding from server (used by Opera):
ISO-8859-1 (windows-1252)
Das eine ist das, was vom Server kommt, und das andere (in Klammern) das, was Opera tatsächlich nutzt.
(frag mich nicht, warum er bei meiner Testseite was anderes als vom Server vorgegeben benutzt - selbst wenn ich explizit statt Automatic auf ISO-8859-1 schalte, bleibt es bei obiger Anzeige, bei Umschaltung auf ISO-8859-2 schreibt er auch ISO-8859-2 in die Klammer)
Seltsamer Browser ...

MudGuard,
Fehlertoleranz, schätze ich. Da haben die Opera-Entwickler berücksichtigt, dass Webseitenersteller unter Windows Zeichen aus dem Bereich von x80 bis x9F („“–…) verwenden könnten und den Quelltext windows-1252-codiert (was im Editor als „ANSI“ bezeichnet wird) abspeichern – in dem Irrglauben, sie würden ISO 8859-1 verwenden.

In einem wirklich in ISO 8859-1 codierten Dokument dürften keine Oktetts aus dem Bereich von x80 bis x9F (Steuerzeichen) auftreten. Taucht in einem (fälschlich) als ISO 8859-1 codiert deklariertem Dokument ein solches Oktett auf, interpretiert Opera dies dennoch als darstellbares Zeichen gemäß windows-1252.

Da ISO 8859-1 und windows-1252 in den Bereichen von 0 bis x7F sowie von xA0 bis xFF identisch sind, spielt es keine Rolle, welche Codierung Opera dort verwendet.

Live long and prosper,
Gunnar

[MudGuard]

Hi,

(frag mich nicht, warum er bei meiner Testseite was anderes als vom Server vorgegeben benutzt - selbst wenn ich explizit statt Automatic auf ISO-8859-1 schalte, bleibt es bei obiger Anzeige, bei Umschaltung auf ISO-8859-2 schreibt er auch ISO-8859-2 in die Klammer)
Seltsamer Browser ...

Fehlertoleranz, schätze ich.

Wenn Opera das bei der Einstellung "Automatic" macht, ist das eine Sache.
Bei manueller Auswahl der zu verwendenden Kodierung ist das aber eine ganz andere Sache.

Wenn ich als Nutzer ausdrücklich ISO-8859-1 einstelle, dann will ich nicht Windows-1252 haben. Denn wenn ich Windows-1252 haben wollte, würde ich das ja ebenfalls auswählbare Windows-1252 auswählen.
Wofür läßt mir Opera die Auswahl zwischen ISO-8859-1 und Windows-1252 (und weiteren), wenn er dann meine Wahl doch ignoriert?

Entweder halten die Opera-Programmierer die Browser-Benutzer für zu dumm, den Unterschied zu kennen, oder sie geben einen Scheiß darauf, was der User will.
Beides spricht nicht gerade für die Opera-Programmierer.

cu,
Andreas

[Sven Rautenberg]

Moin!

Wenn ich als Nutzer ausdrücklich ISO-8859-1 einstelle, dann will ich nicht Windows-1252 haben. Denn wenn ich Windows-1252 haben wollte, würde ich das ja ebenfalls auswählbare Windows-1252 auswählen.
Wofür läßt mir Opera die Auswahl zwischen ISO-8859-1 und Windows-1252 (und weiteren), wenn er dann meine Wahl doch ignoriert?

Kannst du beweisen, dass Opera die Auswahl ignoriert? Also nicht nur anhand dieser Anzeige vermuten, dass Opera die eingehenden Bytes direkt als Windows-1252 interpretiert, sondern dafür auch Belege bringen?

Entweder halten die Opera-Programmierer die Browser-Benutzer für zu dumm, den Unterschied zu kennen, oder sie geben einen Scheiß darauf, was der User will.
Beides spricht nicht gerade für die Opera-Programmierer.

Heftige Anschuldigungen, die du hier auffährst, ohne drüber nachzudenken, was Opera möglicherweise auch machen könnte:

Die Seiten mit ISO-8859-1 werden intern konvertiert zu Windows-1252 und dann dargestellt. Also vollkommen korrekt im Sinne von ISO-8859-1. Denn ich habe es noch nicht erlebt, dass Opera irgendeinen Blödsinn mit ISO-8859-1 gemacht hat.

Mutmaßlich kommen bei Opera verschiedene Routinen je nach Zeichensatz zum Zuge. UTF-8 erfordert zwingend eine etwas umfangreichere Behandlung, da Opera je nach darzustellendem Zeichen einen anderen Zeichensatz zu wählen hat, während beispielsweise bei ISO-8859-1 alle Zeichen auch mit Windows-1252 behandelbar sind, ebenso bei ISO-8859-15, es sich also lohnt, diese Codierungen intern alle umzuwandeln zum umfassenderen Windows-1252, und erst dann die Zeichendarstellungsroutine anzuwerfen.

Nur mal so als Gedankenspiel...

- Sven Rautenberg

[MudGuard]

Hi,

Kannst du beweisen, dass Opera die Auswahl ignoriert? Also nicht nur anhand dieser Anzeige vermuten, dass Opera die eingehenden Bytes direkt als Windows-1252 interpretiert, sondern dafür auch Belege bringen?

Wenn es nur die Anzeige wäre, dann würden die Opera-Programmierer versuchen, mich anzulügen. Auch nicht besser.

cu,
Andreas

[molily]

Hallo,

Kannst du beweisen, dass Opera die Auswahl ignoriert? Also nicht nur anhand dieser Anzeige vermuten, dass Opera die eingehenden Bytes direkt als Windows-1252 interpretiert, sondern dafür auch Belege bringen?

Speichere mal ein Euro-Zeichen Windows-1252-kodiert, stelle Opera auf Latin-1 und öffne das Dokument. Das Euro-Zeichen wird angezeigt.

Die Seiten mit ISO-8859-1 werden intern konvertiert zu Windows-1252 und dann dargestellt. Also vollkommen korrekt im Sinne von ISO-8859-1.

Äh - häh? ;)
Nix korrekt im Sinne von ISO-8859-1. In ISO-8859-1 liegt an der Stelle ein Steuerzeichen, kein Euro-Zeichen. Wenn man Opera absichtlich auf ISO-8859-1 stellt, sollte er diese Zeichen ignorieren.

Denn ich habe es noch nicht erlebt, dass Opera irgendeinen Blödsinn mit ISO-8859-1 gemacht hat.

Aber ja doch. Opera interpretiert die Zeichen 0x80 bis 0x9F immer als Zeichen aus Windows-1252, auch wenn man ausdrücklich irgendeine ISO-Kodierung einstellt. Das geht schon als Blödsinn durch.

Dumm ist das schon: In den Steuerzeichen ist z.B. 0x85, NEL, Next Line. Wird von manchen Systemen als Zeilentrenner benutzt, ähnlich 0x0A Line Feed und 0x0D Carriage Return. Das stellt Opera immer gemäß Windows-1252 als … dar.

(...) während beispielsweise bei ISO-8859-1 alle Zeichen auch mit Windows-1252 behandelbar sind, ebenso bei ISO-8859-15, es sich also lohnt, diese Codierungen intern alle umzuwandeln zum umfassenderen Windows-1252, und erst dann die Zeichendarstellungsroutine anzuwerfen.

Naja, nee. ISO-8859-1 und ISO-8859-15 lassen sich meines Wissens schon verlustlos in Windows-1252 transkodieren. Die anderen ISO-Kodierungen haben aber mit Windows-1252 nicht viel gemeinsam, also erklärt das nicht Operas generellen Umgang mit den Oktetts 0x80 bis 0x9F. Ich nehme mal an, bei allen 8-Bit-Kodierungen, bei denen diese Oktetts als Steuerzeichen definiert sind, werden sie als Windows-1252 dekodiert.

Intern verwendet Opera wahrscheinlich sowieso eher UTF-32 oder ähnliches, ich denke nicht, dass Opera 8-Bit-Kodierungen zu anderen 8-Bit-Kodierungen transkodiert.

Mathias

[Gunnar Bittersmann]

Speichere mal ein Euro-Zeichen Windows-1252-kodiert, stelle Opera auf Latin-1 und öffne das Dokument. Das Euro-Zeichen wird angezeigt.

Hi molily,
Ich schätze, Opera behandelt windows-1252 und ISO 8859-1 völlig gleich. Aus Gründen, die ich in https://forum.selfhtml.org/?t=114465&m=730082 versucht habe darzustellen. Warum sollte Opera da auch unterscheiden?

Dumm ist das schon: In den Steuerzeichen ist z.B. 0x85, NEL, Next Line. Wird von manchen Systemen als Zeilentrenner benutzt, ähnlich 0x0A Line Feed und 0x0D Carriage Return.

Äh, in https://forum.selfhtml.org/?t=114465&m=730139 sagtest du doch gerade noch: „U+0080 bis U+009F dürfen in keinem HTML-Dokument vorkommen“.

Live long and prosper,
Gunnar

[molily]

Hallo,

Dumm ist das schon: In den Steuerzeichen ist z.B. 0x85, NEL, Next Line. Wird von manchen Systemen als Zeilentrenner benutzt, ähnlich 0x0A Line Feed und 0x0D Carriage Return.

Äh, in https://forum.selfhtml.org/?t=114465&m=730139 sagtest du doch gerade noch: „U+0080 bis U+009F dürfen in keinem HTML-Dokument vorkommen“.

Stimmt, ich habe damit auf XML angespielt (insbesondere XML 1.1, wo NEL ein offizielles Zeilenendezeichen ist), also XHTML-Dokumente.

Mathias

[molily]

Hallo,

kleine Ergänzung:

(...) In einem wirklich in ISO 8859-1 codierten Dokument dürften keine Oktetts aus dem Bereich von x80 bis x9F (Steuerzeichen) auftreten.

Naja, was heißt »dürfen nicht«? Sie dürfen nicht, weil es die SGML-Deklaration für HTML mit DESCSET (...) 128 32 UNUSED verbietet. Das heißt, U+0080 bis U+009F dürfen in keinem HTML-Dokument vorkommen, ganz gleich in welcher Kodierung.
In einem Windows-1252-kodierten Dokument werden andere Unicode-Zeichen mit 0x80 bis 0x9F kodiert, daher lässt sich Windows 1252 prinzipiell in HTML-Dokumenten nutzen.
In XML/XHTML darf man auch Windows-1252 verwenden, die Steuerzeichen aus ISO 8859-1 ebenfalls, auch wenn sie abgesehen von U+0085 zu den nicht empfohlenen Zeichen gehören.

Mathias

[Twilo]

Hallo,

und wer's genau wissen will, der schaut ins info-panel des opera - dort findet sich nämlich ein punkt "Encoding from server (used by Opera): UTF-8 (UTF-8)"

Ich frage mich gerade, warum die Kodierung hier immer zwei Mal aufgeführt wird...

weil auch mal sowas bei rauskommt

Serverseitig angegebene Kodierung (von Opera verwendet):
iso-8859-1 (windows-1252)

mfg
Twilo

[Der Martin]

Hallo wahsaga,

außerdem _muss_ er eine vom server idR. per default gemachte, anderslautende angabe überschreiben - ansonsten hat diese vorrang.

dann habe ich also in diesem Beitrag Unsinn verzapft:

[...] denn die Angabe im HTTP-Header hat Vorrang.

Da muss ich mich doch nochmal informieren, denn für mich klingen beide Darstellungen plausibel.

Ciao,

Martin

[wahsaga]

hi,

dann habe ich also in diesem Beitrag Unsinn verzapft:

nein, wieso?

[...] denn die Angabe im HTTP-Header hat Vorrang.

so ist es doch auch.

erst, wenn die angabe vom server komplett fehlt (weil dieser keine sendet, oder auch weil die seite wie schon angesprochen abgespeichert und über's lokale dateisystem geöffnet wird), kommt die meta-angabe zum zuge.
meta-alleine würde also in solchen fällen ggf. auch ausreichen - allerdings sind die meisten webserver derart konfiguriert, dass sie für bestimmte dateitypen per default eine angabe senden - und die müsste dann, wenn anders lautend als die meta-angabe und als die tatsächlich verwendete kodierung, ersetzt werden.

gruß,
wahsaga

[Der Martin]

Hallo,

dann habe ich also in diesem Beitrag Unsinn verzapft:
nein, wieso?

[...] denn die Angabe im HTTP-Header hat Vorrang.

so ist es doch auch.

Dann habe ich dich missverstanden. Ich habe aus deinem vorherigen Posting gelesen, die META-Angabe würde eine anderslautende Angabe vom Server überschreiben. Das war wohl nicht ganz eindeutig formuliert.

erst, wenn die angabe vom server komplett fehlt (weil dieser keine sendet, oder auch weil die seite wie schon angesprochen abgespeichert und über's lokale dateisystem geöffnet wird), kommt die meta-angabe zum zuge.

Das war auch meine Überzeugung - bis du mich eben verunsichert hast. ;-)

[...] per default eine angabe senden - und die müsste dann, wenn anders lautend als die meta-angabe und als die tatsächlich verwendete kodierung, ersetzt werden.

In der Serverkonfiguration (httpd.conf oder .htaccess) ersetzt werden, hast du gemeint?

Ciao,

Martin

[Naseweis]

Hallo,

das ist aber nicht so ganz sinnvoll. Der Hinweis ist schon korrekt, aber entweder gibt er die Kodierung mit HTTP an oder er benutzt die meta-Zeile, aber nicht beides. Doppelte Angaben bringen nichts außer Verwirrung.

so ein quark.

nanana.

es wird ausdrücklich empfohlen, beide angaben zu machen.

Wer ist denn "es" und wo hat "es" das empfohlen?

außerdem _muss_ er eine vom server idR. per default gemachte, anderslautende angabe überschreiben - ansonsten hat diese vorrang.

Es gibt Ausnahmen von der Regel und einen statistischen Nachweis für die Behauptung, dass der Server meistens irgendwas standardmäßig ausspuckt, hast du doch sicher nicht, oder? :-)

Wenn es sich nicht ändern lässt, muss er natürlich die HTTP-Angabe überschreiben (zum Beispiel per htaccess), aber es ist weder gesagt, dass so eine Standardvorgabe immer vorhanden ist, noch, dass sich das nicht ändern ließe.

Netten Gruß und den Quark darfst du erstmal behalten ;-)
Naseweis

[wahsaga]

hi,

es wird ausdrücklich empfohlen, beide angaben zu machen.

Wer ist denn "es" und wo hat "es" das empfohlen?

da steht es wird, nicht es hat.
irgendwie ist es mit deinem sprachverständnis nicht allzu weit her, hm?

Es gibt Ausnahmen von der Regel und einen statistischen Nachweis für die Behauptung, dass der Server meistens irgendwas standardmäßig ausspuckt, hast du doch sicher nicht, oder? :-)

apache als am weitesten verbreiteter webserver, plus kenntnis über dessen defaultkonfiguration bei auslieferung reichen mir zur untermauerung dieser aussage.

gruß,
wahsaga

[Naseweis]

es wird ausdrücklich empfohlen, beide angaben zu machen.

Wer ist denn "es" und wo hat "es" das empfohlen?

da steht es wird, nicht es hat.
irgendwie ist es mit deinem sprachverständnis nicht allzu weit her, hm?

Deines ist offenbar überhaupt nicht vorhanden, ansonsten hättest du meine Frage nach demjenigen, der diese Empfehlung abgibt, verstanden und kurzerhand beantwortet anstatt mit einem thematisch unpassenden und inhaltlich falschen Kommentar deine Dümmlichkeit preiszugeben. Aber du hast Glück, ich bin trollerant und habe einmal herzlich über dich gelacht :-)

Einen dicken Schmatz für dich, mein Schatz!

[Der Martin]

Moin,

Aber du hast Glück, ich bin trollerant und habe einmal herzlich über dich gelacht :-)

^ ?
Ach drum.   -------------------+
Ich hatte nämlich auch schon den Eindruck, es könnte sich um ein Trollposting handeln.

Schönen Tag noch,

Martin

[Orlando]

Hallo Naseweis,

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Wichtig ist aber auch, dass dein Server die Ressource dann auch als utf-8 ausliefert, denn die Angabe im HTTP-Header hat Vorrang. Heißt: Auch im HTTP-Header muss der obige Content-Type inclusive Charset angegeben werden.

das ist aber nicht so ganz sinnvoll. Der Hinweis ist schon korrekt, aber entweder gibt er die Kodierung mit HTTP an oder er benutzt die meta-Zeile, aber nicht beides. Doppelte Angaben bringen nichts außer Verwirrung.

Welcher Server liefert lokal gespeicherte Seiten aus? Keiner. Daher sollte die Meta-Angabe im Dokument stehen, um den Browser nicht wild raten zu lassen.

Specifying the character encoding:

„To sum up, conforming user agents must observe the following priorities
  when determining a document's character encoding (from highest priority
  to lowest):

• An HTTP "charset" parameter in a "Content-Type" field.
  • A META declaration with "http-equiv" set to "Content-Type" and a value
    set for "charset".
  • The charset attribute set on an element that designates an external
    resource.“

Grüße
 Roland