Go xml.Decoder.InputOffset 怎样记录 XML 解析位置

用 encoding/xml.Decoder 按 token 读取 XML 时，如果日志只写“读到了第几个标签”，解析错误就很难回到原始输入。解决办法是：每次 Token() 成功返回后，立刻调用 InputOffset() 保存当前位置。这个值是输入流的字节偏移，同时表示最近返回 token 的结束位置和下一个 token 的开始位置。

官方文档：https://pkg.go.dev/encoding/xml#Decoder.InputOffset

记住调用时机就够了：先拿到 token，再读取 InputOffset()；不要把它当成当前 token 的起始下标，也不要把字节偏移直接当作字符数量。

先看清偏移值落在哪里

假设输入是 Go。解析器返回 的开始元素 token 后，游标已经越过这 6 个 ASCII 字节，因此 InputOffset() 返回 6。随后返回字符数据 Go，游标来到 8；这个 8 既是字符数据 token 的结束位置，也正好是下一个结束元素 token 的起点。

这里的“位置”不是某个 token 的开始下标，而是 decoder 当前已经消费到哪里。这个定义很适合记录“错误发生前最后确认的输入位置”，但如果要得到当前 token 的起点，需要把上一次成功读取后的偏移保存下来，再用本次偏移作为结束位置。

为什么要在 Token 返回后记录

常见的排查代码会把 InputOffset() 放在循环开头，结果读到的偏移经常和日志里的 token 对不上。原因是 Token() 负责推进解析器；调用它之前，游标仍停在上一个 token 的边界。记录动作应该和“成功拿到 token”绑定。

package main

import (
    "encoding/xml"
    "fmt"
    "io"
    "strings"
)

func main() {
    dec := xml.NewDecoder(strings.NewReader(``))

    for {
        tok, err := dec.Token()
        if err == io.EOF {
            // EOF 说明没有新的 token；最后一次成功记录仍然有效。
            break
        }
        if err != nil {
            // 解析失败时打印最近一次成功读取后的字节位置。
            fmt.Printf("parse error near byte %d: %v\n", dec.InputOffset(), err)
            return
        }

        offset := dec.InputOffset()
        // 偏移值对应刚刚返回的 token 末尾，也是下一个 token 的起点。
        fmt.Printf("token=%T end-or-next=%d\n", tok, offset)
    }
}

这段写法有两个关键点。第一，io.EOF 是正常结束，不应当被当成解析错误；第二，解析错误发生在某次 Token() 调用中时，应该保留此前已经记录的成功位置。若业务需要把错误关联到一个确定的起点，可以在每轮开始时保存 previousOffset，成功后再更新它。

用上一位置和当前位置组成 token 范围

InputOffset() 返回的是一个游标点，而不是区间。做诊断记录时，可以把上一轮的偏移当作当前 token 的候选起点，把本轮成功后的偏移当作结束点。对 XML 解析来说，这个区间最适合做日志关联、原始字节切片或错误上下文摘要。

package main

import (
    "encoding/xml"
    "fmt"
    "io"
    "strings"
)

type tokenRecord struct {
    Kind       string
    Start      int64
    End        int64
    Line       int
    Column     int
}

func collectRecords(input string) ([]tokenRecord, error) {
    dec := xml.NewDecoder(strings.NewReader(input))
    records := make([]tokenRecord, 0, 8)
    var previous int64

    for {
        tok, err := dec.Token()
        if err == io.EOF {
            // 正常结束时直接返回已经收集到的记录。
            return records, nil
        }
        if err != nil {
            // previous 是最近一次成功 token 的边界，可用于错误上下文。
            return records, fmt.Errorf("XML parse failed near byte %d: %w", previous, err)
        }

        end := dec.InputOffset()
        line, column := dec.InputPos()
        records = append(records, tokenRecord{
            Kind:   fmt.Sprintf("%T", tok),
            Start:  previous,
            End:    end,
            Line:   line,
            Column: column,
        })
        // 下一轮开始时，当前 token 的结束位置成为新的起点。
        previous = end
    }
}

这个示例把 InputOffset 和 InputPos 放进同一条记录：前者服务字节级定位，后者服务日志中的行列提示。它并不意味着行列值可以替代字节偏移；两者解决的是不同的定位问题。

字节偏移和行列位置不要混用

InputOffset() 的返回类型是 int64，语义是输入流字节偏移；InputPos() 则返回当前 decoder 位置的行号和列号。对于只包含 ASCII 的片段，两者看起来容易互相印证；一旦 XML 中出现中文或其它多字节 UTF-8 内容，把偏移直接当成 Go 字符串的字符下标就会出错。

如果你的目标是从原始输入中截取上下文，应保留原始字节切片并使用偏移；如果目标是给人看的日志提示，应额外记录行列。不要先把字符串转成 []rune 再使用 InputOffset() 的结果，因为 rune 下标和字节下标不是同一个坐标系。

解析出错时应该保留哪一个位置

解析循环通常只有“最后一个成功 token”的位置可以确定。错误发生在下一次 Token() 内部时，错误返回本身不一定对应一个完整 token，因此日志中应明确写成“解析失败前的最近边界”，而不要声称它就是坏字符的精确起点。

更稳妥的记录结构可以包含三类信息：

• token 类型：例如开始元素、字符数据或结束元素。
• 边界偏移：上一成功位置与本次 InputOffset()。
• 可读位置：需要面向源码提示时再记录 InputPos() 的行列。

这样即使下一次读取返回语法错误，也能知道解析器已经确认到哪个字节边界，并把附近的原始内容交给上层日志或错误包装逻辑。

把调用时机固定成一个小检查表

最后的结论

记录 XML 解析位置的核心不是计算标签长度，而是尊重 decoder 的游标语义：Token() 成功后读取 InputOffset()，把它保存为最近 token 的结束边界和下一个 token 的起始边界。需要范围时保留前后两个偏移，需要人类可读提示时再叠加 InputPos()。

InputOffset 返回的是 token 的开始位置吗？

它返回当前 decoder 位置；按官方定义，这个位置同时是最近返回 token 的结束位置和下一个 token 的开始位置。因此不能单独把它称作当前 token 的起点。

InputOffset 是字符位置还是字节位置？

它是输入流字节偏移。XML 中有多字节 UTF-8 内容时，不要拿它直接索引 rune 切片。

为什么要额外记录 InputPos？

InputPos 提供行号和列号，适合面向源码的错误提示；InputOffset 更适合和原始字节、日志片段或外部记录做精确关联。