Steffen: UTF-8 festlegen

0 70

UTF-8 festlegen

Steffen
  • php
  1. 0
    T-Rex
    1. 0
      Gunnar Bittersmann
  2. 0
    Der Martin
    1. 0
      Steffen
      1. 0
        Tom
        1. 0

          UTF-8 festlegen - Autsch

          Steffen
          1. 0
            hotti
            1. 0
              Steffen
              1. 0
                ChrisB
                1. 0
                  Steffen
                  1. 0
                    Gunnar Bittersmann
                    1. 0
                      Steffen
                      1. 0
                        Auge
                        1. 0
                          Tom
                          1. 0
                            Auge
                            1. 0

                              Autsch - falscher Vorposter :-)

                              Tom
                              • menschelei
                          2. 0
                            Steffen
                        2. 0
                          Steffen
                          1. 0
                            Auge
                            1. 0
                              dedlfix
                  2. 0

                    UTF-8 festlegen - PHP kann das nicht durchgehend

                    dedlfix
              2. 1
                hotti
              3. 0
                Tom
          2. 0
            Tom
            1. 0
              Steffen
              1. 0
                ChrisB
              2. 0
                Der Martin
                1. 0
                  Gunnar Bittersmann
                2. 0
                  Steffen
                  1. 0
                    ChrisB
                  2. 0
                    Gunnar Bittersmann
                    1. 0
                      dedlfix
                3. 0
                  Steffen
                  1. 0
                    Der Martin
                    1. 0
                      Steffen
                      1. 0
                        dedlfix
                4. 0
                  Tom
                  1. 0
                    Gunnar Bittersmann
              3. 0

                UTF-8 festlegen, Escaping, Request-Parameter, Response-Daten

                Tom
  3. 0
    Tom
    1. 0

      UTF-8 festlegen, Pragma oder einfeas Meta...

      Tom
  4. 0

    Datei als UTF-8 speichern

    Rowland
    1. 0
      Tom
      1. 0
        Matthias Apsel
        1. 0

          Darstellung vom Ersatzzeichen

          Olaf
        2. 0
          Gunnar Bittersmann
      2. 1
        ChrisB
    2. 0
      Gunnar Bittersmann
      1. 0
        Rowland
        1. 0
          Gunnar Bittersmann
          1. 0
            Rowland
            1. 0
              Gunnar Bittersmann
              1. 0
                Rowland
                1. 0
                  Gunnar Bittersmann
                2. 0
                  1UnitedPower
            2. 0
              Tom
              1. 0
                Gunnar Bittersmann
                1. 0
                  Tom
        2. 0
          1UnitedPower
        3. 0
          Matthias Apsel
      2. 0
        WernerK
        1. 0
          Matthias Apsel
        2. 0
          Gunnar Bittersmann
          1. 0
            WernerK
            1. 0
              Der Martin
              1. 0
                WernerK
                1. 0
                  Der Martin
                2. 0
                  Gunnar Bittersmann
                3. 0
                  Tom

Hallo,
ich beginne mein PHP-Programm mit

<?php  
header('Content-Type: text/html; charset=UTF-8');  
echo <<<TXT  
<!DOCTYPE html>  
<html lang="de">  
<head>  
<meta charset="UTF-8">  
....  
</head>  
<body>  
TXT;

Ist dies so ausreichend, zuviel, zuwenig oder gar komplett falsch,
wenn ich in dem Programm UTF-8 ohne BOM Textdateien lesen und schreiben möchte und auch HTML-Ausgaben UTF-8 kodiert sein sollen?

Im Augenblick wird nämlich Ö (in der Eingabe) als weißes ? (im schwarzen Quadrat) im erzeugten HTML-Dokument und bei echo-Ausgaben im PHP-Programm dargestellt.

(Das Programm ist sehr umfangreich, so dass ich es ungern hier poste)
Viele G. Steffen

  1. header('Content-Type: text/html; charset=UTF-8');

    unnötig.
    charset im meta reicht. Wenn du deine Dateien dann noch schön codierst wie du es sagst, dann passt alles.
    Wenn dein Inhalt jedoch aus einer Datenbank kommt sind das andere mögliche Fehlerquellen.

    und da ich sicherlich wieder irgendein Fachwort in dem Zusammenhang benutzt habe, wird sich Gunnar auch gleich nochmal melden :D.

    Gruß
    wartender
    T-Rex

    1. @@T-Rex:

      nuqneH

      header('Content-Type: text/html; charset=UTF-8');

      unnötig.
      charset im meta reicht.

      Nein. Wenn der Server als Default eine andere Codierungsangabe im HTTP-Header setzt …

      und da ich sicherlich wieder irgendein Fachwort in dem Zusammenhang benutzt habe, wird sich Gunnar auch gleich nochmal melden :D.

      Da isser. ;-) Wozu schreib ich den den ganzen Kram auf gut deutsch? Zum Lesen!

      Qapla'

      --
      „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
  2. Hi,

    Im Augenblick wird nämlich Ö (in der Eingabe) als weißes ? (im schwarzen Quadrat) im erzeugten HTML-Dokument und bei echo-Ausgaben im PHP-Programm dargestellt.

    das ist dann ein relativ sicheres Zeichen, dass der aus _dieser_ Quelle stammende Text eben _nicht_ in UTF-8 codiert ist, sondern vermutlich irgendeine 1-Byte-Codierung wie ISO-8859-x, so dass Bytesequenzen auftreten, die in UTF-8 ungültig sind.

    Ciao,
     Martin

    --
    Ich denke, also bin ich hier falsch.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hi,

      das ist dann ein relativ sicheres Zeichen, dass der aus _dieser_ Quelle stammende Text eben _nicht_ in UTF-8 codiert ist, sondern vermutlich irgendeine 1-Byte-Codierung wie ISO-8859-x, so dass Bytesequenzen auftreten, die in UTF-8 ungültig sind.

      Doch, die Eingabe ist in UTF-8 codiert, und ich habe jetzt auch die Ursache.
      Ich möchte das erste Zeichen eines Strings verwenden für Vergleiche u.a., also
      substr($text(0,1)).
      Das geht aber bei Umlauten schief:

        
      <?php  
      header('Content-Type: text/html; charset=UTF-8');  
      echo <<<TXT  
      <!DOCTYPE html>  
      <html lang="de">  
      <head>  
      <meta charset="UTF-8">  
      </head>  
      <body>  
      TXT;  
        
        
         $string='Apfel';  
         $key = substr($string,0,1);  
         echo "$key <br>";             // => A   ok  
        
         $string='Äpfel';  
         $key = substr($string,0,1);  
         echo "$key <br>";             // => ?   (hex'c3')  
        
         $key = substr($string,0,2);  
         echo "$key <br>";             // => Ä   ok  
        
        
      echo <<<TXT  
      </body>  
      </html>  
      TXT;  
      ?>
      

      Nun weiß ich doch zunächst nicht, ob das gewünschte Zeichen ein Umlaut ist, um dann zu entscheiden, ob ich mit substr 1 oder zwei Bytes lese.
      Wie löst man das am einfachsten?
      Danke Steffen

      1. Hello,

        Doch, die Eingabe ist in UTF-8 codiert, und ich habe jetzt auch die Ursache.
        Ich möchte das erste Zeichen eines Strings verwenden für Vergleiche u.a.,

        $string='Äpfel';
           $key = substr($string,0,1);
           echo "$key <br>";             // => ?   (hex'c3')

        Wenn Du multibytecodierte Texte benutzt, dann solltest Du auch die passenden Funktionen dafür benutzen:

        http://de1.php.net/manual/en/function.mb-substr.php

        Das sollte dann auch durchgängig durchgehalten werden im ganzen Projekt.

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bikers-lodge.com
        1. Hallo,

          http://de1.php.net/manual/en/function.mb-substr.php

          Das sollte dann auch durchgängig durchgehalten werden im ganzen Projekt.

          Ach Du großer Schreck! Das heißt Arbeit.
          Aber schon am Anfang scheitere ich:

          <?php  
          header('Content-Type: text/html; charset=UTF-8');  
          echo <<<TXT  
          <!DOCTYPE html>  
          <html lang="de">  
          <head>  
          <meta charset="UTF-8">  
          </head>  
          <body>  
          TXT;  
            
            
             $string='Apfel';  
             $key = mb_substr($string,0,1);  
             echo "$key <br>";             // => A  
            
             $string='Äpfel';  
             $key = mb_substr($string,0,1);  
             echo "$key <br>";             // => ?  
            
             $string='Apfel';  
             $key = mb_substr($string,0,2);  
             echo "$key <br>";             // => Ap  
            
             $string='Äpfel';  
             $key = mb_substr($string,0,2);  
             echo "$key <br>";             // => Ä  
            
            
          echo <<<TXT  
          </body>  
          </html>  
          TXT;  
          ?>  
          
          
          1. hi,

            Ach Du großer Schreck! Das heißt Arbeit.
            Aber schon am Anfang scheitere ich:

              
            $string = '€123';  
            $s = mb_substr($string,0,1, 'utf-8');  
            echo $s ; // €  
            
            

            Ergo: in der Verwendung der Funktion das Encoding angeben, und schon funktioniert das richtig.

            Horst Flegel

            1. hi,

              Ach Du großer Schreck! Das heißt Arbeit.
              Aber schon am Anfang scheitere ich:

              $string = '€123';
              $s = mb_substr($string,0,1, 'utf-8');
              echo $s ; // €

              
              >   
              > Ergo: in der Verwendung der Funktion das Encoding angeben, und schon funktioniert das richtig.  
              >   
              
              Das stimmt, aber wozu muss ich die Codierung hier noch einmal angeben, wenn schon - wie aus den Anfangsbeiträgen hervorgeht - alles auf UTF-8 eingestellt ist?  
              Gruß  
              Steffen
              
              1. Hi,

                $string = '€123';
                $s = mb_substr($string,0,1, 'utf-8');
                echo $s ; // €

                
                > >   
                > > Ergo: in der Verwendung der Funktion das Encoding angeben, und schon funktioniert das richtig.  
                > >   
                > Das stimmt, aber wozu muss ich die Codierung hier noch einmal angeben, wenn schon - wie aus den Anfangsbeiträgen hervorgeht - alles auf UTF-8 eingestellt ist?  
                  
                Weil noch \*nicht\* „alles” auf UTF-8 eingestellt war.  
                  
                Oder hattest du etwa [mbstring.internal-encoding](http://www.php.net/manual/en/mbstring.configuration.php#ini.mbstring.internal-encoding) schon auf UTF-8 gesetzt …?  
                  
                MfG ChrisB  
                  
                
                -- 
                RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
                
                1. Hallo,

                  Das stimmt, aber wozu muss ich die Codierung hier noch einmal angeben, wenn schon - wie aus den Anfangsbeiträgen hervorgeht - alles auf UTF-8 eingestellt ist?

                  Weil noch *nicht* „alles” auf UTF-8 eingestellt war.

                  Oder hattest du etwa mbstring.internal-encoding schon auf UTF-8 gesetzt …?

                  Ich war nach den ersten Antworten in dem Thread tatsächlich der Meinung, dass nun alles auf UTF-8 eingestellt ist.
                  Muss ich nun bei jeder neuen Funktion, die ich verwenden werde, suchen, ob dazu ein Parameter auf 'UTF-8' zu setzen ist?
                  Wäre es nicht denkbar (in jedem Fall sinnvoll) einen Parameter in PHP angeben zu können:
                  "allovercoding=UTF", der alles auf 'UTF-8' einstellt?
                  Schönen Dank an alle für die bisherige Hilfe
                  Steffen

                  1. @@Steffen:

                    nuqneH

                    Oder hattest du etwa mbstring.internal-encoding schon auf UTF-8 gesetzt …?

                    Wäre es nicht denkbar (in jedem Fall sinnvoll) einen Parameter in PHP angeben zu können:
                    "allovercoding=UTF", der alles auf 'UTF-8' einstellt?

                    Lesen ist nicht deine Stärke, oder?

                    Qapla'

                    --
                    „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                    1. Wäre es nicht denkbar (in jedem Fall sinnvoll) einen Parameter in PHP angeben zu können:
                      "allovercoding=UTF", der alles auf 'UTF-8' einstellt?

                      Lesen ist nicht deine Stärke, oder?

                      Der zitierte Text gibt allerdings keine Antwort auf meine Frage.
                      Steffen

                      1. Hallo

                        Wäre es nicht denkbar (in jedem Fall sinnvoll) einen Parameter in PHP angeben zu können:
                        "allovercoding=UTF", der alles auf 'UTF-8' einstellt?

                        Lesen ist nicht deine Stärke, oder?

                        Der zitierte Text gibt allerdings keine Antwort auf meine Frage.

                        Wieso nicht? „Defines the default internal character encoding.“ heißt für mich, dass dort die Standardkodierung angegeben ist. Du wolltest einen Parameter haben, mit dem du die Kodierung vorgeben kannst. Et voila, da isser.

                        Tschö, Auge

                        --
                        Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                        Terry Pratchett, "Wachen! Wachen!"
                        ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                        Veranstaltungsdatenbank Vdb 0.3
                        1. Hello,

                          Der zitierte Text gibt allerdings keine Antwort auf meine Frage.

                          Wieso nicht? „Defines the default internal character encoding.“ heißt für mich, dass dort die Standardkodierung angegeben ist. Du wolltest einen Parameter haben, mit dem du die Kodierung vorgeben kannst. Et voila, da isser.

                          ... mit der Einschränkung, die schon Dedlfix erwähnt hat, dass die "zentrale Einstellung" der Codierung nur auf die neueren Funktionen wirkt, die für Multibyteverarbeitung vorgesehen sind.

                          Die älteren Funktionen (die durchaus oft noch weiterhin sinnvoll sind), nehmen eben keine Rücksicht darauf.

                          Bevor ich eine Funktion in PHP nutze, schaue ich immer nochmal ins Manual, ob ich nicht z.B. Attribute vergessen oder vertauscht habe. In der Attributreihenfolge ist PHP leider sehr inkonsequent.

                          Und wenn ich dann schon die Beschreibung auf dem Schirm habe, schaue ich in den Abschnitt "See also"

                          Beispiel:

                          http://de3.php.net/manual/en/function.substr.php#refsect1-function.substr-seealso

                          und folge den Links dort. Dann wärst Du schon von selber darauf gekommen, dass es eine Funktion gibt, die deine Anforderungen besser erfüllt, bzw. dass die ausgewählte dies nämlich nicht tut.

                          -------------------------

                          Wir wollen Dich überigens nicht ärgern, wenn wir dieses ganze Zeugs erzählen, sondern Dir unsere Erfahrungen zur Verfügung stellen, damit du nicht alles selbst herausfinden musst.

                          Wenn Dich das nicht interessiert, könnte es allerdings sein, dass Programmierung nicht das passende Arbeitsfeld für dich ist, dann wäre vielleicht Archäologie besser ;-)

                          Liebe Grüße aus dem schönen Oberharz

                          Tom vom Berg

                          --
                           ☻_
                          /▌
                          / \ Nur selber lernen macht schlau
                          http://bikers-lodge.com
                          1. Hallo

                            Wir wollen Dich überigens nicht ärgern, wenn wir dieses ganze Zeugs erzählen, sondern Dir unsere Erfahrungen zur Verfügung stellen, damit du nicht alles selbst herausfinden musst.

                            Ok, merk' ich mir.

                            Wenn Dich das nicht interessiert, könnte es allerdings sein, dass Programmierung nicht das passende Arbeitsfeld für dich ist, dann wäre vielleicht Archäologie besser ;-)

                            Archäologie, auch nicht schlecht.

                            Tschö, Auge

                            --
                            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                            Terry Pratchett, "Wachen! Wachen!"
                            ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                            Veranstaltungsdatenbank Vdb 0.3
                            1. Hello Auge,

                              Wir wollen Dich überigens nicht ärgern, wenn wir dieses ganze Zeugs erzählen, sondern Dir unsere Erfahrungen zur Verfügung stellen, damit du nicht alles selbst herausfinden musst.

                              Ok, merk' ich mir.

                              *huch*

                              Da bist Du irgendwie dazwischen gerutscht beim Antworten

                              Zum Glück hast Du ja Humor :-)

                              Liebe Grüße aus dem schönen Oberharz

                              Tom vom Berg

                              --
                               ☻_
                              /▌
                              / \ Nur selber lernen macht schlau
                              http://bikers-lodge.com
                          2. Hallo Tom
                            ich bin Euch ja dankbar für die vielen Tipps, wenn ich jetzt allerdings alles lesen muss, was Ihr verlinkt (inkl. "See also" und alle weiterführenden links), so schaffe ich die Umstellung auf UTF-8 in 2 Jahren nicht - dabei klingt das in vielen Beiträgen so einfach (Stell einfach um auf UTF-8 und Du bist alle Sorgen los ;-).
                            Also wie geschrieben, danke, und ich habe schon viel gelernt ohne das o.g. Literaturstudium.
                            Schönen Gruß
                            Steffen

                        2. Der zitierte Text gibt allerdings keine Antwort auf meine Frage.

                          Wieso nicht?

                          Weil meine Frage war:

                          Muss ich nun bei jeder neuen Funktion, die ich verwenden werde, suchen, ob dazu ein Parameter auf 'UTF-8' zu setzen ist?
                          Gruß
                          Steffen

                          1. Hallo

                            Der zitierte Text gibt allerdings keine Antwort auf meine Frage.

                            Wieso nicht?
                            Weil meine Frage war:

                            Muss ich nun bei jeder neuen Funktion, die ich verwenden werde, suchen, ob dazu ein Parameter auf 'UTF-8' zu setzen ist?

                            Jein, eine deiner Fragen war, ob man zentral einstellen kann, dass man UTF-8 als Kodierung nutzt. Und genau das kannst du damit machen. Und wenn du auf die Einstellung keinen Zugriff hast, geht's auch mit einer Funktion. Die muss dann aber auch explizit aufgerufen werden. Praktisch würde ich das in einer Skriptdatei, die immer aufgerufen wird (z.B. per require_once), tun, damit ich sicher sein kann, dass der Aufruf stets erfolgt.

                            Tschö, Auge

                            --
                            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                            Terry Pratchett, "Wachen! Wachen!"
                            ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                            Veranstaltungsdatenbank Vdb 0.3
                            1. Tach!

                              Jein, eine deiner Fragen war, ob man zentral einstellen kann, dass man UTF-8 als Kodierung nutzt. Und genau das kannst du damit machen. Und wenn du auf die Einstellung keinen Zugriff hast, geht's auch mit einer Funktion.

                              Um das nochmal deutlich hervorzuheben, das betrifft nur die Funktionen der Multibyte-String-Extension und nichts weiter in PHP. Andere Ecken haben eigene Möglichkeiten (Perl-RegExp zum Beispiel) oder auch nicht.

                              dedlfix.

                  2. Tach!

                    Muss ich nun bei jeder neuen Funktion, die ich verwenden werde, suchen, ob dazu ein Parameter auf 'UTF-8' zu setzen ist?

                    Ja.

                    Wäre es nicht denkbar (in jedem Fall sinnvoll) einen Parameter in PHP angeben zu können:
                    "allovercoding=UTF", der alles auf 'UTF-8' einstellt?

                    Schön wär's, aber PHP hat noch keine eingebaute durchgängige UTF-8-Unterstützung. So bleibt dir nichts anderes übrig, als die speziellen Extensions und Funktionsparameter zu verwenden, wenn es welche für UTF-8 gibt, und ansonsten zu beachten, dass die verwendeten Funktionen dann eben nicht uneingeschränkt UTF-8-geeignet sind.

                    dedlfix.

              2. Moin Steffen,

                Das stimmt, aber wozu muss ich die Codierung hier noch einmal angeben, wenn schon - wie aus den Anfangsbeiträgen hervorgeht - alles auf UTF-8 eingestellt ist?

                In Deiner PHP-Datei steht eine Bytesequenz, Du hast die gespeichert als UTF-8. Nehmen wir die Bytesequenz 0xE2 0x82 0xAC 0x31 0x32 0x33 was im Editor oder im Browser die Zeichenfolge

                €123

                ergibt. Nun ist das erste Zeichen gefragt. Hmm, die mb_FUNKTION muss jetzt wissen, welche Bytes zu welchen Zeichen gehören. Also muss der mb_FUNKTION die Kodierung bekannt sein. Wenn Du das nicht bekanntgibst (zentral in der php.ini oder im Funktionsargument) wird mb_substr() eine Default-Einstellung verwenden, die durchaus auch ISO-8859-1 sein kann. In einem solchen Fall wird mb_substr('€123',1,0) annehmen, 0xE2 wäre das erste Zeichen.

                Ist hingegen mb_substr('€123',1,0, 'utf-8') die Kodierung bekannt, werden die Bytes 0xE2 0x82 0xAC als EIN Zeichen betrachtet und das ist das €-Zeichen.

                Horst

              3. Hello,

                Ergo: in der Verwendung der Funktion das Encoding angeben, und schon funktioniert das richtig.

                Das stimmt, aber wozu muss ich die Codierung hier noch einmal angeben, wenn schon - wie aus den Anfangsbeiträgen hervorgeht - alles auf UTF-8 eingestellt ist?

                Ist es eben nicht. Dann hätte es doch geklappt!

                Was meinst Du, warum ich Dich auf
                http://de3.php.net/manual/en/function.mb-internal-encoding.php
                hingewiesen hatte? Damit kannst Du die für die gesamte Scriptlaufzeit geltende Codierung _einstellen_.

                Und wenn Du nicht weißt, wie die Codierungen heißen, dann frage mit
                http://de3.php.net/manual/en/function.mb-list-encodings.php

                Liebe Grüße aus dem schönen Oberharz

                Tom vom Berg

                --
                 ☻_
                /▌
                / \ Nur selber lernen macht schlau
                http://bikers-lodge.com
          2. Hello,

            das ist schon ganz schön verknotet bei Dir :-O

            http://de1.php.net/manual/en/function.mb-substr.php

            Das sollte dann auch durchgängig durchgehalten werden im ganzen Projekt.

            Ach Du großer Schreck! Das heißt Arbeit.
            Aber schon am Anfang scheitere ich:

            <?php

            header('Content-Type: text/html; charset=UTF-8');
            echo <<<TXT
            <!DOCTYPE html>
            <html lang="de">
            <head>
            <meta charset="UTF-8">
            </head>
            <body>
            TXT;

            $string='Apfel';
               $key = mb_substr($string,0,1);
               echo "$key <br>";             // => A

            $string='Äpfel';
               $key = mb_substr($string,0,1);
               echo "$key <br>";             // => ?

            $string='Apfel';
               $key = mb_substr($string,0,2);
               echo "$key <br>";             // => Ap

            $string='Äpfel';
               $key = mb_substr($string,0,2);
               echo "$key <br>";             // => Ä

            echo <<<TXT
            </body>
            </html>
            TXT;
            ?>

              
            Lass Dir mal <http://de1.php.net/manual/en/function.mb-internal-encoding.php> augeben.  
              
            Und gewöhn Dir an, Ausgaben, die im HTML-Kontext landen, gleich richtig zu behandeln  
              
            <http://de1.php.net/manual/en/function.htmlspecialchars.php>  
              
              
            Und hast Du auch mal in den Quelltext im Browser geschaut, was dort angekommen ist?  
              
            Denke daran, dass der Editor des Browsers (Quelltextanzeige) auch schon cooked arbeitet, also die seiner Meinung nach passende Decodierung benutzt.  
              
              
              
              
              
            Liebe Grüße aus dem schönen Oberharz  
              
              
            Tom vom Berg  
            ![](http://selfhtml.bitworks.de/Virencheck.gif)  
              
            
            -- 
             ☻\_  
            /▌  
            / \ Nur selber lernen macht schlau  
            <http://bikers-lodge.com>
            
            1. Hallo Tom,
              die Lösung (zu der ich aber jetzt noch eine Frage habe), hat ja hotti geliefert.

              Und gewöhn Dir an, Ausgaben, die im HTML-Kontext landen, gleich richtig zu behandeln

              http://de1.php.net/manual/en/function.htmlspecialchars.php

              Meinst Du damit, ich solle z.B. ö als &ouml; darstellen?
              Ein Vorteil von UTF-8 wäre aber doch gerade, dass man dies nicht mehr machen muss.
              Gruß
              Steffen

              1. Hi,

                Und gewöhn Dir an, Ausgaben, die im HTML-Kontext landen, gleich richtig zu behandeln

                http://de1.php.net/manual/en/function.htmlspecialchars.php

                Meinst Du damit, ich solle z.B. ö als &ouml; darstellen?

                Ist das etwa, was die Funktion laut Beschreibung macht …?

                MfG ChrisB

                --
                RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
              2. Hi,

                Und gewöhn Dir an, Ausgaben, die im HTML-Kontext landen, gleich richtig zu behandeln
                http://de1.php.net/manual/en/function.htmlspecialchars.php
                Meinst Du damit, ich solle z.B. ö als &ouml; darstellen?

                neiiiin!
                Was meinst du, warum Tom ausgerechnet die dafür geeignete Funktion htmlspecialchars() verlinkt hat? Die codiert genau die Zeichen um, für die das in HTML notwendig ist, also '<', '>', '&' und '"', und lässt andere Zeichen in Ruhe.

                Ein Vorteil von UTF-8 wäre aber doch gerade, dass man dies nicht mehr machen muss.

                Ja, eben.

                Ciao,
                 Martin

                --
                Früher habe ich mich vor der Arbeit gedrückt. Heute könnte ich stundenlang zusehen.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                1. @@Der Martin:

                  nuqneH

                  Ein Vorteil von UTF-8 wäre aber doch gerade, dass man dies nicht mehr machen muss.

                  Ja, eben.

                  Eben.

                  Qapla'

                  --
                  „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                2. Hallo

                  Und gewöhn Dir an, Ausgaben, die im HTML-Kontext landen, gleich richtig zu behandeln
                  http://de1.php.net/manual/en/function.htmlspecialchars.php
                  Meinst Du damit, ich solle z.B. ö als &ouml; darstellen?

                  neiiiin!
                  Was meinst du, warum Tom ausgerechnet die dafür geeignete Funktion htmlspecialchars() verlinkt hat? Die codiert genau die Zeichen um, für die das in HTML notwendig ist, also '<', '>', '&' und '"', .....

                  ... aber doch auch die Umlaute, um die es mir in diesem Thread ging.
                  Ich weiß jetzt nicht, was Tom meinte, was ich in meinem Beispiel umcodieren sollte?
                  Das Beispiel funktioniert doch jetzt ohne eine Umcodierung.
                  Schönen Gruß
                  Steffen

                  1. Hi,

                    Was meinst du, warum Tom ausgerechnet die dafür geeignete Funktion htmlspecialchars() verlinkt hat? Die codiert genau die Zeichen um, für die das in HTML notwendig ist, also '<', '>', '&' und '"', .....

                    ... aber doch auch die Umlaute

                    Nei-en. Steht das etwa irgendwo in der Beschreibung der Funktion?

                    MfG ChrisB

                    --
                    RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
                  2. @@Steffen:

                    nuqneH

                    Was meinst du, warum Tom ausgerechnet die dafür geeignete Funktion htmlspecialchars() verlinkt hat? Die codiert genau die Zeichen um, für die das in HTML notwendig ist, also '<', '>', '&' und '"', .....

                    ... aber doch auch die Umlaute, um die es mir in diesem Thread ging.

                    Lesen ist nicht deine Stärke, oder?

                    Ich weiß jetzt nicht, was Tom meinte, was ich in meinem Beispiel umcodieren sollte?

                    Dass hinter jedes echo ein htmlspecialchars() gehört.

                    Das Beispiel funktioniert doch jetzt ohne eine Umcodierung.

                    In deinem Beispiel liegen die Werte von $string und $key in der Kontrolle deines Scripts, ja.

                    Das ändert sich schlagartig, sobald du Nutzereingaben verarbeitest, die per se als böse anzusehen sind.

                    Qapla'

                    --
                    „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                    1. Tach!

                      In deinem Beispiel liegen die Werte von $string und $key in der Kontrolle deines Scripts, ja.

                      Das ändert sich schlagartig, sobald du Nutzereingaben verarbeitest, die per se als böse anzusehen sind.

                      Bitte nicht auf Benutzereingaben beschränken. Vielmehr ist die Datenquelle beim kontextgerechten Behandeln der Werte für die Ausgabe komplett uninteressant. Alle Daten müssen dem Kontext gerecht kodiert werden, nicht nur spezielle.

                      dedlfix.

                3. Hi,

                  Was meinst du, warum Tom ausgerechnet die dafür geeignete Funktion htmlspecialchars() verlinkt hat? Die codiert genau die Zeichen um, für die das in HTML notwendig ist, also '<', '>', '&' und '"', und lässt andere Zeichen in Ruhe.

                  Ich verwende weder Javascript noch andere Scriptsprachen. Benutzereingaben werden strengstens geprüft.
                  Wie soll dann noch Schadcode (bei Nichtcodierung obiger Sonderzeichen) eingeschleust werden?
                  Gruß
                  Steffen

                  1. Moin,

                    Was meinst du, warum Tom ausgerechnet die dafür geeignete Funktion htmlspecialchars() verlinkt hat? Die codiert genau die Zeichen um, für die das in HTML notwendig ist, also '<', '>', '&' und '"', und lässt andere Zeichen in Ruhe.
                    Ich verwende weder Javascript noch andere Scriptsprachen.

                    das ist okay, tut aber nichts zur Sache.

                    Benutzereingaben werden strengstens geprüft.

                    Sollte auch selbstverständlich sein, hat aber auch nichts mit der Frage zu tun.

                    Wie soll dann noch Schadcode (bei Nichtcodierung obiger Sonderzeichen) eingeschleust werden?

                    Wer spricht von Schadcode? Okay, im weitesten Sinn mag der Ausdruck sogar passen. Aber hier geht's um grundlegende Prinzipien: Wenn Daten von einem Kontext (hier: String in PHP) in einen anderen übergehen (hier: HTML), dann müssen die Regeln des Zielkontexts beachtet werden. Und das bedeutet in HTML beispielsweise, dass die oben genannten Zeichen nicht unmaskiert stehen dürfen, wenn sie als normaler Text gelten sollen.

                    Vielleicht ist dir gar nicht klar, wie trivial solche Problemkandidaten aussehen können: So wird etwa der String "paste&copy" ebenso für Überraschungen sorgen wie "Wir haben festgestellt, dass immer r<1.25 gilt", wenn kein geeignetes Escaping verwendet wird. Dagegen kann mit "übles Ölkännchen" nichts passieren - sofern die Zeichencodierung passt.

                    Wie gesagt, das ist kein "Sonderfall", den man "eventuell" oder "in komlexen Fällen" beachten muss - das ist Grundlage, das sollte einem so in Fleisch und Blut übergehen, dass man es instinktiv tut.

                    Ciao,
                     Martin

                    --
                    F: Was sagt die kleine Kerze zur großen Kerze?
                    A: Ich gehe heute nacht aus!
                    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                    1. Hallo,

                      Vielleicht ist dir gar nicht klar, wie trivial solche Problemkandidaten aussehen können: So wird etwa der String "paste&copy" ebenso für Überraschungen sorgen wie "Wir haben festgestellt, dass immer r<1.25 gilt", wenn kein geeignetes Escaping verwendet wird. Dagegen kann mit "übles Ölkännchen" nichts passieren - sofern die Zeichencodierung passt.

                      Ich muss gestehen, dass mir dies nicht klar ist. Kennst Du (kennt Ihr) vielleicht eine einfache deutsche Behandlung dieses Themas mit Beispielen für Linkshänder und Einäugige?
                      Gruß
                      Steffen

                      1. Tach!

                        Vielleicht ist dir gar nicht klar, wie trivial solche Problemkandidaten aussehen können: So wird etwa der String "paste&copy" ebenso für Überraschungen sorgen wie "Wir haben festgestellt, dass immer r<1.25 gilt", wenn kein geeignetes Escaping verwendet wird. Dagegen kann mit "übles Ölkännchen" nichts passieren - sofern die Zeichencodierung passt.

                        Und wie ich schon an anderer Stelle schrieb, ist es dabei unerheblich woher die Daten kommen und wie gut sie gefiltert wurden. Zu viel Filterung ist oftmals auch kontraproduktiv, besonders wenn dabei erwünschte Information verlorengeht, beispielsweise Zeichen im Code in einem Kommentar eines Blog über Webzeugs oder Programmierung.

                        Ich muss gestehen, dass mir dies nicht klar ist. Kennst Du (kennt Ihr) vielleicht eine einfache deutsche Behandlung dieses Themas mit Beispielen für Linkshänder und Einäugige?

                        Allgemein und speziell: Kontextwechsel

                        dedlfix.

                4. Hello,

                  neiiiin!

                  *stimmt*

                  Was meinst du, warum Tom ausgerechnet die dafür geeignete Funktion htmlspecialchars() verlinkt hat? Die codiert genau die Zeichen um, für die das in HTML notwendig ist, also '<', '>', '&' und '"', und lässt andere Zeichen in Ruhe.

                  Ein Vorteil von UTF-8 wäre aber doch gerade, dass man dies nicht mehr machen muss.

                  Das musste man auch bei ISO8859-1 nicht mehr. Hat Sven Rautenberg lange geprdigt damals. Ich erinnere mich noch gut :-)

                  Liebe Grüße aus dem schönen Oberharz

                  Tom vom Berg

                  --
                   ☻_
                  /▌
                  / \ Nur selber lernen macht schlau
                  http://bikers-lodge.com
                  1. @@Tom:

                    nuqneH

                    Meinst Du damit, ich solle z.B. ö als &ouml; darstellen?
                    Ein Vorteil von UTF-8 wäre aber doch gerade, dass man dies nicht mehr machen muss.

                    Das musste man auch bei ISO8859-1 nicht mehr.

                    Für ö nicht, für Anführungszeichen und Gedankenstriche aber.

                    Qapla'

                    --
                    „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
              3. Hello,

                Hallo Tom,
                die Lösung (zu der ich aber jetzt noch eine Frage habe), hat ja hotti geliefert.

                Jein. Hotti hat Dir nur eine Stelle genannt, an der Du das Funktionsargument _jedes_Mal_ mit übergeben musst. Ich habe Dir eine Möglichkeit genannt, wie Du das Argument einmal am Anfang des Scriptes festlegen kannst. Dann Wird er von PHP automatisch gesetzt und vor Allem ist das Encoding dann eindeutig festgelegt.

                Und gewöhn Dir an, Ausgaben, die im HTML-Kontext landen, gleich richtig zu behandeln

                http://de1.php.net/manual/en/function.htmlspecialchars.php

                Meinst Du damit, ich solle z.B. ö als &ouml; darstellen?
                Ein Vorteil von UTF-8 wäre aber doch gerade, dass man dies nicht mehr machen muss.
                Gruß
                Steffen

                Schau hier im Archiv oder bei Google mal nach dem Stichwort "Affenformular". Die "Affenformular-Übung" sollte man am Anfang immer ganz ausführlich durcharbeiten nach allen Regeln der Kunst. Daran kann man dann alles über

                • Codierung

                • Escaping

                • $_POST

                • $_GET

                • Umgang mit Sessions und Cookies

                • $_SESSION

                • $_COOKIE

                • Umgang mit dem Fileupload (ein File, mehrere Files)

                • $_FILES

                • Umgang mit Formularen

                • was ist ein Roundturn?

                • usw.

                lernen. Zur Kontrolle lässt man sich in jeder Response die gewünschten Kontrollausgaben mitsenden

                Beispiel:

                  
                echo "<pre>\r\n";  
                echo htmlspecialchars(print_r($_POST,1)) . "\r\n";  
                echo htmlspecialchars(print_r($_SESSION,1)) . "\r\n";  
                echo "</pre>\r\n";  
                
                

                So siehst Du am besten, was da so passiert bei einer "Datenrunde"

                Liebe Grüße aus dem schönen Oberharz

                Tom vom Berg

                --
                 ☻_
                /▌
                / \ Nur selber lernen macht schlau
                http://bikers-lodge.com
  3. Hello,

    ich beginne mein PHP-Programm mit

    <?php

    header('Content-Type: text/html; charset=UTF-8');
    echo <<<TXT
    <!DOCTYPE html>
    <html lang="de">
    <head>
    <meta charset="UTF-8">
    ....
    </head>
    <body>
    TXT;

      
    Ich habe da mal gerlernt:  
      
        <meta http-equiv="content-type" content="text/html; charset=utf-8">  
      
    @ Gunnar: reicht das jetzt auch in der obigen "Kurzschreibweise" von Steffen?  
      
    Den Header für den Server würde ich auf jeden Fall festlegen, wenn ich nicht wirklich garantieren kann, was der sonst sendet. Ich hatte das gerade erst, dass der Server überhaupt keine Angabe gemacht hat zum Character-Set und obwohl die Meta-Angabe drinsteht, haben einige Browser dann gezickt.  
      
      
      
      
    Liebe Grüße aus dem schönen Oberharz  
      
      
    Tom vom Berg  
    ![](http://selfhtml.bitworks.de/Virencheck.gif)  
      
    
    -- 
     ☻\_  
    /▌  
    / \ Nur selber lernen macht schlau  
    <http://bikers-lodge.com>
    
    1. Hello,

      <meta charset="UTF-8">

      Die Frage hat sich geklärt. Manchmal hilft es wirklich, Gunnars Übersetzungen zu lesen ;-))

      http://www.w3.org/International/questions/qa-html-encoding-declarations

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://bikers-lodge.com
  4. Hola Steffen,

    Ist dies so ausreichend, zuviel, zuwenig oder gar komplett falsch,

    In der Regel reicht die Angabe im HTML Code, dass du UTF-8 nutzt. Aber die Angabe im HTML Code muss auf jeden Fall da sein. Ansonsten was Gunnar erwähnt hat beachten. In der Regel ist UTF-8 aber zumindest was die europäische Seite anbelangt, Standard. D.H. du wirst eigentlich keinen seriösen Anbieter in der EU finden, der das nicht auf UTF-8 hat. Zumindest hoffe ich das stark. :))
    Mit einem kleinen, wehleidigen Blick Richtung Tom, dem doch sowas passiert ist. Ich sehe aber bei dir, dass du das schon mit PHP gemacht hast und dennoch nicht funktioniert.

    Im Augenblick wird nämlich Ö (in der Eingabe) als weißes ? (im schwarzen Quadrat) im erzeugten HTML-Dokument und bei echo-Ausgaben im PHP-Programm dargestellt.

    So, wenn dir jetzt keiner der Tipps geholfen hat, die hier erwähnt wurden, dann kann es nur noch an einer Sache liegen. An deiner Datei selbst.
    Wenn du die z.B. als ANSI speicherst, aber im Dokument UTF-8 angibst, kommt es zu Fehlern. Die ersten 127 Zeichen stimmen bei beiden Zeichenkodierungen überein, die restlichen nicht. Und weil die ersten eben nur englische Buchstaben enthalten, kommt es zu keiner Übereinstimmung mehr.

    Das kannst du so umgehen...
    1. Erstelle eine Textdatei
    2. Kopier dein Code da rein, und wähle "Speichern unter".
    3. Gib deiner Datei einen Namen und die entsprechende Dateiendung: .php
    4. DARUNTER ist ein Punkt mit "Codierung". Setz den auf UTF-8
    5. Rechts daneben steht speichern. Use it! :)

    Gut, es gibt noch andere Möglichkeiten, aber die sind äußerst selten. Versuch es erstmal damit. Gib mir bitte bescheid, wenn es daran lag. :)

    (Das Programm ist sehr umfangreich, so dass ich es ungern hier poste)

    Ist ja auch nicht nötig, oder sind da irgendwelche Fehler drinnen?

    VE,
    Rowland

    1. Hello,

      Im Augenblick wird nämlich Ö (in der Eingabe) als weißes ? (im schwarzen Quadrat) im erzeugten HTML-Dokument und bei echo-Ausgaben im PHP-Programm dargestellt.

      Dass das 'Ö' als '?' angezeigt wird, ist vermutlich eine Sache des Zeichensatzes, der kein 'Ö' kennt und daher die Rendering Engine mit dem Codepoint nichts anfangen kann.

      Wenn alle Stricke reißen, sollte man sich die Quelldatei mal im HEX-Editor ansehen, welche Bitfolgen denn tatsächlich darin stehen. Bei mehrfacher Hin- und Hercodierung geschehen schon manchmal seltsame Verwandlungen :-)

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://bikers-lodge.com
      1. Om nah hoo pez nyeetz, Tom!

        Dass das 'Ö' als '?' angezeigt wird, ist vermutlich eine Sache des Zeichensatzes, der kein 'Ö' kennt und daher die Rendering Engine mit dem Codepoint nichts anfangen kann.

        Ne, das ist, was der Martin schrieb. Heißt U+FFFD REPLACEMENT CHARACTER.

        �������������
          
        �������������

        Zeichen, die im Zeichensatz nicht enthalten sind werden in der Regel mit Quadraten, die nicht auf einer Spitze stehen, dargestellt.

        □□□□□□□□□□□□□□□□□□□□□□□□□□

        Matthias

        --
        Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Integral und Integralhelm.

        1. Moin,

          �������������
            
          �������������
          ...
          Zeichen, die im Zeichensatz nicht enthalten sind werden in der Regel mit Quadraten, die nicht auf einer Spitze stehen, dargestellt.

          deshalb sind bei mir (IE11) über und unter deiner Bildquelle wohl auch lauter Quadrate zu sehen? Auf dem Smartphone (Android) sehe ich den entsprechenden "Replacement Character" (black diamond with a white question mark).

          Auf den Wikipediaseiten ist es auch so (da wo ChrisB hin verlinkt hat).

        2. @@Matthias Apsel:

          nuqneH

          Zeichen, die im Zeichensatz nicht enthalten sind werden in der Regel mit Quadraten, die nicht auf einer Spitze stehen, dargestellt.

          Wobei sich „Zeichensatz“ hier nicht auf den Dokument-Zeichensatz bezieht (der ist Unicode – da sind alle™ Zeichen drin!), sondern auf den Satz an Zeichen (Glyphen), den die Schriftarten zur Verfügung stellen.

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
      2. Hi,

        Im Augenblick wird nämlich Ö (in der Eingabe) als weißes ? (im schwarzen Quadrat) im erzeugten HTML-Dokument und bei echo-Ausgaben im PHP-Programm dargestellt.

        Dass das 'Ö' als '?' angezeigt wird, ist vermutlich eine Sache des Zeichensatzes, der kein 'Ö' kennt und daher die Rendering Engine mit dem Codepoint nichts anfangen kann.

        Nein, ein Fragezeichen in einem Quadrat ist mit so gut wie 100%er Sicherheit ein Zeichen für eine Bytefolge, die in der zur Interpretation gewählten Zeichenkodierung invalid ist.

        Siehe auch http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences – dort sind explizit “popular replacements” gelistet, darunter der replacement character U+FFFD: “often a black diamond with a white question mark.”

        MfG ChrisB

        --
        RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
    2. @@Rowland:

      nuqneH

      In der Regel reicht die Angabe im HTML Code, dass du UTF-8 nutzt.

      Nö. Das kann man so nicht sagen. Die Angabe ist weder notwendig noch hinreichend.

      Hinreichend nicht, denn wenn der Server im HTTP-Header etwas anderes angibt, dann hat dessen Angabe Vorrang. Es sei denn, die Datei beginnt mit einem BOM, was (seit neustem) Vorrang vor HTTP hat. (Noch nicht in allen Browsern so implementiert.)

      Notwendig nicht, denn wenn der Server keine Angabe macht und auch im Dokument weder ein BOM noch eine meta-Angabe ist, ist laut HTML5 UTF-8 Default. (Vorher war’s ISO 8859-1.)

      Aber die Angabe im HTML Code muss auf jeden Fall da sein.

      Muss nicht. Sollte aber.

      In der Regel ist UTF-8 aber zumindest was die europäische Seite anbelangt, Standard. D.H. du wirst eigentlich keinen seriösen Anbieter in der EU finden, der das nicht auf UTF-8 hat. Zumindest hoffe ich das stark. :))

      Ist das jetzt wirklich so, dass alle Hoster UTF-8 als Default setzen?

      Wenn nicht, ist da ja auch schnell gemacht.

      Wenn du die z.B. als ANSI speicherst, aber im Dokument UTF-8 angibst, kommt es zu Fehlern. Die ersten 127 Zeichen stimmen bei beiden Zeichenkodierungen überein, die restlichen nicht.

      Du meinst ASCII, nicht ANSI.

      Qapla'

      --
      „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
      1. Hola Gunnar,

        In der Regel reicht die Angabe im HTML Code, dass du UTF-8 nutzt.
        Hinreichend nicht, denn wenn der Server im HTTP-Header etwas anderes angibt, dann hat dessen Angabe Vorrang.

        Richtig. Aber:

        du wirst eigentlich keinen seriösen Anbieter in der EU finden, der das nicht auf UTF-8 hat.

        Wo du wiederrum Einspruch erhebst:

        Ist das jetzt wirklich so, dass alle Hoster UTF-8 als Default setzen?

        Es gibt Hoster, die arbeiten noch mit PHP 4 ohne irgendwelche patches innerhalb der Version. Ich denke das beantwortet deine rhetorisch gestellte Frage, nur um es nochmal zu bestätigen gebe ich dir recht. ^^

        Folgend nur als persönliche Meinung:
        UTF-8 ist DIE Zeichenkodierung schlecht hin. Ich würde keinem meine HP Daten anvertrauen, der nicht weiß und versteht was das ist. Wer versteht was UTF-8 ist, der erkennt auch den Wert. Wer nicht mit der Technik geht, wird dauerhaft nicht bestehen. Außer er restauriert Oldtimer. Was für Sachgüter zutrifft, trifft aber nicht auf sowas zu. Wer will schon z.B. zum IE 6 zurück?!

        Es sei denn, die Datei beginnt mit einem BOM, was (seit neustem) Vorrang vor HTTP hat.

        BOM dann nur in Verbindung mit UTF-16. Für unsere Sprache ist UTF-8 ja mehr als ausreichend.

        Notwendig nicht, denn wenn der Server keine Angabe macht und auch im Dokument weder ein BOM noch eine meta-Angabe ist, ist laut HTML5 UTF-8 Default.

        Das ist eine gute Neuigkeit. Bestätigt auch das, was ich mal gelesen habe, dass UTF-8 Standard werden soll. Frag mich nur nicht wo.

        Was ich aber nicht verstehe, ist nochmal rückbezogen auf deinen übersetzten Artikel, warum selfhtml.org beide Varianten nutzt um die Zeichenkodierung zu setzen, wo doch "verboten" wird, beides zu nutzen (Zitat: "aber nicht beides zusammen")? Hat das einen bestimmten Grund, dass Selfhtml das doch macht?

        Du meinst ASCII, nicht ANSI.

        Bei mir steht bei Codierung ANSI. Aber ANSI und ASCII nehmen sich ja im Prinzip nichts, da ANSI darauf aufbaut. Die Zeichen sind dennoch gleich.

        Ich wünsche eine schöne Nacht,
        Roland

        --
        "Dont't believe everything you read on the Internet, just because there's a quote with a name next to it." - Abraham Lincoln
        1. @@Rowland:

          nuqneH

          BOM dann nur in Verbindung mit UTF-16. Für unsere Sprache ist UTF-8 ja mehr als ausreichend.

          Was hätte das mit „ausreichend“ zu tun? UTF-16 kann den gesamten Unicode-Bereich codieren; UTF-8 kann den gesamten Unicode-Bereich codieren.

          Der Unterschied liegt nicht darin, welche Zeichen codiert werden können, sondern wie codiert wird.

          warum selfhtml.org beide Varianten nutzt um die Zeichenkodierung zu setzen, wo doch "verboten" wird, beides zu nutzen (Zitat: "aber nicht beides zusammen")? Hat das einen bestimmten Grund, dass Selfhtml das doch macht?

          Nein, das ist unsinnig.

          Du meinst ASCII, nicht ANSI.

          Du meintest doch ANSI (was wohl Synonym für ISO 8859-1 sein soll?), als du schriebst „Die ersten 127 Zeichen stimmen bei beiden Zeichenkodierungen überein, die restlichen nicht.“

          Bei ASCII gibst es kaum restliche.

          Und es sind die ersten 128.

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
          1. Hola Gunnar,

            Was hätte das mit „ausreichend“ zu tun? UTF-16 kann den gesamten Unicode-Bereich codieren; UTF-8 kann den gesamten Unicode-Bereich codieren.

            Ich habe UTF-16 verbunden mit "kann auch asiatische + afrikanische Zeichen darstellen, UTF-8 nicht". Und verbraucht doppelt soviel Speicherplatz. Jetzt habe ich nochmal nachgelesen, es können anscheinend beide. Glaube, ich habe damals aus den falschen Quellen gelernt, merk ich immer wieder.......

            Und es sind die ersten 128.

            0 - 127 Indizes, so ists besser. :)

            lg,
            Rowland

            1. @@Rowland:

              nuqneH

              Ich habe UTF-16 verbunden mit "kann auch asiatische + afrikanische Zeichen darstellen, UTF-8 nicht". Und verbraucht doppelt soviel Speicherplatz.

              Weder das eine noch das andere stimmt.

              Bei ASCII-Zeichen verbraucht UTF-16 doppelt so viel Speicherplatz wie UTF-8, ja.
              Bei CJK-Zeichen* verbraucht UTF-16 nur 2/3 so vie Speicherplatz wie UTF-8, also weniger.
              Bei Zeichen jenseits der BMP, also ab U+10000, nehmen sich beide nichts.

              * chinesisch, japanisch, koreanisch

              Was sind für dich „afrikanische“ Zeichen?

              Glaube, ich habe damals aus den falschen Quellen gelernt

              W3Schools?

              Qapla'

              --
              „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
              1. Hola Gunnar,

                Was sind für dich „afrikanische“ Zeichen?

                Ich hab da in die Richtung Höhlenmalerei und Rauchzeichen gedacht. Gerade hatte ich sogar noch eine Quelle, wo das stand, dass UTF-16 für afrikanische Symbole/Zeichen ist.

                Jetzt hab ichs sogar noch gefunden, hat mich einiges an Zeit gekostet wieder die richtigen Keywords bei google einzutippen... → Im ersten Absatz.

                W3Schools?

                Ja, teilweise. Aber nachdem ich mal hier gelesen hatte wie darüber abgelästert wurde, hatte ich sofort damit aufgehört :D

                Ich denke nach soviel falschen bzw. unpräzisen Quellen, lese ich nur noch bei W3 und vorher auf ego4u...

                gz,
                Roland

                --
                "Dont't believe everything you read on the Internet, just because there's a quote with a name next to it." - Abraham Lincoln
                1. @@Rowland:

                  nuqneH

                  Gerade hatte ich sogar noch eine Quelle, wo das stand, dass UTF-16 für afrikanische Symbole/Zeichen ist. […] → Im ersten Absatz.

                  Antwort von Radio Jerewan: Im Prinzip schon. Nur steht da nicht speziell „für afrikanische Symbole/Zeichen“, sondern „lateinische und andere europäische Schriften und deren Symbole, afrikanische und asiatische Schriften.“ Und das bezieht sich nicht auf UTF-16, sondern auf die BMP.

                  In der BMP haben übrigens auch amerikanische und ozeanische Schriften ihren Platz.

                  Qapla'

                  --
                  „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                2. Meine Herren!

                  W3Schools?

                  Ja, teilweise. Aber nachdem ich mal hier gelesen hatte wie darüber abgelästert wurde, hatte ich sofort damit aufgehört :D

                  Inzwischen ist W3Schools zu einer soliden Wissens-Basis herangewachsen. Sie haben sich der Kritik gut angenommen (findet auch Paul Irish, Initiator von w3fools). Ich persönliche lese auch lieber an anderen Stellen, aber aus anderen Gründen. Mich stört nur, dass dieser Bash kein Ende nimmt und dabei inhaltlich schon lange auf der Strecke geblieben ist.

                  --
                  “All right, then, I'll go to hell.” – Huck Finn
            2. Hello,

              Ich habe UTF-16 verbunden mit "kann auch asiatische + afrikanische Zeichen darstellen, UTF-8 nicht". Und verbraucht doppelt soviel Speicherplatz.

              Wenn ich das richtig deute, dann braucht utf-16 auch nicht grundsätzlich doppelt soviel Speicherplatz. Das hängt von den benutzten Code-Points ab.

              Liebe Grüße aus dem schönen Oberharz

              Tom vom Berg

              --
               ☻_
              /▌
              / \ Nur selber lernen macht schlau
              http://bikers-lodge.com
              1. @@Tom:

                nuqneH

                Ich habe UTF-16 verbunden mit "kann auch asiatische + afrikanische Zeichen darstellen, UTF-8 nicht". Und verbraucht doppelt soviel Speicherplatz.

                Wenn ich das richtig deute, dann braucht utf-16 auch nicht grundsätzlich doppelt soviel Speicherplatz.

                Was genau deutest du? Antwortest du schon wieder auf das falsche Posting? Nur dass ich nicht dazwischen-, sondern weggerutscht bin?

                Qapla'

                --
                „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                1. Hello,

                  Antwortest du schon wieder auf das falsche Posting? Nur dass ich nicht dazwischen-, sondern weggerutscht bin?

                  Deins habe ich erst gelesen, nachdem ich bereits geantwortet hatte.

                  Nach dem Redesign des Forums kann ich nicht mehr (noch nicht wieder?) eindeutig erkenne, welche Postings ich schon gelesen habe und welche noch nicht. Ich werd' auch langsam alt - da schwindet die Aufmerksamkeit.

                  Liebe Grüße aus dem schönen Oberharz

                  Tom vom Berg

                  --
                   ☻_
                  /▌
                  / \ Nur selber lernen macht schlau
                  http://bikers-lodge.com
        2. Meine Herren!

          UTF-8 ist DIE Zeichenkodierung schlecht hin. Ich würde keinem meine HP Daten anvertrauen, der nicht weiß und versteht was das ist. Wer versteht was UTF-8 ist, der erkennt auch den Wert. Wer nicht mit der Technik geht, wird dauerhaft nicht bestehen. Außer er restauriert Oldtimer. Was für Sachgüter zutrifft, trifft aber nicht auf sowas zu. Wer will schon z.B. zum IE 6 zurück?!

          Plot-Twist: Der IE6 ist fast zehn Jahre jünger als UTF-8 :P

          Ich stimme dir zwar größtenteils zu, was die Verbreitung von UTF-8 betrifft, bin aber anderer Auffassung was die Ahnungslosigkeit darüber betrifft. Die EDV-Werkzeuge der Gegenwart erlauben es produktiv zu arbeiten ohne auch nur einmal einen Gedanken an Zeichensatz oder -kodierung zu verschwenden. Auch sind die typischen Probleme mit Zeichenkodierungen meistens recht schnell und einfach behoben.

          Oft ist die Zugriff-Verweigerung auch gar keine Option. Ich habe mich schon mit Kunden auseinandersetzen müssen, die FTP-Zugriff haben wollten (für den sie ja auch bezahlen) und die dann putzemunter wichtige Skript-Dateien gelöscht haben, um die lästigen fünf Kilobyte von der Terrabyte-Platte freizugeben. Glücklicherweise gab es in diesem Fall Backups ;) In einem anderen Fall hat ein Kunde aus einer Laune heraus Ordner umbenannt, weil seiner Meinung nach Nomen mit einem Großbuchstaben zu beginnen haben – immer. Das sind meine beiden Mittwochs-Anekdoten.

          --
          “All right, then, I'll go to hell.” – Huck Finn
        3. Om nah hoo pez nyeetz, Rowland!

          Was ich aber nicht verstehe, ist nochmal rückbezogen auf deinen übersetzten Artikel, warum selfhtml.org beide Varianten nutzt um die Zeichenkodierung zu setzen, wo doch "verboten" wird, beides zu nutzen (Zitat: "aber nicht beides zusammen")? Hat das einen bestimmten Grund, dass Selfhtml das doch macht?

          Nein, in der allerersten Version waren beide Varianten drin und dann hat bei Änderungen keiner mehr darauf geachtet. Im Artikel heißt es: „Dies wird auch schon von den gängigen Browsern unterstützt.“ Möglicherweise war das zum Zeitpunkt des Entwurfes der Startseite noch nicht so, so das deshalb derjenige, der die Seite gemacht hat, beide Varianten verwendet hat.

          Matthias

          --
          Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Mars und Marseille.

      2. Hallo Gunnar,

        <<Hinreichend nicht, denn wenn der Server im HTTP-Header etwas anderes angibt, dann hat dessen Angabe Vorrang.

        Ich habe diesen Thread gerade verfolgt. Ich hatte bisher auch immer in allen PHP Dateien
        <meta http-equiv="content-type" content="text/html; charset=utf-8">
        drin stehen.

        Bedeutet dies dann wirklich, dass wenn der Server etwas anders vorgibt, diese Einstellung ignoriert wird?.
        Du meinst mit Server z.b. den Apache Webserver? Wo bzw. in welcher Konfigurationsdatei wird dies denn angegeben und wie kann man dies überprüfen ob der Server etwas vorgibt?

        viele Grüße
        Werber

        1. Om nah hoo pez nyeetz, WernerK!

          <<Hinreichend nicht, denn wenn der Server im HTTP-Header etwas anderes angibt, dann hat dessen Angabe Vorrang.

          Bitte füge Zitatmarkierungen mit der Bearbeitungsleiste (> … – ≈ ≠ × → ↑ ▲ ⇒ „“ ‚‘ “” ‘’ «» »«)
          hinzu, dann erkennt die Software, dass es sich um ein Zitat handelt.

          Der Gunnar hat auch die Beantwortung dieser Frage übersetzt.

          Matthias

          --
          Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Host und Hostie.

        2. @@WernerK:

          nuqneH

          Ich habe diesen Thread gerade verfolgt. Ich hatte bisher auch immer in allen PHP Dateien
          <meta http-equiv="content-type" content="text/html; charset=utf-8">
          drin stehen.

          Was du in HTML5 kürzer als <meta charset="utf-8"> schreiben kannst.

          Bedeutet dies dann wirklich, dass wenn der Server etwas anders vorgibt, diese Einstellung ignoriert wird?.

          Wirklich wirklich.

          und wie kann man dies überprüfen ob der Server etwas vorgibt?

          W3C Internationalization Checker

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
          1. Hallo,

            danke an euch für die Hinweise.
            Habe ich das richtig verstanden das die Servervorgaben nicht über die "httpd.conf" Datei oder ähnliche konfiguriert wird, sondern nur über .htaccess Dateien?

            Ich rede jetzt nur mal von einem lokalen Xampp Server.

            Gruss
            Werner

            1. Hi,

              Habe ich das richtig verstanden das die Servervorgaben nicht über die "httpd.conf" Datei oder ähnliche konfiguriert wird, sondern nur über .htaccess Dateien?

              nein, das ist falsch.

              Die zentrale Server-Konfigurationsdatei (httpd.conf) ist die höchste Instanz. Konfigurations-Direktiven, die hier stehen, gelten global. Die lokale Konfigurationsdatei (.htaccess) kann aber Einstellungen aus httpd.conf für einzelne Verzeichnisse (und deren Nachfahren) ergänzen oder überschreiben.
              Nicht alle Direktiven sind in .htaccess überhaupt gültig. Insbesondere kann sogar in der zentralen Konfigurationsdatei schon festgelegt werden, was in .htaccess überhaupt noch erlaubt ist.

              Ich rede jetzt nur mal von einem lokalen Xampp Server.

              Das ist gut, denn beim durchschnittlichen Webhoster hast du normalerweise keinen Zugriff auf die zentrale Konfiguration, dort musst du also alles über die .htaccess abfrühstücken - und bist dadurch möglicherweise in den Möglichkeiten eingeschränkt.

              Ciao,
               Martin

              --
              Okay, Alkohol ist keine Antwort.
              Aber manchmal vergisst man beim Trinken wenigstens die Frage.
              Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              1. Hallo Martin,

                sind das in der httpd.conf diese Einträge die ihr meint?

                AddDefaultCharset ISO-8859-1

                AddCharset UTF-8       .utf8

                und nochmals:

                Angenommen es gibt auf dem lokalen XAMPP Server im Apache htdocs keine .htaccess Dateien und in der httpd.conf steht nur
                AddDefaultCharset ISO-8859-1

                Wird dann die Angabe in den PHP Dateien mit
                <meta http-equiv="content-type" content="text/html; charset=utf-8">

                ignoriert?

                Gruss
                Werner

                1. Hallo,

                  sind das in der httpd.conf diese Einträge die ihr meint?

                  AddDefaultCharset ISO-8859-1
                  AddCharset UTF-8       .utf8

                  ja, richtig. Hier wird festgelegt, dass der Server als Default-Encoding ISO-8859-1 angeben soll, für Dateien mit der Extension .utf8 jedoch UTF-8. Ziemlich merkwürdig, finde ich.

                  Angenommen es gibt auf dem lokalen XAMPP Server im Apache htdocs keine .htaccess Dateien und in der httpd.conf steht nur
                  AddDefaultCharset ISO-8859-1

                  Wird dann die Angabe in den PHP Dateien mit
                  <meta http-equiv="content-type" content="text/html; charset=utf-8">
                  ignoriert?

                  Ja. Und das hat nichts mit PHP zu tun - die obige Zeile ist ja pures HTML. Anders sähe es aus, wenn du mit der Funktion header() in PHP den HTTP-Header "Content-Type" entsprechend setzt. Das überschreibt dann tatsächlich den Default-Header des Servers und hat ebenfalls wieder Vorrang vor einer zusätzlichen Angabe _im_Dokument_.

                  Ciao,
                   Martin

                  --
                  Die neue E-Mailadresse des Papstes: mailto:urbi@orbi
                  Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                2. @@WernerK:

                  nuqneH

                  Wird dann die Angabe in den PHP Dateien mit
                  <meta http-equiv="content-type" content="text/html; charset=utf-8">
                  ignoriert?

                  Prioritätsregeln (temporär von meinem Server – Der Artikel auf der W3C-i18n-Website bezieht sich noch auf eine ältere Version der HTML5-Spec.)

                  Qapla'

                  --
                  „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
                3. Hello,

                  Wird dann die Angabe in den PHP Dateien mit

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

                  ignoriert?

                  Kommt darauf an, wie Du sie im Script notierst (*scnr*).

                  Wenn Du die Direktive mit ausgibst (echo) ins HTML, dann wird sie wohl gesehen und ausgewertet vom Browser. Wenn der schon einen HTTP-Header zum Thema bekommen hat, hat der Vorrang.

                  Aber ich würde die zum Header passende <meta>-Angabe trotzdem immer vornehmen, weil dann die Files auch offline richtig interpretiert werden können. Wenn sich also jemand die Seite auf seinem Rechner speichert, wird nicht bei allen Browsern die Codierung als Meta-Angabe ins Dokument eingestanzt, einige machen das allerdings für Dich, wenn Du die "Offline lesbar machen" Funktion benutzt.

                  Liebe Grüße aus dem schönen Oberharz

                  Tom vom Berg

                  --
                   ☻_
                  /▌
                  / \ Nur selber lernen macht schlau
                  http://bikers-lodge.com