charset=utf-8 auf unterschiedlichen Servern

[auto01]

Hallo Leute,

ich habe folgendes Phänomen.

Ich habe 2 Webseiten mit komplett identischem Quelltext in denen die Zeichenkodierung auf UTF-8 mittels Meta-Tag gesetzt ist:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Die eine liegt im Internet und die 2. bei mir auf einem Server im lokalen Netzwerk.
Die Seite auf dem Server im Internet wird die Schriftcodierung korrekt angezeigt.
Bei der Seite auf dem Server im Lokalen Netzwerk wird auf allen Browsern und auch verschiedenen Computern die Codierung nicht richtig erkannt und es wird der UTF-8 Code angezeigt.
Wie kann das sein?
Der einzige Unterschied ist der Domainname beim Aufruf im Browser.
1. Server im Internet
http://www.meinedomain.de/abi.html
2. Server im lokalen Netzwerk
http://linux.local/abi.html

[suit]

1. Server im Internet
   http://www.meinedomain.de/abi.html

Nachdem du offenbar für die Schlund+Partner AG arbeitest, sollte das Problem doch für dich einfach zu lösen sein.

Wenn nicht, RFC 2606, Abschnitt 3.

http-equiv ist übrigens nur das HTTP-Äquivalent und gilt nur dann, wenn kein HTTP-Header mit entsprechenden Informationen vorhanden ist - von der Seite her solltest du deine Webserver entsprechend konfigurieren.

[Sven Rautenberg]

Moin!

1. Server im Internet
   http://www.meinedomain.de/abi.html

Nachdem du offenbar für die Schlund+Partner AG arbeitest, sollte das Problem doch für dich einfach zu lösen sein.

Solche Sprüche waren vielleicht mal witzig, sind es aber mittlerweile nicht mehr. Sie sollten abgeschafft werden, weil sie niemandem weiterhelfen, außer dein Ego zu polieren.

- Sven Rautenberg

[suit]

Solche Sprüche waren vielleicht mal witzig, sind es aber mittlerweile nicht mehr. Sie sollten abgeschafft werden, weil sie niemandem weiterhelfen, außer dein Ego zu polieren.

ich denke sehrwohl, dass sie zusätzlich angebracht sind - über die formulierung kann man reden - aber die aussage ist imho äusserst wichtig - in diesem fall ist es nich so tragisch - aber ich bin mir sicher, dass die stiftung warentest mehr spam bekommt, als sie vertragen kann, weil irgendwelche helden zum testen anstatt "[e-mail]" einfach eine entsprechend andere adresse verwenden

zudem habe ich ja auch den hinweis gegeben, dass http-equiv in abhängigkeit des http-headers keine gültigkeit besitzt - das sollte als denkanstoss in die richtige richtig reichen - wer einen webserver lokal installieren kann, sollte sich früher oder später mit seiner konfiguration auseinandersetzen - wenn die hilfe nicht genug war, gibts gerne mehr - aber ohne zu wissen, welche serversoftware verwendet wird, ist es etwas schwierig

natürlich lässt sich das ganze auch über eine entsprechende scriptsprache regeln, aber auch diese ist nicht bekannt

[auto01]

Solche Sprüche waren vielleicht mal witzig, sind es aber mittlerweile nicht mehr. Sie sollten abgeschafft werden, weil sie niemandem weiterhelfen, außer dein Ego zu polieren.

ich denke sehrwohl, dass sie zusätzlich angebracht sind - über die formulierung kann man reden - aber die aussage ist imho äusserst wichtig - in diesem fall ist es nich so tragisch - aber ich bin mir sicher, dass die stiftung warentest mehr spam bekommt, als sie vertragen kann, weil irgendwelche helden zum testen anstatt "[e-mail]" einfach eine entsprechend andere adresse verwenden

zudem habe ich ja auch den hinweis gegeben, dass http-equiv in abhängigkeit des http-headers keine gültigkeit besitzt - das sollte als denkanstoss in die richtige richtig reichen - wer einen webserver lokal installieren kann, sollte sich früher oder später mit seiner konfiguration auseinandersetzen - wenn die hilfe nicht genug war, gibts gerne mehr - aber ohne zu wissen, welche serversoftware verwendet wird, ist es etwas schwierig

natürlich lässt sich das ganze auch über eine entsprechende scriptsprache regeln, aber auch diese ist nicht bekannt

Vielen Dank fü die Antworten.

Es gibt in der Apache-Datei
mod_mime-defaults.conf

einen Eintrag
AddDefaultCharset ISO-8859-1

den habe ich auskommentiert obwohl im Kommentar darüber erklärt wird, dass es eine gute Idee ist so etwas zu definieren.
#AddDefaultCharset ISO-8859-1

Seit dem wir auch die richtige Codierung verwendet.

Die andere Geschichte mit den Domainnamen werde ich mir merken.

[EKKi]

Mahlzeit auto01,

einen Eintrag
AddDefaultCharset ISO-8859-1

den habe ich auskommentiert

Warum das? Warum legst Du nicht stattdessen einen anderen (den "richtigen") fest?

obwohl im Kommentar darüber erklärt wird, dass es eine gute Idee ist so etwas zu definieren.

Ist es auch. Wie wäre es stattdessen mit

AddDefaultCharset UTF-8

MfG,
EKKi

[auto01]

Mahlzeit auto01,

einen Eintrag
AddDefaultCharset ISO-8859-1

den habe ich auskommentiert

Warum das? Warum legst Du nicht stattdessen einen anderen (den "richtigen") fest?

obwohl im Kommentar darüber erklärt wird, dass es eine gute Idee ist so etwas zu definieren.

Ist es auch. Wie wäre es stattdessen mit

AddDefaultCharset UTF-8

MfG,
EKKi

Hallo EKKi
Dann gibt es wieder Probleme mit Seiten, die nicht UTF-8 Codiert sind und auch auf dem Server liegen.
AddDefaultCharset UTF-8.
Ich habe es nun noch nicht probiert solch einen Eintrag in der Virtuellen Hosts zu machen.
Aber selbst in den einzelnen Virtuellen Hosts gibt es Seiten mit verschiedenen Codierungen. Meißtens ist es ISO-8859-1. Es ist ja auch nur ein Testserver.

[EKKi]

Mahlzeit auto01,

Hallo EKKi

es wäre schön, wenn Du Dich beim Zitieren auf das beschränken würdest, auf das Du Dich beziehst - TOFU ist ungern gesehen, da Beiträge dadurch teilweise unleserlich werden.

Dann gibt es wieder Probleme mit Seiten, die nicht UTF-8 Codiert sind und auch auf dem Server liegen.

Hm.

AddDefaultCharset UTF-8.
Ich habe es nun noch nicht probiert solch einen Eintrag in der Virtuellen Hosts zu machen.

Das sollte aber eigentlich problemlos funktionieren.

Aber selbst in den einzelnen Virtuellen Hosts gibt es Seiten mit verschiedenen Codierungen. Meißtens ist es ISO-8859-1.

Dann solltest Du vielleicht - zumindest pro VirtualHost - mal ein generelles Aufräumen anberaumen: UTF-8 hat eigentlich keinerlei Nachteil gegenüber ISO-8859-1 ... es spricht also eigentlich nichts dagegen, einfach alle Dateien/Skripte entsprechend umzukodieren.

Es ist ja auch nur ein Testserver.

Na also, dann bietet es sich ja an, testweise so eine "Aufräumaktion" durchzuführen ... :-)

MfG,
EKKi

[suit]

UTF-8 hat eigentlich keinerlei Nachteil gegenüber ISO-8859-1 ... es spricht also eigentlich nichts dagegen, einfach alle Dateien/Skripte entsprechend umzukodieren.

doch - sämtliche von 128 bis 255 werden dann fehlerhaft dargestellt, diese müssen natürlich entsprechend ersetzt werden

lediglich die zeichen von 0 bis 127 sind in den ansi/ascii-zeichensätzen ident zur codierung von utf-8

[EKKi]

Mahlzeit suit,

es spricht also eigentlich nichts dagegen, einfach alle Dateien/Skripte entsprechend umzukodieren.

doch - sämtliche von 128 bis 255 werden dann fehlerhaft dargestellt, diese müssen natürlich entsprechend ersetzt werden

Sagte ich doch: "entsprechend umkodieren"

lediglich die zeichen von 0 bis 127 sind in den ansi/ascii-zeichensätzen ident zur codierung von utf-8

Und? Das ist kein Vorteil von ISO-8859-1 gegenüber UTF-8.

MfG,
EKKi

[suit]

Sagte ich doch: "entsprechend umkodieren"

ich hab das als "speichere die dateien einfach anders" interpretiert ;)

lediglich die zeichen von 0 bis 127 sind in den ansi/ascii-zeichensätzen ident zur codierung von utf-8

Und? Das ist kein Vorteil von ISO-8859-1 gegenüber UTF-8.

das ist weder ein vor, noch ein nachteil - einfach ein schlauer schachzug bei der entwicklung von utf-8 ;)

[auto01]

1. Server im Internet
   http://www.meinedomain.de/abi.html

Nachdem du offenbar für die Schlund+Partner AG arbeitest, sollte das Problem doch für dich einfach zu lösen sein.

Wenn nicht, RFC 2606, Abschnitt 3.

http-equiv ist übrigens nur das HTTP-Äquivalent und gilt nur dann, wenn kein HTTP-Header mit entsprechenden Informationen vorhanden ist - von der Seite her solltest du deine Webserver entsprechend konfigurieren.

Also 1. für Schlund+Partner AG arbeite ich nicht.
Aber aus Deiner Antwort entnehme ich dass es an der Konfiguration des Webservers liegt. Irgendwo muss ja der HTTP-Header so erstellt werden. Das kann ja eigentlich nur am Apachen liegen.

[EKKi]

Mahlzeit auto01,

Also 1. für Schlund+Partner AG arbeite ich nicht.

Warum miss^H^H^H^Hbenutzt Du dann deren Domain? suit hat Dir einen lesenswerten Link genannt, in dem beschrieben ist, warum man zum Testen und für Beispiele nur bestimmte Domainnamen benutzen sollte und welche das sind.

Aber aus Deiner Antwort entnehme ich dass es an der Konfiguration des Webservers liegt. Irgendwo muss ja der HTTP-Header so erstellt werden. Das kann ja eigentlich nur am Apachen liegen.

Korrekt. Interessant könnten für Dich in diesem Zusammenhang die Direktive CharsetDefault und der Artikel über Content Negotiation sein.

MfG,
EKKi

[auto01]

Erst einmal vielen Dank an alle, die mir geantwortet haben!

Grundsätlich ist es ja so, dass man in Zukunft alles in UTF-8 machen sollte.
Da es sich bei mir nur um einen Testserver handelt, finde ich es am Besten, wenn er genau so reagiert, wie der Server im Internet. Ich vermute mal dort ist auch "AddDefaultCharset" nicht gesetzt.
Deshalb ist es für mich die beste Lösung. Alle Seiten umzukodieren ist wegen des Aufwandes bei mir nicht machbar. Das kann ich nur Schritt für Schritt machen.

mfg auto01

[suit]

Grundsätlich ist es ja so, dass man in Zukunft alles in UTF-8 machen sollte.

solange, bis uft-8 nicht mehr reicht, aber dafür gibts ja schon uft-16 und -32  ;)

irgendwann werden sicher mal die hieroglyphen digitalisiert und zur verfügung stehen und die haben in utf-8 einfach nicht mehr platz :D

aber prinzipiell hast du recht, utf-8 ist wesentlich schlauer als latin-1 bis irgendwas oder big5 zu verwenden

Deshalb ist es für mich die beste Lösung. Alle Seiten umzukodieren ist wegen des Aufwandes bei mir nicht machbar. Das kann ich nur Schritt für Schritt machen

musst du auch nicht alles gleichzeitig - wenn du eine serverseitige scriptsprache verwendest, kannst du den http-header auch pro dokument alternativ gestalten

[Jens Holzkämper]

Tach,

Grundsätlich ist es ja so, dass man in Zukunft alles in UTF-8 machen sollte.
solange, bis uft-8 nicht mehr reicht, aber dafür gibts ja schon uft-16 und -32  ;)

UTF-8, UTF-16 und UTF-32 decken alle exakt die selben Zeichen ab (nämlich alle in Unicode enthaltenen), die Kodierung ist nur unterschiedlich.

irgendwann werden sicher mal die hieroglyphen digitalisiert und zur verfügung stehen und die haben in utf-8 einfach nicht mehr platz :D

Von den 1114112 in Unicode möglichen Zeichen sind bisher 100713 belegt, darunter sind auch antike Zeichen, wie die des Minoischen, Phönizischen oder Linear B; Hieroglyphen sind geplant, allerdings noch nicht drin, da die Zeichenanordnung noch einiges Kopfzerbrechen bereitet.

mfg
Woodfighter

[suit]

solange, bis uft-8 nicht mehr reicht, aber dafür gibts ja schon uft-16 und -32  ;)

UTF-8, UTF-16 und UTF-32 decken alle exakt die selben Zeichen ab (nämlich alle in Unicode enthaltenen), die Kodierung ist nur unterschiedlich.

ja, nur je nach codierung werden die dateien unterschiedlich gross - um etwas (sprich ein zeichen) mit uft-8 zu codieren benötigt man 8 bis 32 bit - das ist variabel

wenn man nun zeichen im bereich der bmp von 0800 bis FFFF codieren möchte, braucht mit mit utf-8 jeweils 3 byte, mit utf-16 aber nur 2

da komplexe sprachen, die man selten benötigt, eher in den "höheren zahlenbereichen" angesiedelt sind, ist es also anzunehmen dass dort auch so geschichten wie eben hieroglyphen landen werden

ich hab mich etwas unglücklich ausgedrückt, natürlich reicht der unicode bereich mit 2^32 bit bei weitem aus um potentiell alle kommenden zeichen aufnehmen zu können (auch irgendwelche aliensprachen :p), aber es ist nicht unbedingt sinnvoll, diese auch mit utf-8 zu codieren, da man bei sehr langen texten extrem viel overhead produzieren kann - das muss nicht sein

umgekehrt benötigt natürlich uft-32 mehr platz

[auto01]

musst du auch nicht alles gleichzeitig - wenn du eine serverseitige scriptsprache verwendest, kannst du den http-header auch pro dokument alternativ gestalten

Das ist allerdings eine Idee. Ich kann ja auch mittels PHP den Header ändern. Irgendwas in der Art.

  
HEADER("Content-Type: text/html; charset=UTF-8")  

Wobei das wieder an anderer Stelle zu Problemen kommen kann.

mfg auto01

[dedlfix]

echo $begrüßung;

Ich kann ja auch mittels PHP den Header ändern. Irgendwas in der Art.
HEADER("Content-Type: text/html; charset=UTF-8")
Wobei das wieder an anderer Stelle zu Problemen kommen kann.

An welche Stelle(n) dachtest du dabei? Mit header() setzt du für die angeforderte Ressource einen Header. Nebenwirkungen mit anderen Requests sind dabei nicht zu erwarten.

echo "$verabschiedung $name";

[suit]

An welche Stelle(n) dachtest du dabei?

mir fällt spontan ein: wenns gemeinsame includes für die uft-8-codierten seiten und die ansi-codierten seiten gibt - das include müsste dann auch entsprechend angepasst werden, damit jeweils die zeichencodierung stimmt

[dedlfix]

echo $begrüßung;

An welche Stelle(n) dachtest du dabei?
mir fällt spontan ein: wenns gemeinsame includes für die uft-8-codierten seiten und die ansi-codierten seiten gibt - das include müsste dann auch entsprechend angepasst werden, damit jeweils die zeichencodierung stimmt

Das ist kein Problem von header() oder der Charset-Angabe im Allgemeinen. Pro Dokument geht nun mal nur eine Kodierung. Wenn Teil-Dokumente in unterschiedlichen Kodierungen vorliegen ist das eher als Konzeptfehler zu sehen. Das Anpassungsproblem hat man unabhängig von der Art der Charset-Angabe.

echo "$verabschiedung $name";

[suit]

Das ist kein Problem von header() oder der Charset-Angabe im Allgemeinen. Pro Dokument geht nun mal nur eine Kodierung. Wenn Teil-Dokumente in unterschiedlichen Kodierungen vorliegen ist das eher als Konzeptfehler zu sehen. Das Anpassungsproblem hat man unabhängig von der Art der Charset-Angabe.

das ist ist mir klar, nur wenn die seite jetzt komplett in ansi/latin-1 gehalten ist und sich aus völlig korrekt codierten komponenten zusammensetzt und man nun stückerweise umstellen möchte, stößt man an dieses problem

dann ist es nicht mehr unabhängig von der charsetangabe - es muss vorher ermittelt werden, welches charset gesetzt wird/wurde und der inhalt der includes entsprechend neu codiert werden (stichwort utf8_encode()

das würde ich dann nicht als konzeptionellen fehler bezeichen sondern als hindernis bei der umstellung der seite, die vorher bedacht werden muss

[Gunnar Bittersmann]

@@suit:

mir fällt spontan ein: wenns gemeinsame includes für die uft-8-codierten seiten und die ansi-codierten seiten gibt - das include müsste dann auch entsprechend angepasst werden, damit jeweils die zeichencodierung stimmt

Bei Includes kann es sinnvoll sein, ausschließlich ASCII-Zeichen im Quelltext zu verwenden und die anderen zu escapen.

Live long and prosper,
Gunnar