Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.misc > #1919

Re: JavaScript

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>

Show all headers | View raw


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


Thread

Re: JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-04-14 02:30 +0200

csiph-web