字符串字节数统计（按编码方式）
测量输入的文本在 UTF-8、Shift_JIS、EUC-JP、UTF-16 和 JIS（ISO-2022-JP）编码下各占多少字节。适用于确认数据库字段长度限制或旧式表单输入上限等场景。
使用提示
- 在 UTF-8 编码下，半角英数字每个占 1 字节，而平假名、片假名、汉字等日文字符通常每个占 3 字节，因此即使字符数相同，英文和日文文本的字节数也会相差很大。
- 如果数据库字段（如 VARCHAR(255)）采用的是旧式基于字节数的长度限制，包含日文的文本会比同样字符数的英文文本更快达到上限。
- 大多数表情符号（emoji）由两个代理对代码单元组成，在 UTF-8 和 UTF-16 中都占 4 字节，这也是社交媒体的字数统计有时会比预期更快达到上限的原因。
- 如果你已经知道字节数，想将其换算成 KB、MB 等单位，请使用姊妹工具「字节单位换算」——本工具负责的是从文本反向计算字节数。
常见问题
字符数指的是字符串中可见字符的数量，而字节数表示将该字符串作为计算机数据存储或传输时所需的字节（八位组）数量。对于纯 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 个字符。“只用了一个日文字符，可发送的字数就骤减一半以上”，正是本工具所要测量的字符编码与字节数关系的一个生动例证。