SciTE4AutoHotKey ändert die Umlaute (ä,ö,ü)

[Jakobus]

An die Freunde von SciTE4AutoHotKey,

SciTE4AutoHotKey (Version 3.1.00)
hat die Umlaute (ä, ö, ü) ausgewechselt.

Aus ä wird xE4
Aus ö wird xF6
Aus ü wird xFC

Beispiel:

; -------------------------------------------------------
; Jetzt den Text fxFCr Auto-Kunden lxF6schen
; -------------------------------------------------------

Die "SciTE4AutoHotKey settings" sind wie folgt:

Language: Deutsch
Style: SciTE4AutoHotKey Light
Encoding: UFT-8
Code font: Consolas
Text Zoom: -1

++ siehe Anhang ++

Die Umlaute sind 5 Tage nach dem erneutem Öffnen der Datei ersetzt worden.
Tippe ich ä,ö,ü in das Codefenster von SciTE4AutoHotKey, so werden diese unverändert als ä, ö. ü angezeigt.

Gibt es ein Möglichkeit, die ausgewechselten deutschen Umlaute wieder sichtbar zu machen?

Nachtrag:
Der Menuepunkt Sprache steht auf Autohotkey.
Nach Auswahl der 3 darunterliegen Punkten wie Lua, und INI and property files und Difference kommen die Umlaute auch nicht zurück.

[gregster]

Ganz unabhängig vom Editor, solltest du für AHK v1 immer sicherstellen, dass du UTF-8 with BOM(mit byte order mark)-Kodierung für die Skriptdatei verwendest, wenn du so exotische Zeichen wie deutsche Umlaute verwenden möchtest.

scite encoding.png (31.19 KiB) Viewed 1769 times

Aber zurückbekommen? Weiß ich nicht. Im Zweifel Search>Replace>Replace all.

[Jakobus]

Danke gregster für Deine schnelle Antwort.

Encoding (Kodierung) hatte ich übersehen.

Damit das AHK-Script die Änderung übernimmt
muss die Einstellung auf UFT-8 with BOM (mit Markierung)abgespeichert werden.

Leider ändert sich dadurch nichts.

Siehe unten den Vergleich; Vorher und Nachher

[gregster]

Aber zurückbekommen? Weiß ich nicht. Im Zweifel Search>Replace>Replace all.

Nein, zurück wirst du die Umlaute dadurch wohl nicht bekommen - das bringt nur was bevor das Malheur passiert ist.
Ich würde aber mal versuchen, was ich oben noch nachgeschoben habe...

[Jakobus]

Danke für Deinen Hinweis, gregster.

Sorry, Deinen Satz hatte ich zuerst übersehe.
Im Augenwinkel noch registriert hatte ich es für Deine Signatur gehalten.

An "Search and Replace" hatte ich auch schon gedacht.

Wollte aber sicher sein,
dass man nicht irgendwo in der Einstellung mit z.B. einem "Häkchen setzen" die Umlaute wieder zurückholt.

Zuvor war Endcoding auf Systemeinstellung gesetzt gewesen.
D.h. möglicherweise ist das gestrige Update von Microsoft nicht unschuldig?
Wobei, in den Microsoft-Tools habe ich nicht das Problem.

[gregster]

Sorry, nicht dass ich wüsste.

[Jakobus]

Ok,
(1) ich passe über "Search And Replace" die Umlaute an und
(2) setze Encoding auf UFT-8 mit Markierung
in der Hoffnung die Umlaute werden in der Zukunft nicht wieder unverhofft umgestellt.

Danke für Deine Unterstützung, gregster.

Vielleicht hat jemand anderes noch eine kluge Idee, wie man es schafft,
dass SciTE4AutoHotKey die Umlaute nicht ändert (oder möglicherweise Microsofts Update).

[BoBo]

@Jakobus - welches Tool benutzt du für den Screenshot (bzw. die Beschriftung desselben)?

[Jakobus]

Hallo Bobo,

das geniale Tool für die Screenshoots ist Snagit von TechSmith.
Mit dem gleichen Tool lassen sich auch Videos vom Bildschirm erstellen.

[just me]

Moin,

ich habe das so noch nicht erlebt. xFC steht für Hexadezimal FC (252), und das ist die ANSI-Kodierung (CP1252) für das Zeichen ü.
Ich gehe davon aus, dass Dein Skript ursprünglich ANSI kodiert gespeichert war. Wenn man SciTE sagt, dass die Kodierung UTF-8 ohne BOM ist, scheint es auch nur gültiges UTF-8 zu akzeptieren. In UTF-8 sind nur die Zeichenwerte von 0x00 (0) bis 0x7F (127) als ein Byte codiert. Alle anderen Zeichen werden als Folgen von 2, 3 oder 4 Bytes im Bereich von 0x80 (128) bis 0xFF (255) kodiert. Das 1. Zeichen bestimmt die Länge der Folge.

Code: Select all

; Jetzt den Text für Auto-Kunden löschen

Wenn dieser Text in einer ANSI kodierten Datei steht, SciTE aber gesagt wird, es soll UTF-8 sein, stößt SciTE auf das Zeichen ü (0xFC). Dieser Wert ist als erstes Zeichen einer UTF-8 Folge ungültig. Selbst wenn nicht, würde das folgende r (0x72) dafür sorgen, dass eine ungültige UTF-8 Folge erkannt wird. SciTE scheint nun die ungültigen UTF-8 Werte als Hexadezimalwerte auszugeben, hier xFC. Wenn SciTE das beim Speichern auch so in die Datei schreibt, sind die 'ungültigen' Zechen verloren.

Wenn Du das Encoding für SciTE vor der ersten Anwendung auf UTF-8 mit BOM gesetzt hättest, hätte SciTE an der fehlenden BOM bemerkt/bemerken können, dass die Datei nicht UTF-8 ist.

[Jakobus]

Hallo just me,

Danke für Deine ausführliche Erklärung.

ANSI und UFT-8 sind leider nicht mein "Steckenpferd".
Für Deine Hilfe bin ich sehr dankbar.

Ich habe gelernt, dass ich vorab prüfe (wenn ich dran denke),
ob das Encoding für die AHK Datei auf UFT-8 mit Markierung bzw, UFT-8 with BOM eingestellt ist.

Allerdings hatte ich die Einstellung heute bei einem neuen Skript schon wieder vergessen.

Gelernt daraus wäre mein Wunsch,
dass das Encoding by default auf UFT-8 mit Markierung eingestellt ist.

Ich vermute, nicht viele haben das gleiche Problem.

Der Arbeitsrechner ist auf Language = English eingestellt.
SciTE4AutoHotKey wieder ist auf Deutsch eingestellt.
Möglich, dass dadurch das Problem auftauchte.

[just me]

Moin Jakobus,

ich habe SciTE4AutoHotkey nicht installiert und kann deshalb die Einstellungen nicht selbst testen. Vielleicht kann ja aber ein SciTE Nutzer etwas dazu sagen?