Folgendes Problem:

Nach dem Umzug auf den neuen Server funktionieren die Umlaute plötzlich
nicht mehr.

Dazu wurden mit rsync alle Dateien auf den neuen Server kopiert.

Alt (funktioniert): [url down]
Neu (funktioniert nicht): [url down]
(man Beachte die Wörter "Untermenü" und "Änderung")

Sieht so aus als ob die Umlaute dort wo sie ohne ü stehen verhunzt
wurden denn für das ä und ü steht das gleiche Fragezeichen. Vermutlich
war der alte Server auf ISO-8859-1 eingestellt und der neue auf UTF-8,
kann das der Grund sein?

Daher die Frage:
Wie kann man das richtig vom einen Server auf den anderen kopieren bzw.
kann man das im Nachhinein noch ändern?

On Mon, 8 Feb 2010, Martin Brunner wrote:

> Alt (funktioniert): [..]
> Neu (funktioniert nicht): [..]

Gehn tun sie beide nicht. Beide Server schicken

Content-Type: text/html; charset=UTF-8

aber die Seite ist de-facto in ISO-8859-1 codiert.

Andreas Prilop schrieb:

>On Mon, 8 Feb 2010, Martin Brunner wrote:
>
>> Alt (funktioniert): [..]
>> Neu (funktioniert nicht): [..]
>
>Gehn tun sie beide nicht. Beide Server schicken
>
> Content-Type: text/html; charset=UTF-8
>
>aber die Seite ist de-facto in ISO-8859-1 codiert.

Wie?

Also <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"> steht in der Datei aber der
Server sagt trotzdem UTF-8?

Ja gut von mir aus kann ich alles in UTF-8 konvertieren, aber wie lässt
sich das machen?

Geht das im Nachhinein noch mit sowas wie
iconv -f ISO-8859-1 -t UTF-8 filename.txt
oder muss ich schauen dass beim kopieren vom einen Server auf den
anderen alles angepasst wird?

Also am alten Server liegen die Daten ja offenbar in ISO-8859-1 am neuen
in UTF-8 und beim kopieren wurde das verhunzt. Ist das so richtig?

On 2010-02-08 18:03, Martin Brunner <konigjh> wrote:
> Andreas Prilop schrieb:
>
> Wie?
>
> Also <meta http-equiv="content-type"
> content="text/html;charset=iso-8859-1"> steht in der Datei aber der
> Server sagt trotzdem UTF-8?

Der Server schaut (normalerweise) nicht ins HTML-File. Und der Client
glaubt dem Server.


> Ja gut von mir aus kann ich alles in UTF-8 konvertieren, aber wie lässt
> sich das machen?
>
> Geht das im Nachhinein noch mit sowas wie
> iconv -f ISO-8859-1 -t UTF-8 filename.txt

Ja.

> oder muss ich schauen dass beim kopieren vom einen Server auf den
> anderen alles angepasst wird?

Nein.


> Also am alten Server liegen die Daten ja offenbar in ISO-8859-1 am neuen
> in UTF-8 und beim kopieren wurde das verhunzt. Ist das so richtig?

Nein. Auf beiden Servern liegen die Daten in ISO-8859-1, beide Server
behaupten, es wäre UTF-8, somit funktioniert es bei beiden nicht.

Verdächtigerweise haben auch beide Server die gleiche IP-Adresse und die
Response-Header schauen auch vollkommen identisch aus. Bist Du sicher,
dass das zwei verschiedene Server sind?

hp

Martin Brunner schrieb:

> Also <meta http-equiv="content-type"
> content="text/html;charset=iso-8859-1"> steht in der Datei aber der
> Server sagt trotzdem UTF-8?

Das ist unabhängig voneinander.

Der Server interessiert sich in der Regel nicht für das, was im File
drinsteht. Der Server richtet sich ausschließlich nach seiner
Konfiguration, und dort ist irgendwo "charset=UTF-8" eingestellt (nein,
ich weiß nicht, wo und wie man das ändert, würde mich aber auch
interessieren). Dass die Seiten eigentlich anders codiert sind, ist ihm
dabei reichlich wurscht. Der Inhalt wird einfach 1:1 durchgereicht.

Der Browser indes schaut in die Datei, wertet dieses <meta>-Tag aber nur
dann aus, wenn der Server kein "charset" angibt. Das tut dieser aber.
Also richtet sich der Browser nach dieser Server-Angabe und ignoriert
die Angabe in der Datei.

> Ja gut von mir aus kann ich alles in UTF-8 konvertieren, aber wie lässt
> sich das machen?

Brauchst Du nicht. Du musst nur Deinen Server dazu bringen, kein
"charset" zu übermitteln. Dann richtet sich der Browser nach dem <meta>-Tag.

> Also am alten Server liegen die Daten ja offenbar in ISO-8859-1 am neuen
> in UTF-8 und beim kopieren wurde das verhunzt. Ist das so richtig?

Nein. Sie liegen auf beiden Servern (falls es überhaupt zwei sind) als
ISO-8859-1 vor. Nur wissen das die Server nicht. Brauchen sie
normalerweise auch nicht zu wissen.

Gruß. Claus

Martin Brunner wrote:
> Also <meta http-equiv="content-type"
> content="text/html;charset=iso-8859-1"> steht in der Datei aber der
> Server sagt trotzdem UTF-8?

Das kann gut sein.

cd /var/www/whatever
echo "AddDefaultCharset iso-8859-1" >> .htaccess

Peter J. Holzer schrieb:

>Nein. Auf beiden Servern liegen die Daten in ISO-8859-1, beide Server
>behaupten, es wäre UTF-8, somit funktioniert es bei beiden nicht.

Ja aber was ich dann nicht verstehe:

Wieso werden die Seiten vom alten Server überall richtig angezeigt?
Wieso stehst beim Ä und Ü das gleiche Zeichen, kann ich das mit dem
iconv-Befehl wirklich wieder auseinanderdividieren?

On 2010-02-09 09:00, Martin Brunner <konigjh> wrote:
> Peter J. Holzer schrieb:
>>Nein. Auf beiden Servern liegen die Daten in ISO-8859-1, beide Server
>>behaupten, es wäre UTF-8, somit funktioniert es bei beiden nicht.
>
> Ja aber was ich dann nicht verstehe:
>
> Wieso werden die Seiten vom alten Server überall richtig angezeigt?

SIE WERDEN EBEN NICHT RICHTIG ANGEZEIGT!

Zumindest nicht unter dem URL, den Du uns mitgeteilt hast.

Daher noch einmal die Frage:

Bist Du sicher, dass Du uns die richtigen URLs mitgeteilt hast?

> Wieso stehst beim Ä und Ü das gleiche Zeichen,

Das Zeichen, das Du da siehst, bedeutet "Kodierungsfehler". Das zeigt
der Browser an, wenn er das, was ihm der Server schickt, nicht
entziffern kann.

> kann ich das mit dem iconv-Befehl wirklich wieder
> auseinanderdividieren?

Dafür musst Du Dir das anschauen, was Du mit iconv bearbeiten willst,
also die Files auf der Platte, nicht die Anzeige im Browser.

hp

On Tue, 9 Feb 2010, Martin Brunner wrote:

> Wieso werden die Seiten vom alten Server überall richtig angezeigt?

Der Server kann sich äußern (im HTTP-Header; hat nichts mit dem Inhalt der
Datei zu tun) und in der Datei kann etwas stehen (z.B. <meta
http-equiv="content-type" content="text/html; charset=UTF-8">). Es sieht
danach aus, als sei zweiteres mal als Anweisung an der Server gedacht
gewesen, ersteres zu tun, aber so läuft es nicht. Stattdessen wird
hergenommen, was der Server sagt, und der Dateiinhalt nur herangezogen,
wenn der Server nichts von sich aus sagt. Vielleicht hat der bisherige
Server nichts gesagt und die <meta>-Tags haben für die korrekte
Interpretation gesorgt -- was wirklich geschehen ist, können wir von hier
aus nicht sagen.

> Wieso stehst beim Ä und Ü das gleiche Zeichen, kann ich das mit dem
> iconv-Befehl wirklich wieder auseinanderdividieren?

Ist es wirklich das gleiche Zeichen in der Datei, oder sieht es nur am
Bildschirm gleich aus?

iconv und recode verlangen, dass die Ausgangsdatei wenigstens in einem
Code konsistent codiert ist. Damit würde ich erstmal anfangen. Es kommt
aber auch vor, dass die Ausgangsdatei bei nachträglichen Änderungen in
sich inkonsistent geworden ist -- auch dann kann man oft noch etwas
retten.

Am 09.02.2010 10:38, schrieb Peter J. Holzer:

>> Wieso werden die Seiten vom alten Server überall richtig angezeigt?
>
> SIE WERDEN EBEN NICHT RICHTIG ANGEZEIGT!
>
> Zumindest nicht unter dem URL, den Du uns mitgeteilt hast.
>
> Daher noch einmal die Frage:
>
> Bist Du sicher, dass Du uns die richtigen URLs mitgeteilt hast?

Oha. Nun ich habe die richtigen URLs mitgeteilt aber mein Kollege hat da
was an den Domains verstellt.

Also in kurzer zeit sollten die beiden Links wieder auf unterschiedliche
Server zeigen und bei ersterem die Umlaute funktionieren.

Am 09.02.2010 05:03, schrieb Michael Holzt:
> Martin Brunner wrote:
>> Also <meta http-equiv="content-type"
>> content="text/html;charset=iso-8859-1"> steht in der Datei aber der
>> Server sagt trotzdem UTF-8?
>
> Das kann gut sein.
>
> cd /var/www/whatever
> echo "AddDefaultCharset iso-8859-1" >> .htaccess

Das klingt gut aber leider bekomme ich damit einen "Internal Server
Error". (Verzeichnis habe ich natürlich angepasst).

On 09.02.2010 14:42, Martin Brunner wrote:
> Am 09.02.2010 05:03, schrieb Michael Holzt:

>> cd /var/www/whatever
>> echo "AddDefaultCharset iso-8859-1" >> .htaccess
>
> Das klingt gut aber leider bekomme ich damit einen "Internal Server
> Error". (Verzeichnis habe ich natürlich angepasst).

Du hast also jetzt eine .htaccess-Datei mit dem Eitnrag
AddDefaultCharset iso-8859-1
Dann musst du mit dem Provider vereinbaren, dass er entweder die globale
charset-Zuweisung unterlässt (dann reicht die Angabe auf Dateiebene)
oder zulässt, dass du den Eintrag wie oben mittels .htaccess überschreibst.

ausführliche Hintergrundinfos gibt es übrigens hier: W3C I18N (X)HTML &
CSS Techniques
<http://www.w3.org/International/techniques/authoring-html#charset>
einige der Unterseiten liegen auch bereits auf deutsch vor.

Gruß
Susanne

Am 09.02.2010 14:22, schrieb Martin Brunner:
> Also in kurzer zeit sollten die beiden Links wieder auf unterschiedliche
> Server zeigen und bei ersterem die Umlaute funktionieren.

So bitte jetzt gehts wieder, unter
[url down] sollten nun die Umlaute richtig sein, unter
[url down] hingegen falsch.

hallo

Martin Brunner schrieb:

> [..] sollten nun die Umlaute richtig sein, unter
-----------------------------------------------------
Date: Tue, 09 Feb 2010 14:11:32 GMT
Server: Apache/2.2.3 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.2.3 OpenSSL/0.9.8c
X-Powered-By: PHP/4.4.4-8+etch6
Set-Cookie: PHPSESSID=ec9827daf040e607c0d9f3150517b056; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Content-Type: text/html
Content-Length: 6569
Accept-Ranges: none
Proxy-Connection: Keep-Alive

200 OK
-----------------------------------------------------


> [..] hingegen falsch.
-----------------------------------------------------
Date: Tue, 09 Feb 2010 14:11:16 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.9-0.dotdeb.1 with
Suhosin-Patch mod_ruby/1.2.6 Ruby/1.8.5(2006-08-25) mod_ssl/2.2.3
OpenSSL/0.9.8c
X-Powered-By: PHP/5.2.9-0.dotdeb.1
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=98
Content-Type: text/html; charset=UTF-8
Content-Length: 6569
Accept-Ranges: none
Proxy-Connection: Keep-Alive

200 OK
-----------------------------------------------------

Die Umlaute sind weder hier richtig noch dort falsch sondern einmal
schickt der Server Anweisungen mit und das andere mal nicht.
Wenn variante 2 "falsch" ist, dann sind die files eben nicht in UTF-8.

Variante 1 ist "richtig", weil der Browser seine Voreinstellung von
ISO-8859-1 bzw. -15 benutzt.

Gruß
Irmgard

Martin Brunner <konigjh> writes:

> Am 09.02.2010 14:22, schrieb Martin Brunner:
>> Also in kurzer zeit sollten die beiden Links wieder auf unterschiedliche
>> Server zeigen und bei ersterem die Umlaute funktionieren.
>
> So bitte jetzt gehts wieder, unter
> [..] sollten nun die Umlaute richtig sein, unter
> [..] hingegen falsch.

,----
| $ HEAD [url down]
| 200 OK
| Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
| Connection: close
| Date: Tue, 09 Feb 2010 15:48:09 GMT
| Pragma: no-cache
| Server: Apache/2.2.3 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.2.3 OpenSSL/0.9.8c
| Content-Type: text/html
| Expires: Thu, 19 Nov 1981 08:52:00 GMT
| Client-Date: Tue, 09 Feb 2010 15:48:47 GMT
| Client-Peer: 91.143.100.230:80
| Client-Response-Num: 1
| Set-Cookie: PHPSESSID=cdcaeb18d6e9a69e0397a100746d59a0; path=/
| X-Powered-By: PHP/4.4.4-8+etch6
`----

Der Server gibt keine Zeichenkodierung an, der Client benutzt also die
in der Datei angegebene Zeichenkodierung.


,----
| $ HEAD [url down]
| 200 OK
| Connection: close
| Date: Tue, 09 Feb 2010 15:49:39 GMT
| Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.9-0.dotdeb.1 with Suhosin-Patch mod_ruby/1.2.6 Ruby/1.8.5(2006-08-25) mod_ssl/2.2.3 OpenSSL/0.9.8c
| Vary: Accept-Encoding
| Content-Type: text/html; charset=UTF-8
| Client-Date: Tue, 09 Feb 2010 15:50:17 GMT
| Client-Peer: 91.143.100.238:80
| Client-Response-Num: 1
| X-Powered-By: PHP/5.2.9-0.dotdeb.1
`----

Der Server gibt UTF-8 als Zeichenkodierung an, der Client ignoriert also
in der Datei angegebene Zeichenkodierung.


Florian