Go unicode/utf8 怎样统计 rune 数而不是字节数

统计 Go 字符串中的 rune 数，直接使用 utf8.RuneCountInString(s)；len(s) 返回的是字节数。只需要计数时，不必先把整个字符串转换为 []rune。但 rune 数仍不等于用户看到的字符数，更不等于显示宽度；组合附加符和某些 emoji 序列会让这些指标不同。

先把接口中的长度单位写清楚

假设批量导入接口允许标题最多 40 个 rune。英文标题看起来正常，中文标题却提前超限，常见原因是沿用了 len(title) 判断。改函数之前，应先确认这“40”究竟代表字节、Unicode 码点、扩展字素簇还是显示列宽。不同单位解决不同问题，不能让开发者各自理解“字符数”。

本文把接入流程限定为：受控大小的 UTF-8 文本、编码是否合法、rune 是否超限、失败如何反馈。不涉及字符集转码、数据库字段类型选型或复杂的用户感知字符切分。示例数值来自编码规则推导，未在本地执行测试。

使用标准库不需要额外依赖

计数与编码判断都在标准库 unicode/utf8 中。它处理 UTF-8 编码，不会把 GBK 字节自动转换为中文。Go string 能容纳任意字节，所以“已经是 string”不意味着“已经是合法 UTF-8”。这一点在文件、消息、网络输入转换成字符串时尤其重要。

API 行为见 RuneCountInString 官方文档；字节、字符串和码点的关系可参考 Go 官方字符串说明。当业务确实要求用户感知字符时，切分规则应另行采用 Unicode 文本分段规范，不能把标准库 rune 计数改个名字就当成字素簇计数。

把字节数和 rune 数放在一起看

package main

import (
    "fmt"
    "unicode/utf8"
)

func main() {
    // 用转义写清组合附加符，避免编辑器显示掩盖区别。
    values := []string{"A中🙂", "\u00e9", "e\u0301", ""}
    for _, s := range values {
        fmt.Printf("%q：字节=%d，rune=%d，UTF-8有效=%t\n",
            s, len(s), utf8.RuneCountInString(s), utf8.ValidString(s))
    }
}

按 UTF-8 规则，A中🙂 应有 8 个字节、3 个 rune：A 占 1 字节，中占 3 字节，单个笑脸码点占 4 字节。预组形式 é（U+00E9）是 2 字节、1 个 rune；e 加组合重音（U+0065、U+0301）是 3 字节、2 个 rune，常见排版中两者外观相近。空串的两种计数都是 0，且是合法 UTF-8。

不要把 s[i] 当成第 i 个 rune：字符串索引取的是单个字节，切片位置也按字节解释。range 遍历能够按 UTF-8 解码 rune，但其中的索引仍是字节偏移。仅做数量判断时使用 RuneCountInString 更能表达意图；如果还要逐个检查码点，再选择 range。

在入口先处理非法 UTF-8

RuneCountInString 本身不报告格式错误。对错误或不完整编码，标准库按每个宽度为一字节的错误单元计数。因此返回了数字，不足以证明输入是合法文本。接口要求有效 UTF-8 时，应先拒绝非法编码，再检查业务 rune 上限。可以另外保留一个字节上限，控制资源规模。

package titlelimit

import (
    "errors"
    "fmt"
    "unicode/utf8"
)

var (
    ErrTitleBytes = errors.New("标题字节数超限")
    ErrTitleUTF8 = errors.New("标题不是合法UTF-8")
    ErrTitleRunes = errors.New("标题rune数超限")
)

// CheckTitle 只校验长度与编码，不修改原始字符串。
func CheckTitle(s string) (int, error) {
    const maxBytes = 4096
    const maxRunes = 40

    // 字节限制优先，避免扫描无界的大字段。
    if len(s) > maxBytes {
        return 0, ErrTitleBytes
    }
    if !utf8.ValidString(s) {
        return 0, ErrTitleUTF8
    }
    n := utf8.RuneCountInString(s)
    if n > maxRunes {
        return n, fmt.Errorf("%w：实际=%d，上限=%d",
            ErrTitleRunes, n, maxRunes)
    }
    return n, nil
}

这个函数允许空串，不会去掉空格，也不会合并 Unicode 的规范等价形式。如果业务要求非空、禁止控制字符或统一规范化形式，应另写明确规则，并确定这些处理发生在计数前还是计数后。不要在校验函数里悄悄更改用户数据。4096 字节与 40 rune 是示例中的两项独立约束，不表示二者等价。

此函数检查的是已经拿到内存里的字段；若输入来自 HTTP 请求体或大文件，还要在读取层限制总体积，不能等读完整份超大内容后才寄希望于 len 检查。对于已有 []byte 的入口，可使用 utf8.Valid 和 utf8.RuneCount，避免仅为计数转换类型。

让失败记录能解释而不暴露内容

将失败分为字节超限、编码非法和 rune 超限，调用方就能分别给出可理解的提示。日志可记录字段名称、错误类别和已得到的计数，不需要原样记录整段标题。对于非法 UTF-8，不应伪造一个“正常字符数”作为用户侧解释，更不要先静默替换错误字节，再声称原输入通过。

合法的替换字符 U+FFFD 也可能真实存在于文本中。因此，只看到 rune 值等于 RuneError，不能直接断言编码有错；如果需要定位非法字节，必须结合解码宽度等信息。本文的入口判断直接使用 ValidString，不把这类细节混入长度计数。

计数需要随输入规模扫描，ValidString 与计数是两次逻辑独立的遍历。示例选择可读性与明确错误类型，不声称做过性能优化。只取数量时，不必为所有 rune 建立切片；只有后续确实需要按 rune 索引或处理整个码点序列时，才考虑 []rune，并评估额外存储。

统一上下游计数约定

跨语言接口要把“UTF-8 有效文本，最多 40 个 Unicode 码点”这类约定写进字段文档。JavaScript 字符串 length 使用 UTF-16 代码单元口径，不能直接拿来与 Go 的 rune 数对照。前端展示的剩余数量、服务端校验和存储约束如果使用不同单位，应明确各自目标，而不是让用户反复遇到“还没到限制却提交失败”。

可以在项目自身的用例中覆盖 ASCII、中文、单码点 emoji、组合字符、空串、合法 U+FFFD、非法字节及超限输入；预期值按约定定义，不以屏幕上看见几个图形为准。本文不运行这些用例，也不把配图当成测试结果。

len([]rune(s)) 可以统计 rune 吗？

可以得到相应的解码 rune 数，但为了一个数量不必构造整个切片；它也不能替代输入编码有效性检查。

为什么两个看起来相同的 é 计数不同？

一个可能是预组码点，另一个可能是字母与组合附加符。Go 不会自动保证字符串已经规范化。

按 rune 截断就不会拆开 emoji 吗？

不能保证。某些 emoji 是多个码点组成的序列；按用户感知字符截断需要独立的字素簇分段规则。

落地时保留清楚的分工：len 约束字节，ValidString 判断 UTF-8，RuneCountInString 统计 rune；字素簇和显示宽度由另外的业务规则负责。这样，长度限制才不会在中英文、emoji 和异常输入之间改变含义。