Massives Zeichensatzproblem: Bei UTF-8 zerlegt er mir ö,ä und ü

X(HT)ML wird immer als grundsätzlich als UTF-8 angesehen, wenn es keinen entsprechenden HTTP-Header gibt, der bereits vor dem Dokument geschickt wird (-> http-equiv funktioniert also nicht). Dementsprechend sollte konsequent UTF-8 verwendet werden.

[Powie]

nimm das einfach aus dem TPL mal raus, auskommentieren:
{ *  * }

Was soll das bringen?

[k00ni]

Was schlägst du also vor?

Hab ich doch geschrieben: Konsequent UTF-8. Dabei ist es egal, was in einem File deklariert wird, da, um zu sehen was in einem File steht, die Kodierung doch schon bekannt sein muss.
Zum besseren Verständnis:
Schicke ich einen XML-File ohne expliziten Content-Encoding-Header, wird dieses immer als UTF-8 angesehen und dann auch so kodiert. Stößt der Parser dann auf eine Angabe, dass ein Dokument z.B. als Latin-9 kodiert ist, ist es schon zu spät. Hier hilft keine implizite Kodierung mehr.
Deswegen:
* Komplettes PSys auf UTF-8 umstellen,
* Datenbankdaten auf UTF-8 umstellen,
* Klarstellen, dass auch der HTTPD Seiten als UTF-8 ausliefern muss
Hier existiert hier eh noch ein ordentliches Problempotenzial, da praktisch alle Operationen im PSys davon ausgehen, dass nur Latin-9 verarbeitet wird, jedoch wird dies nirgends explizit sichergestellt. Dementsprechend kann man das PSys mit eher ungewöhnlichen Zeichensätzen ordentlich aus dem Tritt bringen, bspw. mit UTF-7 oder UCS.

[Powie]

Welche Variante der Kollation würdest du für die Datenbank empfehlen?
utf8_general_ci ?

Ja.

[Powie]

Die Datenbank auf UTF-8 anzulegen ist klar, eine existierende umzustellen ist Fleissarbeit /uploads/emoticons/icon_e_smile.gif.4a0acefcb917340d2c82e5239c009e6e.gif\" alt=\":)\" />
was muss man bei diesen beiden Punkten noch beachten:
* Komplettes PSys auf UTF-8 umstellen,
* Klarstellen, dass auch der HTTPD Seiten als UTF-8 ausliefern mus

[k00ni]

Komplettes PSys auf UTF-8 umstellen[/quote]
Ich denke, dass du hier noch jede Datei als UTF-8 speichern musst sowie alle Zeichen die dann falsch dargestellt werden noch abänderst. Oder du konvertierst direkt ins UTF-8, was Statler etwas weiter vorne im Thread geschrieben hatte.
 
Anbei, danke dass du dir wegen mir so ne Arbeit machst.  /uploads/emoticons/icon_e_biggrin.gif.1a84f5257b36e14b36d04985314f877f.gif\" alt=\":-D\" />/uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />

[Powie]

Anbei, danke dass du dir wegen mir so ne Arbeit machst. [/quote]
lol..... ich denke da bist du wohl nicht der einzigste ..... ich denke das wird ehr \"alle\" betreffen  [/uploads/emoticons/icon_e_surprised.gif.a005678239f11b45b64b526b2c82e9a1.gif\" alt=\":o\" />]

Mit der L10N betrifft es jeden, der außerhalb von Latin-9 (also außerhalb der Westeuropäischen Sprachen) arbeiten will.

[k00ni]

So, habs nun umgestellt und es läuft sauber bei mir. Du hast zwar in der header.tpl und admin_header.tpl zwar das [/code]
drin gelassen. Dadurch wurde es wieder ISO-8859-1 und die Zeichen falsch dargestellt.
Habe es nun so geändert, dass oben ein
 

steht und habe dass

 
 
herausgenommen. Falls jemand mit der Umstellung Probleme hat, kann die beiden Dateien im Anhang nehmen. Die header.tpl in den tpl-Ordner im Hauptverzeichnis, die admin_header.tpl in den tpl-Ordner im Ordner admin.
 
Grüße

Es reicht nicht, im Dokument einen Zeichensatz zu deklarieren, dies muss bereits beim Ausliefern der Seiten passieren, also als entsprechender HTTP-Header.

[mahe]

also ein

header(\'Content-type: text/html; charset=utf-8\');

 
?

Genau. Vorzugswiese konfiguriert man dies aber über den Webserver, da man sich mit header-Aufrufen in PHP leicht andere Probleme einhandelt, bspw. wenn man kein Output Buffering verwendet oder eine Ressource vergisst.