Charset Problem - Umlaute werden nicht angezeigt

[Tian]

Guten Tag die Herren,

ich habe vorhin eine Webseite hochgeladen auf der einige Umlaute drauf sind.
Lokal im Firefox angeschaut gab es auch absolut keine Probleme - die Umlaute wurden korrekt angezeigt.
Als Metatag steht im HEAD Bereich auch:

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

Mein FTP Programm hatte ich nun zwischendurch mal auf "utf-8 erzwingen" eingestellt, nachdem es vorher auf automatische Erkennung stand.

Leider bringt das alles nichts. Sobald die Seite auf dem Webspace drauf ist, werden die Umlaute nicht mehr korrekt dargestellt.

Laut phpinfo() akzeptiert der Server aber utf-8 als Zeichenkodierung:

HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7

Hat jemand eine Idee, wodran das noch liegen könnte? Ich würde ansich nur sehr ungerne alle Umlaute dauernd als &auml etc. schreiben.

Hab zwischendurch auch mal versucht die Kodierung auf ISO-8859-1 zu ändern, aber die Umlaute wurden auch danach immer noch falsch angezeigt.

Hoffnungsvolle Grüße
vom Tian

[Tom]

Hello,

ich habe vorhin eine Webseite hochgeladen auf der einige Umlaute drauf sind.
Lokal im Firefox angeschaut gab es auch absolut keine Probleme - die Umlaute wurden korrekt angezeigt.
Als Metatag steht im HEAD Bereich auch:

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

Hättest Du die URL auch gepostet, könnten wir Dir direkt helfen.
Somusst Du bitte selber schauen, welche Codierung der Server benutzt, auf dem sie Seite liegt. Das kannst Du z.B. mittels der Live-HTTP-Header-Extension des Firefox wunderbar nachsehen.

https://addons.mozilla.org/de/firefox/addon/3829/

Die Header des Servers haben (i.d.R.) Vorrang vor den Eintragungen im <meta>-Element.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tian]

URL der Webseite ist: http://schwarzlichtfoto.ideenplantage.de/kontakt.html

Habe gerade das Addon installiert. Wenn ich das nun alles richtig gelesen habe, benutzt der Server laut dem Addon auch UTF-8.

[Der Martin]

Hallo,

Lokal im Firefox angeschaut gab es auch absolut keine Probleme - die Umlaute wurden korrekt angezeigt.
Als Metatag steht im HEAD Bereich auch:
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

daraus darf man wohl schließen, dass das Dokument *wirklich* in UTF-8 codiert ist.

Mein FTP Programm hatte ich nun zwischendurch mal auf "utf-8 erzwingen" eingestellt, nachdem es vorher auf automatische Erkennung stand.

Ein FTP-Client tut normalerweise gar nichts in der Richtung; dass die Textcodierung durch FTP verändert wird, habe ich noch nie gehört. Außerdem hat FTP natürlich keinen Einfluss auf das Verhalten des Webservers.

Leider bringt das alles nichts. Sobald die Seite auf dem Webspace drauf ist, werden die Umlaute nicht mehr korrekt dargestellt.

Dann wird der Webserver vermutlich die Zeichencodierung falsch angeben - vermutlich ISO-8859-1. Ändere das, beispielsweise mit der Direktive AddDefaultCharset in einer .htaccess-Datei.

Es gibt drei wichtige Schritte bei der Zeichencodierung:
 * die tatsächliche Codierung, in der das Dokument gespeichert wird
 * die angebliche Codierung, die der Server im HTTP-Header mitteilt
 * die angebliche Codierung, die als Ersatzangabe im meta-Element steht

Laut phpinfo() akzeptiert der Server aber utf-8 als Zeichenkodierung:
HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7

"Akzeptieren" ist etwas anderes als "angeben". Das eine ist Empfangen, das andere ist Senden.

Hab zwischendurch auch mal versucht die Kodierung auf ISO-8859-1 zu ändern

Wie hast du das getan?

aber die Umlaute wurden auch danach immer noch falsch angezeigt.

Offensichtlich nicht richtig.

So long,
 Martin

[Tian]

Hallo,

Lokal im Firefox angeschaut gab es auch absolut keine Probleme - die Umlaute wurden korrekt angezeigt.
Als Metatag steht im HEAD Bereich auch:
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

daraus darf man wohl schließen, dass das Dokument *wirklich* in UTF-8 codiert ist.

Ich weiss nicht, wie es etwas wirklich oder unwirklich kodiert sein kann. Ich habe einfach nur darauf geachtet, dass diese Zeile dort oben am Anfang in meinem HTML Dokument im HEAD Bereich steht.

Dann wird der Webserver vermutlich die Zeichencodierung falsch angeben - vermutlich ISO-8859-1. Ändere das, beispielsweise mit der Direktive AddDefaultCharset in einer .htaccess-Datei.

Habe nun eine .htaccess Datei mit dem Inhalt AddDefaultCharset UTF-8 ins Verzeichnis hochgeladen. Aber leider gehts immer noch nicht.

Hab zwischendurch auch mal versucht die Kodierung auf ISO-8859-1 zu ändern

Wie hast du das getan?

Indem ich den Meta Tag oben geändert habe in:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />

Grüße vom
Tian

[Tom]

Hello,

Hab zwischendurch auch mal versucht die Kodierung auf ISO-8859-1 zu ändern

Wie hast du das getan?

Indem ich den Meta Tag oben geändert habe in:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />

Wie Du ja schon weißt, reicht das nicht. Wenn der Server nämlich etwas anderes behauptet, hat das normalerweise Vorrang.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tian]

Huhu

Wie Du ja schon weißt, reicht das nicht. Wenn der Server nämlich etwas anderes behauptet, hat das normalerweise Vorrang.

okay - aber wie soll ich damit jetzt umgehen? Also wie krieg ich das Problem nun in den Griff?

[Tom]

Hello,

Wie Du ja schon weißt, reicht das nicht. Wenn der Server nämlich etwas anderes behauptet, hat das normalerweise Vorrang.
okay - aber wie soll ich damit jetzt umgehen? Also wie krieg ich das Problem nun in den Griff?

• Feststellen, wie das Dokument tatsächlich codiert ist. Nehmen wir mal an: ISO-8859-1
      Beim Editor darauf achten, dass der keine eigenwilligen Entscheidungen trifft
      und Dir die Codierung zerschießt/mischt.
• Server (notfalls per .htaccess) einstellen auf ISO-8859-1
• Im <meta>-Element ebenfalls ISO-8859-1 eintragen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunnar Bittersmann]

@@Tian:

nuqneH

Indem ich den Meta Tag oben geändert habe in:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />

Wenn du an einen Strohballen ein Schild "Gold" ranheftest, hast du dann aus Stroh Gold gemacht?

[CHANGING-ENCODING] hab ich nur für dich übersetzt. ;-)

Qapla'

[Tom]

Hello,

Indem ich den Meta Tag oben geändert habe in:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />

Wenn du an einen Strohballen ein Schild "Gold" ranheftest, hast du dann aus Stroh Gold gemacht?

[CHANGING-ENCODING] hab ich nur für dich übersetzt. ;-)

Naja, die Beschreibung unter "Schritt 1" ist natürlich hahnebüchener Unsinn, wenn die Seiten mittels PHP-Scripten erstellt werden, denn sooo leicht geht es leider nicht.

Die PHP-Scripte müssen sämtlich umgeschrieben werden und alle String-Funktionen (und auch noch ein paar andere, die ich aber jetzt nicht aus dem Handgelenk herunterbeten kann) auf Multibytefestigkeit umgestellt werden. Dazu gehört leider nicht immer nur der Austausch der Funktionen, sondern oft auch die Umstellung der ganzen Logik drum herum.

Bstehende Seiten, die mittels PHP dynamisch erzeugt werden, müssen also dehr genau kontrolliert oder vollständig neu aufgebaut werden, wenn sie denn Zeichen oberhalb von CP127 enthalten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunnar Bittersmann]

@@Tom:

nuqneH

[CHANGING-ENCODING] hab ich nur für dich übersetzt. ;-)

Naja, die Beschreibung unter "Schritt 1" ist natürlich hahnebüchener Unsinn

Nein.

wenn die Seiten mittels PHP-Scripten erstellt werden, denn sooo leicht geht es leider nicht.

Die PHP-Scripte müssen sämtlich umgeschrieben werden und alle String-Funktionen (und auch noch ein paar andere, die ich aber jetzt nicht aus dem Handgelenk herunterbeten kann) auf Multibytefestigkeit umgestellt werden.

Was hahnebüchener Unsinn ist, sind Stringfunktionen in PHP, die ihren Namen nicht verdienen, weil sie nicht auf Strings, sondern auf Bytefolgen operieren.

Qapla'

[Tom]

Hello,

Die PHP-Scripte müssen sämtlich umgeschrieben werden und alle String-Funktionen (und auch noch ein paar andere, die ich aber jetzt nicht aus dem Handgelenk herunterbeten kann) auf Multibytefestigkeit umgestellt werden.

Was hahnebüchener Unsinn ist, sind Stringfunktionen in PHP, die ihren Namen nicht verdienen, weil sie nicht auf Strings, sondern auf Bytefolgen operieren.

Du willst jetzt aber bitte nicht PHP die Schuld daran geben, dass der Artikel mindestens die Hälfte der Arbeite verschweigt? Meinst Du wirklich, dass jemand, der sein Backend für komplexere Webseiten mit C, Pascal oder C++ oder deren anderer Derivate gebaut hat, da weniger Stress bekommt?

Wie sit es denn bei komplexeren Perl-Backends? Kann man die einfach durch "Umschmeißen" einer Konfigurationseinstellung umstellen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Pragma]

Du willst jetzt aber bitte nicht PHP die Schuld daran geben, dass der Artikel mindestens die Hälfte der Arbeite verschweigt? Meinst Du wirklich, dass jemand, der sein Backend für komplexere Webseiten mit C, Pascal oder C++ oder deren anderer Derivate gebaut hat, da weniger Stress bekommt?

Zitat von fraglicher Seite:

"Zielgruppe: Neulinge auf dem Gebiet Internationalisierung, die die Zeichencodierung ihrer (X)HTML-Seiten ändern möchten"

Wie sit es denn bei komplexeren Perl-Backends?

Die Stringfunktionen von Perl verdienen ihren Namen :-)

Kann man die einfach durch "Umschmeißen" einer Konfigurationseinstellung umstellen?

Bzgl. der Sprache also solcher sicher schmerzfreier als bei PHP. Der Rest wird vom fraglichen System abhängen. Sofern dass vorher schon brav dem Grundsatz "Dekodiere alles, was reinkommt und enkodiere alles, was rausgeht" folgte, ist das zumindest vorstellbar.

[Gunnar Bittersmann]

@@Tom:

nuqneH

Du willst jetzt aber bitte nicht PHP die Schuld daran geben, dass der Artikel mindestens die Hälfte der Arbeite verschweigt?

Es ist nicht Inhalt des Artikels, die Unzulänglichkeiten von PHP zu beschreiben. Es ist der Inhalt des Artikels, die Verwendung von UTF-8 als sinnvolle Zeichencodierung zu beschreiben.

Wenn dir UTF-8 mit PHP Probleme bereitet, kannst du dich gern an die PHP-Entwickler wenden mit der Bitte, aus dem Gestammel endlich eine Sprache zu machen.

Qapla'

[Keine Ahnung]

Es gibt eine Funktion die wandelt so'n Schrott wie diese äöüÄÖÜß-Ersatzzeichenketten wieder in die Zeichen um. Sie heißt utf_decode() oda so... schau einfach mal hier: Google-Suche

mfg, ...

[Gunnar Bittersmann]

@@Keine Ahnung:

nuqneH

Es gibt eine Funktion die wandelt so'n Schrott wie diese äöüÄÖÜß-Ersatzzeichenketten wieder in die Zeichen um.

Du machst hier deinem Nickname alle Ehre.

Es geht nicht darum, ein Problem zu kaschieren statt zu lösen.

Sie heißt utf_decode() oda so... schau einfach mal hier: Google-Suche

Wenn der Fragende das Suchwort nicht kennen konnte, ist ein Link zu lmgtfy IMHO unangebracht. Und per Short-URL sowieso.

Qapla'