sporadisches Umlaut-Problem

Hallo zusammen,

ich betreibe schon seit einiger Zeit einen Suse Linux-Server, mit dem ich nun aber schon seit ein paar Monaten ein merkwürdiges Umlaut-Problem habe. Ich habe eine LAMP-Installation und eigentlich alles auf ISO-8859-1 konfiguriert.

Der HTTP-Header schreibt ISO-8859-1 raus (das hab ich mit drweb.de geprüft), die Webseiten setzen per Meta-Tag die Kodierung auf ISO-8859-1, im PHP ist das default charset auf ISO-8859-1 gesetzt, in der Apache-Konfiguration wird das charset ebenfalls auf ISO-8859-1 gesetzt, die MySQL-DB ist auf latin1 eingestellt. Die LANG und LC-Variablen sind auf de_DE.ISO_8859_1 gestzt.

Soweit weiß ich keine Stelle mehr wo ich noch ISO-8859-1 einstellen soll. Trotzdem landen sporadisch in meiner DB UTF-8 codierte Umlaute, welche dann etwa so aussehen: ä (ä). Das Ganze passiert bei sämtlichen Clients, unabhängig von Betriebssystem oder eingesetztem Browser. Meist passiert es beim ersten und zweiten mal und wenn man dann das dritte mal ein Formular absendet kommen die Zeichen korrekt in ISO-8859-1 Konvertierung in der DB an.

Ich such jetzt schon seit Monaten nach dem Problem und weiß einfach nicht mehr weiter. Hat jemand schon solche Erfahrungen gemacht und kann Tipps geben, was ich noch untersuchen kann um dem Problem auf die Spurt zu kommen?

Wäre für Hilfe sehr dankbar, so ist das einfach kein Zustand, weil sämtliche Webapplikationen (Homepage, Forum, Blog, Coppermine-Gallery etc.) welche auf dem Server laufen, sporadisch diese Fehler zeigen.

MfG Micha

Welche DB (mit welchen Einstellungen)?

ist ne MySQL-Version. Welche Einstellungen brauchst du genau? Ich hab hier jetzt erstmal die "SHOW VARIABLES" gepostet:

back_log=50
basedir=/usr/
binlog_cache_size=32768
character_set=latin1
character_sets=latin1 big5 czech euc_kr gb2312 gbk sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5
concurrent_insert=ON
connect_timeout=5
datadir=/var/lib/mysql/
delay_key_write=ON
delayed_insert_limit=100
delayed_insert_timeout=300
delayed_queue_size=1000
flush=OFF
flush_time=0
have_bdb=NO
have_gemini=NO
have_innodb=NO
have_isam=YES
have_raid=NO
have_openssl=NO
init_file=
interactive_timeout=28800
join_buffer_size=131072
key_buffer_size=16773120
language=/usr/share/mysql/english/
large_files_support=ON
locked_in_memory=OFF
log=OFF
log_update=OFF
log_bin=ON
log_slave_updates=OFF
log_long_queries=OFF
long_query_time=10
low_priority_updates=OFF
lower_case_table_names=0
max_allowed_packet=1047552
max_binlog_cache_size=4294967295
max_binlog_size=1073741824
max_connections=100
max_connect_errors=10
max_delayed_threads=20
max_heap_table_size=16777216
max_join_size=4294967295
max_sort_length=1024
max_user_connections=0
max_tmp_tables=32
max_write_lock_count=4294967295
myisam_max_extra_sort_file_size=256
myisam_max_sort_file_size=2047
myisam_recover_options=0
myisam_sort_buffer_size=8388608
net_buffer_length=7168
net_read_timeout=30
net_retry_count=10
net_write_timeout=60
open_files_limit=0
pid_file=/var/lib/mysql/mysqld.pid
port=3306
protocol_version=10
record_buffer=131072
record_rnd_buffer=131072
query_buffer_size=0
safe_show_database=OFF
server_id=1
slave_net_timeout=3600
skip_locking=ON
skip_networking=OFF
skip_show_database=OFF
slow_launch_time=2
socket=/var/lib/mysql/mysql.sock
sort_buffer=524280
sql_mode=0
table_cache=64
table_type=MYISAM
thread_cache_size=0
thread_stack=65536
transaction_isolation=READ-COMMITTED
timezone=CET
tmp_table_size=33554432
tmpdir=/tmp/
version=3.23.52-log
wait_timeout=28800

Bei der verwendeten MySQL 3.23 kann man fehlerhaftes Encoding beim DB IO wohl ausschließen.

tjoar, es funktionierte auch Alles 1,5 Jahre und dann gingen auf einen Schlag diese Probleme los und ich konnte sie bis heute nicht lösen. Wir hatten ungefähr zu der Zeit, als das Problem auftrat das Problem, dass jemand unser PHPBB Forum gehackt hatte. Na ja, er hatte sich halt Admin-Rechte verschafft und ne Weiterleitung eingerichtet. Nix groß Schlimmes. Mit einem Dump eines MySQL Backups war der Schaden innerhalb von ein paar Stunden nach Analyse behoben. Eventuell wurde bei diesem Hack aber irgendetwas futsch gemacht. Keine Ahnung ...

Irgendwie kann ich mir halt auch nicht so ganz vorstellen, dass es nicht möglich ist den Fehler zu finden und das Problem zu beheben ....

Also ich kenn das Problem nur, wenn die PHP/HTML-Dateien ansich mit UTF8 kodiert sind. Deswegen muss ich im Kate immer auf ISO umstellen; dann funktionierts auch mit den Umlauten!

Das Problem was du dabei haben wirst - wenn du jede Datei mit nem Editor öffnest und da das Charset umstellst, dann musst du im Editor auch jeden Umlaut per Hand editieren

hmm, das hab ich auf jeden Fall noch nicht geprüft. Wobei mir nicht ganz klar ist, warum sich die Kodierung der bereits vorhandenen Files geändert haben sollte. Aber ich werd das auf jeden Fall mal prüfen.

Gibt es ein Bash Command, mit welchem man die Kodierung einer Datei anzeigen kann? Dann würd ich mir das direkt auf dem Server ansehen, damit da nicht ein FTP-Programm etwas umbiegt ...

Was Du eventuell auch noch tun könntest, wäre in den Eingabeformularen
zu setzen. Denn es könnte auch an einer Browsereinstellung liegen, sofern der Browser auf UTF-8 eingestellt wäre. Obwohl Du ja sagst, dass der Fehler von Betriebssystem und Browser unabhängig ist.

ja, also ich konnte zumindest bisher keine Systematik feststellen ... Das mit dem accept-charset hatte ich auch gefunden und hab das jetzt mal testweise in 2 Formulare eingesetzt. Die Zeit wird zeigen, ob das etwas hilft. Wobei das natürlich auch nur ein Workaround ist ... Lieber wäre mir wenn allgemein das Problem behoben werden könnte, denn in alle Formulare (Forum, Blog etc.) die auf dem Server laufen das Attribut einzufügen ist natürlich auch erstmal etwas aufwendig ...

Ja, aber letztendlich, wenn ein Browser mit UTF-8 codierten Text übermittelt, bekommt die Datenbank das so. Ist die Datenbank dann auf ISO-8859-1 eingestellt, werden in den Tabellen wirre Zeichen statt Umlauten eingetragen. Also macht es schon Sinn gleich beim Formular für die richtige Codierung zu sorgen.

ja, das ist vollkommen richtig. Nur leider wird das bei den meisten OpenSource Geschichten anscheinend nicht gemacht, was dann immer Arbeit für mich bedeutet ...

also es will und will nicht werden. Die Scripts sind richtig in ISO-8859-1 gespeichert. LC_ALL etc. hab ich jetzt auf de_DE gesetzt. Alle weiteren Teile PHP, HTTPD, Mysql sind auf ISO-8859-1 bzw. latin1 eingestellt. Aber es will und will nicht richtig gehen. Immer wieder werden Zeichen sporadisch als UTF-8 in der DB gespeichert.

Hat nicht noch jemand eine Idee? Oder kann mir jemand sagen wie ich das Problem noch weiter eingrenzen kann? Kann ich das irgendwie debuggen oder Stück für Stück verfolgen wo die Zeichen umgedreht werden?