RootForum Community

Es scheint so als hättet ihr mit eurem Server dasgleiche Problem wie ich mit meinem: Heute ein apt-get update und upgrade gemacht, bestätigt und weg sind sie, die Umlaute. Alles was nicht maskiert ist kommt als Schrott an :(

Moin,

folgender Eintrag in der php.ini behob den "Bug": Gruss,
Joe User

Zwei weitere Möglichkeiten zur "Bug"-Behebung können sein:
1. /etc/apache2/conf.d/charset anpassen
AddDefaultCharset UTF-8 -> AddDefaultCharset ISO-8859-1

2. php.ini
Die Zeile
;default_charset = "iso-8859-1"
auskommentieren
default_charset = "iso-8859-1"

Allerdings ist man so wieder weg von UTF-8 - das ist ein Teufelskreis ;-)

Apropos ;-)

Mir fällt dies auch schon seit geraumer Zeit in immer mehr Foren auf, u.a. auch diesem hier. Man traut sich ja fast schon nicht mehr, überhaupt noch Umlaute oder Sonderzeichen im Internet einzusetzen... ;-)

Back to the roots, oder wie? *lol*

Nee, im Ernst, muss dies so sein? Vor allem:

folgender Eintrag in der php.ini behob den "Bug":

stimmt ja offensichtlich nicht, da immer noch mind. die Hälfte falsch ist (siehe 1. Beitrag) ;-)

Meine Erfahrung seit ca. 1,5 Jahren mit UFT-8 ist, dass es eigentlich nicht wirklich schwer ist einzusetzen, aber nur gleich bei Projekt-Start. Wenn man mittendrin (z.b. in einem schon recht umfangreichen Forum wie diesem) erst auf UTF-8 umsteigt, hat man meist ein ziemliches Chaos, da die alten Daten erst mühsam ALLE umkodiert werden müssten. Das wird wohl oftmals vergessen, bzw. ohne eigene Hilfs-Scripte wird es nicht gehen, und die zu schreiben, ist wohl nicht jeder in der Lage zu.

Evtl. liege ich auch etwas falsch, und will hier vor allem nicht klugshicen, aber als Entwickler bin ich an diesem Problem sehr interessiert, aber habe bislang mit eigenen Seiten (kein Forum, aber umfangreiches CMS) Null Probleme.

Nun frage ich mich halt einfach immer wieder, was konkret zu den Foren-Missständen führt(e), und wie ich so etwas bei Bedarf auf jeden Fall vermeiden könnte. Es nervt nämlich gewaltig, wenn man jeden 2. Satz doppelt lesen muss, um zu überlegen, welche Zeichen wohl gemeint sein könnten. Das möchte ich meinen Kunden ungern antun... ;-)

Also @joe:
Bitte nicht persönlich nehmen, aber was ist da los bei Euch? Irgendwo ist da noch der Wurm drin wg. UTF-8 oder watt weiss ich, richtig?

EDIT:
oder liegt dies alles nur NICHT-UTF-8-tauglichen Browsern? Gibt es so etwas noch, und wenn, dann in so hoher Anzahl? Das wäre ja schrecklich...

mitMacher wrote:Also @joe:
Bitte nicht persönlich nehmen, aber was ist da los bei Euch? Irgendwo ist da noch der Wurm drin wg. UTF-8 oder watt weiss ich, richtig?

Jupp, als ich vor etwas über einem Jahr die Datenbank von latin1 auf utf8 umstellte, war ich leider etwas zu hektisch :( Die daraus resultierten Kodierungsfehler sind heute nur noch manuell zu korrigieren, was bei >300.000 Vorkommnissen (plus Fipptehler) nur begrenzt möglich ist.
Da ich das RootForum möglichst noch in diesem Jahr auf phpBB3 umstellen möchte, werde ich bei der Gelegenheit auch die gröbsten (aber nicht alle) latin1->utf8 Probleme beseitigen.

HTH

mitMacher wrote:EDIT:
oder liegt dies alles nur NICHT-UTF-8-tauglichen Browsern? Gibt es so etwas noch, und wenn, dann in so hoher Anzahl? Das wäre ja schrecklich...

Die Browser machen das in der Regel schon richtig.
Das Problem liegt in der Diskrepanz zwischen dem was der Apache in den HTTP-Headern ausliefert (Encoding: iso-8859-1) und dem, was im html-head steht <meta http-equiv="content-type" content="text/html; charset=UTF-8" />.
Das kann man z.B. beim Firefox unter "Tools->Page Info" sehen. Der Firefox hält sich erst einmal an das, was er in den HTTP-Headern findet.

Gruß, Olaf.

olaf.dietsche wrote:Das Problem liegt in der Diskrepanz zwischen dem was der Apache in den HTTP-Headern ausliefert (Encoding: iso-8859-1) und dem, was im html-head steht <meta http-equiv="content-type" content="text/html; charset=UTF-8" />.

Genau dafür ist doch AFAIK der <meta> header da, daß man damit den Server-weiten Header, auf den man u.U. keinen Einfluß hat überschreiben kann. Deshalb sollte sich der Browser auch nach dem <meta> tag richten wenn er eins findet (macht mein Mozilla übrigens auch).

Hm, ob das mit dem Metatag so stimmt? Schließlig müsste der Parser vom Browser ja nochmal mit dem neuem Zeichensatz von vorne anfangen... oder etwa nicht?

AFAIK ja. Deshalb steht der Tag auch im <head> der Seite ganz oben, damit der Browser bis dorthin (HTML Doctype, <html> und <head> tags) alles als ASCII parsen kann. Wenn er das richtige Encoding kennt fängt er noch mal von vorne an. Ist natürlich ein ziemlicher "Würg"-around, aber funktioniert. :)

dustpuppy wrote:

olaf.dietsche wrote:Das Problem liegt in der Diskrepanz zwischen dem was der Apache in den HTTP-Headern ausliefert (Encoding: iso-8859-1) und dem, was im html-head steht <meta http-equiv="content-type" content="text/html; charset=UTF-8" />.

Genau dafür ist doch AFAIK der <meta> header da, daß man damit den Server-weiten Header, auf den man u.U. keinen Einfluß hat überschreiben kann. Deshalb sollte sich der Browser auch nach dem <meta> tag richten wenn er eins findet (macht mein Mozilla übrigens auch).

So, ich habe mich mal schlau gemacht. :google: liefert zum Thema <meta http-equiv...> folgende Links:
http://apache.lexa.ru/english/meta-http-eng.html
http://www.w3.org/TR/html4/charset.html#h-5.2.2

Der Abschnitt "To sum up, conforming user agents ..." zeigt die Reihenfolge, in der ein Webbrowser die verschiedenen Möglichkeiten auswerten muß.

Und an erster Stelle steht nun mal der Content-Type aus den HTTP-Headern.

kleiner Tipp: NIEMALS per apache bzw. php einen "default charset" festlegen. Davor wird auch in der config (zumindest wenn ich unter debian, apache neuinstalliere, in der standard-config) gewarnt. Ich (und sicherlich viele andere Entwickler) denken das es ein "Architekturfehler" und wird sicherlich in einige künftigen Versionen nicht mehr existieren.

Grund: mit der "Default charset" direktive wird ein charset aufgezwungen - egal ob ihr es vielleicht in eure html/php-datei anders habt.

Wozu? Keine Ahnung! Denn jede vernünftig kodierte Seite enthält (wenn überhaupt nötig) benötigte Infos im Header, z.B.:
<?xml version="1.0" encoding="UTF-8" ?>
bzw:
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

Also ist die "default" direktive total unnötig.

Probleme? Ja! Sobald nämlich Zeichen verwendet werden die nicht

Umlaute/Sonderzeichen? Entweder per html-entity z.B. gr&uuml;sse oder per utf8: grüsse
So sollten die auch möglichst abgespeichert werden (vorzugsweise utf8), erhöht die portation in andere Systeme (utf8 ist ein Standard)

Sicherlich werden die meisten (vor allem als Deutscher, obwohl wir selber sonderzeichen haben - die aber soweit ich es sehe - noch zur ASCII Tabelle gehören - aus welchen Gründen auch immer) noch nichts von "utf8" bzw. "unicode" gehört haben, aber es ist besser sich schonmal darauf einzustellen, immerhin hat (behaupte ich mal) jedes Land nen Inet anschluss und ist somit potenzieller Kunde ;)


Wie? -->

Apache:
AddDefaultCharset off

PHP:
;default_chartset ...

Latin 1 ?? Ist heute nicht UTF standard ??

Gruß
Outi

guwapo wrote:kleiner Tipp: NIEMALS per apache bzw. php einen "default charset" festlegen. Davor wird auch in der config (zumindest wenn ich unter debian, apache neuinstalliere, in der standard-config) gewarnt. Ich (und sicherlich viele andere Entwickler) denken das es ein "Architekturfehler" und wird sicherlich in einige künftigen Versionen nicht mehr existieren.

Der "Fehler" existiert auch nur bei Debian/Ubuntu. Andere Distributionen wie Gentoo oder SuSE haben diese Direktive nicht in der Standardkonfiguration.

jetzt ist wieder ganz schlimm.. alle Umlaute gefressen

Bekannt und spätestens mit dem Upgrade auf phpBB3 (weitestgehend) behoben.

Sorry, geht momentan leider nicht anders.

Liegt es hauptsächlich an Daten mit gemischten charset (iso-8859-15 und utf-8 ) in der mysql Datenbank, durch "hektisches" umstellen auf utf-8, und damit verbundener "halbherziger" Konvertierung, damals?

Oder habt Ihr ein ähnliches Problem wie ich es bis gestern hatte:

phpinfo() zeigte unter "HTTP Response Headers": nicht zu verwechseln mit den "HTTP Request Headers": In meiner /etc/apache/httpd.conf stand vorher: Und nun steht da: Das Auskommentieren des AddDefaultCharset on brachte die Lösung bei Textaerea und form input.

phpinfo() zeigt nun unter "HTTP Response Headers": Debian/etch apache 1.3.x

floogy wrote:Liegt es hauptsächlich an Daten mit gemischten charset (iso-8859-15 und utf-8 ) in der mysql Datenbank, durch "hektisches" umstellen auf utf-8, und damit verbundener "halbherziger" Konvertierung, damals?

Ja, zudem habe ich vor kurzem auch die libmysql endgültig auf utf8 umgestellt, wodurch der letzte Charset-Bug entstand. Aber wie ich bereits schrieb, werden die (meisten) kaputten Sonderzeichen beim Upgrade auf phpBB3 wieder korrigiert. Bis dahin dürft Ihr mich virtuell prügeln ;)

Was für einen Einfluß haben folgende Größen in phpinfo() auf die Darstellung der Zeichensätze in Webanwendungen? Wie kann man alle Datenbanken in einem Rutsch auf enthaltene charsets prüfen?
Ich habe hier auf Anhieb nichts gefunden:
http://dev.mysql.com/doc/refman/5.1/de/charset.html
http://blog.koehntopp.de/archives/1424- ... lagen.html
http://dev.mysql.com/doc/refman/5.1/de/mysqlcheck.html

In meiner my.cnf ist nicht von charsets (iso oder utf) die Rede, ist das ein gutes Zeichen, ähnlich dem Vermeiden von default-charsets in den php Grundkonfigurationen und der webserver-config?

Server : Apache/1.3.34 (Debian)
PHP Version : 5.2.0-8+etch7
mysql: 5.0.32-Debian_7etch1-log

EDIT: Es sind wohl nicht alle meiner mysql Datenbanken in UTF-8:
http://www.google.de/search?q=%22iconv+ ... C%22+mysql Habe aber gesehen, dass ISO 8859-1 in all_databases.sql vorkommt:

Also ich habe sicher von allen am wenigsten Ahung von all dem, aber wie es scheint werden Umlaute ja jetzt richtig dargestellt wenn ich einen neuen Post eröffne -> ÄÖÜäöü

Ich hatte das Problem nach dem Import der Datenbank und habe habe "einfach" alle Zeichen entsprechend in der Datenbank geändert:

UPDATE `TABELLE` SET SPALTE = REPLACE (SPALTE, 'KAPUTTER UMLAUT', 'RICHTIGER UMLAUT');

Behebt es das Problem dann nicht?

Oh - soor, habe nen neues Thema erstellt - wollte ich nicht - sollte zu dem schon bestehendem Thema - Sorry!

EDIT: Themen zusammengeführt --Roger Wilco

Moin,

ich habe mir mal zwei Tage Zeit genommen und die versemmelten Sonderzeichen (bis auf wenige Ausnahmen) in den Beiträgen korrigiert und den Suchindex neu aufgebaut. Somit dieses Problem endlich behoben sein und ich kann mein schlechtes Gewissen wieder beruhigen ;)

Gruss,
Joe User

Hallo Joe User,
erstens danke, und zweitens brauchst Du als jemand, der ehrenamtlich dermaßen viel arbeitet, sowieso kein schlechtes Gewissen zu haben ;)
Gruß Fritz