@guy038 Merci beaucoup!

@guy038 said: But you found out the culprit : it’s just because the GDI ( most compatible) option was selected !. Luckily, for any other option of the rendering mode, after closing an re-starting N++, this special character does not display, anymore ! Thanks for documenting that! It should appear correctly in GDI mode too, of course. I suspect the problem will turn out to be that GDI mode doesn’t support alpha transparency, so my setting the opacity to zero is doing nothing. I’ll have to find another way.

@ThosRTanner said: This doesn’t seem terribly useful for an installation package though. This is exactly my use case: I download the zip archive end selectively extract only changed files. Some of the files in my installation I explicitly do NOT want to get overwritten. In the end it is really just a matter of taste. And I really appreciate the possibility to choose my desired format. From this I support the current situation, that both format are presented for download.

The Python script I posted is expected to handle single byte errors from UTF8 decoding. Asian languages can be 2 byte for ANSI and so the script may need to get the following byte too to decode both bytes properly. Probably will not find recovery tools and the like that will fix mixed encoding errors as the solution in some cases might be worse then the problem though in this case tested OK. Once saved, then there might be no going back and so creating a backup before the operation would be wise. Inspect the results to confirm is OK.

@Alan-Kilborn said: But it isn’t exactly obvious what its function is, based only upon the UI text. @MarkusBodensee said: Yes, exactly what I thought while taking the screenshots The option is on the “New Document” panel, no doubt, because it is only available when the default encoding for new documents is set to UTF-8. Yet it doesn’t apply to new documents, it applies to existing files. What is really means is, when Notepad++ opens an existing file that contains only ASCII characters, it should treat it as UTF-8 rather than as ANSI. Which, for me, raises the question: Why is this only available when UTF-8 is the default encoding for new files? Background in case anyone reading this doesn’t know: ASCII comprises 128 codes, from 0-127. All the characters on a standard US keyboard are ASCII, but most languages other than English use characters that ASCII lacks. UTF-8 is a standard method for encoding Unicode, a set of over one hundred thousand characters that includes very nearly every character needed for every known language. ANSI refers to any of several dozen legacy “code pages” that were used in Windows to support different languages before Unicode was developed. These encodings are still in common use. In Notepad++, ANSI always refers to the “system default code page,” the one the Windows system on which Notepad++ is running recognizes as the “normal” encoding for files on that system. The specific code page that is default varies by country. The first 128 codes in all ANSI code pages and in UTF-8 are the same as the 128 ASCII characters. Because of all this, when opening a file that contains only ASCII characters, there is no way to distinguish whether it is ANSI or UTF-8 (or some code page other than the system default code page). The results are identical. When Notepad++ loads a file into an editing area, it has to determine which encoding to use. For a pure ASCII file, it will only matter if and when you edit the file by adding characters that are not in the ASCII range. Once you do that, the results will differ depending on which encoding was chosen. This setting lets you tell Notepad++ whether it should load pure ASCII files so that, if you add non-ASCII characters to them, they will wind up as ANSI, or so that they will wind up as UTF-8.

@rafaello , IANAL, and I don’t own the trademark, but with your clarifications and updates, I believe you’re probably not violating the trademark (IMO). It’s good to see someone who is willing to accept such feedback (rather than digging in your heels for a while, like happened with the aforementioned fork).

@PeterJones Perfect thank you very much!

@rdipardo thank you for pointing that out. I will check and do the needful.

because it appears those actually return from the enum UniMode, which is enum UniMode {uni8Bit=0, uniUTF8=1, uni16BE=2, uni16LE=3, uniCookie=4, uni7Bit=5, uni16BE_NoBOM=6, uni16LE_NoBOM=7, uniEnd}; according to the source code. In N++ commit 8149f72 in v8.8.8 (Nov 2025), uniCookie has been renamed as uniUTF8_NoBOM inside the N++ source. Thus, I just put in PythonScript Issue #421 to request that there’s a BUFFERENCODING.UTF8_NOBOM, either as replacement or alias of the old meaninglessly-named BUFFERENCODING.COOKIE … I don’t know if it will happen, but at least the request is in. :-)

Another example can be seen at https://community.notepad-plus-plus.org/topic/27601/with-the-help-of-a-regex-how-to-find-code-preceded-by-a-only-if-code-is-absent-between-style-and-style-in-the-css-section-which-is-below/4