✔ [ORACLE - PHP] Sonderzeichen

[südpol]

Hi,

ich habe das weitläufig im Internet bekannte Sonderzeichenproblem bei dem Einsatz von oracle in php. Ich habe schon alles getestet was ich mir dazu anlesen konnte jedoch habe ich noch keine Lösung für mein Problem gefunden :-(

Mein Problem stellt sich wie folgt da: Speichere ich einen Umlaut oder ein Sonderzeichen in die Datenbank z. B. ein § - Zeichen dann wird dieses laut meinem oracle client (sowohl auf windows wie auch auf linux Seite) richtig eingetragen. Gebe ich diese Textzeile nun wieder aus ohne Sonderzeichen zu maskieren so erhalte ich auch genau das was ich sehen will. Gebe ich nun jedoch dieses Sonderzeichen in einem input Feld wieder aus oder maskiere ich es mit htmlentities() dann erhalte ich jeweils ein für mich sonst unsichtbares Sonderzeichen §.

So gehe ich jetzt hin und gebe genau diese Variable in meine Logdatei aus dann schreibt er dieses Sonderzeichen ebenfalls - wandle ich den Text mit iconv von UTF-8 nach ISO-8859-1 um - dann steht der Text im Logfile richtig. Das ist jedoch sehr strange da ich mt folgenden Einstellunge sicherstellen wollte, dass alles auf UTF-8 läuft:

in der /etc/init.d/apache2:

export NLS_LANG=AMERICAN_AMERICA.UTF8
export NLS_LANGUAGE=AMERICAN

im html header jeder Datei:

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

im html Formular:

<form ... accept-charset="UTF-8">

zu Beginn jeder php Seite:

header("Content-Type: text/html;charset=utf-8");

Ich vermute also, dass es noch irgendwo eine Einstellung gibt, die dafür sorgt, dass etwas mit der Codierung nicht so läuft wie es sollte.

Kann mir jemand einen Ansatz liefern was ich noch machen kann?

 

[Pendergast]

Das gleiche Problem hatte ich erst vor kurzem auch mit MySQL. Hast du beim Verbinden zur Datenbank auch den zu verwendenden Zeichensatz gesetzt?

 

[südpol]

Hi,

ist leider eine mysql eigene funktion - oracle kennt diese funktion scheinbar nicht. Die Sprache wird hier, soweit ich das verstanden habe, über die Umgebungsvariable NLS_LANG gesetzt.

... ich glaube ich verbiete einfach die Deutsche Sprache in meiner Anwendung

 

[Pendergast]

resource oci_connect ( string username, string password [, string db [, string charset [, int session_mode]]] )

Wer redet denn hier von Sprache... versuch doch mal, charset als utf-8 zu übergeben.

 

[südpol]

ok Danke hatte ich vergessen Dort steht auch schon uft-8.

Ich glaube aber langsam, dass es ein html / php Problem ist. Ich bin nun mal hin gegangen und habe eine gettext string an eine php Variable übergeben und diese dann mit htmlentities maskiert. Gleiches Ergebnis wie oben! Darstellung ohne Maskierung geht - mit Makskierung kommt dass nette Sonderzeichn wieder mit.

@MODERATOR: Da es nun eher nach einem PHP Problem aussieht darf der Beitrag gerne dort hin verschoben werden. Danke!

 

[bk75]

Es gibt mehrere Möglichkeiten, hier ein paar Denkansätze (wie immer wenig Zeit). Das Problem ist in der Tat ein bekanntes Thema, egal zu welcher Datenbank.

Möglichkeiten:

- Man stellt die DB richtig ein, sodass von Anfang an der richtige Zeichensatz gespeichert und ausgegeben wird.

- PHP Man speichert den Content vorher mittels htmlentities() ab und lädt diesen so ein,

- PHP man kann Informationen via Befehl iconv() umwandeln

Nebeneffekte:
- Eingaben wie <> sowie Form-Tags werden bei falscher Behandlung der Codierung in Eingabeboxen höchst merkwürdig behandelt, auch werden codiert ausgegebene Informationen in solchen Boxen automatisch decodiert (Firefox zB), das bedeutet der Einsatz von htmlentities() wird empfohlen und man braucht ein bissl Geduld

- Die Volltextsuche nach Infos muss ggf vorher codiert werden, bevor man die Suche durchführt - kommt wieder darauf an wie die DB eingestellt ist usw.

Es ist ein bisschen Trixerei am Anfang aber es funktioniert.

 

[südpol]

Hi,

das mit dem Abspeichern der Sonderzeichen direkt als maskierte html Zeichen kommt leider nicht in Frage da ich einie Views aus anderen Datenbanken anspreche auf die ich keinen Einfluss habe. Da auf dem DB Server einige Anwendungen laufen kann ich leider auch an den locales nichts drehen - wobei das angeblich (lt oracle) kein Problem sein soll wenn der client auf dem Webserver die LC_Locals richtig gesetzt hat.

Wie schon beschrieben aktuell würde ich aufgrund des gettext "Problemchens" darauf tippen, dass die db garnichts dafür kann.

Gruß

 

[südpol]

Hi,

ok ich bin jetzt mal hin geganen und habe diesen gettextstring mit iconv behandelt:

$smarty->assign("test", iconv('UTF-8','ISO-8859-1', _("TEST_UMLAUTE")));

im Template:

{$TEST_UMLAUTE|escape:"htmlall"}

Die Ausgabe kommt richtig in meinem Browser an. Kann mir das jemand erklären? Ich hab dem Browser doch an zwei Stellen gesagt, er soll utf-8 nutzen!

Gruß

 

[südpol]

Hi,

ok das gettext bzw. smarty Problem konnte ich lösen. htmlentities kennt als Übergabeparameter (strings) 3 Werte. Einer davon ist charset. Wenn man sich das den ganzen Text auf php.net anschaut dann stellt man fest, das latin1 default ist - sprich diese bl*de funktion hat mir einfach alle meine übergebenen strings umgewandelt So mal sehen ob ich mein Datenbankproblem damit auch gelöst bekomme - ich schaue jetzt erst mal wleche php funktionen die ich verwende sonst noch so bescheidene default werte haben...

Gruß

 

[südpol]

... ok hab jetzt bei dem Thema oracle + php + utf8 aufgegeben es sollte einfach nciht sein. Kaum war ein Problem gelöst tauchte das nächste auf. Mit ISO-8859-1 gehts auch...

Danke für eure Hilfe und den Beistand