String Enkodierung

[Fritz]

Hallo,

welche Möglichkeiten gibt es, die Kodierung eines Strings herauszufinden und diese ggf. rückgängig zu machen, wenn man nicht weiß mit was der alles so escaped und umgewandelt wurde? Gibts da ein Allheilmittel?

Ich nenne mal ein Bsp:

Der String: fswäöasd hat laut echo strlen("fswäöasd")  eine Länge von 10. Hole ich den selben String aus der DB und teste den, dann hat der ne Länge von 23. Also muss ja nen bißchen was dazugekommen sein. Leider weiß ich nun mal nicht, wie der vor dem INSERT bearbeitet wurde. Die Seite und auch die DB laufen unter UTF8.

Ich hoffe hier kann mir wer helfen.

Danke

[Sven Rautenberg]

Moin!

welche Möglichkeiten gibt es, die Kodierung eines Strings herauszufinden und diese ggf. rückgängig zu machen, wenn man nicht weiß mit was der alles so escaped und umgewandelt wurde? Gibts da ein Allheilmittel?

Nein, gibt es nicht.

Ich nenne mal ein Bsp:

Der String: fswäöasd hat laut echo strlen("fswäöasd")  eine Länge von 10.

Dann ist er in UTF-8 vorhanden.

Hole ich den selben String aus der DB und teste den, dann hat der ne Länge von 23. Also muss ja nen bißchen was dazugekommen sein.

Sicher, dass das nicht Whitespace ist?

Lass dir mal alle Teststrings als Hex-Darstellung ausgeben:
echo chunk_split(bin2hex($string), 2, " ");

Leider weiß ich nun mal nicht, wie der vor dem INSERT bearbeitet wurde. Die Seite und auch die DB laufen unter UTF8.

Das wirst du im Zweifel nachforschen müssen. Grundsätzlich wird die Datenbank aber kein so schreckliches Problem darstellen, wenn sie sowohl beim Schreiben, als auch beim Lesen auf die gleiche Weise falsch kontaktiert wird (d.h. ohne Angabe des Encodings der Connection - üblicherweise mit "SET NAMES utf8" als Query, oder mysqli::set_charset()).

- Sven Rautenberg

[Fritz]

Danke für den Tipp

echo chunk_split(bin2hex($string), 2, " ");

Den merke ich mir. War kein Whitespace, sondern einfach nur andere Darstellungen der Zeichen. Der DB-String wurde anscheinend vorher mit htmlentities bearbeitet, und der "normale" String halt in UTF-8. Muss ich halt schaun, wie ich die auf eine Ebene bekomme.
Ach und "SET NAMES utf8" ist gesetzt.

[Auge]

Hallo

War kein Whitespace, sondern einfach nur andere Darstellungen der Zeichen. Der DB-String wurde anscheinend vorher mit htmlentities bearbeitet, ...

Warum das? Einerseits ist im Normalfall htmlspecialchars zur Maskierung besser, weil es eben nicht alle Zeichen, die eine Entsprechung als HTML-Entity haben, sondern nur die, die in HTML eine Sonderrolle haben (<, >, &, "/'). Andererseits hat dies erst dann zu geschehen, wenn es zur Ausgabe kommt (das gilt für *alle* Aus- und Übergabemedien!), nicht vorher. Wenn du deine Zeichenkette in einem anderen Kontext als HTML verwenden willst, hast du mit &auml; etc. eine unpassende Maskierung.

Tschö, Auge

[dedlfix]

Hi!

Leider weiß ich nun mal nicht, wie der vor dem INSERT bearbeitet wurde. Die Seite und auch die DB laufen unter UTF8.

Es gibt speziell unter MySQL eine ganze Menge Möglichkeiten eine Zeichenkodierung zu konfigurieren. Entsprechend hoch ist das Missverständnispotential. Es ist durchaus üblich, dass man sich die falschen Werte anschaut und dann nicht die richtigen Schlussfolgerungen daraus zieht. (</archiv/2010/1/t194524/#m1301030>)

Grundsätzlich wird die Datenbank aber kein so schreckliches Problem darstellen, wenn sie sowohl beim Schreiben, als auch beim Lesen auf die gleiche Weise falsch kontaktiert wird (d.h. ohne Angabe des Encodings der Connection - üblicherweise mit "SET NAMES utf8" als Query, oder mysqli::set_charset()).

Das kann man so grundsätzlich nur sagen, wenn MySQL von Latin1 oder anderen 1-Byte-Kodierungen als Default-Verbindungskodierung ausgeht. (Latin1 ist zwar der Server-Default-Wert, lässt sich aber administrativ ändern.) Wenn man UTF-8 als Default-Wert (zumindest) für Verbindungen konfiguriert, dann gehen Latin1-kodierten Zeichen oberhalb von 0x80 verloren, weil sie üblicherweise keine gültige UTF-8-Sequenz bilden.

Lo!