Umlaute im Popup des CSV-Scripts des Netzwolf

Moins,

salbi wrote:

Alle Ausgabefelder, die ich erzeuge, werden korrekt angezeigt, bis auf das Popupfeld. In diesem Werden die Umlaute als Raute mit ? gezeigt.
An der DB und am Datensatz kann es nicht liegen, weil wie gesagt alle anderen Felder korrekt sind und den gleichen Zeichensatz verwernden. Die query fällt auch raus. Hat jemand eine Idee?

Die Popup-Daten werden per JavaScript/XmlHttprequest angefordert. Das Serverside-Script liefert die Daten in einer bestimmten Zeichencodierung aus. Wenn eine andere Codierung als ISO-8859-1 benutzt wird, *muss* diese Codierung im Header der Antwort angegeben werden. In PHP erreicht man das mit “header("Content-Type: text/plain; charset=YOUR-CHARSET-HERE")”.

Wenn der Server lügt, also eine andere Codierung angibt als die wirklich verwendete, decodiert das JavaScript/XmlHttpRequest die empfangenen Bytes mit den falschen Tabellen/Regeln und erzeugt so falsche Zeichen oder aber kann bestimmte Byte-Sequenzen überhaupt nicht decodieren und macht daraus einen "Error-Character-Placeholder".

Der Fehler ist wahrscheinlich verursacht durch unüberlegtes Übernehmen meines “;charset=UTF-8”.

Gruß Wolf

Hallo,
wenn ich das also richtig verstehe, dann muß die Datenbank, die DB-Tabellen, die Datensätze und die PHP Abfrage den gleichen gleichen Zeichensatz wie die Website verwende?
Grus salbi

salbi wrote:

wenn ich das also richtig verstehe, dann muß die Datenbank, die DB-Tabellen, die Datensätze und die PHP Abfrage den gleichen gleichen Zeichensatz wie die Website verwende?

Nein! Du musst es nur auf der einen oder anderen Stelle konvertieren.

Nahmd,

salbi wrote:

wenn ich das also richtig verstehe, dann muß die Datenbank, die DB-Tabellen, die Datensätze und die PHP Abfrage den gleichen gleichen Zeichensatz wie die Website verwende?

Nein. Du kannst gleichzeitig beliebig viele unterschiedliche Codierungen nutzen. Musst die aber jeweils dem Browser mitteilen, denn der versucht nicht listig zu raten, sondern nimmt bei fehlender Angabe ISO-8859-1 an.

Technisch übertragen wird die Encodierung im HTTP-Header: “Content-Type: text/xyz; charset=XXX-YYY-ZZZ”. Wie man diesen Header erzeugt, hängt vom Webserver ab. Der Apache kennt dazu als Rules zum Beispiel:

AddDefaultCharset␣utf-8
AddType␣"text/html;charset=utf-8"␣.html

Aus PHP heraus kannst Du beliebige Header mit der “header("Tag: Value")”-Funktion erzeugen.

viw wrote:

salbi wrote:

wenn ich das also richtig verstehe, dann muß die Datenbank, die DB-Tabellen, die Datensätze und die PHP Abfrage den gleichen gleichen Zeichensatz wie die Website verwende?

Nein! Du musst es nur auf der einen oder anderen Stelle konvertieren.

Es reicht, das Encoding anzugeben. Um alles weitere kümmert sich der Browser.

Gruß Wolf

Seit mir nicht böse, aber ich verstehe nur Bahnhof. Wo muss ich nun was angeben und woher bekomme ich die Info welcher Zeichensatz wo gerade eingesetzt wird.
Es ist nicht so, dass ich mich nur auf euch verlasse. Ich suche schon seit Stunden nach einer genauen (einfach zu verstehenden) Erklärung des ganzen.
Gruß
aalbi

Es ist ziemlich schwierig, rauszukriegen, wie bei dir die Daten gespeichert sind, wie sie in PHP aufgerufen werden (mysql kann da recht flexibel sein und das beim Auslesen konvertieren).

Deshalb würde ich zwischen Auslesen aus der DB und Ausgabe entweder die Texte von latin1 in utf8 verwandeln oder umgekehrt. Eines davon sollte das richtige Ergebnis bringen....

Grüße, Max

Also,
so, wie ich das sehe, besteht hier ein Missverständnis. Ich will es mal versuchen aufzuklären.
1. Ich habe eine Seite mit Joomla angelegt. Joomla verwendet UTF8.
2. In die index.php habe ich das Netzwolf JS implementiert.
3. Die CSV-Abfrage habe ich zur SQL-Abfrage umgefummelt.
4. Habe ich eine Joomla Gästebuch-Ext. umgefummelt, um die Daten aus der OSM zusammen mit den Benutzerinfos ins Joomla zu bekommen.
Soweit funktioniert auch alles.
Die über das GB in die DB eingetragenen Daten werden auch korrekt im Gästebuch dargestellt (inkl. Umlaute). Lediglich im Popup und im Tooltip des Netzwolf-Skripts werden die Umlaute zerschossen.
Da die Inhalte überall korrekt dargestellt werden und Joomla 2.5 mit UTF8 arbeitet, glaube ich nicht, dass das Problem an der Codierung meiner Seite liegt, sondern eher an dem, was mir das Netzwolf Skript im Popup / Tooltip zurück liefert. Oder?

salbi wrote:

Da die Inhalte überall korrekt dargestellt werden und Joomla 2.5 mit UTF8 arbeitet, glaube ich nicht, dass das Problem an der Codierung meiner Seite liegt, sondern eher an dem, was mir das Netzwolf Skript im Popup / Tooltip zurück liefert. Oder?

Ich würde es einfach mal mit konvertieren versuchen. Entweder behauptet Joomla es würde utf8 senden, sendet aber latin1 in die Popups, oder umgekehrt. An der Frage, wie ein Zeichen dargestellt werden soll, spielt der Apache mit (so wie in #5 beschrieben), PHP darf auch den Header manipulieren (#2) und die Datenbank darf auch noch mitspielen.

Offensichtlich sind sich die drei einig, was das Gästebuch betrifft. Das könnte z.B. daher kommen, dass das Gästebuch vor seinen Datenbankabfragen den Zeichensatz angibt. Dein CSV-Script tut das nicht. Oder es könnte daran liegen, dass Joomla nach den Abfragen alle Ausgaben konvertiert. Egal wer schuld ist, ein schlichtes "utf8-encode" oder "decode" wäre vermutlich ein Schritt zur Lösung.

Egal wer schuld ist, ein schlichtes "utf8-encode" oder "decode" wäre vermutlich ein Schritt zur Lösung.

Äh, mal blöd gefragt: Und wie geht das?

salbi wrote:

Egal wer schuld ist, ein schlichtes "utf8-encode" oder "decode" wäre vermutlich ein Schritt zur Lösung.

Äh, mal blöd gefragt: Und wie geht das?

Ich kenne Dein Programm nicht.... Du hast doch sicher irgendwas in der Art

echo␣"\t$name\t...."

drinstehen. Das schreibst Du probehalber mal

$konvertiertername=utf8_decode($name);␣echo␣"\t$konvertiertername\t...."

Alternativ probierts du das mit auch utf8_encode. Kannst ja erstmal mit einem der Datenfelder anfangen und schaun, ob das ? weggeht.

Hat funktioniert,
danke.