nicht angemeldet
Zeichencodierung ist falsch
2 
Matthias Apsel
0 0 
Rolf B
0 1 Rolf B
0
1
Zeichencodierung ist falsch
Der Martin
Gunnar Bittersmann
JuliusHallo, aktuell wird ein Text von einer Fremdanwendung in meine Textareas geschrieben. Leider wird das & Zeichen auch als & Zeichen eingefügt. Ich brauche das aber als &. Nur dann kann es von der Anwendung weiter verarbeitet werden. Habt ihr eine Lösung wie die PHP-Seite aussehen soll.
<html>
<head>
<title>IDS-SCHNITTSTELLE</title>
</head>
<body>
<h1>Warenkorb Rückgabe:</h1>
<textarea id="warenkorb"><?php echo $_REQUEST["warenkorb"] ?></textarea>
</body>
</html>
Sorry für die Frage, aber PHP und Web ist nicht meine Heimat.
-
Hallo Andre76,
du suchst möglicherweise htmlspecialchars().
Bis demnächst
Matthias--
Du kannst das Projekt SELFHTML unterstützen,
indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.-
Hallo Matthias,
vielen Dank, dass ist die Lösung gewesen.
Grüße
-
Hallo Stam,
und das ist auch auf jeden Fall nötig gewesen, andernfalls könnte man Dir Bosheiten in die Textarea injizieren und dich hacken.
Text aus unbekannten Quellen muss man immer maskieren.Update: Text muss man immer kontextgerecht maskieren.
Rolf
--
sumpsi - posui - obstruxi-
Hey Danke, ich war ein wenig schnell mit der Meldung "ich habe es gelöst".
Das Problem ist noch folgendes:
Ich bekomme in das Feld einen Warenkorb gelegt.
Händler A:
<?xml version="1.0" encoding="utf-8"?><Warenkorb.....Händler B:
<?xml version="1.0" encoding="ISO-8859-1"?><Warenkorb....Leider haben die kein festes encoding. Wie könnte ich es hinbekommen das die Umläute immer richtig angezeigt werden.
Grüße und Danke
-
Hallo Stam,
sorry, aber deine Problembeschreibung ist schwierig. Du fängst mit einer vermeintlichen Harmlosigkeit an:
aktuell wird ein Text von einer Fremdanwendung in meine Textareas geschrieben , (& vs &)
und auf einmal sind es mehrere Händler, die ein unterschiedlich codiertes XML Dokument übermitteln.
Bitte fang vorne an. Wie ist der Workflow. Was tun die Händler genau? Wie entsteht das XML Dokument? Warum ist da überhaupt unterschiedliches encoding? Wie kommt das XML Dokument in das Warenkorb-Element? Macht da jemand Copy+Paste in eine textarea? Scripten die Händler ein Form von Dir? Bekommst Du direkt einen HTML Request mit dem form-codierten XML Dokument gePOSTet? Ist auf Seiten der Händler eine definierte Anwendung, die sendet? Oder ist die Landschaft dort heterogen?
Warum frage ich soviel? Je nach dem Weg, den die Daten nehmen, ist damit zu rechnen, dass die im XML Dokument behauptete Codierung mehr oder weniger verstümmelt wird. Dass da UTF-8 oder ISO-8859-1 steht, muss nicht heißen, dass das bei Dir im PHP auch exakt so ankommt.
Der Punkt ist: Browser arbeiten heute eigentlich mit Unicode oder zumindest UCS-2. D.h. wenn der Händler Dir Text in eine Textarea kopiert, muss beim Copy+Paste Vorgang sichergestellt sein, dass die Umlaute korrekt im Browser ankommen. ABER: dann ist das encoding im XML-Kopf irrelevant, weil der Browser nämlich beim Senden selbst codiert. Entweder basierend auf dem Charset, mit dem Du das Form geschickt hast, oder basierend auf dem accepted-charset Attribut des <form> Elements. Wenn dagegen irgendeine Anwendung Dir einen POST Request schickt, dann muss sie im Content-Type Request-Header mitteilen, wie sie den Content codiert hat, und dann ist diese Codierung relevant. Da kann es zu wilden Kombinationen kommen, z.B. könnte der XML String ein ISO-8859-1 encoding behaupten, aber diese Bytefolge als UTF-8 codierter String übermittelt werden.
Deswegen: Um eine Lösung skizzieren zu können, muss man den Workflow kennen.
Rolf
--
sumpsi - posui - obstruxi-
Hallo Rolf, danke und für Antwort und stimmt, mit einem Workflow geht es besser. Ich versuche es mal und hoffe Du kommst damit zurecht.
Workflow:
- Ich habe eine Softwarelösung die z.B. ein Angebot erstellt.
- Mit dieser Software kann ich vom Großhandel Artikel importieren.
- Für den Aufruf beim Großhandel öffne ich in meiner Software ein Webbrowser Form und starte meine HTML Seite z.B. www.meineseite.de/Grosshandel.html
Code meiner HTML Seite für den Shopaufruf:
<!doctype html public "-//W3C//DTD HTML 3.2 //EN"> <html><head><title>Schnittstelle WKS</title></head> <body onload="document.forms['wks'].submit();"> <form id="wks" name="wks" action="https://meingrosshandel.de/ids" method="post"> <input type="hidden" name="kndnr" value="..." size="50" maxlength="50"> <input type="hidden" name="name_kunde" value="..." size="50" maxlength="50"> <input type="hidden" name="pw_kunde" value="...." size="50" maxlength="50"> <input type="hidden" name="version" value="1.3" size="5" maxlength="5"> <input type="hidden" name="action" value="WKS" size="3" maxlength="3"> <input type="hidden" name="hookurl" value="https://www.meineseite.de/idsconnect.php" size="256" maxlength="256"> </form></body></html>-
Im WebShop vom Grosshandel kann der Anwender seine Artikel in den Warenkorb legen. Dann kann er dort den Button „Warenkorb übertragen“ anklicken. Der Grosshandel ruft dann die HookUrl aus dem von mir übertragenen Formular auf und Schreibt seinen Warenkorb in ein Feld „Textarea“. Dieses Feld muss die id=“Warenkorb“ haben.
-
Ich erhalte dann in dem Feld den Warenkorb: Muster Warenkorb Rückübertragung:
<?xml version="1.0" encoding="ISO-8859-1"?> <Warenkorb xmlns="http://www.muster.de/Shop-Anbindung/Warenkorb/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.muster.de/Shop-Anbindung/Warenkorb/warenkorb_empfangen.xsd"> <WarenkorbInfo> <Date>2020-07-14</Date> <Time>17:22:39</Time> <RueckgabeKZ>Warenkorbrückgabe</RueckgabeKZ> <Version>2.0</Version> </WarenkorbInfo> <Order> <OrderInfo> <InquiryNo></InquiryNo> <OfferNo>1988783</OfferNo> <PartNo>TEST</PartNo>- Ich lese dann mit meiner Software das Feld aus. Alle Großhändler, die das Encoding ISO verwenden gehen auch, hier stimmen die Umlaute. Bei den andere die das <?xml version="1.0" encoding="utf-8"?> senden, stimmen in meiner Textarea die Umlaute dann nicht mehr.
Hier noch ein Auszug aus der Schnittstelle: 4.1 Warenkorbübernahme Shop zur Handwerkssoftware Über diese Funktion soll die Übernahme eines Warenkorbs aus dem Shop-System in die Handwerkssoftware realisiert werden. Für den Prozess wurden folgende Prozessschritte abgestimmt. a) Starten des GH-Shops aus der Handwerkssoftware in einem Browserfenster Beim Aufruf des GH-Shops soll eine automatische Anmeldung erfolgen. Hierfür werden bei der Anfrage die Parameter „Kundennummer“, „Benutzername“ und „Passwort“ übertragen. Zusätzlich ist der Parameter „Version“ zur Angabe der Version der Schnittstelle (ab Version 1.3) möglich. Die Zugangsdaten sollen den beim Anwender bereits bekannten Zugangsdaten im Shop-System entsprechen. Bei der Übertragung der Parameter soll die POST Variante (komplexere Implementierung aber unbegrenzte Parameterlänge) möglich sein. Die GET Variante wird auf Grund der nicht ausreichenden Länge der Parameter nicht unterstützt. ITEK GmbH 10.09.2013 Seite 10/29 IDS Schnittstelle Beim Aufruf der Shop-Anbindung muss im HTTP-Header der Content "text/html" angegeben werden. Weiterhin muss der Zeichensatz angegeben werden, um eine eindeutige Interpretation zu ermöglichen. Für die Formulardaten muss der enctype "multipart/form-data" angegeben werden. Die gleichen Festlegungen gelten auch beim Aufruf der Hook-URL. Der Zeichensatz der xml Struktur für den Warenkorb soll in der xml Deklaration angegeben werden. Wird nichts angegeben, so wird utf-8 genutzt. Es kann in jeder Anfrage nur ein Warenkorb übermittelt werden. Für die Übertragung wird die Nutzung von HTTPS empfohlen, grundsätzlich soll aber auch HTTP möglich sein. Die Rück-Kommunikation zur Handwerkssoftware soll über eine HOOK-URL erfolgen. Diese wird als Parameter beim Aufruf des GH-Shops übertragen. Zusätzlich kann der Parameter „Target“ angegeben werden. Hier wird das Target angegeben welches durch die Handwerkssoftware überwacht wird, um den Abschluss der RückKommunikation festzustellen. Das Target muss, nach Abschluss der Rück-Kommunikation, durch den Shop aktualisiert werden. Wird der Parameter nicht übertragen wird „TOP“ als StandardTarget genutzt. Die Festlegung, welche Aktion im GH-Shop aufgerufen werden soll, erfolgt über einen Aktionsparameter. Sollten für andere Aktionen weitere Parameter erforderlich sein, so werden diese in Abhängigkeit von der Aktion definiert. Falls beim Aufruf Fehler auftreten, sollen diese im Browserfenster angezeigt werden. Das genaue Fehlerhandling obliegt den einzelnen GH-Shops und wird hier nicht weiter betrachtet. Falls der GH-Shop ein Weiterarbeiten z. B. über eine manuelle Anmeldung ermöglicht, müssen die Aufrufparameter aus der Handwerkssoftware erhalten bleiben um den Abschluss des Prozesses zu ermöglichen. Hinweis: Beim Zugriff auf die Shop-Systeme ist zu beachten, dass es zu Problemen kommen kann, wenn in einem Shop-System mehrere Funktionen parallel gestartet werden.
b) Übernahme des Warenkorbs Der übertragenen Warenkorb muss dem Schema „Warenkorb_empfangen.xsd“ entsprechen. Die Übernahme der Daten erfolgt als Übertragung eines Formulars an die HOOK-URL analog der OCI Schnittstelle.
c) Schließen des GH-Shops Nach Abschluss der Verarbeitung muss das Browserfenster geschlossen werden und der Prozess ist abgeschlossen.
Jetzt stellt sich für mich die Frage wie ich die unterschiedlichen Encoding in den Griff bekommen kann.
-
Hallo,
<?xml version="1.0" encoding="ISO-8859-1"?> <Warenkorb xmlns="http://www.muster.de/Shop-Anbindung/Warenkorb/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.muster.de/Shop-Anbindung/Warenkorb/warenkorb_empfangen.xsd"> <WarenkorbInfo> <Date>2020-07-14</Date> <Time>17:22:39</Time> <RueckgabeKZ>Warenkorbrückgabe</RueckgabeKZ> <Version>2.0</Version> </WarenkorbInfo> <Order> <OrderInfo> <InquiryNo></InquiryNo> <OfferNo>1988783</OfferNo> <PartNo>TEST</PartNo>- Ich lese dann mit meiner Software das Feld aus. Alle Großhändler, die das Encoding ISO verwenden gehen auch, hier stimmen die Umlaute.
also ist dein Shopsystem anscheinend auch in ISO-8859-x codiert.
Bei den andere die das <?xml version="1.0" encoding="utf-8"?> senden, stimmen in meiner Textarea die Umlaute dann nicht mehr.
Dann wird dir vermutlich nichts anderes übrigbleiben, als die encoding-Angabe aus der XML-Deklaration zu picken und, falls sie nicht auf "iso-8859-1" lautet, den gesamten XML-String umzucodieren.
Live long and
proshealthy,
Martin--
Home is where my beer is.-
Tach!
Dann wird dir vermutlich nichts anderes übrigbleiben, als die encoding-Angabe aus der XML-Deklaration zu picken und, falls sie nicht auf "iso-8859-1" lautet, den gesamten XML-String umzucodieren.
Im Falle der Umkodierung von UTF-8 nach ISO-8859-1/Windows-1252 kann man auch die Funktion utf8_decode() nehmen.
Egal welchen Weg man nimmt, weil Unicode viel mehr Zeichen kennt als ISO-8859-1/Windows-1252, ist mit Datenverlust ist zu rechnen, wenn solche nicht in ISO-8859-1/Windows-1252 enthaltene Zeichen in der Quelle enthalten sind. Diese Zeichen werden dann zu einem Fragezeichen konvertiert.
dedlfix.
-
Hallo Martin, danke für die Antwort. Ich habe jetzt mal ein PHP gebastelt. Leider bekomme ich den Text nicht konvertiert.
Hier mein aktueller Code:
<?php $einString = $_REQUEST["warenkorb"]; $suchwort = "ISO-8859-1"; if($position === false) { echo "UTF8 Warenkorb"; iconv("UTF-8", "ISO-8859-1", $einString), PHP_EOL; } else { echo "ISO-88xxxxx Warenkorb"; } ?><html> <head> <title>IDS-SCHNITTSTELLE</title> </head> <body> <h1>Warenkorb</h1> <textarea id="warenkorb"> <?php echo htmlspecialchars($einString, ENT_QUOTES); ?></textarea> </body> </html>In der Iconv Zeile stimmt nicht, wenn diese entfernt ist geht es wieder. Grüße und Danke
-
Hallo Stam,
iconv ist eine Funktion. Du musst das Ergebnis entgegennehmen, der Wert der Variablen im 3. Parameter wird nicht überschrieben.
Und Du musst prüfen, ob die Rückgabe FALSE ist. Wenn ja, gab's einen Fehler.
Rolf
--
sumpsi - posui - obstruxi
-
-
@@Stam
Code meiner HTML Seite für den Shopaufruf:
<!doctype html public "-//W3C//DTD HTML 3.2 //EN">3.2?? Wirklich? Wann kam HTML 4.0? 1997.
Diese DOCTYPE-Angabe dürfte Browser in den Quirksmodus schicken – das sollte man nicht tun.
Der public identifier ist noch dazu falsch.
-//W3C//DTD HTML 3.2 Final//ENwär’s gewesen.Verwende
<!DOCTYPE html>(wenn deine Seiten im Standardmodus denn richtig aussehen).🖖 Stay hard! Stay hungry! Stay alive! Stay home!
--
“Turn off CSS. If the page makes no sense, fix your markup.” —fantasai -
Hallo Stam,
ich kann nicht sagen, dass deine Erklärung meine Fragen beantwortet, mir fehlt zu viel Background.
Wenn ISO-8859-1 bei Dir sauber ankommt, dann sollte der Hinweis mit utf8_decode für Dich hinreichend sein.
Ich möchte nur darauf hinweisen, dass ISO-8859 eine Standardgruppe ist und ISO-8859-1 eigentlich veraltet ist. Er wurde zu ISO-8859-15 aktualisiert (mit € Zeichen). Codepage 1252 ist ähnlich zu ISO-8859-1/-15, aber nicht identisch. Im Bereich der deutschen Umlaute sind die Codepages gleich, ob Du auch andere Akzentzeichen übertragen können musst hängt von Deiner Anwendung ab.
Rolf
--
sumpsi - posui - obstruxi-
@@Rolf B
Ich möchte nur darauf hinweisen, dass ISO-8859 eine Standardgruppe ist und ISO-8859-1 eigentlich veraltet ist. Er wurde zu ISO-8859-15 aktualisiert (mit € Zeichen).
Dann möchte ich noch darauf hinweisen, dass ISO-8859-15 auch veraltet ist. UTF-8 ist angesagt (mit allen Zeichen).
Codepage 1252 ist ähnlich zu ISO-8859-1/-15, aber nicht identisch. Im Bereich der deutschen Umlaute sind die Codepages gleich, ob Du auch andere Akzentzeichen übertragen können musst hängt von Deiner Anwendung ab.
CP-1252 und ISO-8859-1/-15 decken westeuropäische und nordeuropäische Sprachen ab; mitteleuropäische aber nicht.
🖖 Stay hard! Stay hungry! Stay alive! Stay home!
--
“Turn off CSS. If the page makes no sense, fix your markup.” —fantasai
-
-
-
-
Text aus unbekannten Quellen muss man immer maskieren.
Text
aus unbekannten Quellenmuss man immer maskieren.-
Hallo 1unitedpower,
Text aus unbekannten Quellen muss man immer maskieren.
Text
aus unbekannten Quellenmuss man immer maskieren.M.m.n. gehört da noch ein „kontextgerecht“ hin, um es noch klarer zu bekommen.
Gruß
Julius-
Hallo 1UP + Julius,
fixed
Rolf
--
sumpsi - posui - obstruxi
-
-
-
-
-