MySQL Import von Windows ...Sonderzeichen

  • Hallo zusammen.

    Bin nun auch glücklicher Besitzer eines Raspberrys. Hab ihn soweit wunderbar zum laufen gebracht, noobs machts möglich *fg*.

    Nun habe ich ein problem, Google konnt mir nicht helfen. Und zwar:
    Ich habe mit CodeChargeStudio mir ein ..sagen wir mal eine Art Tagebuch gebastelt.
    Dieses lief vorher auf:
    Windows
    XAMPP
    MYSQL v5.1.4.1
    PHP 5.3.1

    Nun habe ich ein Dump erstellt mit PHP MyAdmin

    Das ganze auf dem Raspberry
    Raspbian
    MySQL 5.5.3.1
    PHP 5 (Neuste Version im Moment).

    Den Dump habe ich importiert.
    Das Problem ist nun das er mir die Umlaute, welche aus der Datenbank liest, nicht anzeigt.
    In der Datenbank stehen die Umlaute aber drin, so wie es sein soll.
    Bzw. er zeigt mir gleich den kompletten Datensatz nicht an (leer) in dem Umlaute vorkommen.
    (Da fehlt dann mal ne Überschrift (eigene Spalte), oder der Memotext, ...jedenfalls alles was Umlaute hat.

    Lege ich einen Datensatz an, wird der gespeichert und auch wieder angezeigt.
    Bringe ich Umlaute rein, speichert er diese auch in die Tabelle, aber zeigt ihn aber wieder leer an.


    Alles ohne Umlaute stellt er dar. Und in der HTML zeigt er die Umlaute auch an.
    Der MySQL ist von der Zeichenkodierung genauso eingestellt wie der unter XAMPP.

    Zeichensatz ist auf UTF-8 Unicode

    Kollokation ist latin1-swedish
    Hab ich alles auch schon verändert.
    Diverse Browser versucht


    Nun, hat jemand eine Idee woran das liegen kann?

    Besten Dank im Voraus

    Nops

  • Gehört nicht direkt zum Thema:
    Könntest du eventuell den Quellcode veröffentlichen?
    Würde mich interessieren! ^^

    Hmmm... Immer, wenn ich mich beteilige, artet die Diskussion aus :s

  • Hmm danke mal für den Tip. Habs jetzt nur mal kurz überflogen. Sowas hab ich mal ausprobiert aber ohne Erfolg. Muss es aber nochmal durchlesen.
    Den Quellcode veröffentlichen ist recht schwierig, sind einige php dateien, js ...was Codecharge halt so generiert, und es ist nicht unbedingt sparsam *fg* Teilweise vielleicht.

    Melde mich morgen nochmal

  • "Zeichensätze sind Teufelswerk" sagt einer meiner Kollegen immer - jedenfalls mindestens eine Herausforderung...

    Die Daten sind in der Datenbank in einem bestimmten Format gespeichert (das steht in der Datenbankbeschreibung, bei guten Datenbanken kann das je Feld verschieden sein, steht also in der Feldbeschreibung).

    Der Datenbankserver läuft mit einer bestimmten Umgebung, zum Beispiel in einer deutschen Shell mit ISO8852_1 (oft, weil von CRON/INIT.D sehr früh gestartet, in einer englischen).

    Die Ausgabe erfolgt auf einer Console, die zum Beispiel in einen tty mit ANSI.

    Der Connect erfolgt mit einem Putty SSH, z.B. mit einem Zeichensatz ISO8852_2.

    Die Anzeige erfolgt in einem Win7 mit UTF8.

    Leider gibt es also keine Standard-Antwort auf Deine Frage, aber das Symptom deutet klar darauf hin, dass Dein Anzeige-Client nicht angewiesen ist, das zu verdauen, was die Vorinstanz liefert (oder es nicht kann).

    Entweder Du schraubst bei der liefernden (siehe vorheriges Post) oder bei der empfangenden Instanz...

    Herzliche Grüße, Thomas


  • "Zeichensätze sind Teufelswerk" sagt einer meiner Kollegen immer - jedenfalls mindestens eine Herausforderung...


    Eigentlich nicht wenn alle Komponenten UTF sprechen könnten. Aber die Tatsache, dass alles mit ASCII begann, scheint auch leider heute immer noch durch und bereitet im deutschen Umfeld immer wieder Probleme mit den Umlauts und dem ß. Die Chinesen oder Japaner kämpfen da an noch größerer Front ...

    • Offizieller Beitrag

    Ich hab das gleiche Problem auch ab und an mal...
    Darum benutze ich den dos2unix Converter. Klappt supi :)

    Ich bin ein gefallener Engel namens Turael.

    Einst vor langer Zeit rebelierte ich im Himmel bis Gott mich auf die Erde verbannte.

    Doch meine taten werden kein ende finden....

    Einmal editiert, zuletzt von Turael (10. Juli 2013 um 08:07)

  • Zitat


    Eigentlich nicht wenn alle Komponenten UTF sprechen könnten. Aber die Tatsache, dass alles mit ASCII begann, scheint auch leider heute immer noch durch und bereitet im deutschen Umfeld immer wieder Probleme mit den Umlauts und dem ß. Die Chinesen oder Japaner kämpfen da an noch größerer Front ...

    Ist so nicht ganz richtig. ASCII ist einer der ersten Versuche den Wildwuchs der verschiedensten Zeichensätze zu vereinheitlichen. Im Pleistozän der Computergeschichte hatte bald jede Baureihe einen eigenen Zeichensatz. Leider war ASCII wie der Name schon sagt eine amerikanische Erfindung und die gucken ja selten über den Tellerrand, sprich Ozean. Schon für ihre europäischen Freunde musste der Zeichensatz erweitert werden. Bei den Chinesen war dann ganz endgültig Schluss.

    UTF ist eine feine Sache. Aber Betriebssysteme wie VMS, MVS, Unix u.a. sind viel älter. Und Microsoft macht eh alles anders. Auch Linux kannte anfangs kein UTF.


    Zitat


    Zeichensätze sind Teufelswerk

    Leider nicht. Ist Menschenswerk. Und die wollen es ja immer besser machen. Selten kommt was Gutes dabei raus. Aber der Hinweis zeigt in die richtige Richtung.

    Für das Problem gibt es nur eine Lösung: RTFM

    Und dann die Daten auf dem Quellsystem mit den richtigen Parametern auslesen und auf dem Zielsystem mit den richtigen Parameter einlesen.
    Richtige Dankbanksysteme kann man über Umgebungsvariablen auf unterschiedliche Zeichensätze umstellen. Wie die heißen, steht im Handbuch.
    Meistens muss man dann aber die Altdaten erst auslesen und nach der Umstellung wieder einlesen.

    Keep it simple [,&] stupid

  • Na dann werfe ich meine 2 Cent auch mal auf den Tisch. Wie man oben schon bemerkt kann es an vielen Stellen liegen. Also wie würde cih vorgehen wenn mir das Projekt genau so wie beschrieben auf den Tisch gelegt wird ohne das ich es vorher gesehen habe.

    1. Ich würde mir die neue Seite mit dem Browser anschauen um fest zu stellen ob ich relativ zügig sehen kann WAS GENAU passiert. Es kann auch eine doppel codiering sein, muß nicht das "mißverstehen" von UTF 8 sein.

    Entweder probieren indem man im Browser den Zeichensatz verändert und / oder schauen ob man ein paar der angeblichen Zeichen im quellcode sehen kann. Falls du die findest, screenshot machen und posten.

    2. Beim nutzen von PHP MyAdmin kommt eine Variable ins Spiel die du offensichtlich gerade auch nicht brauchen kannst. Also den dum direkt auf der Konsole ziehen mit "mysqldump" ... ja auf Windows wird das etwas schwieriger, ich gebe es zu. Entweder da sitzt ein cygwin drauf und du machst es mit dem ODER, viel viel besser noch ... du gibst die Windows DB im Netz frei und ziehst es remote gleich mit dem PI.

    Falls nichts der Beiden zum Erfolg führt ... hmmm ... dann kann es noch an deinem neuen Apache liegen, doch bevor du da suchen gehst schau dir die Daten in der Datenbank auf der Kosole an ... nicht in einem Browser und somit nicht im PHP MyAdmin.

    Immer dran denken auch der Browser ist ür den Nutzer gebaut (theoretisch) das heißt er hat schon Mechanismen eingebaut die selber versuchen die Zeichen richtig zu deuten und ob du am Ende WIRKLICH das siehst was in der DB steht ist fraglich.

    Auch meine ganz billigen Komponenten aus China laufen ... aber nach 4 Wochen auf hoher See hat mein 1602 Display wohl etwas an Kontrast verloren.

  • Hallo zusammen, danke erstmal für die viele Hilfe.
    mysql_query("SET NAMES 'utf8'"); funzt leider auch nicht.
    Der Hammer ist ja eigentlich wenn ich etwas eingebe (also über die Seite, nicht phpmyadmin) schreibt er die Zeichen. Und zeigt mir dann auf der "Leseseite" eben nichts an, auch keine Hieroglyphen oder ähnlich er überspringt einfach. Heisst wohl schreiben tut er richtig, importiert ist richtig, nur ausgeben.
    Gebe ich keine Umlaute ein...dann zeigt ers an. Ich poste mal den Code der Seite, welche mir die Probs macht.

  • Hi,

    ich greif hier gerade mal das Kommentar von joschi240 auf.

    Zitat


    ... aber normalerweiße sollten die sätze dennoch angezeigt werden(bis aufs sonderzeichen)

    Ich kann mich gerade nicht daran erinnern, dass mir MySQL jemals einen Datensatz unterschlagen hätte, nur weil das Encoding nicht passt. Komische Zeichen habe ich schon häufig gesehen.

    Das Framework was du benutzt scheint ja mit mächtig viel schwarzer Magie und einem großen Vorschlaghammer Quellcode aus den armen Bits und Bytes zu erschaffen. Bei dem Code den du gepostet hast ist für mich leider nicht viel zu sehen, zumal die eigentlich interessanten Teile nicht dabei sind (z.B. die eigentliche DB-Klasse).

    Hier aber noch ein paar Ideen:

    Schau mal in dein PHP-Log oder aktiviere die Fehler-Ausgabe, falls du es nicht schon gemacht hast. Vielleicht ist irgendwo eine hilfreiche Warning oder Notice.

    Eventuell hat dein mysql_query('set names ...') keine Auswirkungen. Prüf mal mit mysql_error, ob ein Fehler aufgetreten ist. Evtl. wird nichtmals mysql, sondern mysqli oder PDO verwendet. Vielleicht bietet CodeCharger Studio ja auch eine Möglichkeit, das Encoding per Konfiguration zu setzen?

    Was mir kürzlich untergekommen ist: Bei einem Tool wurde intern json_encode verwendet, als alternative zu serialize(). Diese Funktion arbeitet NUR mit UTF-8 und liefert andernfalls häufig leere Werte. Wird bei deiner "Leseseite" evtl. an irgendeiner Stelle mit AJAX gearbeitet?

  • Hmm das mit dem mysql_error versuch ich mal. Er unterschlägt den Datensatz nicht direkt, er zeigt dann eben nur ein leeres Feld an, wenn ein Sonderzeichen kommt. Mit Ajax wird nicht gearbeitet. Nur mit PHP. Das Programm läuft ja seit gut 10 Jahren, wurde von mir immer nur mal geändert, verbessert, updates. Wenn dann hat ich immer nur Probleme mit dem Datumsformat. Aber erst seit dem Umzug auf Raspberry hab ich dieses Problem. Achja hier mal der Common. Kann halt nicht alles veröffentlichen wäre zu umfangreich. Und zu viele Dateien. Und naja schwarze Magie. Benutze das ja nur zuhause und da tuts mir das. Für mich ist die Hauptsache das es funktioniert. Um sowas von Hand zu programmieren bin ich nicht fit genug in PHP *fg*.

    Achja mal was positives abseits von Thema, habe meine externe Festplatte mit NTFS und SMB freigegeben. Und im Gegensatz zur Fritzbox: Meine Frau hat Dateien dessen Dateinamen aus kambodschanischen Schriftzeichen besteht (Khmer Unicode): Sie werden im Explorer einwandfrei angezeigt. Die Fritzbox hat diese Dateien immer unterschlagen.


    Auch in dieser Datei hab ich mit dem UTF8 rumprobiert, aber es klappt nicht^^



    Ehm mal ne kleine Zwischenfrage, will deswegen nicht einen neuen Thread aufmachen.

    Und zwar, ist ja bekannt, das beim Starten von Liedern auf dem Raspberry ein Knacken auftritt.
    Aber nur am Anfang. Bei mir ist es aber so, das wenn ich FLAC abspiele (meine CD Sammlung hab ich komplett in FLAC eingelesen) hab ich ein Knacken das ganze Lied über, was ungefähr meiner Deep Purple - Made in Japan-Schallplatte gleicht, welche einem starken Raucher gehörte der keine Ahnung hat wie man mit Schallplatten umgeht^^. Jemand eine Idee? Also mein 30 Jahre alter Thorens Jubilee knackt fast garnicht mein Raspberry aber^^ Laut Klischee sollte es ja umgekehrt sein *fg*(ok das Platten knacken ist eh nur ein Gerücht bzw falsche Handhabung)

    Gruß und Dank nochmal für die viele Hilfe.

  • Habe gerade den zweiten Quelltext durchgescrollt, leider ist der auch nicht wirklich aufschlussreich für mich.

    Mir ist aber gerade etwas anderes in deinem ersten Schnipsel aufgefallen. Dort steht ziemlich weit unten, dass CP1252 bzw. windows-1252 als Encoding für das Template verwendet wird. Wenn es das Framework richtig angeht, dann wird irgendwo eine Umwandlung von CP1252 nach UTF8 stattfinden, um die Datenbankwerte anzuzeigen. Das kann intern z.B. durch iconv gemacht werden. Wenn iconv dann der Meinung ist, dass da ungültige Zeichen drin sind, dann wird ein false zurückgegeben, was dann als leerer String dargestellt wird.

    Besteht die Möglichkeit, dass du das Template-Encoding irgendwo auf UTF-8 umstellen kannst?

    Ansonsten gehen mir erstmal die Ideen aus.

    LG
    Hacksteak

  • Naja, ich hab mal mit einem Suchen & Ersetzenprogramm alles windows-1252 und CP1252 in utf-8 umgewandelt, in den kompletten Verzeichnissen also alle php und htm... Das Template-Encoding hab in der PHP umgestellt (denke mal das es das war)


    Aber hat auch nix geholfen.
    Noch nicht mal Hieroglyphen bekomm ich raus des ist wie wenn noch nicht mal der Vorlauf aus dem MYSQL-Server käm weil die Sonderzeichen den Kanal komplett verstopfen :D

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!