@guy038 Merci beaucoup!

Search++ version 0.6.2 is available: Fix a critical error that caused ICU searches to crash Notepad++. Fix unwanted characters appearing at the ends of lines in the Results list with Notepad++ rendering mode GDI. Fix regression of line ending symbols being in text color instead of white space color, and switch the CRLF symbol in GDI mode to one that hopefully renders more consistently. Thanks to @guy038 for catching the ICU error and the unwanted characters in the results list in GDI mode. (The ICU error appears to have been due to an uninitialized variable. The faulty code has been there from the beginning. As chance would have it, up until now it just happened to land on memory that contained an innocuous value. Hopefully I didn’t miss anything else similar…)

@Coises said: 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. Yeah, so for example: “Treat ASCII-only files as UTF-8 (instead of ANSI)” or something similar could be a more clear wording for the option. Which, for me, raises the question: Why is this only available when UTF-8 is the default encoding for new files? It would add a bit more flexibility to the user, but on the other side it seems very unlikely to set this option if you don’t want UTF-8 as default. So I guess it could be a preventative measure that the user doesn’t set any confusing options.

@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.

@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).

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.

FYI: Notepad++ v8.9.7 RC2 is available now: https://github.com/donho/notepad-plus-plus/releases/tag/RC2

@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