Sonderzeichen / Datenbank / PHP

[Absolute Beginner]

Hi, habe mir ein einfaches PHP Script gebastelt mit dem ich per Forumlar Texte in eine MySql Datenbank schreibe und auslese. Bisher hat alles auch wunderbar geklappt, aber seit heute bekomme ich bei der Ausgabe von Sonderzeichen wie ü,ä,ö,á,é etc. nur ein Fragezeichen angezeigt.

a) was muss ich machen damit die Daten richtig verarbeitet werden? soll ich die Inputfelder bevor ich den Input in die Datenbank schreibe mit htmlentities (oder ähnlicher Funktion) umwandeln? - Sozusagen für zukünftige Datensätze.

b) anscheinend habe ich ja die falsche Codierung auch in der DB benutzt (hab gerade leider keinen Zugriff auf die Admin Oberfläche um nachzusehen, welche Codierung ich benutzt habe) - kann ich die Codierung ggfls.ändern, ohne die Datensätze zu beeinflussen, oder muss ich die kompletten Datensätze neu einlesen. Bzw. welche Möglichkeit besteht das bei der Ausgabe zu "reparieren"?

c) woran kann es liegen, dass mir die Daten monatelang "richtig" - also sagen wir mal lieber wie gewünscht - angezeigt werden und nun auf einmal nicht mehr?

Wäre echt klasse wenn ihr mir helfen könnt!

Danke Newbe

[Absolute Beginner]

ok, konnte mittlerweile mal in die DB schauen… Also Kollation latin1_swedish_ci - ist anscheinend der Default Wert, kann mich nicht erinnern da was aktiv angegeben/geändert zu haben (was vermutlich ein Fehler war?! Wäre es besser auf UTF-8 zu switchen??)

Allerdings, die Daten sind ganz klassisch mit ü,ä,ö, etc. vorhanden. Habe aber gesehen (hatte ich vergessen), dass ich Daten die ich über ein Textarea eingebe anders behandel als die, die über ein "normales" Textfeld kommen (sorry bin newbe, und habe da nicht konsistent gearbeitet): Bei Daten die über Textfeld ankommen steht in der DB z.B. "über" bei denen die über Textarea ankommen steht in der DB "über" - also so wie es eigentlich sein sollte… (und die auch beim Auslesen richtig dargestellt werden)

Was muss ich machen um bei der Ausgabe für beide Feldern "über" ausgegeben zubekommen? Denke ich muss jedes Ausgabe auf Sonderzeichen überprüfen und diese entsprechen in html umwandeln, gibt es dafür eine Funktion, die alle Sonderzeichen automatisch umfasst, oder muss ich mir selber überlegen, welche Sonderzeichen vorkommen könnten - sind ja nicht nur die Umlaute - und diese dann mit replace behandeln?

Klar für zukünftige Daten muss ich darauf achten, dass vor der Eingabe in die DB die Sonderzeichen entsprechend umgewandelt werden, aber es wäre echt viel Lehrgeld, wenn ich die kompletten Daten neu eingeben müsste.

Hoffe ihr könnt mir weiterhelfen.

[Rolf b]

Hallo Beginner,

in der DB sollte nicht ü stehen, das ist eine HTML Codierung, die nur für die Ausgabe verwendet werden sollte.

Es ist mittlerweile auch üblich, dass Browser Unicode verstehen, du kannst also problemlos deine Ausgabe mit UTF-8 codieren und brauchst Umlaute nicht zu verschlüsseln. Möglicherweise lieferst Du einen Response-Header aus, der UTF8 sagt, und codierst aber in Latin1 (ISO 8859-1), oder umgekehrt. Dann werden alle Zeichen, deren Code über 128 liegt, falsch dargestellt.

Rolf

[Absolute Beginner]

Hi Rolf,

danke schonmal. Wenn ich dich recht verstehe müsste es in meinem Fall langen wenn ich im Head angebe

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

oder sollte ich, nachdem die DB Kollation ja latin1_swedish_ci ist angeben ISO 8859-1

Oder mache ich es mir da zu einfach??

Grüße Newbe

[Auge]

Hallo

Wenn ich dich recht verstehe müsste es in meinem Fall langen wenn ich im Head angebe

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Nein.

oder sollte ich, nachdem die DB Kollation ja latin1_swedish_ci ist angeben ISO 8859-1

Nein.

Oder mache ich es mir da zu einfach?

Ja.

Es reicht nicht, einfach nur zu behaupten, das Dokument würde in der Kodierung UTF-8 vorliegen, wenn nicht sicher ist, dass dies auch tatsächlich so ist. Wenn du im Meta-Element „Content-Type“ sagst, dass es sich um den Typ „text/html“ in der Kodierung „UTF-8“ handelt, musst du auch sicherstellen, dass das Dokument mit seiner HTML-Struktur und seinem Inhalt dieser Angabe genügt.

Und um das „nein“ bezüglich der Verwendung von ISO 8859-1 zu unterfüttern, sei gesagt, dass es wohl kaum einen Grund gibt, diese Kodierung mit beschränktem Zeichenvorrat UTF-8 vorzuziehen, wenn man mit UTF-8 so ziemlich alle auf diesem Planeten bekannten Schriftsysteme abbilden kann. Schon die Verwendung von diakritischen Zeichen aus europäischen Sprachen, die auch in der detuschen Sprache verwendet werden, kann mit ISO-8859-1 problematisch werden, ist es aber in UTF-8 nicht.

Das bedeutet, wenn man dieser Empfehlung folgen will, dass sowohl das HTML-Template in UTF-8 vorliegen muss ^[1], als auch, dass die Nutzdaten, egal, woher sie stammen, dieser Kodierung entsprechen müssen. Das gilt …

• … für deine Datenbankverbindung, mit der du die Daten aus der Datenbank holst. Lege für sie explizit fest, dass du in der Kodierung UTF-8 mit der Datenbank kommunizieren willst, damit die Daten auch in UTF-8 an dich herausgereicht bzw. beim schreiben an die Datenbank übergeben werden. Welche Funktion dafür zu benutzen ist, kommt auf die Funktionen an, die du für die Verbindung mit der Datenbank benutzt.
• … für deine PHP-Skripte, die die Daten aus der Datenbank verarbeiten und daraus eine Ausgabe generieren und genauso für jene Skripte, die Eingaben für die Datenbank aufbereiten und sie an diese zum speichern übergeben. Dazu beschäftige die mit den Multibyte-String-Funktionen, die du statt der normalen String-Funktionen benutzen musst und speziell der Funktion mb_internal_encoding, mit der du für den Skriptlauf festlegst, dass alle Stringverarbeitungen in der Kodierung UTF-8 erfolgen werden.
• … schlussendlich auch für die Auslieferung deiner generierten oder statischen HTML-Dokumente an die Clients (z.B. Browser). Hier – und erst hier – kommt dein Meta-Element ins Spiel. Es ist allerdings nur Ersatz für den vom Webserver oder PHP-Skript gelieferten HTTP-Header für die benutzte Kodierung für den Fall, dass dieser, aus welchen Gründen auch immer, nicht vorhanden ist.

Tschö, Auge

---

1. Das HTML-Gerüst selbst könnte auch in einer anderen, zu UTF-8 kompatiblen Kodierung vorliegen. Aber das will man nicht, weil man so bei späteren Änderungen immer darauf achten müsste, dass sich an der Kodierung nichts ändert. Da die Kodierung nicht in irgendwelchen Metadaten einer Datei gespeichert werden kann, erraten die Editoren sie anhand des Inhalts, liegen dabei aber gelegentlich auch falsch. ↩︎

[Gunnar Bittersmann]

@@Rolf b

Es ist mittlerweile auch üblich, dass Browser Unicode verstehen, du kannst also problemlos deine Ausgabe mit UTF-8 codieren und brauchst Umlaute nicht zu verschlüsseln.

Das war auch vorher schon so. Die Zeiten, als Browser nicht einmal ISO 8859-1 verstanden, sind schon seeehr laaange her.

LLAP 🖖

[TS]

Hello,

nimm besser utf8_general_ci.
Nur für Passwortspalten o. ä., wo Klein-/Großschreibung relevant ist, müssen wir uns was anderes ausdenken. Entweder utf_bin nehmen, oder den Spaltentyp varbinary. Da muss ich aber selber nochmal gucken, ob der Spaltentyp die *_ci überschreibt.

Liebe Grüße
Tom S.

[MudGuard]

Hi,

Nur für Passwortspalten o. ä., wo Klein-/Großschreibung relevant ist, müssen wir uns was anderes ausdenken.

Gibt es Hash-Funktionen, deren Output case-sensitive ist?

Denn man speichert ja niemals das Paßwort selbst …

cu,
Andreas a/k/a MudGuard

[TS]

Hello,

Nur für Passwortspalten o. ä., wo Klein-/Großschreibung relevant ist, müssen wir uns was anderes ausdenken.

Gibt es Hash-Funktionen, deren Output case-sensitive ist?

Denn man speichert ja niemals das Paßwort selbst …

Ich hatte es kaum geschrieben, da wusste ich schon, dass dieser Einwand kommen würde.

Es gibt Funktionen, bei denen auch Groß- und Kleinschreibung herauskommen kann. Aber das ist ja auch unerheblich ob dieses Ergebnis aus einer Funktion kommt. Ich hatte deshalb extra dazugeschrieben "wo Groß- / Kleinschreibung relevant ist".

Viel wichtiger ist es, dass es nochmal genau überprüft wird, was MySQL da treibt. Die Beschreibungen dazu sind nämlich äußerst verwirrend.

Liebe Grüße
Tom S.