Umlaute werden falsch dargestellt

Beitrag von **Wirths Media** » 22.06.2006, 19:48

Das komische ist, wenn ich den String umwandele in ü mag er ihn nicht mehr???

	preg_match&#40;"/<\?xml&#40;.*&#41;<\/RESPONSE>/Uis", $return, $return&#41;;

	$trans = array&#40;"ä" => "&auml;", "ö" => "&ouml;", "ü" => "&uuml;"&#41;;
	$return&#91;"0"&#93; = strtr&#40;$return&#91;"0"&#93;, $trans&#41;;


echo $return&#91;"0"&#93;;
	$xml = simplexml_load_string&#40;$return&#91;"0"&#93;&#41;;

von **Anzeige von ABAKUS** »

Content Erstellung von ABAKUS Internet Marketing
Ihre Vorteile:

einzigartige Texte
suchmaschinenoptimierte Inhalte
eine sinnvolle Content-Strategie
Beratung und Umsetzung

Jetzt anfragen: 0511 / 300325-0

Beitrag von **Kristian** » 22.06.2006, 19:51

Hallo

Ähhhmmm, nein.
well-formed bedeutet bei XML auch UTF-8, die ganze PHP-XLIB-Geschichte ist doch rein UTF-8
Versuch vorher mal ein

Code: Alles auswählen

utf8_encode&#40;$data&#41;

du kannst es ja nachher wieder

Code: Alles auswählen

utf8_decode&#40;$data&#41;

zurücksetzen.

Gruss Kristian

Beitrag von **Wirths Media** » 22.06.2006, 19:56

Weisst Du zufällig, wie man es dann später in ISO umwandelt??

Die ganze Seite ist in ISO naja eigentlich ist es ja nur ne Zeile in den Meta angaben, binn aber eigenwillig...

von **Anzeige von ABAKUS** »

Beitrag von **oldInternetUser** » 22.06.2006, 20:01

calusa-xx hat geschrieben:Das komische ist, wenn ich den String umwandele in ü mag er ihn nicht mehr???

Das ist zu erwarten, weil die Entities uuml usw. nicht definiert sind.

Kristian hat geschrieben:well-formed bedeutet bei XML auch UTF-8

Das ist falsch - well-formed hat nichts mit der Codierung zu tun. Wäre der String nicht wohlgeformt, würde das Laden nicht funktionieren.

calusa-xx hat geschrieben:Im Browser werden die Daten (ausgabe mir print_r) vor simplexml_load_string richtig dargestellt...

Welcher Browser? Der Firefox ist, wenn ich es richtig in Erinnerung habe, in bezug auf Codierungen 'sehr großzügig'. Nimm mal den IE6.

Beitrag von **Wirths Media** » 22.06.2006, 20:05

Welcher Browser? Der Firefox ist, wenn ich es richtig in Erinnerung habe, in bezug auf Codierungen 'sehr großzügig'. Nimm mal den IE6.

War der IE6

Sende und empfange den XML String jetzt in UTF-8

Jetzt muss ich halt alle utf8_decode($xml->Ausgabe) aber so funktioniert es wenigstend.

Besten Dank noch mal an alle und schööööönen Abend

Gruß
Daniel

Beitrag von **Kristian** » 22.06.2006, 20:07

Hallo
@oldInternetUser
Mit der Begründung, dass bei XML, UTF-8 der Standardschriftsatz ist, stimmt es aber zumindest halb?

@calusa-xx
Wie oben gesagt utf8_decode() bevor dus raushaust.

Gruss Kristian

Beitrag von **oldInternetUser** » 22.06.2006, 20:17

Kristian hat geschrieben:@oldInternetUser
Mit der Begründung, dass bei XML, UTF-8 der Standardschriftsatz ist, stimmt es aber zumindest halb?

Es stimmt zwar, daß UTF-8 die Standardcodierung ist (mit Schriftsatz hat das nix zu tun), man kann auch das BOM weglassen.

Aber wenn

Code: Alles auswählen

<?xml encoding='ISO-8859-1'?>

am Beginn der Datei steht, dann wird die Codierung explizit geändert, der Standard also überschrieben. Dann muß der Rest auch dementsprechend passend sein, sprich: ü muß auf der Byteebene 1 Zeichen sein.

Wenn man eine solche fehlerhafte Datei (UTF-8 mit BOM, aber mit der obigen Zeile) als 'datei.xml' speichert und im IE6 aufruft, wird charakteristisch gemosert:

Code: Alles auswählen

Wechseln zwischen aktueller und angegebener Verschlüsselung wird nicht unterstützt. Fehler beim Bearbeiten der Ressource  ...

Der Firefox ist da - leider - großzügiger, außerdem könnte es sein, daß das die Endung .xml voraussetzt, um den IE6 dazu zu bringen, das zu überprüfen. Wenn die Datei als Html betrachtet wird, ist natürlich jeder Browser großzügig.

Beitrag von **Kristian** » 22.06.2006, 20:31

Hallo
Bei dir muss ich ja richtig aufpassen, was ich sage

Er hat die Daten hier ja als ISO-8859-1 eingelesen.
Wenn er das an eine (PHP)Funktion übergibt, die UTF-8 erwartet ist es noch kein Fehler, solange er im Range von 0-255 bleibt.
Die Funktion macht aber automatisch UTF-8 daraus, das kann ja inPHP auch nicht viel anders als durch das Setzen eine High-Bits erfolgen. (dünnes Eis...)
Die Ausgabe ist somit echtes UTF-8 und dadurch kam es IMHO zu dem ganzen Dilemma.
php + XML => UTF-8
Gruss Kristian

Beitrag von **Wirths Media** » 22.06.2006, 20:40

php + XML => UTF-8

genau so.

Beitrag von **oldInternetUser** » 22.06.2006, 20:56

Theoretisch ja, aber:

Kristian hat geschrieben:Er hat die Daten hier ja als ISO-8859-1 eingelesen.

Das stimmt nicht.

Edit: Genauer gesagt: Es stimmt schon, aber in Kombination mit den anderen Informationen ist genau dies das Problem.

{Exkurs: edit.com zeigt nur 1-Byte-Zeichen an.
Speichert mal per Notepad eine Datei mit ein paar Buchstaben und Umlauten als Ascii, UTF-8 und Unicode ab und seht euch die Dateien mit edit.com an.}

Da calusa-xx bestätigte, daß die ersten drei Zeichen nicht komisch waren, fehlt das BOM - das umfaßt bei UTF-8 drei Zeichen und müßte am Anfang stehen. Da er ebenfalls bestätigte, daß im edit.com die Umlaute komisch aussahen (wohl ü als zwei Zeichen), wurde der Datenstrom als UTF-8 codiert geliefert. Sprich: Der Datenstrom war UTF-8 ohne BOM und müßte deshalb - gemäß Standard - als UTF-8 interpretiert werden. Gleichzeitig wird aber in der ersten Zeile behauptet, daß es ISO-8859-1 sei.

Das Problem ist jetzt: Liest man diesen Datenstrom als ISO-8859-1 ein, dann ist ab dann alles falsch - weil Datenstrom und behauptete Codierung nicht zusammenpassen. Es gibt jedoch keine Meldung - weil für den Parser kein Problem existiert, er macht bloß das, was man ihm sagt. Wird jetzt bei der Ausgabe (an den Browser) der Datenstrom als Quasi-Html interpretiert, dann funktioniert alles prächtig, weil nicht scharf genug geprüft wird. Deshalb 'sieht' das Ergebnis bis zu diesem Zeitpunkt korrekt aus.