Go go-multibase 怎样识别文本前缀并恢复原始字节

go-multibase 用 Decode(text) 同时返回编码类型、原始字节和错误。传入的字符串必须保留开头的 multibase 标识；库根据它选择解码方式，不需要调用方在 Base16、Base64 等算法之间猜测。

官方项目地址：https://github.com/multiformats/go-multibase

例如一个配置导入接口允许同一份二进制数据以十六进制或URL友好文本传输，普通编码字符串缺少算法信息，multibase则把编码标识放在内容前面。本文只处理编码文本的识别与恢复，不把解码成功解释成数据来源可信或业务格式正确。

先看最小规则：前缀说明编码，后半段保存编码内容

multibase的结构是“编码标识码点＋编码后的数据”。本文使用的两个标识都是ASCII：f对应小写Base16，u对应无填充Base64url。标识本身不属于原始数据。

不要先删掉首字符，再把剩余内容传给Decode；那会让第一个有效数据字符被误作新的编码标识。也不要给普通Base64文本随意添加u，除非内容确实符合无填充Base64url的字母表与规则。大小写、URL字母表和填充形式都可能影响编码类别。

第一张图分为“传输文本”和“解码结果”：完整文本包含编码标识与编码内容，Decode关联完整文本，并提供Encoding与原始字节两个结果。这是静态数据组成，不是操作时序。

准备依赖，用一份二进制数据观察两种表示

在独立目录初始化模块，再添加官方Go实现。已有工程按自身依赖策略固定版本，不需要为了下面的例子随意升级全部依赖。

# 新建独立示例模块并加入multibase依赖
go mod init example.com/multibase-demo
go get github.com/multiformats/go-multibase
# 将后面的完整代码保存为main.go后运行
go run .

示例原始数据为三个字节00、2a、ff。代码用Encode生成两种完整文本，再交给受限的decodeAllowed函数恢复；打印十六进制而非直接转换成字符串，避免把二进制内容误当作可阅读文本。

package main

import (
    "bytes"
    "fmt"
    "log"

    mb "github.com/multiformats/go-multibase"
)

// 示例接口只允许小写base16与无填充base64url。
// 先限输入字节数并限制前缀，再进入解码器，避免任意编码分支。
func decodeAllowed(s string) (mb.Encoding, []byte, error) {
    if len(s) == 0 || len(s) > 4096 {
        return 0, nil, fmt.Errorf("编码文本长度必须在1到4096字节")
    }
    if s[0] != byte(mb.Base16) && s[0] != byte(mb.Base64url) {
        return 0, nil, fmt.Errorf("当前接口不接受该编码前缀")
    }
    enc, data, err := mb.Decode(s)
    if err != nil {
        // 失败时不把可能返回的局部数据交给下游。
        return 0, nil, fmt.Errorf("multibase解码失败: %w", err)
    }
    if len(data) > 1024 {
        return 0, nil, fmt.Errorf("解码数据超过1024字节")
    }
    return enc, data, nil
}

func run() error {
    source := []byte{0x00, 0x2a, 0xff}
    for _, base := range []mb.Encoding{mb.Base16, mb.Base64url} {
        // Encode会添加编码标识，Decode需要完整字符串。
        text, err := mb.Encode(base, source)
        if err != nil { return fmt.Errorf("编码: %w", err) }
        actual, decoded, err := decodeAllowed(text)
        if err != nil { return err }
        if actual != base || !bytes.Equal(source, decoded) {
            return fmt.Errorf("编码类别或原始数据不匹配")
        }
        // 二进制按十六进制打印，避免误当UTF-8正文。
        fmt.Printf("%s -> %x\n", text, decoded)
    }
    return nil
}

func main() {
    if err := run(); err != nil { log.Fatal(err) }
}

根据编码规则手工推导，预期输出为：

f002aff -> 002aff
uACr_ -> 002aff

这里没有实际运行示例；预期值说明两种文本可以还原同一份字节，Encoding用于区分采用了哪种表示。业务如果需要保存来源格式，应保存Encoding或原始输入，而不是只保存解码字节后再猜。

接入外部输入时，把长度与编码白名单放在前面

库支持的编码范围可以大于某个业务接口允许的范围。本文接口只允许f与u，先检查输入长度与首字节，再调用Decode。这个首字节判断只适用于本例明确限定的两个ASCII前缀，不是通用multibase前缀解析器；规范的标识是码点，不应把所有编码都概括成“删一个字节”。

输入上限4096字节、输出上限1024字节，是示例自行选择的资源合同，不是库的内置限制。输入长度用len测量字节数；接收HTTP或文件时还应在读入完整字符串之前限制请求体或文件大小，避免已经分配过大内容后才拒绝。

第二张图分为“输入合同”和“结果合同”：长度上限与前缀白名单约束外部文本，外部文本关联Decode；Decode关联输出上限与业务解析。输出上限不负责识别内容类型，业务解析也不能代替编码错误处理。

函数在任何错误分支都返回nil数据。这样即使底层解码器同时返回了部分字节与错误，下游也不会误用局部结果。不要只检查data是否非空；空字节序列也可能是合法编码结果，是否允许由业务决定。

恢复出字节后，再判断它是不是业务需要的数据

multibase解决“这些文本采用什么编码”，不提供加密、签名验证或业务模式校验。恢复出的数据可能是UTF-8文本、压缩内容、结构化消息或任意二进制，不能直接用string(data)当作可信配置。

如果业务规定是UTF-8，可单独检查字符有效性；如果规定是JSON，交给JSON解析器并限制字段与嵌套规模。本文示例的ff字节不是有效UTF-8文本的一部分，但作为二进制数据完全可以往返。不要用“能打印”作为数据完整性的判断条件。

若后续要按解码数据做去重，需要先定义业务上的相等关系。同一份字节可以有不同的编码文本；按文本去重与按原始字节去重，得到的业务语义可能不同。

错误记录与接入清单

建议日志保存请求ID、拒绝阶段、输入字节数、允许的编码集合和错误类别，不直接记录完整敏感输入。上层用%w保留解码错误，便于定位，返回给外部的提示则可以更简洁。这个示例没有磁盘、网络连接或后台任务需要关闭；它也没有替业务读取配置文件或执行任何解码结果。

• 接口约定接收完整multibase文本，不能提前删除标识。
• 入口先限制读取体积，解码函数再限定编码与长度。
• Decode错误与业务解析错误分别记录。
• 按字节比较往返结果，不依赖打印成字符串是否好看。

普通十六进制文本能直接Decode吗？它必须按协议带上对应标识；不要对缺少格式合同的任意字符串盲猜。若接口本来只接收普通十六进制，用标准hex解码即可。

所有库支持的编码都应开放吗？不需要，业务可选少量互操作编码，白名单由接口合同确定，不能把标准表中的所有条目当作当前实现都支持。

Decode成功是否说明内容被认证？没有。编码识别与身份、完整性和授权是不同问题，需要由对应业务协议解决。

技术依据：官方Go API、官方编解码实现、multibase格式说明与编码表。输入合同、往返数据与受限函数为本文原创设计。