Umlaute in Beitrag

[knecht]

Ich benutze phpBB3, und habe nach einem Serverumzug Probleme mit neuen Beiträgen. Alle alten Beiträge stimmen, wenn ich aber einen neuen schreibe erhalte ich komisches verhalten bei den Umlauten. Nicht der Umlaut selbst, sondern nachfolgende Zeichen sind zerstört.

Hier ein Beispiel:
http://www.neoberserker.de/phpBB3/viewt ... 418#p13418

Wenn ich mir einen Datenbankdump hole, und per Konsole anschaue wurde der Text dort auch so gespeichert:

Code: Alles auswählen

... Jetzt, drei Jahre spä��ntsteht wieder eine äh�i�e�tuation. US Lobbisten versuchen nun erneut ...

Der vorherige Server war ein Ubuntu 8.04, jetzt läuft es auf einem Ubuntu 10.04. Ich weiß gerade nicht wie ich mich dem Fehler nähern soll.

Hat jemand dazu eine Idee? Danke.

[Mahony]

Hallo
Siehe dazu Die Umlautproblematik. Da wird dir alles wichtige zum Thema erklärt.

Grüße: Mahony

[knecht]

Vielen Dank, das hat schonmal Überblick gebracht. Ich denke mein Problem liegt in unterschiedlichen Encodings, eines ist mir aber noch unklar.

Wer sind die Akteure? Die Kette sieht quasi so aus:

Code: Alles auswählen

Browser des Clients   <-->    Apache2  <--> PHP auf dem Server   <-->  MySQL

MySQL nimmt das Encoding, das der Client anfordert. Das ist in diesem Fall php, richtig?

Für PHP sind aber die Encoding Einstellungen auf beiden Servern gleich:

Alter Server:

Code: Alles auswählen

~# php -i | grep -i encoding
iconv.input_encoding => ISO-8859-1 => ISO-8859-1
iconv.internal_encoding => ISO-8859-1 => ISO-8859-1
iconv.output_encoding => ISO-8859-1 => ISO-8859-1
mbstring.encoding_translation => Off => Off
mbstring.internal_encoding => ISO-8859-1 => no value
SQLite Encoding => UTF-8

Neuer Server:

Code: Alles auswählen

~ # php -i | grep -i encoding
iconv.input_encoding => ISO-8859-1 => ISO-8859-1
iconv.internal_encoding => ISO-8859-1 => ISO-8859-1
iconv.output_encoding => ISO-8859-1 => ISO-8859-1
HTTP input encoding translation => disabled
mbstring.encoding_translation => Off => Off
mbstring.internal_encoding => no value => no value

Also zum Apache, was ist dort eingestellt:

Alter Server:

Code: Alles auswählen

# fgrep -iR AddDefaultCharset /etc/apache2/
/etc/apache2/conf.d/charset:# Read the documentation before enabling AddDefaultCharset.
/etc/apache2/conf.d/charset:#AddDefaultCharset UTF-8
/etc/apache2/mods-available/proxy.conf:                AddDefaultCharset off
/etc/apache2/mods-enabled/proxy.conf:                AddDefaultCharset off

Neuer Server:

Code: Alles auswählen

# fgrep -iR AddDefaultCharset /etc/apache2/
/etc/apache2/conf.d/charset:# Read the documentation before enabling AddDefaultCharset.
/etc/apache2/conf.d/charset:#AddDefaultCharset UTF-8
/etc/apache2/mods-available/proxy.conf:                AddDefaultCharset off
/etc/apache2/mods-enabled/proxy.conf:                AddDefaultCharset off

Als Charsets sind in beiden Servern alle möglichen eingestellt (AddCharset), auch UTF-8 und ISO-8859-1


Also dürfte Apache und PHP nicht anders agieren als auf dem alten Server. Während des übertragen der Daten ist auch nichts falsch gelaufen, ich habe einen mysqldump auf dem alten Server erstellt, und auf dem neuen wieder eingespielt (per Konsole). Beide Konsolen haben eine locale Einstellung für UTF-8, alle kopierten Dateien und Templates sind ohne Probleme auf den neuen Server gelandet.

Wo liegt dann der Fehler? Apache zu Client Kommunikation? Hat jemand noch einen Tip

[Mahony]

Hallo
Schau erstmal nach, in welchem Zeichensatz die Datenbank die Daten erwartet.

Das bekommst du durch Eingabe des SQL-Befehls

Code: Alles auswählen

SHOW VARIABLES LIKE 'character_set%';

heraus (oder eben direkt im Mysqldumper, so wie im verlinkten Artikel beschrieben).

In der Ausgabe schaust du dann, was bei character_set_client und bei character_set_connection steht.

Das ist dann der benötigte Zeichensatz.

Davon interessieren uns vor allem die Einträge zu character_set_client und character_set_connection, die in der Regel gleich sind.
Hier steht in welchem Zeichensatz Daten vom Client erwartet und geliefert werden, wenn nichts anderes vereinbart wird (der "Client" ist in dem Falle sinngemäß das Programm/Script, welches die Verbindung zum MySQL-Server aufbaut).

Die anderen Werte können wir getrost vernachlässigen - egal, was da steht.
MySQL wandelt alle Daten aufgrund der Verbindungskennung in den entsprechenden Zeichensatz um wenn dies nötig ist.
Uns kann völlig egal sein, welchen Standardzeichensatz die Datenbank hat oder wie MySQL intern (character_set_system) Daten abspeichert. MySQL orientiert sich bei der Annahme und Ausgabe von Daten an der Kodierung der Verbindungskennung und wandelt alles selbstständig intern. Hier brauchen wir uns überhaupt gar keine Gedanken machen: wenn die Verbindungskennung auf utf8 steht, dann bekommen wir auch utf8-kodierte Daten und müssen ebenso utf8-kodierte Daten senden.
Punkt - Ende - aus.

P.S. Eine weitere Fehlerquelle könnte hier liegen

Code: Alles auswählen

HTTP input encoding translation => disabled

Also aktiviere das einfach mal testweise.




Grüße: Mahony

[knecht]

Die beiden Werte stehen auf latin1, da php auf ISO-8859-1 steht sind die sich einig.

Code: Alles auswählen

mysql> SHOW VARIABLES LIKE 'character_set%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Ich habe mit mysqldump per Konsole einen Dump erzeugt, und mir mal genauer angeschaut. Folgendes ist mir aufgefallen:

Code: Alles auswählen

  .
  .
  .
/*!40101 SET NAMES utf8 */;
  .
  .
  .
--
-- Table structure for table `phpbb_acl_groups`
--

DROP TABLE IF EXISTS `phpbb_acl_groups`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `phpbb_acl_groups` (
  .
  .
  .
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
/*!40101 SET character_set_client = @saved_cs_client */;

Interpretiere ich das richtig, das der Dump die defaults von mysql durch die Zeile character_set_client = utf8 überschreibt? Sollte ich das in dem Dump mal alles durch latin1 ersetzen, und wieder einspielen?

Da es ein laufender Server ist würde ich ungern zu viel experimentieren, deswegen Frage ich anstatt es einfach zu machen

[Mahony]

Hallo

Interpretiere ich das richtig, das der Dump die defaults von mysql durch die Zeile character_set_client = utf8 überschreibt?

Ja, sieht ganz so aus. Am besten ist es, wenn du das

Code: Alles auswählen

/*!40101 SET character_set_client = utf8 */;

und das

Code: Alles auswählen

ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin

bei allen Vorkommen heraus nimmst.
MYSQL sollte das dann intern richtig regeln.

Wenn du ganz sicher gehen möchtest, erstellst du das Backup mit dem Mysqldumper und spielst es auch wieder mit dem Mysqldumper ein.

Achtung: Bereits fehlerhaft (falscher Zeichensatz) in der Datenbank gespeicherte Inhalte, werden damit natürlich nicht korrigiert.

Grüße: Mahony

[knecht]

Die beiden Einträge habe ich entfernt, und dem Dump wieder eingespielt. Das Problem bleibt bestehen.

Mit folgendem Skript habe ich meinen Dump konvertiert:

Code: Alles auswählen

#!/bin/bash

if [ ! -e "$1" ]; then
        echo
        echo "Parameter fehlt. Pfad zur Datei angeben, deren SQL von UTF-8 codierungen befreit werden soll."
        echo
        exit 1
fi

OUT="cleaned_$1"

sed  s/'\/\*\!40101 SET character_set_client = @saved_cs_client \*\/\;'/''/g  $1 > $OUT
sed  s/' DEFAULT CHARSET=utf8 COLLATE=utf8_bin'/''/g -i $OUT

Ich habe testweise auch diese beiden Muster mal entfernt, und den Dump eingespielt

Code: Alles auswählen

/*!40101 SET character_set_client = utf8 */;
/*!40101 SET NAMES utf8 \*\/\;

In diesem Fall sind alle alten Encodings auch zerschossen (was ja auch sinn macht)

Ich habe jetzt den Dump mit den beiden von dir geschriebenen Zeilen entfernt eingespielt, aber das Problem bleibt bestehen (natürlich hab ich auch mal in den Dump geschaut ob wirklich alles raus ist.)

[Mahony]

Hallo

Ich würde mir die Sache einfach machen und den Mysqldumper benutzen, denn der sichert dir das Backup im richtigen Zeichensatz und spielt dir das Backup auch wieder im richtigen Zeichensatz ein.
Damit wären dann die Datenbank-Probleme schon einmal ausgeschlossen.
An den Standard-Einstellungen des Mysqldumpers, solltest du übrigens nichts ändern (der regelt das ganze selbstständig).

Edit: Ich habe mich mal in deinem Board angemeldet und wie es aussieht, werden die seltsamen Verunstaltungen bereits vor dem Eintragen in die Datenbank verursacht (das sieht man, wenn man die Vorschau benutzt).
Es handelt sich auch nicht wirklich um die Umlaute, denn die Texte werden nach den Umlauten verunstaltet.
Beispiel aus deinem Forum (Vorschaufunktion)

Jetzt, drei Jahre spä�r entsteht wieder eine äh�che Situation.

Die Umlaute selbst sind vorhanden, allerdings werden spätere Buchstaben verunstaltet.
Es liegt wahrscheinlich ein ähnliches Problem wie hier vor viewtopic.php?t=154271

Überprüfe also deine mbstring-Erweiterung/Einstellung/en (php.ini)

Erforderlich – mbstring ist eine PHP-Erweiterung, die Unterstützung für Multibyte-Zeichenketten zur Verfügung stellt. Bestimmte Funktionen von mbstring sind nicht mit phpBB kompatibel und müssen deaktiviert werden.
Überladen von Funktionen:
mbstring.func_overload muss entweder 0 oder 4 sein.

Transparente Zeichenkodierung:
mbstring.encoding_translation muss 0 sein.

HTTP-Eingabe-Kodierung:
mbstring.http_input muss pass sein.

HTTP-Ausgabe-Kodierung:
mbstring.http_output muss pass sein.

Weitere Hilfe: http://www.dynamic-webpages.de/php/ref.mbstring.php


P.P.S. Im übrigen stimmen deine Einstellungen zu Server und Domain (Scriptpfad) bzw. Cookie anscheinend nicht - das solltest du ebenfalls mal überprüfen.

Grüße: Mahony

[knecht]

Das war der Fehler, vielen Dank !

P.P.S. Im übrigen stimmen deine Einstellungen zu Server und Domain (Scriptpfad) bzw. Cookie anscheinend nicht - das solltest du ebenfalls mal überprüfen.

Das gilt es auch noch zu lösen, mir war das Encoding aber erstmal wichtiger. Praktisch bedeutet das ja, das ein eingeloggt bleiben per Cookie nicht möglich ist. Im Moment muß ich mich nach jeden schliessen des Firefox neu anmelden, und er hält die session nur über die sid Variable.

Der Scriptpfad ist .neoberserker.de, meine Domain ist http://www.neoberserker.de. Wenn ich mir ein Cookie anschaue dann passt der Pfad auch, nur ist es komisch das das Datum der Cookies in der Vergangenheit liegt (Ich habe bei Gültigkeit der Cookies 0 Eingetragen).

Beispiel: Ich logge mich am 15.10.2010 um 13:10Uhr ein, das Cookie hat dann das Datum Mon, 10 Oct 2011 11:05:18 GMT.

Der Server selbst hat die passende Uhrzeit: (per ssh auf Konsole ausgeführt)

Code: Alles auswählen

# date
Fri Oct 15 13:07:22 CEST 2010

In /etc/php5/apache2/php.ini habe ich die Zeitzone eingetragen:

Code: Alles auswählen

date.timezone = Europe/Berlin

Sonst habe ich keine date Einstellungen in der Datei.

Hast du eine Ahnung was das Problem ist mit den Cookies? Danke.

[Mahony]

Hallo

Poste mal die Ausgabe dieses Scripts --> read_cookie_settings - Script zum setzen von Server und Cookie Einstellungen

Grüße: Mahony