Zeichensatz suse 11.2 64bit

[ak666]

Hi Community,

ich habe im Netz 2 Root-Server, auf denen ich Game-Server und ne HP betreibe.
Einen der Roots will ich abstellen, da nicht mehr benötigt wird.
Dieser Root ist ein Suse 11.1 32bit.
Der andere Root ist ein Suse 11.2 64bit.
Ich hab ein kleines php-Script geschrieben, welches die Nicknames von Nutzern aus unserem Forum ausliest und in eine Datei schreibt.
Ich habe BEIDE Dateien auf dem 64bit-Server mit vi geöffnet:

Die Datei vom 32-er System:

Da sehen die Sonderzeichen alle wunderbar aus.

Die Datei vom 64-er System:

Das sieht nicht mehr so schön aus.

Es ist alles auf UTF-8 eingestellt, so denke ich. Die DB, apache2 und putty.
Was mich am meisten wundert-> die Datei vom 32er wird auf dem 64er richtig dargestellt.
D.h. der Server muss über diesen Zeichensatz komplett verfügen.
Habt ihr ne Idee, wie ich das in den Griff kriege?

Gruß

AK

 

[Appleonkel]

Hat soweit nix mit der Installation, Deinstallation von Paketen zu tun.
Mit

file

kannst du überprüfen ob die Dateien den gleichen Zeichensatz haben, und mit

iconv

kannst sie umwandeln. Trotzdem falsches Forum

 

[panamajo]

Könnte doppeltes UTF-8 sein.
Mach mal einen Dump der Tabelle mit den Usernamen und öffne diesen mit einem Editor der UTF-8 kann (auf einem Rechner ohne Darstellungsprobleme). Stimmen dort die Nicks?

 

[ak666]

Hi,

beide dateien sind utg8 eng text.
Und nein, die nicks stimmen nicht.
Ich habe das php-Script jetzt mit einem utf8_decode versehen.
Auf dem 64er bringt das: ¢ĥэŦ▒?▒?
Auf dem 32er war schon utf8_decode drin (ooops).
Anscheinden hat der 64er nicht alle Zeichen.
Sind das fehlende Installationen oder ist dem System das zuviel rumkodiererei?

Gruß

 

[panamajo]

Und nein, die nicks stimmen nicht.

Dann hast du mit großer Wahrscheinlichkeit doppelt Encodetes UTF-8 in der DB. Und ein Problem.

Ich habe das php-Script jetzt mit einem utf8_decode versehen.

D.h. du wandelst alles was die DB ausspuckt per PHP Funktion utf8_decode() um? Das wird nicht funktionieren.

Auf dem 64er bringt das: ¢ĥэŦ▒?▒?
Auf dem 32er war schon utf8_decode drin (ooops).

Was willst du damit sagen?

Anscheinden hat der 64er nicht alle Zeichen.

Falsch geraten. Vergleiche mal die Ausgabe von MySQL wenn du in der MySQL Shell eingibst:

SHOW VARIABLES LIKE 'c%';

Wenn ich richtig liege wird das alte, scheinbar funktionierende System sagen dass latin1 verwendet wird, das neue utf8.

 

[ak666]

Du liegst richtig.
Ich werde die DB vom neuen Server auf latin1 umstellen, aber erst am we.

Ich danke schon mal, melde mich nach dem Umstellen.

Gruß

AK

 

[panamajo]

Ich werde die DB vom neuen Server auf latin1 umstellen

Ganz schlechte Idee(tm).

Auf dem alten Server hast du UTF-8 encodetes UTF-8, also doppelt. Das kommt daher dass MySQL vor 5.1 als Default für character_set_client weiterhin latin1 hatte. Wenn du dort also UTF-8 Daten schreibst schaut MySQL in seine Metadaten und stellt fest dass die Tabelle ja UTF-8 sein soll und wandelt es um. Beim Lesen das Ganze rückwärts, heraus kommt wieder UTF-8. Nur: in der DB steht zwar valides, aber vollkommen sinnfreies UTF-8. Soweit, so schlecht.

Dein Problem ist nicht dass der neue Server irgendwas falsch macht, der käme mit korrektem UTF-8 zurecht. Dein Problem ist dass der alte es schon immer falsch gemacht hat.

 

[ak666]

hast du denn eine idee, wie ich das problem löse?

 

[panamajo]

EInfache Lösungen wie z.B. einen Dump mit iconv korrigieren funktionieren nicht.

Mit z.B. PHP kann man das korrigieren, allerdings dürfen dabei keine weiteren Zugriffe auf die DB stattfinden:
Du öffnest 2 Verbindungen zur DB auf dem alten Server, eine wie gewohnt (Reader), eine weitere bei der du initial per SET NAMES 'utf8' dem Server mittteilst dass die Daten bereits in UTF-8 sind.

Dann liest du alle Tabellen mit Reader zeilenweise aus und schreibst alle Felder die Text enthalten (VARCHAR, CHAR, TEXT, ..) per Writer wieder rein:

UPDATE table SET field='$field' WHERE id=$pkey

Danach stellst du den alten MySQL Server um als Default UTF-8 zu verwenden:
my.cnf:

init-connect='SET NAMES utf8'

ersatzweise (insbesonders wenn weitere DBs auf dem Server laufen die latin1 benötigen) kann man das auch in der Anwendung setzen (wenn ein DB Wrapper verwendet wurde, wenn an 1000 verschiedenen Stellen MySQL Connects auf- und zugemacht werden hast du Pech).

Dann kannst du einen Dump ohne Änderungen auf den neuen Server übertragen.

ODER du arbeitest auf dem neuen Server (der als Default ja bereits UTF-8 verwendet):

2 Connects, der Reader sorgt per

SET NAMES 'latin1'

dafür dass das doppelte Encoding zu einfachem korrigiert wird, der Writer hat bereits das richtige Encoding, wieder dasselbe: alles auslesen und schreiben.

Das Ganze am besten per CLI da PHP bei der Web SAPI meist eine nicht ausreichende max_execution_time gesetzt hat.
Aufpassen muss man auch bei Feldern die NULL Werte enthalten können, diese sollte man keinesfalls ändern indem man z.B. einen leeren String schreibt.

 

[ak666]

Hmm,

ich habs versucht, bin aber nicht zu einem Ergebnis gekommen.
Werde es aber noch mal versuchen.
Jedoch habe ich Zweifel an deiner Theorie.
Wie kann es sein, dass ein php-Script auf die gleiche DB zugreift, und auf den Roots unterschiedliche Ergebnisse erscheinen?

Script:
<?php
$link = new mysqli("8x.3x.1x.1x","user","passWD","xxxxxxxx");
if($res=mysqli_query($link,"SELECT user_nickname FROM iga_user WHERE user_id = 1")) {
$usr=mysqli_fetch_array($res);
echo $usr['user_nickname']."\n";
}
?>

Ausgabe auf neuem Root: ¢ĥ�ŦғΞ
Mit utf8_decode: ¢ĥэŦ▒?▒?

Ausgabe auf altem Root: ¢ĥэŦғΞ

Das versteh ich immer noch nicht.
Kann ja nicht an der DB liegen, da auf die gleiche Zugegriffen wird.

Gruß

 

[panamajo]

Ausgabe auf neuem Root: ¢ĥ�ŦғΞ
Mit utf8_decode: ¢ĥэŦ▒?▒?

Ausgabe auf altem Root: ¢ĥэŦғΞ

Vergiss utf8_decode. Das wandelt UTF-8 zu Latin1. Was du brauchst ist etwas das Schrott zu UTF-8 wandelt.

Kann ja nicht an der DB liegen, da auf die gleiche Zugegriffen wird.

Aber die Server reagieren auf dieselben SELECTS mit unterschiedlichen Ergebnissen da sie unterschiedlich konfiguriert sind.

 

[ak666]

Aber es kann nicht der DB-Server sein!!!
Es sind 2 unterschiedliche Roots und NUR EINEN DB SERVER!!!!

Gruß

 

[panamajo]

Aber es kann nicht der DB-Server sein!!!
Es sind 2 unterschiedliche Roots und NUR EINEN DB SERVER!!!!

Schau in dein OP und überlege dir was du sinnvollerweise zu den dort geschilderten Settings noch anmerken willst.
Und überlege dir ob du Hilfe willst oder den dicken Max machen. Posts mit mehreren Ausrufungszeichen werden zukünftig ignoriert, klar?