Go BitString.RightAlign 怎样处理不足整字节的位串

asn1.BitString.RightAlign() 会把有效位右对齐，让补零位出现在返回字节切片的开头。例如五位 11011 在 BitString 中保存为 11011000，右对齐后是 00011011。它返回的是字节切片，不是新的 BitString，也不是 DER 编码；返回切片还可能与原对象共享内存。

官方文档地址：https://pkg.go.dev/encoding/asn1#BitString.RightAlign

先把字节长度和有效位长度分开

在协议接入中，Bytes 的长度回答“用了多少个字节”，BitLength 回答“有多少位有意义”。五位内容仍要占用一个字节，其余三位是填充。对有效的最短存储表示，字节数是有效位数除以八后向上取整；填充位数是字节数乘八减去 BitLength。

原始 BitString 把有效位放在前面，末字节尾部补零。RightAlign 改变的是这些位在字节容器中的对齐位置，不会反转有效位的次序。生产接入应从成功解析的 BIT STRING 或符合约定的手工对象开始，不要把任意 Bytes 和任意 BitLength 拼起来后指望这个方法修复。

用五位和跨字节示例理解右对齐

下面的示例输入均由本文构造，便于逐位计算。它们不是外部协议报文，也没有被描述为本机实测结果。

package main

import (
    "encoding/asn1"
    "fmt"
)

func main() {
    samples := []asn1.BitString{
        // 有效位 11011，低三位为补零。
        {Bytes: []byte{0xD8}, BitLength: 5},
        // 有效位 101001011，末字节低七位为补零。
        {Bytes: []byte{0xA5, 0x80}, BitLength: 9},
        // 整字节输入没有需要移动的填充位。
        {Bytes: []byte{0x6D}, BitLength: 8},
    }
    for _, bits := range samples {
        aligned := bits.RightAlign()
        fmt.Printf("有效位=%d 原字节=%x 右对齐=%x\n",
            bits.BitLength, bits.Bytes, aligned)
    }
}

这些是按输入与位移规则推导的对应关系。九位案例的有效内容是 101001011，放进两个字节右端后得到 00000001 01001011。如果业务把它视为无符号二进制数，这种表示更容易与大端整数读取逻辑衔接；但 BIT STRING 本身并不自动规定业务必须把它解释为整数。

需要修改结果时建立独立缓冲

方法名中的 RightAlign 没有“返回独立副本”的承诺。官方接口明确允许共享内存。官方当前实现对整字节位串直接返回原 Bytes；没有尾部填充时，修改返回切片的元素可能同时修改原对象。

因此，接收只读数据时可以读取返回值；需要修改、缓存或交给另一个可写组件时，先复制到独立缓冲。下面把 DER 解析、尾部数据处理和内存隔离放在一个接入函数里。

package bitvalue

import (
    "encoding/asn1"
    "fmt"
)

type AlignedBits struct {
    Bytes     []byte
    BitLength int
}

func DecodeAligned(der []byte) (AlignedBits, error) {
    // 4096 字节是本例的业务限额，应在读取输入时也限制总大小。
    if len(der) > 4096 {
        return AlignedBits{}, fmt.Errorf("位串输入超过业务限额")
    }
    var bits asn1.BitString
    rest, err := asn1.Unmarshal(der, &bits)
    if err != nil {
        return AlignedBits{}, fmt.Errorf("BIT STRING 解析失败: %w", err)
    }
    // 本接口只允许一个完整的顶层 BIT STRING 对象。
    if len(rest) != 0 {
        return AlignedBits{}, fmt.Errorf("位串后存在额外数据")
    }
    aligned := bits.RightAlign()
    // 始终复制，调用方修改结果不会改到原位串或输入缓冲。
    owned := make([]byte, len(aligned))
    copy(owned, aligned)
    return AlignedBits{Bytes: owned, BitLength: bits.BitLength}, nil
}

这里的 owned 是独立缓冲；AlignedBits 同时保留右对齐字节和有效位长度。4096 是示例业务限额，不是 ASN.1 标准上限。输入若来自网络，应在读取阶段限制大小，不能等完整大报文进入内存后才依赖这个长度判断。

对齐后的字节不要直接写回原位串

不要执行“用 RightAlign 的返回值替换 bits.Bytes，同时保留旧 BitLength”这样的赋值。BitString 约定的是有效位靠前、尾部补零；五位 1B 是右对齐的字节表示，不能直接当作五位 BitString 的标准存储。

如果需要重新生成 DER，保留原始的有效 BitString 并交给 asn1.Marshal；如果只需要数值视图，使用独立的右对齐结果即可。RightAlign 不生成 ASN.1 标签、长度和填充计数字段。DER 报文、BitString.Bytes 和右对齐字节是三个不同层次。

仅保存右对齐字节还会丢失位长信息：含前导零的不同位串可能得到相同的字节内容。若后续还需要还原原位串，必须保留 BitLength，不能只保存某个整数。

接入解析边界并保留必要诊断

对外部 DER 数据，先处理 Unmarshal 错误，再使用解析对象。本文接口只允许一个顶层 BIT STRING，所以拒绝非空 rest。日志可以记录输入字节数、有效位数和错误类型；无需把完整业务位串写入日志。对于手工构造对象，应由构造层保证位长、字节数和补零一致，RightAlign 没有返回 error，也不是输入合法性检查器。

RightAlign 会修改原 Bytes 吗？调用本身用于返回对齐表示，不能由此推导结果一定独立。后续写返回切片时，应按可能共享内存处理。

整八位的结果也需要复制吗？如果接下来要修改或要求独立所有权，就需要复制；只读使用不必为了对齐额外制造副本。

At(i) 应读取哪个对象？At 使用原 BitString 的存储约定和 BitLength。右对齐切片是另一种表示，不应直接替换原存储再沿用相同索引逻辑。

实际选择取决于用途：保留协议结构时保存原 BitString，读取右对齐字节时调用 RightAlign，需要可写结果时明确复制，并始终保留业务需要的有效位长度。

参考：BitString 与 RightAlign 文档、Go ASN.1 官方实现。