mysql-latin1-codec 2.0

命令行工具

命令行工具的行为类似于 iconv

$ python -m mysql_latin1_codec --help
usage: mysql_latin1_codec.py [-h] [-f encoding] [-t encoding] [-o filename]
                             [-c]
                             [inputs [inputs ...]]

iconv-like tool to encode or decode data using MySQL's "latin1" dialect,
which, despite the name, is a mix of cp1252 and ISO-8859-1.

positional arguments:
  inputs                Input file(s) (defaults to stdin)

optional arguments:
  -h, --help            show this help message and exit
  -f encoding, --from encoding
                        Source encoding (uses MySQL's "latin1" if omitted)
  -t encoding, --to encoding
                        Target encoding (uses MySQL's "latin1" if omitted)
  -o filename, --output filename
                        Output file (defaults to stdout)
  -c, --skip-invalid    Omit invalid characters from output (not the default)

Python API

在 Python 代码中，只需导入名为 mysql_latin1_codec 的模块，并调用 register() 函数。将在 Python 的编码注册表中注册一个名为 mysql_latin1 的字符串编码。

import mysql_latin1_codec

mysql_latin1_codec.register()

您可以使用正常的 (字节) 字符串上的 .decode() 和 .encode() 方法，您还可以将其指定为各种 I/O 函数（如 io.open()）的 encoding 参数。示例

# String encoding/decoding round-trip
s1 = u'foobar'
s2 == text.encode('mysql_latin1').decode('mysql_latin1')
assert s1 == s2

# Reading files
import io
with io.open('/path/to/file', 'r', encoding='mysql_latin1') as fp:
    for line in fp:
        pass

MySQL 如何定义 latin1

当指定 latin1 时，MySQL 使用的字符集实际上不是众所周知的 latin1 字符集，官方称为 ISO-8859-1。MySQL 所称的 latin1 实际上是基于 cp-1252（也称为 windows-1252）的自定义编码。

MySQL 文档关于 西欧字符集 9§ 10.1.14.2) 包含以下内容：

latin1 是默认字符集。MySQL 的 latin1 与 Windows 的 cp1252 字符集相同。这意味着它与官方的 ISO 8859-1 或 IANA（互联网分配数字权威机构）的 latin1 相同，除了 IANA latin1 将 0x80 和 0x9f 之间的代码点视为“未定义”，而 cp1252 以及因此 MySQL 的 latin 将字符分配给这些位置。例如，0x80 是欧元符号。对于 cp1252 中的“未定义”条目，MySQL 将 0x81 转换为 Unicode 0x0081，0x8d 转换为 0x008d，0x8ff 转换为 0x008f，0x90 转换为 0x0090，0x9d 转换为 0x009d。

更多详细信息可以在 MySQL 源代码的文件 strings/ctype-latin1.c 中找到

WL#1494 notes:

We'll use cp1252 instead of iso-8859-1.
cp1252 contains printable characters in the range 0x80-0x9F.
In ISO 8859-1, these code points have no associated printable
characters. Therefore, by converting from CP1252 to ISO 8859-1,
one would lose the euro (for instance). Since most people are
unaware of the difference, and since we don't really want a
"Windows ANSI" to differ from a "Unix ANSI", we will:

 - continue to pretend the latin1 character set is ISO 8859-1
 - actually allow the storage of euro etc. so it's actually cp1252

Also we'll map these five undefined cp1252 character:
  0x81, 0x8D, 0x8F, 0x90, 0x9D
into corresponding control characters:
   U+0081, U+008D, U+008F, U+0090, U+009D.
like ISO-8859-1 does. Otherwise, loading "mysqldump"
output doesn't reproduce these undefined characters.

如您所见，此编码与 ISO-8859-1（真正的 latin1）有很大不同，但 MySQL 仍然错误地将它标记为 latin。

为什么这可能会成为一个问题

MySQL的latin1编码允许数据库列存储任意数据，而不进行任何验证。这意味着latin1文本列可以存储任何字节序列，例如UTF-8编码的文本（每个字符使用可变数量的字节）或甚至JPEG图像（根本就不是文本）。

这当然不是latin1列的正确用途。即使在现代的Unicode意识世界中，所有处理文本的正确软件都应该使用UTF-8（或其他Unicode编码），但仍很常见会遇到错误配置的数据库或编写不良的软件。大多数应用程序在存储和检索数据时使用相同的（错误的）假设，因此在许多配置中，这仍然“正常工作”，问题可能长时间未被察觉。

使这个问题更加严重的是，MySQL默认使用latin1字符编码，这主要是出于历史和向后兼容性的原因。这意味着许多现实世界的数据库可能错误地配置为在MySQL的latin1编码的列中存储数据，尽管这些列中实际存储的数据根本不是使用latin1编码的。

这可能导致各种问题，例如编码或解码错误、双重编码的文本、字符串操作的故障或错误的截断，这些都可能导致数据损坏。在许多情况下，这表现为mojibake文本。这可能是由于对字节所代表的字符的误解，或者由于双重编码造成的，例如，一个备份脚本将一个转换为UTF-8的latin1列再次转换为UTF-8。

许多工具，如Python的内置文本编码解码器以及iconv（命令行工具和C库）都不能使用这种自定义MySQL编码转换数据。这使得“恢复”例如存储在latin1列中的UTF-8数据变得非常困难，即使你知道自己在做什么以及使用了哪种实际编码。

当在命令行上调用时，此脚本将转换命令行上指定的转储文件（如果没有给出文件，则为标准输入）。数据被解释为UTF-8，并编码为MySQL的latin1，然后写入标准输出。输出是原始数据，可能需要进一步处理，例如使用iconv“重新解释”数据（例如作为UTF-8）。