Validierungsfehler

[Jeena Paradies]

Hallo,

Durch einen Eintrag in einem anderen Weblog bin ich darauf aufmerksam geworden, dass ich mal wieder validieren sollte. Das habe ich auch gemacht und bekomme dieses Ergebnis:

------------
Line 217, column 97: non SGML character number 132
...g und hab dich in Gedanken immer scho_n_ „da oben“ eingeordnet ;-) </p>

Line 217, column 105: non SGML character number 147
...b dich in Gedanken immer schon „da o_b_en“ eingeordnet ;-) </p>
------------

Kan dass jemand vielleicht für mich deuten? Ich habe keine Ahnung was der Validator damit meint.

Elya, ja das ist dein Kommentar ;-) weißt du vielleicht was du da irgendwie gedrückt hast oder so?

Grüße
Jeena Paradies

[Jeena Paradies]

Hallo,

Gibt es irgendeine Möglichkeit beim Veröffentlichen die Seite automatisch testen zu lassen und eine Variable zurück zu bekommen ob alles valide ist oder nicht? Also ich dachte da irgendwie an so einen Dienst den ich noch nicht kenne, an den ich meine HTML Seite als String oder so sende und die mir dann antwortet true oder false je nach dem ob valide oder nicht?

Grüße
Jeena Paradies

[Ashura]

Hallo Jeena Paradies.

Gibt es irgendeine Möglichkeit beim Veröffentlichen die Seite automatisch testen zu lassen und eine Variable zurück zu bekommen ob alles valide ist oder nicht?

Automatisch nicht unbedingt, aber im Dreamweaver z.B. ist ein Validator integriert, was doch viel Aufwand erspart.

Gruß, Ashura

[Marc Reichelt]

Hallo Ashura,

Gibt es irgendeine Möglichkeit beim Veröffentlichen die Seite automatisch testen zu lassen und eine Variable zurück zu bekommen ob alles valide ist oder nicht?

Automatisch nicht unbedingt, aber im Dreamweaver z.B. ist ein Validator integriert, was doch viel Aufwand erspart.

Der Validator vom Dreamweaver hat Fehler - schon mal probiert, mehrere Seiten unterschiedlicher Doctypes zu validieren, wenn sie in einer Site sind?
Richtig, er prüft auf _einen_ Doctype.

Meine Seite damals enthielt z.B. ein Frameset, mit entsprechendem Doctype.
Meinst du, Dreamweaver hätte das automatisch erkannt? Nein, er hat alles auf HTML 4.01 Transitional geprüft... ;-)

Bis dann!

Marc Reichelt || http://www.marcreichelt.de/

[Ashura]

Hallo Marc Reichelt.

Der Validator vom Dreamweaver hat Fehler - (...)

Da muss ich dir Recht geben. Er kann z. B. auch "nur" bis maximal XHTML 1.0 Strict validieren; XHTML 1.1 ist ihm unbekannt.

Aber der Validator erspart doch eine Menge Datenverkehr, der sonst über den Server laufen würde.

Gruß, Ashura

[Götz]

Hallo Ashura!

Aber der Validator erspart doch eine Menge Datenverkehr, der sonst über den Server laufen würde.

Naja, man kann sich ja auch den W3C-Validator lokal installieren.

MfG
Götz

[Ashura]

Hallo Götz.

Naja, man kann sich ja auch den W3C-Validator lokal installieren.

Kann man. Aber "Damit der Validator läuft benötigt man natürlich erst einmal einen Webserver." gefällt mir nicht...

Gruß, Ashura

[MudGuard]

Hi,

Naja, man kann sich ja auch den W3C-Validator lokal installieren.
Kann man. Aber "Damit der Validator läuft benötigt man natürlich erst einmal einen Webserver." gefällt mir nicht...

A Real Validator. http://arealvalidator.com/

cu,
Andreas

[Ashura]

Hallo MudGuard.

A Real Validator. http://arealvalidator.com/

Obgleich der Tatsache, dass es sich hierbei um Shareware handelt, ist das doch recht interessant. Sollte ich es einmal brauchen, werde ich vielleicht darauf zurück kommen.

Gruß, Ashura

[Jeena Paradies]

Hallo,

Automatisch nicht unbedingt, aber im Dreamweaver z.B. ist ein Validator integriert, was doch viel Aufwand erspart.

Naja das ist nicht der Sinn der Sache, es geht um mein Weblog welches sowieso online administriert wird. Ich muss/darf dort richtigen HTML Code eingeben. Bevor dieser aber in die Datenbank geschrieben wird und online auf der Seite sichtbar wird sollte er validiert werden, bzw wenigstens ein Warnung erscheinen dass ich da wieder etwas verpfuscht habe. Wenn ich nämlich irgendwann einmal auf .xml umsteigen will und die sachen dann als richtiges xml ausliefern will damit die Browser es schneller parsen können als HTML dann muss das alles schön valide bevor es veröffentlicht wird, sonst wird da nur ein Fehler angezeigt. Jetzt dachte ich an irgendeine PHP Klasse oder eine Externe Seite die das irgendwie machen könnte.

Grüße
Jeena Paradies

[Ashura]

Hallo Jeena Paradies.

Naja das ist nicht der Sinn der Sache, es geht um mein Weblog welches sowieso online administriert wird.

Ach, ich verstehe nun, was du meinst. Hm... Tja, tut mir leid, bis auf die bereits hinschlägig bekannten Online-Validatoren ist mir nichts dergleichen bekannt.

Aber ich könnte mir vorstellen, dass ein gewiefter PHPler so etwas umsetzen könnte.

Gruß, Ashura

[Henryk Plötz]

Moin,

Gibt es irgendeine Möglichkeit beim Veröffentlichen die Seite automatisch testen zu lassen und eine Variable zurück zu bekommen ob alles valide ist oder nicht? Also ich dachte da irgendwie an so einen Dienst den ich noch nicht kenne, an den ich meine HTML Seite als String oder so sende und die mir dann antwortet true oder false je nach dem ob valide oder nicht?

Ja. Hier nochmal meine Anmerkungen aus dem Chat und in ausführlicher (für's Archiv):

Das ist üblicherweise kein Problem, man muß bloß erstmal unterscheiden ob man valides HTML oder XML haben möchte. Für HTML leistet der W3C-Validator ja bekanntlich gute Dienste. Und der macht auch nichts anderes als ein Programm dafür aufzurufen: onsgmls, wenn ich mich richtig erinnere. Früher hat er sogar mal die genauen Kommandozeilenparameter verraten, das scheint jetzt nicht mehr drin zu sein. Google offenbart: http://www.adp-gmbh.ch/misc/validating_html.html

XML ist ebenfalls einfach: Für XML gibt es das xmllint-Tool, das bei mir im Paket libxml2 enthalten war, und welches - wie der Name schon sagt - XML-Dateien überprüfen kann. Standardmäßig gibt xmllint Warnungen über das Dokument aus und sofern möglich eine korrigierte Version. Mit --noout unterdrückt man diese zweite Ausgabe. Ausserdem würde es versuchen DTDs ggbf. aus dem Netz zu ziehen, was neben der Verursachung von zusätzlichem Netzverkehr den unangenehmen Nebeneffekt hat dass sich die Sache länger hinzieht als nötig. Mit --nonet unterdrückt man das, hat aber ggbf. das Problem dass die Validierung ohne DTDs nicht wirklich viel Spaß macht. Ich hab dann halt eine lokale Kopie der DTD die ich benutze (XHTML 1.0 Strict) sowie der Entitydefinition die darin eingebunden sind und gebe xmllint mit dem Parameter --dtdvalid ... den URL zu meiner DTD-Kopie an (ausserdem ersetze ich noch den URL in der Doctype-Deklaration).

Insgesamt sieht das bei mir so aus: http://www.ploetzli.ch/blog/xmllint.phps. Die Konstante XMLLINT zeigt den Pfad zu xmllint (/usr/bin/xmllint) und DTDURL zeigt zu meiner DTD-Kopie (file:///home/hploetz/.../xhtml1-strict.dtd, und im gleichen Verzeichnis liegen auch xhtml-lat1.ent, xhtml-special.ent und xhtml-symbol.ent). Dann gibt es da eine Funktion xmllint die ein XHTML-Fragment (erster Parameter) wahlweise nur auf well-formedness prüft (dritter Parameter auf FALSE) oder gegen XHTML 1.0 Strict validiert (dritter Parameter auf TRUE), die dabei anfallenden Meldungen im zweiten Parameter speichert und ausserdem den Rückgabecode von xmllint (0 wenn alles glatt ging, sonst einen anderen) zurückgibt.

Weiter unten baut die Funktion das übergebene Textfragment in die Hülle ein die alle anderen Seiten auch haben um ein ordentliches Dokument draus zu machen, führt ggbf. die Ersetzung der DTD-URL aus und gibt das Resultat dann an xmllint.

Da diese Funktion über alle Inhalte drüberläuft bevor sie online gehen sollte eigentlich kein nicht valider Inhalt auftauchen, insbesondere nicht in Kommentaren (und vielleicht irgendwann mal Track/Pingbacks). Bei Kommentaren habe ich da noch eine weitere, vielleicht etwas übertriebene Sache: Kommentare werden zuerst auf well-formedness (dafür ist der Parameter da oben) geprüft. Dann weiss ich dass sie ordentliches XML sind und ich gehe mit einem Selbstbau-XML-Parser (http://www.ploetzli.ch/blog/sanitizer.phps) drüber der nur noch Elemente und Attribute übriglässt die ich für sicher halte (<style>body { display: none; }</style> gehört eher nicht dazu ;). Das Ergebnis geht dann nochmal durch die Validierung um sicher zu stellen dass zwischenzeitlich nichts schlimmes passiert ist.

[Jeena Paradies]

Hallo,

Es ist mir noch etwas aufgefallen, auf einer anderen Seite wo Elya auch kommentiert hat ist auch wieder in ihrem Text der gleiche Fehler aufgekommen: http://validator.w3.org/check?uri=http%3A%2F%2Fjeenaparadies.net%2Fweblog%2F2005%2Fjan%2Fneues-design&charset=(detect+automatically)&doctype=(detect+automatically)&ss=1

So weit ich weiß benutzt Sie OSX aber welchen Browser weiß ich nicht mehr.

Grüße
Jeena Paradies

[Götz]

Hallo Jeena!

http://validator.w3.org/check?uri=http%3A%2F%2Fjeenaparadies.net%2Fweblog%2F2005%2Fjan%2Fneues-design&charset=(detect+automatically)&doctype=(detect+automatically)&ss=1

Wenn Du als Zeichensatz z.B. Windows-1050 nimmst, dann schluckt der Validator es ohne Fehlermeldung: http://validator.w3.org/check?uri=http%3A%2F%2Fjeenaparadies.net%2Fweblog%2F2005%2Fjan%2Fneues-design&charset=windows-1250+(Central+Europe)&doctype=(detect+automatically)&ss=1.
Du kannst also einfach Deine Zeichensatzangabe ändern. Ob das allerdings eine "schöne" Lösung des Problems ist kann ich nicht beurteilen.

MfG
Götz

[Ingo Turski]

Hi,

So weit ich weiß benutzt Sie OSX aber welchen Browser weiß ich nicht mehr.

das sieht mir eher nach Windows aus. Jedenfalls verwendet sie die Gänsefüßchen im Windows-Format, die natürlich nicht in iso-8859-1 enthalten sind.
Entweder Du validierst mit windows-1252 oder - besser - Du prüfst vor dem Speichern die Einhaltung der gültigen Zeichen und konvertierst so etwas.

freundliche Grüße
Ingo

[Elya]

Hallo Ingo,

das sieht mir eher nach Windows aus. Jedenfalls verwendet sie die Gänsefüßchen im Windows-Format, die natürlich nicht in iso-8859-1 enthalten sind.

hm. das ist jetzt aber komisch. Ich weiß nicht mehr, auf welchem Rechner ich gerade diesen Kommentar geschrieben habe, aber auf  Windows nehme ich den Ziffernblock:

alt-0132 und
alt-0147

Und auf dem Mac die Tastenkombis

alt-^ und
alt-2

Kein Unicode? Dann muß ich mir was anderes überlegen, denn Windows-Zeichensatz... igitt, ne, das muß nicht sein ,-)

Gruß aus Köln-Ehrenfeld,

Elya

[Henryk Plötz]

Moin,

Kein Unicode? Dann muß ich mir was anderes überlegen, denn Windows-Zeichensatz... igitt, ne, das muß nicht sein ,-)

Kommt halt drauf an. Der Zeichensatz ist immer der gleiche, nur die Codierung ist unterschiedlich. Und die Codierung ist dem absendenden Browser im wesentlichen überlassen und er sollte sie auch angeben[1]. Dann sollte man sich die Codierungsangabe nehmen und sie wahlweise in die Datenbank tun und beim senden der Daten mitausliefern (igitt) oder man codiert sich das in seine Lieblingscodierung um und verwendet nur noch die.

Gut, man sollte bei seiner Lieblingscodierung natürlich drauf achten dass man nicht irgendwelche Zeichen wegwirft. So ein bisschen ordentliche Typographie soll schon sein. Ich hatte bei mir als Codierung glaube ich ISO-8859-15 gewählt und codiere alle Zeichen ausserhalb dieses Bereichs als Zeichenreferenzen (hoffe ich).

[1] Dass das in der Realität anders aussieht ist nun noch wieder eine andere sehr spaßige Sache. Christian hat hier im Forum einige Mühe drauf verwandt, das sollte man sich mal ansehen wenn man etwas derartiges haben will.

[Elya]

Hallo Henryk,

Und die Codierung ist dem absendenden Browser im wesentlichen überlassen und er sollte sie auch angeben[1].

Daß Safari aber ausgerechnet Windows-Codierung zurückgibt, finde ich schon skurril.

Gruß aus Köln-Ehrenfeld,

Elya

[Henryk Plötz]

Moin,

Daß Safari aber ausgerechnet Windows-Codierung zurückgibt, finde ich schon skurril.

Naja, was wäre die Alternative? Mac-Roman? Hmm, das würde immerhin auffallen ...

[MudGuard]

Hi,

Daß Safari aber ausgerechnet Windows-Codierung zurückgibt, finde ich schon skurril.
Naja, was wäre die Alternative? Mac-Roman? Hmm, das würde immerhin auffallen ...

Dann doch lieber Ronald MacDonald ;-)

cu,
Andreas

[Elya]

Hallo Jeena,

Elya, ja das ist dein Kommentar ;-) weißt du vielleicht was du da irgendwie gedrückt hast oder so?

*g* - das sind die typographischen Anführungsstriche, die ich mir neuerdings angewöhne:  „ “ - die sind imho in deinem Zeichensatz charset=iso-8859-1 nicht mit drin.

Die Ellipse "…" (3 Punkte in einem Zeichen) krieg ich in meinem Blog auch als Fehler zurück, obwohl ich dort Unicode verwende. Das finde ich jetzt wieder komisch, daß das Zeichen in utf-8 nicht mit drin sein soll. Habe es aber noch nicht geprüft.

Gruß aus Köln-Ehrenfeld,

Elya

[Ingo Turski]

Hi,

*g* - das sind die typographischen Anführungsstriche, die ich mir neuerdings angewöhne:  „ “

... aber leider im falschen Format abschickst. Ein guter Browser sollte sich an die Kodierungsvorgabe der Seite halten... ;-)

freundliche Grüße
Ingo

[Elya]

Hallo Ingo,

... aber leider im falschen Format abschickst. Ein guter Browser sollte sich an die Kodierungsvorgabe der Seite halten... ;-)

hm. Das müßte ich jetzt nochmal genauer testen. Bei Jeena hatte ich gerade Debugging mit mehreren Browsern gemacht, üblicherweise sollten die Browser aber Firefox (Win) und Safari gewesen sein.

Gruß aus Köln-Ehrenfeld,

Elya

[Jeena Paradies]

Hallo,

Ok danke für die Aufklärung, auf den Zeichensatz wäre ich nie gekommen. Jetzt aber auf Windows-blabla umzusteigen finde ich nicht richtig. Ich weiß ja nicht wer und von wo aus die Leute kommentieren werden.

Deshalb würde ich es wohl am liebsten als utf8 ausliefern. Habt ihr tipps für mich wie ich das machen soll, bzw. Anfängerfallen in die ich tappen könnte?

Grüße
Jeena Paradies

[dedlfix]

Deshalb würde ich es wohl am liebsten als utf8 ausliefern. Habt ihr tipps für mich wie ich das machen soll, bzw. Anfängerfallen in die ich tappen könnte?

Hier ein schöner langer Artikel http://dev.mysql.com/tech-resources/articles/4.1/unicode.html (in englisch) von der MySQL (behandelt aber auch allgemeine Probleme).

[Jeena Paradies]

Hallo,

Hier ein schöner langer Artikel http://dev.mysql.com/tech-resources/articles/4.1/unicode.html (in englisch) von der MySQL (behandelt aber auch allgemeine Probleme).

Danke für den Link, der hilft mir schon sehr weiter.

Warscheinlich hast du Elya den Safari benutzt, denn da steht:

----------------
If your HTML page contains a form, browsers will generally send the results back in the character set of the page. So if your page is sent in UTF-8, you will (usually) get UTF-8 results back. The default encoding of HTML documents is ISO-8859-1, so by default you will get form data encoded as ISO-8859-1, with one big exception: some browsers (including Microsoft Internet Explorer and Apple Safari) will actually send the data encoded as Windows-1252, which extends ISO-8859-1 with some special symbols, like the euro (€) and the curly quotes (“”).
----------------

Werde das gleich mal ausprobieren.

Grüße
Jeena Paradies

[Elya]

Hallo Jeena,

some browsers (including Microsoft Internet Explorer and Apple Safari) will actually send the data encoded as Windows-1252

Das glaube ich doch jetzt nicht...! IE und Safari in einem Satz ;-)  Dem gehe ich jetzt auch mal nach.

Gruß aus Köln-Ehrenfeld,

Elya

[Sven Rautenberg]

Moin!

some browsers (including Microsoft Internet Explorer and Apple Safari) will actually send the data encoded as Windows-1252, which extends ISO-8859-1 with some special symbols, like the euro (€) and the curly quotes (“”).

Wenn die Seite als UTF-8 ausgeliefert wird und als accept-charset im form auch UTF-8 steht, dann schicken alle nennenswert häufig auftretenden Browser auch UTF-8 an den Server zurück.

Sofern man nicht spezielle Stringoperationen plant, also z.B. nach exakt einem Buchstaben sucht, was durch die benutzte Skriptsprache in die "Suche nach exakt einem Octet" umgesetzt wird, ist es vollkommen irrelevant, ob man UTF-8 oder ISO-8859-1 verwendet. Dazu hatte ich in der Vergangenheit hier im Forum schon etliche Erklärungen geliefert.

Auch die Datenbank muß nicht zwingend UTF-8 verstehen, es reicht vollkommen aus, wenn sie in der Lage ist, 8-Bit-Texte zu speichern und wieder auszugeben. Man muß dann halt einkalkulieren, dass ein Umlaut nicht als ein Zeichen durchgeht, sondern als zwei Zeichen, und das Eurosymbol sogar als drei Zeichen.

Böse Nebeneffekte wären zum Beispiel eine unsachgemäße Anwendung der wordwrap-Funktion. Eine Begrenzung der Zeilenlänge auf 80 Zeichen wirkt sich in PHP so aus, dass z.B. nach 80 Byte eine Leerzeiche eingefügt wird. Wenn man in der Zeile aber viele UTF-8-Zeichen mit Doppelbytes hat, sind zwar 80 Byte enthalten, das Resultat sind aber z.B. nur 40 Zeichen in der Zeile. Und natürlich könnte auch ein UTF-8-Zeichen in der Mitte durchgeschnitten und damit zerstört werden.

Sortierungsmäßig hingegen ist UTF-8 extra so konzipiert, dass man auch ohne Kenntnis, dass es sich um UTF-8 handelt die Strings einfach mit einer simplen bytewertorientierten Sortierung in eine Reihenfolge bringen kann. ÄÖÜ werden genau wie bei ISO-8859-1 hinten einsortiert.

Sortieren nach Alphabet ist allerdings nur auf den ersten Blick und bei 7-Bit-ASCII-Zeichen "ganz einfach". Die deutschen Umlaute beispielsweise werden beim "richtigen" Sortieren eigentlich wie A, O und U behandelt. Und auch andere Unicode-Alphabete sind in ihrer Codefolge nicht so abgelegt, dass ein Sortieren nach den Codepoint-Werten automatisch das aufsteigende Alphabet ergibt, sondern es müssen dafür spezielle Sortier-Routinen eingesetzt werden.

Zurück zu den Browsern und "accept-charset": Man kann dort in der Tat mehrere Zeichencodierungen als erlaubt eintragen. Die Browser nehmen das dann auch tatsächlich für bare Münze und wenden die Codierung an, die gerade noch paßt - soll heißen: Wenn ISO-8859-1 und UTF-8 erlaubt sind, dann wird normaler Text (auch mit Umlauten) als ISO-8859-1 verschickt, wird aber das Eurozeichen eingetippt, schickt der Browser UTF-8.

Das ist soweit noch nicht schlimm. Das Problem ist nur: Außer Opera teilt kein einziger Browser mit, welche Codierung er denn nun gewählt hat. Und nur an den gesendeten Zeichen-Bytes kann man es auch nicht erkennen - außer diese Codierung liefert für die Nicht-UTF-8-Alternative Zeichencodes, die in UTF-8 nicht vorkommen können.

Deshalb ist es absolut keine gute Idee, im accept-charset mehr als eine Möglichkeit anzugeben, und es ist (IIRC wegen einiger älterer IEs) auch nahezu unumgänglich, die Formularseite selbst schon als UTF-8 auszuliefern.

Die deutsche Wikipedia hat im Vorfeld ihrer Umstellung auf UTF-8 (etwas, das tatsächlich unumgänglich ist, weil man nur mit einem voll unicodefähigen Zeichencodierungsschema zukunftssicher ALLE Zeichen verwalten kann) diverse Diskussionen und Feststellungen hinsichtlich der Verwendbarkeit der einzelnen Browser zum BEARBEITEN der Wikipedia-Seiten festgehalten. Die Seiten-URL finde ich jetzt spontan nicht, aber es wurde dort eben akzeptiert, dass es etliche Browser gibt, die enthaltene Unicode-Zeichen durch das Bearbeiten der Seite zerstören.

Bei Gästebüchern und Forums-Postings ist sowas allerdings halb so schlimm, weil es üblicherweise nicht vorkommt, dass beliebige Besucher die Texte vorheriger Besucher verändern. Schlimmstenfalls kommen eben die Sonderzeichen des geschriebenen Textes nicht ordentlich durch - ist dann halt Pech.

- Sven Rautenberg

[Jeena Paradies]

Hallo,

Vielen dank für die ausführliche Antwort ich werde versuchen alles zu beachten. Ich hatte sowieso vor dann die ganze Seite immer als utf8 auszuliefern.

Grüße
Jeena Paradies

[Elya]

Hallo Sven

Die deutsche Wikipedia hat im Vorfeld ihrer Umstellung auf UTF-8 (etwas, das tatsächlich unumgänglich ist, weil man nur mit einem voll unicodefähigen Zeichencodierungsschema zukunftssicher ALLE Zeichen verwalten kann) diverse Diskussionen und Feststellungen hinsichtlich der Verwendbarkeit der einzelnen Browser zum BEARBEITEN der Wikipedia-Seiten festgehalten. Die Seiten-URL finde ich jetzt spontan nicht,

http://de.wikipedia.org/wiki/Wikipedia:Umstellung_auf_Unicode

Gruß aus Köln-Ehrenfeld,

Elya