Zeichensatz suse 11.2 64bit

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

Hat soweit nix mit der Installation, Deinstallation von Paketen zu tun.
Mit kannst du überprüfen ob die Dateien den gleichen Zeichensatz haben, und mit kannst sie umwandeln. Trotzdem falsches Forum

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?

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ß

ak666 schrieb:

Und nein, die nicks stimmen nicht.

Zum Vergrößern anklicken....

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

ak666 schrieb:

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

Zum Vergrößern anklicken....

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

ak666 schrieb:

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

Zum Vergrößern anklicken....

Was willst du damit sagen?

ak666 schrieb:

Anscheinden hat der 64er nicht alle Zeichen.

Zum Vergrößern anklicken....

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

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

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

ak666 schrieb:

Ich werde die DB vom neuen Server auf latin1 umstellen

Zum Vergrößern anklicken....

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.

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

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:

Danach stellst du den alten MySQL Server um als Default UTF-8 zu verwenden:
my.cnf:
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
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.

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ß

ak666 schrieb:

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

Ausgabe auf altem Root: ¢ĥэŦғΞ

Zum Vergrößern anklicken....

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

ak666 schrieb:

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

Zum Vergrößern anklicken....

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

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

Gruß

ak666 schrieb:

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

Zum Vergrößern anklicken....

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?