notepad++扩展模式仅支持\n、\r、\t、\0及\xhh（两位十六进制）等ascii控制符查找，不支持\u200b等unicode码点；查低字节符需启用扩展模式直接输\x01等形式，且不可勾选正则或匹配新行。
扩展模式能搜哪些控制符
Notepad++ 的「扩展模式」（Extended）只识别有限的转义序列：\n（换行）、\r（回车）、\t（Tab）、\0（空字符）、\x（十六进制字节）。它不支持 Unicode 码点写法（如 \u200B），也不解析 \R 或 PCRE 风格的 \x{200B}。这意味着你只能用它查 ASCII 范围内的常见控制符，比如 \x01、\x00、\t，但查不到零宽空格或 BOM。
怎么正确输入\xxx查找低字节控制符
在「查找」对话框中启用「扩展」模式后，直接在「查找目标」里输入 \x01 就能定位 SOH 字符；\x00 查空字节；\x09 和 \t 效果等价。注意以下三点：
-
\x后必须紧跟两位十六进制数字（00–FF），不能多也不能少 - 文件编码不影响扩展模式匹配——哪怕当前是 ANSI 或 GBK，
\x01仍能命中二进制值为 0x01 的字节 - 不要勾选「正则表达式」或「匹配新行」，否则
\x01会被当作文本字面量处理，搜不到
为什么\u200B、\uFEFF在扩展模式下搜不到
因为 \u200B 是 Unicode 码点写法，Notepad++ 的扩展模式根本不解析它——它只会把这四个字符当成普通字母 u、2、0、0、B 来匹配。真正有效的做法是：先确认文档编码为 UTF-8（右下角显示「UTF-8」），然后切换到「正则表达式」模式，输入 \x{200B} 并勾选「匹配全部字符」。但这个操作和扩展模式无关，属于正则引擎能力范畴。
扩展模式 vs 正则模式的实际选择建议
日常排查日志或数据文件里的分隔符（如 UNL 格式常用 \x01、\x10），用扩展模式最稳、最快；但遇到 JSON 解析失败怀疑有零宽空格、或 Git 提交异常怀疑有 BOM，就得切正则模式 + \x{200B} / \x{FEFF}，且必须确保编码是 UTF-8。两者能力边界清晰，混用反而容易漏掉关键字符。
