Suche

[PeterGeorgAnton]

Hallo pragmaMx-Spezialisten,

ich habe wegen meines Hoster-Umzuges noch immer kleinere Bereiche auf meiner Seite, in denen die Umlaute und Sonderzeichen nicht richtig wiedergegeben werden.
Im Impressum nicht so tragisch, da habe ich das Problem mit der Schreibweise ue, ae etc. umgangen.
Aber jetzt habe ich in der Navigationsleiste "?", da dieser "●" nicht interpretiert werden kann.
Im Übrigen auch in den pragmaMx-News!
Das ist wirklich sehr störend!?!
Siehe: www.peter-esterl.de

Wer kann helfen?
Beste Grüße Peter

[lemming]

mhm komisch bei mir werden ä, ö und auch der ● bei den navigationslinks richtig angezeigt. wo genau soll das falsch interpretiert werden?

seh grad bei den kommentaren gehts auch 

[PeterGeorgAnton]

Hallo lemming,
danke für die schnelle Antwort.

Ich gehe im Admin-menue auf Blöcke/System und
setze einen Hyperlink
● Interessante Links

In der Navigationsleiste wird der "●" als "?" wiedergegeben. (Auf dem Bildschirm ganz unten links)!
Siehe: www.peter-esterl.de

Beste Grüße Peter

[lemming]

Hi Peter,
versuchs mal mit den HTML Sonderzeichen:

http://de.selfhtml.org/html/referenz/zeichen.htm

da wär der punkt dann zB. das hier:

Code Auswählen Erweitern

Zeichen Beschreibung Name in HTML Unicode in HTML
• Bullet-Zeichen •                •

[PeterGeorgAnton]

Hallo lemming,
danke für den Tipp.
Ich hab das Zeichen bei "selfhtml" gefunden, kopiert und übertragen. Nur "pragmamx" interpretiert die Zeichenfolge nicht als "." sondern gibt die Buchstabenfolge wieder.
Ich denke, das wars nicht oder hab ich was falsch verstanden?
Beste Grüße Peter

[lemming]

hast du so probiert:

Code Auswählen Erweitern

• Anmelden

wenn das nciht funktioniert muss ich leider auch passen tut mir leid 

[Andi]

Moin

für mich sieht das immernoch so aus, als läge das an der falsch konvertierten Datenbank vom Serverumzug. Ich denke die Krücke mit dem Charset verstellen auf utf um die eigentlich falschen Daten aus der Datenbank auszulesen funktioniert einfach nicht so, wie das der Tipgeber gedacht hat. PragmaMx zeigt ja nicht nur Daten aus der Datenbank an, sondern auch aus den scripten selbst und vor allem aus den Sprachdateien. Und die sind nicht UTF-8 kodiert....
pragmaMx funktioniert (noch) nicht mit UTF-8, da gehört bisserl mehr geändert als nur das Charset für die Ausgabe verstellt...

Hast du noch Zugriff auf den alten Server, bzw die Datenbank dort?

Dass man da nochmal einen korrekten Dump zieht, mit den richtigen Charset und Colation Optionen, die man auch wieder einlesen kann....

[Mecki]

Hi,

ich stimme Andi zu, das liegt bestimmt an der falsch konvertierten Datenbank. Die Kollation sollte normalerweise latin1_german1_ci sein. Dann geben viele php Editoren trotz richtig konfigurierter Datenbank die Umlaute und Sonderzeichen falsch wieder.

Mal ein kleiner Ausschnitt von meiner Konfiguration. Der Mist ist ganz schön nervig*lach


Variable                       Wert für diese Sitzung       Globaler Wert
character set client            utf8                                  latin1
character set connection   latin1                             latin1
character set database       latin1                             latin1
character set results          utf8                                latin1
character set server          latin1                                latin1
character set system        utf8                              utf8
character sets dir         /usr/share/mysql/charsets/    /usr/share/mysql/charsets/
collation connection           latin1_german1_ci          latin1_german1_ci
collation database           latin1_german1_ci          latin1_german1_ci
collation server              latin1_german1_ci             latin1_german1_ci

LG
Mecki

[Andi]

Hi Mecki, lange nicht gesehen 

[Mecki]

Huhu Andi,

aber doch wieder erkannt   

Viele liebe Grüße

Mecki

[PeterGeorgAnton]

Hallo Andi,

danke für Deine verständlich erklärende Antwort.
ich habe zwar nicht mehr Zugriff auf den alten Server, aber ich habe die alte Datei noch mittels "Mysqldumper" gesichert. Nur ist mir nicht klar, wie man einen "Dump" zieht und wieder einliest.

Beste Grüße Peter

[PeterGeorgAnton]

Hallo Andi,
ich meinte natürlich alte Datenbank und nicht "alte Datei".

Beste Grüße Peter

[Andi]

Oki, dann muss man mal den alten Dump (Datensicherung) ansehen, welche Parameter da existieren um das wieder korrekt einzulesen...

Kannst du mir die Datei, die der Mysqldumper gesichert hat zusenden?
Ich schau dann mal rein....

info@pragmamx.org

[PeterGeorgAnton]

Hallo Andi,

hast Du bereits etwas kurzfristig geändert? Ich hatte zwischenzeitlich kurz ein altes Gästebuch drauf und die Fehlermeldung:
Parse error: syntax error, unexpected $end in /home/ftp............./www/data/phpGedView-3.3.8/index/authenticate.php on line 131
Jetzt ist wieder der neueste Stand der HP-Seite drauf aber immer noch die o.a. Fehlermeldung.
Der Link zu meiner "phpGedView-Seite" funktioniert nicht mehr.
Beste Grüße Peter

[Andi]

Hi

ich kann bei dir nichts ändern. Du hast mir den Datenbankdump zugeschickt, aber keine Zugangsdaten
Hat dein Provider evtl. ein Backup oder irgendwas eingespielt...


In dem Dump, sind unterschiedliche Einstellungen in verschiedene Tabellen für das Charset. ANscheinend war da beim alten Server die Grundeinstellung für neu Tabellen anders, als für bestehende oder irgendsowas....

Das müsste man abgleichen und dann wieder neu einspielen. Dabei muss man beim Einspielen wieder auf das korrekte Format achten. Der mySqlDumper hat diesbezüglich da keine Einstellmöglichkeiten, das müsste man mit phpMyAdmin machen.

Wenn du mir komplette Zugangsdaten zukommen lässt, dann probier ich das. Das würde mich selbst interessieren, auf was man da achten muss und entsprechend einstellen mus....


EDIT:
habe jetzt ne Spur...
Die vom mysqldumper erstellte Textdatei hat reines ANSI Format. Die Zeichen sind aber als UTF-8 Kodiert darin enthalten. Vermutlich erkennt das der mysqldumper beim importieren nicht richtig. Wenn man das mit phpMyAdmin importiert und dort als Quellzeichenformat expliziet UTF-8 angibt, dann werden die Daten korrekt importiert und auch wieder korrekt angezeigt.
Das Problem ist also nicht das bei den mysql-Daten angegebene Zeichenformat, sondern das nicht passende Format der erstellten Textdatei.

Anscheinend gibt es da öfters Probleme, weil bei mysqldumper.de gibt es eine neue Version, die Sonderzeichenprobleme verhindern soll:
http://www.mysqldumper.de/download/

Diese MySQLDumper-Version basiert auf UTF8 (Webseiten und Datenbankverbindung) und ist der Versuch Umlautprobleme zu verhindern. Außerdem enthält diese Version die aktuellsten Bugfixes. Diese Version empfiehlt sich bei der Verwendung eines MySQL-Servers ab Version 4.1.0 oder höher. Bei kleineren MySQL-Versionen sind Umlautprobleme unvermeidlich.

EDIT 2:
das war übrigens der erste Thread zu dem Problem:
http://www.pragmamx.org/forum-topic-19697.0.html

Edit 3:
hier demo:
http://********.*******.cx/pragmamx/temp/pragmamx_01/
passt alles....

[PeterGeorgAnton]

Hallo Andi,
danke für Deine umfassende erklärende Antwort.
Ich habe einmal jubilee Ende des Jahres in einem anderen Problemzusammenhang meine Zugangsdaten mitgeteilt. Ich dachte, dass Du deshalb evtl. die notwendigen Informationen hattest.

Das mit dem "backup" muss ich mit meinem Provider noch klären.

Ich habe im Übrigen die Datenbank mit der neuen MySQLDumper-Version gesichert und  auch wieder eingespielt.
Hinweis des MysqlDumper-Entwicklers:
"Nimm die neuste Entwicklerversion 1.21 b13 und stelle die Verbindungsoptionen auf utf8. Mach ein neues Backup und spiele dieses wieder ein.
Das sollte funktionieren."

Trotzdem hatte ich die Umlautprobleme weiterhin und habe mich deshalb noch einmal mit dem Entwickler von MySQLDumper in Verbindung gesetzt.

Dieser hatte mir folgendes mitgeteilt:

"Hallo Peter,
das liegt nicht am MySQLDumper.
In der Datenbank stehen die Daten korrekt drin. Schau Dir mal einige Tabellen, die Umlaute in den Datensätzen enthalten, im SQLBrowser des Dumpers an.

Dein Programm auf der Webseite sendet per META-Tag die Information, dass die anzuzeigenden Zeichen ISO 8859-1 kodiert sind, sendet aber keinen entsprechenden Header.
utf8-kodierte Daten aus der Datenbank müssen vor der Ausgabe auf einer iso-kodierten Webseite dann auch entsprechend von utf8 nach iso gewandelt werden. Das macht das Programm aber offensichtlich nicht.
Wenn Du im Browser die Zeichenkodierung händisch auf utf8 stellst, wird alles korrekt angezeigt.

Der Dumper ist wiedermal unschuldig."

Ehrlich gesagt, ich verstehe da nur "Bahnhof".
Siehe auch meine folgende Anfrage:
 
pragmaMx / Installation & Update / Re: Neuinstallation von pragmaMx 1.8
am: 28 Dezember 2006, 13:14:25
   

Vielleicht kannst Du mir helfen?!

Beste Grüße Peter

[Andi]

Hi Peter

wie gesagt, das Problem ist das Format der Textdatei, die der mysqldumper erstellt hat. Die ist entweder vom mysqldumper her falsch, oder wurde nachträglich im falschen Format zwischengespeichert. Wenn man die in einem unicode-fähigen Editor öffnet, wird die trotzdem als Ansi interpretiert. Die Sonderzeichen sind aber als Unicode (utf8) kodierte Zeichen darin enthalten.
Liest man diese Daten jetzt per mysql-dumper oder phpmyadmin wieder in eine Datenbank ein, dann werden diese Sonderzeichen dort falsch importiert. Die Datenbank meint es kommt normaler ANSI-Text und lässt die kryptischen, falschen Unicode-Sonderzeichen unbehelligt. Werden die jetzt normal wieder ausgelesen und vom Browser auch wieder als normaler ANSI-Text interpretiert, werden eben diese Sonderzeichen so bescheuert angezeigt. Der Trick, mit dem Charset-Header senden, funktioniert dann zwar mit den Daten aus der Datenbank, weil die dann richtig interpretiert werden, aber alle anderen Daten aus den Sprachdateien, oder die neuen, die du in die Datenbank eingibst werden dann dadurch falsch angezeigt.

Hier ein Auszug aus der entsprechenden Textdatei:

Im Bewusstsein, dass jeder Vorfahre seinem Nachkommen einen Teil seiner Erbanlagen weiter gibt, dass also unsere Ahnen in uns und wir in unseren Nachkommen weiter leben, ist es von großem Interesse zu wissen, wie unsere Ahnen gelebt haben, was sie bewegte, welche Berufe sie ausübten und möglicherweise, welche Charakteranlagen sie hatten. Darüber können diese Tafeln keine Auskunft geben.

Wenn ich das so in die Datenbank einlese, ohne eine Option zu verstellen, dann wird das sowohl in phpMyAdmin als auch im pragmaMx genau so auch wieder angezeigt. Es ist also Unsinn zu sagen es liegt am "Programm auf der Webseite". Sowohl pragmaMx als auch phpMyAdmin senden dem Browser einen korrekten Metatag nach HTML-Standard, der sagt, wie die Sonderzeichen zu interpretieren sind:

Code Auswählen Erweitern

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="content-language" content="de">
Da braucht man keinen Extra Header zu senden. Zumal dieser UTF-8 Header in deinem Fall sowieso falsch ist, weil nur die alten iportierten Datenbankdaten dadurch korrigiert werden und alle anderen Daten dadurch falsch interpretiert werden.

"Nimm die neuste Entwicklerversion 1.21 b13 und stelle die Verbindungsoptionen auf utf8. Mach ein neues Backup und spiele dieses wieder ein.
Das sollte funktionieren."

Wie beschrieben, mit den internas von MySql hat das garnichts zu tun. Die Importdatei ist fehlerhaft, und beim Import muss dieser Umstand beachtet werden.
Dass es auch offensichtlich nicht funktioniert zeigen etliche Beiträge im Forum vom mysqldumper. Es bringt nix, wenn man die Daten im UTF-8 Format in die Textdatei (dump) exportiert, diese dann aber nicht wieder als UTF-8 korrekt importiert werden können.

Dein Programm auf der Webseite sendet per META-Tag die Information, dass die anzuzeigenden Zeichen ISO 8859-1 kodiert sind, sendet aber keinen entsprechenden Header.
utf8-kodierte Daten aus der Datenbank müssen vor der Ausgabe auf einer iso-kodierten Webseite dann auch entsprechend von utf8 nach iso gewandelt werden. Das macht das Programm aber offensichtlich nicht.
Wenn Du im Browser die Zeichenkodierung händisch auf utf8 stellst, wird alles korrekt angezeigt.

Wie oben geschrieben...
Es ist unsinnig, wenn das wirklich so wäre, dann hätten wir ständig Probleme mit Umlauten im pragmaMx. Habe wir aber trotz mehrer tausend installationen nicht. Und diese Installationen dann noch international in versch. Sprachräumen...
Mir ist jetzt auch noch kein CMS oder Forenscript begegnet, welches einen explizieten Charset-Header sendet. Das würde auch den HTML-Standard ad adsurdum führen.

Der Dumper ist wiedermal unschuldig

Mag sein. Aber entweder hat er die Datei falsch exportiert, oder hat sie später falsch importiert. Wie das jetzt genau zustande gekommen ist kann ich nicht sagen.
pragmaMx hält sich nur an die Standards und zeigt an was es aus der Datenbank geliefert bekommt....

Ich habe einmal jubilee Ende des Jahres in einem anderen Problemzusammenhang meine Zugangsdaten mitgeteilt. Ich dachte, dass Du deshalb evtl. die notwendigen Informationen hattest.

Das Team tauscht die Zugangsdaten der USer nicht untereinander aus. Die bekommt und verwendet immer nur der, der sie auch vom user persöhnlich erhalten hat. Auch werden die normalerweise nach dem Abschluss der jeweiligen Sache wieder gelöscht, so dass wir die immer wieder erneut abfragen müssen.

Wenn du mir komplette Zugangsdaten zukommen lässt, dann probier ich das. Das würde mich selbst interessieren, auf was man da achten muss und entsprechend einstellen mus....

Also, schick mir die Zugangsdaten und wir machen das.... 

[PeterGeorgAnton]

Hallo Andi,
es ist einfach toll, wie Du Dich da reinhängst. Herzlichen Dank.
Ich werde Dir die Zugangsdaten per PM mitteilen.
Beste Grüße Peter

[DSB]

Hallo Andi,

Der Trick, mit dem Charset-Header senden, funktioniert dann zwar mit den Daten aus der Datenbank, weil die dann richtig interpretiert werden, aber alle anderen Daten aus den Sprachdateien, oder die neuen, die du in die Datenbank eingibst werden dann dadurch falsch angezeigt.

Das ist kein Trick sondern eine Notwendigkeit.
Das Ergebnis hängt ganz entscheidend von der verwendeten MySQL-Version ab und in welcher Form die Backupdatei vorliegt.
Es gibt eine ganze Menge Server, die die Option AddDefaultCharset auf einen bestimten Zeichensatz gestellt haben. Und wenn das der Fall ist, dann kannst Du Meta-Tags senden wie Du lustig bist - der Server wird sie nicht akzeptieren und mit dem eigenen Zeichensatz überscheiben. Du musst zwangsläufig einen Heaer mit dem korrekten Zeichensatz senden, sonst geht es bei diesen Servern in die Hose.

Liest man diese Daten jetzt per mysql-dumper oder phpmyadmin wieder in eine Datenbank ein, dann werden diese Sonderzeichen dort falsch importiert. Die Datenbank meint es kommt normaler ANSI-Text und lässt die kryptischen, falschen Unicode-Sonderzeichen unbehelligt.

Deshalb gibt es in MySLDumper Version 1.21 b13 die Option die Verbindung zwischen PHP und MySQL explizit auf utf8 zu stellen.
Die Schwierigkeit besteht darin, dass eine Datei keinerlei Kodierung besitzt, die man aus den Dateiattributen auslesen könnte. Man muss also bereits vor dem Einlesen wissen in welcher Form die Datei eigentlich vorliegt und dann die Verbindung entsprechend setzen. Wählt man hier das Richtige, so ist auch das Ergebnis korrekt.
Funktionieren tut das aber auch nur ab MySQL Version 4.1. Davor gibt es erhebliche Proleme mit unterschiedlichen Zeichensätzen. Deshalb ist es unglaublich schwer eine allgemeingültige Anleitung zu schreiben.

Fakt bei Peter war jedoch, dass der Datenbankinhalt nach dem Restore korrekt war, der in den Meta-Tags angegebene Zeichensatz per Default-Einstellung vom Server überschreiben wurde und dadurch die generierte Webseite falsch dargestellt wurde, obwohl die Daten in der DB korrekt waren.
Hier fehlte der richtig Header, der dann die Default-Einstellungen des Servers korrekt überschrieben hätten.

Du siehst, dass hier der Programmiere wieder einmal gefragt ist die ganzen unterschiedlichen Fälle abzufangen.
Schmecken tut mir das auch nicht...

[jubilee]

Ich habe einmal jubilee Ende des Jahres in einem anderen Problemzusammenhang meine Zugangsdaten mitgeteilt.

Ich lösche die Zugangsdaten i.d.R. nach Abschluß der Arbeiten spätestens jedoch wenn ich meine PM das
nächste mal ausmiste (bei der Menge an PM die ich bekomme sind das höchstens ein paar Tage später).
Weitergegeben (auch an andere Admin-Kollegen) , werden die Daten sowieso nicht. Die sind ausschließlich mir anvertraut und so behandele ich die Daten auch.

Mfg