Currently if a script file lacks a BOM, AutoHotkey defaults to interpreting it as ANSI. UTF-8 was the default for a short time, but it caused issues since Notepad is the default editor, and Notepad did not default to UTF-8. IIRC, the "UTF-8" option in Notepad was UTF-8 with BOM; now it is without BOM.What's new in the Windows 10 Insider Preview Builds 1903 - Windows Insider Program | Microsoft Docs
We’ve made significant improvements to the way Notepad handles encoding. Starting with this build, we are adding the option to save files in UTF-8 without a Byte Order Mark and making this the default for new files. UTF-8 without a Byte Order Mark is backwards-compatible with ASCII and will provide better interoperability with the web, where UTF-8 has become the default encoding. Additionally, we added a column to the status bar that displays the encoding of the document.
The /cp65001 command-line switch can be used to make UTF-8 the default for script files (but it does not affect A_FileEncoding). If you add this into the command line associated with .ahk files in the registry (i.e. HKCR\AutoHotkeyScript\Shell\Open\Command) it effectively becomes the default for .ahk files launched via Explorer. There's currently no option in the installer for this, but it does detect whether the switch was present and preserve it when reinstalling.
For Windows v1903+, I'm thinking that I will make UTF-8 the default for script files. I have not decided how; I could:
- Have the AutoHotkey installer add /cp65001 by default in new installations on v1903+. I suppose this benefits new users while minimizing change for existing users.
- Change the default within AutoHotkey.exe on v1903+. The previous behaviour could be restored by adding /cp0 to the command line. Existing scripts which are saved without a BOM might be adversely affected, although I suppose that updating to v1903 might have already caused problems if you're using Notepad. If a user updates to v1903 after installing AutoHotkey, the behaviour will change to match Notepad.