phpBB.de

wobo hat geschrieben:Mal langsam mit solchen voreiligen Schlüssen. Hier läuft PHP in der Version 5.2.4

Ich habe bisher keinen Server erlebt, der utf8_encode nicht kannte, aber man lernt ja nie aus. Ich habe diesbezüglich mal geforscht und herausgefunden, dass dieser Befehl Bestandteil der Extension XML ist. Dir fehlt also diese Extension auf Deinem Server:
http://de3.php.net/xml

DSB hat geschrieben:Dir fehlt also diese Extension auf Deinem Server: http://de3.php.net/xml

Genau das ist es. Auf dem Server ist sie installiert, auf meinem lokalen System nicht. Daher erhalte ich auf meinem lokalen System die Fehlermeldung. Dummerweise hatte ich angenommen, dass die "wichtigen" Extensions mit dem Apache-PHP-Paket mit installiert werden. Ok, wieder was gelernt.

DSB hat geschrieben:Teste das doch mal, indem Du in den HTML-Templates statt des {S_ENCODING...} direkt "UTF-8" eingibst.

Geht im Moment leider nicht, da ich die DB bereits mit den SQL-Befehlen umgeformt habe. Nach dem Wochenende werde ich das Ganze mal im Testbett auf dem Server ausprobieren, da kann ich diesen Test machen (hab mirs notiert).

Da sind noch andere Fragen offen, z.B.:
In allen 3 Systemen (punbb, phpbb2 und phpbb3) ist (vor der Veränderung von heute) der Inhalt der Datenbank in dieser Form abgelegt: "der Bär".
In PunBB wird die korrekte Darstellung ähnlich wie bei phpBB2 mit der Variable $Encoding = 'utf-8' in der Sprachdatei geregelt. Wenn ich da aber in der DB die Umlaute durch die tatsächlichen Buchstaben ersetze, also aus dem "Bär" ein "Bär" mache, bekomme ich anschließend die Umlaute als Kommata angezeigt, also "B,r". Genau das Gleiche passiert in phpbb2, wenn ich in der DB die Zeichen durch Buchstaben ersetze.
Nur in phpbb3 wird aus "Bär" nach der Änderung in "Bär" auch in der Darstellung im Browser ein "Bär".

Das bedeutet doch, dass diese Anweisungen in punbb und phpbb2 nur aus den Sonderzeichen lesbares utf-8 erzeugen, während tatsächlich in der DB vorhandene non-ascii-Zeichen durch ein Komma ersetzt werden.

So langsam fangen meine für dieses Thema relevanten Hirnzellen an, mir dauernd "Don't worry, be happy" zwischen die Denkvorgänge einzuspielen.

Schönes Wochenende!

wobo

ich hatte das oben genannte problem gerade eben.. ich habe die datenbank einfach per latin7 importiert und weg wars.

grüße

Hm, ok. Ist bei mir eigentlich egal. Ob ich nun die DB exportiere und sie dann wieder importiere oder ob ich die SQL-Befehle drüber laufen lasse, beides ist vom Aufwand her gleich.

Ich schrieb vorher im Thread, dass das Anwenden der SQL-Befehle so lange dauerte. Das war dadurch bedingt, dass eine wildgewordene Python-Anwendung (python-coherence) über 90% der CPU belegte und daher für den armen mysqld nur noch ein paar mickerige Prozente übrig blieben.

Habe das heute nochmal durchlaufen lassen, war in insgesamt 10 Minuten mit allen Ersetzungen fertig.

wobo

Das WE ist vorbei, zurück ans Rätselraten:

Ich hatte ja versprochen, die duk.exe auszuprobieren. Ich war also eben bei meinem Bekannten, der Windows XP auf seinem Rechner hat. Habe dort getreu nach Anleitung die Wrapper-Datei editiert und auf den Server hochgeladen. Dann habe ich die duk.exe gestartet. Die Oberfläche erschien, ich habe den URL zum Script eingegeben, das Script wurde gefunden (links unten angezeigt) und es erschien eine Fehlermeldung, dass die MySQL-Version nicht festgestellt werden kann. Es wird als Ursache vermutet, dass die Zugangsdaten nicht korrekt eingegeben wurden.

Also habe ich mich per putty (ssh) auf dem Server angemeldet und mich auf der Kommandozeile des Servers mit genau diesen Zugangsdaten in mysql eingeloggt - kein Problem, die Zugangsdaten sind korrekt, die Datenbank ist vorhanden. Dann habe ich im Browser des Windowssystems phpmyadmin auf dem Server aufgerufen und mit den gleichen Zugangsdaten ebenfalls Zugang zur Datenbank erhalten. Also kann ich "falsche Zugangsdaten" als Grund für die Fehlermeldung definitiv ausschließen.

wobo

wobo hat geschrieben:es erschien eine Fehlermeldung, dass die MySQL-Version nicht festgestellt werden kann.

Außer der Vermutung gibt es auch noch andere Gründe warum die Version nicht ermittelt werden konnte. Das war ja auch nur eine Vermutung.
Welche MySQL-Version läuft denn dort?

mysql-5.0.45

Mann, mann, mann, bei Dir ist ja alles anders als der Standard.
Aber Deine Beschreibung war sehr präzise.
Dann hat Dein MySQL-User kein Recht die Version zu erfragen. DUK ermittelt die Version mittels des normalen Queries "SELECT VERSION()".
Gib ihm das Recht wenn Du kannst.

DSB hat geschrieben:Mann, mann, mann, bei Dir ist ja alles anders als der Standard.

Und welchen "Standard" meinst Du jetzt?

Dann hat Dein MySQL-User kein Recht die Version zu erfragen. DUK ermittelt die Version mittels des normalen Queries "SELECT VERSION()". Gib ihm das Recht wenn Du kannst.

Hat er selbstverständlich, sonst würden doch andere Tools, die diese Funktion verwenden, auch nicht laufen!
Hier der Durchgang auf unserem Server. User und Passwort sind die gleichen Werte, die auch in dem duk-Script eingetragen sind: wobo

wobo hat geschrieben:Hat er selbstverständlich, sonst würden doch andere Tools, die diese Funktion verwenden, auch nicht laufen!
Hier der Durchgang auf unserem Server. User und Passwort sind die gleichen Werte, die auch in dem duk-Script eingetragen sind

Das stimmt. Dann frage ich mich aber, warum DUK dann die Version nicht ermitteln kann, da er es genau so macht.
Ich denke, ohne Zugriff auf den Server kommen wir hier nicht weiter.

Jetzt ist es aber auch schon ein paar Tage her - ist das Problem mittlerweile gelöst?