Firefox - Warum werden Seiten beim Speichern verfälscht?

    Firefox - Warum werden Seiten beim Speichern verfälscht?

    Gelegentlich werden HTML-Seiten, die mit der Firefoxfunktion 'Seite speichern unter ...' abgespeichert sind, beim erneuten (Offline-) Aufruf anders angezeigt, z. B. mit verfälschten Umlauten.

    Um die Ursache zu analysieren, habe ich eine solche Seite untersucht.

    Online zeigt der Browser mit der Funktion 'Quelltext' u. a. die folgenden Zeilen (in der Darstellung sind die spitzen Klammern für Tag-Anfang und -Ende durch geschweifte ersetzt, damit die Zeilen unterwegs nicht als HTML-Zeilen interpretiert werden können):

    {meta http-equiv="content-type" content="TEXT/HTML; CHARSET=UTF-8" /}
    {link rel="stylesheet" href="../css/style.css" type="text/css" /}
    {td colspan="3" class="ueberschrift"}Informationen zu einigen Zeichensätzen{/td}

    Für die Seite ist also der Zeichencode UTF-8 vorgesehen (Zeile 1), die Umlaute sind aber in HTML-Code codiert (Zeile 3). Ich denke, dass dies zulässig ist.

    Seite speichern unter ...; Wideraufruf mit Browser, dann zeigt 'Quelltext':

    {meta http-equiv="content-type" content="TEXT/HTML; CHARSET=UTF-8"}
    {link rel="stylesheet" href="zeichensatz-Dateien/style.css" type="text/css"}
    {td colspan="3" class="ueberschrift"}Informationen zu einigen Zeichens?tzen{/td}

    Beim Speichern wurden also verändert:

    - Die Tag-Ende-Codierung von ' />' in '>' (alle Zeilen). Das ist nicht bei allen Versionen zulässig, soll hier aber nicht weiter betrachtet werden, weil es keine erkennbaren Auswirkungen zeigt.

    - Der link für die zur Seite gehörenden Dateien ist verändert (Zeile 2). Das ist notwendig, damit diese Dateien beim Aufruf der gespeicherten Seite wieder (im dafür eingerichteten Verzeichnis) gefunden werden.

    - Die HTML-Umlautcodierung ist geändert, dort steht jetzt ein Fragezeichen (Zeile 3). Mit DEBUG nachgesehen steht jetzt für ä Code E4. Das ist die Codierung nach ANSI (Code Page 1252).

    Diese Änderung führt nun dazu, dass die Darstellung beim erneuten Aufruf falsch wird! Der Browser verwendet für die Decodierung UTF-8 (nach Zeile 1) und da hat Code E4 keine Bedeutung, was durch ein Fragezeichen dargestellt wird 'Zeichens?tze'. Das ist ebenso bei der Anzeige des Quelltextes. (Beim Aufruf mit dem HTML-Editor Phase 5 steht dort wieder ein ä, dieser beachtet also bei der Ausgabe des Quelltextes die Code-Vorschrift UTF-8 nicht.)

    So stellt sich die Frage, warum Firefox die Codierung beim 'Seite speichern unter ...' verändert?

    Allgemeiner gefragt: Wie gehen Browser und HTML-Editoren mit den Zeichencodierungen um?

    Und spezieller gefragt: Gibt es eine Methode zum Speichern ganzer HTML-Seiten, die in dieser Hinsicht fehlerfrei ist?

    Anmerkung 1: Ich meine hier nicht das Speichern ganzer Websites wie z. B. mit HTTrack, sondern das Speichern einer HTML-Seite, d. h. einer HTML-Datei zusammen mit den unmittelbar in der Seite wirksamen 'gelinkten' Dateien. (Leider werden dabei gelegentlich auch die 'externen', nur außerhalb der Seite wirksamen links mit geändert.)

    Anmerkung 2: Ein weiteres, ebenso interessantes Thema wäre die Frage nach einer originären Abspeicherung von HTML-Seiten mit externer CSS-Formatierung. Bei derartigen Seiten wird oft die Formatierung nicht mit gespeichert, was zu einer sehr schlechten Darstellung führt. Man vergleiche hierzu z. B. die Darstellung einer Wikipedia-Seite bei Offline-Aufruf aus dem gespeicherten Zustand.

    Dieter Oechsle

    Dieter Oechsle wrote:

    Zitat

    Und spezieller gefragt: Gibt es eine Methode zum Speichern ganzer HTML-Seiten, die in dieser Hinsicht fehlerfrei ist?

    Anmerkung 1: Ich meine hier nicht das Speichern ganzer Websites wie z. B. mit HTTrack, sondern das Speichern einer HTML-Seite, d. h. einer HTML-Datei zusammen mit den unmittelbar in der Seite wirksamen 'gelinkten' Dateien. (Leider werden dabei gelegentlich auch die 'externen', nur außerhalb der Seite wirksamen links mit geändert.)

    Wie stellst du dir denn das Speichern "ganzer HTML-Seiten" vor, wenn es nicht analog zu HTTrack erfolgen soll? Wie differenzierst du an der Stelle? Die Anmerkung in der Klammer ist für mich nicht ganz nachvollziehbar. Kannst du das am konkreten Beispiel erläutern?

    Zitat

    Anmerkung 2: Ein weiteres, ebenso interessantes Thema wäre die Frage nach einer originären Abspeicherung von HTML-Seiten mit externer CSS-Formatierung. Bei derartigen Seiten wird oft die Formatierung nicht mit gespeichert, was zu einer sehr schlechten Darstellung führt. Man vergleiche hierzu z. B. die Darstellung einer Wikipedia-Seite bei Offline-Aufruf aus dem gespeicherten Zustand.

    Liegt an den CSS-Import Anweisungen. Die werden nicht verfolgt.

    Zitat von .Ulli

    Gib doch mal die Links zu den problematischen Seiten bekannt.

    Ich will mal vier Adressen angeben, ohne Gewähr, ich habe nur die erste jetzt untersucht.
    http://www.123people.de/ [Sucher nach Namen mit Umlauten]
    http://w3g.med.uni-giessen.de/gene/www/ghlp/dzfg-de.html
    https://www.enbw.com/content/de/por…egistrierung.do
    http://www.hostelbookers.com/hostels/germany/bad-urach/ [Suche nach Hotel Vier Jahreszeiten]
    Die ‚Verfälschungen’ scheinen dann aufzutreten, wenn die Codierung im Text nicht mit der charset-Angabe übereinstimmt. Durch andere Versuche habe ich herausgefunden:
    Bei ‚Seite speichern unter...’ wird die Textcodierung geändert, abhängig von der Zeichensatzangabe in der Datei. HTML-Code wird in ANSI abgespeichert, bei Dateivorgabe UTF aber in UTF. ANSI wird bei UTF-8-Vorgabe verfälscht, deshalb werden dort nur Fragezeichen ausgegeben. UTF wird bei Vorgabe ISO verfälscht, es wird ein Durcheinander ausgegeben.
    Da diese Umcodierung bei jeder Wiederholung von ‚Seite speichern unter...’ erfolgt, kommen bei mehrmaligem Speichern einer Seite wieder andere Verfälschungen zustande. Das scheint alles nur zu passieren, wenn die Code-Vorschrift in der Datei nicht mit den Codes im Text übereinstimmt. Das ist in den von mir untersuchten Fällen dann der Fall, wenn im Text auch HTML-Codierungen vorkommen.
    Ich hielte es für besser, wenn beim ‚Speichern unter’ die Original-Codierungen erhalten blieben.

    Zitat

    Wie stellst du dir denn das Speichern "ganzer HTML-Seiten" vor, wenn es nicht analog zu HTTrack erfolgen soll? Wie differenzierst du an der Stelle? Die Anmerkung in der Klammer ist für mich nicht ganz nachvollziehbar. Kannst du das am konkreten Beispiel erläutern?

    Wir haben das Problem mit ‚Seite’ und ‚Site’. Deshalb unterscheide ich (möglicherweise nicht korrekt):
    - HTML-Datei: Eine einzelne Datei, z. B. mit der Endung ‚.htm’
    - Unter ‚Seite’ verstehe ich das, was (auch mit scrollen, aber ohne aktiv links anzuklicken) auf dem Bildschirm dargestellt wird (werden soll).
    - vollständige HTML-Seite: Eine HTML-Datei zusammen mit allen Dateien, die zur beabsichtigten Darstellung dieser HTML-Daiei (‚Seite’) benötigt werden, also z. B. Grafiken o. ä.; auch eine CSS-Datei oder weitere selbsttätig aufgerufene HTML-Seiten können dazugehören. Die erforderliche Verlinkung(en) müssen vorhanden sein. Dagegen sollen Verlinkungen auf ‚Seiten’ außerhalb, also z. B. auf (eigenständige) Fortsetzungen usw. nicht verändert sein, sodass man sie (online) aufrufen kann.
    - HTTrack holt (je nach Einstellung) auch solche Dateien heran, die zur Darstellung anderer (verlinkter) ‚Seiten’ erforderlich sind. Das geht bis zur Speicherung einer ganzen
    - Website, also allen Dateien, die bei einer Adresse gespeichert sind.
    Ich würde gerne auch andere Bezeichnungen verwenden, aber ich habe festgestellt, dass diese Dinge oftmals nicht auseinanderzuhalten sind.

    Dieter Oechsle

    Dieter Oechsle wrote:

    Zitat

    Ich will mal vier Adressen angeben, ohne Gewähr, ich habe nur die erste jetzt untersucht.
    http://w3g.med.uni-giessen.de/gene/www/ghlp/dzfg-de.html


    Seite ist nicht zugreifbar.

    Zitat

    Die "Verfälschungen" scheinen dann aufzutreten, wenn die Codierung im Text nicht mit der charset-Angabe übereinstimmt.

    Und dann ist das aber ein Fehler des Seitenbetreibers. Woher soll den der Fx wissen, welche Kodierung verwendet wird, wenn die HTTP-Header-Angaben oder Meta-Tags falsch oder inkonsistent sind?
    Schau dir mal den dritten Link an, dort steht im HTTP-Header Content-Type=text/html;charset=ISO-8859-1, in der Datei selbst ist UTF-8 angegeben. Speichere ich die Datei als komplette Seite, so ändert er den Meta-Tag auf ISO-8859-1 (gemäß dem HTTP-Header). Beim erneuten Öffnen wird die Seite korrekt angezeigt (Umlaute). Speichere ich die Seite als reines HTML, so lässt der Fx den Code unberührt und interpretiert ihn beim erneuten Öffnen fehlerhaft, da im Meta-Tag UTF-8 angegeben ist, es sich aber um ISO-8859-1 handelt. Ein manuelles Ändern über das Ansicht-Menü bestätigt dies.
    Somit liegt die Schuldfrage dabei beim Betreiber, der nicht in der Lage ist korrekt und konsistent zu arbeiten.

    Zitat

    Bei "Seite speichern unter... " wird die Textcodierung geändert, abhängig von der Zeichensatzangabe in der Datei.

    Kann ich nicht bestätigen. Im obigen Beispiel wird der HTTP-Header beim Speichern als komplette Webseite herangezogen und über die Angabe im Meta-Tag gestellt.

    Zitat

    Da diese Umcodierung bei jeder Wiederholung von "Seite speichern unter... " erfolgt, kommen bei mehrmaligem Speichern einer Seite wieder andere Verfälschungen zustande.

    Was macht es für einen Sinn eine HTML-Seite mehrfach derart zu bearbeiten? Ein recht unrealistisches Szenario.

    Zitat

    Ich hielte es für besser, wenn beim "Speichern unter " die Original-Codierungen erhalten blieben.

    Hast du es einmal mit einer konsistenten und korrekten Seite probiert? Insbesondere sollte man auch darauf achten, welchen Doctype die Seite anbietet und wie der Server den Mime-Type ausgibt.

    Zitat

    Ich würde gerne auch andere Bezeichnungen verwenden, aber ich habe festgestellt, dass diese Dinge oftmals nicht auseinanderzuhalten sind.

    Die Bezeichnungen sind anhand deiner Definitionen als Diskussionsgrundlage durchaus geeignet.

    Zitat

    - HTTrack holt (je nach Einstellung) auch solche Dateien heran, die zur Darstellung anderer (verlinkter) "Seiten" erforderlich sind. Das geht bis zur Speicherung einer ganzen

    "Je nach Einstellung" - HTrack lässt sich sicher auch auf eine Seite beschränken. Du kannst dir aber diesbezüglich auch einmal die Erweiterung Scrapbook ansehen.

    Zitat

    Die "Verfälschungen" scheinen dann aufzutreten, wenn die Codierung im Text nicht mit der charset-Angabe übereinstimmt.Und dann ist das aber ein Fehler des Seitenbetreibers. Woher soll den der Fx wissen, welche Kodierung verwendet wird, wenn die HTTP-Header-Angaben oder Meta-Tags falsch oder inkonsistent sind?

    Ich danke sehr für die ausführliche Stellungnahme.

    Definitif werden die von Firefox aus dem Web empfangenen Codes beim ‚Seite speichern unter...’ teilweise verändert. Das stört mich, weil die Darstellung beim Wiederaufruf auch geändert sein kann. Das ist so!

    Natürlich ist es unzulässig, bei der Zeichsatzvorgabe mit ‚charset=’ die Zeichen in den Codes eines anderen Zeichensatzes zu speichern. Mir scheint es aber zulässig, bei jeder Zeichensatzvorgabe zusätzlich HTML-Code zu verwenden, also ‚mit vereinbarten Namen' (zwischen & und ; geschrieben) und ‚mit Zeichennummer nach UNICODE' (dezimal, zwischen &# und ; geschrieben) oder (hexadezimal zwischen &#x und ; geschrieben). Ob das ein guter Stil ist, ist eine andere Frage. (Wenn ausschließlich die HTML-Codierung verwendet wird, ist übrigens eine Zeichensatzvorgabe im Header nicht erforderlich.)

    Möglicherweise haben unrichtige Codierungen und Codierungsangaben ihre Ursache in der Unkenntniss, dass die HTML-Codierung ‚&#[nummer];’ keine UTF-8-Codierung ist. Eine andere Ursache könnte in undurchsichtiger Arbeitsweise von HTML-Editoren liegen. Auch diese ändern teilweise beim Speichern die Codes ab, was der Ersteller von HTML-Seiten vielleicht gar nicht mitbekommt.

    Freundliche Grüße

    Dieter Oechsle

    Dieter Oechsle wrote:

    Zitat

    Natürlich ist es unzulässig, bei der Zeichsatzvorgabe mit "charset=" die Zeichen in den Codes eines anderen Zeichensatzes zu speichern.

    "Unzulässig" würde ich es nicht nennen, eher sinnlos und irreführend.

    Zitat

    Definitif werden die von Firefox aus dem Web empfangenen Codes beim "Seite speichern unter... " teilweise verändert.

    Hast du dabei auch darauf geachtet, um was es sich für Seiten handelt und wie sie vom Server geliefert werden? Stichwort XHTML als text/html. Ich bezweifle, dass der Fx bspw. die schließenden Shlashes entfernt, wenn der Mime-Type vom Server korrekt angegeben wird.
    XHTML als text/html ausgeliefert, schleußt den Code durch den normalen HTML-Parser, durch das anschließende Serialisieren und Speichern werden bspw. die Slashes entfernt, allerdings werden diese auch nicht benötigt in HTML 4. Daher dürfte man wohl wieder fragen, warum der Server ein Dokument als text/html ausliefert, obwohl es sich um application/xhtml+xml handeln soll.
    Hast du also ein Beispiel, bei dem ein XHTML-Dokument, dass korrekt kodiert, bezeichnet und ausgeliefert auch vom Fx verändert wird?

    Zitat

    Möglicherweise haben unrichtige Codierungen und Codierungsangaben ihre Ursache

    Meist liegt die Ursache darin, dass sich die Webseiten-Autoren gar nicht bewusst sind, dass es so etwas wie Kodierungen gibt und dass man das Zusammenspiel zwischen Server, Client und Seite beachten sollte.

    Zitat

    dass die HTML-Codierung "&#[nummer];" keine UTF-8-Codierung ist.

    Wie darf man das verstehen?

    Zitat

    Eine andere Ursache könnte in undurchsichtiger Arbeitsweise von HTML-Editoren liegen.

    Das spielt manchmal wohl auch eine Rolle, insbesondere wenn der Autor eben davon keinen Schimmer hat.

    Zitat von boardraider

    Woher soll den der Fx wissen, welche Kodierung verwendet wird, wenn die HTTP-Header-Angaben oder Meta-Tags falsch oder inkonsistent sind?
    Schau dir mal den dritten Link an, dort steht im HTTP-Header Content-Type=text/html;charset=ISO-8859-1, in der Datei selbst ist UTF-8 angegeben. Speichere ich die Datei als komplette Seite, so ändert er den Meta-Tag auf ISO-8859-1 (gemäß dem HTTP-Header).

    Wenn ein Konflikt zwischen HTTP-Header und META-Tag vorliegt, sollte meines Erachtens der META-Tag Vorrang erhalten. Schließlich hat der Seitenersteller meist keinen Einfluß auf die Serverkonfiguration, sollte jedoch das Characterencoding kennen.

    Zitat von Dieter Oechsle

    Wenn ausschließlich die HTML-Codierung verwendet wird, ist übrigens eine Zeichensatzvorgabe im Header nicht erforderlich.

    Falsch. Es ist immer eine Zeichensatzangabe erforderlich, egal ob im HTTP-Header oder in dafür vorgesehenen Elementen innerhalb des (X)HTML-Dokuments. Ist keine Zeichensatzangabe vorhanden, versucht der Browser anhand der vorgefundenden Codes zu raten. Klappt das nicht, erfolgt ein Fallback zu UTF-8. Das ist aber bei der "HTML"-Kodierung problemlos, weil:

    Zitat von Dieter Oechsle

    Möglicherweise haben unrichtige Codierungen und Codierungsangaben ihre Ursache in der Unkenntniss, dass die HTML-Codierung ‚&#[nummer];’ keine UTF-8-Codierung ist.

    Das ist sehr wohl gültiges UTF-8. Alle Zeichen des US-ASCII Zeichensatzes sind UTF-8, und durch diese Art der Kodierung werden alle Zeichen in den US-ASCII Satz konvertiert.

    Junker Jörg wrote:

    Zitat

    Wenn ein Konflikt zwischen HTTP-Header und META-Tag vorliegt, sollte meines Erachtens der META-Tag Vorrang erhalten.


    http://www.w3.org/TR/REC-html40/charset.html
    Ist aber im Standard anders definiert:

    Zitat

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

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

    In dem Dokument wird auch erklärt, warum es zu dieser Reihenfolge kommt.

    Zitat

    Schließlich hat der Seitenersteller meist keinen Einfluß auf die Serverkonfiguration

    Wenn man die Serverkonfiguration nicht direkt beeinflussen bzw. den Admin zur Änderung bewegen kann, bietet sich oft die Möglichkeit über htaccess den korrekten Header zu setzen.
    Sollte das nicht gehen und der Server kein UTF-8 ausliefern, dann kann man noch immer auf die von Dieter angesprochene Kodierung ausweichen - oder den Hoster wechseln ;)

    Zitat

    sollte jedoch das Characterencoding kennen.

    Ja richtig, nur wie ich schrieb beachten viele Autoren genau diesen Punkt nicht, was in Folge dessen zu Problemen führt.

    Zitat

    Hast du dabei auch darauf geachtet, um was es sich für Seiten handelt und wie sie vom Server geliefert werden? Stichwort XHTML als text/html. ... ... Hast du also ein Beispiel, bei dem ein XHTML-Dokument, dass korrekt kodiert, bezeichnet und ausgeliefert auch vom Fx verändert wird?


    Es wird mir jetzt zu speziell, da ich nicht viel von HTML und fast gar nichts von der Übertragung verstehe. Aber ich habe Seiten, die ich selbst geschrieben habe, die vom Validator als korrekt bezeichnet sind, deren Codierung ich genau kenne, jedes einzelne Byte. Sie werden beim (offline!) Aufruf korrekt angezeigt. Wenn ich sie dann (immer noch offline!) mit ,Seite speichern unter...’ speichere, ist die Codierung teilweise geändert. Das ist so. (Diese Diskussion kann abgebrochen werden.)

    Zitat

    Falsch. Es ist immer eine Zeichensatzangabe erforderlich, egal ob im HTTP-Header oder in dafür vorgese-henen Elementen innerhalb des (X)HTML-Dokuments. Ist keine Zeichensatzangabe vorhanden, versucht der Browser anhand der vorgefundenden Codes zu raten. Klappt das nicht, erfolgt ein Fallback zu UTF-8. Das ist aber bei der "HTML"-Kodierung problemlos, weil:


    Zitat aus SELFHTML: „Sie können mit Hilfe einer Meta-Angabe angeben, welche Zeichenkodierung die HTML-Datei verwendet. Diese Angabe ist für den Web-Browser besonders wichtig, denn sie teilt ihm mit, nach welcher Kodierung die Bytes der Datei in Zeichen umgewandelt werden müssen. ... ... Wichtig ist die Angabe vor allem dann, wenn Sie innerhalb der HTML-Datei z.B. deutsche Umlaute nicht über benannte Zeichen maskieren.“

    Das kann natürlich anderswo anders stehen.

    Ich meine, dass der Browser nach folgenden Regeln decodieren sollte:
    1. nach der meta-Angabe.
    2. wenn diese fehlt nach der im Browser als Standard vorgegebenen.

    Zitat

    Das ist sehr wohl gültiges UTF-8. Alle Zeichen des US-ASCII Zeichensatzes sind UTF-8, und durch diese Art der Kodierung werden alle Zeichen in den US-ASCII Satz konvertiert.


    Da muss ich doch etwas ausholen. Nach meinen Kenntnissen kann man in HTML Zeichen wie folgt codieren:
    (1) in ASCII (Codes kleiner als $80 (128), unmittelbar geschrieben; damit sind also keine Sonderzeichen (Umlaute ...) möglich).
    (2) mit vereinbarten Namen (zwischen & und ; geschrieben; in SELFHTML auch ‚maskieren’ genannt).
    (3) mit der Zeichennummer nach UNICODE, dezimal (zwischen &# und ; geschrieben) oder hexadezimal (zwischen &#x und ; geschrieben), in SELFHTML auch ‚maskieren’ genannt.
    (4) mit den für einen Zeichensatz vereinbarten Codevorschriften, wenn der Zeichensatz im Header benannt ist.

    Meines Erachtens ist die Verwendung aller genannten Codierungen in einer Datei gleichzeitig zulässig, aber bei (4) natürlich nur in genau einem (dem mit charset= festgelgten) Zeichensatz. Was der Browser daraus macht, ist eine andere Sache. Deshalb ist auch sehr schwer zu sagen, welche Methode günstiger ist.

    Festzuhalten ist weiter, dass bei (1), (2) und (3) alle übertragenen Zeichen ausschließlich mit ‚ASCII-Codes’ gespeichert sind, nur bei (4) kommen Codes im Bereich $80 bis $FF (128 bis 255) vor.

    Um den Unterschied zwischen den Codierungen aufzuzeigen biete ich die folgenden Beispiele, alle zeigen die Codierung nur für den Buchstaben ‚ä’ (klein a Umlaut).
    (1) Das Zeichen ä kann in ASCII nicht dargestellt werden!
    (2) ä wird codiert mit; 26 61 75 6D 6C 3B
    (3) wird codiert mit: 26 23 32 32 38 3B oder mit: 26 23 78 45 34 3B
    (4) In ANSI mit Vorgabe
    {meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"}
    wird ä codiert mit: E4
    (4) In UTF-8 mit Vorgabe
    {meta http-equiv="content-type" content="text/html; charset=UTF-8"}
    wird ä codiert mit: C3 A4
    (Die eckigen Klammern sind hier durch geschweifte ersetzt, damit die Zeilen ‚unterwegs’ nicht als HTML-Anweisungen gelesen werden können.)

    Im Beispiel (4) wird der Unterschied zwischen der UNICODE-Zeichennummer und dem eigentlichen Code deutlich: Die UNICODE Zeichennummer von ä ist 00E4 (228), die Codierung in UTF-16 wäre dann 00 E4, in UTF-8 ist sie C3 A4.
    So ist bei UNICODE zu beachten, dass es mehrere, verschiedene Codierungen für jede Zeichennummer gibt. Am schwersten verständlich ist der UTF-8-Code, er wurde zur Verringerung der Bytezahl für Texte mit hohem Anteil an ASCII-Zeichen eingeführt.

    Dieter Oechsle

    Dieter Oechsle wrote:

    Zitat

    (Diese Diskussion kann abgebrochen werden.)

    Weshalb hast du sie dann eröffnet? :roll: Etwas fruchtlos auf diese Art.

    Zitat

    Das kann natürlich anderswo anders stehen.

    Ich meine, dass der Browser nach folgenden Regeln decodieren sollte:
    1. nach der meta-Angabe.
    2. wenn diese fehlt nach der im Browser als Standard vorgegebenen.


    Ja das steht anderswo anders und zwar im Standard, den ich oben verlinkt habe. *g*
    An dem sollten sich die UAs und auch Webautoren ausrichten.

    Zitat

    (Die eckigen Klammern sind hier durch geschweifte ersetzt, damit die Zeilen 1Aunterwegs 19 nicht als HTML-Anweisungen gelesen werden können.)

    Dafür gibt es die Möglichkeit beim Verfassen HTML-Codes zu deaktivieren ;)

    Zitat

    Nach meinen Kenntnissen kann man in HTML Zeichen wie folgt codieren

    Grundsätzlich ist HTML erstmal Text, d.h. von vorn herein hat der Text eine Kodierung (in Worten: welche Bits bedeuten welche Zeichencodes). Dies Kodierung ist dem UA zunächst unbekannt. Im Falle HTML über HTTP kann der Server die Kodierung über die HTTP-Header mitteilen, deswegen ist das auch die wichtigste Direktive. Ohne Kenntnis über die Kodierung kann der UA das Dokument theoretisch nicht zuverlässig darstellen.
    Die Kodierung in der Datei selbst bekannt zu geben, ist ein Kompromiss aus der Praxis und eigentlich widersinnig. Da aber in nahezu allen Zeichenkodierungen die unteren Bereiche identische Zeichen darstellen kann der Browser bei Unkenntnis über die Kodierung bspw. bei HTML den Beginn der Datei auswerten (deswegen sollte die Meta-Angabe dort auch als eines der ersten Header-Elemente erscheinen).
    Grundsätzlich ist also die Frage, in welcher Kodierung man das Dokument abspeicherst und nicht welche zusätzlichen "Meta"-Codes (&xxx;) man verwendest. Diese Codes können theoretisch fehlschlagen, wenn es auch in der Praxis auf Grund der meist identischen unteren Zeichen funktioniert.

    Zitat

    Deshalb ist auch sehr schwer zu sagen, welche Methode günstiger ist.

    Was die Datengröße betrifft, so hängt es vom Inhalt ab.

    Dieter Oechsle
    Du hast mich offensichtlich falsch verstanden. Unabhängig vom gewählten Zeichensatz muß dieser in irgendeiner Form übertragen werden, auch wenn die HTML-Datei nur aus US-ASCII-Zeichen besteht. Wird der Zeichensatz im HTTP-Header übertragen, kann auf die META-Angabe generell verzichtet werden, unabhängig vom verwendeten Zeichensatz , auch wenn die HTML-Datei Nicht-US-ASCII Zeichen enthält.

    Außerdem verwechselst du Maskierung mit Codierung. Wenn ich die Nicht-ASCII-Zeichen nach HTML-Schema maskiere (also entweder mit HTML-Namen, z.B. ä oder mit ihrem Unicode-Wert, z.B. & #228;), dann ist der Zeichensatz weitestgehend* irrelevant und die Darstellung wird korrekt sein, Schriftarten mit entsprechendem Zeichenvorrat vorausgesetzt. Wenn ich die Sonderzeichen aber nicht maskiere, dann wird die Darstellung fehlerhaft, wenn sie mit einem anderen Zeichensatz decodiert werden als sie codiert wurden. Ob du den Namen oder die Nummer zur Maskierung verwendest ist egal, die Namen sind für Menschen die den Quelltext lesen verständlicher, die Nummern für Programme einfacher.

    * natürlich wird es schief laufen, wenn man z.B. UTF-8 als UTF-16 öffnet (Blödes Beispiel, ich weiß). Aber alle Zeichensätze, die "Erweiterungen" des US-ASCII-Zeichensatzes darstellen, werden dadurch abgedeckt. Ich kann den Zeichensatz also als UTF-8, US-ASCII, ANSI, WINDOWS-1252, einen beliebigen aus der ISO-8859 Gruppe, etc. pp. deklarieren bzw. interpretieren.

    Zitat

    Weshalb hast du sie dann eröffnet? Etwas fruchtlos auf diese Art.


    Eröffnet habe ich sie weil ich mich ärgere, wenn wenn die Darstellung einer HTTP-Seite beim Aufruf aus gespeichertem Zustand anders ist. Dabei war mir schon klar, dass es vorkommen kann dass die HTML-Dateien an sich nicht richtig sind. Da ich aber auch bei vermeintlich guten Seiten Veränderungen finde, wollte ich wissen, warum der Browser, hier Firefox, beim Speichern Veränderungen in der Zeichencodierung vornimmt. (Und das macht er!) Darauf erwarte ich nun auch bei Weiterführung der Diskussion keine Antwort mehr.

    Zitat

    Ja das steht anderswo anders und zwar im Standard, den ich oben verlinkt habe. *g*
    An dem sollten sich die UAs und auch Webautoren ausrichten.


    Die wenigen Sätze, die ich im ‚Standard’ gelesen habe, bestätigen mir das nicht, z. B.:

    „To address server or configuration limitations, HTML documents may include explicit information about the document's character encoding; the META element can be used to provide user agents with this information.“

    „The META declaration must only be used when the character encoding is organized such that ASCII-valued bytes stand for ASCII characters (at least until the META element is parsed).“

    (Ich möchte hier nicht weiter in den Dschungel vordringen.)

    Zitat

    Dafür gibt es die Möglichkeit beim Verfassen HTML-Codes zu deaktivieren ;)


    Vielleicht lerne ich das auch noch.

    Zitat

    Im Falle HTML über HTTP kann der Server die Kodierung über die HTTP-Header mitteilen, deswegen ist das auch die wichtigste Direktive. Ohne Kenntnis über die Kodierung kann der UA das Dokument theore-tisch nicht zuverlässig darstellen.

    Zitat

    Du hast mich offensichtlich falsch verstanden. Unabhängig vom gewählten Zeichensatz muß dieser in irgendeiner Form übertragen werden, auch wenn die HTML-Datei nur aus US-ASCII-Zeichen besteht. Wird der Zeichensatz im HTTP-Header übertragen, kann auf die META-Angabe generell verzichtet werden, unabhängig vom verwendeten Zeichensatz , auch wenn die HTML-Datei Nicht-US-ASCII Zeichen ent-hält.

    Zitat

    Außerdem verwechselst du Maskierung mit Codierung.


    Da ich gar nicht die Absicht hatte, in die (Un-) Tiefen von HTML einzudringen, kann ich zugeben, dass ich über die Übertragung fast nichts weiß. So wird mir erst jetzt langsam klar, dass der HTTP-Header etwas anderes ist als der Datei-Header. Meine Anfrage galt nur den Veränderungen innerhalb der Datei, die von Firefox vorgenommen werden bei ‚Seite speichern unter...’. Und im Datei-Header – so meine ich – ist die Meta-Angabe eines Zeichensatzes nur erforderlich, wenn ein von ASCII abweichender Zeichensatz-Code verwendet wird. Die Verwendung von Maskierungen (die ich wohl fälschlicherweise HTTL-Codes genannt hatte) erfordert keine von ASCII abweichenden Codes, also auch keine Meta-Angabe im Datei-Header. Ich halte diese (subjektiv) sogar für unrichtig, wenn davon gar kein Gebrauch gemacht wird. Eine Datei, die durchgehend nur ASCII-Codes enthält, darf m. E. durch die Übertragung nicht verändert werden. (Ich bitte um Nachsicht, wenn ich als Laie solch eine Ansicht äußere.)

    Dieter Oechsle wrote:

    Zitat


    Eröffnet habe ich sie weil ich mich ärgere, wenn wenn die Darstellung einer HTTP-Seite beim Aufruf aus gespeichertem Zustand anders ist.

    Du machst also nur deinem Ärger Luft, aber warum und in welchen Fällen es zu den Veränderungen kommt, interessiert dich nicht.
    Na gut, wenn das so ist, brauche ich meine Zeit nicht länger opfern. ;)

    Zitat

    Die wenigen Sätze, die ich im 1AStandard 19 gelesen habe, bestätigen mir das nicht


    Vielleicht solltest du das Zitat oben nochmal lesen, da steht es klar und deutlich.

    Zitat

    (Ich möchte hier nicht weiter in den Dschungel vordringen.)


    Damit gilt an der Stelle auch obiges.

    Schönes Wochenende :)

    Zum css-Teil der Frage:
    Das Speichern von Seiten samt (externer) Stylesheets & evt. darin enthaltener Bilder kannst Du mal mit der Extension Save Complete testen.

    Gruß gammaburst

    Zitat von Dieter Oechsle

    Und im Datei-Header – so meine ich – ist die Meta-Angabe eines Zeichensatzes nur erforderlich, wenn ein von ASCII abweichender Zeichensatz-Code verwendet wird.

    Nein. Hättest den Standard etwas vertiefen sollen. Die Angabe im Datei-Header ist nie (auch wenn der Zeichensatz von US-ASCII abweicht) erforderlich, wenn der Server das Characterset im HTTP-Header überträgt (Was eigentlich Standard sein sollte, aber bei Massenhostern nur selten der Fall sein wird, da sie sonst den Inhalt jeder Datei vor der Übertragung prüfen müßten). Die Angabe in den Meta-Tags ist zulässig, als Fallback für den Fall, das kein Characterset vom Server im HTTP-Header übertragen wird. Aber: Die Angabe in den Meta-Tags ist nur dann zulässig, wenn der Zeichensatz ASCII-Zeichen auch als ASCII-Zeichen darstellt (z.B. UTF-8, iso8859-?). Widersprechen sich Angabe im HTTP-Header und den Meta-Tags, hat der HTTP-Header Vorrang (Ich finde diese Regelung auch unsinnig. Aber so ist es nun einmal festgelegt.)

    Zitat

    Widersprechen sich Angabe im HTTP-Header und den Meta-Tags, hat der HTTP-Header Vorrang (Ich finde diese Regelung auch unsinnig. Aber so ist es nun einmal festgelegt.)

    Der Server hätte theoretisch die Möglichkeit das Dokument umzukodieren. Wenn der meta-Tag auf der Seite des Clients Vorrang hätte, dann würde es dabei zu Schwierigkeiten kommen.
    In der Praxis gerade bei Massenhostern ist die definierte Reihenfolge natürlich dann ein Problem, wenn der Webautor wenig bis keine Ahnung von der Problematik hat. Zum Service des Hosters sollte es daher gehören auf diese Umstände hinzuweisen und eine entsprechende Konfigurationsmöglichkeit anzubieten. Letztlich liegt aber ein Teil der Verantwortung eben beim Autor. Als universelleren Ansatz halte ich die Reihenfolge daher für richtig gewählt.