Hi,
Du meinst, UTF-8 transformierte Octet-Streams...?
wenn die so heißen - ja. Also es steht nicht, wie Du weiter unten beschreibst Hex-Codiert, sondern utf-8-codiert byte für byte quasi als latin-1 geschrieben, also aus ä wird ä und aus Ä wird Ä.
stehen als Feldinhalte in Text-Feldern von Datenbanken, die kein UTF-8 unterstützen?
genau, in MySQL 3.23 bzw. 4.0.x ... jaja, vielleicht sollte ich mich mal mit Version 4.1 beschäftigen ;-) - trau mich aber nicht.
Wenn im Feldinhalt "Höhe" als "48c3b66865" steht, Du aber nur WHERE feld = "Höhe" eingeben kannst, und Höhe eben in ISO-8859-1 "48f66865" ist, dann kann dort nichts übereinstimmen.
natürlich nicht so. Wenn das Suchformular ä als utf-8 abschickt, dann wird die DB schon nach ö gefragt. Das geht ja auch, aber Ä wäre eben eine ganz andere Bytefolge und da bräuchte man ja endlos Tabellen, welch utf-8 Zeichen als Gross-/klein zusammengehören.
Du hast keine Chance, nutze sie ;-)). Man könnte, wenn die Datenbank das anbietet, mit WHERE feld = "H".concat(0xc3b6).concat("he") suchen. Oder man könnte mit Hilfe des ersten Teils der Funktion von Christian, wo es um Zwei-Octet-UTF-8, beginnend mit c<0xe0 geht, die UTF-8-Octetstreams micht in Entities, sondern in 1-Byte-Hex-Werte umwandeln.
na, da kann ich auch bei ISO bleiben :-)
btw.: ist es in anderen Sprachen eigentlich auch so, daß es zwingend zusammengehörende Gross-/kleinVersionen von den Buchstaben gibt? Also, wie in Latin-1 eben ä und Ä zusammengehören und in MySQL ja auch nicht-case-Sensitiv im iso-Modus beide gefunden werden. Und kann MySQL 4.1 das erkennen?
Gruß, Andreas
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch