notepad++字符面板仅显示控制码的unicode码点而不标注语义，且“显示所有字符”功能仅支持\t、\r、\n等极少数控制符的可视化，soh（u+0001）、etx（u+0003）等空闲控制码既无名称提示也无图形符号，需通过十六进制查找或扩展模式正则（如\x01）主动探测。
Notepad++ 无法在字符面板中识别大多数空闲控制码
Notepad++ 的「字符面板」（View → Character Panel）只显示当前光标所在位置的 Unicode 码点（如 U+0020）、UTF-8 字节序列（如 20）和 ASCII 名称（如 SPACE），但它不解析也不标注控制字符语义。像 SOH（U+0001）、ETX（U+0003）、ACK（U+0006）这类“空闲控制码”（idle control codes，即未被标准文本协议定义用途的 C0 控制字符），它只会显示为 U+0001、U+0003 等原始码位，不会给出名称或分类提示。
哪些控制字符能被 Notepad++ 可视化？仅限极少数 ASCII 控制符
Notepad++ 的「显示所有字符」功能（Ctrl+Shift+P）只硬编码支持有限几个 C0 控制符的图形符号：
-
\t→ 渲染为→ -
\r和\n→ 在行尾组合渲染为¶（Windows）或单独¶（Unix） -
\b、\f、\v等——完全不显示任何符号，视觉上就是“空白” -
SOH（U+0001）、STX（U+0002）、ETX（U+0003）等——既不画图标，也不报错，更不会高亮
也就是说：你用字符面板看到 U+0003，但不知道它是 ETX；你打开「显示所有字符」，也看不到任何标记——它就安静地躺在那儿，等着在 JSON 解析或串口通信时突然炸开。
怎么实际定位和清理这些“隐身”的控制码
靠肉眼或字符面板不行，必须用主动探测手段：
- 用十六进制模式查找：
查找 → 查找 → 模式：十六进制，输入01查SOH、03查ETX - 用正则配合扩展模式：
查找 → 替换 → 勾选「扩展(\n, \r, \t, \0, \x…)」，然后输入\x01或\x03定位 - 零宽字符（如
U+200B）需复制粘贴原文到查找框，或用十六进制查200b - 全角空格（
U+3000）不能用\s匹配，得显式写\x{3000}或直接粘贴该字符
注意：\x{...} 语法只在「扩展」模式下有效，「正则表达式」模式不支持 Unicode 转义。
为什么别依赖「显示所有字符」来排查控制码问题
这个功能名字有误导性——它其实只显示三类符号：·（空格）、→（Tab）、¶（行尾），其余所有控制字符都沉默通过。你在 Git 提交前看到满屏 · 和 →，就以为缩进干净了，结果 U+0001 躲在注释末尾，导致 CI 构建失败。真正危险的从来不是看得见的，而是那些连 ¶ 都懒得给你画一个的字符。
