中英文混排字数怎么算？「按字」和「按词」的区别

上周给一个公众号投稿，编辑要求 800 字以上。我在 Word 里看着左下角显示「字数 812」，放心交稿。编辑回了一句「你这才 680，不够」。我把同一段文字粘到三个地方：Word 812、博客平台 690、字数统计工具 730。三个数都对不上。

折腾了半小时才搞明白：不是哪个工具有 bug，是它们压根不在算同一件事。中英文混排的字数统计，口径有好几套，对不上才是常态。

中文按字，英文按词

第一层分歧在这里。

中文每个汉字都是独立计数。一段「今天天气不错」，就是 6 个字。实现上一般用正则去匹配 CJK 统一表意文字范围（Unicode 一 到 鿿），每命中一个就加一。汉字的粒度天然是「字」。

英文的粒度不是字符，是单词。「hello world」是 2，不是 10。统计时按空格和标点把文本切成一段段，数有多少段。所以 can't 算 1 个词，front-end 算 1 个词（连字符没断开），U.S.A. 也算 1 个。

两种语言的粒度不一样，于是混排文章只能各自算各自的，最后再合计。

混排怎么加起来

一篇典型的技术文章，正文可能是这样：

本文介绍 fetch API 的基本用法，包括 GET、POST 请求和错误处理。

数一下：汉字有「本文介绍的基本用法包括请求和错误处理」一共 18 个。英文词有 fetch、API、GET、POST，一共 4 个。合计 22。

这是绝大多数字数统计工具采用的口径：「汉字数 + 英文词数」。它符合我们对中文「字数」的直觉，也符合英文「word count」的直觉。

但注意这里已经埋了两个小坑：

• 标点没算。中文逗号、英文句号、括号引号都游离在统计之外。
• 数字怎么算有歧义。2026 是 1 个英文词还是 4 个字符？大多数工具按「词」处理，算 1。

所以同样是「汉字 + 英文词」的口径，不同实现对标点和数字的处理细节还会略有差异，最后差几个字很正常。

字符数和字数是两码事

第二层分歧在这里。

「字符数」不区分语言，按 Unicode 码点一个个数。一个汉字算 1，一个英文字母算 1，一个空格也算 1，一个 emoji 看编码可能算 1 也可能算 2。上面那段话按字符数算是 41（含空格）或 36（不含空格）。

字符数通常用在两种场景：

• 数据库字段长度限制（VARCHAR(255) 指 255 个字符）。
• Twitter、微博这种按字符计数的平台。

写作场景里说的「字数」，默认是指前面那种「汉字 + 英文词」的合计，不是字符数。把这两个搞混，你会发现字符数永远比字数大，因为空格和标点都被算进去了。

阅读时间是个估算

很多字数工具会附带一个「预计阅读时间」。它的算法很直白：中文按每分钟 400 字、英文按每分钟 200 词估算，用前面的字数除一下。

这两个数字是成人平均阅读速度的常见参考值，但偏差可以非常大：

• 网文、口语化内容读得快，可能到 600 字/分钟。
• 技术文、文言文、法律条文读得慢，可能只有 200 字/分钟。
• 同一篇技术文，内行扫一眼，外行啃半天。

所以「预计阅读 3 分钟」这种话，当成一个数量级的参考就行，别拿去跟实际对账。Medium、公众号 显示的阅读时间也是同一套估算逻辑，口径一样会有出入。

工具之间的数字为什么对不上

回到开头那个 812 vs 690 vs 730 的谜题。原因无非这几条：

• Word 把标点计入字数，连中文标点也算。所以 Word 的数字通常偏大。
• Markdown 编辑器会算上语法符号，**、#、` 这些都进了字符流。
• 博客平台有自己的口径，有的统计正文 HTML 渲染后的文字，有的连代码块都算，有的不算。
• 字数统计工具的口径最窄，只算汉字加英文词，标点语法都不算。

所以同一篇文章在四个地方看到四个数，不一定是 bug，是各自定义不同。投稿、排版对字数有硬要求时，先问清楚对方用哪个工具为准，再按那个口径核对，省得来回扯皮。

实操

要快速核对一篇中英文混排文章的真实字数，最省事的办法是直接粘到 UPTools 字数统计工具 里。它会同时给出汉字数、英文词数、字符数（含和不含空格两种）、段落数、阅读时间，几套口径并排显示，一眼就能看出差异。所有计算在浏览器本地完成，文本不会上传。

三句话总结

中文按汉字逐字计数，英文按空格分隔的单词计数，混排文章的总字数通常是两者相加。字符数是另一套口径，按 Unicode 码点算，不区分语言，含空格和不含空格又分两种。Word 把标点算进去、Markdown 把语法符号算进去，所以不同工具数字对不上属正常，对字数有硬要求时先对齐口径再核对。