Go x/text/encoding/charmap Windows1252 为什么不能当作 ISO8859_1

Windows1252 和 ISO8859_1 都是单字节编码，但“一个字节对应一个字符”不等于“每个字节的字符定义相同”。最容易出错的是 0x80 到 0x9F：Windows1252 在这里放了欧元符号、标点和字母变体，ISO8859_1 则把这段保留为 C1 控制字符。因此，Go 中不能只因为两者都占一个字节，就把 charmap.Windows1252 换成 charmap.ISO8859_1。

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

两个编码都只有一字节，为什么结果仍然不同

单字节描述的是存储宽度，不是字符表。ASCII 的 0x00 到 0x7F 在两种编码中基本保持相同，所以英文、数字和常见标点经常让错误选择暂时不暴露。一旦输入包含扩展字节，解码器就必须按照各自的映射表把字节转成 Unicode 码点。

ISO8859_1 把全部 256 个字节直接放在 U+0000 到 U+00FF；其中 0x80 到 0x9F 对应控制字符。Windows1252 复用了同一个字节区来表示西欧文字常见的排版字符，例如 0x80 是欧元符号，0x85 是省略号，0x91 与 0x92 是弯引号。

同一组字节用两个 Charmap 解码会发生什么

可以把包含 0x80、0x85 和 0x91 的字节交给两个解码器对比。下面的代码不依赖文件或终端，重点是把同一份原始字节分别交给两个明确的编码表：

package main

import (
    "fmt"

    "golang.org/x/text/encoding/charmap"
)

func main() {
    raw := []byte{0x80, 0x85, 0x91, 'G', 'o'}

    // Windows1252 把扩展字节映射到欧元符号、省略号和弯引号等字符。
    winText, winErr := charmap.Windows1252.NewDecoder().Bytes(raw)
    // ISO8859_1 会把同一段字节按 U+0080–U+009F 控制字符解释。
    isoText, isoErr := charmap.ISO8859_1.NewDecoder().Bytes(raw)

    fmt.Printf("Windows1252: %q, err=%v\\n", string(winText), winErr)
    fmt.Printf("ISO8859_1:   %q, err=%v\\n", string(isoText), isoErr)
}

前者得到的是可见的西欧排版字符，后者得到的字符串包含控制码。控制码在日志、JSON、HTML 或数据库展示层可能表现为空白、转义序列或不可见差异，于是问题经常被误判为“乱码”或“丢字符”。

不要用显示效果反推输入编码

如果样本只有 ASCII，两个解码器的结果几乎一样；如果样本刚好没有落入差异字节区，错误选择也可能持续隐藏。更可靠的判断顺序是追溯文件导出系统、HTTP 响应头、协议说明或数据库连接配置，并确认它们使用的名称究竟指向 Windows-1252 还是 ISO-8859-1。

在 Go 中选择正确的 Charmap 与转换边界

golang.org/x/text/encoding 定义了编码接口，charmap 提供具体的单字节字符表，transform 则提供 Reader 和 Writer 包装器。三者的职责不同：Charmap 决定映射，Decoder/Encoder 负责方向，Reader/Writer 负责把转换接到流上。

package main

import (
    "io"
    "os"

    "golang.org/x/text/encoding/charmap"
    "golang.org/x/text/transform"
)

func decodeWindows1252(r io.Reader, w io.Writer) error {
    // Reader 读取原始 Windows1252 字节，并把输出转换成 UTF-8。
    decoded := transform.NewReader(r, charmap.Windows1252.NewDecoder())
    // Copy 只负责搬运转换后的字节，错误仍然返回给调用方。
    _, err := io.Copy(w, decoded)
    return err
}

func main() {
    // 真实程序中 r 可以是文件或网络响应，w 可以是 UTF-8 文件。
    if err := decodeWindows1252(os.Stdin, os.Stdout); err != nil {
        // 读取或转换失败时保留原始错误，便于定位输入边界。
        panic(err)
    }
}

若文件实际是 ISO8859_1，只需要替换为 charmap.ISO8859_1.NewDecoder()。不要把“读取成功”当作编码选择正确：读取器通常能消费字节，错误会在字符映射或后续展示阶段才显现。

反向编码时，Windows1252 也不是 ISO8859_1 的超集

编码方向同样需要关注目标字符表。Windows1252 能表示欧元符号等字符，而 ISO8859_1 没有对应的单字节位置，因此把包含欧元符号的 UTF-8 字符串编码到 ISO8859_1 时，应检查返回的错误，而不是静默丢弃字符：

package main

import (
    "fmt"

    "golang.org/x/text/encoding/charmap"
)

func main() {
    text := "价格 €"

    // Windows1252 有欧元符号的字节映射，编码结果可以继续写入旧系统。
    winBytes, winErr := charmap.Windows1252.NewEncoder().String(text)
    // ISO8859_1 没有欧元符号的对应字节，应把 error 作为兼容性信号。
    isoBytes, isoErr := charmap.ISO8859_1.NewEncoder().String(text)

    fmt.Printf("Windows1252: % x, err=%v\\n", []byte(winBytes), winErr)
    fmt.Printf("ISO8859_1:   % x, err=%v\\n", []byte(isoBytes), isoErr)
}

如果业务确实需要“尽量输出”而不是遇到不可表示字符就停止，encoding.ReplaceUnsupported 可以替换不在目标字符集中的字符，但这是兼容旧系统的取舍，不应掩盖错误的输入或目标编码配置。

把编码选择写成一个可复查的约束

• 先看来源：以导出系统、协议或接口声明为准，不以文件名后缀猜测。
• 再看差异：至少抽样一个包含 0x80、弯引号或省略号的真实字节序列。
• 解码后统一到 UTF-8：在应用内部尽早转换，避免把原始单字节字符串传到多个层。
• 编码前检查目标：目标 Charmap 不可表示字符时保留 error，只有明确业务策略时才使用替换。
• 记录映射选择：在适配层注明来源编码，避免后续维护者看到“都是单字节”就替换实现。

常见问题

Windows1252 和 ISO8859_1 在 ASCII 范围内一样吗？

大体一致，这也是误用不容易立刻暴露的原因；差异主要在 0x80 到 0x9F。

把 Windows1252 当 ISO8859_1 会一定报错吗？

不一定。解码可能正常消费字节，但字符语义已经变化；问题可能到展示、排序、搜索或再次编码时才出现。

ISO8859_1 能编码欧元符号吗？

不能按 ISO8859_1 的单字节表表示欧元符号；反向编码时应检查返回的 error。

为什么代码里要用 transform.NewReader？

它把 Decoder 接到 io.Reader 上，适合文件和网络流；如果数据已经完整放在内存中，则可直接使用 Decoder 的 Bytes 或 String。