pto: Eleminierung von HTML-Fehlern

Hallo,

ich versuche, meine Validator-Fehler zu eliminieren und bekomme z. B.

Line 255, Column 16: Forbidden code point U+009f.

Der Fehler bezieht sich aber auf einen eingelesenen Feed - und ich weiß nicht, wie ich den beheben könnte.

Dann wird moniert, dass all meine articles kein heading haben, aber die brauchen keinen header (oder kann ich images als article-header benutzen?)

Und zur Vermeidung von

Bad value X-UA-Compatible for attribute http-equiv on element meta

habe ich auch keine Lösung gefunden?

Gruß und Dank für Tipps
pto

  1. Hallo,

    Line 255, Column 16: Forbidden code point U+009f.

    Der Fehler bezieht sich aber auf einen eingelesenen Feed - und ich weiß nicht, wie ich den beheben könnte.

    Indem du solche Steuerzeichen aus sämtlichem Input entfernst.

    In PHP z.B. http://stackoverflow.com/a/8171868

    (\r, \n und \t willst du vielleicht behalten.)

    Dann wird moniert, dass all meine articles kein heading haben, aber die brauchen keinen header (oder kann ich images als article-header benutzen?)

    Eine HTML5-Section (also auch Articles) sollte eine Überschrift (hX-Element) haben. Muss sie aber nicht zwingend.

    Ob in der Überschrift ein Bild (img) liegt oder per CSS geladen wird, ist dir überlassen.

    Bad value X-UA-Compatible for attribute http-equiv on element meta

    habe ich auch keine Lösung gefunden?

    Dafür gibt es keine Lösung, außer die Warnung zu ignorieren.

    Brauchst du das meta-Element denn unbedingt? Es reicht meistens, einen korrekten DOCTYPE zu setzen (<!DOCTYPE html>), das bringt den IE dazu, die Seite nach bestem Wissen und Gewissen zu rendern, es sei denn, er ist anders konfiguriert.

    Grüße
    Mathias

    1. Danke, ich habe jetzt die bei stackoverflow empfohlene function clear_string eingesetzt

      function clean_string($string) {  
        $s = trim($string);  
        $s = iconv("UTF-8", "UTF-8//IGNORE", $s); // drop all non utf-8 characters  
        
        // this is some bad utf-8 byte sequence that makes mysql complain - control and formatting i think  
        $s = preg_replace('/(?>[\x00-\x1F]|\xC2[\x80-\x9F]|\xE2[\x80-\x8F]{2}|\xE2\x80[\xA4-\xA8]|\xE2\x81[\x9F-\xAF])/', ' ', $s);  
        
        $s = preg_replace('/\s+/', ' ', $s); // reduce all multiple whitespace to a single space  
        
        return $s;  
      }
      

      Allerdings kommt der Fehler trotzdem. Vielleicht steht dort in dem feed ein Steuerzeichen, das von der Funktion nicht erfasst wird.

      webseite

      Die anderen Fehler konnte ich eliminieren.

      1. Hallo,

        Danke, ich habe jetzt die bei stackoverflow empfohlene function clear_string eingesetzt

        Okay. Das ist nicht die Funktion, die ich verlinkt habe, die preg_replace explizit sagt, dass UTF-8 verwendet wird. Im Prinzip kann man auch auf Byte-Ebene arbeiten, aber Unicode-Zeichenebene ist einfacher.

        Allerdings kommt der Fehler trotzdem.

        In der Fehlermeldung steht doch der problematische Codepoint?!

        Mathias

        1. em.

          In der Fehlermeldung steht doch der problematische Codepoint?!

          Aber wo in z. B.

          $string = preg_replace('/[\x00-\x1F\x80-\xFF]/', '', $string);

          gehört denn "U+009f" hin, damit es ersetzt wird und wieso soll es denn durch "nichts" ersetzt werden, anscheinend gehört doch an die Stelle korrekterweise ein Umlaut stattdessen, der anscheinend beim NDR nur falsch codiert wird?

          1. Hallo,

            $string = preg_replace('/[\x00-\x1F\x80-\xFF]/', '', $string);

            gehört denn "U+009f" hin, damit es ersetzt wird und wieso soll es denn durch "nichts" ersetzt werden, anscheinend gehört doch an die Stelle korrekterweise ein Umlaut stattdessen

            U+009F ist ein Steuerzeichen, kein Umlaut.
            http://www.fileformat.info/info/unicode/char/9f/index.htm
            Es ergibt Sinn, das durch nichts zu ersetzen, also komplett zu verwerfen.

            In obiger RegExp wird der Bereich 0x80 bis 0xFF angegeben (Zahlen in Hexadezimalschreibweise):

            [\x80-\xFF]

            0x9F liegt in diesem Zahlenbereich.

            Übrigens ist hier der RegExp-Modifier /…/u wichtig. Das behandelt die Eingabe als UTF-8. Ich vermute, dann wird die 0xXX-Notation als Unicode-Codepoint verstanden?! Ansonsten würde es ja Multibyte-Zeichen zerstören. Ich habe es nicht ausprobiert. Gegebenenfalls würde ich auf die \uXXXX-Notation ausweichen, die sich unmissverständlich auf Unicode-Codepoints und nicht auf Bytes bezieht.

            Wenn da tatsächlich ein Umlaut hingehört, dann ist irgendetwas kaputt. Entweder du liest den Feed mit einer falschen Kodierung ein, oder es geht etwas bei der Verarbeitung schief. Welche Kodierung nutzt der NDR und mit welcher verarbeitest du den String?

            Mathias

            1. Übrigens ist hier der RegExp-Modifier /…/u wichtig. Das behandelt die Eingabe als UTF-8. Ich vermute, dann wird die 0xXX-Notation als Unicode-Codepoint verstanden?! Ansonsten würde es ja Multibyte-Zeichen zerstören. Ich habe es nicht ausprobiert. Gegebenenfalls würde ich auf die \uXXXX-Notation ausweichen, die sich unmissverständlich auf Unicode-Codepoints und nicht auf Bytes bezieht.

              Wenn da tatsächlich ein Umlaut hingehört, dann ist irgendetwas kaputt. Entweder du liest den Feed mit einer falschen Kodierung ein, oder es geht etwas bei der Verarbeitung schief. Welche Kodierung nutzt der NDR und mit welcher verarbeitest du den String?

              also, ich habe es jetzt mit /u und so versucht:
              $descr = preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x80-\x9F]/uXXXX', '', $descr);

              Im ersten Fall entfernt er Umlaute ganz und im zweiten Fall ändert sich nichts. Im Validator sieht es so aus:

              Error Line 229, Column 286: Forbidden code point U+009f.

              …stätigen, wäre dies der bisher gröÃ...te Skandal um einen deutsch-amerikanisc…


              Error Line 244, Column 559: Forbidden code point U+009f.

              …le ="Zum Sport: Für die deutsche FuÃ...ball-Nationalmannschaft geht es heute b…

              offenbar wird mit dem Umlaut ein Steuerzeichen ausgeliefert. Die Seite ist als <meta charset="utf-8"> deklariert. Ich verarbeite auch in utf8.
              Ich habe hier mal die Steuerzeichen durch ... ersetzt, sonst werden sie hier nicht akzeptiert.

              1. Hallo,

                $descr = preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x80-\x9F]/uXXXX', '', $descr);

                Dieses /uXXXX ergibt hier keinen Sinn, ich sprach von zwei Dingen:

                Escape Sequences:
                http://www.php.net/manual/de/regexp.reference.escape.php
                Die kann man

                Der u-Modifier:
                http://www.php.net/manual/de/reference.pcre.pattern.modifiers.php

                Beispiel (UTF-8-kodierte PHP-Datei):
                <?php
                $s = 'ö';
                $s2 = preg_replace('/\x{00F6}/u', 'ersetzt', $s);
                echo $s2;
                ?>

                Das arbeitet auf Zeichenebene, nicht auf Byteebene (vermute ich, bin kein PHP-Programmierer, hab ich noch nie im Einsatz gehabt außer in obigem Beispiel ;)).

                Mathias

                1. <?php
                  $s = 'ö';
                  $s2 = preg_replace('/\x{00F6}/u', 'ersetzt', $s);
                  echo $s2;
                  ?>

                  ich blick nicht mehr durch jetzt habe ich das so umgesetzt, bloß mit 009f, jetzt streikt der validator ganz und sagt Sorry! This document cannot be checked.  Sorry, I am unable to validate this document because on line 437 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.

                  The error was: utf8 "\xC3" does not map to Unicode