字符串字节数统计(按编码方式)

测量输入的文本在 UTF-8、Shift_JIS、EUC-JP、UTF-16 和 JIS(ISO-2022-JP)编码下各占多少字节。适用于确认数据库字段长度限制或旧式表单输入上限等场景。

字符数与字节数并非一回事

十个字符占去三十个字节,一旦沾上非拉丁文字便是家常便饭。**同一串文字,字节数会随编码而变**:UTF-8 里一个汉字占三个字节,一个表情符号占四个;Shift_JIS 里一个日文字符则只用两个。本工具会把您输入的内容,同时按 UTF-8、Shift_JIS、EUC-JP、UTF-16 与 ISO-2022-JP 五种方式,各算出多少字节。

**一并列出的「UTF-16 码元数」,正是 JavaScript 的 `.length` 所返回的那个数。** 这是最常被漏看的陷阱:表情符号与某些字符要用两个码元组成的代理对来表示,**故而人眼算作一个字的东西,`.length` 会算作两个。** 用 `.length` 做长度限制时,含表情符号的输入之所以比预想更早被挡下,缘故就在这里。数据库那一侧同样如此——`VARCHAR(255)` 究竟按字节还是按字符计,随产品与设置而异,两个数字都看在眼里,判断便不会出错。

使用方法

  1. 输入文字 一贴进去便即刻统计,含换行也无妨。
  2. 对照字符数与字节数 **一个字符在 UTF-8 中照样可能是三个字节。**
  3. 读取所关心那一种编码 看您的存储或目的地实际所用的那一行便是。
  4. 查看 UTF-16 码元数 **若限制是用 JavaScript 的 `.length` 施加的,决定结果的正是这个数。**

用好本工具的小技巧

  • 在 UTF-8 编码下,半角英数字每个占 1 字节,而平假名、片假名、汉字等日文字符通常每个占 3 字节,因此即使字符数相同,英文和日文文本的字节数也会相差很大。
  • 如果数据库字段(如 VARCHAR(255))采用的是旧式基于字节数的长度限制,包含日文的文本会比同样字符数的英文文本更快达到上限。
  • 大多数表情符号(emoji)由两个代理对代码单元组成,在 UTF-8 和 UTF-16 中都占 4 字节,这也是社交媒体的字数统计有时会比预期更快达到上限的原因。
  • 如果你已经知道字节数,想将其换算成 KB、MB 等单位,请使用姊妹工具「字节单位换算」——本工具负责的是从文本反向计算字节数。

这些场景会用到

防止数据库字段溢出

**当存储按字节设限时,中日文所能容纳的还不到您所设想的三分之一。** 写入之前便可核实。

设计表单的输入上限

它为「按字符设限还是按字节设限」提供了判断的材料。

对接老旧系统

在定长文件与 Shift_JIS 的交换中,字节数就是列的位置。

检验表情符号的处置

**可以确认含代理对的字符串,是否被当作您所期望的长度来对待。**

字符编码的术语

UTF-8
以一至四个字节的变长来表示世上文字的方式。**大略而言,ASCII 占一个,汉字占三个,表情符号占四个。**
Shift_JIS
面向日文的方式,**一个日文字符恰好容纳于两个字节。** 在老系统与定长文件中至今仍在使用。
EUC-JP
长期用于 UNIX 系统的日文方式。一个日文字符通常占两个字节。
UTF-16
以十六位为单位表示字符的方式。**JavaScript 的字符串正是按这种单位来计数的。**
代理对
**把一个容不下于单个 UTF-16 单位的字符,以两个单位成对表示**的安排。表情符号与某些字符属于此类。
ISO-2022-JP
以转义序列切换字符集的方式,长期用于日文邮件,亦径称作 JIS。

常见问题

字符数指的是字符串中可见字符的数量,而字节数表示将该字符串作为计算机数据存储或传输时所需的字节(八位组)数量。对于纯 ASCII 文本,两者数值相同;但对于包含日文等多字节字符的文本,字节数可能是字符数的好几倍。

UTF-8 是每个字符使用 1 到 4 字节的可变长编码方式,大多数日文字符(平假名、片假名、常用汉字)占 3 字节。而 Shift_JIS 大多数日文字符只占 2 字节,因此同样的日文文本在 UTF-8 下通常比 Shift_JIS 下占用更多字节。

这取决于数据库引擎以及字段的字符集设置。MySQL 的 VARCHAR(n) 基本上是按“n 个字符”限制的,但内部通常还存在独立的字节数限制(例如索引可用的最大键长),因此包含表情符号的文本有时会导致报错。具体行为请参考所使用数据库管理系统的官方文档。

半角英数字和符号在 UTF-8、Shift_JIS、EUC-JP 中都只占 1 字节,而全角字符(平假名、片假名、汉字、全角符号)根据编码方式不同占 2 到 3 字节。同样是“10 个字符”的文本,全部为半角时只需 10 字节,全部为全角时则需要 20 至 30 字节。

本工具是输入一段文本,计算该文本在各种编码下的字节数。而「字节单位换算」工具则是输入一个已知的字节数(例如 1,500,000 字节),将其换算为 KB、MB、GB 等单位。想从“文本”求“字节数”时用本工具,想从“字节数”换算成“其他单位”时用字节单位换算工具。
工具君

闲话 ― 社交媒体字数限制与字节数之间鲜为人知的关系

早期版本 MySQL 的 “utf8” 字符集存在一个令人意外的限制:它其实无法存储 U+10000 以上的 Unicode 补充字符,也就是许多表情符号。UTF-8 本身是支持每字符最多 4 字节的可变长编码,但 MySQL 的 “utf8” 出于历史原因最多只能处理 3 字节,导致插入包含表情符号的文本时经常报错。如今推荐迁移到能正确支持完整 4 字节范围的 “utf8mb4”,这是理解字符编码与字节数关系在实际应用中重要性的一个经典案例。

在 Twitter(现 X)曾实行 140 字符限制的年代,围绕语言间公平性曾有过长期争论:日语用户用 140 个字符就能表达相当完整的意思,而英语用户在同样限制下往往只能写 20 到 30 个单词。这是因为一个日文汉字所承载的信息量远超一个英文字母。Twitter 后来引入了一套加权计数机制,让日语等语言按“1 字符 = 1 计数”计算,而部分其他语言的某些字符按“2 字节 = 1 计数”计算,以此在不同语言之间取得平衡。

手机短信也存在类似的现象。标准 GSM 编码的短信每条最多允许 160 个字符,但只要其中包含哪怕一个不在 7 位 GSM 字符集范围内的字符——比如表情符号或日文字符——编码方式就会切换为 UCS-2(大致相当于 UTF-16),上限也会骤降到仅 70 个字符。“只用了一个日文字符,可发送的字数就骤减一半以上”,正是本工具所要测量的字符编码与字节数关系的一个生动例证。