Problem mit Anzeige wg. falschem Zeichensatz

[ZapBee]

Hi,

ich habe hier eine Interbase-Datenbank (DB) unter Linux laufen. Ich habe einen ODBC-"Treiber" dafür, der zusammen mit einem Apache-Webserver mit PHP-Modul auf einem Linux-Rechner läuft. Ich greife mit PHP über ODBC auf die DB zu und möchte Datensätze im Browser (Win32) anzeigen.
Die Datenbank ist mit Werten gefüllt, die mit dem Zeichensatz "cp437" (aka dBase DEU cp 437) da reingeschrieben wurden.
Problem: Ich kriege die Sonderzeichen (ä, ß, €, ...) nicht richtig angezeigt. Ich müßte an irgendeiner Stelle sagen, daß die ausgelesenen Daten mit cp437 angezeigt werden sollen. Aber ich weiß nicht, Wo ich das Wem Wie sagen soll.
Probiert bisher:
1. Zeichensatz der *.php mittels "meta ... charset=..." auf cp437 umgestellt, aber den kennt der Browser wohl nicht
2. Versucht, die ASCII-Codes umzusetzen:
$name = ersetze_zeichen(chr(134), "ä", $name)
...

manches geht, aber manchmal kommt nur ein "Buchstabe" zurück, wo drei stehen müßten. Beispiel:
Name ist "Geißler", Rückgabe ist "Gei?r"
Da scheitert das Umsetzen natürlich.

Hat jemand einen Tipp für mich?

Zap

[zisoft]

Du musst beim Datenbank-Login den zu verwendenden Zeichensatz angeben, z.B. ISO8859_1, dann sollten die Zeichen korrekt zurück kommen.

Schau' Dir mal die PHP-Parameterübergabe für den Interbase-Login an, da müsste es möglich sein, den Zeichensatz zu übergeben. In PHP habe ich das noch nie gemacht, aber in Perl sieht das so aus:


my $db = DBI->connect (
"dbi:InterBase:database=$database;ib_dialect=3;ib_charset=ISO8859_1",
$db_user,
$db_passwd, {
RaiseError => 1,
AutoCommit => 0
}
);

[ZapBee]

Du musst beim Datenbank-Login den zu verwendenden Zeichensatz angeben, z.B. ISO8859_1, dann sollten die Zeichen korrekt zurück kommen.
Schau' Dir mal die PHP-Parameterübergabe für den Interbase-Login an, da müsste es möglich sein, den Zeichensatz zu übergeben. In PHP habe ich das noch nie gemacht, aber in Perl sieht das so aus:
Bei ODBC-Verbindungen gibt man nur die DSN an, auf dem Server sind dann alle Verbindungsdaten in der ODBC.ini gespeichert. Da gibts zwar eine Einstellung "charset", aber die hilft nicht weiter.
Bin seit Tagen mit den Support-Menschen für den ODBC-Treiber in Kontakt, die meinten am Ende, daß die übergebenen Zeichencodes (in Hex) falsch auf den Zeichensatz gemappt werden und daß ich das von Hand wandeln muß; erste Versuche siehe oben.
Aber ich denke, es wäre doch besser, wenn ich diesen Mapping-Fehler beheben könnte.

Zap

[LigH]

a) Du möchtest die Daten im Browser anzeigen. Der PHP-Preprozessor erzeugt als Ausgabe ein HTML-Dokument. Und im Header eines HTML-Dokumentes kann man die verwendete Codepage angeben (META content). Dadurch weiß der Browser, wie er es anzeigen muss.

b) Noch kompatibler: Lass die Umlaute als HTML-Entitäten ausgeben (ä => auml). Dazu gibt es in PHP die Funktion htmlentities (http://www.php.net/manual/de/function.htmlentities.php).

[ZapBee]

a) Du möchtest die Daten im Browser anzeigen. Der PHP-Preprozessor erzeugt als Ausgabe ein HTML-Dokument. Und im Header eines HTML-Dokumentes kann man die verwendete Codepage angeben (META content). Dadurch weiß der Browser, wie er es anzeigen muss.
Richtitsch, das meinte ich mit
1. Zeichensatz der *.php mittels "meta ... charset=..." auf cp437 umgestellt, aber den kennt der Browser wohl nicht
b) Noch kompatibler: Lass die Umlaute als HTML-Entitäten ausgeben (ä => auml). Dazu gibt es in PHP die Funktion
Das bringt leider garnix, denn es kommt ja kein "ä" an, welches ich wie auch immer ausgeben könnte.
Ich weiß leider nichtmal, ob aus der DB schon Schrott kommt oder der Webserver nur Zeichencodes bekommt, die er mangels richtigen Zeichensatz nicht interpretieren kann. Ich vermute letzteres, aber ... naja, weiß es halt nicht.

Zap

[LigH]

Vielleicht sind die Funktionen "recode_string" oder "iconv" brauchbar?!

[zisoft]

Wird auch nicht helfen, da er bereits aus der Datenbank die unbrauchbaren Zeichen erhält. Statt eines 'ä' kommt ein '?', was aber auch ein gültiges Zeichen aus dem normalen Zeichensatz wäre. Wie soll man jetzt zwischen einem echten Fragezeichen und einem verkorksten 'ä' unterscheiden?

@ZapBee: Welchen ODBC-Treiber verwendest Du? Für Interbase/Firebird gibt es doch eine ganze Menge.


EDIT:
Optional for the new InterSolv ODBC driver for InterBase:
8) Go to the Advanced tab and fill in the CharacterSet and Roles.


Quelle: http://www.kkhec.ac.ir/Touska%20Forum/Articles/Connecting%20via%20ODBC%20using%20Delphi%20or%20C++%20Builder.htm


EDIT2:
Probier' doch mal den FireBird ODBC-Treiber (http://firebird.sourceforge.net/index.php?op=files&id=odbc) (OpenSource), der sollte kompatibel zu Interbase sein.

[ZapBee]

Wird auch nicht helfen, da er bereits aus der Datenbank die unbrauchbaren Zeichen erhält. Statt eines 'ä' kommt ein '?', was aber auch ein gültiges Zeichen aus dem normalen Zeichensatz wäre. Wie soll man jetzt zwischen einem echten Fragezeichen und einem verkorksten 'ä' unterscheiden?

Das klingt erstmal logisch. Werds trotzdem probieren, siehe unten.
@ZapBee: Welchen ODBC-Treiber verwendest Du? Für Interbase/Firebird gibt es doch eine ganze Menge.
Es ist eine Interbase DB der Verion 4.0
Dafür gibts leider nicht so viele Treiber, der verwendete ist von Easysoft (http://www.easysoft.com). Sehr nette Leute übrigens, haben mir schon ganz schön weitergeholfen. Eigentlich wird nämlich nur Interbase 6+ unterstützt, die haben aber ein bißchen gebastelt und es auch für die 4er zum Laufen bekommen. Ich habe denen mal eine Beispiel-DB geschickt, die können bei sich die Daten auch korrekt anzeigen, es scheint also an der Konfiguration hier zu liegen...
Deshalb glaube ich auch, daß der Treiber die Daten aus der DB richtig holt und dann irgendwo zwischen PHP-Modul, Webserver und Browser ins Straucheln gerät.

Zap

[wodi666]

na vielleicht quick&dirty.. ist aber mehr dirty und nur als Beispiel gedacht...

function Zap2Bee($str)
{
for($i=0;$i<=strlen($str); $i++)
{
switch (ord($str[$i]))
{
case 142: $str[$i]=chr(196); //Ä
break;
case 132: $str[$i]=chr(228); //ä
break;
case 153: $str[$i]=chr(214); //Ö
break;
case 148: $str[$i]=chr(246); //ö
break;
case 154: $str[$i]=chr(220); //Ü
break;
case 129: $str[$i]=chr(252); //ü
break;
case 225: $str[$i]=chr(223); //ß
break;
}
}
return $str;
}



WoDi666

[ZapBee]

na vielleicht quick&dirty.. ist aber mehr dirty und nur als Beispiel gedacht...
habe ich probiert, siehe Thread-Eröffnung.

So, habe gerade recode_string() probiert, die ä's, ö's und ü's werden jetzt richtig angezeigt, aber bei den ß's hängts noch
mal kommt sowas wie "Stra`e des Friedens" raus, das ginge ja noch zu wandeln, aber bei sowas wie mit dem "Geißler" -> "Gei?r" oben scheiterts dann alles...
Auch schön:
der Mensch wohnt in der "Großstr."
Ausgabe: "Gro" :huh:
Es scheint, als würde das ß eine andere Bedeutung haben und die nachfolgenden n Zeichen {mit n>=0} mit beeinflussen...
Edit: Neuer Rekord: Aus "Müggelschlößchenweg" wird "Müggelschlög". Da fehlen mit ß dann sieben Zeichen... :kotz:

Zap

[wodi666]

Hast du schon mal iconv probiert?

[ZapBee]

Hast du schon mal iconv probiert?
Jup, leider auch kein Erfolg, fast gleiches Ergebnis wie mit replace_string, nur daß beim "Müggelschlößchenweg" jetzt nach dem ö garnix mehr kommt. http://cheesebuerger.de/images/smilie/konfus/n065.gif http://cheesebuerger.de/images/smilie/konfus/p095.gif http://cheesebuerger.de/images/smilie/konfus/n055.gif

Zap