Windows-1252（也称 CP1252 或 ANSI）是微软 Windows 系统中常用的单字节字符编码。它基于 ISO 8859-1（Latin-1），但在 0x80-0x9F 范围内使用了不同的字符映射，包含了欧元符号 €、智能引号 ""、破折号 — 等常用符号。它是西欧语言环境下的默认编码，广泛存在于旧版 Windows 文件、Excel 导出的 CSV、电子邮件等场景中。每个字符占用 1 个字节（0x00-0xFF），共可表示 256 个字符。

两者在 0xA0-0xFF 范围完全一致，但在 0x80-0x9F 范围有显著差异：
• ISO 8859-1：0x80-0x9F 为 C1 控制字符（不可打印）
• Windows-1252：0x80-0x9F 映射为可打印字符，如 € (0x80)、' (0x91)、" (0x93)、– (0x96)、— (0x97)、™ (0x99) 等
这导致许多网页声明的 charset=ISO-8859-1 实际使用的是 Windows-1252——浏览器也默认将 ISO-8859-1 当作 Windows-1252 处理（HTML5 标准明确规定）。

乱码的根本原因是编码与解码使用了不同的字符集。常见场景：
场景A（最常见）：UTF-8 编码的文件被用 Windows-1252 打开。例如 "é" 的 UTF-8 字节是 0xC3 0xA9，用 Win1252 解读就变成了 "é"。这在打开旧版 CSV、日志文件时非常普遍。
场景B：Windows-1252 编码的文件被用 UTF-8 打开。UTF-8 解码器遇到非法字节序列会使用替换字符 � (U+FFFD)，导致信息丢失。
场景C：数据库连接字符集不匹配，如 MySQL latin1 列存储 UTF-8 数据。
修复的关键在于用正确的编码重新解读字节。

1. 切换到「乱码修复」标签页
2. 将乱码文本粘贴到输入框
3. 先尝试方向A（UTF-8→Win1252误读，最常见）：工具会将乱码字符映射回原始 UTF-8 字节，再正确解码
4. 如果方向A不理想，尝试方向B（Win1252→UTF-8误读）
5. 观察修复结果是否可读。如果两种方向都失败，可能需要考虑其他编码组合（如 GBK、Shift-JIS 等）
提示：如果乱码中包含 � 或 ? 等替换字符，说明原始字节已经丢失，无法完全恢复。

推荐使用 UTF-8：现代应用应优先使用 UTF-8，它支持全球所有语言字符，是 Web 标准编码。Windows-1252 仅支持西欧语言（约 256 个字符），无法表示中文、日文、阿拉伯文等。
仅在以下情况使用 Windows-1252：
• 需要兼容旧版 Windows 系统或软件
• 处理明确要求 ANSI 编码的 CSV/文本文件
• 与特定硬件设备通信（如某些 POS 打印机）
• 文件大小敏感且仅需西欧字符（Win1252 比 UTF-8 节省空间）

Python：data.decode('cp1252') 或 data.encode('cp1252')
JavaScript (浏览器)：new TextDecoder('windows-1252').decode(bytes)
Java：new String(bytes, "Windows-1252")
PHP：mb_convert_encoding($str, 'UTF-8', 'Windows-1252')
C#：Encoding.GetEncoding(1252)
注意：TextEncoder 在大多数浏览器中仅支持 UTF-8，编码为 Windows-1252 需要手动映射或使用 polyfill。

欧元符号 € 在 Windows-1252 中的字节值为 0x80（十进制 128）。这是 Windows-1252 与 ISO 8859-1 最显著的区别之一——在 ISO 8859-1 中 0x80 是一个不可打印的控制字符。这也解释了为什么某些旧系统显示 € 时会出问题：它们可能使用了纯 ISO 8859-1 而非 Windows-1252。