Bei der Gruppe, für die Sie eine Mitteilung verfassen, handelt es sich um eine Usenet-Gruppe. Wenn Sie in dieser Gruppe Nachrichten posten, ist Ihre E-Mail-Adresse für jeden im Internet sichtbar
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?
>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?
>>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?
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?
> 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.
>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 <koni...@tin.at> 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.
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.
> 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).
> 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.
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.
Martin Brunner <koni...@tin.at> 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.
Claus Reibenstein <4spamerso...@kabelmail.de> writes: > 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).
>> http://mar.tin.at/404c/ sollten nun die Umlaute richtig sein, unter > ----------------------------------------------------- > Content-Type: text/html
Keine Zeichencodierung vom Server vorgegeben --> <meta> wird ausgewertet.
Zeichencodierung vom Server vorgegeben --> <meta> wird _nicht_ ausgewertet.
Also genau das, was wir bereits vermutet haben.
> Die Umlaute sind weder hier richtig noch dort falsch sondern einmal > schickt der Server Anweisungen mit und das andere mal nicht.
Du redest wirr.
Variante 1 _ist_ richtig, weil der Server keine Zeichencodierung vorgibt. Also wertet der Browser das <meta>-Tag aus, in welchem die korrekte Zeichencodierung drinsteht.
Variante 2 _ist_ falsch, weil der Server eine Zeichencodierung vorgibt, die nicht mit der Codierung der Dateien übereinstimmt.
> Wenn variante 2 "falsch" ist, dann sind die files eben nicht in UTF-8.
Das hatten wir bereits festgestellt.
> Variante 1 ist "richtig", weil der Browser seine Voreinstellung von > ISO-8859-1 bzw. -15 benutzt.
Sie ist richtig (ohne Anführungszeichen), weil der Browser sich nach der <meta>-Angabe richtet.
>> 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).
Danke allen für die Infos jedenfalls, jetzt ist mir das Problem klar.
Am 09.02.2010 19:15, schrieb Claus Reibenstein:
> Variante 2 _ist_ falsch, weil der Server eine Zeichencodierung vorgibt, > die nicht mit der Codierung der Dateien übereinstimmt.
So seh ich das auch. Hat das überhaupt einen Sinn das der Server einfach eine Codierung vorgibt und dabei die Codierung in der <meta>-Angabe "overruled"?
On Wed, 10 Feb 2010, Martin Brunner wrote: > So seh ich das auch. Hat das überhaupt einen Sinn das der Server einfach > eine Codierung vorgibt und dabei die Codierung in der <meta>-Angabe > "overruled"?
Meiner Meinung nach nicht, weil der Seiteninhalt vom Seitenautor gesetzt wird, und der weiß die Codierung besser als der Serverbetreiber. Es ist vor allem dann lästig, wenn ein Server viele Autoren bedient, die kein gemeinsamens CMS benutzen.
Aber es geht nicht darum, was sinnvoll ist, sondern wie es laut Normen sein soll. Und das ist nun mal so wie in diesem Thread diskutiert, ob man das schön findet oder nicht.
>>> http://mar.tin.at/404c/ sollten nun die Umlaute richtig sein, unter >> ----------------------------------------------------- >> Content-Type: text/html
> Keine Zeichencodierung vom Server vorgegeben --> <meta> wird ausgewertet. >> Die Umlaute sind weder hier richtig noch dort falsch sondern einmal >> schickt der Server Anweisungen mit und das andere mal nicht.
> Du redest wirr.
> Variante 1 _ist_ richtig, weil der Server keine Zeichencodierung > vorgibt. Also wertet der Browser das <meta>-Tag aus, in welchem die > korrekte Zeichencodierung drinsteht.
Ich habe mich wohl nur ungenau ausgedrückt. Es ist weder richtig noch falsch, ein "ä" mit einem byte (ISO-8859-1) oder mit 2 byte (UTF-8) zu codieren. Man muß nur dafür sorgen, daß der webserver dann auch die korrekte Codierung übergibt.
Ist es so, daß jeder Browser immer das auswertet, was in <meta http-equiv="content-type" ...> steht, wenn das Dokument von einem webserver geliefert wird? Oder setzen da nicht manche Browser auf das, was in deren Standardvorgeben eingestellt ist?
Schließlich mag das manchmal auch nur ein Wunschdenken sein, was da in <meta ..> steht.
> Hat das überhaupt einen Sinn das der Server einfach eine Codierung > vorgibt und dabei die Codierung in der <meta>-Angabe "overruled"?
Du hast ganz richtig erkannt, daß diese Regel blödsinnig ist, denn der Server-Administrator kann üblicherweise gar nicht wissen, wie eine HTML-Datei codiert ist, der Autor derselben hingegen schon. Nichtsdestotrotz ist die Regel gültig.
Server-Administratoren, die für alle Text-Ressourcen den charset- Parameter (wie etwa in "Content-Type: text/html; charset=utf-8") erzeugen lassen, handeln also rücksichtslos. Martin Dürst hat das in <https://issues.apache.org/bugzilla/show_bug.cgi?id=23421#c0> sehr gut auf den Punkt gebracht: "Charset information is important, but no charset information is much preferable to wrong charset information."
On Wed, 10 Feb 2010 12:40:24 +0100, Christoph Schneegans wrote: > Server-Administratoren, die f r alle Text-Ressourcen den charset- > Parameter (wie etwa in "Content-Type: text/html; charset=utf-8") > erzeugen lassen, handeln also r cksichtslos.
ACK
Aber das grundlegende Problem wird davon nicht ber hrt. Als Webmaster muss man, sofern m glich, auf jeden fall daf r Sorge tragen, das man das korrekte Charset in den HTTP-Headern mitsendet.
Man kann halt, wenn man nicht gerad den Server konfigurieren kann, nicht wissen ob der Webhoster z.B. nach einem Umzug immer noch die selben Einstellungen f hrt wie bisher.
> Claus Reibenstein schrieb: >>>> http://mar.tin.at/404c/ sollten nun die Umlaute richtig sein, unter >>> ----------------------------------------------------- >>> Content-Type: text/html
>> Keine Zeichencodierung vom Server vorgegeben --> <meta> wird ausgewertet.
>>> Die Umlaute sind weder hier richtig noch dort falsch sondern einmal >>> schickt der Server Anweisungen mit und das andere mal nicht.
>> Du redest wirr.
>> Variante 1 _ist_ richtig, weil der Server keine Zeichencodierung >> vorgibt. Also wertet der Browser das <meta>-Tag aus, in welchem die >> korrekte Zeichencodierung drinsteht.
> Ich habe mich wohl nur ungenau ausgedrückt. > Es ist weder richtig noch falsch, ein "ä" mit einem byte (ISO-8859-1) > oder mit 2 byte (UTF-8) zu codieren.
Warum soll das nicht richtig sein? Natürlich ist beides richtig, wenn:
> Man muß nur dafür sorgen, daß der webserver dann auch die korrekte > Codierung übergibt.
Wenn die Deklaration zum Inhalt passt, ist es richtig, sonst falsch.
> Ist es so, daß jeder Browser immer das auswertet, was in <meta > http-equiv="content-type" ...> steht, wenn das Dokument von einem > webserver geliefert wird?
Eine Frage, in der "jeder Browser immer" vorkommt, kann man getrost mit Nein beantworten. Irgendwelche User wird es sicher geben, die ihren Browser auf "ignoriere alles, was vom Server kommt und nimm an, die Dokumente seien klingonisch" eingestellt hat. Die sind aber selber schuld.
Vorgeschrieben ist diese Reihenfolge:
1. An HTTP "charset" parameter in a "Content-Type" field. 2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset". 3. The charset attribute set on an element that designates an external resource.
und die weitverbreiteten Browser halten sich per default auch daran.
>> Variante 1 _ist_ richtig, weil der Server keine Zeichencodierung >> vorgibt. Also wertet der Browser das <meta>-Tag aus, in welchem die >> korrekte Zeichencodierung drinsteht.
> Ich habe mich wohl nur ungenau ausgedrückt. > Es ist weder richtig noch falsch, ein "ä" mit einem byte (ISO-8859-1) > oder mit 2 byte (UTF-8) zu codieren. > Man muß nur dafür sorgen, daß der webserver dann auch die korrekte > Codierung übergibt.
Oder keine, wenn im HTML-Code eine drinsteht.
> Ist es so, daß jeder Browser immer das auswertet, was in <meta > http-equiv="content-type" ...> steht, wenn das Dokument von einem > webserver geliefert wird?
Ich kenne keinen, der es nicht auswertet. Kennst Du einen?
> Oder setzen da nicht manche Browser auf das, > was in deren Standardvorgeben eingestellt ist?
Manche Browser kann man so einstellen. Sinnvoll ist das allerdings nur, um fehlerhafte Seiten richtig angezeigt zu bekommen. Wer seinen Browser jedoch dauerhaft auf eine Zeichencodierung festlegt, ist selber schuld.
> Schließlich mag das manchmal auch nur ein Wunschdenken sein, was da in > <meta ..> steht.
Der Autor weiß wohl am besten (oder sollte wissen), welche Codierung er verwendet hat. Also wird er auch genau diese im <meta>-Tag angeben. Wenn jedoch ein Server meint, seinerseits eine Codierung vorzugeben, die dann oft die falsche ist, ist das kontraproduktiv.
> Als Webmaster muss man, sofern möglich, auf jeden fall dafür > Sorge tragen, das man das korrekte Charset in den HTTP-Headern > mitsendet.
Als Administrator kann man das nicht. Und als Autor muß man es nicht, denn die Codierungsdeklaration im "meta"-Element reicht aus.
> Man kann halt, wenn man nicht gerad den Server konfigurieren kann, > nicht wissen ob der Webhoster z.B. nach einem Umzug immer noch die > selben Einstellungen fährt wie bisher.
So einem Provider muß man dann eben kräftig auf die Finger hauen. Nach einem Umzug könnte er ja auch "Content-Encoding: gzip" setzen. Soll man sich IYO dagegen auch schützen?
|
