Go x/text/secure/precis Nickname 怎样比较昵称

我在做国际化昵称查重时，最初也想直接用 strings.ToLower 再比较字符串。真正遇到全角字符、非 ASCII 空格和兼容字符后，这个写法很快就显得不够稳。Go 的 golang.org/x/text/secure/precis 已经提供了 precis.Nickname，可以把昵称的准备、规范化和比较规则集中起来。

官方地址：https://pkg.go.dev/golang.org/x/text/secure/precis

需要判断两个昵称是否代表同一个可读标签时，直接使用 precis.Nickname.Compare(a, b)；需要保存规范值用 String，需要做索引或批量查重用 CompareKey。昵称只用于展示和冲突处理，认证授权仍应依赖稳定身份。

这次变化真正解决了什么

Nickname 实现的是 RFC 8266 定义的 Nickname profile。它属于 PRECIS 的 FreeformClass，目标是处理人类可读的显示名，而不是生成登录名或权限主体。与只做小写转换相比，它还会把非 ASCII 空格映射为空格、去掉首尾空格、合并内部连续空格，并使用 NFKC 归一化。

这意味着 " Foo  Bar " 和 "foo bar" 的比较不能只看原始字节；兼容字符也可能在比较中得到一致结果。另一方面，昵称的展示文本和比较文本不是一回事，不能把比较后的键直接回显给用户。

先用 String 生成规范昵称

如果数据库需要保存一个经过规则处理的昵称，可以调用 precis.Nickname.String。它返回规范化后的字符串和错误；输入经过处理后变成空字符串时，也应把它视为不可接受的昵称。下面的代码保留原始输入用于展示审计，同时只把规范值交给后续查重逻辑。

package nickname

import (
    "fmt"

    "golang.org/x/text/secure/precis"
)

// NormalizeNickname 生成可用于业务存储的昵称规范值。
func NormalizeNickname(raw string) (string, error) {
    // Nickname profile 负责空格映射与 NFKC 等规则，不手写替代流程。
    normalized, err := precis.Nickname.String(raw)
    if err != nil {
        return "", fmt.Errorf("normalize nickname: %w", err)
    }
    if normalized == "" {
        // 规范化后为空时拒绝，避免数据库出现无法展示的昵称。
        return "", fmt.Errorf("nickname becomes empty after normalization")
    }
    return normalized, nil
}

这里的规范值适合做业务字段或日志中的安全摘要，但不建议覆盖原始展示值。昵称可能因产品规则还需要长度上限、保留词或字符范围限制，这些是应用层约束，不能假设 Nickname profile 会替你完成。

比较时用 Compare，不要手动拼规则

precis.Nickname.Compare 会对两边执行比较所需的规则，然后按字节一致性判断结果。它的比较路径包含大小写映射，所以“Foo”和“foo”可以视为等价；而保存展示值时不应该为了查重先把内容全部改成小写。

package nickname

import "golang.org/x/text/secure/precis"

// SameNickname 判断两个输入是否是同一个昵称比较值。
func SameNickname(left, right string) bool {
    // Compare 会处理两端的准备、映射、大小写与归一化。
    return precis.Nickname.Compare(left, right)
}

这也解释了为什么不推荐把 strings.TrimSpace、strings.ToLower 和某个 Unicode 归一化函数随意串起来：顺序、空格类别和错误边界都可能与 Nickname profile 不一致。RFC 还提醒 Nickname 规则对部分字符并非天然幂等，应用不需要自己复制这套循环，应该让库的 profile 负责规则实现。

批量查重时换成 CompareKey

如果昵称要进入 map、缓存键或数据库唯一索引，使用 precis.Nickname.CompareKey 更合适。它返回可用于比较、哈希或排序的字符串；输入不符合 profile 时返回错误，不能把错误吞掉后继续写入集合。

package nickname

import (
    "fmt"

    "golang.org/x/text/secure/precis"
)

// NicknameKey 返回用于集合查重的键，不把键当作展示文本。
func NicknameKey(raw string) (string, error) {
    // CompareKey 适合索引和 map key，能保持比较规则与 Compare 一致。
    key, err := precis.Nickname.CompareKey(raw)
    if err != nil {
        return "", fmt.Errorf("build nickname compare key: %w", err)
    }
    return key, nil
}

实际落库时可以同时保留 display_name、normalized_name 和 compare_key，具体字段取决于产品是否允许用户重新编辑昵称。若只需要一次性判断，直接调用 Compare 更简单，不必为了短暂比较额外生成键。

旧代码迁移时要守住三条边界

• 不要用昵称替代用户 ID、URI 或资源主键；RFC 8266 明确要求认证和授权基于底层稳定身份。
• 不要把比较键回显到页面，也不要把“比较相等”解释成两个用户就是同一个身份。
• 不要忽略规范化错误、空结果、长度限制和产品保留词；这些仍然是业务层的入场条件。

我的实际取舍是：入口先用 String 做规范化和业务校验，查重用 CompareKey，需要解释冲突时再用 Compare 重现判断路径。这样既不会把 Unicode 规则散落在业务代码里，也不会误把昵称规范化做成身份系统。

相关问题

Nickname 和 UsernameCaseMapped 应该怎么选？

Nickname 面向显示名和可读标签，允许的表达空间更偏向 FreeformClass；账户名、网络标识等身份字段应根据协议选择对应的 Username profile，不要只因为都要比较就混用。

为什么不直接比较 strings.ToLower 的结果？

因为昵称比较还涉及空格映射、NFKC 和输入错误处理。手写小写转换无法完整复现 Nickname profile 的语义。