文本统计

关于 文本统计

文本统计工具实时统计输入文本的字符数、字节数（UTF-8 与 GBK 编码下结果不同，中文在 UTF-8 占 3 字节、GBK 占 2 字节）、单词数、行数与中文字符数，并区分可见字符与空白字符。这些数字背后是真实的使用门槛：接口字段的长度限制、数据库 varchar/char 的容量规划、截断逻辑的边界条件，往往按"字节"而非"字符"判定——一个中文字符在 UTF-8 下就是 3 字节，与英文字符的 1 字节差别巨大，只看字符数容易判断失误。它也适合编辑精确估算稿件字数、社媒字数上限与排版空间。工具在浏览器本地逐字符计算，不缓存也不上传任何文本，可放心粘贴含敏感信息的草稿、密钥片段或内部日志。统计结果随输入即时刷新，无需安装任何插件；对混排中英文的文本，它还帮你看清字符数、单词数与字节数的差异。作为写作与开发流程中的轻量校验环节，它能避免"以为够长其实被截断"的线上事故，是发布前的最后一道自检，帮助团队在数据上线前消除隐性的长度隐患。例如对一段 300 字的文章，一次性给出字符数、单词数、行数、句数与平均词长，无需再数。

最常见的误用是拿不同口径的数字互相比较：按字符数统计时是否计入空格与标点相差很大，按词数统计时以空格分词的规则根本不适用于中文。另一个误用是只看总量而不看分布，例如行数很多但大量为空行、字符数很多但重复度高，这些差异决定了文本是否需要先清洗再统计。

统计口径之外，还有一类容易忽略的差异：按「字符」统计时，字符指的是码位、字素簇还是代码单元，三种口径在含表情符号或组合字符的文本上结果不同。一段含家庭表情的文字按码位可能是七八个，按字素簇只有一个。因此在跨工具比对字数之前，先确认双方说的是哪一种「字符」。

行数统计同样有口径问题。文件末尾有没有换行会让行数差一；空文件是零行还是一行取决于实现；含回车换行的混合文件在部分工具里会被算成两行。这些差异在几十行的文件上无关紧要，在上百万行的数据上会直接影响分片、校验与对账，因此批处理前先在小文件上确认行数口径，是值得固定下来的习惯。

与「去重后统计」的分工也值得说清：原始字数与去重字数反映的是不同问题——前者衡量体量，后者衡量信息量。一段高度重复的文本字数很多但去重后很少，说明它更接近模板拼装而非独立内容。把两个数字放在一起看，比只看其中一个更能判断文本性质，这也是内容质量检查里常用的一对指标。

在写作与编辑场景里，统计结果应结合目标读者判断。给屏幕阅读的段落以句长与段落长度为关键指标，句长过长会让理解成本上升；给检索优化的内容则要看关键词密度是否自然，密度过高反而降低可读性。同一份文本在不同目标下的「好」标准不同，因此统计只是输入，判断仍要由人来做。

最后，统计前先做一次基础清洗几乎是必需的：统一换行符、去掉首尾空白、把不可见的控制字符处理掉。不清洗直接统计，全角与半角混排、零宽字符与不换行空格都会让结果与预期有出入，而这些字符在编辑器里通常看不见，排查起来很费时间。把清洗作为统计的第一步，能让后续所有数字都可信。