@Freon-Sandoz said in Unexpected match when searching files for an end-quote character (non-ASCII):
I can reproduce the file contents and the unexpected behavior
I was able to do that, too… and now I see what is happening. The character you are calling an end quote is not the Right Double Quotation Mark, U+201D but the Double Prime, U+2033.
Windows-1252 (and Windows-1254) contains the right double quotation mark at 0x94. However, it does not contain the double prime. The entry boxes on the file dialog are always in Unicode. (That’s how it works pretty much everywhere in modern Windows.) But if the file is in ANSI, the file search is done in ANSI, so Notepad++ asks Windows to translate the string you gave it into ANSI. Seeing that there is no double prime character in your current code page, Windows “helpfully” translates it to something that looks a lot like it… the ASCII double quote.
Further confusing the issue is that Notepad++ never loads a file in any code page other than your system code page (which you said is 1252) or Unicode. So when you open the file in Windows-1254, Notepad++ is actually converting it from 1254 to UTF-8 and editing that way. That’s why the search behaved as expected in 1254: it wasn’t really 1254 in, it was in UTF-8.
Bottom line… this behavior actually is “expected”… but not by any normal human being. About the only thing you can do about it is to work in Unicode wherever possible when you are using non-ASCII characters.
It might be possible for Notepad++ to change its search so that it warned you when you tried to search an ANSI document for characters that aren’t possible in that document. I haven’t looked into it in depth; I would guess there must be a call to WideCharToMultiByte somewhere, and it could be passed the WC_NO_BEST_FIT_CHARS flag and the lpUsedDefaultChar output pointer to detect such shenanigans so the program could tell the user about it instead of potentially claiming to find something that isn’t there.