Umlaute März statt März

[hazweioo]

Hallo,

ich suche nun seit Tagen dumm in der Gegend rum aber habe nix gefunden
zu meinem evtl. nur recht kleinen Problem.

Folgendes, ich bin dabei auf meinem eigenen OS X 10.4 Server ein Blog
zu installieren, das alles funktioniert auch recht prima nur ein kleines
Problem taucht auf, die Umlaute der Datumsanzeige werde etwas seltsam
angezeigt, okay es handelt sich dabei im deutschen nur um den Monat März
aber mich stoert das ganze schon ein wenig. Im Blog wird naemlich März
statt März angezeigt. Ich dachte okay liegt das evtl. an deiner Software,
also probierte ich Nucleus und Sunblog aus, bei beiden habe ich de_DE
eingestellt damit Datumsanzeige usw. in deutsch erscheinen klappt alles
auch prima nur das winzig kleine Problem mit dem März )o:

Also hab ich mal in der httpd.conf und php.ini rumgesucht, auch nochmal
ueberprueft in den Systemeinstellungen alles richtig ist. Aber ich habe so
nicht wirklich was gefunden. Ich habe danach mal die Blogsoftware noch
auf mein iBook installiert mit dem selben Effekt. Unter Google und Co. hat
sich auch nichts brauchbares gefunden. Weiss vielleicht hier jemand Rat
was da nicht stimmt und wenn ja wo ich das richtig einstellen kann?

Nochmal zusammengefasst:
Die generiert Datumsanzeige in meinem Blog zeigt März statt März an.
Ausporbierte Blogsoftware: Nucleus und Sunlog
Webserver: Apache auf OS X 10.4 und OS X Server 10.4

Weiss da jemand was? (o:
Danke.

ahoi tillman

 

[mcnewbie]

kodierung falsch eingestellt? sonnst halt kodiert reinschreiben ... ä für ä? man möge mir widersprechen

 

[hazweioo]

Wo stelle ich die Codierung denn ein? In der Blogsoftware sind fuer Locales de_DE
eingestellt. Und die Kodierung wird ja vom Server dynamisch erstellt, ich kann mir
nicht vorstellen das ich in dem Blogscript was aendern muesste, denn auf nem
Webserver von Hosteurope zBsp. gibts es das März Problem nicht da wird März
richtig dargestellt, ich wuerde meinen das irgendwo am Server was nicht stimmt?!?!

 

[maceis]

Schreibe in eine .htaccess Datei im Server Root Verzeichnis:

AddDefaultCharset On

Damit wird das Charset auf ISO 8859-1 gesetzt.

 

[oneOeight]

das sieht aber eher nach UTF-8 aus
ein
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
im html der seite sollte das doch auch fixen

 

[Incoming1983]

Entweder mußt du das character encoding korriegieren, oder du gibst alle Umlaute etc. als named entities aus. Letzteres ist ohnehin zu bevorzugen.

 

[maceis]

das sieht aber eher nach UTF-8 aus
ein
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
im html der seite sollte das doch auch fixen

Dann muss man schreiben

AddDefaultCharset utf-8

Finde ich wesentlich einfacher, als den meta Tag, den man dann ja auf jeder Seite setzen muss.
Wenn man natürlich Dokumente in unterschiedlichen Kodierungen ausliefert kommt man wohl nicht darum herum.

...
oder du gibst alle Umlaute etc. als named entities aus. Letzteres ist ohnehin zu bevorzugen.

Ansichtsache. Ich mach's schon lang nicht mehr.
Was an dieser IMHO veralteten Tecnik zu bevorzugen ist, habe ich noch nie verstanden.

 

[Incoming1983]

Ansichtsache. Ich mach's schon lang nicht mehr.
Was an dieser IMHO veralteten Tecnik zu bevorzugen ist, habe ich noch nie verstanden.

Die paar Bytes Speicherplatz hat man idR, es entsteht also kein wirklicher Nachteil.
Und des weiteren muß man sich nie darum kümmern, ob das Character Encoding nicht doppelt vorkommt (Webserver + Dokument) und, ganz wichtig, es ist völlig egal, wie mans editiert.
Ansonsten mußt du immer darauf schauen, daß du es mit einem editor editierst, der das charenconding versteht, und auch korrekt abspeichert, sonst gibts Datensalat.

Deshalb schreibt der bequeme die Entities einfach aus ;-)

 

[maceis]

Ich kann leider keines Deiner Argumente nachvollziehen.

Nervig wird's meiner Ansicht nach vor allem dann, wenn man Benutzerdaten verarbeitet, Textdateien oder Datenbanken ausliest o. ä.
Dann gehen nämlich die bequemen "Suchen und Ersetzen" Orgien los *äääächz*

 

[hazweioo]

Hallo,

erstmal danke fuer die schnellen Antworten (o:
Nun habe ich mal alles schoen ausprobiert, das mit dem .htaccess File, selbst
in der httpd.conf hab ich mal versucht diesen AddDefaultCharset On zu nutzen.
Ergebniss negativ.
Das mit der Kodierung direkt im HTML Dokument klappt leider auch nicht, es
bleibt bei dem schoenen März Problem.
Wie gesagt auf dem Server von Hosteurope zBsp. laeuft alles ganz prima, mit
dem Nucleus und Sunlog Script, nur auf meinem will er nicht )o:
Kann es evtl. noch mit der MySQL Datenbank zu tun haben? wobei das Datum dort
ja in dem Format abgelegt wird 2003-11-09 18:28:22 also wird es meiner Meinung
nach von dem PHP Blog Script erst in das deutsche Format umgewandelt.

Also ich bin ein wenig Ratlos. )o:

 

[Incoming1983]

Ich kann leider keines Deiner Argumente nachvollziehen.

Erstelle eine html datei mit einem editor, der unicode kann.
Speichere das ab.
Bearbeite die Datei dann mit einem editor, der das nicht kann, fummel ein wenig darin rum (insbesondere Umlaute ändern), und speichere das dann ab.
Witzig auch, wenn man die Dinge mit Notepad erstellt, und dann aufm Server mit vi bearbeitet. Oder aufm PDA.

Dann kopiere mal die Datei auf einen Webserver, der per default schon ein charset vorgibt. Der Validator wird meckern, daß zweimal ein Charset angegeben wurde, der Browser wirds evtl. falsch darstellen, wenn die sich unterscheiden.

Das einzige, was GEGEN die Entities spricht, ist der Speicherplatz. Und ich denke, davon gibts eigentlich genug. Zumal du sonst mit Unicode sogar das doppelte brauchst gegenüber 8Bit Zeichensätzen.

Edit: Für das Suchen und Ersetzen gibts reguläre Ausdrücke ;-)

 

[Scribble]

hazweioo: Dann such mal in den von der Software mitgelieferten Dateien nach den deutschen Sprachpaketen. Irgendwo muss dort der Übersetzer die Monate eingetragen haben und hat dort »März« in das Dokument reingeschrieben. Daher hast du das Problem auch nur mit diesem Monatsnamen; die anderen elf haben ja keine Umlaute.

Wenn du das »März« gefunden hast, kannst du es entweder austauschen gegen »M&auml;rz« oder du speicherst das Dokument neu ab, diesmal korrekt encodiert (je nachdem, welchen Charset dein Server ausliefert, z.B. UTF-8 oder iso-8859-1).

 

[maceis]

@ hazweioo
Ich vermute, Dein Problem steckt in dem PHP Skript oder in der PHP Einstellung auf Deinem Rechner.

; As of 4.0b4, PHP always outputs a character encoding by default in
; the Content-type: header. To disable sending of the charset, simply
; set it to be empty.
;
; PHP's built-in default is text/html
default_mimetype = "text/html"
;default_charset = "iso-8859-1"

Erstelle eine html datei mit einem editor, der unicode kann.
Speichere das ab.
Bearbeite die Datei dann mit einem editor, der das nicht kann, fummel ein wenig darin rum (insbesondere Umlaute ändern), und speichere das dann ab.
Witzig auch, wenn man die Dinge mit Notepad erstellt, und dann aufm Server mit vi bearbeitet. Oder aufm PDA.
...

Ich arbeite nicht mit kaputten Editoren .

...
Dann kopiere mal die Datei auf einen Webserver, der per default schon ein charset vorgibt. Der Validator wird meckern, daß zweimal ein Charset angegeben wurde, der Browser wirds evtl. falsch darstellen, wenn die sich unterscheiden.
...)

Meines Wissens gibt es eine klar definierte Hierarchie in der die Charset Angaben verarbeitet werden.
1. Server Default
2. Virtual Host Konfiguration
3. Verzeichnis Konfiguration
3. .htaccess Konfiguration
4. meta tag
5. Client Einstellung

Die nachfolgenden überschreiben die jeweils vorangegangen.
Ich persönlich hatte noch in keinem einzigen Fall ein Problem damit.

Aber ich muss hier auch niemanden bekehren.
Wenn Du das anders machen möchtest. steht es Dir ja völlig frei das zu tun .

 

[Schlingsi]

weiss nich obs schon einer geschrieben hat, aber ich löse das in php einfach so:
htmlentities("string_mit_hässlichen_umlauten");

das funktioniert so lange man keine html tags von hand noch in die DB einträgt. die schreibt er dann nämlich auch als string in den text. da gibts aber wiederum etwas um das zu beheben.

 

[Incoming1983]

Ich arbeite nicht mit kaputten Editoren .

Du nicht, andere schon ;-)

Die nachfolgenden überschreiben die jeweils vorangegangen.
Ich persönlich hatte noch in keinem einzigen Fall ein Problem damit.

Aber ich muss hier auch niemanden bekehren.
Wenn Du das anders machen möchtest. steht es Dir ja völlig frei das zu tun .

Ich traue dir natürlich zu, daß du ordentlich arbeitest.
Aber ich sehe leider sehr oft Fälle, wo es genau zu diesen Problemen kommt, gerade bei öffentlichen Seiten im Netz, bei denen halt die Umlaute nicht stimmen. Und da isses halt peinlich, eben weil der Designer schon hätte vorbeugen können, indem er named entities verwendet, dann ist es auch egal, wie gut die übrigen Techniker und die Qualitätskontrolle ist.

 

[oneOeight]

ich weiß gar nicht warum ihr probleme mit umlauten und DBs habt
DBs wie mysql geben doch die collation an, ihr musst doch die einfach nur auslesen und dann den meta tag dementsprechend setzen...

 

[maceis]

...
DBs wie mysql geben doch die collation an, ihr musst doch die einfach nur auslesen und dann den meta tag dementsprechend setzen...

Das ist schon richtig. Allerdings muss man dann dafür sorgen, dass die restlichen Ressourcen im selben Charset kodiert sind.

Meine persönliche Strategie ist: Grundsätzlich überall mit iso-8859-1 arbeiten.
Damit habe ich, wie gesagt, sehr gute Erfahrungen gemacht.

 

[oneOeight]

Das ist schon richtig. Allerdings muss man dann dafür sorgen, dass die restlichen Ressourcen im selben Charset kodiert sind.

Meine persönliche Strategie ist: Grundsätzlich überall mit iso-8859-1 arbeiten.
Damit habe ich, wie gesagt, sehr gute Erfahrungen gemacht.

du könntest dich doch mal inzwischen modernisieren und auf UTF-8 umschwenken

 

[maceis]

du könntest dich doch mal inzwischen modernisieren und auf UTF-8 umschwenken

Sobald es eine guten Grund dafür gibt, werde ich das in Betracht ziehen. Bis dahin sehe ich keinen Handlungsbedarf.

 

[naomi_watts]

at maceis:
Sobald du dich mit der Internationalisierung von Websites beschäftigen wirst, wirst du merken was für ein Unsinn es ist länderspezifische Zeichensätze wie iso-8859-1 zu benutzen, da du hier zwei Zeichensätze auf einer Seite nicht mischen kannst.

Für die Verwirrten:
Allgemein ist es wichtig zu begreifen, das es primär auf die richtige Speicherung und die richtige Auslieferung des Dokuments ankommt. Dies läßt sich beides nicht über einen Meta-Tag im HTML-Dokument angeben.

(edit: fehlendes "s" im letztem Satz eingefügt.)