String-Literals automatisiert in ASCII konvertieren?

[Tim Landscheidt]

Hi,

mein Webserver deklariert leider per Default kein
„charset=utf-8“ für *.js-Dateien, was bei Android Chrome zu
fehlerhaften Darstellungen führt. Da ich JavaScript nur bei
temporären „Projekten“ nutze, möchte ich das Problem mög-
lichst auf Dateiebene lösen.

jq erlaubt mittels „jq --ascii-output .“ UTF-8-Eingaben in
ASCII umzuschreiben, das heißt, mit Emacs kann ich JSON-ar-
tige Daten markieren, C-u M-x shell-command-on-region jq
--ascii-output . RET und fertig.

Aber geht das auch automatisiert? Das heißt, gibt es einen
„Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
erals gegebenenfalls nach ASCII umwandelt und dann wieder
ausgibt?

TIA,
Tim

[Stefan Reuther]

Am 27.09.2022 um 12:03 schrieb Tim Landscheidt:
> Aber geht das auch automatisiert? Das heißt, gibt es einen
> „Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
> erals gegebenenfalls nach ASCII umwandelt und dann wieder
> ausgibt?

Ich nehme an, du meinst, dass "ö" nach "\u00f6" ersetzt werden soll?
Wenn du nicht darauf bestehst, *nur* String-Literale zu konvertieren:

recode u8..java


Stefan

[Tim Landscheidt]

r...@zedat.fu-berlin.de (Stefan Ram) wrote:

>> gibt es einen
>>„Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
>>erals gegebenenfalls nach ASCII umwandelt und dann wieder
>>ausgibt?

> Falls Nicht-ASCII-Zeichen nur in Zeichenfolgenliteralen
> (und vielleicht noch in Kommentaren) vorkommen sollten,
> können wir einfach alle Zeichen nach ASCII wandeln.

> […]

Danke für den Denkanstoß, auch an den anderen Stefan. Nach
etwas Abwägung habe ich mich dazu entschieden, die String-
Literals in der Datei direkt in „konvertierter“ Form zu
speichern und dafür in Emacs:

| (dir-locals-set-class-variables 'lighttpd-ascii-only-style
| '((js-mode . ((before-save-hook . ((lambda nil
| (save-mark-and-excursion
| (goto-char (point-min))
| (while (re-search-forward "[[:nonascii:]]" nil t)
| (replace-match (format "\\u%04x" (aref (match-string 0) 0)) t t))))
| t))))))
| (dir-locals-set-directory-class "~/src/homepage" 'lighttpd-ascii-only-style)

verwendet.

Tim

[Thomas 'PointedEars' Lahn]

Stefan Ram wrote:

> Tim Landscheidt <t...@tim-landscheidt.de> writes:
>> gibt es einen
>>„Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
>>erals gegebenenfalls nach ASCII umwandelt und dann wieder
>>ausgibt?
>

> Falls Nicht-ASCII-Zeichen nur in Zeichenfolgenliteralen
> (und vielleicht noch in Kommentaren) vorkommen sollten,
> können wir einfach alle Zeichen nach ASCII wandeln.
>

> Das sollte ein geeignetes Python-3.9-Skript sein:
>
> with open( 'example.txt', mode='r', encoding='utf-8' )as stream:
> source = stream.read()
> for ch in source:
> print( end=ch if ord( ch )<= 127 else rf'\u{ord(ch):04x}' )

“\u{…}” ist (im Unterschied zu “\u…”, welches schon mit ECMAScript Edition 2
[1998] eingeführt wurde) ein relativ neues syntaktisches Konstrukt
(eingeführt mit ECMAScript Ed. 6 [2015]. Das Ergebnis wird daher nur von
neueren Script-Engines korrekt interpretiert werden können. Bei anderen
führt es entweder dazu, dass die Escape-Sequenz angezeigt wird, oder zu
einem Syntaxfehler (Script kann nicht mehr compiliert werden).

Bei der neueren Syntax ist es nicht erforderlich, dass führende Nullen
angegeben werden, und tatsächlich werden damit Unicode-Zeichen bis zum
Codepunkt U+10FFFF (statt nur U+FFFF wie bei der älteren Syntax)
unterstützt.

Grundsätzlich ist die Veränderung des Quelltextes hier der falsche Ansatz;
stattdessen ist das Serverproblem zu lösen, was relativ einfach möglich ist.

--
PointedEars
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2
Please do not cc me. /Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Stefan Ram wrote:

> Tim Landscheidt <t...@tim-landscheidt.de> writes:

>> gibt es einen
>>„Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
>>erals gegebenenfalls nach ASCII umwandelt und dann wieder
>>ausgibt?
>

> Falls Nicht-ASCII-Zeichen nur in Zeichenfolgenliteralen
> (und vielleicht noch in Kommentaren) vorkommen sollten,
> können wir einfach alle Zeichen nach ASCII wandeln.
>
> Das sollte ein geeignetes Python-3.9-Skript sein:
>
> with open( 'example.txt', mode='r', encoding='utf-8' )as stream:
> source = stream.read()
> for ch in source:
> print( end=ch if ord( ch )<= 127 else rf'\u{ord(ch):04x}' )

“\u{…}” ist (im Unterschied zu “\u…”, welches schon mit ECMAScript Edition 2
[1998] eingeführt wurde) ein relativ neues syntaktisches Konstrukt

(eingeführt mit ECMAScript Ed. 6 [2015]). Das Ergebnis wird daher nur von

[Tim Landscheidt]

Thomas 'PointedEars' Lahn <Point...@web.de> wrote:

>>> gibt es einen
>>>„Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
>>>erals gegebenenfalls nach ASCII umwandelt und dann wieder
>>>ausgibt?

>> Falls Nicht-ASCII-Zeichen nur in Zeichenfolgenliteralen
>> (und vielleicht noch in Kommentaren) vorkommen sollten,
>> können wir einfach alle Zeichen nach ASCII wandeln.

>> Das sollte ein geeignetes Python-3.9-Skript sein:

>> with open( 'example.txt', mode='r', encoding='utf-8' )as stream:
>> source = stream.read()
>> for ch in source:
>> print( end=ch if ord( ch )<= 127 else rf'\u{ord(ch):04x}' )

> “\u{…}” ist (im Unterschied zu “\u…”, welches schon mit ECMAScript Edition 2
> [1998] eingeführt wurde) ein relativ neues syntaktisches Konstrukt
> (eingeführt mit ECMAScript Ed. 6 [2015]). Das Ergebnis wird daher nur von
> neueren Script-Engines korrekt interpretiert werden können. Bei anderen
> führt es entweder dazu, dass die Escape-Sequenz angezeigt wird, oder zu
> einem Syntaxfehler (Script kann nicht mehr compiliert werden).

> […]

Die geschweiften Klammern werden hier von Python verarbeitet
(https://docs.python.org/3/reference/lexical_analysis.html#f-strings),
wie auch Stefans Beispiel zeigte.

Tim

[Thomas 'PointedEars' Lahn]

Tim Landscheidt wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>>> gibt es einen
>>>>„Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
>>>>erals gegebenenfalls nach ASCII umwandelt und dann wieder
>>>>ausgibt?
>
>>> Falls Nicht-ASCII-Zeichen nur in Zeichenfolgenliteralen
>>> (und vielleicht noch in Kommentaren) vorkommen sollten,
>>> können wir einfach alle Zeichen nach ASCII wandeln.
>
>>> Das sollte ein geeignetes Python-3.9-Skript sein:
>
>>> with open( 'example.txt', mode='r', encoding='utf-8' )as stream:
>>> source = stream.read()
>>> for ch in source:
>>> print( end=ch if ord( ch )<= 127 else rf'\u{ord(ch):04x}' )
>
>> “\u{…}” ist (im Unterschied zu “\u…”, welches schon mit ECMAScript
>> Edition 2
>> [1998] eingeführt wurde) ein relativ neues syntaktisches Konstrukt'𐀀

>> (eingeführt mit ECMAScript Ed. 6 [2015]). Das Ergebnis wird daher nurက

>> von neueren Script-Engines korrekt interpretiert werden können. Bei
>> anderen führt es entweder dazu, dass die Escape-Sequenz angezeigt wird,
>> oder zu einem Syntaxfehler (Script kann nicht mehr compiliert werden).
>
>> […]
>
> Die geschweiften Klammern werden hier von Python verarbeitet
> (https://docs.python.org/3/reference/lexical_analysis.html#f-strings),
> wie auch Stefans Beispiel zeigte.

Richtig, das war mir später selbst aufgefallen (ich war nur noch nicht dazu
gekommen, es zu erwähnen).

Richtig bleibt jedoch auch, dass Unicode heutzutage *weitaus* mehr
Codepunkte enthält als nur die der Basic Multilingual Plane (BMP: U+0000 bis
U+FFFF), was von Python spätestens ab Version 3.0 auch unterstützt wird.
Daher erzeugt obiger Code falshce ECMAScript-Escape-Sequenzen für Zeichen
ausserhalb der BMP (z. B. '\u10000', was als '\u1000' gefolgt von '0'
interpretiert wird, also äquivalent zu 'က0' ist statt zu '𐀀' (Original).

Um diese Zeichen auch noch zu erfassen, müsste die generierte Escape-Sequenz
die Form '\u{…}' haben (in Python: rf'\u{{{ord(ch):x}}}'); das führt aber zu
den von mir erwähnten Inkompatibilitäten. Es gibt zwar einen Workaround
über die Zerlegung in Surrogate Pairs (wie das mit meinem
JSX:string/unicode.js:WideString möglich ist¹), das ist aber wiederum in
diesem Fall in der Codierung nicht effizient.

Grundsätzlich ist Dein ganzer Ansatz in der Umsetzung fehlerträchtig und
ineffizient; er bläht auch den Quelltext unnötig auf (im Worst Case auf das
Neunfache) was auch die Ausführung des so modifizierten Codes ineffizient
macht. Es ist daher ein Ansatz vorzuziehen, der das tatsächliche Problem
löst, d. h. die korrekte Serverkonfiguration. Dieser hat auch den Vorteil,
weitaus einfacher realisierbar zu sein (nämlich im Best Case lediglich eine
.htaccess-Datei mit “AddCharset utf8 .js”).

[Thomas 'PointedEars' Lahn]

Tim Landscheidt wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>>> gibt es einen
>>>>„Präprozessor“, der JavaScript-Dateien einliest, String-Lit-
>>>>erals gegebenenfalls nach ASCII umwandelt und dann wieder
>>>>ausgibt?
>
>>> Falls Nicht-ASCII-Zeichen nur in Zeichenfolgenliteralen
>>> (und vielleicht noch in Kommentaren) vorkommen sollten,
>>> können wir einfach alle Zeichen nach ASCII wandeln.
>
>>> Das sollte ein geeignetes Python-3.9-Skript sein:
>
>>> with open( 'example.txt', mode='r', encoding='utf-8' )as stream:
>>> source = stream.read()
>>> for ch in source:
>>> print( end=ch if ord( ch )<= 127 else rf'\u{ord(ch):04x}' )
>
>> “\u{…}” ist (im Unterschied zu “\u…”, welches schon mit ECMAScript
>> Edition 2
>> [1998] eingeführt wurde) ein relativ neues syntaktisches Konstrukt'𐀀

>> (eingeführt mit ECMAScript Ed. 6 [2015]). Das Ergebnis wird daher nurက

>> von neueren Script-Engines korrekt interpretiert werden können. Bei
>> anderen führt es entweder dazu, dass die Escape-Sequenz angezeigt wird,
>> oder zu einem Syntaxfehler (Script kann nicht mehr compiliert werden).
>
>> […]
>
> Die geschweiften Klammern werden hier von Python verarbeitet
> (https://docs.python.org/3/reference/lexical_analysis.html#f-strings),
> wie auch Stefans Beispiel zeigte.

Richtig, das war mir später selbst aufgefallen (ich war nur noch nicht dazu
gekommen, es zu erwähnen).

Richtig bleibt jedoch auch, dass Unicode heutzutage *weitaus* mehr
Codepunkte enthält als nur die der Basic Multilingual Plane (BMP: U+0000 bis
U+FFFF), was von Python spätestens ab Version 3.0 auch unterstützt wird.
Daher erzeugt obiger Code falshce ECMAScript-Escape-Sequenzen für Zeichen
ausserhalb der BMP (z. B. '\u10000', was als '\u1000' gefolgt von '0'
interpretiert wird, also äquivalent zu 'က0' ist statt zu '𐀀' (Original).

Um diese Zeichen auch noch zu erfassen, müsste die generierte Escape-Sequenz
die Form '\u{…}' haben (in Python: rf'\u{{{ord(ch):x}}}'); das führt aber zu
den von mir erwähnten Inkompatibilitäten. Es gibt zwar einen Workaround
über die Zerlegung in Surrogate Pairs (wie das mit meinem
JSX:string/unicode.js:WideString möglich ist¹), das ist aber wiederum in
diesem Fall in der Codierung nicht effizient.

Grundsätzlich ist Dein ganzer Ansatz in der Umsetzung fehlerträchtig und
ineffizient; er bläht auch den Quelltext unnötig auf (im Worst Case auf das
Neunfache) was auch die Ausführung des so modifizierten Codes ineffizient
macht. Es ist daher ein Ansatz vorzuziehen, der das tatsächliche Problem
löst, d. h. die korrekte Serverkonfiguration. Dieser hat auch den Vorteil,
weitaus einfacher realisierbar zu sein (nämlich im Best Case lediglich eine
.htaccess-Datei mit “AddCharset utf8 .js”).

_______
¹ <https://github.com/PointedEars/JSX/blob/master/string/unicode.js>

[Tim Landscheidt]

Thomas 'PointedEars' Lahn <Point...@web.de> wrote:

> […]

> Grundsätzlich ist Dein ganzer Ansatz in der Umsetzung fehlerträchtig und
> ineffizient; er bläht auch den Quelltext unnötig auf (im Worst Case auf das
> Neunfache) was auch die Ausführung des so modifizierten Codes ineffizient
> macht. Es ist daher ein Ansatz vorzuziehen, der das tatsächliche Problem
> löst, d. h. die korrekte Serverkonfiguration. Dieser hat auch den Vorteil,
> weitaus einfacher realisierbar zu sein (nämlich im Best Case lediglich eine
> .htaccess-Datei mit “AddCharset utf8 .js”).

Neee, Du. Für /meinen/ Anwendungsfall ist der von den beiden
Stefans vorgeschlagene Weg nicht nur ausreichend, sondern
damit auch ideal.

Tim

[Thomas 'PointedEars' Lahn]

| $ echo 𐀀 | recode u8..java
| \u0000
| $ recode --version
| Free recode 3.6
| […]