Notice: Undefined index: mysql_can_change_encoding

**Donator** Joined: 03 Jan 2009 Posts: 8

Hallo,

nach einem Umzug von Webspace auf einen Rootserver (Hetzner DS3000) kämpfe ich damit mein vbulletin wieder in Gang zubekommen.

Beim arbeiten mit Mysqldumper ist mir zum einen beim SQL-Browser folgende Meldung aufgefallen:

Notice: Undefined index: mysql_can_change_encoding in /var/www/localhost/htdocs/sqldumper/inc/functions_global.php on line 1038

Das ist das eine, mein Hauptproblem liegt aber in einer (hier so oft besprochenen) Umlautproblematik.

Obwohl auf dem Webspace und dem Server die selben Verbindungen:

character_set_client utf8
character_set_connection utf8

laut mysqldumper eingestellt sind, erhalte ich die Umlautproblematiken.

Hat jemand eventuell eine Idee dazu?

*Anmerken muss ich das der Server (Apache & SQL unter Gentoo frisch installiert sind und es auch an dortigen sonstigen Einstellungen liegen könnte. Dieses entzieht sich aber meinem Wissen*

LG Soidberg

Posted: 2009-01-03, 13:47 (No subject)

Hm, die Variable wird eigentlich bei jeder Verbindung zur DB gesetzt.
Welche Seite hast Du aufgerufen, als die Meldung erschien?

**Donator** Joined: 03 Jan 2009 Posts: 8

Beim Klick auf "SQL-Browser"

LG Soidberg

Posted: 2009-01-03, 16:16 (No subject)

Direkt auf der Startseite oder hast Du bereits eine Aktion ausgelöst und im SQL-Browser irgendwo geklickt??

Bezüglich Deiner Umlautprobleme - welche Server-Version hatte der Server von dem Du das Backup gemacht hast? Ist es mit MySQLDumper angelegt owrden oder mit einem anderen Programm?
Hast Du mein Korrektur-Tool DUK bereits ausprobiert?

**Donator** Joined: 03 Jan 2009 Posts: 8

Hy Daniel,

der Fehler kommt direkt beim klicken auf den Button. Also Home-->SQL-Browser (Button / Menü)

Das Backup habe ich mit MySQLDumper 1.23 (tagesaktuell) gezogen. Anbei mal die Serverdaten:

Webspace Vorher:

Server OS/PHP Linux (Safe Mode)

Webserver Apache
PHP 4.4.9

PHPs max. Post-Größe 8,00 MB

PHPs maximale Uploadgröße 8,00 MB

PHPs Speicherlimit 32,00 MB

MySQL-Version 5.0.32-Debian_7etch6-log

MySQL Paketgröße 16,00 MB

Server nachher:

Server OS/PHP Linux

Webserver Apache

PHP 5.2.8-pl1-gentoo

PHPs max. Post-Größe 8,00 MB

PHPs maximale Uploadgröße 2,00 MB

PHPs Speicherlimit 128,00 MB

MySQL-Version 5.0.70

MySQL Paketgröße 1,00 MB

DUK habe ich auch schon drüber laufen lassen, mit 28 Funden, die alle beseitigt wurden. Das Problem bleibt allerdings...

LG Soidberg

Posted: 2009-01-03, 16:36 (No subject)

Hm, ich kann Dein Problem technisch nicht nachvollziehen. Die Funktion, die den Fehler bei Dir verursacht, wird nur dann ausgeführt, wenn die Kodierung zur DB nicht ermittelt werden kann. Und das ist bei MySQL 5 nicht der Fall. Inosfern stehe ich gerade etwas auf dem Schlauch.

Kannst Du mir einen temporären FTP-Zugang zu Deinem Server geben, damit ich das dort direkt debuggen kann?

Ich gehe davon aus, dass Du eine aktuelle Revision der 1.23 benutzt.

**Donator** Joined: 03 Jan 2009 Posts: 8

Posted: 2009-01-03, 16:49 (No subject)

**Donator** Joined: 03 Jan 2009 Posts: 8

Du hast eine Mail bekommen.

LG Soidberg

Posted: 2009-01-03, 23:42 (No subject)

So, die Ausgabe habe ich in den Griff bekommen. Die Meldung bleibt nun aus.

Deine Datenbankdaten sind sauber. Dort sind die Umlaute korrekt kodiert abgelegt. Dein Problem liegt auf der Ausgabeseite des Forums. Dort wird ein iso 8859-1 Header gesendet, obwohl danach utf8-Daten folgen. Das ist eine Einstellungssache in der Forensoftware. Wenn Du die Anzeige im Fourm im Browser händisch auf utf8 umstellst, wird alles korrekt angezeigt.

Öffne im Adminbereich des vb das Header-Template und ersetze dort iso-8859-1 durch utf-8, dann müsste es gehen. Ich hatte das gleiche Problem in einem vb. Dort ist das Steuern von Kodierungen ziemlich unglücklich gelöst. Ich hatte auch mal vor auf vb umzusteigen, habe mir eine Lizenz gekauft und bin dann ziemlich entsetzt gewesen, als ich den Code gesichtet und fest gestellt habe, dass die Software die Kontrolle über Kodierungen von Daten und dem Senden von entsprechenden Headern nicht vollständig übernimmt. Wenn man die Datenbank auf utf8 umstellt, muss man das in den Templates ebenso anpassen. Auch beim Import von Modulen via XML-Dateien wird immer davon ausgegangen, dass die XML-Datei utf8-kodiert vorliegt - unabhängig davon, welche Kodierungs-Angabe in der ersten Zeile der XML-Datei tatsächlich gemacht wird. Das Konzept ist hier im vb noch ziemlich lückenhaft. Es ist nicht möglich verschiedene Templates mit unterschiedlichen Kodierungen zu fahren. Zumindest war das der Stand vor knapp einem Jahr.

Deshalb ist dieses Forum hier auch immer noch ein altes, aber gut funktionierendes Orion und kein vb. Wink

**Donator** Joined: 03 Jan 2009 Posts: 8

Hy, vielen Dank für Deine Erklärung.

...ja ich kann den Header umbiegen auf utf-8. Das ergibt auch ein sauberes Bild..nur:

Vorher auf dem Webspace musste ich diese Einstellung nicht vornehmen. Ist es nicht so das wenn ich ein Backup ziehe und einspiele das dann ein identisches Bild da sein muss? Also Backup erstellt und eingespielt, mehr ist nicht verändert worden....

*Ich habe bisher sehr gut ohne utf-8 gelebt (also das Board) und brauche es auch nicht wirklich. Macht es dann nicht Sinn utf-8 aus Sicht des vb den Rücken zu kehren und die Daten per Latin1 einzuspielen?

Eventuell mal die Datenbank auf dem Webspace (Urzustand) sichten ... ,der Unterschied will sich mir einfach nicht erklären.

LG Soidberg

Posted: 2009-01-04, 00:39 (No subject)

Das hat hier überhaupt nichts mit der Datenbank zu tun. Die ist sauber.

Hier liegt es am gesendeten Header der Webseite. Ich kann Dir das nicht in 2 Sätzen erklären. In der nächsten Ausgabe der Zeitschrift Internet Magazin wird ein Artikel von mir darüber veröffentlicht.
Kurzform: es gibt einen Standardparameter im Server (AddDefaultCharset), der verwendet wird, wenn die Webieite keinen eigenen Header sendet (und damit ist nicht die Meta-Tag Angabe im HTML-Code gemeint). Dieser wird auf dem neuen Server anders eingestellt sein.

**Donator** Joined: 03 Jan 2009 Posts: 8

ja, soweit verstehe ich es. Habe vb auch jetzt befohlen utf-8 zu nehmen und es läuft ja jetzt auch.

Nur wieso läuft es auf dem Webspace (wenn die Daten identisch sind in der Datenbank) ohne das ich vb dazu zwinge. Dort steht es auf ISO und hat auch keinerlei Fehler....

Deinen Artikel habe ich bereits mehrfach gelesen, gerade des halb interessiert es mich ja. Ich möchte ja nur verstehen wieso es auf dem Webspace ohne läuft und auf dem Server nur mit dieser "Umstellung".

Ich musste auch noch nie eine .xml (Addondatei / vb) in utf-8 per Textpad ändern, bisher bin ich der Meinung das wir kein UTF-8 am laufen haben.

Wieso ist es jetzt utf-8 oder anders herum, wieso lief es vorher?

Lg Soidberg

Posted: 2009-01-04, 00:55 (No subject)

**Donator** Joined: 03 Jan 2009 Posts: 8

Super, unsere Nachrichten (EMail, Posting( haben sich gerade überschnitten sorry.

Das bedeutet, wenn ich den Header wieder umstelle dann sollte es auch das identische Ergebnis bei rum kommen!!

Ich werde sofort berichten sobald ich die Einstellungen befunden habe...

LG Soidberg