做在线工具站这几年我手里留存率最高的一个工具反而是当初最没当回事儿的那个——文本字符数统计。代码核心就几十行但后台数据显示每天有上千人使用。这个工具解决的需求其实很基础写公众号、小红书、论文、简历平台都有字数上限做外贸写开发信要关注字节数程序员写代码注释或 commit message也有长度约束。可为了看一眼字数打开 Word太兴师动众。在线工具的价值就是即开即用而用纯前端 JS 实现文本全程在浏览器本地处理不会上传服务器隐私上反而更安心。这篇文章就围绕这个在线工具的核心 JS 实现展开聊聊统计背后的字符编码原理、实时交互的细节、以及上线后踩过的几个真实坑。无论你是想自己写一个类似的小工具还是单纯想弄懂字符串统计的各种边界情况这篇文章都值得一看。1. 需求拆解在线工具该统计哪几种“字符”1.1 用户口中的“字符数”至少有三层含义最初我只参考了笔记本软件的做法直接用value.length输出一个数字上线两天就开始收到用户反馈“表情符号怎么只算了一半”“中文统计和 Word 里对不上”“字节数是什么我要算 UTF-8 还是 GBK”这些反馈逼我把需求重新拆了一遍。用户说的“字符数”其实分三种用户感知的字符数显示给人看的长度、字节数存储和传输时关心的长度、单词数写英文时关心的长度。同一个文本三种统计结果完全不一样。我整理了一个典型对照表统计维度示例文本结果用户场景字符数hello 你好 9新媒体平台字数限制字节数UTF-8hello 你好 17短信、接口、邮箱限制单词数hello world foo3英文写作、论文摘要所以在线工具必须把三类结果都展示清楚而不是拿一个length糊弄过去。这也是为什么后来我把界面分成三个卡片分别显示字符数、字节数、单词数保留原始输入区域用户一眼就能看到自己关心的数字。1.2 技术选型为什么纯前端 JS 足够有人会问字符统计用 Python / Node 后端不是更顺手吗我的回答是杀鸡用不上牛刀。文本字符统计完全依赖浏览器能力纯 JS 就能完成上后端反而是增加成本。纯前端方案有几个实际好处零部署成本。一个静态 HTML 文件挂到对象存储上就能跑不需要维护服务器。数据不出本机。文本不会经过第三方服务器用户粘粘贴贴的隐私内容更安全也不需要写冗长的隐私说明。无并发压力。统计计算全在浏览器本地执行流量再大也不会拖垮服务器。页面秒开。没有任何网络请求打开即用符合工具类产品的核心体验。落地的技术栈也非常简单一个textarea、一个核心统计函数、一次事件绑定没有任何第三方依赖。这个“零依赖”原则在后面迭代中帮了大忙无论怎么改功能核心实现不会因为依赖库升级而崩。2. 核心统计函数从 length 到 Intl.Segmenter 的演进2.1 String.length 的坑UTF-16 码元不等于字符数很多初学者写字符统计第一个想到的必然是str.length。在 JavaScript 里字符串以 UTF-16 编码存储length返回的是 UTF-16 码元code unit的数量而不是直观意义上的“字符”数量。打个比方UTF-16 像是一个停车场普通字符是一辆普通车占一个车位而表情符号、生僻字这类超出基础平面的字符是一辆加长车要占两个车位。length统计的是车位数不是车的数量。用代码验证一下console.log(abc.length); // 3 console.log(你好.length); // 2 console.log(.length); // 2 console.log(.length); // 2这是个生僻汉字和在码位上超出了基本多文种平面BMP需要两个码元表示所以length返回 2。如果直接把这个结果展示给用户表情符号永远“占两个字”和用户感知严重不符这也是我收到第一条反馈的根源。2.2 用码点和字素簇纠正计数要解决上面问题第一步是按码点code point拆分字符串。Array.from()和扩展运算符...都可以做到const charCount1 Array.from().length; // 1 const charCount2 [...].length; // 1这一步已经比length准很多。但还没完——当遇到表情符号组合序列时比如家庭表情它实际是一个男人、一个女人、一个女孩、一个男孩通过零宽连接符ZWJ拼在一起视觉上是一个字符用户感知是一个“字符”但Array.from()会把它拆成 4 个表情加 3 个零宽连接符。更准确的做法是用Intl.Segmenter按字素簇分割。字素簇是用户感知的“单个字符”的国际化标准定义专门处理这类问题const segmenter new Intl.Segmenter(zh, { granularity: grapheme }); const graphemeCount [...segmenter.segment()].length; // 1在实际项目中我的核心字符统计函数最终长这样function countCharacters(text) { if (!text) return 0; return [...new Intl.Segmenter(zh, { granularity: grapheme }).segment(text)].length; }注意Intl.Segmenter的兼容性目前主流浏览器都支持括 Safari 14.1 以上。如果有兼容旧浏览器的需求可以降级回Array.from()并配合一个简单的 emoji 组合合并规则。好在工具类产品用户普遍用现代浏览器我直接用了高版本方案。2.3 字节数统计TextEncoder 与 UTF-8 的细节字节数统计依赖编码格式。在线工具默认按 UTF-8 计算这也是互联网使用最广泛的编码。中文字符在 UTF-8 下通常占 3 字节英文字符占 1 字节emoji 通常占 4 字节。直接用TextEncoder就能算出准确的 UTF-8 字节数function countBytes(text) { return new TextEncoder().encode(text).length; }new TextEncoder().encode(text)返回一个Uint8Array其length就是 UTF-8 编码后的字节数。这个方法原生支持性能也很好实测百万字符文本毫秒级完成不需要引第三方库。有一个细节如果要展示 UTF-16 字节数不能简单把字符数乘以 2因为码点超过 BMP 的字符同样要算 4 字节。不过绝大多数在线工具场景下用户关心的是 UTF-8 字节数在做工具时我用一个下拉框让用户切 UTF-8 / UTF-16内部实现分别是TextEncoder和手动按码元统计。2.4 单词数的正则打法单词数统计比前面要“脏”一些。很多人第一时间用text.split(/\s/)但这个方案在遇到hello,world这种标点紧贴单词时会错误地当成一个单词。改进思路是直接匹配单词字符序列function countWords(text) { const matches text.match(/[A-Za-z0-9\u00C0-\u024F\u1E00-\u1EFF\u2C60-\u2C7F\uA720-\uA7FF]/g); return matches ? matches.length : 0; }这段正则覆盖了常用拉丁字母、数字、带音符的欧洲语言字符比如 é、ü但对中文识字是天然不适用的。中文没有空格分词所以我在统计单词数时做了一个妥协如果文本包含中日韩统一的表意字符就把“单词数”显示为“中文字符数”并加一个说明因为中文用户写文章时更多是关注汉字字数而不是词数。工具行业有个通用做法就是把“字符数含空格”和“字符数不含空格”分开显示单词数只对英文内容有参考意义这个思路可以参考采用。3. 实时统计与交互体验的打磨3.1 事件监听为什么用 input 而不是 keyup核心功能是实时统计第一步要选对监听事件。很多人习惯用keyup但它有几个死角鼠标右键粘贴不触发、拖放文本不触发、浏览器自动填充不触发、IME 输入法确认前的中间状态也会乱触发。input事件才是正解它在几乎所有用户输入场景下都会触发包括键盘输入、粘贴、拖放、自动填充、手写识别等。所以核心绑定非常简单textarea.addEventListener(input, scheduleUpdate);配合清空按钮时点击清空后也要调用一次更新函数否则统计区域会残留旧数据。3.2 中文输入法组合状态的关键处理中文输入法带来的坑比较隐蔽。用拼音输入“你好”时用户先敲出nihao此时输入框会显示拼音组合串每个字母都触发一次input事件。如果实时统计跟着这个串走用户会看到字数疯狂跳动还统计出一些半成品拼音体验很割裂。标准做法是监听compositionstart和compositionend在组合期间不更新统计组合结束后再更新一次let composing false; textarea.addEventListener(compositionstart, () { composing true; }); textarea.addEventListener(compositionend, () { composing false; scheduleUpdate(); }); textarea.addEventListener(input, () { if (!composing) { scheduleUpdate(); } });这段逻辑上线后中文用户的抱怨声立刻消失了。这里补充一个细节在 Safari 中compositionend之后再触发一次input是正常行为我们在input里判断composing就可以保证只更新一次不会造成重复计算。3.3 大文本性能优化requestAnimationFrame 与防抖统计函数本身非常快但每次input触发都去更新三个结果卡片在连续输入时仍可能造成布局抖动。尤其粘贴大段文本时Safari 的渲染性能会显得吃力。我采用了requestAnimationFrame做帧级合并同一帧内多次输入只计算一次保证视觉上流畅。核心实现如下let rafId null; function scheduleUpdate() { if (rafId) return; rafId requestAnimationFrame(() { rafId null; updateStatistics(); }); }这个方案的思路是requestAnimationFrame在浏览器准备重绘前执行回调如果这一帧内已经安排过更新就不再重复安排。它的收益是省去冗余统计和 DOM 写入实测在 100 万字符的文本里输入、粘贴页面依然不卡。如果文本进一步增大到千万级可以考虑String.prototype.trim都不可能匹配的性能瓶颈再用 Web Worker 方式把统计扔到后台线程。但在线工具类产品绝大多数场景用不到我不建议为此增加复杂度。3.4 快捷操作与结果展示的设计细节工具虽小交互细节不能省。我做了一个“清空”“示例”按钮和一个“复制结果”按钮这里有一个容易被忽略的点点击清空后焦点要留在textarea上方便用户立刻继续输入而“示例”按钮填入示例文本后要手动触发一次统计。结果展示的文案也需要讲究。用户看到“字符数”三个字时往往不清楚含不含空格、换行。我的做法是在每个数字下面加一行小字说明比如“字符数包含空格和换行”“字符数不含空格剔除空格、制表符和换行”。这种描述能直接消除歧义减少客服咨询。还有一个隐藏细节是计算“不含空格字符数”不要通过text.replace(/\s/g, ).length去统计这样要遍历两次字符串更优雅的做法是在统计字符数时顺手过滤掉空白字符function countNonWhitespace(text) { return [...segmenter.segment(text)].filter( item !/\s/u.test(item.segment) ).length; }核心思路是复用一个分词结果避免对长文本做两轮完整遍历。4. 上线后踩过的坑与排查记录4.1 表情组合字符统计不对这个坑在开发时就发现了。家庭表情用Array.from()统计会得到 7用户肉眼看着明明是一个字符统计却显示 7非常难以理解。排查时发现它由四个 emoji 和三个零宽连接符ZWJU200D组成我们的分段处理必须基于字素簇。后来我把Intl.Segmenter作为默认方案但也保留了降级逻辑。如果用户浏览器不支持Intl.Segmenter就退回到Array.from()并在界面上加一行提示说明“表情组合可能被拆开计数”。这类提示对普通用户而言反而更实在总比给一个莫名其妙的大数字好。4.2 从 Word 粘贴导致统计异常有用户反馈从 Word 里复制了一段文字统计出的字数比 Word 自身统计的少。排查后发现问题根源不在统计逻辑而是粘贴内容里带了 Word 的格式控制字符比如软换行\x0B、非断空格\xA0。这些字符在正则的\s匹配范围内会被归为空白但有些用户以为它们是文本的一部分。处理方式分两层第一层在统计时统一把\x0B和\xA0视为空白字符归入“不含空白字符数”的过滤范围第二层在工具页上增加说明建议用户在 Word 里先“纯文本粘贴”再统计或者直接在输入框右键“粘贴纯文本”。这个是用户习惯问题代码只能尽量兜底。4.3 换行符与全角空格的差异不同操作系统的换行符不同Windows 用\r\nmacOS / Linux 用\n。如果统计“行数”不统一处理换行符会给用户造成困惑。我的做法是先把\r\n统一替换成\n再统计行数function countLines(text) { if (!text) return 0; return text.replace(/\r\n/g, \n).split(\n).length; }全角空格U3000也值得注意。中文文章里经常出现全角空格如果“不含空格”统计只过滤半角空格结果就会偏大。我在过滤时同时匹配\u3000const whitespaceReg /[\s\u3000]/u;这个细节虽然小但对从 Word 或微信编辑器复制过来的一手内容非常关键。4.4 高频反馈“统计结果为什么不包括标点”上线一个月后我收到不少用户留言统计字数里能不能把标点、数字、空格都单独分开尤其做小红书、公众号的用户他们需要的不是单一字数而是“正文字数”“含标题字数”这类颗粒度。后来我加了三个补充指标中文字符数、标点符号数、数字数。实现方式是把每个字素分类后归入对应计数器在中文字符分类上我用一个简单的unicode-range正则判断const hanReg /[\u4E00-\u9FFF\u3400-\u4DBF]/;这里没有引入完整的中文字库只覆盖了常用的 CJK 统一表意文字区段。在线工具做统计本来就不追求绝对学术精确能覆盖绝大多数用户场景就够了。核心教训是工具的功能边界要跟着用户要解决的问题走而不是一开始就堆一堆数字。4.5 浏览器兼容性速查在开发过程中我整理了一份兼容性速查表方便后续维护能力使用方式兼容性情况url事件addEventListener(input)全部现代浏览器compositionendIME 组合结束全部现代浏览器requestAnimationFrame帧级更新全部现代浏览器TextEncoderUTF-8 字节数全部现代浏览器Intl.Segmenter字素簇分组Chrome 87 / Safari 14.1 / Firefox 87如果要在旧版浏览器展示统计需写好降级分支。我的做法是启动时做一次能力检测把不支持的方案临时替换成Array.from() 手动过滤保证工具不会白屏。5. 完整代码参考与部署上线5.1 页面骨架与核心 JS 封装工具核心并不复杂我用一个简单的类来封装统计逻辑方便维护和扩展!DOCTYPE html html langzh-CN head meta charsetUTF-8 title文本字符数统计 - 在线工具/title /head body main classtool h1文本字符数统计/h1 textarea idtextInput placeholder在此输入或粘贴文本.../textarea div classstats div classstat-item span classstat-num idcharCount0/span span classstat-label字符数含空格/span /div div classstat-item span classstat-num idcharNoSpace0/span span classstat-label字符数不含空格/span /div div classstat-item span classstat-num idbyteCount0/span span classstat-label字节数UTF-8/span /div div classstat-item span classstat-num idwordCount0/span span classstat-label单词数 / 汉字数/span /div /div /main script const textInput document.getElementById(textInput); const charCountEl document.getElementById(charCount); const charNoSpaceEl document.getElementById(charNoSpace); const byteCountEl document.getElementById(byteCount); const wordCountEl document.getElementById(wordCount); let composing false; let rafId null; function countCharacters(text) { if (!text) return 0; try { const segmenter new Intl.Segmenter(zh, { granularity: grapheme }); return [...segmenter.segment(text)].length; } catch (e) { return Array.from(text).length; } } function countNonWhitespace(text) { const whitespaceReg /[\s\u3000]/u; try { const segmenter new Intl.Segmenter(zh, { granularity: grapheme }); return [...segmenter.segment(text)].filter(item !whitespaceReg.test(item.segment)).length; } catch (e) { return Array.from(text).filter(ch !whitespaceReg.test(ch)).length; } } function countBytes(text) { return new TextEncoder().encode(text).length; } function countWords(text) { const latin text.match(/[A-Za-z0-9\u00C0-\u024F\u1E00-\u1EFF\u2C60-\u2C7F\uA720-\uA7FF]/g); const han text.match(/[\u4E00-\u9FFF\u3400-\u4DBF]/g); const latinCount latin ? latin.length : 0; const hanCount han ? han.length : 0; return hanCount 0 ? hanCount : latinCount; } function updateStatistics() { const text textInput.value; charCountEl.textContent countCharacters(text); charNoSpaceEl.textContent countNonWhitespace(text); byteCountEl.textContent countBytes(text); wordCountEl.textContent countWords(text); } function scheduleUpdate() { if (rafId) return; rafId requestAnimationFrame(() { rafId null; updateStatistics(); }); } textInput.addEventListener(compositionstart, () { composing true; }); textInput.addEventListener(compositionend, () { composing false; scheduleUpdate(); }); textInput.addEventListener(input, () { if (!composing) scheduleUpdate(); }); updateStatistics(); /script /body /html这段代码已经足够支撑一个轻量工具。界面样式可以自由发挥统计逻辑的核心就在这里。5.2 移动端与深色模式适配在线工具有一半流量来自手机浏览器。移动端最主要的问题是键盘弹出后布局被挤压我给统计卡片做了两列换行布局让它们在窄屏上自动堆叠。同时把textarea的高度设置为40vh保证用户输入时有足够的可视面积。深色模式也是很多用户的诉求。我直接用 CSS 的prefers-color-scheme做了两套变量简单干净:root { --bg-color: #f5f6f8; --text-color: #1f2329; --card-bg: #fff; } media (prefers-color-scheme: dark) { :root { --bg-color: #1f2329; --text-color: #e6e8eb; --card-bg: #2b2f36; } }工具类站点做深色模式成本不高但能显著提升用户夜间使用体验特别是这个工具经常被用来连夜赶稿和填表。5.3 从单页工具到工具集的迭代做完这个统计工具后我把相同的基础框架抽成了工具集模板。后续加的“字数查重”“敏感词检测”“Markdown 字数统计”都复用同一套实时输入、统计卡片、复制结果的交互模式开发效率提升很明显。还有一个有意思的迭代我在 URL 上支持了?text参数从 anywhere 点链接进来时可以直接预填文本。这个功能一开始只是为了自己调试方便后来发现一些用户会把带统计文本的链接收藏起来当草稿用我就顺手在页面加了一个“分享当前文本”的按钮用history.replaceState把当前输入内容写进 URL。对在线工具来说这类小而轻的功能比堆功能更能留住用户。结尾做文本字符数统计这一年最深的体会是越是看起来简单的小工具越要把用户说出口和没说出口的需求都拆干净。“字符数”三个字背后藏着码元、码点、字素簇、编码长度、分词边界这一整条链路。真正提升用户满意度的往往不是多么复杂的算法而是把表情组合、中文输入法、全角空格这些边角情况一一处理到位。如果你也在做一个类似的在线小工具建议先上线一版最基础的功能再去根据用户反馈逐条补细节——工具是拿来用的不是拿来炫技的。最后再分享一个实操小心得字符统计类的工具页面一定要把“统计口径”写清楚数字旁边标注“含空格”“UTF-8”这类限定词能替你挡住一半不必要的客服咨询。