Lokale Datenbank auf utf8 umstellen?

[QueenF]

Hallo,

ich habe eine Anwendung geschrieben, welche mit zwei Datenbanken arbeitet:

- Daten werden in einem XML-Schema mittels PHP & utf8_decode in eine Server-Datenbank geschrieben und von dieser auch wieder mittels PHP abgefragt

.... resultierende Form:
<contact>M. Müller</contact>

... Also alles in Ordnung ... spitze Klammern und auch Umlaute werden (sowohl in der Datenbank als auch nach Abfrage) korrekt dargestellt.

Diesen XML-String speichere ich nun in die lokale Datenbank, welche ich direkt mit Air erzeugt habe (Spaltenformat: Text). Frage ich die Daten nun wieder ab (nicht mehr über PHP, sondern direkt über SQLConnection mit Air), so erhalte ich:

&lt;contact&gt;M. Müller&lt;/contact&gt;

... Die Umlaute sind also noch da, aber die öffnenden und schließenden spitzen Klammer werden nicht korrekt übermittelt. Dadurch schafft es das Programm dann natürlich auch nicht den String wieder in eine XML aufzulösen und es kommt zu Fehlern ... Nun meine Frage, kann ich irgendwie beim Anlegen der DB oder DB-Tabellen festlegen, dass auch bei der lokalen DB utf8 verwendet werden soll?

Oder gibt es in Air eventuell einen analogen Befehl zum utf8_decode von PHP?

Ich danke euch schon mal für eure Antworten,

liebe Grüße!

[Martin Kraft]

Mit UTF-8 hat Dein Problem IMO nichts zutun, sonst würden nämlich in erster Linie die Umlaute dran glauben. In Deinem Fall werden jedoch "nur" die in XML reservierten Zeichen durch die zugehörigen Entities ersetzt.

Da ich das genaues Script zum Speichern und Auslesen dieser Daten nicht kenne, kann ich nur vermuten, dass die Daten irgendwann in einem XML basierenden Container tranportiert werden und irgendeine Funktion den Text zum Schutz html-escaped.

Loswerden könntest Du die Entities mit diesem Workaround:

PHP-Code:

var str:String = "<contact>M. Müller</contact>";
str = new XMLDocument(str).firstChild.nodeValue;

var xml:XML = new XML(str);

trace(xml.toXMLString()); // -> <contact>M. Müller</contact> 


Der ist allerdings nicht wirklich elegant, weshalb ich Dir raten würde, zunächst einmal nachzuforschen, wo und warum die oben beschriebene Konvertierung stattfindet und wie man sie umgehen könnte.

[QueenF]

Hallo und vielen Dank für den Tipp!!! Ich habe die Anweisungen nun eingebaut und alles funktioniert einwandfrei.

Leider finde ich jedoch die Stelle nicht, in der die Zeichen gewandelt wurden (alle Forschungen landen letztlich wieder bei der lokalen Datenbank).

Ich versuche mal den Workflow des Programmes kurz darzustellen, vielleicht hat ja Jemand eine Idee woran es liegen könnte.

Also, in der Server-Datenbank gibt es eine Tabelle mit einer Spalte "data", in dieser werden über PHP (utf8_decode) die Daten in XML-Form gespeichert. Schaut man sich den DB-Eintrag an, so werden alle Zeichen korrekt dargestellt.

Die Abfrage erfolgt ebenfalls über PHP, nur werden hier die abgefragten Inhalte in einem XML-Dokument gespeichert, etwa in der Art:

$xml = new DOMDocument("1.0","utf-8");
...
$node = $xml->createElement("data", $daten->data);
$item->appendChild($node);
...
header('Content-type:text/xml');
echo $xml->saveXML();

Die so abgefragten Inhalte der Tabelle werden in der AIR-Anwendung als eine Variable vom Typ XML behandelt (loadedData:XML) und wie folgt verarbeitet/gespeichert:

for each (serverItem in loadedData.item){
.... (SQL-Insert-Statement) ....
sqlStmt.parameters[':data'] = serverItem.data.text();
sqlStmt.execute();
}

Ein trace(serverItem.data.text()) an dieser Stelle ergibt noch eine Ausgabe in der gewünschten Form. Also obwohl die XML-Daten bei der PHP-Abfrage in einem weiteren XML-Dokument transportiert wurden, existieren hier noch die spitzen Klammern und sollten somit eigentlich auch in der lokalen DB gespeichert werden.

Zur Abfrage aus der lokalen DB wird ein SQLStatement verwendet und das Resultat wird in einer ArrayCollection gespeichert (var results:ArrayCollection = new ArrayCollection(); results.source = result.data as Array

Über results.source[0].data; wird nun im Weiteren auf die Daten zugegriffen um diese weiterzureichen und zu verarbeiten ... gibt man sie an dieser Stelle jedoch nochmals mittels trace aus, so wurden die spitzen Klammern ersetzt.

An welcher Stelle könnte es denn zu dieser Konvertierung kommen und wie kann man das umgehen?

Schon mal Danke für alle Hinweise und schönen Abend noch!

[QueenF]

Ich habe noch einmal nachgeforscht - der Fehler geschieht tatsächlich an der Stelle, an der ich mit PHP die Resultat-XML erzeuge, also bei folgendem Code:

Die Abfrage erfolgt ebenfalls über PHP, nur werden hier die abgefragten Inhalte in einem XML-Dokument gespeichert, etwa in der Art:

$xml = new DOMDocument("1.0","utf-8");
...
$node = $xml->createElement("data", $daten->data);
$item->appendChild($node);
...
header('Content-type:text/xml');
echo $xml->saveXML();

Das Attribut $data->data ist ebenfalls in XML-Struktur und alle XML-basierenden Zeichen werden gewandelt, sobald ich es als Node hinzufüge.

Problem ist jedoch, dass die data-XML Usereingaben beinhaltet (Also unter Umständen auch & und < oder >). Aus diesem Grund sind alle Felder in dieser data-XML mit CData gekennzeichnet. Da jedoch alle spitzen Klammern gewandelt werden, wird auch das CData nicht mehr erkannt und ich bekomme ständig Fehler.
Frage ist nun, ob es möglich ist eine XML in einer weiteren XML zu transportieren ohne das alle Zeichen gewandelt werden ... und wenn ja, wie ich das Wandeln umgehen kann ...

Ich danke euch für eure Hinweise!

[Martin Kraft]

Es zwingt Dich ja nimand mit der DOMDocument-Klasse zu arbeiten. Bau das XML doch einfach so zusammen, wie Du mit PHP auch HTML ausgeben würdest: mit Strings und echo.