[Erledigt] Kodierungsfehler

[Forumsgast]

Hi, ich habe für meine FH die Aufgabe eine Datenbankanwendung auf Basis von PHP zu entwickeln. Als Datenbank steht mir eine Oracle-Datenbank zur Verfügung.

Mein Problem ist, dass Oracle keine Sonderzeichen beherrscht (jedenfalls nicht die uns zur Verfügung gestellte). Um die zu umgehen wollte ich alle Sonderzeichen welche auftreten mit str_replace() ersetzen.

jedoch scheint es bei der Übertragung der Daten via $_POST oder $_GET zu einem Kodierungsfehler zu kommen.

$search=$_GET['search'];
echo strlen($search);
echo strlen("ä"); 

Das stückchen Code sollte eigentlich wenn in $_GET['search'] auch ein ä gespeichert ist mir

2
2

ausgeben.
Die wirkliche ausgabe ist aber leider

1
2

Damit ist auch klar warum str_replace() lange suchen kann und nie ein sonderzeichen zum ersetzen findet.

Das Problem liegt also in der Kodierung und auch meine Versuche in UTF-8 ohne BOM zu speichern, was bei anderen mit dem selben Problem zur Lösung führte, brachte kein verändertes ergebnis (ausser ich war zu dämlich die Kodierung richtig zu ändern).

Und so langsam bin ich verzweifelt. Wenn einer von euch eine Idee hat wäre ich sehr verbunden

Informationen die vielleicht noch nützlich sind:

PHP-Dateien liegen auf einem Server der FH, OS: Linux (sry genauer weiss ichs echt nicht)
Editor: Netbeans 7.0.1
aktuelle Kodierung angegeben von Netbeans UTF-8

Ziel: Werte die via $_POST oder $_GET empfangen wurden nach Sonderzeichen zu durchsuchen und diese zu ersetzen

[Forumsgast]

Mein Problem ist, dass Oracle keine Sonderzeichen beherrscht

Und deshalb baust du jetzt - sorry - so einen Scheiss ein? Frag lieber vorher nochmal nach, ob das wirklich der Fall ist. Kann ich mir nicht wirklich vorstellen ...

[Forumsgast]

Und deshalb baust du jetzt - sorry - so einen Scheiss ein? Frag lieber vorher nochmal nach, ob das wirklich der Fall ist. Kann ich mir nicht wirklich vorstellen ...

Hab meinem Dozenten diesbezüglich schon mehrfach gesagt das er nur die verwendete Zeichentabelle des Servers ändern müsste. Macht er aber nicht also brauch ich ne Lösung mit Ersetzung.

[Forumsgast]

Hab meinem Dozenten diesbezüglich schon mehrfach gesagt das er nur die verwendete Zeichentabelle des Servers ändern müsste. Macht er aber nicht also brauch ich ne Lösung mit Ersetzung.

rawurlencode() + urldecode()

Das erhält die Daten im Gegensatz zu deinem str_replace()-Ansatz.

Mit strlen() kannst du hernach trotzdem nicht arbeiten: UTF-8-Codepoints haben sowieso unterschiedliche Bytelängen, aber rawurlencode() macht das ganze noch etwas länger.

Außerdem müssen in jeder Datenbankabfrage die Strings entsprechend kodiert und zurückgegebene Daten wieder dekodiert werden.

Zusätzlich funktionieren String-Vergleiche oder die Groß-Kleinschreibung-tolerierende Suche innerhalb der Datenbank nicht mehr richtig (Stichwort: Collations). Die Datenbank degeneriert dann zu einem "dummen" Datenspeicher. Da kannst du auch gleich SQLite benutzen.

Das Ganze wäre also nur ein hässlicher Workaround für eine kranke Situation. Wir haben 2011. Unicode ist Standard. Datenbanken können damit schon seit Jahr(zehnt)en umgehen. Wenn da irgendwer zu blöd ist, das korrekt einzustellen, soll er dich nicht damit belasten, dafür hässliche Umgehungen zu basteln. Bitte nenne den Namen dieser Fachhochschule, damit zukünftige Studenten davor gewarnt sind.

*update*

Der PHP-PDO-Oracle-Treiber erlaubt das Einstellen der Zeichenkodierung beim Öffnen der Datenbankverbindung über die Option "charset" im DSN: http://www.php.net/manual/en/ref.pdo-oci.connection.php

Allerdings ist der PDO-Treiber selbst immer noch als experimentell gekennzeichnet (und das seit 2004).

...
jedoch scheint es bei der Übertragung der Daten via $_POST oder $_GET zu einem Kodierungsfehler zu kommen.

$search=$_GET['search']; 
echo strlen($search); 
echo strlen("ä"); 

Das stückchen Code sollte eigentlich wenn in $_GET['search'] auch ein ä gespeichert ist mir

2
2

ausgeben.
Die wirkliche ausgabe ist aber leider

1
2

Damit ist auch klar warum str_replace() lange suchen kann und nie ein sonderzeichen zum ersetzen findet.

Das Problem liegt also in der Kodierung und auch meine Versuche in UTF-8 ohne BOM zu speichern, was bei anderen mit dem selben Problem zur Lösung führte, brachte kein verändertes ergebnis (ausser ich war zu dämlich die Kodierung richtig zu ändern).

Deine Kenntnisse bezüglich Zeichenkodierungen scheinen mir ausbaufähig:

Eine (Pseudo-)BOM hat hier erstmal nichts verloren.

Wenn ein 'ä' die "Länge" 1 Byte hat, dann ist der Buchstabe in einer Single-Byte-Kodierung gespeichert. Man darf hier ISO-Latin-1 oder einen seiner Stiefgeschwister (8859-15, Win-1252) vermuten. Ist das 'ä' 2 Byte lang, dann liegt es in Unicode vor. Wir nehmen mal UTF-8 an, weil PHP (derzeit) nichts anderes wirklich richtig kann.

In deinem Fall stellt sich das so dar: Per GET hat der Client dem Server ein 'ä' in einer Single-Byte-Kodierung übertragen.

Dein zweites 'ä' hast du dagegen in einem Unicode-fähigen Texteditor erzeugt. Und es steht im Quellcode des PHP-Scripts als UTF-8-kodierte 2-Byte-Folge. Das kannst du mit einem Hex-Editor leicht nachprüfen.

Wenn du Benutzerdaten entgegennimmst und diese als Unicode in die Datenbank sollen, muss dein Script erstmal dem Client sagen, dass er UTF-8 liefern soll.

Dazu sollte das HTML und das darin eingebettete Formular die entsprechenden Attribute gesetzt haben. Außerdem muss der Server entsprechende Header ("Content-Encoding") setzen.

Da manche komische Clients trotzdem etwas anderes liefern, sollte man die Kodierung bei Entgegenname überprüfen. Kommt ISO-Latin-1 an, kann man zumindest daraus mit utf8_encode() noch UTF-8 machen.

Kurze Einführung: http://de.selfhtml.org/html/formular...ichenkodierung

Informationen die vielleicht noch nützlich sind:

PHP-Dateien liegen auf einem Server der FH, OS: Linux (sry genauer weiss ichs echt nicht)

Nicht sehr hilfreich. Angaben zum Webserver und Datenbank-Client-Treiber wären nützlicher gewesen. Phpinfo() ist dein Freund. Es gibt aber noch einige PHP-Funktionen mehr, die Interna übers System ausplaudern.

Editor: Netbeans 7.0.1
aktuelle Kodierung angegeben von Netbeans UTF-8

Script-Quelltexte in einer anderen Unicode-Kodierung kann PHP sowieso nicht ausführen.

Ziel: Werte die via $_POST oder $_GET empfangen wurden nach Sonderzeichen zu durchsuchen und diese zu ersetzen

Es gibt in diesem Fall so etwas wie "Sonderzeichen" nicht. Das 'ä' ist bspw. ein ganz gewöhnlicher Buchstabe.

[Forumsgast]

Danke für die ausführliche Erklärung, werde mal schauen das ich sowohl das HTML gerüst als auch das ganze PHP auf UTF-8 umsetze.


Da meine PHP/HTML-Kenntnisse vor 6 Wochen noch 0 Waren muss ich aber auch gestehen das ich mich über eine Hilfestellung wie ich den HTML-teil auf UTF-8 setze sehr freuen würde.

Zur der FH. Es ist die FH Brandenburg im Studium Wirtschaftsinformatik. An sich ganz nett aber die IT sollte man feuern und durch Leute ersetzen die im 21 Jahrhundert angekommen sind.

Und für die Aufgabe wäre ein SQLite völlig ausreichend aber wir sollen halt diese Oracle-Datenbank nehmen über die ich leider nichts aussagen kann da alle eingaben über ein vom Dozenten (recht schlecht) erstelltes PHP-Interface laufen.

EDIT: DAAAAANKEEEE, 2 Nächte hab ich mir um die Ohren geschlagen nur weil ich unterschiedliche Kodierungen hatte....

@FireWeasel: Super Erläuterung des Problems und schöne Lösung eines idiotischen Problems
Wenns Facebook wär gebs nen großen Dauem hoch für dich