Also oben war die Rede von Validator. Ich selbst habe die WebDevToolbar von Chris Pederick im FF win. Dort kannst unter Einstallungen > Extras die Standardabfrage des W3C-Validators verwenden, oder andere angeben, z.B. Validome und ggf. Parameter angeben. Standardmäßig steht dort (in meiner Version 1.1.4) auch für HTML validieren: http://validator.w3.org/check?verbose=1&uri=. Wo ist also das Problem?
Der einzig zuverlässige Dienst ist mitnichten alleinig der W3C-Validator, denn zuverlässig heißt nicht dem Zufall überlassen. Oft genug ist dieser Dienst überlastet, nicht erreichbar – warum nicht auf Validome ausweichen, wenn dieser auch gemäß der Spezifikation und dazu auch in meiner Sprache verfügbar ist und sicher nicht ungenauer?

Die HTML4-Spezifikation erlaubt – bis auf wenige Ausnahmen – alle Unicode-Zeichen in URLs

Das ist unbestritten – aber sobald XHTML, XML usw. verwendet wird – sollte jeder kleine Fehler vermieden werden, damit der Browser ∇ ∉ usw. nur dann anzeigt, wenn es ausdrücklich gewollt ist.

HTML4 expands the allowable range to include all of the Unicode character set

. Bei Scripts verlasse ich mich da nicht nur die Theorie, sondern den praktischen Einsatz.

Es sollte natürlich nicht UNIX dort stehen, sondern UTF-8 bzw. Unicode. Und das ist ein anderes Thema, stimmt, aber es hat doch wieder mit Kodierung zu tun (ich schrieb missverständlich "Format"), das war mein Gedanke. Ich hatte da mal ein supi php-Script und falsch kodiert – auf dem PC geschrieben und gespeicjhert, aber eben nicht geschmeidig genug für den Nicht-Windows-Server. Natürlich ging gar nichts mehr und es lag auch daran, dass sich der im Header des Servers festgelegte Zeichensatz (ISO-8859-1) vom dem im Dokument angegebenen Zeichensatz (UTF-8) unterschied. (Ganz schlechter Stil, aber ist hoffentlich etwas klarer, was ich meinte).
Heute morgen war es so früh!

Der einzige zuverlässige Dienst für die Validierung von HTML ist der offizielle W3C-Validator – Er ist nicht umsonst „offiziell”. Der Firefox HTML-Validator ist kein Validator sondern ein „Tidy“-Implementation (http://tidy.sourceforge.net/), was ein Programm ist um Webseiten valide zu machen bzw. aufzuräumen.

Man kann beim HTML-Validator statt des Tidy-HTML-Parsers einen SGML-Parser auswählen. Das ist lt. Autor des Add-ons der gleiche, der auch beim W3C-Validator zum Einsatz kommt (http://openjade.sourceforge.net/).

Bei etlichen Stichproben, die ich gemacht habe, lieferte die Erweiterung das gleiche Ergebnis und die gleichen Meldungen wie der W3C-Validator.

Das stimmt so nicht.

Erweiterungen würde ich grundsätzlich misstrauen, weil jedes System empfindlich gegen äußere Eingriffe ist

Der einzige zuverlässige Dienst für die Validierung von HTML ist der offizielle W3C-Validator – Er ist nicht umsonst „offiziell”. Der Firefox HTML-Validator ist kein Validator sondern ein „Tidy“-Implementation (http://tidy.sourceforge.net/), was ein Programm ist um Webseiten valide zu machen bzw. aufzuräumen. Dort wo es nicht weiter kommt gibt es dann Fehler aus, manchmal sind das aber keine, sondern Mängel von Tidy.

Da im Quelltext der Seite der Zeichensatz festgelegt ist, können Browser die Zeichen auch zuordnen. Kodieren ist also dann nicht nötig, maskieren schon.

Die HTML4-Spezifikation erlaubt – bis auf wenige Ausnahmen – alle Unicode-Zeichen in URLs (Quelle):

HTML4 expands the allowable range to include all of the Unicode character set

Allerdings ist die Verwendung der Zeichen des ISO-8859-1-Standards empfehlenswert, da er auch für URLs besser implementiert zu sein scheint. (Er enthält ja aber die deutschen Umlaute und das Eszett.)

Es kommt auch darauf an, in welchem Format ein Dokument gespeichert wird. Im WindwosEditor gibt es z. B. ANSI und UNIX als Speicherformat. Je nach Server können bei Speicherung im "verkehrten" Format auch seltsame Zeichen im Browser erscheinen.

Das ist völlig falsch. ANSI und Unix im Windows-Editor beziehen sich nur auf die Zeilenenden. Unix setzt ans Ende einer Zeile nur ein LF (Zeilenvorschub), ANSI-Systeme LF+CR (Zeilenvorschub, Wagenrücklauf) (mehr bei Wikipedia). Mit dem Zeichensatz hat das aber überhaupt nichts zu tun. Dafür gibt es im Windows-Editor die Einstellung UTF-8 und Windows-Zeichensatz (oder so, ich arbeite gerade an einem Mac).

Grundsätzlich haben Zeichensatz und Dateiformat nichts miteinander zu tun.

Ist die FF-Browser-Erweiterung kompatibel zu deiner Browserversion, eventuell weiteren Add-Ons und sonstigen Einstellungen, die du im Browser verändert hast (z.B. Zeichenkodierung)?

Ein Test mittels W3C-Validator gibt jedoch ein ordentliches Ergebnis mit 0 Fehlern aus. Nun sitz ich natürlich da und frag mich, welchem Test ich trauen soll.

Erweiterungen würde ich grundsätzlich misstrauen, weil jedes System empfindlich gegen äußere Eingriffe ist – aber das ist nur meine persönliche Meinung. Da im Quelltext der Seite der Zeichensatz festgelegt ist, können Browser die Zeichen auch zuordnen. Kodieren ist also dann nicht nötig, maskieren schon.

Es kommt auch darauf an, in welchem Format ein Dokument gespeichert wird. Im WindwosEditor gibt es z. B. ANSI und UNIX als Speicherformat. Je nach Server können bei Speicherung im "verkehrten" Format auch seltsame Zeichen im Browser erscheinen. Ein Validator sagt dann z.B.

…Found one or more Bits in Line XX I cannot interpret as UTF8.

Es wurde dann entweder nicht maskiert oder im "ungeschmeidigen" Format serviert.

Habe auch schon ein wenig recherchiert:
Firefox kodiert Sonderzeichen automatisch beim Aufruf, Internet Explorer lässt sie sowohl kodiert als auch unkodiert durch. Ich glaube aus diesem Grund hab ich mich vor einer Weile dazu entschieden, diese Zeichen in Links immer kodiert anzugeben.

wenn man jetzt im Beispiel noch die "ß" in den beiden URLs in der Fußzeile in die entsprechenden Hexcodes ändert (Fußball -> Fu%C3%9Fball), dann ist alles schön

LG,
Dan

CSS-Tabellen Galerie

Eric, deine Aufhübschung find ich wegen der grafischen Präsentation Klasse auch für Nicht-Fußballer.