ctrl+shift+c 是 notepad++ 中唯一按 unicode 码点统计字符数的准确入口，其 characters 值与编码无关，包含所有可见及不可见字符；其他标“chars”处均为字节数，易导致长度误判。
Ctrl+Shift+C 是唯一可信的字符数统计入口
Notepad++ 里所有标“chars”的地方——状态栏 length: xxx、视图→摘要里的 chars: xxx、双击状态栏弹出的面板——全都是字节数，不是你理解的“字数”。同一段含 10 个汉字 + 5 个英文的文本，在 UTF-8 编码下显示 chars: 35，在 GBK 下变成 chars: 30，但真实 Unicode 字符数始终是 15。
Ctrl+Shift+C 弹出窗口中的 Characters 值才是你要的“字数”，它按 Unicode 码点计数，与编码无关：
- 一个汉字、一个 Emoji、一个空格、一个制表符
\t、一个换行符\n或\r\n，全部算 1 个 - 必须在文档已打开、光标落在文本区时才有效（空白标签页或只读状态会失效）
- 选中某一段再按
Ctrl+Shift+C，只统计所选区域——这是查某段落字数的唯一精准手段 -
Lines包含最后一行（哪怕末尾没换行符也计为 1 行），Words按空白切分，对中文基本无效（整段中文算 1 个 word）
为什么不能靠“视图→摘要”或状态栏 length 查字数
这些位置显示的数值本质是当前编码下的字节数，不是字符长度。常见误判场景：
- 复制粘贴后直接看右下角
length: 128，以为就是 128 字，结果提交平台因超限被拒（对方按 Unicode 字符计，而你看到的是 UTF-8 字节数） - 文件编码从 UTF-8 切到 GBK，
chars值突变，误以为内容被修改 - 含 Emoji 或零宽空格（
\u200b）时，length值跳变，但实际可见字符没增加
它们不说明单位，也不提示“这是 bytes”，信了就容易在合同、投稿、API 接口对接等对长度敏感的场景翻车。
正则统计中文字符：用 [\u4e00-\u9fff] 而不是搜“的”
想单独统计中文字符数量，不能靠 Ctrl+F 输“的”然后点“计数”——那只是“的”字出现次数，不是中文字符总数。
正确做法是启用正则表达式匹配 Unicode 中文范围：
- 打开
Ctrl+F，切换到“查找”标签页 - 勾选“匹配正则表达式”
- 输入
[\u4e00-\u9fff]（覆盖绝大多数简体汉字） - 点击“在当前文档中查找”（大文件优先用这个，比“全部计数”响应快）
- 结果出现在下方“查找结果”面板顶部：“共找到 X 个匹配项”
注意：\u3000 是全角空格，不是中文字符，别加进正则；如果文件是 GBK 编码但 Notepad++ 以 UTF-8 解析，正则可能不匹配——务必确认右下角显示的编码正确。
查找→计数不是字数工具，是关键词频次工具
Ctrl+F → 输入关键词 → 点“计数”，返回的是该字符串在文档中**出现的位置数**，和总长度完全无关：
- 搜
的得到 42，意思是“的”出现了 42 次，不是全文 42 字 - 正则用
^.*$再计数，结果是行数，不是字符数 - 匹配
user_id时，若末尾带零宽空格\u200b，会被漏掉——建议先开“视图 → 显示符号 → 显示所有字符”排查
真正适用场景很窄：查日志里 ERROR 出现频次、核对模板中 {{id}} 是否漏写、统计中文全角标点 [,。!?;:] 总数。别把它当 Ctrl+Shift+C 的替代方案——目标不同，逻辑不搭界。
最常被忽略的一点：Ctrl+Shift+C 的 Characters 包含不可见字符（BOM、\r\n、零宽空格）。如果你对接的系统只计可见字符，得手动剔除这些；Notepad++ 不做区分，它只忠实反映 Unicode 码点总数。
