Path: csiph.com!weretis.net!feeder8.news.weretis.net!news.mb-net.net!open-news-network.org!.POSTED.178.197.201.249!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: de.comp.lang.javascript Subject: Re: String-Literals automatisiert in ASCII konvertieren? Supersedes: <5613867.DvuYhMxLoT@PointedEars.de> Date: Thu, 29 Sep 2022 20:40:33 +0200 Organization: PointedEars Software (PES) Lines: 64 Message-ID: <5870471.lOV4Wx5bFT@PointedEars.de> References: <877d1pm8w6.fsf@vagabond.tim-landscheidt.de> <12070813.O9o76ZdvQC@PointedEars.de> <87sfka2vyg.fsf@vagabond.tim-landscheidt.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit Injection-Info: gwaiyur.mb-net.net; posting-host="178.197.201.249"; logging-data="997257"; mail-complaints-to="abuse@open-news-network.org" User-Agent: KNode/4.14.10 Cancel-Key: sha1:xzzZaYJ2pCvyKKNFaXuYRgHWJ+k= Cancel-Lock: sha1:VY+QIi7n1FhhJ2Bu9Ja0pkfk+vk= X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. Thomas 'PointedEars' Lahn 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”). _______ ¹ -- PointedEars | Twitter: @PointedEars2 Please do not cc me. /Bitte keine Kopien per E-Mail.