emoji Icons im MySQL DB speichern - Zeichensatz problemchen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • emoji Icons im MySQL DB speichern - Zeichensatz problemchen

    Hi Leute,
    hab ein aussergewöhnliches Problem - vielleicht ist es auch normal, aber ich hoffe es ist es nicht...

    Ich arbeite gerade daran dass die emoji icons im DB gespeichert werden können (ihr wisst schon von app zu php-file von da zu mysql DB).. lläuft auch alles wunderbar jedoch werden mir im DB die Daten falsch angezeigt.
    Also in den typischen kryllischen Zeichen eben.
    Zur INfo: alles in utf8: PHP-File, DB, und auch Daten kommen super vom App ins PHP-file an (habs getestet indem ichs in einer txt-datei zwischengespeichert habe). Es verwuschtelt sich bei der Übertragung von PHP-File zu DB.
    Ich hab (nach meiner Meinung) alles versucht:
    - utf8_encode /-decode / ohne....Resultat war meist: emoji funzt+umlaute gar nicht oder beides eben nicht - im Moment funktioniert zwar alles jedoch sehe ich (mein Problemchen) die Daten im DB in kryllischen Zeichen...das soll
    ja nicht so sein - habt ihr eventuell noch eine Idee waren es liegen kann

    Kurz nochmal zusammengefasst:
    PHP-File (utf8 ohne DOM)
    DB (DB selbst, Tabellen wie auch Spalten in utf8_general_ci)
  • acidayi schrieb:

    lläuft auch alles wunderbar jedoch werden mir im DB die Daten falsch angezeigt.
    Was die Frage aufwirft: wie überprüfst Du das? Per GUI-Tool? Per Web-Tool? Per Shell? Per Dump? Und falls eine der ersten drei Optionen: es könnte auch sein, dass die Daten in der DB korrekt vorliegen, aber der verwendete Client den Inhalt verhackstückt.

    Carsten
  • Hi Leute,
    danke schon mal an die Beteiligung am Thread.

    Also ganz easy: Im moment funzt alles bedeutet: Daten werden toll übertragen der Enduser sieht alles korrekt - jedoch nachwievor im DB alles zerhackt...nicht toll. Die Tolle lösung natürlich: Enduser kann lesen , wie auch im DB alles top vorliegend.

    Wo ich das getestet habe: phpMyAdmin - er zerstückelt mir regelrecht die umlaute und sonderzeichen...

    set names utf8 hab ich mittlerweile auch drin..sah aber keine veränderung. Wenn ich auf die Emoticons verzichte, also wenn mein Verlangen nur nach korrekten Umlauten wäre, wäre es kein Problem - Mit utf8_encode/decode läuft das ja 1A.
  • Update: Ich hab zum test mal in der gleichen DB, diesmal Daten die aus einem Formular auf der gleichen Webseite generiert werden, versucht (mit Umlauten) Einträge zu erstellen.
    Und sieh an: es funktioniert, und ohne irgendwie die daten zu en- oder decoden zu müssen --> Liegt wohl der Fehler jetzt doch etwa an den Daten die vom App gesendet werden? Hmm...
    Die Daten die vom App ankommen hatte ich aber mal in einer txt-Datei auf dem Server zwischengespeichert - und die Umlaute waren auch da... - aber um diese auch im DB zu sehen musste ich
    diese immer vorher utf8_encode bzw. decode beim auslesen.

    Kurzer Fazit bis jetzt: Daten die auf der Webseite generiert werden (keine Emoticons, indem Fall mal mit vielen Umlauten), werden reibungslos übertragen.
    Daten die vom App kommen, nicht. Die Daten die vom App kommen werden aber exakt genauso in einer txt-DAtei gespeichert, jedoch bei der Übertragung ins DB, wird alles zerhackt (inkl. Umlaute).
    Bin grad etwas ratlos...ich teste weiter...
  • Wenn du z.B. die Daten ihn Deiner DB in UTF8 ablegst und sie Dir dann mit PHPMyAdmin ansiehst, dann sehen sie kaputt aus. Das liegt aber daran, dass der ISOLatin1 haben möchte. Das bedeutet aber noch lange nicht, dass die Daten in der DB kaputt sind. Am besten ist es ja wohl, wenn die Nutzer der DB das Format nicht wandeln müssen. Also wenn dein Client UTF8 baucht, dann ist es auch schön wenn da UTF8 drin steht.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • acidayi schrieb:

    Hi Leute,
    danke schon mal an die Beteiligung am Thread.

    Also ganz easy: Im moment funzt alles bedeutet: Daten werden toll übertragen der Enduser sieht alles korrekt - jedoch nachwievor im DB alles zerhackt...nicht toll. Die Tolle lösung natürlich: Enduser kann lesen , wie auch im DB alles top vorliegend.

    Wo ich das getestet habe: phpMyAdmin - er zerstückelt mir regelrecht die umlaute und sonderzeichen...

    set names utf8 hab ich mittlerweile auch drin..sah aber keine veränderung. Wenn ich auf die Emoticons verzichte, also wenn mein Verlangen nur nach korrekten Umlauten wäre, wäre es kein Problem - Mit utf8_encode/decode läuft das ja 1A.


    vertrau doch nicht auf phpMyAdmin. die zeigen oft müll an!

    außerdem kann es auch sein dass die zeichen im browser durch die LucidaGrande oder "LastResort" font dargestellt werden und nicht durch die "emoji".

    lass dir die gespeicherten daten in binärer form anzeigen, dann siehst du ja ob der korrekt kodierte unicode-char drin steht.
  • Hab zum Test mal die utf8_encode/decode's rausgenommen und Daten vom App an die PHP-File übertragen und dort mal kurz in einer txt.-DAtei zwischengespeichert.
    Hier werden alle emoji's in Kästchen abgebildet...und wenn so ein Kästchen in einer SQL-Anweisung übertragen werden soll, dann bricht er auch exakt an dieser STelle ab bzw. liest es nur bis zum Kästchen, der Rest wird ignoriert.

    btw: gerade hab ich ein Post exakt mit diesem Kästchen per Copy Paste probiert, bricht ebenfalls im Text ab (musste es glatt nochmal schreiben, ohne Kästchen).

    Update: Umlaute werden super übertragen (jetzt auf einmal komischerweise). die Emoticons werden im Notepad mit einem Kästchen abgebildet und im Notepad++ bspw. mit "ðŸ"

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von acidayi () aus folgendem Grund: zerhackt... Update

  • Jouu....
    nach etlichen versuchen hier die 90%ige Lösung oder sagen wir mal ein ultra-kurz Tutorial - ich werde dazu auch ein großes Tutorial schreiben und hier verlinken (sobalds zu 100% passt):
    1. Alle Felder im DB (sei es Spalten oder Tabellen oder die DB an sich) --> utf8mb4 (dazu ausreichend Infos auf der dev.mysql.com holen, zwecks Spaltengrößen)
    2. im PHP auch mal direkt nach dem connecten

    Quellcode

    1. SET NAMES 'utf8mb4'
    ausführen

    ..jou und jetzt läuft alles ohne in utf8 zu de oder encoden zu müssen und Umlaute passen und...Emoji icons auch aaaaaaaber, diese werden nachwievor im DB (laut phpmyadmin, obwohl auf utf8mb4 umgestellt) als Fragezeichen abgebildet. Das komische ist aber dass wenn man diesen wieder ausliest und der App beispielsweise zurückgibt, die tollen emoji icons wunderbar dargestellt werden. Ist eigentlich ein klarere Beweis dafür dass die Zeichen 1A im DB abgespeichert werden, nur phpmyadmin wohl diese mir nicht zeigen mag.

    Hoffe ich konnte anderen damit etwas helfen und natürlich am meisten mir selbst.. :D :D

    Die 10 % die fehlen beziehen sich auf die Anzeige im phpmyadmin. Wems egal ist (und im Grunde ist das egal, wenn man weiß dass die Daten im DB abgespeichert werden), kann es so lassen. Sollte ich rauskriegen wie man phpmyadmin noch einstellen muss damits die Orginal-Zeichen anzeigt, poste ich natürlich.
  • Ich greife dieses wunderbare Thema mal wieder auf, es hat mir endlich geholfen Emojis zu verschicken, in einer DB abzuspeichern und dann in der App wieder anzuzeigen !! :)
    Mein Problem sind jetzt aber die letzten 10%^^.
    Also in der Mysql-Datenbank werden die Emojis als ? dargestellt, auf dem iOS-Gerät dann wieder als Emoji (wie oben beschrieben).

    Die Frage ist nun aber, wie kann ich die Emojis auf der Website darstellen?
  • kulka1 schrieb:

    Ich greife dieses wunderbare Thema mal wieder auf, es hat mir endlich geholfen Emojis zu verschicken, in einer DB abzuspeichern und dann in der App wieder anzuzeigen !! :)
    Mein Problem sind jetzt aber die letzten 10%^^.
    Also in der Mysql-Datenbank werden die Emojis als ? dargestellt, auf dem iOS-Gerät dann wieder als Emoji (wie oben beschrieben).

    Die Frage ist nun aber, wie kann ich die Emojis auf der Website darstellen?


    auf welcher webseite?

    du musst natürlich eine (odere mehrere, je nach system) schriften angeben die die zeichen auch enthällt.
    die werden dann natürlich nur korrekt angezeigt wenn die schrift auch existiert. die font gibts glaub ich erst ab 10.7 und unter windows natürlich garnicht...
  • Du solltest sowohl deine SQL DB als auch dein werbservice Script und deine HTML Seite einfach auf UTF-8 stellen. Dann sieht alles überall gleiche aus.

    Bei der SQL DB geht das über den phpmyAdamin
    Beim Webservice über einen Befehl (kommt halt auf die Scriptsprache an)
    Beim HTML über den DocType

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Du solltest sowohl deine SQL DB als auch dein werbservice Script und deine HTML Seite einfach auf UTF-8 stellen. Dann sieht alles überall gleiche aus.

    Bei der SQL DB geht das über den phpmyAdamin
    Beim Webservice über einen Befehl (kommt halt auf die Scriptsprache an)
    Beim HTML über den DocType

    Gruß

    Claus


    bei html würd ichs aber nicht als einfaches utf8 schreiben sondern in html-entities umwandeln. bei PHP zb mit "htmlentities".

    es sieht aber nicht überall gleich aus weil es wie gesagt von den (nicht)installierten schriften abhängt!
  • auf welcher webseite?


    Zum Beispiel auf einer Seite mit dem CMS phpkit.

    Ich habe jetzt die Datenbank auf utf8mb4 gestellt.

    So trage ich etwas in die Datenbank ein:

    PHP-Quellcode

    1. $text = $_POST['text'];
    2. $result = dbquery("INSERT INTO test (text) VALUES ('$text')");


    Und so lese ich das aus:

    PHP-Quellcode

    1. <?php
    2. // hier stehen die verbindungsdaten
    3. ?>
    4. <html>
    5. <head>
    6. <title>page title</title>
    7. <meta http-equiv='Content-Type' content='text/html; charset=UTF-8' />
    8. </head>
    9. <body>
    10. <?php
    11. $query = "SELECT * FROM `test`";
    12. $sql = mysql_query($query) or die(mysql_error());
    13. while ($ds = mysql_fetch_object($sql)){
    14. $text = $ds -> text;
    15. echo $text."<br>";
    16. }
    17. ?>
    18. </body>
    19. <html>
    Alles anzeigen


    Mir werden trotzdem ? angezeigt.

    Wenn ich das irgendwann mal vernünftig zum laufen bringen würde, dann könnte man da schon fast ne Arbeit zu schreiben :D
  • Also ich weiß einfach nicht was ich falsch mache, ich mache eigtl immer alles so wie es mir gesagt wird, aber es klappt nicht ...

    Wenn ich von dem iPhone ein ;) (als Emoji) absende wird es, wie beschrieben, als ? in die Datenbank eingetragen. Bei der Ausgabe wird es auch als ? ausgegeben, egal ob mit htmlentities oder nicht.

    Wenn ich &#x1f609; bei SQL eintrage, dann wird mir das richtig Emoticon ausgegeben.


    Ich will doch nur das das endlich mal funktioniert :S ?( :D