跳到正文
DevTools / 文本统计与命名转换

文本统计与命名转换

字数统计的用途远不止作文:超出长度限制的 meta 描述会在搜索结果中被截断,过长的提交信息会被某些 linter 拒绝,而设有字节上限的字符串字段关心的是 UTF-8 长度而不是字符数。本工具把这些数字一并给出,同时统计句子与段落数、估算阅读与朗读时间、生成过滤停用词后的词频图表,并提供代码中真正会用到的各种命名规范转换。

完全在浏览器本地运行——不会上传任何内容。

字符数
263
不含空格
220
词数
63
独立词数
36
句子数
4
段落数
2
行数
5
非空行
4
字母
210
数字
0
标点
10
空白
43
中日韩字符
20
UTF-8 字节
309
阅读时间
17s
@ 220 字/分钟
朗读时间
29s
@ 130 字/分钟
词频 — 30 独立词
  • nothing3
  • is2
  • anywhere.1
  • browser.1
  • customer1
  • data1
  • developer1
  • drop1
  • entirely1
  • every1

默认过滤常见停用词,否则图表会被 the、of、and 之类的词占满。

命名转换

按空格、连字符、下划线、点号、斜杠以及大小写边界拆分后重新组合。

工作原理

字符数与字节数是两个不同的数字,混为一谈会带来真实缺陷。JavaScript 字符串以 UTF-16 码元计量,设有长度限制的数据库列可能按字符计数,而 HTTP 请求头或定长字段按字节计数。一个汉字是一个字符,但在 UTF-8 中占三个字节;一个 emoji 常常是两个码元、四个字节。本工具分别给出字符数、UTF-8 字节数和码点数,使“能通过前端校验却撑爆数据库列”的值在写入之前就被发现。

分词是语言相关的,并不存在唯一正确的定义。对以空格分隔的语言,按空白切分已经足够接近,再对紧贴单词的标点做修正即可。对中文和日文这类不以空格分词的语言,按空白切分会让整整一段的结果为 1,因此 CJK 字符会被逐字计数并单独报告。每分钟 220 词的阅读速度与 130 词的朗读速度是通行取值,两者都是近似值,不同读者之间可能相差近一倍。

词频图表先分词、转小写、去标点、剔除停用词,然后计数。没有停用词过滤,图表毫无意义:the、of、and 会统治任何英文文本。过滤之后,真正承载含义的词才会浮现。写作者用它发现无意的重复,开发者用它抽查分词器的行为。此外还会给出独立词数以及独立词与总词数之比(类型—形符比),作为词汇丰富度的粗略度量。

命名转换是开发者最常用的部分。它支持 camelCase、PascalCase、snake_case、SCREAMING_SNAKE_CASE、kebab-case、dot.case、标题式大写、句首大写以及全小写,并且会按真实标识符中确实出现的边界拆分:空格、连字符、下划线、点号、斜杠,以及大小写字母之间的转换。最后一条规则正是让已有的 camelCase 标识符能正确转成 snake_case,而不是整体被当成一个词的原因。

常见应用场景

  • 检查 meta 描述或标题是否超出搜索引擎展示的字符上限。
  • 在写入定长数据库列之前,测量字符串的 UTF-8 字节长度。
  • 为文档估算阅读时间,或为讲稿估算朗读时间。
  • 在发布文章前找出被过度使用的词。
  • 在语言或规范之间切换时,把字段名在 camelCase、snake_case 与 kebab-case 之间转换。
  • 确认某个 JSON 字段名能否在会改变大小写的转换中幸存。

最后更新: 2026-10-14

常见问题解答

为什么字符数与字节数不一样?

因为 UTF-8 中每个字符占 1 到 4 个字节。ASCII 字母、数字和标点各占一字节,大多数带重音的拉丁字符占两字节,中日韩文字占三字节,emoji 占四字节。任何设有字节上限的系统——短信分段、HTTP 请求头、以字节长度定义的 VARCHAR 列——都会拒绝字符数看起来完全没超的文本。当值明明很短却被判超长时,字节数才是关键数字。

中文和日文文本是如何计数的?

按字符逐个计数,因为没有空格可以切分。基于空白的词数统计对整段中文会返回 1,这虽然自洽却毫无用处,因此 CJK 字符会按单个单位计数并单独报告。阅读时间估算对 CJK 文本采用更慢的速率,因为通行的“每分钟词数”是按空格分词语言校准的,用在中文上会严重失真。

什么算作一个句子?

以句号、问号、感叹号或其全角等价符号结尾的一段文本,同时排除缩写和小数,使 e.g.、Dr. 和 3.14 不会各自结束一个句子。这个启发式在普通散文上表现良好,在代码、数字表格和没有终止标点的文本上并不可靠。请把结果当作估算值,不过对散文来说它确实有用,尽管它并不是解析器。

变量名该用哪种命名规范?

用你所用语言社区所期望的那一种,因为一致性比具体选择更重要。JavaScript、Java 和 Swift 的变量与函数用 camelCase;类型与导出的组件用 PascalCase;Python、Ruby 和 Rust 的变量用 snake_case;多数语言的常量用 SCREAMING_SNAKE_CASE;CSS 类名、HTML 属性和 URL 用 kebab-case,因为在大小写不敏感的场景下它是唯一安全的选择。转换器不会替你决定,但能让切换时的机械工作变得轻松。

相关工具