Chinesisch (utf-8) läuft auf Kundenserver nicht

[daniello1]

Hallo Leute,

ich habe grad meine erste fünfsprachige Website mit Contenido 4.8.12 erstellt und habe Probleme mit der chinesischen Version auf dem Kundenserver. Auf meinem eigenen Webserver in der chinesischen Sprache mit Encoding utf-8 läuft alles wunderbar und die Zeichen werden richtig angezeigt. Auf dem Kundenserver wird mir bei identischen Einstellungen (bin ich zumindest der Meinung) nur Buchstabensalat angezeigt. Hat jemand schon mal soetwas gehabt? Habe auch in der Datenbank sämtliche encodings der Tabellen abgeglichen etc. und nichts gefunden. Gibt es da serverseitige Umgebungsvariablen, die gegeben sein müssen? Hab sonst keine Idee mehr.... Über Hinweise würde ich mich freuen...

Vielen Dank für Eure Hilfe vorab.

Grüsse
Daniel

[kummer]

Encoding der DB-Verbindung hast du auch angeschaut?

[thepoet]

你好,

bei UTF8-Problemen arbeite ich eigentlich immer die selbe Checkliste ab:

• Encoding in der Datenbank(-tabelle/-spalte)
• Encoding (wie von kummer erwähnt) der Verbindung (bringt ein vorausgeschicktes "SET NAMES 'utf8'" was?)
• Charset- bzw. Content-Type-Header des Webservers
• Meta-Tags im HTML
• Datenbank-Inhalte noch mal genau prüfen (mittels 'mysqldump -r ausgabedatei.sql' rausladen, was diverse graphische Tools anzeigen ist nicht immer verlässlich)

Irgendwo in dieser Kette liegt dann auch der Fehler.

[daniello1]

Hallo,

vielen Dank für Eure Antworten. Also, hab nochmal mit phpMyAdmin auf dem Kundenserver folgendes überprüft:

Zeichensatz /Kollation der MySQL-Verbindung: utf8_unicode_ci

Die Kollation sämtlicher Tabellen sowohl auf dem System wo es korrekt angezeigt wird, alsauch auf dem System, wo es nicht korrekt lauft: latin1_general_ci / latin_swedish_ci

Ich habe folgendes getestet. Selbst wenn ich die betreffenden Tabellen z.B. con_cat_lang für die Navi und das Feld name auf utf-8 ändere, tut sich nichts. Hab das auch mit der con_code getestet. Ebenfalls keine Veränderung.

In den Metatags steht folgendes:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Was hat es mit dem "SET NAMES 'utf8'" auf sich? Das sagt mir leider nichts. Wo muss ich dies einfügen?

Ich verstehe auch nicht, warum es bei identischen Einstellungen auf einem System funktioniert und auf dem anderen nicht. Kann da der Fehler nicht nur beim Export/Import bzw Anlegen der Datenbank passiert sein?

Kann ich eigentlich Inhalte nur einer Sprache aus der Datenbank exportieren? Auf dem Kundensystem sind leider die anderen Sprachen schon wieder zwischenzeitlich modifiziert worden.

Danke für Eure Mühe.

Daniel

[daniello1]

So, ich denke, dass ich den Grund für die unterschiedliche Darstellung in den Variableneinstellungen gefunden habe:

Eigener Server:
collation connection utf8_unicode_ci
(Globaler Wert) latin1_swedish_ci
collation database latin1_swedish_ci
collation server latin1_swedish_ci

Kundenserver:
collation connection utf8_unicode_ci
(Globaler Wert) utf8_general_ci
collation database utf8_general_ci
collation server utf8_general_ci

Ich frage mich jetzt nur, was alles ich auf utf8_general_ci umstellen muss, damit es auch auf dem Kundenserver läuft?

Habe jetzt die Datenbank, erstmal Tabelle con_code, con_cat_lang sowie die Felder inerhalb auf utf8_general_ci umgestellt. Aber es ändert sich leider immer noch nichts an Navi und Content... Und an die Serverkonfiguration komme ich nicht dran.

[daniello1]

Habt Ihr noch einen Tipp für mich, wie ich weiter vorgehen kann?

[thepoet]

Erstmal: "SET NAMES 'utf8'" ist ein SQL-Kommando, das die Verbindungs- und Clienteinstellungen bezüglich des Charsets in einem Rutsch setzt. Das ließe sich z.B. in die conlib/db_mysql.inc einbauen (vor der Rückgabe in function connect(...), bei mir Zeile 116):

Code: Alles auswählen

    $this->query("SET NAMES 'utf8'");
    return $this->Link_ID;
}

Wenn die Charsets/Collations auf beiden Servern soweit gleich eingestellt waren, dann lag der Fehler aber wohl irgendwo beim Im-/Export. Hast du den Export mit dem phpMyAdmin oder dem Kommandozeilen-Client vorgenommen? Wenn letzteres, dann kann hier natürlich ein anderes Charset als via Web verwendet worden sein. Was auch ganz oft Fehler produziert ist, wenn ein Kommandozeilendump in eine Datei gedumpt wird (mysqldump -u bla blubb > dump.sql). Dann schlägt auch noch die Zeichensatzeinstellung der Shell/Cmd zu, das lässt sich aber durch das Angeben der Ausgabedatei als Parameter (mysqldump -r dump.sql ...) umschiffen.

Mal ein Lösungsversuch: Die enthaltenen Daten sind eigentlich UTF8, werden aber vermutlich als latin1 behandelt. Also müssten sie als latin1 geparst werden, ein Binary-Flag bekommen, damit MySQL sie danach nicht mehr zurückkonvertiert und zum Schluss als UTF8 wieder in die Tabelle eingefügt werden. Das Script hier sollte das für die con_cat_lang machen:

Code: Alles auswählen

CREATE TABLE con_cat_lang_test (
  idcatlang int(10) NOT NULL default '0',
  idcat int(10) NOT NULL default '0',
  idlang int(10) NOT NULL default '0',
  idtplcfg int(10) NOT NULL default '0',
  name varchar(255) NOT NULL,
  visible tinyint(1) NOT NULL default '0',
  public tinyint(1) NOT NULL default '0',
  status int(10) NOT NULL default '0',
  author varchar(32) NOT NULL,
  created datetime NOT NULL default '0000-00-00 00:00:00',
  lastmodified datetime NOT NULL default '0000-00-00 00:00:00',
  startidartlang int(10) NOT NULL default '0',
  urlname varchar(64) NOT NULL,
  PRIMARY KEY  (idcatlang),
  KEY idcat (idcat),
  KEY idcatlang (idcatlang),
  KEY idlang (idlang),
  KEY idtplcfg (idtplcfg),
  KEY idlang_2 (idlang,visible),
  KEY idlang_3 (idlang,idcat)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

INSERT INTO con_cat_lang_test
SELECT * FROM con_cat_lang;

UPDATE con_cat_lang_test
SET name = CONVERT(
  CONVERT(
    CONVERT(
      name USING latin1
    ) USING binary
  ) USING utf8
);

RENAME TABLE con_cat_lang TO con_cat_lang_orig,
             con_cat_lang_test TO con_cat_lang;

Falls das nicht hilft, kannst du ja jederzeit mittels

Code: Alles auswählen

RENAME TABLE con_cat_lang TO con_cat_lang_test,
             con_cat_lang_orig TO con_cat_lang;

DROP TABLE con_cat_lang_test;

zurückswitchen und die Testtabelle verwerfen.

[daniello1]

Vielen Dank für Deine Antwort.

Also wenn ich in der db_mysql.inc den Eintrag SET NAMES 'utf8' tätige, dann bekomme ich einen Internal Server Error:
The server encountered an internal error or misconfiguration and was unable to complete your request.

Der Export und Import wurde jeweils über phpMyAdmin erledigt. Da sollte auch der Fehler nicht liegen...

Der Fehler liegt wohl eher in den unterschiedlichen Servereinstellungen:

Eigener Server: (wo es richtig angezeigt wird)
character set client utf8
(Globaler Wert) latin1
character set connection utf8
(Globaler Wert) latin1
character set database latin1
character set filesystem binary
character set results utf8
(Globaler Wert) latin1
character set server latin1
character set system utf8
character sets dir /usr/local/share/mysql/charsets/
collation connection utf8_unicode_ci
(Globaler Wert) latin1_swedish_ci
collation database latin1_swedish_ci
collation server latin1_swedish_ci

Kundenserver: (wo es Buchstabensalat gibt)
character set client utf8
character set connection utf8
character set database utf8
character set filesystem binary
character set results utf8
character set server utf8
character set system utf8
character sets dir /usr/share/mysql/charsets/
collation connection utf8_unicode_ci
(Globaler Wert) utf8_general_ci
collation database utf8_general_ci
collation server utf8_general_ci

Auf den Kundenrechner habe ich keinen Zugriff, da es sich auch nur um ein virtuellen Host bei einem Provider handelt.

Ich weiß leider jetzt nicht genau wie ich fortfahren soll oder ob die von Dir beschriebenen Lösungsansätze hier Sinn machen.

[thepoet]

Also wenn ich in der db_mysql.inc den Eintrag SET NAMES 'utf8' tätige, dann bekomme ich einen Internal Server Error:
The server encountered an internal error or misconfiguration and was unable to complete your request.

Sorry, da müssen die Quotes um 'utf8' raus, mein Fehler.

Der Export und Import wurde jeweils über phpMyAdmin erledigt. Da sollte auch der Fehler nicht liegen...

Niemals ganz auszuschließen, auch phpMyAdmin ist nicht unfehlbar und trifft manchmal auch Annahmen, die spezifisch zur Serverversion sind.

Auf den Kundenrechner habe ich keinen Zugriff, da es sich auch nur um ein virtuellen Host bei einem Provider handelt.

Ich weiß leider jetzt nicht genau wie ich fortfahren soll oder ob die von Dir beschriebenen Lösungsansätze hier Sinn machen.

Kaputt machen kannst du eigentlich nichts, denn alle Operationen erfolgen auf einer Kopie der Tabelle. Wenn du dich nicht ganz traust, dann schnapp dir einfach mal einen Eintrag in der con_cat_lang mit einem Kategorienamen mit (chinesischen) Sonderzeichen und führ die Konvertierung nur für eine Zeile aus:

Code: Alles auswählen

UPDATE contenido.con_cat_lang
SET name = 
CONVERT(
  CONVERT(
    CONVERT(name USING utf8)
    USING BINARY
  )
  USING latin1
)
WHERE idcatlang = DEINEGENAUEIDCATLANG

Wenn der Kategoriename danach im Menü richtig erscheint, dann war das auch das Problem, und es ist dann sicher auch möglich die Konvertierung nur für diese eine Sprache durchzuführen.

[daniello1]

Hab eben sämtliche relevanten Felder für Navi, Content etc. in den Tabellen auf utf-8 umgestellt und die Inhalte von Testsystem per Copy & Paste rüberkopiert. Jetzt werden die chinesischen Zeichen richtig angezeigt.

Vielen Dank für die Hilfe.