UTF-8

Beitrag von **RolWg** » 22.05.2009, 19:47

Hallo zusammen,

wenn ich mittels .htaccess das character encoding vorgebe,

AddDefaultCharset utf-8

beschwert sich der W3C-Validator, er fände keines.

Kann mir jemand verraten, warum der W3C das nicht sieht?

von **Anzeige von ABAKUS** »

Hochwertiger Linkaufbau bei ABAKUS:

Google-konformer Linkaufbau
nachhaltiges Ranking
Linkbuilding Angebote zu fairen Preisen
internationale Backlinks

Wir bieten Beratung und Umsetzung.
Jetzt anfragen: 0511 / 300325-0

Beitrag von **Mork vom Ork** » 22.05.2009, 21:36

RolWg hat geschrieben:wenn ich mittels .htaccess das character encoding vorgebe,
Code: Alles auswählen
AddDefaultCharset utf-8
beschwert sich der W3C-Validator, er fände keines.

Besorge dir Firefox und dazu Firebug oder LiveHTTPHeaders. Beide Erweiterungen erlauben es, die HTTP-Protokolldaten anzuzeigen, die zwischen Browser und Server ausgetauscht werden (LiveHTTPHeaders: über den Seiteninformationen-Dialog; Firebug: auf der Net-Seite), so dass du selbst prüfen kannst, ob dein Server die utf-8-Angabe sendet. Vermutlich ist das nicht der Fall, funktioniert denn die .htaccess überhaupt?

Beitrag von **RolWg** » 24.05.2009, 15:03

Hallo "Mork vom Ork",

danke für Deine Nachfrage.

Mork vom Ork hat geschrieben: Besorge dir Firefox und dazu Firebug oder LiveHTTPHeaders. ...
Vermutlich ist das nicht der Fall, funktioniert denn die .htaccess überhaupt?

Als Antwort Header bekomme ich:

Code: Alles auswählen

RESPONSE HTTP/1.1 200 OK
Date Sun, 24 May 2009 13&#58;50&#58;45 GMT
Server HTTPD
X-Powered-By PHP/5.2.5
Expires Fri, 22 May 2009 19&#58;15&#58;43 GMT
Last-Modified Fri, 22 May 2009 19&#58;15&#58;43 GMT
Keep-Alive timeout =5, max = 100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=utf-8
Content-Language de
imagetoolbar false
content-srcipt-type text/javascript

Und - ja, die .htaccess funktioniert ansonsten (301 redirect funktioniert).
Merkwürdig finde ich "Connection Keep-Alive" und "Transfer-Encoding chunked".

Allerdings bekomme ich heute vom W3C
(nach einigem 'Rumprobieren' gestern und heute)

Code: Alles auswählen

No Character Encoding Found! Falling back to UTF-8.

Gestern war's noch

Code: Alles auswählen

No Character Encoding Found! Falling back to ISO-8859-1.

Da ich ja schon in der .htaccess das encoding definiere, habe ich wenig Lust, das auch noch 'mal mit

Code: Alles auswählen

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

zu machen. Gibt's da eigentlich Regeln, welches von beiden wann besser genommen werden sollte?

von **Anzeige von ABAKUS** »

Beitrag von **RolWg** » 24.05.2009, 15:23

Genaugenommen schreibt der W3C-Validator:
"This document was Tentatively checked as XHTML 1.0 Transitional"
Diese "Vorläufigkeit" bezieht sich auf das ausschließliche Encoding mittels .htaccess.

Er schreibt weiter
"No Character encoding declared at document level"
Wenn ich das W3C auf
https://www.w3.org/International/tutori ... #Slide0250 richtig verstehe, dann ist das Encoding mittels .htaccess nur ein "default-overriding"?
Wann man jetzt besser .htaccess benutzt und wann die HTTP-header information, ist mir allerdings immer noch nicht so richtig klar.

Beitrag von **Mork vom Ork** » 24.05.2009, 16:30

RolWg hat geschrieben:Als Antwort-Header bekomme ich:
Code: Alles auswählen
RESPONSE HTTP/1.1 200 OK
&#91;..&#93;
Content-Type&#58; text/html; charset=utf-8

Wenn du in dieser Seite kein <meta>-Content-Type-Element hast, dann gibt der Server die Zeichenkodierung korrekt aus, AddDefaultCharset funktioniert also und die Validator-Meldung muss eine andere Ursache haben.

Merkwürdig finde ich "Connection Keep-Alive" und "Transfer-Encoding chunked"

Das ist vollkommen normal. Wenn du von Oma am Telefon das Kirschkuchenrezept haben möchtest und dann gleich noch wissen willst, ob sie Sonntag zum Kaffee kommt, wählst du ja auch nicht zweimal, sondern stellst beide Fragen in derselben Verbindung. Genauso läuft es zwischen Browser und Server, der Browser stellt nicht für jede Grafik und was sonst noch von einer Seite benötigt wird, eine neue Verbindung her, sondern benutzt die, die er schon hat. Erhöht die Geschwindigkeit und verringert die Netzlast.

Die Kodierung chunked ist eine sichere Methode, die Daten gerade bei solchen stehenden Verbindungen unfallfrei zu übertragen.

Gibt's da eigentlich Regeln, welches von beiden wann besser genommen werden sollte?

Wenn der Benutzer deine Seite auf seinem Rechner abspeichert (nicht als Lesezeichen, sondern richtig als Datei), dann geht zumindest bei Firefox die per HTTP übermittelte Information zur Zeichenkodierung verloren. Da der Standardzeichensatz iso-8859-1 bzw. windows-1252 ist, gibt's Zeichensalat, ist die Seite eigentlich utf-8-kodiert. Schreibst du die Zeichenkodierung stattdessen als <meta>-Element in Seite, stellt sich das Problem logischerweise nicht.

Das ist aber IMHO auch der einzige Vorteil der Verwendung von <meta>, ansonsten sind beide gleichwertig, wie ja auch das "equiv" (äquivalent) in <meta http-equiv= …> aussagt.

Abraten würde ich davon, beide Wege zu nutzen. Sind beide Angaben gleich, ist das zwar wurscht, aber bei unterschiedlichen Angaben ist nicht sicher, wer bei welchem Browser Vorrang hat, was dann im dümmsten Fall zu jenen unerklärlichen Darstellungsfehlern führt, an denen man sich stundenlang die Zähne ausbeißt.

Genaugenommen schreibt der W3C-Validator:
"This document was Tentatively checked as XHTML 1.0 Transitional"
Diese "Vorläufigkeit" bezieht sich auf das ausschließliche Encoding mittels .htaccess.

Also ich liefere die Kodierung wie du im HTTP-Kopf, nicht als <meta>, und bekomme "This document was successfully checked as HTML 4.01 Strict!", trotz des Hinweises "No Character encoding declared at document level".
Bei XML bzw. XHTML hat sich in Sachen Zeichenkodierung AFAIK nichts geändert.

Kannst du vielleicht die URL nennen?

dann ist das Encoding mittels .htaccess nur ein "default-overriding"?

Es gibt verschiedene Möglichkeiten, in der Serverkonfiguration festzulegen, ob und welche Kodierungsinformation per HTTP ausgegeben wird. Mit AddDefaultCharset legst du fest, dass alle (Text-) Objekte, die nicht von sonstwoher eine Kodierungsinfo haben, eine Standardkodierungsinfo verpasst bekommen.

"Sonstwoher" bezieht sich insbesondere auf die Option AddCharset sowie auch AddType.
Du kannst beispielsweise der Dateiendung .html auch explizit utf-8 zuordnen, indem Du AddCharset utf-8 .html oder AddType "text/html; charset=utf-8" .html einträgst. Oder du legst eine separate Dateiendung fest; AddCharset iso-8859-15 .15 würde der Datei bla.html.15 den Typ text/html (aus AddType text/html .html) und die Kodierung iso-8859-15 (aus AddCharset iso-8859-15 .15) zuordnen.

Diese Einstellungen würden jene von AddDefaultCharset überschreiben - das ist beim W3C mit "default-overriding" gemeint.

Beitrag von **RolWg** » 25.05.2009, 08:42

Huii,

das ist ja ein richtiger "Aufsatz" geworden - vielen Dank.

Mit der Frage:

RolWg hat geschrieben: Gibt's da eigentlich Regeln, welches von beiden wann besser genommen werden sollte?

meinte ich aber mit "beiden"
- meta http equiv und
- .htaccess
nicht: "http equiv" versus "meta".

Wenn ich sowohl die .htaccess benutze als auch http-equiv, dann meckert W3C nicht mehr aber z.B.
ranks.nl meldet 2mal die Zeile
"Content-Type: text/html; charset=utf-8".
Das finde ich störend - ist aber wohl im Sinne von validem Code der ausschließlichen Angabe in der .htaccess (mit den beschriebenen Nebenwirkungen "tentatively") vorzuziehen.

Beitrag von **Mork vom Ork** » 25.05.2009, 12:20

RolWg hat geschrieben:Wenn ich sowohl die .htaccess benutze als auch http-equiv, dann meckert W3C nicht mehr

Nachvollziehbar, da der W3C-Validator dann wohl die Angabe aus dem <meta>-Teil nimmt und sich damit zufrieden gibt.

sowohl die .htaccess benutze als auch http-equiv […] ist aber wohl im Sinne von validem Code der ausschließlichen Angabe in der .htaccess (mit den beschriebenen Nebenwirkungen "tentatively") vorzuziehen.

Ich denke, da zieht dich ein vermutliches Fehlverhalten (Nicht-Erkennen der Angabe im HTTP-Kopf) zu einem falschen Schluss.

Wenn du die HTTP-Angabe rausnimmst und nur die <meta>-Angabe nutzt, wird der Validator sich vermutlich weiterhin nicht beschweren; würde er tatsächlich beide Angaben haben wollen, müsste er dann etwas in der Richtung „No Character encoding declared at protocol level“ ausspucken.

Klärt sich das nicht HTTP-seitig, solltest du es meiner Meinung nach bei der ausschließlichen Verwendung der <meta>-Angabe belassen. Die gleiche Sache an zwei getrennten Stellen zu deklarieren birgt, wie ich schon anmerkte, immer einen Stolperstein.

Beitrag von **RolWg** » 20.07.2009, 13:28

Hallo Mork vom Ork,

Du scheinst Dich mit dem obigen Kram (header / .htaccess) ziemlich gut auszukennen.
Kannst Du vielleicht 'nen Tipp verteilen, wo ich das strukturiert nachlesen kann? Lieber wär' mir nicht in angelsächsisch

geht aber auch.

Also wann welche Methode, wann und wie mischen, was hat Priorität, wie ist die beste Syntax, wie am besten testen (Live http-headers)?

Du hast dazu nicht zufällig ein größeres Tutorial geschrieben

?

Irgendwie gibt's dazu tausendundeinen Tipp in zig verschiedenen Schreibweisen im Netz und mein Provider zeigt sich bei Problemen etwas mürrisch.

Eigentlich wollte ich "nur" eindeutig und ein für allemal UTF-8 festlegen,
meine Startseite in einem Unterverzeichnis (statt index.php im root) (trotzdem) suma-freundlich unterbringen und
userfreundliche Fehlerseiten für 404er und 500er-Fehler machen.

Da fand ich den Schritt ganz systematisch, das alles per .htaccess zu regeln.
(Irgendwo in diesem Forum empfiehlst glaube ich Du, genau das nicht zu machen, um die vielen .htaccess-Zugriffe zu minimieren?)

Leider wird der .htaccess-Befehl :
"redirect 301 https://tld.de https://tld.de/kategorie1/thema1.php"
oder
"redirect 301 https://tld.de/index.php https://tld.de/kategorie1/thema1.php"
vollständig vom Server ignoriert (index.php wird trotzdem angezeigt)

und nur _alternativ_ der php-Befehl in der index.php :
"header ("Location: kategorie1/thema1.php");" in der index.php bei meinem Provider ausgeführt.

(Provider behauptet, es gäbe bei ihm keine Einschränkungen der .htaccess)

Oooops - sorry für diesen langen Bittbrief

Beste Grüße

Beitrag von **Synonym** » 20.07.2009, 14:27

https://httpsd.apache.org/docs/2.0/mod/ ... l#redirect

The old URL-path is a case-sensitive (%-decoded) path beginning with a slash. A relative path is not allowed. The new URL should be an absolute URL beginning with a scheme and hostname.
Redirect /service https://foo2.bar.com/service

Sprich, mache mal aus Deinem
"redirect 301 https://tld.de/index.php https://tld.de/kategorie1/thema1.php"
ein
"redirect 301 /index.php https://tld.de/kategorie1/thema1.php"

Beitrag von **Mork vom Ork** » 20.07.2009, 14:51

RolWg hat geschrieben:Kannst Du vielleicht 'nen Tipp verteilen, wo ich das strukturiert nachlesen kann?

Ob das so strukturiert ist, wie du gerne möchtest, weiß ich nicht, aber ich gucke seit jeher einfach in die Originalanleitung: https://httpsd.apache.org/docs/2.2/, unter https://httpsd.apache.org/docs/2.2/mod/ ... rence.html findest du sämtliche Anweisungen, unter https://httpsd.apache.org/docs/2.2/mod/ eine Übersicht über die einzelnen Module.
Das Original ist zwar Englisch, die Seiten stehen aber teilweise übersetzt zur Verfügung. Sicherlich kapiert man nicht alles sofort und hat in einer halben Stunde den totalen Überblick, aber mit der Zeit wird das schon. Du solltest die für dich interessanten Abschnitte ganz lesen, zur Not zwei- oder dreimal; ich merke immer wieder, dass Leute Fehler machen, weil sie die Anleitung schlichtweg nicht ordentlich gelesen haben (siehe Synonyms Hinweis).

wie am besten testen (Live http-headers)?

LiveHTTPHeaders ist sehr praktisch. Zusätzlich solltest du [url=https://getfirebug[/url]Firebug[/url] installieren.

Eigentlich wollte ich "nur" eindeutig und ein für allemal UTF-8 festlegen,

Steht oben.

meine Startseite in einem Unterverzeichnis (statt index.php im root)

Wenn's die Startseite ist, was macht sie dann in einem Unterverzeichnis? Das hört sich für mich so an, als wenn du deinem Auto einen Esel vorspannen möchtest, anstatt den Motor zu reparieren.

userfreundliche Fehlerseiten für 404er und 500er-Fehler machen./quote]
ErrroDocument

Da fand ich den Schritt ganz systematisch, das alles per .htaccess zu regeln.
(Irgendwo in diesem Forum empfiehlst glaube ich Du, genau das nicht zu machen, um die vielen .htaccess-Zugriffe zu minimieren?)
Die .htaccess ist für Hosting-Kunden in der Regel der einzigste Weg, Apache-Einstellungen unterzubringen, insofern geht es nicht ohne. Ich empfehle nur, die .htaccess nicht zu groß werden zu lassen, weil sie bei jeder Anfrage mindestens einmal eingelesen wird. 300 einzelne Weiterleitungen vom Wurzelverzeichnis aus täte ich zum Beispiel lieber in ein Skript auslagern, 300 einzelne Weiterleitungen in einem bestimmten Ordner in eine .htaccess in diesem Ordner (statt in /.htaccess).

und nur _alternativ_ der php-Befehl in der index.php :
"header ("Location: kategorie1/thema1.php");" in der index.php bei meinem Provider ausgeführt.
Auch nicht richtig, Location benötigt eine vollständige URL.

Beitrag von **RolWg** » 21.07.2009, 15:27

Zunächst Dank an Synonym -
jetzt funkts.

@Mork vom Ork,
Danke auch an Dich. Ich werde mich wohl wirklich mal intensiver mit den ganzen Apache-Seiten beschäftigen müssen, die mir allerdings immer etwas zuuu dröch sind.

Zu meinen Versuchen mit relativen Pfaden: Bin immer versucht, mit relativen Pfaden zu arbeiten, dann kann ich das Ganze auch auf meiner Spielwiese Xampp entwickeln und testen.
Und der relative Pfad

Code: Alles auswählen

header &#40;"Location&#58; frontend/01_home/home.php"&#41;;

funktioniert prima. Da muß kein http://... vor.

Mork vom Ork hat geschrieben:
RolWg hat geschrieben:Kannst Du vielleicht 'nen Tipp verteilen, wo ich das strukturiert nachlesen kann?

Ich meinte tatsächlich nicht nur die redirects sondern auch 'ne Argumentation,
wann .htaccess

Code: Alles auswählen

AddDefaultCharset utf-8
redirect 301 /index.php http&#58;//TLD.de/frontend/01_home/home.php

wann lieber http equiv

Code: Alles auswählen

<meta http-equiv="content-language"	content="de" />
<meta http-equiv="Content-type"		content="text/html; charset=utf-8" />
<meta http-equiv="imagetoolbar" 		content="false" />

wann lieber header

Code: Alles auswählen

header &#40;"Location&#58; frontend/01_home/home.php"&#41;;

wann lieber meta?

Code: Alles auswählen

<meta name="language" 					content="de" />

War halt 'n Versuch, ob's von Dir ein Buch gibt

Beitrag von **Mork vom Ork** » 21.07.2009, 20:49

RolWg hat geschrieben:Und der relative Pfad
Code: Alles auswählen
header &#40;"Location&#58; frontend/01_home/home.php"&#41;;
funktioniert prima. Da muß kein http://... vor.

Praktisch nicht, theoretisch schon. Und da wir ja alle schön nach Standard arbeiten und selbiger unmissverständlich sagt: „absoluteURI“ … Vielleicht kann ich dich ja mit header("Location: http://" . $_SERVER["HTTP_HOST"] . "/frontend/01_home/home.php"); vom Pfad des Lichts überzeugen ;)

Ich meinte tatsächlich nicht nur die redirects sondern auch 'ne Argumentation, wann .htaccess, wann lieber http-equiv, wann lieber header

Das ist einfach: <meta>-http-equiv ist, wie der Name schon andeutet, im Endeffekt das Gleiche wie header() - header() gibt Daten in den HTTP-Strom aus, http-equiv steht für Daten, die zum HTTP-Strom gehören sollen. Der Vorteil von header() ist, dass eventuell nicht jedes Programm <meta>-http-equiv verarbeitet, der Vorteil von <meta>-http-equiv ist wiederum, dass die Informationen auch dann nicht verloren gehen, wenn der Besucher die Seite auf seinem Rechner abgespeichert.

Die .htaccess wiederum hat viele Aufgaben und deckt auch weitere (URL- bzw. Datei-) Bereiche ab als header(), was naturgemäß auf PHP beschränkt ist, und <meta>, was ebenso naturgemäß auf HTML beschränkt ist. Ansonsten auch hier: Egal.

Und was Dinge wie

<meta name="language" content="de" />

betrifft, halte ich mich an die Grundregel, für alles, für was es einen relevanten Standard gibt (RFC ist relevant, „benutzen alle“ nicht), keinen anderen Kram zu benutzen. Content-Language ist im HTTP-Protokoll definiert, da braucht's kein zusätzliches <meta>-language.

Das ist natürlich alles leicht dahergesagt, in der Praxis tauchen doch immer Fragen auf, aber die muss man dann halt anhand der vorhandenen Dokumente recherchieren. So hab ich's gemacht, und wenn du's auch so machst, bist du irgendwann so klug wie ich und schreibst das Buch, das ich nicht geschriebe habe, und verdienst damit Millionen ;)

Beitrag von **RolWg** » 22.07.2009, 08:37

Hi Mork,

Mork vom Ork hat geschrieben: … Vielleicht kann ich dich ja mit header("Location: http://" . $_SERVER["HTTP_HOST"] . "/frontend/01_home/home.php"); vom Pfad des Lichts überzeugen

Theoretisch ja ...

Aber das ist ja wieder PHP und nicht .htaccess
und ich dachte, Umleitungen / redirects, etc. stringent nur in dieser ?

Beitrag von **Mork vom Ork** » 22.07.2009, 08:57

RolWg hat geschrieben:Aber das ist ja wieder PHP und nicht .htaccess
und ich dachte, Umleitungen / redirects, etc. stringent nur in dieser ?

Nee, ja, das kommt auf den Anwendungsfall an. Grundsätzlich .htaccess, nimmt die jedoch monströse Ausmaße an, sollte man sich überlegen, ob's nicht eine schlankere Möglichkeit gibt. Wann aber nun was praktikabel ist, hängt -wie gesagt- vom Einzelfall ab - da hilft nur der gesunde Menschenverstand.

Auf deine header()/Location:-Verwendung bin ich nur eingegangen, weil du sie genannt hattest.

Ich weiß nicht, was du da oben mit „etc“ meintest, aber du solltest dann auch nicht zu viel in einen Topf werfen. Im Falle von Content-Language ist es egal, ob .htaccess, header() oder <meta>-http-equiv angewendet wird; das ist aber nicht unbedingt auf andere Funktionen übertragbar.

Beitrag von **RolWg** » 22.07.2009, 10:30

Mork vom Ork hat geschrieben: Nee, ja, das kommt auf den Anwendungsfall an. Grundsätzlich .htaccess, nimmt die jedoch monströse Ausmaße an, sollte man sich überlegen, ob's nicht eine schlankere Möglichkeit gibt. Wann aber nun was praktikabel ist, hängt -wie gesagt- vom Einzelfall ab - da hilft nur der gesunde Menschenverstand.

Den jeder glaubt, zu haben ...,

Mork vom Ork hat geschrieben: Auf deine header()/Location:-Verwendung bin ich nur eingegangen, weil du sie genannt hattest.
Ich weiß nicht, was du da oben mit „etc“ meintest

404er, 500er-Fehlerseiten

Aber ich will Dich nicht ausschließlich in Beschlag nehmen.
Danke für Deine ausführlichen Hilfen.