Ingo Siemon: XML-Deklaration

Hallo

Ich habe meine Seite gerade mal mit dem neuen
Validator von http://www.validome.org/ getestet.
Der sagt mir dann auch schön, dass alles valide ist.

Nur gibt es mir noch einen Hinweis und eine Warnung aus.

Hinweis
-------
Dieses XHTML 1.0-Dokument wurde mit dem MIME-Type text/html ausgeliefert, was jedoch nur dann zugelassen ist wenn es den Richtlinien zu HTML entspricht.XML-Deklaration nicht vorhanden! Es wird ausdrücklich empfohlen eine XML-Deklaration dem Dokument hinzuzufügen.

Warnung
-------
Dieses XHTML-Dokument wurde ohne Angabe einer Zeichensatzkodierung im HTTP-Header übertragen.
In diesen Fall müssen sowohl in der XML-Deklaration (z.B. <?xml version="1.0" encoding="ISO-8859-1"?>), als auch in einen Meta-Tag (z.B. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">) eine Zeichensatzkodierung angegeben werden, wenn einer der Beiden vorhanden ist.
Bitte ergänzen Sie die Fehlenden Angaben im Dokument.

Nun muss ich gestehen, dass das etwas zu hoch für mich ist.

Bei meiner Seiite sieht es folgendermassen aus:
[code lang=htm]<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">

<head>

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

<title>SPACEart - Science Fiction + Erotik Modelle</title>

</head>[/Code]

  1. hi,

    Dieses XHTML 1.0-Dokument wurde mit dem MIME-Type text/html ausgeliefert, was jedoch nur dann zugelassen ist wenn es den Richtlinien zu HTML entspricht.XML-Deklaration nicht vorhanden! Es wird ausdrücklich empfohlen eine XML-Deklaration dem Dokument hinzuzufügen.

    Du kannst natürlich deinem Dokument eine XML-Deklaration hinzufügen - sei dir dabei aber bewusst, dass du damit den IE in den Quirks Mode versetzt, was dann Auswirkungen auf das Rendering hat.
    Es ist also nicht mindern Empfehlenswert, zwecks IE-Kompabilität den obige Hinweis einfach Hinweis sein zu lassen, und auf die XML-Deklaration zu verzichten.

    Dieses XHTML-Dokument wurde ohne Angabe einer Zeichensatzkodierung im HTTP-Header übertragen.
    In diesen Fall müssen sowohl in der XML-Deklaration (z.B. <?xml version="1.0" encoding="ISO-8859-1"?>), als auch in einen Meta-Tag (z.B. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">) eine Zeichensatzkodierung angegeben werden, wenn einer der Beiden vorhanden ist.
    Bitte ergänzen Sie die Fehlenden Angaben im Dokument.

    Nun muss ich gestehen, dass das etwas zu hoch für mich ist.

    Es wird erwartet, dass der Server bereits beim Ausliefern der Ressource in den Response Headern eine Angabe zum verwendeten Zeichencode macht, dies findet bei deinerm Server aber nicht statt.
    Wende dich also an den Administrator des Servers, oder sorge selbst dafür, dass ein solcher Header gesendet wird - in PHP-Scripten beispielsweise mittels header() machbar.

    gruß,
    wahsaga

    --
    /voodoo.css:
    #GeorgeWBush { position:absolute; bottom:-6ft; }
    1. Tach

      Es ist also nicht mindern Empfehlenswert, zwecks IE-Kompabilität den obige Hinweis einfach Hinweis sein zu lassen, und auf die XML-Deklaration zu verzichten.

      Ok, ich verstehe. Dann werde ich das mal schön so lassen, wie es ist.

      Wende dich also an den Administrator des Servers, oder sorge selbst dafür, dass ein solcher Header gesendet wird

      Ich habe meine Seite bei Schlund+Partner gehostet.
      Sorry, dass ich nun nochmal so blöd frage,
      aber wie kann ich denn selbst dafür sorgen, dass der entsprechenden
      Header gesendet wird (bei .htm-Dateien)?

      Gruß
      Ingo

      1. hi,

        Sorry, dass ich nun nochmal so blöd frage,
        aber wie kann ich denn selbst dafür sorgen, dass der entsprechenden
        Header gesendet wird (bei .htm-Dateien)?

        Bei einem Apache-Webserver z.b. über AddCharset, was sich auch in einer .htaccess-Datei unterbringen lässt (abhängig von der Konfiguration des Servers).

        gruß,
        wahsaga

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }
        1. Hallo nochmal

          Bei einem Apache-Webserver z.b. über AddCharset, was sich auch in einer .htaccess-Datei unterbringen lässt (abhängig von der Konfiguration des Servers).

          OK, ich habe nun folgendes in meine .htaccess-Datei geschrieben:
          AddDefaultCharset iso-8859-1

          Aber die Meldungen des Validators bleiben immer noch.
          Gruß
          Ingo

    2. Hallo,

      Es ist also nicht mindern Empfehlenswert, zwecks IE-Kompabilität den obige Hinweis einfach Hinweis sein zu lassen, und auf die XML-Deklaration zu verzichten.

      Der Hinweis besagt: Dieses Dokument ist kein gültiges XHTML/XML.
      Klar kann man das ignorieren. Es gibt dann allerdings keinen Grund mehr, sich überhaupt irgendwo um Standardkonformität und technische Korrektheit zu scheren - »Hauptsache es funzt«.

      Mathias

      1. hi,

        Der Hinweis besagt: Dieses Dokument ist kein gültiges XHTML/XML.
        Klar kann man das ignorieren.

        "Muss" man wohl sogar, wenn man nicht für den IE im Quirks Mode CSS-Workarounds stricken will.

        Es gibt dann allerdings keinen Grund mehr, sich überhaupt irgendwo um Standardkonformität und technische Korrektheit zu scheren - »Hauptsache es funzt«.

        Das ist m.E. ein "nicht Kümmern bis auf weiteres" - wobei auf weiteres die Geburt eines neuen IE und damit die langsame Verdrängung der Versionen <= 6 ist. Wenn das mal eingetreten ist, bin ich auch dafür, XHTML auch mit XML-Deklaration auszuliefern - und ältere IE ab Unterschreitung einer gewissen Prozentzahl an Nutzern nicht mehr mit Extrawürsten zu bedienen. Aber so lange bleibe ich bei diesem Kompromiss.

        gruß,
        wahsaga

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }
        1. Hallo wahsaga.

          Wenn das mal eingetreten ist, bin ich auch dafür, XHTML auch mit XML-Deklaration auszuliefern - und ältere IE ab Unterschreitung einer gewissen Prozentzahl an Nutzern nicht mehr mit Extrawürsten zu bedienen. Aber so lange bleibe ich bei diesem Kompromiss.

          Was spricht dann gegen folgenden Kompromiss?

          if (isset($_SERVER["HTTP_ACCEPT"]) and stristr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml')) {  
            header('content-type: application/xhtml+xml; charset=utf-8');  
            echo '<?xml version="1.0" encoding="utf-8"?>'."\n";  
          }  
          else {  
            header('content-type: text/html; charset=utf-8');
          

          Ja, dies ist auch nur ein Kompromiss, erlaubt aber wirklich XML-fähigen Clients, betroffene X(HT)ML-Dokumente auch als solche zu verarbeiten.

          Einen schönen Mittwoch noch.

          Gruß, Ashura

  2. Hallo,

    wenn du XHTML verwendest, hat dies nur einen Sinn, wenn du auch korrektes, XML-konformes XHTML schreibst. Ansonsten bist du mit korrektem HTML vielleicht besser beraten als mit fehlerhaftem XHTML, welches sich überhaupt nicht als XML verarbeiten lässt.

    Die Kodierungsfrage ist so ein Punkt. Die halbe Welt pustet momentan inkorrektes XML in Form von »HTML-kompatiblen« XHTML (MIME-Typ text/html, Kompatibilitätsrichtlinien) ins Netz. Diese Dokumente werden niemals von einem XML-Parser verarbeitet werden können, insofern sind sie weder echtes XHTML noch einfaches HTML. Die Vorteile von XHTML werden sich nie zeigen.

    Ein XML-Dokument hat standardmäßig die Kodierung UTF-8. Wenn du eine abweichende Kodierung verwendest, solltest du diese in einer XML-Deklaration angeben, damit der XML-Parser in jedem Fall weiß, welche Kodierung das Dokument hat (auch beim Verschicken via E-Mail, beim Speichern und Archivieren auf der Festplatte, bei der Übertragen mit anderen Protokollen als HTTP usw.). Wenn du ISO 8859-1 statt UTF-8 verwendest, dies aber nicht auf diese Weise angibst, ist das Dokument für sich genommen kein gültiges XML. Jeder XML-Parser muss und wird die Verarbeitung abbrechen, weil er ein Dokument ohne Kodierungsangabe als UTF-8 verarbeitet. Solange du die Vorteile von XHTML nicht nutzt und die Browser sowieso nur HTML-Parser (»Tag-Soup-Parser«) beim Verarbeiten des Dokuments verwenden, ist es unerheblich, dass das Dokument niemals von einem XML-Parser gelesen werden kann.

    Was nun die Lösung ist? Gegenfrage, warum verwendest du XHTML, wenn es doch sowieso nie als echtes XHTML verarbeitet wird bzw. werden kann? XML wurde als strenges Austauschformat erfunden, das einfachen, klaren Regeln folgt und dementsprechend einfach verarbeitet werden kann. Das Produzieren von inkorrektem XML hilft niemanden weiter (natürlich bleiben einige Vorteile von XHTML - man kann z.B. gegen eine strengere DTD validieren, weil die üblichen Validatoren keine echten XML-Parser sind; das kann man bei HTML 4 allerdings prinzipiell auch). Mein Rat ist: Verwende korrektes XHTML (am besten direkt UTF-8-kodiert, damit du dir um den Quirks-Modus keine Sorgen machen musst) oder verwende korrektes HTML 4 (dort gibt es das »Problem« nicht bzw. dort HTML hat im Gegensatz zu XHTML dieses Feature der Klarheit und Strenge nicht).

    Du kannst die Kodierung in einem HTTP-Header angeben, was aber bei den genannten Szenarien nicht unbedingt weiterhilft.

    XHTML-Dokumente solltest du übrigens direkt mit einem XML-Schema-Validator prüfen, weil Validome und der W3C-Validator sich wie gesagt nur scheinbar XML verstehen. Zudem ist die Prüfung über das Schema viel strenger.

    Mathias

    1. hi,

      Die halbe Welt pustet momentan inkorrektes XML in Form von »HTML-kompatiblen« XHTML (MIME-Typ text/html, Kompatibilitätsrichtlinien) ins Netz.

      Stimmt.
      Warum macht sie das bloß? Böse Welt!

      gruß,
      wahsaga

      --
      /voodoo.css:
      #GeorgeWBush { position:absolute; bottom:-6ft; }
      1. Hallo,

        Die halbe Welt pustet momentan inkorrektes XML in Form von »HTML-kompatiblen« XHTML (MIME-Typ text/html, Kompatibilitätsrichtlinien) ins Netz.

        Stimmt.
        Warum macht sie das bloß? Böse Welt!

        Was meinst du?

        molily.de sendet keinen charset-Parameter im Content-Type-Header, wenn du darauf hinaus willst. Nirgendwo habe ich gesagt, dass dies eine notwendige Voraussetzung für korrektes XHTML sei. Ich liefere UTF-8-kodiertes XHTML aus, da brauche ich weder charset-Parameter im Content-Type-Header noch eine Kodierungangabe in einer XML-Deklaration. Für HTML-User-Agents gibt es eine Kodierungsangabe in einem Meta-Element.

        Das XHTML unter http://molily.de/ ist korrektes, XML-konformes XHTML, das den Kompatibilitätsrichtlinien folgt. Falls du das meintest: Auch gegen die Kompatibilitätsrichtlinien an sich habe ich nichts gesagt. Auch sogenanntes HTML-kompatibles XHTML kann korrektes XHTML sein.

        Ich habe in meinem Posting lediglich auf die Kodierungsproblematik abgezielt, nicht auf den Sinn oder Unsinn von XHTML als text/html (wobei diese Punkte zusammenhängen, wie die gängige Argumentation gegen XHTML als text/html zeigt).

        Mathias

        1. hi,

          Auch gegen die Kompatibilitätsrichtlinien an sich habe ich nichts gesagt. [...]

          Aha - es kam für mich so rüber, als ob das deine Absicht gewesen wäre.

          gruß,
          wahsaga

          --
          /voodoo.css:
          #GeorgeWBush { position:absolute; bottom:-6ft; }
    2. Lieber Mathias

      wenn du XHTML verwendest, hat dies nur einen Sinn, wenn du auch korrektes, XML-konformes XHTML schreibst ...

      OK, ich möchte Dir hier auch erstmal sehr für Deine
      ausführlichen Erklärungen danken!

      So bin ich nun wieder ein gutes Stückchen weiter auf dem Weg
      des Verständnisses für diese Dinge.

      Gruß
      Ingo

  3. Ingo,
    Warum codierst du deine XHTML-Dokumente überhaupt in ISO 8859-1?

    Wenn du UTF-8 verwendest (und das dann auch in der HTTP-EQUIV-Angabe sagst), kannst du

    a) auf die XML-Deklaration verzichten, hast also weniger Ärger mit dem IE und Quirksmode,

    b) auch Zeichen im Quelltext haben, die sich mit ISO 8859-1 nicht codieren lassen: „ “ – … €

    Nachteile von UTF-8: <style type="Otto">Ich sehe keine, gibt es denn welche?</style>

    Live long and prosper,
    Gunnar

    --
    „Weisheit ist nicht das Ergebnis der Schulbildung, sondern des lebenslangen Versuchs, sie zu erwerben.“ (Albert Einstein)
    1. Hallo Gunnar,

      Nachteile von UTF-8: <style type="Otto">Ich sehe keine, gibt es denn welche?</style>

      Es muss in der gesamten Kette vom Ḝḏḭṭớṝ bis ins ḈṂṨ unterstützt werden. In dieser Kette gibt es leider noch viele schwache Glieder.

      Grüße
       Roland

      1. Lieber Roland

        Nachteile von UTF-8: <style type="Otto">Ich sehe keine, gibt es denn welche?</style>

        Es muss in der gesamten Kette vom Ḝḏḭṭớṝ bis ins ḈṂṨ unterstützt werden. In dieser Kette gibt es leider noch viele schwache Glieder.

        Die Kette geht von ??? zu ??? ?
        Bei mir werden da nur merkwürdige "Ersatz-Zeichen" angezeigt in Deinem Posting.

        Welche sind denn Deiner Meiniung nach die schwachen Glieder inder Kette?

        Ich würde mich sehr freuen, wenn Du mir das nochmal
        erleutern könntest, weil ich ja nun gerade überlege,
        meine Seiten auf UTF-8 umzustellen.

        Gruß
        Ingo

        1. Hallo Ingo,

          Nachteile von UTF-8

          Es muss in der gesamten Kette vom Ḝḏḭṭớṝ bis ins ḈṂṨ unterstützt werden. In dieser Kette gibt es leider noch viele schwache Glieder.

          Die Kette geht von ??? zu ??? ?
          Bei mir werden da nur merkwürdige "Ersatz-Zeichen" angezeigt in Deinem Posting.

          Deiner für die Anzeige des Forums eingesetzten Schriftart fehlen die nötigen Zeichen. Screenshot: Die Schriftart, die die meisten Unicode-Zeichen abdeckt, ist AFAIK Arial Unicode MS. Ich lese das Forum in Bitstream Vera Sans.

          Das sollte dich allerdings nicht abschrecken, da die geläufigen Zeichen auch in Wald-und-Wiesen-Schriftarten enthalten sind. Das Forum hat im Gegensatz zu manch anderer Software kein Problem mit UTF-8.

          Welche sind denn Deiner Meiniung nach die schwachen Glieder inder Kette?

          Beileibe nicht alle Editoren können mit UTF-8 umgehen. Mit welchem arbeitest du? Du solltest daher vor der Umstellung ausgiebig testen. Wie wandelst du die vorhandenen Dokumente in UTF-8 um?

          Grüße
           Roland

          1. Lieber Roland

            Deiner für die Anzeige des Forums eingesetzten Schriftart fehlen die nötigen Zeichen.

            OK, ich verstehe.

            Beileibe nicht alle Editoren können mit UTF-8 umgehen. Mit welchem arbeitest du? Du solltest daher vor der Umstellung ausgiebig testen.

            Ich arbeite bisher mit Phase5, aber der kann eben leider auch kein UTF-8.
            Darum bin ich gerade auf der Suche nach einem neuen Editor.
            Hast Du da vieleicht eine gute Empfehlung?

            Wie wandelst du die vorhandenen Dokumente in UTF-8 um?

            Bisher eben noch garnicht.
            Ich will ja eben erst je´tzt auf UTF-8 umsteigen sozusagen.

            Gruß
            Ingo

            1. Hallo Ingo,

              Ich arbeite bisher mit Phase5, aber der kann eben leider auch kein UTF-8.
              Darum bin ich gerade auf der Suche nach einem neuen Editor.
              Hast Du da vieleicht eine gute Empfehlung?

              Ich arbeite mit Notepad++ 3.2.

              Wie wandelst du die vorhandenen Dokumente in UTF-8 um?

              Bisher eben noch garnicht.
              Ich will ja eben erst je´tzt auf UTF-8 umsteigen sozusagen.

              Dann würde ich das eventuell in einem Rutsch per utf8_encode() erledigen. Ob das problemlos funktioniert, weiß ich allerdings nicht. Mit dem Suchbegriff „iso2utf“ lässt sich auch einiges finden.

              Grüße
               Roland

              1. Lieber Roland

                Ich arbeite mit Notepad++ 3.2.

                Ja, den hatte ich auch schon in die engere Auswahl genommen.
                Aber hat der denn auch so eine Include-Funktion wie z.B. Phase5?

                Wenn Du nun nicht genau weisst, was ich mit "Include-Funktion" meine,
                dann gibts hier ne sehr gute Erklärung:
                http://www.clairette.de/tutorial/lektionen/include.html

                Gruß
                Ingo

    2. Lieber Gunnar

      Warum codierst du deine XHTML-Dokumente überhaupt in ISO 8859-1?

      Wenn du UTF-8 verwendest (und das dann auch in der HTTP-EQUIV-Angabe sagst), kannst du

      a) auf die XML-Deklaration verzichten, hast also weniger Ärger mit dem IE und Quirksmode,

      b) auch Zeichen im Quelltext haben, die sich mit ISO 8859-1 nicht codieren lassen: „ “ – … €

      Nachteile von UTF-8: <style type="Otto">Ich sehe keine, gibt es denn welche?</style>

      Puhhh, das übersteigt langsam echt meine Kenne :)
      Ich bin mir nun ganrnicht so sicher, ob ich meine Seite
      überhaupt in XHTML machen soll/muss.

      Ich versuche eigentlich immer möglichst wenig bzw. keine
      Sonderzeichen wie z.B. € zu benutzen, sondern anstall lieber "EUR" zu schreiben.

      Ist es denn im Grunde so, wie ich es jetzt habe,
      vollkommener Unsinn?

      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
      <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

      Wenn ich nun UTF-8 verwende, muss doch auch mein html-Editor die
      Seiten in UTF-8 speichern und mein FTP-Programm die dann in UTF-8
      auf den Webspace meines Providers hochladen ... richtig?
      Und dann muss ich doch auch noch per .htacess-Datei dafür
      sorgen, dass der Server meines Providers die Dateien UTF-8 codiert
      an die Browser der User ausliefert.

      Hab ich das soeit richtig begriffen?

      Es würde mich sehr freuen, wenn Ihr mir noch weiter behilflich
      sein könntet, auf dem Weg zum Verständnis für diese Dinge.

      Gruß
      Ingo

      1. Ich bin mir nun ganrnicht so sicher, ob ich meine Seite
        überhaupt in XHTML machen soll/muss.

        Ingo,
        Du kannst deine Seiten auch in HTML 3.2 machen; aber das willst du ja nicht.

        XHMTL 1.0 zwingt dich gegenüber HTML 4.01 zu genauerer Schreibweise: keine Endtags weglassen, Attributwerte immer in Gänsefüßchen, Groß-/Kleinschreibung. Da du mit den strengeren Regeln vertraut bist, spricht nichts gegen XHTML, im Gegenteil.

        Ich versuche eigentlich immer möglichst wenig bzw. keine
        Sonderzeichen wie z.B. € zu benutzen, sondern anstall lieber "EUR" zu schreiben.

        Damit bist du auf der sicheren Seite. Ich verwende allerdings bedenkenlos „ “ – … €; die Systeme, die das nicht darstellen können, dürften heutzutage in der verschwindenden Minderheit sein.

        Ist es denn im Grunde so, wie ich es jetzt habe,
        vollkommener Unsinn?

        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
        <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

        Zu den Problemen damit hat [molily] ja ausführlich geschrieben.

        Bei XHML also
        • entweder Codierung in ISO 8859-1 mit Angabe der Codierung in der XML-Deklaration, die hier notwendig ist und IEs in den QUirksmodus schickt
        • oder Codierung in UTF-8 mit Angabe der Codierung in der HTTP-EQUIV-Angabe; die XML-Deklaration kann entfallen.

        (Und der Server muss im HTTP-Header die richtige Codierung oder gar keine angeben.)

        Wenn ich nun UTF-8 verwende, muss doch auch mein html-Editor die Seiten in UTF-8 speichern

        Äh, n(j)ein. Du könntest auch "ä" in den Quelltext schreiben und den ISO-8859-1-codiert speichern. Dann steht die Oktettfolge C3 A4 im Dokument ("Ã" ist C3 in ISO 8859-1; "¤" ist A4). Sagst du nun einer verarbeitenden Sofware, das Dokument sei als UTF-8 zu interpretieren, ist C3 A4 ein "ä".

        Aber besser ist natürlich, du schreibst "ä" und speicherst als UTF-8. Was steht dann für "ä" (wenn du das mit einem Hex-Editor anschaust)? Die Oktettfolge C3 A4.

        und mein FTP-Programm die dann in UTF-8 auf den Webspace meines Providers hochladen ... richtig?

        Das FTP-Programm sollte damit gar nichts zu tun haben. Das verändert beim Dateityp A noch die Zeichen für Zeilenumbrüche ja nach System (0D 0A, nur 0D bzw. nur 0A), sollte aber alle anderen Zeichen unverändert lassen.

        Und dann muss ich doch auch noch per .htacess-Datei […]

        (o.a. Möglichkeiten der Serverkonfiguration)

        […] dafür sorgen, dass der Server meines Providers die Dateien UTF-8 codiert an die Browser der User ausliefert.

        Oder dass der Server gar keine Angabe zur Codierung macht. Dann kommt die XML-Deklaration / die HTTP-EQUIV-Angabe ins Spiel.

        Live long and prosper,
        Gunnar

        --
        „Weisheit ist nicht das Ergebnis der Schulbildung, sondern des lebenslangen Versuchs, sie zu erwerben.“ (Albert Einstein)
        1. Lieber Gunnar

          XHMTL 1.0 zwingt dich gegenüber HTML 4.01 zu genauerer Schreibweise: keine Endtags weglassen, Attributwerte immer in Gänsefüßchen, Groß-/Kleinschreibung. Da du mit den strengeren Regeln vertraut bist, spricht nichts gegen XHTML, im Gegenteil.

          Ja, an diese Regeln habe ich mich inzwischen ganz gut gewöhnt.
          Und ich möchte unbedingt gerne auch streng W3C-Konform weitermachen.

          Ich versuche eigentlich immer möglichst wenig bzw. keine
          Sonderzeichen wie z.B. € zu benutzen, sondern anstall lieber "EUR" zu schreiben.

          Damit bist du auf der sicheren Seite. Ich verwende allerdings bedenkenlos „ “ – … €; die Systeme, die das nicht darstellen können, dürften heutzutage in der verschwindenden Minderheit sein.

          OK, ich verstehe.

          Zu den Problemen damit hat [molily] ja ausführlich geschrieben.

          OK, ich habe mir das von [molily] nun nochmal sorgfältig durchgeselen
          und auch das dazugehörige bei selfHTML.
          Und ich glaube, inzwischen habe ich da wieder etwas mehr gescheckt :)

          Bei XHML also
          • entweder Codierung in ISO 8859-1 mit Angabe der Codierung in der XML-Deklaration, die hier notwendig ist und IEs in den QUirksmodus schickt

          Neee, um Gottes Willen, das möchte ich ja nun auf keinen Fall.

          • oder Codierung in UTF-8 mit Angabe der Codierung in der HTTP-EQUIV-Angabe; die XML-Deklaration kann entfallen.

          OK,und diese HTTP-EQUIV-Angabe mache ich dann doch in meiner
          .htaccess-Datei ... gelle?
          Weil ich meine Seite ja ganz normal bei einem Provider
          gehostet habe, wo ich keinen weiteren Zugriff auf den Server habe.

          (Und der Server muss im HTTP-Header die richtige Codierung oder gar keine angeben.)

          Ist das denn nicht damit erreicht, dass ich diese HTTP-EQUIV-Angabe
          per .htaccess-Datei angebe? Doch. oder?

          Aber besser ist natürlich, du schreibst "ä" und speicherst als UTF-8. Was steht dann für "ä" (wenn du das mit einem Hex-Editor anschaust)? Die Oktettfolge C3 A4.

          OK, verstehe.

          Das FTP-Programm sollte damit gar nichts zu tun haben. Das verändert beim Dateityp A noch die Zeichen für Zeilenumbrüche ja nach System (0D 0A, nur 0D bzw. nur 0A), sollte aber alle anderen Zeichen unverändert lassen.

          OK, wenn ich meine Dateien also mit einem Editor schreibe
          und diese dann auf meiner Festplatte schreibe, welche UTF-8 kann,
          ist das Problem gelöst.
          Dann lade ich die mit einem x-beliebigen FTP-Programm auf meinen Webspace
          beim Provider.
          Und wenn ich dann in den Dateien alle Angaben (Doctype) und per
          .htaccess-Datei auch die Angabe der Codierung in der HTTP-EQUIV-Angabe gemacht habe, ist alles korrekt.

          Und dann muss ich doch auch noch per .htacess-Datei […]

          (o.a. Möglichkeiten der Serverkonfiguration)

          Habe ich ja nicht, da meine Seite einfach bei einem Provider gehostet sind.

          […] dafür sorgen, dass der Server meines Providers die Dateien UTF-8 codiert an die Browser der User ausliefert.

          Oder dass der Server gar keine Angabe zur Codierung macht. Dann kommt die XML-Deklaration / die HTTP-EQUIV-Angabe ins Spiel.

          Wie kann ich denn feststellen, ob der Server meines Providers
          Angaben zur Codierung macht oder nicht?

          Gruß
          Ingo

          1. OK,und diese HTTP-EQUIV-Angabe mache ich dann doch in meiner
            .htaccess-Datei ... gelle?

            Nein, Ingo. Dort kannst du angeben, was der Server im HTTP-Header rausschickt.

            Die HTTP-EQUIV-Angabe ist ein Äquivalent (deshalb EQUIV) dazu, die wirksam wird, wenn im HTTP-Header keine entsprechenden Angaben (z.B. zur Zeichencodierung) gemacht werden.

            Die HTTP-EQUIV-Angabe steht im HTML-Quelltext: z.B.
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

            OK, wenn ich meine Dateien also mit einem Editor schreibe
            und diese dann auf meiner Festplatte schreibe, welche UTF-8 kann,

            ?? Die Festplatte kann kein UTF-8. Die kann nur Daten schreiben und lesen. Was das für Daten sind, interessiert sie nicht; die Festplatte interpretiert diese Daten nicht. Ob C3 A4 für "ä" steht oder für "ä" oder für xC3A4 = 50084 oder für xA4C3 = 42179 oder für Instruktionen in Maschinencode, ist der Festplatte völlig egal.

            Live long and prosper,
            Gunnar

            --
            „Weisheit ist nicht das Ergebnis der Schulbildung, sondern des lebenslangen Versuchs, sie zu erwerben.“ (Albert Einstein)
            1. Lieber Ingo

              Nein, Ingo. Dort kannst du angeben, was der Server im HTTP-Header rausschickt.

              Die HTTP-EQUIV-Angabe ist ein Äquivalent (deshalb EQUIV) dazu, die wirksam wird, wenn im HTTP-Header keine entsprechenden Angaben (z.B. zur Zeichencodierung) gemacht werden.

              Die HTTP-EQUIV-Angabe steht im HTML-Quelltext: z.B.
              <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

              Ach so.
              OK neuer Versuch ...
              Wenn meine Dateien vom Edotor UTF-8 codiert auf den Server kopiert sind,
              muss als allererstes in der Datei stehen:

              <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">  
              <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
              

              Und im head-Bereich dann die HTTP-EQUIV-Angabe:
              <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

              Die XML-Deklaration, die den IE in den Quirksmodus schicken würde, kann dann entfallen.

              Und der Server muss im HTTP-Header die richtige Codierung oder gar keine angeben.

              Das müsste doch nun stimmen ... oder?
              Woher weiss ich denn nun eigentlich ob der Server meines Providers
              die richtoge Codierung bzw. eben auch garkeine im HTTP-Header angibt?

              ?? Die Festplatte kann kein UTF-8. Die kann nur Daten schreiben und lesen. Was das für Daten sind, interessiert sie nicht; die Festplatte interpretiert diese Daten nicht. Ob C3 A4 für "ä" steht oder für "ä" oder für xC3A4 = 50084 oder für xA4C3 = 42179 oder für Instruktionen in Maschinencode, ist der Festplatte völlig egal.

              Ja, ist natürlich klar.
              Ich hatte meinen Satz da blöd fomuliert.
              Ich meine natürlich nicht die Fesztplatte, sondern den Editor,
              der die Dateien UTF-8 codiet auf die festplatte speichert.

              Gruß
              Ingo

              1. Hallo Ingo.

                Ach so.
                OK neuer Versuch ...
                [...]
                Das müsste doch nun stimmen ... oder?

                Ja, das hast du richtig verstanden.

                Woher weiss ich denn nun eigentlich ob der Server meines Providers
                die richtoge Codierung bzw. eben auch garkeine im HTTP-Header angibt?

                Dafür gibt es unzählige Möglichkeiten.
                Nutze einen Webservice, welcher dir den Resonse-Header deines Servers anzeigt, oder nutze Wget, oder LiveHTTPHeaders, oder ...

                Einen schönen Sonntag noch.

                Gruß, Ashura

                1. Tach Ashura

                  Ja, das hast du richtig verstanden.

                  Puhhh endlich :)
                  Hat ja ne Weile gedauert, bis ichs kapiert habe.
                  Ist aber auch nicht ganz einfacher Stoff für mich.

                  Dafür gibt es unzählige Möglichkeiten.
                  Nutze einen Webservice, welcher dir den Resonse-Header deines Servers anzeigt, oder nutze Wget, oder LiveHTTPHeaders, oder ...

                  OK, ich werde mir das ales mal ansehen und schauen, ob ich damit klarkomme.
                  Danke für die Tipps jedenfalls.

                  Gruß
                  Ingo

                2. Hallo Ashura nochmal

                  Woher weiss ich denn nun eigentlich ob der Server meines Providers
                  die richtoge Codierung bzw. eben auch garkeine im HTTP-Header angibt?

                  Dafür gibt es unzählige Möglichkeiten ...

                  OK, ich habe nun festgestellt, dass der Server meines Providers
                  keine Angaben zur Zeichensatzkodierung im HTTP-Header macht.

                  Darum habe ich ja nun folgende HTTP-EQUIV-Angabe im <head>-Bereich meiner Datei stehen:
                  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

                  Wenn ich nun per .htaccess-Datei dafür sorge, dass im HTTP-Header
                  eben doch angegeben wird, dass die Datein UTF-8 codiert sind,
                  kann dann die HTTP-EQUIV-Angabe auch entfallen?

                  Gruß
                  Ingo

                  1. Hallo Ingo.

                    Wenn ich nun per .htaccess-Datei dafür sorge, dass im HTTP-Header
                    eben doch angegeben wird, dass die Datein UTF-8 codiert sind,
                    kann dann die HTTP-EQUIV-Angabe auch entfallen?

                    Normalerweise ja, aber wenn jemand eines deiner HTML-Dokumente bei sich lokal abspeichert, ist die HTTP-Equiv-Metaangabe ggf. von Nutzen.

                    Sie also in den Dokumenten zu belassen sollte sowieso eigentlich keinen Mehraufwand darstellen.

                    Einen schönen Sonntag noch.

                    Gruß, Ashura

                    1. Hallo Ashura

                      Normalerweise ja, aber wenn jemand eines deiner HTML-Dokumente bei sich lokal abspeichert, ist die HTTP-Equiv-Metaangabe ggf. von Nutzen.

                      Sie also in den Dokumenten zu belassen sollte sowieso eigentlich keinen Mehraufwand darstellen.

                      OK, habs verstanden. Danke.

                      Gruß
                      Ingo

                  2. Wenn ich nun per .htaccess-Datei dafür sorge, dass im HTTP-Header
                    eben doch angegeben wird, dass die Datein UTF-8 codiert sind, […]

                    Ingo,
                    Warum willst du das tun?

                    Ist dieses Verhalten des Servers nicht vorteilhaft? So können unterschiedlich codierte Dokumente nebeneinander stehen, und jedes wird vom Client entsprechend der im Dokument selbst gemachten Angabe verarbeitet.

                    kann dann die HTTP-EQUIV-Angabe auch entfallen?

                    HTML-Parser geben bei fehlender Angabe (wenn du dir das bspw. lokal, nicht über HTTP) von ISO 8859-1 aus.

                    Um solche Klippen gleich zu umschiffen, würd ich nicht mit dem Gedanken spielen, die Angabe wegzulassen.

                    Live long and prosper,
                    Gunnar

                    --
                    „Weisheit ist nicht das Ergebnis der Schulbildung, sondern des lebenslangen Versuchs, sie zu erwerben.“ (Albert Einstein)
                    1. Lieber Gunnar

                      Ist dieses Verhalten des Servers nicht vorteilhaft? So können unterschiedlich codierte Dokumente nebeneinander stehen, und jedes wird vom Client entsprechend der im Dokument selbst gemachten Angabe verarbeitet.

                      Ahhh, stimmt, alles klar.

                      kann dann die HTTP-EQUIV-Angabe auch entfallen?

                      HTML-Parser geben bei fehlender Angabe (wenn du dir das bspw. lokal, nicht über HTTP) von ISO 8859-1 aus.

                      Um solche Klippen gleich zu umschiffen, würd ich nicht mit dem Gedanken spielen, die Angabe wegzulassen.

                      OK, wird gemacht.

                      Gruß
                      Ingo

              2. muss als allererstes in der Datei stehen:

                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

                <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">

                  
                Wenn deutsch die (Haupt-)Sprache dieses Dokuments ist, ja. ;-)  
                  
                Live long and prosper,  
                Gunnar
                
                -- 
                „Weisheit ist nicht das Ergebnis der Schulbildung, sondern des lebenslangen Versuchs, sie zu erwerben.“ (Albert Einstein)