Hallo zusammen, ich habe hier den interessanten Fall, daß ein non-breaking space in einer HTML-Doku vom Apache 2.2.3 offensichtlich als 2-Byte-Zeichen an den web browser zurückgeliefert wird. Im Firefox erscheint dann unter Windows ein ?, unter Linux F0 FD in einem Rahmen drin (die genaue Hex-Kombination müßte ich noch mal nachschauen).
Die HTML-Doku wurde aus DocBook XML sources mit den XSL stylesheets erzeugt.
Das Problem tritt unabhändig von der Version der XSL stylesheets auf (nicht
nur mit der aktuellen V 1.71.1 sondern auch mit älteren Versionen). In den
erzeugten HTML pages steht als encoding ISO8859-1 drinnen. Andere Zeichen
wie z. B. Umlaute werden richtig dargestellt. Gerade in HTML-Doku, die
mittels der XSL stylesheets erzeugt wurde, wird an verschiedenen Stellen
massiv Gebrauch von non-breaking spaces gemacht (u. a. in den
Naviagions-Links am Anfang und am Ende der web pages).
Legt man die generierte HTML-Doku lokal auf dem Rechner ab und surft
mit einer "file://"-URL drauf, wird der non-breaking space KORREKT
dargestellt. Folglich bleibt eigentlich nur noch der Apache übrig,
der die HTML-Doku verhunzt.
Der der Apache ja als user www-data läuft, habe ich diesen account mal
unlocked (ein passwd verpaßt), und dann als user www-data die LANG und
LC_ Variablen kontrolliert. LANG steht auf [EMAIL PROTECTED] und LC_MESSAGES
auf C, die übrigen LC_ Variablen sind nicht gesetzt. Die [EMAIL PROTECTED]
locale ist auf dem System auch generiert worden und somit vorhanden.
Habe auch nach "debian etch apache non-breaking space 2 bytes" gegoogled,
aber leider nix zu dem Problem gefunden.
Naheliegende Fragen: Hat jmd. von Euch schon mal so ein (oder ein Ähnliches)
Problem gehabt? Falls ja, gibt es für den Apache eine Konfigurations-Option,
mit der man die o.g. Unschönheit beheben könnte?
Schon mal vielen Dank für die Info im Voraus!
Viele Grüße,
Holger
--
GPG key: 0x965D2902
GPG key fingerprint: 3FE8 7472 2637 2993 6BD7 015E 6E25 6D5A 965D 2902
signature.asc
Description: Digital signature
