Discrepancy in "Find in Files": UTF-16 bug and missing report for skipped binary files

[daddel80]

Summary

As reported by @guy038 in the Notepad++ Community Forum, "Find in Files" (v6.0.0.36) returns significantly fewer matches than native Notepad++ and the Search++ plugin on identical searches.

Original forum thread: [Insert Link to Forum Post]
Follow-up post with both test cases: [Insert Link to Post 106204]

Test case 1: USB drive scan

Search: Fi, Regular expression + Match case enabled, filter *.*, entire drive (1,772 files).

Tool	Matches	Files
Notepad++ native	27,081	841
Search++	27,081	841
MultiReplace Find in Files	18,767	726

Test case 2: E:\Test folder (7 files)

Same search, MultiReplace only, folder open in N++ with no session:

• Find in Files: 83 hits in 3 files
• Find in Docs: 372 hits in 7 files

Root causes (two separate issues)

1. Binary files skipped without UI feedback (by design, undocumented)
HiddenSciGuard::loadFile skips any file with a NUL byte in its first 8 KB and no BOM, the same heuristic grep uses. Native N++ and Search++ scan such files as raw bytes and count matches inside them (e.g. .exe, .dll, .pdf, .zip). This is likely the main driver of test case 1. Not a bug, but _skippedBinaryCount is tracked internally and never surfaced to the user.

• Fix: show "N binary files skipped" in the result summary / dock header.

2. UTF-16 files mishandled in Find in Files (actual bug)
In the Find in Files loop, isLikelyBinary (MultiReplacePanel.cpp) flags any file containing a NUL byte anywhere in the buffer, including UTF-16 files with a BOM that loadFile deliberately let through. Those get searched as raw ANSI bytes, so Fi can never match F\0i\0. UTF-16 files without a BOM are separately caught by the binary skip in loadFile. Replace in Files does not have this flaw (decodes via Encoding::detectEncoding before searching), and Find in Docs works on buffers Notepad++ has already decoded, which is why results diverge between the three modes.

• Fix: apply the same encoding detection Replace in Files uses before the binary heuristic in Find in Files.

Test case 2 most likely combines both causes (some of the 4 missing files binary-skipped, some UTF-16-miscounted) rather than being a clean example of #2 alone, to be confirmed once the test files are available.

Verification pending

@guy038 has offered to share the E:\Test folder contents. Will attach here and re-verify both fixes against it before closing.

[daddel80]

@guy038 Before you upload the files, I'm preparing an update for you to test.

[guy038]

Hi, @thomas-knoefel,

First, many thanks for creating this immediate and complete GitHub post, inspired from mine on NodeBB !!

For information, note that all the tests, including this one, were conducted with N++ v8.9.0

The contents of the E:\Test that I'm ready to send you, are :

 Le volume dans le lecteur E s’appelle STORE-N-GO
 Le numéro de série du volume est 1CD9-0AC4

 Répertoire de E:\Test

29/08/2026  09:15    <DIR>          .
29/08/2026  09:15    <DIR>          ..
29/08/2026  10:13    <DIR>          890
15/05/2025  00:10            35 500 license_890.txt
28/08/2026  13:53             8 283 Mark_Style.txt
09/11/2025  11:10            14 272 Xomx.txt
               3 fichier(s)           58 055 octets

 Répertoire de E:\Test\890

29/08/2026  10:13    <DIR>          .
29/08/2026  10:13    <DIR>          ..
29/08/2026  10:13    <DIR>          Plugins
28/12/2025  16:31           533 449 langs.xml
27/12/2025  14:31         8 356 480 Notepad++.exe
28/12/2025  16:27         5 996 623 npp.8.9.portable.x64.7z
               3 fichier(s)       14 882 840 octets

 Répertoire de E:\Test\890\Plugins

29/08/2026  10:13    <DIR>          .
29/08/2026  10:13    <DIR>          ..
08/02/2026  11:17           668 160 Marginalize.dll
               1 fichier(s)          668 160 octets

By the way, don't bother about my French post Mark_Style.txt as well as the xomx.txt file wich recapitulates all my posts to @xomx, either on NodeBB or GitHub forums. They are just, with the License_890.txt and the langs.xml files, simple UTF-8 files. The three last files are the executable notepad++.exe, the archive npp.8.9.portable.x64.7z and a @Coises plugin named Marginelize.dll which are all ANSI encoded !

All these files had previously been chosen, at ramdom, just for the test. However, as you can see, I simply use 4 UTF-8 files and 3 binary files. Thus, I don't know if this will be enough to solve all the problems !? My test with the entire D: key should be better ?

Of course, this post have been saved on the E:\ key in order to not change the future results from the D:\ USB key ;-))

---

Here are the two screen-shoots of the Find in Files and Find in Docs operations :

and :

Best Regards

guy038

[daddel80]

Hi @guy038,

Thanks for the detailed file listing! It's very helpful to see exactly what we are dealing with.

Actually, the UTF-16 fix was already completed on my end and waiting for the next release. Your thorough testing perfectly confirms why it was so important to get that patched! MultiReplace now correctly detects the encoding before searching.

I also changed how binary files are handled so nothing happens silently anymore.

There is now a new "Skip binary files" setting in the Settings Panel(on by default). If you turn it off, binaries get searched as raw bytes, just like in native N++.

The result header now explicitly states how many files were skipped and why. It looks like" Search "NEEDLE" (32 hits in 16 file(s)) [20 file(s) searched, 4 skipped: 3 binary, 1 not decodable]"

Your 7-file test (4 texts + 3 binaries) is a perfect quick check for this. With the default settings, the summary should clearly report the 3 binaries as skipped.

I'll provide you with a new build, I would appreciate it if you could give it some tests!

New Build to test

Best regards,
Thomas

[guy038]

Hi, @thomas-knoefel,

I'm pleased to confirm that the Multi-Replace-Release-x64 version of your New Build to test gives exactly the same results with N++, Search++ and MultiReplace

As you specified, I first disabled the MultiReplace Settings > File Search > Skip binary files option, in order to scan all files

Of course, the number of occurrences slightly changed from 27,081 to 27,129 for the three kinds of search, as shown in this screen-shot :

And, for the tiny subset of 7 files, within the E:\Test folder, the results followed the same scheme : they are all identical as well !

Thus, I suppose that I do not need to send you the Test.zip archive !

Thank you so much for this quick fix !!

Best Regards

guy038

P.S. :

In Settings > File Search, you could omit the File Search : already written on the left !

P.P.S. :

As promised, I'll soon study the Search/Replace functionality of your plugin more closely, like I did with the Columns++ and the Search++ plugins of @Coises !

[guy038]

Hello, @thomas-knoefel,

I did again the tests contained in the E:\Test folder

As you can see, in the screen-shot below :

• The first two searches scan all the files and give the same results => OK

• The third search is run with the Skip binary files enabled option => OK., but you'll notice that the Mark_Style.txt although an UTF-8 file is also considered as a binary file. I supposed that is because it contains some codes under 0x20. Here are the full contents of the Mark_Style.txt file :

Le raccourci, par DÉFAUT, 'Ctrl + Shift + 0', pour atteindre le 'Mark style' PRÉCÉDENT, NE fonctionne PAS correctement

D'après @alan_kilborn, il y a une ASTUCE a effectuer dans les paramètres de Windows 11 :

    • Appuyer sur la touche 'Paramètres' du clavier bluetooth 'Microsoft'

    • Sélectionner, en partie GAUCHE, le choix 'Heure et Langue'

    • Sélectionner, en partie DROITE, le 4ème choix 'Saisie'

    • Sélectionner, en partie DROITE, le 7ème choix 'Paramètres avancés du clavier'

    • Cliquer, tout en BAS, sur l'option 'Touches de raccourci de langue d'entrée'

    • Cliquer sur le bouton 'Modifier'

    • Cliquer, en partie GAUCHE ( Changer la langue d'entrée ), le choix 'Non assignée'

    • Cliquer sur le bouton 'OK' pour valider

    • Cliquer enfin sur le bouton 'Appliquer' puis sur le bouton 'OK'

Cependant, cette méthode reste INOPÉRANTE sur mon micro !

Finalement, la méthode la plus simple consiste à REMPLACER les raccourcis 'Ctrl + 0' et 'Ctrl + Shift + 0' par 'Ctrl + 6' et 'Ctrl + Shift + 6' dans le gestionnaire de raccourcis 'Shortcut Mapper'

L'avantage de cette méthode fait que vous pouvez, désormais, entrer directement le caractère 'NUL' en activant le raccourci 'Ctrl + 0'


NOTES :

• Compte tenu des différentes commandes N++ de la forme 'Ctrl + Lettre', seuls les DEUX raccourcis 'Ctrl + 0' et 'Ctrl + E affichent le caractère 'NUL' et 'ENQ'


• Ne JAMAIS utiliser la forme ALT + Signe PLUS + chiffre 0.  Si ce raccourci à été activé par ERREUR :

    • Sauvegarder le fichier COURANT avec l'option 'File > Save'

    • Fermer Notepad++

    • Appuyer sur 'Ctrl + Alt + .'

    • Choisir l'option 'Se déconnecter"


• Si l'option 'Prevent control character (C0 code) typing into document' dans 'Settings > Préférences... > Editing2' est COCHÉE :

  => TOUS les caractères en ORANGE, produits par l'une des formes ci-DESSOUS, ainsi que les caractères 'LF' et 'CR', NE seront JAMAIS affichés


REMARQUE : l'affichage des tableaux ci-dessous est CORRECT avec le micro HP, sous Windows 11


  •-------------•---------•           •-------•-------•          •--------•-------•          •-----------------•-------•           •-------------------------•-------•
  | Alt + '+' + | Unicode |           | Alt + |  850  |          | Alt +  |  1252 |          |  Ctrl + Lettre  |  CHR  |           |  Ctrl + Shift + Lettre  |  CHR  |
  •-------------•---------•           •-------•-------•          •--------•-------•          •-----------------•-------•           •-------------------------•-------•
  |  [[0]0]00   |  ██████ |           | [0]00 |  None |          |  0000  |  None |          |  Ctrl + 0       |     |           |                         |       |
  |  [[0]0]01   |   �   |           | [0]01 |  �  |         |  0001  |  �  |          |                 |       |           |  Ctrl + Shift + A       |  �  |
  |  [[0]0]02   |   �   |           | [0]02 |  �  |         |  0002  |  �  |          |                 |       |           |                         |       |
  |  [[0]0]03   |   �   |           | [0]03 |  �  |         |  0003  |  �  |          |                 |       |           |  Ctrl + Shift + C       |  �  |
  |  [[0]0]04   |   �   |           | [0]04 |  �  |         |  0004  |  �  |          |                 |       |           |  Ctrl + Shift + D       |  �  |
  |  [[0]0]05   |   �   |           | [0]05 |  �  |         |  0005  |  �  |          |  Ctrl + E       |  �  |           |  Ctrl + Shift + E       |  � |
  |  [[0]0]06   |   �   |           | [0]06 |  �  |         |  0006  |  �  |          •-----------------•-------•           |                         |       |
  |  [[0]0]07   |   �   |           | [0]07 |  �  |         |  0007  |  �  |                                                |  Ctrl + Shift + G       |  �  |
  |  [[0]0]08   |   �    |           | [0]08 |  �   |         |  0008  |  �   |                                                |  Ctrl + Shift + H       |  �   |
  |  [[0]0]09   |   	  |           | [0]09 |  	   |         |  0009  |  	  |                                                |  Ctrl + Shift + I       |  	 |
  |  [[0]0]0A   |   LF    |           |  010  |  LF    |         |  0010  |  LF   |                                                |  Ctrl + Shift + J       |  LF   |
  |  [[0]0]0B   |   �    |           |  011  |  �   |         |  0011  |  �   |                                                |                         |       |
  |  [[0]0]0C   |       |           |  012  |     |         |  0012  |     |                                                |                         |       |
  |  [[0]0]0D   |   CR    |           |  013  |  CR    |         |  0013  |  CR   |                                                |  Ctrl + Shift + M       |  CR   |
  |  [[0]0]0E   |   �    |           |  014  |  �   |         |  0014  |  �   |                                                |                         |       |
  |  [[0]0]0F   |   �    |           |  015  |  �   |         |  0015  |  �   |                                                |  Ctrl + Shift + O       |  �   |
  |  [[0]0]10   |   �   |           |  016  |  �  |         |  0016  |  �  |                                                |                         |       |
  |  [[0]0]11   |   �   |           |  017  |  �  |         |  0017  |  �  |                                                |                         |       |
  |  [[0]0]12   |   �   |           |  018  |  �  |         |  0018  |  �  |                                                |                         |       |
  |  [[0]0]13   |   �   |           |  019  |  �  |         |  0019  |  �  |                                                |                         |       |
  |  [[0]0]14   |   �   |           |  020  |  �  |         |  0020  |  �  |                                                |                         |       |
  |  [[0]0]15   |   �   |           |  021  |  �  |         |  0021  |  �  |                                                |                         |       |
  |  [[0]0]16   |   �   |           |  022  |  �  |         |  0022  |  �  |                                                |  Ctrl + Shift + V       |  �  |
  |  [[0]0]17   |   �   |           |  023  |  �  |         |  0023  |  �  |                                                |                         |       |
  |  [[0]0]18   |   �   |           |  024  |  �  |         |  0024  |  �  |                                                |                         |       |
  |  [[0]0]19   |   �    |           |  025  |  �   |         |  0025  |  �   |                                                |  Ctrl + Shift + Y       |  �   |
  |  [[0]0]1A   |   �   |           |  026  |  �  |         |  0026  |  �  |                                                |                         |       |
  |  [[0]0]1B   |   �   |           |  027  |  �  |         |  0027  |  �  |                                                |                         |       |
  |  [[0]0]1C   |   �    |           |  028  |  �   |         |  0028  |  �   |                                                |  Ctrl + Shift + 8       |  �   |
  |  [[0]0]1D   |   �    |           |  029  |  �   |         |  0029  |  �   |                                                |                         |       |
  |  [[0]0]1E   |   �    |           |  030  |  �   |         |  0030  |  �   |                                                |  Ctrl + Shift + 9       |  �   |
  |  [[0]0]1F   |   �    |           |  031  |  �   |         |  0031  |  �   |                                                •-------------------------•-------•
  |  [[0]0]20   |   SP    |           |  032  |  SP   |          |  0032  |  SP   |
  |             |         |           |  ...  |  ...  |          |  ....  |  ...  |
  |  [[0]0]7F   |  �    |           |  127  |  ⌂    |          |  0127  |  � |
  •-------------•---------•           •-------•-------•          •--------•-------•

Note that I don't mind this oddity. I understand that the plugin considers this specific file as a binary file !

---

More annoying is the fourth case : although the Skip binary files option is enabled, the Find in Docs option gives the save results like when this option is disabled !

Best Regards,

guy038

[daddel80]

Hi @guy038,

That is fantastic news! Seeing the exact same match count across N++, Search++, and MultiReplace is exactly I was hoping for.

You also made two excellent observations regarding your smaller test folder, which I have addressed in the newest build:

Mark_Style.txt: You nailed it - the control characters (like NUL) in your table are exactly what triggers the binary heuristic, and that classification itself is correct and stays as-is. What I've improved is what happens next: with "Skip binary files" unchecked, the plugin now checks whether the file is structurally valid UTF-8 despite those control characters, and if so, searches and displays it using the correct encoding instead of falling back to ANSI. That means accented words like PRÉCÉDENT will now be found and shown correctly instead of turning into mojibake.

Find in Docs: Good catch, and worth clarifying - "Skip binary files" is deliberately not applied there. Open documents are ones you've already loaded and decided to keep open, so native N++ searches all of them too, and I want to keep that exact behavior. What I did add is transparency: the summary header now tells you exactly how many open documents were searched versus excluded by the document filter (e.g., [5 document(s) searched, 2 excluded by filter]) - the same clarity the Find in Files header already gives you.

And the "File Search:" label in the SettingsPanel cleaned up as well.

I've attached a new build . Feel free to play around with it.

Thanks again for polishing this release!

Best regards, Thomas

[guy038]

Hello, @thomas-knoefel,

Again, with your second new version of Multi-Replace-Release-x64, the N++ search, the MultiReplace search and the Search++ search in files give the same results , with, this time, 27,112 hits !

---

You said :

What I've improved is what happens next: with "Skip binary files" unchecked, the plugin now checks whether the file is structurally valid UTF-8 despite those control characters, and if so, searches and displays it using the correct encoding instead of falling back to ANSI.

However, as you can verify with the screen-shot below, is that nothing has changed since your first new built and that the MArk-Style.txt file is still considered as a binary file ! Again, I don't bother personally about this specific case ( just in case you hesitate to study this problem more deeply ! )

---

I also noted that, unlike with the native Find in files feature of N++, if you modify a file without saving it, the Find in Files feature does not take these new modifications in account for, both, your plugin and the Search++ plugin of @Coises !

However, note that the Count , the Find All the Find All in All Opened Documents and the Mark features do take these new unsaved modifs in account with either N++, Search++ and MultiReplace ! It's also the case with the Count feature of the Columns++ plugin of @Coises !

This can be summarized in the following table :

    •================•=========•============•===================•=================•========•
    |                |  Count  |  Find All  |  Find All in All  |  Find in Files  |  Mark  |
    |                |         |            |    Opened Docs    |                 |        |
    •================•=========•============•===================•=================•========•
    |  Notepad++     |    OK   |     OK     |        OK         |       OK        |   OK   |
    •----------------•---------•------------•-------------------•-----------------•--------•
    |  Search++      |    OK   |     OK     |        OK         |       KO        |   OK   |
    •----------------•---------•------------•-------------------•-----------------•--------•
    |  MultiReplace  |    OK   |     OK     |        OK         |       KO        |   OK   |
    •----------------•---------•------------•-------------------•-----------------•--------•
    |  Columns++     |    OK   |     n/a    |        n/a        |       n/a       |   n/a  |
    •================•=========•============•===================•=================•========•

---

Finally, an other question : why the bookmarks of the matched lines are not also deleted when you click on the Clear all marks button and that the Bookmark matched lines indication is checked ? With the native N++ Mark feature, the bookmarks remain ONLY IF the Bookmark line option is not checked !

Best Regards,

guy038

[daddel80]

Hi @guy038,

Thank you for confirming the parity again, both of your findings were great catches.

On Mark_Style.txt: nothing changing is expected, the file is still correctly classified as binary due to the literal NUL bytes in your table, so the fix isn't visible there. It only shows up with non-ASCII search terms. Quick test: uncheck "Skip binary files" and search for a word with an accent, like PRÉCÉDENT. Old build: no hits, just ANSI mojibake. New build: correct hits, no mojibake.

Bookmarks are fixed too: "Clear all marks" now also removes bookmarks when "Bookmark matched lines" is checked, matching native N++.

Find in Files now shows OK on your table too. ;-) Files open in Notepad++ are now searched through their live document instead of on-disk content, matching native N++. If a file has unsaved changes, Find in Files now sees what's in the editor, not the stale disk version. New setting, "Search open documents instead of files on disk" (Settings > File Search), on by default.

Replace in Files: doesn't write to a file anymore if it's open with unsaved changes, it skips it instead and reports it in the summary ("N file(s) skipped: open with unsaved changes").

New build attached

Best regards,
Thomas

[guy038]

Hello, @thomas-knoefel,

Due to a reorganization of my USB drive D: le number of files and hits has decreased significantly. However, again, the results are identical for N++, Search++ and MultiReplace :

( 24581 hits in 582 file(s))[1075 file(s) searched]

BTW, could you add a comma or a space separator for readability. This would give (24,581 hits in 582 file(s))[1,075 file(s) searched] or ( 24 581 hits in 582 file(s))[1 075 file(s) searched] ?

---

You said :

Quick test: uncheck "Skip binary files" and search for a word with an accent, like PRÉCÉDENT. Old build: no hits, just ANSI mojibake. New build: correct hits, no mojibake.

No problem : within my USB key, I've got plenty of French files which do give Fi hits and are correctly listed in your Search results panel, with the last builds ! See an example in the snapshot below :

---

Now, many thanks for scanning the document buffers rather than their equivalents on disk and also for adding the new option Search open documents instead of files on disk ;-)

Note, that in the Settings > Preferences... > Searching panel of the last v8.9.8 release, there is, as well, a new option : Find in Files: Prefer on-disk file content over open buffers which is disabled, by default !

---

A last request if not too difficult to implement. I noticed that :

• Within the N++ Search results, it is possible to easily see all files which has matches, without seeing the matched lines :

  • By hitting Ctrl and clicking on ⊟, on the first line ( Search ... ) => The search collapses after some time and then with a simple click on ⊞

  • By using the Fold All option of the Context dialog and then a simple click on ⊞ of the first line

• To get again the full list again : :

  • Do a simple click on ⊟, on the first line and then, hit Ctrl and click on ⊞ => The search expands after some time

  • Use the Unfold All option of the Context dialog

• Within the Search++ Results panel, just right-click on the empty olive zone, on the left and choose the second Expand/Collapse Documents option

Could you also get this behavior within your plugin ? Just a suggestion, of course !

Best Regards,

guy038

[daddel80]

Hi @guy038,

I'm glad to hear the UTF-8 fix is doing exactly what it should on your French files!

Regarding your two new requests: You are absolutely right, and I have already implemented both of them.

The numbers in the search summaries will now automatically use your Windows locale's thousand separator, which definitely makes them much easier to read. I have also added a new "Collapse to file list" option to the result dock's right-click menu. A simple click will fold the search block down to just the file names and their hit counts, exactly as you suggested.

While looking into your Ctrl-click hint I noticed the result dock was swallowing the fold modifiers entirely, so those now work as well: Ctrl folds a node with everything below it, Shift expands it, and Ctrl+Shift toggles all folds. Your first route works now too - Ctrl-click the Search ... line, then a simple click to reopen it, and you are left with the bare file list.

The new build.

Thanks again for your excellent ideas and your continuous testing! This is the stage of development where user input like yours counts the most.

Best regards, Thomas

[guy038]

Hello, @thomas-knoefel,

Again, the results are identical for the three searches and give Search "Fi" (24 601 hits in 582 file(s)) [1 075 file(s) searched]. Note the NO-BREAK SPACE char which is used as a thousand separator on my French laptop !

Thanks you also for your new context option Collapse to file list !

---

Now, you could add a new option in the context menu of the Search results panel : Delete current search or Delete all prior searches. However, this new option is not really mandarory as I noticed that, if you put the caret within a green line and hit the Del key, all contents of this specific search is deleted, like in the N+++ search results panel, too !

---

As the last @Coises post said at its end, how to manage properly the Find in Files and Replace in Files features in case of multiple N++ instances ? I only use a mono-instance but I suppose it's probably safer to uncheck the Search open documents instead of files on disk option when several instances of N++ are used, at the same time !

---

Presently, I can't think of other significant improvements about a single Find in Files search ! Of couse, later, I'll study more deeply the list mode of your plugin which seems very powerful too !

Best Regards,

guy038

[daddel80]

Hi @guy038,

Quick follow-up on the last build. While double-checking the thousand separators I found a bug in my own change: Find All in the current document showed "1.1.500 hits" instead of "1.500" once a file had more than 1000 matches. Fixed.

One more thing: Replace in Files used to write a "?" whenever the replacement text contained a character the file's encoding couldn't hold, say an arrow or a Cyrillic letter going into an ANSI file, silently, with no way to tell afterwards. It now leaves such files untouched and reports them in the status line as "not encodable" instead. The other skip reasons (read-only, open with unsaved changes) moved into that same one-line breakdown too, so the summary reads a lot cleaner now.

New build attached.

Best regards, Thomas

[daddel80]

Hi @guy038,

about Coises' post: the difficulty described there comes from Search++ being multithreaded, its file scan runs in worker threads that cannot touch Scintilla buffers. MultiReplace is not built that way, it runs single-threaded on Scintilla, so open documents are no problem here. Multiple instances are a separate question and independent of the option: it only decides how documents open in the same instance are handled. A file open in another instance is invisible to the plugin and always handled on disk, exactly as with native Notepad++. So the option can simply stay on.

For the next build I have taken this one step further. The option is now called "Use open documents instead of files on disk" and covers Replace in Files as well. An open file is replaced directly in the editor, like Replace All on that document: a clean document is saved afterwards, one with unsaved changes is left for you to save and counted in the status line. The reason: writing to disk under an open document caused the reload prompts, and skipping unsaved documents, as the current build does, meant Find showed hits in a file that Replace then reported as skipped. Now both work on the same content, and nothing is saved behind your back. The "open with unsaved changes" skip only remains with the option off.

New build attached.

Best regards, Thomas

[guy038]

Hello, @daddel80,

I've done some other tests using my E:\Tests directory. Here are the files used for these tests :

 Répertoire de E:\Test

29/08/2026  10:13    <DIR>          890
31/08/2026  11:36            35 500 license_890.txt
03/09/2026  13:35             8 283 Mark_Style.txt
09/11/2025  11:10            14 272 Xomx - Copie.txt
03/09/2026  14:52            14 272 Xomx.txt
03/09/2026  12:27            14 218 Xomx_ANSI - Copie.txt
03/09/2026  12:27            14 218 Xomx_ANSI.txt
               6 fichier(s)          100 763 octets

 Répertoire de E:\Test\890

29/08/2026  10:13    <DIR>          Plugins
03/09/2026  13:39           533 881 langs.xml
27/12/2025  14:31         8 356 480 notepad++.exe
28/12/2025  16:27         5 996 623 npp.8.9.portable.x64.7z
               3 fichier(s)       14 886 984 octets

 Répertoire de E:\Test\890\Plugins

08/02/2026  11:17           668 160 Marginalize.dll
               1 fichier(s)          668 160 octets

     Total des fichiers listés :
              10 fichier(s)       15 655 907 octets

And here are the configuration of these 10 files :

•---------------------------•-----------------------•----------•----------------•
|           File            |        Status         | Encoding |  Matches "Fi"  |
•---------------------------•-----------------------•----------•----------------•
|  Mark_Style.txt           |   Contains NUL char   |  UTF-8   |        2       |
•---------------------------•-----------------------•----------•----------------•
|  License_890.txt          |  Read -ONLY Windows   |  UTF-8   |        1       |
•---------------------------•-----------------------•----------•----------------•
|  Xomx.txt                 |                       |  UTF-8   |       10       |
•---------------------------•-----------------------•----------•----------------•
|  Xomx_ANSI.txt            |                       |   ANSI   |       10       |
•---------------------------•-----------------------•----------•----------------•
|  npp.8.9.portable.x64.7z  |  Binary               |   ANSI   |       98       |
•---------------------------•-----------------------•----------•----------------•
|  Marginalize.dll          |  Binary               |   ANSI   |       27       |
•---------------------------•-----------------------•----------•----------------•
|  langs.xml                |  Read_ONLY Notepad++  |  UTF-8   |       72       |
•---------------------------•-----------------------•----------•----------------•
|  notepad++.exe            |  Binary               |   ANSI   |      162       |
•---------------------------•-----------------------•----------•----------------•
|  Xomx - Copie.txt         |  NOT saved            |  UTF-8   |       10       |
•---------------------------•-----------------------•----------•----------------•
|  Xomx_ANSI - Copie.txt    |  NOT saved            |   ANSI   |       10       |
•---------------------------•-----------------------•----------•----------------•

As you can see, two files are Read-Only. The Xomx.txt file is duplicated as an ANSI file. Then, these two files are themselves duplicated with a single modification in line 7 : I deleted the string when I saw that some people can use

To begin with, I did a Find in Files search on all files, so with the Skip binary files option disabled => I got Search "Fi" (402 hits in 10 file(s)) [10 file(s) searched]

Then, I decided to restrict my tests on standard files and I checked the Skip binary files option => I got, this time Search "Fi" (115 hits in 7 file(s)) [7 file(s) searched, 3 skipped: 3 binary]

BTW, note that the Mark_Style.txt file, although containing one NUL char is not considered as a binary file !

Now, I typed in the Cyrillic string люди in the Replace field and ran a Replace in Files opération. Here is a snapshot of the results :

As you can see the status line shows :

Replace in files: 3 of 3 files(s) modified. 1 of them in open document(s), not saved. 7 file(s) skipped: 3 binary, 2 read-only, 2 not encodable.

Thus, I suppose that this table is correct :

•===========================•=======================•==========•===============-•==================•=================•
|           File            |        Status         | Encoding |  Matches 'Fi'  |  Matches 'люди'  |     Results     |
•===========================•=======================•==========•===============-•==================•=================•
|  Mark_Style.txt           |   Contains NUL char   |  UTF-8   |        2       |          2       |  Modified       |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  License_890.txt          |  Read -ONLY Windows   |  UTF-8   |        1       |          0       |  Read-ONLY      |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Xomx.txt                 |                       |  UTF-8   |       10       |         10       |  Modified       |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Xomx_ANSI.txt            |                       |   ANSI   |       10       |          0       |  NOT encodable  |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  npp.8.9.portable.x64.7z  |  Binary               |   ANSI   |       98       |          0       |      n/a        |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Marginalize.dll          |  Binary               |   ANSI   |       27       |          0       |      n/a        |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  langs.xml                |  Read_ONLY Notepad++  |  UTF-8   |       72       |          0       |  Read-ONLY      |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  notepad++.exe            |  Binary               |   ANSI   |      162       |          0       |      n/a        |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Xomx - Copie.txt         |  NOT saved            |  UTF-8   |       10       |         10       |  Modified       |  ( in open documents, NOT saved )
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Xomx_ANSI - Copie.txt    |  NOT saved            |   ANSI   |       10       |          0       |  NOT encodable  |
•===========================•=======================•==========•===============-•==================•=================•

---

I then decided of an second test, still skipping the binary fiiles. This time, I uncheck the Use open documents instead of files in disk option in the settings

I first ran a Find in Files operation. I was rather surprised to not see the same results as before : Search "Fi" (41 hits in 5 file(s)) [6 file(s) searched, 4 skipped: 4 binary]

The Mark_Style.txt was considered, this time, as a binary file and the 72 hits of the langs.xml file were totally skipped as well !?

Anyway, I ran again a Replace in Files opération. Here is a snapshot of the results :

As you can see the status line shows :

Replace in files: 1 of 2 files(s) modified. 8 file(s) skipped: 4 binary, 1 read-only, 2 open with unsaved changes, 1 not encodable.

Thus, I suppose that this table is correct :

•===========================•=======================•==========•===============-•==================•=================•
|           File            |        Status         | Encoding |  Matches 'Fi'  |  Matches 'люди'  |     Results     |
•===========================•=======================•==========•===============-•==================•=================•
|  Mark_Style.txt           |   Contains NUL char   |  UTF-8   |        2       |          0       |      n/a        |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  License_890.txt          |  Read -ONLY Windows   |  UTF-8   |        1       |          0       |  Read-ONLY      |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Xomx.txt                 |                       |  UTF-8   |       10       |         10       |  Modified       |  <------•
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•         |
|  Xomx_ANSI.txt            |                       |   ANSI   |       10       |          0       |  NOT encodable  |         |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•         |
|  npp.8.9.portable.x64.7z  |  Binary               |   ANSI   |       98       |          0       |      n/a        |         | ( 1 of the 2 files modified )
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•         |
|  Marginalize.dll          |  Binary               |   ANSI   |       27       |          0       |      n/a        |         |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•         |
|  langs.xml                |  Read_ONLY Notepad++  |  UTF-8   |       72       |          0       |      n/a  ??    |  <------•
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  notepad++.exe            |  Binary               |   ANSI   |      162       |          0       |      n/a        |
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Xomx - Copie.txt         |  NOT saved            |  UTF-8   |       10       |          0       |  NOT modified   |  ( Open with unsaved changes )
•---------------------------•-----------------------•----------•----------------•-  ---------------•-----------------•
|  Xomx_ANSI - Copie.txt    |  NOT saved            |   ANSI   |       10       |          0       |  NOT modified   |  ( Open with unsaved changes )
•===========================•=======================•==========•===============-•==================•=================•

Certainly, I must have misunderstood a lot of things ! Just tell me about it !

Best Regards,

guy038