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