Wie Apache auf UTF-8 umstellen?
Christoph Schneegans
Ich muß^Wdarf mich nach längerer Zeit mal wieder mit Apache
beschäftigen. Schwierigkeiten machen mir gerade Nicht-ASCII-Zeichen in
URLs, und ich möchte am liebsten ganz vorne anfangen und verstehen,
wie Apache hier "tickt".
Wenn ich mit einem Client die nicht vorhandene Ressource
GET /%C3%BC.txt HTTP/1.0
abrufe, erhalte ich
HTTP/1.1 404 Not Found
Server: Apache/2.2.9 (Win32)
Content-Type: text/html; charset=iso-8859-1
<p>The requested URL /ü.txt was not found on this server.</p>
zurück. Dies zeigt doch, daß Apache die URL als ISO-8859-1-codiert
annimmt. Würde Apache sie als UTF-8-codiert betrachten, sollte die
Antwort doch
HTTP/1.1 404 Not Found
Server: Apache/2.2.9 (Win32)
Content-Type: text/html; charset=iso-8859-1
<p>The requested URL /ü.txt was not found on this server.</p>
oder äquivalent
HTTP/1.1 404 Not Found
Server: Apache/2.2.9 (Win32)
Content-Type: text/html; charset=utf-8
<p>The requested URL /ü.txt was not found on this server.</p>,
sein. (Die Bodies habe ich in allen drei Beispielen zwecks Lesbarkeit
bereits entsprechend dem "charset"-Parameter decodiert; die des
zweiten und dritten Beispiels wären auf Byte-Ebene also
unterschiedlich.)
Kann man Apache so einstellen, daß URLs mit %HH-Sequenzen als UTF-8-
codiert betrachtet werden?
--
<http://schneegans.de/web/kanonische-adressen/> · Gute URLs
Andreas Prilop
> Wenn ich mit einem Client die nicht vorhandene Ressource
> GET /%C3%BC.txt HTTP/1.0
> abrufe, erhalte ich
> HTTP/1.1 404 Not Found
> Content-Type: text/html; charset=iso-8859-1
> <p>The requested URL /ü.txt was not found on this server.</p>
>
> zurück. Dies zeigt doch, daß Apache die URL als ISO-8859-1-codiert
> annimmt.
Das sollte mit
http://httpd.apache.org/docs/2.2/mod/mod_headers.html#header
zu korrigieren sein.
--
In memoriam Alan J. Flavell
http://www.alanflavell.org.uk/charset/
Carsten Wiedmann
> Hallo allerseits!
>
> Ich muß^Wdarf mich nach längerer Zeit mal wieder mit Apache
> beschäftigen. Schwierigkeiten machen mir gerade Nicht-ASCII-Zeichen in
> URLs, und ich möchte am liebsten ganz vorne anfangen und verstehen,
> wie Apache hier "tickt".
>
> Wenn ich mit einem Client die nicht vorhandene Ressource
>
> GET /%C3%BC.txt HTTP/1.0
>
> abrufe, erhalte ich
>
> HTTP/1.1 404 Not Found
> Server: Apache/2.2.9 (Win32)
> Content-Type: text/html; charset=iso-8859-1
>
> <p>The requested URL /ü.txt was not found on this server.</p>
>
> zurück. Dies zeigt doch, daß Apache die URL als ISO-8859-1-codiert
> annimmt.
Der Apache hat eigentlich gar keine Ahnung von der Kodierung, sondern reicht
die erhaltene URI as-is weiter. Es ist dann Aufgabe der Zielanwednung
(PHP/Perl) diese korrekt weiterzuverarbeiten, bzw. bei direkter Ausgabe der
URI als String, einen korrekten Charset zu setzten oder den String passend
umzukodieren.
Was jetzt die internen Status- (Fehler- ) Seiten angeht, so sind diese beim
Apache hardcodiert auf ISO-8859-1. Da der Apache nichts umkodiert, kommt
dann bei einer URI mit "%C3%BC", ausgegeben in einer Seite mit ISO-8859-1,
eben "ü" heraus.
Wenn man das ErrorDocument selbst erzeugt, kann man dann naürlich dasd
Charset UTF-8 setzten und es käme hier das erwartete "ü" heraus.
Interessant wird das (das direkte durchreichen der URI) gerade auch bei
Zugriffen auf das Dateisystem, weil unter Windows auch wirklich die Datei
"ü.txt" gefunden wird. Unter *nix hat man ja häufig die C-Locale für Server
und Dateien (namen) liegen dann ISO-8859-1 kodiert auf der Platte. Hier
würde eine "ü.txt" oft nicht gefunden werden, sondern man müsste da
"%FC.txt" benutzen.
> Kann man Apache so einstellen, daß URLs mit %HH-Sequenzen als UTF-8-
> codiert betrachtet werden?
Nein. Beim W3 gibt es aber ein Modul namens mod_fileiri [1] was einem bei
diesem Problem helfen kann.
Gruß
Carsten
Christoph Schneegans
>> Wenn ich mit einem Client die nicht vorhandene Ressource
>> GET /%C3%BC.txt HTTP/1.0
>> abrufe, erhalte ich
>> HTTP/1.1 404 Not Found
>> Content-Type: text/html; charset=iso-8859-1
>> <p>The requested URL /ü.txt was not found on this server.</p>
>>
>> zurück. Dies zeigt doch, daß Apache die URL als ISO-8859-1-codiert
>> annimmt.
>
> Das sollte mit
> http://httpd.apache.org/docs/2.2/mod/mod_headers.html#header
> zu korrigieren sein.
Ich will nicht an den Symptomen herumdoktern, und es ist auch nicht
mein Ziel, die Fehlerseite zu "verbessern", das war ja nur ein
Beispiel.
--
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML
Christoph Schneegans
> Da der Apache nichts umkodiert, kommt dann bei einer URI mit
> "%C3%BC", ausgegeben in einer Seite mit ISO-8859-1, eben "ü"
> heraus.
Ja, ich hätte dieses Ergebnis nicht verallgemeinern sollen.
>> Kann man Apache so einstellen, daß URLs mit %HH-Sequenzen als
>> UTF-8-codiert betrachtet werden?
>
> Nein.
Doch, aber schon klar; dafür geht ISO-8859-1 nicht. Das ist ja doch
ziemlich blöd, gerade unter Windows.
IIS7 macht es irgendwie anders. Der decodiert die URL erst mit UTF-8
und dann, wenn es keine Datei mit dem passenden Namen gibt, mit ANSI.
Einstellen kann man das aber auch nicht.
Harald Maedl
> ... Dies zeigt doch, daß Apache die URL als ISO-8859-1-codiert
> annimmt. Würde Apache sie als UTF-8-codiert betrachten, sollte die
> Antwort doch
Du müßtest Perl so konfigrieren, dass UTF-8 verarbeitet wird.
Vielleicht hilft dir folgendes Skript:
<http://perldoc.perl.org/utf8.html>
Richtig kompetent kann ich dir auch nicht weiterhelfen, da ich mich
selber gerade in Perl und Apache einarbeiten und damit herumschlagen
darf.
--
Grüße
Harald
Christoph Schneegans
> Du müßtest Perl so konfigrieren, dass UTF-8 verarbeitet wird.
Ich verwende Perl aber gar nicht.
Harald Maedl
> Harald Maedl schrieb:
>
>> Du müßtest Perl so konfigrieren, dass UTF-8 verarbeitet wird.
> Ich verwende Perl aber gar nicht.
Vielleicht helfen folgende Links:
<http://blog.antikoerperchen.de/beitrag/42/utf-8-und-die-entity.html>
<http://blog.oncode.info/2006/11/20/unicode-holle-php-apache-mysql-und-symfony-in-utf-8/>
Nun, die Suchmaschine wirst ja selber schon angeworfen haben. Ansonsten
würde ich mich ja gerne im Gegenzug für deine vielen guten Tipps in
einer anderen NG revanchieren, nur ist dieses Thema hier mir selbst
noch ziemlich fremd.
--
Grüße
Harald
Christoph Schneegans
> Vielleicht helfen folgende Links:
> <http://blog.antikoerperchen.de/beitrag/42/utf-8-und-die-entity.html>
> <http://blog.oncode.info/2006/11/20/unicode-holle-php-apache-mysql-und-symfony-in-utf-8/>
In beiden Artikeln geht es um UTF-8 im _Body_ von HTTP-Anfragen und
-Antworten. Mein Problem dreht sich um UTF-8 in URLs.
--
<http://schneegans.de/expression-web/zeichencodierung/> · Unicode in xWeb
Andreas Prilop
> Doch, aber schon klar; dafür geht ISO-8859-1 nicht. Das ist ja doch
> ziemlich blöd, gerade unter Windows.
Nur mal so am Rande - ich zitiere aus der apache2.conf
http://crizee.free.fr/apache/apache2.conf.html
# It is generally better to not mark a page as being a certain language
# than marking it with the wrong language!
# ...
AddDefaultCharset ISO-8859-1
# Specify a default charset for all pages sent out.
# This is always a good idea
Wer den Widerspruch zuerst findet, gewinnt 10 000 Lewonzen.
Christoph Schneegans
> Nur mal so am Rande - ich zitiere aus der apache2.conf
> http://crizee.free.fr/apache/apache2.conf.html
>
> # It is generally better to not mark a page as being a certain language
> # than marking it with the wrong language!
> # ...
> AddDefaultCharset ISO-8859-1
> # Specify a default charset for all pages sent out.
> # This is always a good idea
Die AddDefaultCharset-Direktive findet sich in aktuellen Releases?
Dieser Schwachsinn sollte sich doch eigentlich mit
<https://issues.apache.org/bugzilla/show_bug.cgi?id=23421#c0>
endgültig erledigt haben.
--
<http://schneegans.de/sv/> · Schema-Validator für XML
Dirk Ohme
> Kann man Apache so einstellen, daß URLs mit %HH-Sequenzen
> als UTF-8- codiert betrachtet werden?
Nach RFC-3986 sollten sie immer als UTF-8 kodiert angesehen werden.
Die Frage ist doch eher, wie man bei der Ausgabe der 404-Fehlerseite
bewirkt, dass diese selbst UTF-8 kodiert nach draussen gegeben wird
bzw. warum dort nicht von UTF-8 nach ISO-8859-1 gewandelt wird.
Gruß, Dirk
Christoph Schneegans
>> Kann man Apache so einstellen, daß URLs mit %HH-Sequenzen
>> als UTF-8- codiert betrachtet werden?
>
> Nach RFC-3986 sollten sie immer als UTF-8 kodiert angesehen
> werden.
Für HTTP-URLs gilt das aber nicht.
Dirk Ohme
Und wieso nicht, wenn sich HTTP 1.1 darauf bezieht? Content-Encoding
bezieht sich, wie der Name schon sagt, auf den Body, nicht auf den
Header.
Gruß, Dirk
Christoph Schneegans
>>> Nach RFC-3986 sollten (URLs) immer als UTF-8 kodiert angesehen
>>> werden.
>>
>> Für HTTP-URLs gilt das aber nicht.
>
> Und wieso nicht, wenn sich HTTP 1.1 darauf bezieht?
Wie meinen? RFC 2616 ist von 1999, RFC 3986 von 2005.
Dein überaus knappes Quoting habe ich übrigens korrigiert.
Peter J. Holzer
> Christoph Schneegans schrieb im Newsbeitrag
>> Für HTTP-URLs gilt das aber nicht.
>
> Und wieso nicht, wenn sich HTTP 1.1 darauf bezieht?
*Worauf* bezieht sich HTTP 1.1? RFC 3986 schreibt keineswegs vor, dass
in URIs UTF-8 zu verwenden ist, sondern stellt im Gegenteil sogar fest:
Local names, such as file system names, are stored with a local
character encoding. URI producing applications (e.g., origin
servers) will typically use the local encoding as the basis for
producing meaningful names.
Weiter unten wird zwar empfohlen:
When a new URI scheme defines a component that represents textual
data consisting of characters from the Universal Character Set [UCS],
the data should first be encoded as octets according to the UTF-8
character encoding [STD63]; then only those octets that do not
correspond to characters in the unreserved set should be percent-
encoded.
aber das gilt explizit für "a new URI scheme". Und HTTP, das
mittlerweile über 15 Jahre alt ist, kann kaum als "new" gelten.
hp
Dirk Ohme
> Weiter unten wird zwar empfohlen:
> When a new URI scheme defines a component that represents
> textual data consisting of characters from the Universal
> Character Set [UCS], the data should first be encoded as
> octets according to the UTF-8 character encoding [STD63];
> then only those octets that do not correspond to characters
> in the unreserved set should be percent-encoded.
> aber das gilt explizit für "a new URI scheme".
Lies' mal genau, was man *dann* (then) machen sollte ... um es kurz zu
machen:
Wenn's das neue Schema gibt, dann kodiere alles, was im reservierten
Bereich, ist mit Prozent und den Rest belasse UTF-8.
Ich seh' aber nirgends den Ausschluss von UTF-8 per se. Insofern kann
man auch jetzt schon UTF-8 rüberschicken, muss dann aber alles
nicht-druckbare/reservierte bzw. nicht-ASCII per Prozent kodieren.
Ansonsten halte ich mich an das hier:
A system that internally provides identifiers in the form of a
different character encoding, such as EBCDIC, will generally
perform
character translation of textual identifiers to UTF-8 [STD63] (or
some other superset of the US-ASCII character encoding) at an
internal interface, thereby providing more meaningful identifiers
than those resulting from simply percent-encoding the original
octets.
For example, consider an information service that provides data,
stored locally using an EBCDIC-based file system, to clients on the
Internet through an HTTP server. When an author creates a file
with
the name "Laguna Beach" on that file system, the "http" URI
corresponding to that resource is expected to contain the
meaningful
string "Laguna%20Beach". If, however, that server produces URIs by
using an overly simplistic raw octet mapping, then the result would
be a URI containing "%D3%81%87%A4%95%81@%C2%85%81%83%88". An
internal transcoding interface fixes this problem by transcoding
the
local name to a superset of US-ASCII prior to producing the URI.
Naturally, proper interpretation of an incoming URI on such an
interface requires that percent-encoded octets be decoded (e.g.,
"%20" to SP) before the reverse transcoding is applied to obtain
the
local name.
(Am Ende von S. 15 in RFC-3986)
Gruß, Dirk
Christoph Schneegans
> Insofern kann man auch jetzt schon UTF-8 rüberschicken, muss dann
> aber alles nicht-druckbare/reservierte bzw. nicht-ASCII per Prozent
> kodieren.
Das mußte man in URLs schon immer.
Peter J. Holzer
> Peter J. Holzer schrieb im Newsbeitrag
>> Weiter unten wird zwar empfohlen:
>> When a new URI scheme defines a component that represents
>> textual data consisting of characters from the Universal
>> Character Set [UCS], the data should first be encoded as
>> octets according to the UTF-8 character encoding [STD63];
>> then only those octets that do not correspond to characters
>> in the unreserved set should be percent-encoded.
>> aber das gilt explizit für "a new URI scheme".
>
> Lies' mal genau, was man *dann* (then) machen sollte ... um es kurz zu
> machen:
> Wenn's das neue Schema gibt, dann kodiere alles, was im reservierten
> Bereich, ist mit Prozent und den Rest belasse UTF-8.
Beachte aber, dass das "unreserved set" nur die Zeichen 0-9, A-Z, a-z,
"-" / "." / "_" / "~" umfasst. Alle anderen Octets sollten also
prozentkodiert werden, wie die Beispiele danach ja auch zeigen (À wird
zu %C3%80, ア wird zu %E3%82%A2)
> Ich seh' aber nirgends den Ausschluss von UTF-8 per se.
Hat auch keiner behauptet. Es wurde nur verneint, dass RFC 3986 diese
Form vorschreibt. Das tut er nicht, und es wäre sowohl für diesen RFC
als auch seine Vorgänger eine schlechte Idee gewesen, das zu tun: Es gab
und gibt eben Millionen von Webservern mit irgendwelchen
Legacy-Encodings - die werden sich nicht so schnell ändern. Wenn jemand
ein neues Webservice anbietet, ist es sicherlich eine gute Idee, das so
zu machen.
> Ansonsten halte ich mich an das hier:
>
> A system that internally provides identifiers in the form of a
> different character encoding, such as EBCDIC,
Du hast lokale Namen in EBCDIC? Mein Beileid.
hp
Dirk Ohme
>> A system that internally provides identifiers in the form of a
>> different character encoding, such as EBCDIC,
> Du hast lokale Namen in EBCDIC? Mein Beileid.
Nö, seit wann muss man etwas selbst haben, wenn man nur sagt, man hält
sich an diese Vorgehensweise? s/EBCDIC/ISO8859-15/g
Gruß, Dirk