Umlaute auf der Homepage

Halli, hallo.

Ich habe mich in letzter Zeit damit beschäftigt, eine Homepage aufzubauen, das Ergebnis ist hier zu finden:
pixelmann.bplaced.net/
Nun habe ich allerdings folgendes Problem: Die Umlaute der News werden nicht korrekt angezeigt.
Ein <meta http-equiv="content-type" content="text/html; charset=utf-8"> ist natürlich vorhanden, allerdings bleibt das Resultat bei falschen Umlauten. Mit der entsprechenden header() Funktion über PHP-Code bleibt das gewünschte Ergebnis auch aus und über die .htaccess konnte ich mein Ziel auch noch nicht erreichen.
Die Ausgabe des content-headers zeigt folgendes:

Die Status-Leiste oben kann die Umlaute auch richtig darstellen.
ABER: Rufe ich die eingebettete Datei “content.php” in meinem browser über diese URL auf, so erhalte ich meine korrekten Umlaute.

Ich bin mit meinem Latein am Ende und dachte, dass ich es mal hier herein schreibe, da es ja vielleicht sein könnte, dass es am hoster liegt.
LG Pixelmann :slight_smile:

Diese Ressource enthält keine UTF-8-kodierten Daten. (Es wird auch keine Angabe zur Kodierung gemacht, die „korrekte“ Anzeige basiert also nur darauf, dass der Browser richtig „rät“.)

Du kannst nicht mehrere Zeichenkodierungen in einer Ressource mischen (und genau das tust du aber, wenn du content.php in deine Index-Seite, die UTF-8 kodiert ist, einbindest).

Speichere auch deine content.php in UTF-8 kodiert ab.

Okay, lasse ich mir nun die content.php anzeigen, habe ich auch hier die Fragezeichen. :slight_smile:
Edit: Antwort-Header sagt: Content-Type: text/html

Auf die Kodierung kommst an. Hast du php jetzt mit UTF-8 gespeichert?

[quote=“pixelmann”]
Edit: Antwort-Header sagt: Content-Type: text/html[/quote]

Versuch es mal mit
.htaccess

AddDefaultCharset utf-8 AddType 'text/html; charset=UTF-8' .php

Ich hab sowohl einen header("Content-Type: text/html; charset=utf-8"); drin, als auch ein <meta http-equiv="content-type" content="text/html; charset=utf-8">.

Btw: Super service hier, danke für die schnellen Antworten :slight_smile:

Die Datei als UTF-8 abspeichern. Was verstehst du daran nicht?

Du öffnest den Windows editor, gehst auf speichern unter und bei codierung auf UTF-8…

Ah, alles klar, sie war nicht als UTF-8 gespeichert. Allerdings muss ich mich gerade mit einem anderen Problem rumschlagen. Anscheinend läuft der php code nicht mehr durch den compiler…
Edit: Alles geht wieder und Umlaute werden korrekt dargestellt. Lag wohl an der .htaccess von fishi…
Edit2: Ups, wohl doch nicht. ß wird richtig dargestellt, doch äs ös und üs nicht…

Das mit utf-8 speichern + meta tag sollte funktionieren…zumindest tuts bei mir seit ewig :wink:

Ich hab jetzt die Konversation nicht genau verfolgt, aber mir stellt sich die Frage, warum du keine HTML-Maskierungen verwendest?

lg

Ich habs grad mal gegoogelt. Theoretisch kann ich ja einfach nur eine php Datei machen, in der ich für jedes Sonderzeichen (also eigentlich brauch ich ja nur meine äs, ös, üs und ß) eine Bedingung einbau, bei der statt Ä eben Ä schreib, oder?

Klar kann man das machen, aber es wäre ziemlicher Unfug.

Speichere deine include-Datei einfach in UTF-8 kodiert ab, und zwar korrekt in UTF-8 kodiert, dann sollte sich das Problem erledigt haben.

Naja… Ich bin immer dafür, Sonderzeichen jeglicher Art aus Quelltext hinauszuhalten, aber das kann jeder halten, wie er will, sofern er die richtige Codierung verwendet. Und da bist du ja auch schon am Ziel.

Und stattdessen mit Entities Schreibweisen hineinzubringen, die sich schlechter lesen lassen und beim Editieren noch mehr Aufwand verursachen …?

FYI: w3.org/International/questio … en.php#not

[quote]It is almost always preferable to use an encoding that allows you to represent characters in their normal form, rather than using character entity references or NCRs.

Using escapes can make it difficult to read and maintain source code, and can also significantly increase file size.[/quote]

Gut zu wissen, dann bleib ich mal bei der Codierung.
Ich arbeite hier ja unter Linux. Über meinen gedit konnte ich die Codierung bis jetzt nicht ändern. iconv hat mir aus us-ascii binary gemacht, statt des gewünschtem utf-8. iconv -f us-ascii -t utf-8 index.php>index.php
Ich hatte jetzt einen Kumpel gefragt, ob er mir die Datei von seinem Windows aus neu codiert. Gesagt, getan. Allerdings hatte ich nun das Problem, dass ich einen “header already sent”-Fehler bekam. Das konnte ich zum Glück mit dem Hex-Editor lösen, da sich vor dem <?php drei versteckte Punkte befanden. Allerdings habe ich jetzt wieder us-ascii als Codierung…

Und hier mein Antwort-header.

[quote]Date: Fri, 05 Nov 2010 08:55:10 GMT
Server: Apache/2.2
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
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=4, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

200 OK[/quote]
Edit: Die Datei ist jetzt utf-8 codiert. Es musste einfach nur ein ä, ö oder ü vorkommen. Allerdings sind die Zeichen immer noch Fragezeichen…
Edit2: Jetzt steht im Antwort-header schonmal UTF-8. Die Umlaute sind immer noch Fragezeichen. Beim Aufrufen der content.php sehe ich wieder alles.

file -i Desktop/index.php Desktop/index.php: text/x-php; charset=utf-8
Edit3: Und hier steht was interressantes: rexswain.com/cgi-bin/httpview.cgi
Der Header von pixelmann.bplaced.net/ aber nicht…
Edit4 (:o): Wenn man eine Datei über die include() Funktion einbindet, werden die Umlaute “falsch” dargestellt.

Alles, was per include zusammengepappt wird, muß jedenfalls
dieselbe Kodierung haben. Es ist auch sonst nicht möglich, in einer
Datei verschiedene Kodierungen unterzubringen.
Versehentliche Editierungen mit einem Editor, der die Kodierung
falsch interpretiert hat, führt zu Dokumenten, die sich nicht mehr
durchgehend automatisch dekodieren lassen.

Wenn man vom server einen header mit Kodierungsangaben sendet,
müssen diese jedenfalls zu der Kodierung passen, mit der das
Dokument abgespeichert wurde.

Was die Maskierungen ß etc anbelangt, so ist dabei vor allem
problematisch, daß einige browser die bei XHTML nicht mehr
für alle Versionen kennen (hängt davon ab, ob und welcher dotype
im Dokument steht, was nirgends spezifiziert ist, sondern mehr
so eine destruktive Laune der browser-Anbieter ist).

Wenn es fraglich ist, was für eine Kodierung vorliegt, sollte man
solange mit browser oder Editor die Kodierung der Ansicht
manuell ändern, bis man die passende gefunden hat, die kann
man dann vom server senden lassen oder im Falle einer
gewünschten Konvertierung als Ausgangskodierung angeben.