Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.misc > #1919
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Newsgroups | de.comp.lang.misc |
| Subject | Re: JavaScript |
| Date | 2017-04-14 02:30 +0200 |
| Organization | PointedEars Software (PES) |
| Message-ID | <1692251.L2AbbRQnKb@PointedEars.de> (permalink) |
| References | <JavaScript-20170402004405@ram.dialup.fu-berlin.de> |
Stefan Ram wrote:
> atob( `hier konnte ich
> den mehrzeiligen base64-
> kodierten Text einfuegen` )
>
> . Ich erhielt nun zwar eine Ausgabe, aber sie war noch
> UTF-8-kodiert.
Nein, war sie nicht. Wäre sie UTF-8-codiert gewesen, dann hättest Du dort
ein sinnvolles Zeichen gesehen.
> Mir wurde also beispielsweise das Wort
> »Wünsche« als
>
> Wünsche
>
> angezeigt.
Das ist aber nicht UTF-8, sondern das Ergebnis einer falschen Decodierung
eines mit UTF-8 codierten Unicode-Zeichens mit Codepunkt jenseits U+007F als
ISO-8859-1, da dort solche Zeichen mit einer Codesequenz aus zwei oder mehr
Oktetts codiert werden.
> Dies konnte ich mit
> decodeURIComponent( escape( ... )) dekodieren.
Zufall. Mit der Programmiersprache hat das wenig zu tun.
window.atob() is proprietär; diese lediglich von einer Host-Umgebung
vom Typ Web-Browser bereitgestellte Methode wird hier implizit aufgerufen.
escape() is proprietär und wurde in Netscape JavaScript eingeführt (und aus
Wettbewerbsgründen von M$ für JScript und anderen Implementierern für deren
ECMAScript-Implementierungen in deren Programmen kopiert), bevor Unicode-
Support mit ECMAScript eingeführt und Netscape JavaScript 1.3 als
Implementierung von ECMAScript Ed. 3 definiert wurde.
Daher werden (aus Gründen der Abwärtskompatibilität) diese Unicode-Zeichen
von escape() u.a. in Mozilla JavaScript von Mozilla SpiderMonkey in Mozilla
Firefox als Zeichen im ISO-8859-1-Zeichensatz interpretiert und nur mit je
einem Prozent-Code gemäss RFC 2396 § 2.1 (OBSOLETE) codiert:
| > escape("Wünsche")
| <- "W%C3%BCnsche"
Das Ergebnis entspricht dann dem UTF-8-Prozentcode für das korrekte
Unicode-Zeichen, wie er in RFC 3986 § 2.1 definiert ist, und was das
standardkonforme decodeURIComponent() daher decodieren kann:
| > decodeURIComponent("W%C3%BCnsche")
| <- "Wünsche"
Das Ergebnis ist dann in der Regel ein mit UTF-16 codierter String; siehe
ECMAScript (ECMA-262) 2016 (Edition 7.0), §§ 18.2.6.3, 4.3.17 und 6.1.4.
> decodeURIComponent( escape( "Wünsche" ))
>
> ergibt beispielsweise
>
> Wünsche
>
> . Insgesamt konnte ich meine Mail /mit lesbaren
> Klartextumlauten/ also durch
>
> decodeURIComponent( escape( atob( `mailtext` )))
>
> erhalten. Welche andere Programmierspracher erlaubt es,
> auf so einfache Weise base64 und utf-8 zu dekodieren?
Es wird hier zwar base64 decodiert, nicht aber UTF-8.
Es sollte nun klar sein, dass sich in dieser Weise kaputtcodierte Unicode-
Zeichen mit jeder Programmiersprache reparieren lassen, die den Zugriff auf
einzelne Zeichen/Oktetts eines Strings, eine Möglichkeit zur Ermittlung des
Codepunkts eines Zeichens sowie eine Möglichkeit zur Konvertierung von
Dezimal- in Hexadezimalzahlen bereitstellt.
Trotzdem danke; ich werde diesen Ansatz für die Reparatur von durch nicht
standardkonform arbeitende Newsreader verunstaltete Headerfeld-Werte bei der
Entwicklung meiner Newsreader-Web-Applikation in Betracht ziehen.
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
Back to de.comp.lang.misc | Previous | Next | Find similar
Re: JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-04-14 02:30 +0200
csiph-web