Umlaute in einigen Dateien stimmen nicht mehr

[MarkF]

Hallole,
ich habe vor etwa 2 Monaten zunächst testweise Win11 installiert, und zwar - da MS meine Hardware nicht mag - als Inplace-Upgrade von Win10 über das Zero-Projekt und arbeite seither damit. So weit, so gut. Version 22H2, Build 22621.2428, Windows Feature Experience Pack 1000.22674.1000.0.
Jetzt habe ich erstmals unter Win11 den Kalorienmanager KaLoMa benutzt (dient dem Nahrungstracking) und da fiel mir auf, daß im Gegensatz zu Win10 die Umlaute nicht korrekt - genauer gesagt überhaupt nicht - dargestellt werden: Leerstelle. Dies betrifft nur die erfaßten und gespeicherten Daten. Das ist an sich eine normale Textdatei mit einer speziellen Dateierweiterungs-Kennung (.klf), in der monatsweise die Daten zeilenweise gespeichert werden.
Ich habe eine der Dateien mit dem Win-Editor geöffnet und hier werden die Umlaute mit einem Symbol, das aussieht wie ein Fragezeichen in einem Rechteck, dargestellt. Mit Wordpad geöffnet werden die Umlaute korrekt dargestellt. Beim Versuch, die Datei mit Word 2007 zu öffnen, erscheint das Fenster für die Dateikonvertierung, in dem die Textcodierung eingestellt werden kann. Mit der default-Einstellung Windows-Standard wird in der Vorschau anstelle der Umlaute ein Fragezeichen in einem Karo angezeigt. Beim Umschalten auf "Andere Codierung" und "Unicode (UTF-8)" dasselbe. Stelle ich um auf z.B. "Unicode (UTF-7)", "Westeuropäisch (ISO)", "Westeuropäisch (Windows)", "Mitteleuropäisch (ISO)" oder "Mitteleuropäisch (Windows)" erscheinen in der Vorschau die Umlaute korrekt.
Also scheint irgendetwas in der Spracheinstellung von Win 11 nicht zu stimmen. Denn unter Win10 - auch dort steht alles auf "Deutsch/Deutschland/Deutsch(Deutschland)" - werden sowohl in KaloMa als auch im Win-Editor die Umlaute korrekt dargestellt; es ist also kein spezifisches Problem der Software KaLoMa.
Ich kann mich nicht konkret erinnern, bei der Installation von Win11 etwas eingestellt zu haben - aber wenn dann nur die normale Sprachauswahl und alles auf "Deutsch/Deutschland/Deutsch(Deutschland)" gestellt. Die gegenwärtige Einstellung ist jedenfalls bei Sprache und Region überall "Deutsch/Deutschland/Deutsch(Deutschland)". Dies gilt auch für "Administrative Sprachoptionen" - "Gebietsschema ändern" und dort ist "Beta: Unicode UTF-8 ..." abgewählt.
Jetzt meine Bitte um Hilfe - woran kann es liegen, an welchen Einstellungen kann ich noch drehen?
Edit: Ich habe alle Einstellungen noch einmal explizit bestätigt und neu gebootet und jetzt werden im Editor und Wordpad anstelle der Umlaute nur noch Leerzeichen angezeigt.
Edit 2: Jezt mal bei einem neu installierten Win 11 (also kein Inplace-Upgrade) getestet - da sind die Umlaute o.k. Die Einstellungen sind, soweit erkennbar, identisch.

[Tante Google]

[Holgi]

Hast du es mal mit ANSI probiert?
Musste jetzt selbst mal eine Notepad Textdatei mit Umlauten erstellen.
Das ging bei mir nur mit ANSI.

[MarkF]

Was meinst Du "mit ANSI"? Wo kann ich das einstellen?
Meinst Du die Einstellung der Kodierung beim Speichern mit dem Editor?
Das ist hier auf UTF-8 eingestellt und damit werden vorhandene Umlaute auch richtig gespeichert.
Aber das ist hier nicht einschlägig. Denn es geht ja um Dateien, die bereits vorhanden sind, mit KaLoMa erstellt wurden, und sowohl unter Win10 als auch auf einem anderen Win11-System mit den enthaltenen Umlauten sowohl von KaLoMa als auch Editor usw. richtig gelesen/dargestellt werden, nicht aber mit dem Editor auf meinem gegenwärtig benutzten Win11-System.
Dein Hinweis ist aber insofern wichtig, als der Fehler bei der Anzeige der Umlaute in KaLoMa, durch den ich auf das Problem erst aufmerksam wurde, daher rührt, daß ich zuvor die betreffende Datei mit dem Editor geändert hatte. Und zwar habe ich eine alte Datei als Basis genommen, die Datumsdaten geändert und als neue Datei gespeichert. Auf den Inhalt, d.h. Umlaute, habe ich überhaupt nicht geachtet. Dadurch wurde zusätzlich zu dem Problem der falschen Anzeige der Umlaute die Datei hinsichtlich der Umlaute geändert, was dazu geführt hat, daß sie in KaLoMa nicht mehr angezeigt wurden - und ich danach bei Tests mit Wordpad scheinbar unerklärliche Unterschiede gesehen habe, was eben daran liegt, daß ich alte, unveränderte und aktuell mit Editor geänderte und unerkannt hinsichtlich der Umlaute veränderte Dateien betrachtet habe.
Nachdem ich die betreffenden Dateien noch einmal mit Wordpad, das bei den ursprünglichen Dateien die Umlaute richtig darstellt, geändert habe, zeigt auch KaLoMa die Umlaute richtig an.
Unverändert ist aber das Probklem mit dem Editor: Die Umlaute aus den "alten" Dateien werden nur als "?" in einem Rechteck dargestellt. In der Statusanzeige rechts unten wird UTF-8 angezeigt. Es mag sein, daß diese Kodierungseinstellung beim Einlesen der Dateien die Ursache für das Problem ist. Aber wie soll ich das ändern? Die Kodierung läßt sich nur beim Speichern ändern und springt beim nächsten Öffnen einer Dabei wieder auf UTF-8. Selbst beim Öffnen von Dateien, die in ANSI gespeichert wurden, bleibt die Kodierungsanzeige auf UTF-8.
Ich vermute, daß der Editor dauerhaft, auch fürs Lesen, auf Windows (Standard) bzw. Westeuropäisch (oder ANSI?) eingestellt werden muß. Aber wie geht das? Der in z.B. https://www.querrum.de/querbeet/Notepad ... ndern.html beschriebene Weg (wird so auch von MS beschrieben) funktioniert nicht. Was aber entgegen der Behauptung von MS in https://www-winhelponline-com.translate ... x_tr_hl=de funktioniert ist die Einstellung des Editors auf "Ansi" beim Neuanlegen eines Textdokuments: Dieselbe Vorgehensweise wie zur Einstellung von UTF-8, nur speichert man die Datei template.txt - rate mal - im Ansi-Format. Aber das hilft hier nicht weiter.

[Holgi]

Der „neue“ Editor brachte mich fast zur Verzweifelung. Notepad geöffnet, umgestellt auf ANSI , gespeichert und wieder geöffnet:
wieder war UTF-8 eingestellt.
Dann drauf gekommen:
nach der Umstellung auf ANSI tatsächlich auch mal einen Umlaut eingegeben und dann abgespeichert.
Siehe da: ANSI bleibt erhalten.
Wie und ob das bei Kaloma hilft vermag ich nicht zu beurteilen.

[MarkF]

Bei mir funktioniert dies nichtWenn die Template-Datei mit einem Umlaut als Ansi angespeichert wird, dann stellt sich der Editor beim nächsten Aufruf auch auf Ansi ein, d.h. er lädt diese Template-Datei mit dem Umlaut. Allerdings ist dann eben auch diese Datei template.txt geöffnet, was nicht wirklich sinnvoll ist.
Das ändert aber nichts daran, daß die bereits vorhandenen KaLoMa-Dateien wieder nur mit UTF-8 geöffnet werden.
Und zwar auch dann, wenn ich sie ausdrücklich als Ansi speichere. Also ich öffne die Datei mit Wordpad, die Umlaute werden richtig dargestellt, kopiere alles mit ctrl-a und ctrl-c, füge es mit ctrl-v im Editor ein und speichere es als Ansi-Datei ab. In KaLoMa werden die Umlaute richtig dargestellt - aber der Editor stellt sich beim Öffnen dieser Datei wieder auf UTF-8 und zeigt die Umlaute nicht an.
Das ist kein Problem von KaLoMa, das ist ein Problem des Editors.
...
Viele, viele Versuche später:
Editor hat einen weiteren damit zusammenhängenden Bug:
Die Datei wird nur dann als Ansi-Datei erkannt, wenn innerhalb der ersten 1024 Byte ein Umlaut (oder, ich vermute, ein anderes Sonderzeichen) erscheint.Danach scheint es keine weitere Begrenzung dieser Art zu geben.Die Speicherung als Ansi scheint immer zu erfolgen: Ich habe eine Datei, bei der der erste Umlaut erst als 1025. Byte erscheint, mit Editor als Ansi gespeichert. Beim Öffnen schaltet Editor auf UTF-8 und erkennt den Umlaut nicht. Wordpad liest die Datei probemlos und erkennt den Umlaut. Dann lösche ich ein Zeichen vor dem Umlaut, speichere mit Wordpad und öffne wieder mit Editor. Diesmal erkennt Editor die Datei als Ansi.
Probiere es aus.
Bei den KaLoMa-Dateien wirkt sich dieser Bug aus, denn dort erscheinen Umlaute meistens erst nach diesen 1024 Zeichen.

[Holgi]

Die Datei wird nur dann als Ansi-Datei erkannt, wenn innerhalb der ersten 1024 Byte ein Umlaut (oder, ich vermute, ein anderes Sonderzeichen) erscheint.

Das deckt sich mit meinen Erfahrungen:
"Dann drauf gekommen:
nach der Umstellung auf ANSI tatsächlich auch mal einen Umlaut eingegeben und dann abgespeichert.
Siehe da: ANSI bleibt erhalten."
Da habe ich ja auch gleich am Anfang einen Umlaut eingegeben.

Man kann ja eine "Default"-Txt Datei anlegen mit z.B.:

Code: Alles auswählen

rem ö

am Anfang.
Bin jetzt dazu übergegangen, den alten Editor (also nicht die Store App) wieder als Standard Editor zu implementieren.
Dazu werden bei mir bei einer Neuinstallation u.a. folgende Registry-Einträge vorgenommen:

Code: Alles auswählen

;Restore Old Classic Notepad on Windows 11
[HKEY_CLASSES_ROOT\Applications\notepad.exe]
"NoOpenWith"=-
[HKEY_CURRENT_USER\Software\Microsoft\Notepad]
"fWindowsOnlyEOL"=dword:00000000
"fPasteOriginalEOL"=dword:00000000
"ShowStoreBanner"=dword:00000000
"iDefaultEncoding"=dword:00000001
[HKEY_CLASSES_ROOT\*\shell\Mit Notepad öffnen\command]
@="notepad.exe %1"
"Icon"="C:\\Windows\\System32\\notepad.exe"

Code: Alles auswählen

"iDefaultEncoding"=dword:00000001

setzt übrigens ANSI als Standard.
https://www.querrum.de/querbeet/Notepad ... ndern.html

[MarkF]

Die Datei wird nur dann als Ansi-Datei erkannt, wenn innerhalb der ersten 1024 Byte ein Umlaut (oder, ich vermute, ein anderes Sonderzeichen) erscheint.

Das deckt sich mit meinen Erfahrungen:
"Dann drauf gekommen:
nach der Umstellung auf ANSI tatsächlich auch mal einen Umlaut eingegeben und dann abgespeichert.
Siehe da: ANSI bleibt erhalten."
Da habe ich ja auch gleich am Anfang einen Umlaut eingegeben.

Ich habe es gelesen. Ich bin aber nicht sicher, ob wir behaupten können, daß nicht in ANSI abgespeichert wird, genauer gesagt bin ich ziemlich sicher, daß beim Speichern die ANSI-Kodierung erfolgt.
Nach meinen Beobachtungen wird zwar in ANSI gespeichert, aber der Bug tritt nur beim Lesen auf. Ich kann das mit dem Speichern aber nur indirekt erkennen, denn ich weiß nicht, woran man eine im ANSI-Format gespeicherte Textdatei informationstechnisch (Dateistruktur, einleitende Bits, was auch immer) erkennt. Ich sehe nur: Wenn ich den Inhalt einer KaLoMa-Datei, bei der die Umlaute erst nach 1024 Byte auftreten, in Wordpad öffnen, kopiere und in Notepad einfüge (und dann natürlich die Umlaute aufgrund der direkten Texteingabe zu sehen sind) und dann in Notepad mit ANSI-Format abspeichere, dann wird diese Datei in KaLoMa richtig gelesen und die Umlaute richtig angezeigt. Was ja wohl zwingend voraussetzt, daß Notepad die Datei im ANSI-Format gespeichert hat.
Jenseits dieser Schlußfolgerung, die das Abspeichern durch Notepad betrifft, kann ich daher mit 100% Sicherheit (nur) sagen, daß Notepad beim Lesen/Öffnen einer Datei ungeachtet des Formats/Kodierung der Datei Umlaute und Sonderzeichen bzw. die festgelegte ANSI-Kodierung ignoriert, wenn der erste Umlaut/Sonderzeichen erst nach dem 1024. Byte auftritt.

Wenn nur als ANSI gelesen (oder gespeichert) würde, wenn überhaupt irgendwo in der Datei ein Umlaut/Sonderzeichen auftaucht, dann würde ich das zwar immer noch als Bug ansehen (weil explizit beim Speicher vorgegeben), aber MS könnte und würde das als "stringent" und "logisch" verteidigen: ANSI-Format nur bei Bedarf und Bedarf nur wenn Umlaute/Sonderzeichen vorkommen.
Aber der tatsächliche Bug ist ja, daß in den ersten 1024 Byte ein Umlaut/Sonderzeichen vorkommen muß! Es hilt nichts, wenn nach den ersten 1024 "normalen" Zeichen 100 oder 1.000 Sonderzeichen vorkommen.

Man kann ja eine "Default"-Txt Datei anlegen mit z.B.:

Code: Alles auswählen

rem ö

am Anfang.

Wie geschrieben hatte ich das getan mit der dafür vorgesehenen Datei "template.txt" im Ordner c:\windows\shellnew. Früher, also noch ANSI Standard war, sollte diese (leere) Datei im UTF-8-Format gespeichert bewirken, daß Notepad eine/die neue Datei als UTF-8-Datei öffnet. Einzutragen in der Registry:

Code: Alles auswählen

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.txt\ShellNew]
"FileName"="template.txt"

Mit Win11 bzw. UTF-8 als Standard und ANSI als Format dieser template.txt funktioniert das aber nicht - also in Hinblick auf das Wunschformat ANSI.
Gestern konnte ich feststellen (bzw. meine mich so zu erinnern): Solange diese Datei leer ist wird das ANSI Format der Datei ignoriert. Hat sie einen Inhalt, wird diese template.txt-Datei regulär als Textdatei geöffnet. Steht innerhalb der ersten 1024 Byte ein Umlaut/Sonderzeichen, wird auf ANSI-Kodierung umgeschaltet. Andernfalls eben nicht und auch danach erscheinende Umlaute werden nicht richtig angezeigt.
Heute: Die template.txt-Datei wird insgesamt ignoriert. Keine Ahnung wieso.

Bin jetzt dazu übergegangen, den alten Editor (also nicht die Store App) wieder als Standard Editor zu implementieren.
Dazu werden bei mir bei einer Neuinstallation u.a. folgende Registry-Einträge vorgenommen:

Code: Alles auswählen

;Restore Old Classic Notepad on Windows 11
[HKEY_CLASSES_ROOT\Applications\notepad.exe]
"NoOpenWith"=-
[HKEY_CURRENT_USER\Software\Microsoft\Notepad]
"fWindowsOnlyEOL"=dword:00000000
"fPasteOriginalEOL"=dword:00000000
"ShowStoreBanner"=dword:00000000
"iDefaultEncoding"=dword:00000001

Bei mir ebenso plus zahlreiche weitere Einträge.

Code: Alles auswählen

[HKEY_CLASSES_ROOT\*\shell\Mit Notepad öffnen\command]
@="notepad.exe %1"
"Icon"="C:\\Windows\\System32\\notepad.exe"

Fehlt bei mir.

Code: Alles auswählen

"iDefaultEncoding"=dword:00000001

setzt übrigens ANSI als Standard.[/code]
https://www.querrum.de/querbeet/Notepad ... ndern.html

Wie ich bereits dazu geschrieben haben: Das gilt nicht (mehr) für Windows 11 bzw. dessen Notepad. Probiere es aus, es funktioniert leider nicht.

[Holgi]

Code: Alles auswählen

;Restore Old Classic Notepad on Windows 11
[HKEY_CLASSES_ROOT\Applications\notepad.exe]
"NoOpenWith"=-
[HKEY_CURRENT_USER\Software\Microsoft\Notepad]
"fWindowsOnlyEOL"=dword:00000000
"fPasteOriginalEOL"=dword:00000000
"ShowStoreBanner"=dword:00000000
"iDefaultEncoding"=dword:00000001

Bei mir ebenso plus zahlreiche weitere Einträge.

was hast du noch für Einträge?

[MarkF]

Hier
https://www.heise.de/ratgeber/Zurueck-z ... 32890.html
steht, daß Du das alte Notepad nicht zu installieren brauchst sondern nur das neue Notepad deinstallieren mußt. Ausprobiert habe ich es nicht.

Mir fiel eben erst auf, daß man beim Öffnen einer Datei aus dem Notepad-Dateiöffnungs-Dialog heraus die automatische Erkennung der Kodierung oder dezidiert z.B. ANSI wählen kann (ich öffne Textdateien bislang immer aus dem Explorer-Kontext-Menü). Wählt man dezidiert ANSI klappt alles. Der Bug liegt also in der automatischen Erkennung der Kodierung.

So sieht es in Registry bei mir aus:

Code: Alles auswählen

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Notepad]
"fWindowsOnlyEOL"=dword:00000000
"fPasteOriginalEOL"=dword:00000000
"fReverse"=dword:00000000
"fWrapAround"=dword:00000000
"fMatchCase"=dword:00000000
"iWindowPosX"=dword:fffffffb
"iWindowPosY"=dword:00000050
"iWindowPosDX"=dword:00000492
"iWindowPosDY"=dword:00000270
"fWrap"=dword:00000000
"StatusBar"=dword:00000001
"lfEscapement"=dword:00000000
"lfOrientation"=dword:00000000
"lfWeight"=dword:00000190
"lfItalic"=dword:00000000
"lfUnderline"=dword:00000000
"lfStrikeOut"=dword:00000000
"lfCharSet"=dword:00000000
"lfOutPrecision"=dword:00000003
"lfClipPrecision"=dword:00000002
"lfQuality"=dword:00000001
"lfPitchAndFamily"=dword:00000002
"lfFaceName"="Avojaloina"
"iPointSize"=dword:0000006e
"iDefaultEncoding"=dword:00000001

[Holgi]

wegen der Registry:
alles klar. Ist natürlich bei mir auch so. Die eher unwichtigen bzw. nicht individuellen Einstellungen hatte ich weggelassen.
Ich dachte, du hättest da noch ein paar Kniffe untergebracht.

Zu deiner Frage auf Heise.de:
nur die notepad.exe reicht nicht.
Da gehört auch noch mindestens eine Sprach-mui dazu, welche z.B. im Ordner System32\de-de bzw. Windows\de-de zu finden ist:
notepad.exe.mui
wofür die c_notepad.exe.mui ist (System32\de-de)? Keine Ahnung!

also:
notepad.exe und Ordner de-De mit der mui immer nebeneinander!

[MarkF]

Hui, danke. Das war die Lösung. Habe jetzt die Win7-Dateien umbenannt in "notepad7" und "notepad7.exe.mui" und in ein eigenes Verzeichnis (die .mui in de-de) gepackt. Nach dem Umbenennen funktioniert sogar die Verknüpfung im Kontextmenü mit "Öffnen mit". Das ist als workaround für mich o.k.
Mit dem Parameter "/A" läßt sich beim 11er-Notepad das Öffnen einer Datei mit ANSI-Kodierung erzwingen. Das funktioniert aber leider nicht ohne Angabe des Dateinamens; ohne, also nur mit "/A", öffnet sich Notepad unverändert in UTF-8. Aber als weiterer Öffnungs-Eintrag im Kontextmenü läßt sich das nutzen, also z.B. als Eintrag "Öffnen als ANSI in Notepad".

[Holgi]

vlt. kann man das hier noch zusätzlich verwenden (für öffnen mit /A):
viewtopic.php?p=413409&hilit=notepad#p413409

[MarkF]

So ganz nachvollziehen konnte ich das ad hoc nicht, aber letztlich wäre ein Zwangsöffnen als ANSI bei "Öffnen mit" ohnehin suboptimal. Nämlich dann, wenn es sich nicht um eine ANSI-codierte Datei handelt. Und das ist sicherlich nicht allzu selten. Dieser bug in der automatischen "Erkennung" der Kodierung ist zwar ärgerlich (und wirkt sich, das muß ich zugestehen, vermutlich ohnehin nur selten aus), aber ein zwangsweises Öffnen jeder Datei als ANSI-codiert wäre noch übler. Ich habe bei mir zusätzlich (neben der "Aktivierung" des alten Notepads) als temporären workaround einen zusätzlichen Eintrag "Öffnen als ANSI in Notepad" ins Kontextmenü gebastelt und das genügt mir, damit kann ich leben.