Hallo zusammen,
ich bekomme seit heuer bei einem Zugriff auf einen Webservice die Daten in einem anderen Zeichensatz retour. Kann mir jemand sagen, welcher Zeichensatz bei "Die A¬bermittelten Zugangsdaten sind ungA¬ltig" verwendet wird und wie ich ihn nach Ansi konvertiere.
CodePageUtf82Ansi habe ich schon probiert, bringt aber die Umlaute nicht korrekt.
LG
Zeichensatz konvertieren
Moderator: wriedmann
Zeichensatz konvertieren
- Attachments
-
- _Login.xml
- (306 Bytes) Downloaded 45 times
Re: Zeichensatz konvertieren
Notepadd++ sagt Ansi, was nicht stimmt. Im Hexdump sieht man auch nicht mehr, also Ki gefragt, das war die Antwort:
urzfassung: Aus dem Dump lässt sich kein eindeutiger Zeichensatz mit 100%iger Sicherheit bestimmen. Aber es gibt starke Hinweise: Die Datei ist nicht UTF‑8 (das Byte 0xAC steht isoliert und ist kein gültiges UTF‑8‑Startbyte), es handelt sich also sehr wahrscheinlich um eine single‑byte‑Kodierung wie ISO‑8859‑1 (Latin‑1) oder Windows‑1252.
Erläuterung und Hinweise:
- Der Hexdump enthält überwiegend ASCII‑Bytes; zusätzlich taucht 0xAC an Stellen auf, an denen in korrekt kodiertem Deutsch Umlaute erwartet würden. In ISO‑8859‑1 bzw. Windows‑1252 ist 0xAC das Zeichen "¬" (NOT‑Sign). Deshalb sieht man im Text z. B. "A¬" statt eines Umlauts.
- 0xAC alleine wäre in UTF‑8 ungültig (Bytes mit der Form 10xxxxxx sind nur als Fortsetzungsbytes erlaubt). Weil Sie keinen BOM und keine XML‑Prolog‑Encoding‑Angabe haben, ist UTF‑8 zwar die standardmäßige Vermutung bei XML/SOAP, aber die Bytefolge passt nicht zu UTF‑8 — also ist der Sender falsch kodiert oder die Anzeige falsch interpretiert worden.
- Zwischen ISO‑8859‑1 und Windows‑1252 kann man hier nicht unterscheiden, weil beide bei 0xAC dasselbe Glyph haben. Für deutsche Umlaute wären in Latin‑1/CP1252 allerdings andere bytewerte zu erwarten (z. B. ü = 0xFC), weshalb die tatsächlich sichtbaren Fehlbytes auf eine fehlerhafte Konversion hindeuten (z. B. eine doppelte/fehlerhafte Rekodierung).
Was Sie tun können
- Prüfen Sie die HTTP‑Response‑Header der Abfrage (Content-Type; charset=...), dort steht oft die verwendete Kodierung.
- Prüfen Sie, ob der SOAP‑Server ein XML‑Prolog sendet (<?xml version="1.0" encoding="...">). In Ihrem Dump fehlt der Prolog.
- Probieren Sie verschiedene Dekodierungen lokal aus (latin1, cp1252, utf-8 mit Replacement), z. B. mit Python:
bytes.fromhex("...hex...").decode("latin1")
bzw.
bytes.fromhex("...hex...").decode("cp1252")
und
bytes.fromhex("...hex...").decode("utf-8", errors="replace")
So sehen Sie das Verhalten.
- Wenn der Dienst UTF‑8 senden soll, melden Sie dem Provider, dass die Antwort ungültige UTF‑8‑Bytes enthält.
Fazit: wahrscheinlich single‑byte (ISO‑8859‑1 / Windows‑1252) oder eine fehlerhafte Rekodierung — aber ohne HTTP‑Header/Prolog kann man den korrekten Zeichensatz nicht hundertprozentig festlegen. Wenn Sie wollen, dekodiere ich den Hexdump mit einigen Encodings und zeige die Ergebnisse.
urzfassung: Aus dem Dump lässt sich kein eindeutiger Zeichensatz mit 100%iger Sicherheit bestimmen. Aber es gibt starke Hinweise: Die Datei ist nicht UTF‑8 (das Byte 0xAC steht isoliert und ist kein gültiges UTF‑8‑Startbyte), es handelt sich also sehr wahrscheinlich um eine single‑byte‑Kodierung wie ISO‑8859‑1 (Latin‑1) oder Windows‑1252.
Erläuterung und Hinweise:
- Der Hexdump enthält überwiegend ASCII‑Bytes; zusätzlich taucht 0xAC an Stellen auf, an denen in korrekt kodiertem Deutsch Umlaute erwartet würden. In ISO‑8859‑1 bzw. Windows‑1252 ist 0xAC das Zeichen "¬" (NOT‑Sign). Deshalb sieht man im Text z. B. "A¬" statt eines Umlauts.
- 0xAC alleine wäre in UTF‑8 ungültig (Bytes mit der Form 10xxxxxx sind nur als Fortsetzungsbytes erlaubt). Weil Sie keinen BOM und keine XML‑Prolog‑Encoding‑Angabe haben, ist UTF‑8 zwar die standardmäßige Vermutung bei XML/SOAP, aber die Bytefolge passt nicht zu UTF‑8 — also ist der Sender falsch kodiert oder die Anzeige falsch interpretiert worden.
- Zwischen ISO‑8859‑1 und Windows‑1252 kann man hier nicht unterscheiden, weil beide bei 0xAC dasselbe Glyph haben. Für deutsche Umlaute wären in Latin‑1/CP1252 allerdings andere bytewerte zu erwarten (z. B. ü = 0xFC), weshalb die tatsächlich sichtbaren Fehlbytes auf eine fehlerhafte Konversion hindeuten (z. B. eine doppelte/fehlerhafte Rekodierung).
Was Sie tun können
- Prüfen Sie die HTTP‑Response‑Header der Abfrage (Content-Type; charset=...), dort steht oft die verwendete Kodierung.
- Prüfen Sie, ob der SOAP‑Server ein XML‑Prolog sendet (<?xml version="1.0" encoding="...">). In Ihrem Dump fehlt der Prolog.
- Probieren Sie verschiedene Dekodierungen lokal aus (latin1, cp1252, utf-8 mit Replacement), z. B. mit Python:
bytes.fromhex("...hex...").decode("latin1")
bzw.
bytes.fromhex("...hex...").decode("cp1252")
und
bytes.fromhex("...hex...").decode("utf-8", errors="replace")
So sehen Sie das Verhalten.
- Wenn der Dienst UTF‑8 senden soll, melden Sie dem Provider, dass die Antwort ungültige UTF‑8‑Bytes enthält.
Fazit: wahrscheinlich single‑byte (ISO‑8859‑1 / Windows‑1252) oder eine fehlerhafte Rekodierung — aber ohne HTTP‑Header/Prolog kann man den korrekten Zeichensatz nicht hundertprozentig festlegen. Wenn Sie wollen, dekodiere ich den Hexdump mit einigen Encodings und zeige die Ergebnisse.
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Re: Zeichensatz konvertieren
Hallo zusammen,
Fehler gefunden: Ist UTF-8, aber durchs Speichern mit Memowrit werden die Zeichen anscheinend verändert, muss wahrscheinlich eher mit FWrite gespeichert werden.
LG
Fehler gefunden: Ist UTF-8, aber durchs Speichern mit Memowrit werden die Zeichen anscheinend verändert, muss wahrscheinlich eher mit FWrite gespeichert werden.
LG