字符串长度统计工具

使用方法

1. 「待统计文本」里已经放着四行示例：Hello World、第二行 second line、一个空行、第四行 with spaces。示例由页面直接给出，不必先粘贴内容。
2. 把光标放进文本框，按 Ctrl + Enter（苹果键盘是 Cmd + Enter）触发统计；输入过程中统计值同步刷新。
3. 「目标长度上限」下拉提供七种取值：不比较、微博（早期）140、X / Twitter 280、短信 GSM 单条 160、短信中文单条 70、Meta description 建议 155、SEO Title 建议 60。
4. 选了上限之后，结果区会多出一行「还差 N 字符」或「已超 N 字符」。比较的基准是 Unicode 字符数而不是字节数，因为各平台的字数提示通常按字符给出。
5. 「复制结果」把七项口径打包成一段文字放进剪贴板，「复制对照表」复制逐行明细的制表符表格，「导出 CSV」带 UTF-8 字节序标记，表格软件里不会乱码。
6. 逐行明细超过六行会自动出现「加载更多」；「重置」把文本框恢复成默认四行示例，上限恢复成不比较。

这个工具能解决什么问题

本页要解决的是「这段文本到底有多长」这个看着一句话就能答完、实际有两个答案的问题。同一段示例文本，按 Unicode 字符数是 44，按 UTF-8 字节数是 56；页面上的计数框多半按前者，数据库字段与接口限额多半按后者，两边不一致时，超长常常要到提交那一刻才被发现。

第二个作用是给有硬门槛的内容做预检。社交平台正文、短信单条长度、搜索结果标题与摘要的建议字数各不相同。与其把文本粘过去被截断后回头删字，不如先在这里选一个目标上限，直接看到离门槛还差几个字。

第三个作用是代理对的判定。表情符号与一部分扩展区汉字在 JavaScript 字符串里占两个 UTF-16 码元，用取长度的方式读出来会比肉眼多一个字；本页一律按 Array.from 拆字，这类字符记一个，与屏幕上看到的一致。

它和站内其它文字类工具的分工也不同：字数统计工具侧重成篇文稿的规模，词频统计工具关心词表分布，而本页面向开发场景，把字符、字节、行数、单词数并排给出。

这个工具在本站也叫 `字符串长度统计`。

字符、字节与行数的统计口径

七项口径全部写在页面上，逐条说明如下：

• Unicode 字符数 = Array.from(text).length：按码点拆分字符串，代理对算一个字。
• UTF-8 字节数 = new TextEncoder().encode(text).length：交给浏览器的编码器去算，而不是把非 ASCII 一律乘 3。乘 3 对中文成立，对占 4 字节的表情符号与带重音的拉丁字母就不成立。
• 去空白字符数：剔除空格、制表符与换行之后剩下的字符数，示例文本是 36。
• 行数 = text.split("\n").length：按换行符切分，最后一行不带换行也算一行。示例里的第三行是空行，它仍然占一行，所以总数是 4。
• 单词数：去掉首尾空白后按空白切分，空串记 0。中文之间本来没有空格，所以「第二行 second line」记 3 个单词。
• 中文字符数 = (text.match(/[\u4e00-\u9fff]/g) || []).length：只覆盖常用区，扩展区的生僻字不计入这一项，但仍然计入字符数与字节数。
• 最长行字符数：逐行取 Unicode 字符数的最大值，用来定位会把排版顶歪的那一行。

为什么同一段文本会给出两个数。示例文本 44 个字符对应 56 个字节，差的 12 字节恰好来自 6 个汉字：每个汉字在 UTF-8 里占 3 字节，若它属于 ASCII 则只占 1 字节，一个字多出 2 字节，6 个字多出 12 字节。反过来，纯 ASCII 的 Hello World 是 11 个字符也是 11 个字节，两个数相等。数据库字段常写的 VARCHAR(255) 限制的是字节，用 UTF-8 存中文只能放 85 个字，按字符数去填就会截断或报错。

为什么不用取长度的方式数字符。JavaScript 的字符串以 UTF-16 码元为单位，代理对由两个码元组成，直接取长度会得到 2，而屏幕上只有一个字。Array.from 以码点为步长，得出的字数才与肉眼一致。这也解释了为什么同一个符号，有的编辑器里显示一个字、有的显示两个字。

为什么字节数交给浏览器编码器。自己按「中文 3 字节、英文 1 字节」估算只能覆盖基本平面里的常见字符；UTF-8 是变长编码，2 到 4 字节的区间各有大量字符分布，估算办法必然出错。编码器的实现按规范逐码点推进，不存在估算误差。

为什么行数要单独定义。按换行符切分时，末尾多敲一个回车就多出一个空行，这与编辑器里的光标行号一致，与「非空行数」不是一回事。本页不预处理回车换行，文本里的每个字符都会如实计入。

完整示例（数值仅作演示）

示例条件：文本框保持默认四行内容，目标上限选「不比较」。下列数值全部由本页自己的算法算出，与页面默认输出逐项一致：

• Unicode 字符数 44，其中包含 3 个换行符与 5 个空格
• UTF-8 字节数 56，去空白字符数 36
• 行数 4，单词数 8，中文字符数 6，最长行 15 字符

逐行拆开看：第一行 Hello World 是 11 字符 / 11 字节；第二行「第二行 second line」是 15 字符 / 21 字节；第三行空行是 0 字符 / 0 字节；第四行「第四行 with spaces」是 15 字符 / 21 字节。四行相加为 41 字符 / 53 字节，再加 3 个换行符，正好是全篇的 44 字符 / 56 字节；15 字符的最长行由第二行与第四行并列保持。

把目标上限换成 SEO Title 建议的 60 字符，结果区会给出「还差 16 字符」；换成微博早期的 140 字符则是「还差 96 字符」。判断依据始终是字符数 44 而不是字节数 56，超过后会改成「已超 N 字符」。

单位换算的直观对照：3 个中文字符占 9 字节，11 个英文字符占 11 字节，单个表情符号占 4 字节而字符数只记 1。上述数值均为演示。

常见平台的长度上限对照表

下表列出十二个常见场景的字符上限。它们的口径并不统一：社交平台会把链接折算成固定长度计入，短信按字符集切换单条容量，搜索引擎给的是「展示得下」的建议值而非硬限制。

短信那两行最容易被误读：160 与 70 不是两套换算结果，而是两种编码方案——纯 GSM 字符按 7 位打包成 160，一旦混进中文就整条切到 UCS-2，容量掉到 70。只要这一条里出现一个非 GSM 字符，整条短信就按 70 个字符的容量来算。

下表按 UTF-8 编码给出三种典型字符的单位代价，用来快速判断「我把这段文本塞进某个字段会不会爆」：

结果边界、舍入与适用说明

• 文本框为空时会给出「请先粘贴或输入要统计的文本」，不会拿上一次的结果冒充本次输出，也不会静默返回全 0。
• 目标上限只允许下拉里的取值。收到列表之外的数值会给出「请从下拉里选择一个长度上限」。
• 差额判断一律基于字符数，原因是平台给出的门槛通常按字符发布；若你要按字节入库，请直接看字节数那一格。
• 本页不做 Unicode 规范化。像带重音的拉丁字母这类字符，写成「字母 + 组合符」的形式会被算成 2 个字符，写成单个预组合字符则只算 1 个，两者在屏幕上看起来完全一样。
• 中文字符数只统计常用区，扩展 B 区以后的生僻汉字不计入这一项；它们仍计入字符数与字节数，所以两项不必相等。
• 单词数按空白切分，对纯中文文本没有区分度：整段中文会被记成一个词。
• 字节数只按 UTF-8 计算，与 GBK、Latin-1 等编码落盘后的结果不同。
• 页面不联网、不写本地存储，刷新后回到默认示例与默认上限。

常见问题

相关工具

• 字数统计工具：面向成篇文稿的规模统计。
• 字符数统计工具：按字符口径统计总量。
• 词频统计工具：统计词汇出现次数与分布。
• 行统计：按行聚合行数与各行的构成。
• 元音辅音计数：分别统计元音与辅音的数量。