Das Verhalten von TIniFile bzw. der dahinter liegenden WritePrivateProfileString Funktion ist in der Tat schwer zu durchschauen.
Zum Einen wird
Unicode geschrieben, wenn die Datei schon als
Unicode Datei vorliegt, andernfalls
ANSI:
https://learn.microsoft.com/en-us/wi...profilestringa
Zitat:
If the file was created using
Unicode characters, the function writes
Unicode characters to the file. Otherwise, the function writes
ANSI characters.
Dazu kommt dann noch eine etwas versteckt liegende Windows-Option, die anstatt
ANSI dann netterweise UTF8 schreibt:
https://en.wikipedia.org/wiki/Unicod...rosoft_Windows
Zitat:
In April 2018 (or possibly November 2017[13]), with insider build 17035 (nominal build 17134) for Windows 10, a "Beta: Use
Unicode UTF-8 for worldwide language support" checkbox appeared for setting the locale code page to UTF-8.[a] This allows for calling "narrow" functions, including fopen and SetWindowTextA, with UTF-8 strings. However this is a system-wide setting and a program cannot assume it is set.
https://learn.microsoft.com/en-us/wi...utf8-code-page
Zitat:
-A vs. -W APIs
Win32 APIs often support both -A and -W variants.
-A variants recognize the
ANSI code page configured on the system and support char*, while -W variants operate in UTF-16 and support WCHAR.
Until recently, Windows has emphasized "
Unicode" -W variants over -A APIs. However, recent releases have used the
ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the
ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.
Nur so am Rande:
https://learn.microsoft.com/en-us/wi...profilestringa
Zitat:
Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should store initialization information in the registry.