homtata hat geschrieben:Hallo Faar,
nein, das ist definitiv nicht das Problem.
Sicher?
Der Fehler taucht auch beim Umbenennen von Kategorien auf, und da kanns nun gar nicht an der Codierung liegen, weil ja nur unformatierter Text eingegeben wird.
Wenn die Datei, die das Formularfeld für "das Umbenennen von Kategorien" darstellt, nicht auch als utf-8 Format gespeichert wurde, dann funktioniert das nicht richtig.
Selbst WENN ich die Texte vorher in einen Editor gebe und dort das Encoding auf UTF8 umstelle und dann von dort aus wieder den Text kopiere, ändert das nichts - die Fehler bleiben bestehen...
Ja eben, es spielt da keine Rolle, ob du es irgendwo als utf-8 eingestellt hast, wenn das Formular-Dokument mit dem das Zeichen abgesendet wird, nicht selbst utf-8 ist.
Du kannst inzwischen selbst beim Windows Standardeditor eine Textdatei als Ansi oder UTF-8 abspeichern. Damit ist das Dokument selbst auch als utf-8 codiert.
Der Witz ist nämlich, dass das Programm davon ausgeht, dass es Ansi ist, wenn du ein Zeichen von einem Ansi-Dokument übernimmst.
Schaust du in Wordpress-Datenbanken rein, wirst du sehen, dass dort die Kollation auch auf irgendwas steht, aber nicht auf utf-8, das spielt dabei keine Rolle.
Warum?
Weil die UTF-8 Ersatzzeichen (diese Hiroglyphen) in der Datenbank stehen, die mit Ansi angezeigt werden können.
Gibst du so ein Zeichen dann wieder als utf-8 aus, wie in Webseiten, dann wird auch das richtige Zeichen dargestellt und nicht mehr das Ersatzzeichen.
Nachtrag: selbst wenn ich versuche, das Sonderzeichen direkt in die Datenbanktabelle einzufügen, wird es in ein Fragezeichen umgewandelt...
Das geht nicht, weil die Formularmaske, wo du das utf-8 Zeichen einträgst, nicht utf-8 ist. Es ist Ansi oder sonstwas westliches, daher wird der Datenbank selbst dann gesagt, es wäre ein Ansi Zeichen, was da kommt.
Und weil Ansi kein echtes UTF-8 darstellen kann (falls es nicht in die Ersatzhiroglyphe umgewandelt wurde), wird ein Fragezeichen angezeigt.
Das Fragezeichen ist das Ersatzzeichen für nicht darstellbare Zeichen (die fehlen im Zeichensatz).
Es nützt auch nix, wenn ich die Kollation dieser Tabelle auf utf8_general ändere. Ich versteh grad die Welt nicht.
Siehe oben, die Datenbank "denkt", es wäre ein normales Ansi oder westlich Zeichen das da vom Ansi oder westlich Formular-Dokument an die Datenbank gesendet wird.
Ich hatte mich damit auch schon ausgiebig beschäftigen dürfen und ganz klar, was da wirklich immer passiert, wird es wohl nie werden, vermutlich auch den Erfindern von utf-8 nicht.
Ich hatte auch Kollation utf-8 und bekam Fragezeichen in der Frontseite, aber komischerweise bekam ich es ordentlich im Backend (einer nativen Programmierung, kein Stangen-CMS) angezeigt. Woran lag es?
Die Backendseite hatte ich als utf-8 Dokument umgewandelt, aber nicht die Dokumente die die weitere Verarbeitung im Frontend machten, besonders nicht das HTML-Template.
Selbst die modifizierte HTTP-Header Übergabe als utf-8 half nichts, denn der Server ging davon aus, dass es westliche Codierung sei, die da als Zeichen auszugeben wäre, selbst wenn dann der Browser also Seiten-Codierung utf-8 angezeigt bekommen hat.
Es wurde wegen dem html-Template wohl doppelt gemoppelt, ein utf-8 codiertes Zeichen als westlich interpretiert und versucht, als utf-8 darzustellen.
Im Backend war es dagegen banal, da gab es noch nicht einmal eine Browseranweisung für die Darstellung in utf-8, es war einfach als utf-8 Zeichen, weil das Dokument utf-8 codiert war.
Dagegen war es nicht möglich, ein Zeichen direkt in der DB zu ändern, weil man so nicht direkt an die Daten heran kommt, es stand immer eine Eingabemaske dazwischen.
Ob die Kollation nun utf-8 war oder nicht, spielte für die Zeichenausgabe keine Rolle, aber bei phpmyadmin wurden bei westlicher Kollation nur Ersatzzeichen-Hiroglyphen angezeigt und bei utf-8 Kollation wurden die Zeichen in Klartext dargestellt.
VG,
Frank
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.
Das heißt: die von dir genannten Werte in 