mysql - MySQL中的unicode字段在哪里出错？

Question

我的MySQL数据库中有一个包含字符串的字段表。
MySQL版本是5.0.51a。表的默认字符集是“utf8”。
许多字符串都有unicode字符，如\xae和\u21222（分别是注册符号和商标符号）。
例如，假设我有一行的字段值为：

"Bing® Blang™ Blaow"

mysql命令行客户机的默认字符集是“latin1”。
如果我从命令行在mysql客户机程序中发出一个SELECT语句，而不指定字符集，则标题的输出如下所示：

"Bing® Blang Blaow"

（R）符号正确，但（TM）符号丢失。如果我将这个字符串从控制台剪切并粘贴到TextMate中，就会出现（TM）符号，但它位于单词“Blang”中g的中间位置。
我认为g的后半部分只是TextMate中的一个显示错误（尽管如果有人能提供更多的细节那就太好了，但这并不是真正重要的部分）。
在剪切和粘贴行为之后，我从its-there推断出的主要问题是数据在数据库中，但是某些字符集设置有问题。
如果我在命令行中重写mysql客户机的默认编码，如下所示：

mysql --default-character-set=utf8 

然后执行相同的选择，字符串将显示为：

"Bing® Blang™ Blaow"

也就是说，（R）和（TM）符号都出现在正确的位置，但都前面是unicode字符xae，它是一个A，顶部有一个扬抑符。
（顺便说一下，当我使用python将数据提取出来并显示在web页面上时，数据也是这样显示的，这就是我真正的问题所在）。
不管怎样，这是怎么回事？我们最近所做的一切都尽可能地使用了UTF8，但其中一些行可能是在更改之前插入的，这意味着它们将使用latin1默认值。。。然而，这两种编码似乎都不能产生正确的结果？
如果在切换到utf8之前，当表上的默认编码是latin1时插入了行，那么编码被切换（通过alter table..），那么编码实际上是否已经更新？其中一个编码现在应该工作了吗？unicode会不会不再踢我的屁股？

Answer 1

这里有很多问题：
关于角色
表示文本包含字符U+AE和U+2122（分别为？和？）。然而，结果暗示文本中有U+99作为“Blang”之后的字符：当您将MySQL设置为输出UTF8时，您会看到这个“the™”--这是U+99的UTF8序列，显示在将这个字节流解释为Windows-1252的终端上。
U+99可能不是您想要的：在Unicode中，这是一个没有图形表示的扩展控制字符。恰好在Windows-1252中，0x99是商标符号（U+2122）的编码。
（请注意，当您选择Latin1时，MySQL和大多数web浏览器都有使用Windows-1252的常见“坏”行为。叹气。）
可能是什么问题
你的终端没有在正确的字符集中运行。它显然是在Windows-1252中运行的。
程序应该用UTF-8连接到数据库。如您所发现的，您可以在命令行中执行该操作，或者在执行其他操作之前在数据库句柄中执行SET NAMES utf8_general_ci;语句。一些其他的数据库api可能有其他的方法来实现这一点，但是对于所有的SQL引擎没有通用的方法。SET NAMES ...是MySQL特有的，但设置了所有必需的字符集变量（共有三个！）马上。
将数据插入数据库的进程正在接受用户输入，但在插入之前无法将其从Windows-1252正确转换为UTF-8。这就是你把U+99输入数据库的方法。因为我不知道你是怎么得到这些数据的，所以我不知道该修复什么，但是有几种可能性：
如果数据来自网页表单，请确保表单所在的页面以UTF-8格式提供服务，并正确标记为UTF-8格式（通过MIME类型和<meta>标记）。此外，请确保<form>标记没有指定不同的字符集。
转换数据时，请确保使用iconv或类似的库将输入字符集转换为UTF-8。即使您认为输入是拉丁语1，也不要尝试手动执行此操作（例如，将每个字节零扩展为16位，然后声明这是UTF-16，这对Windwos-1252不起作用！）。请绝对确保您知道源数据的字符集。特别是，一定要知道它是Latin1还是Windows-1252。
不用转换用户输入，您可以在用户输入的字符集中连接到数据库，然后插入从用户获得的原始字节数据。但是，您必须确保仅以这种方式执行插入：如果其他行的数据不能在该字符集中表示，则从具有用户有效字符集的数据中读取数据将丢失信息。可以设置MySQL连接，以便在一个字符集中发出语句并在另一个字符集中读取结果。。。但这并不是为胆小的人准备的，未来的程序员可能会疯狂地试图理解代码为什么会这样做。
如果，当您使用Python拉出数据并将其显示在web页面中时，您看到了字符串“then”，那么这表示您将数据正确地作为UTF-8从数据库中拉出，但随后将其放入一个未正确标识为UTF-8的web页面中。可能它只是默认为Latin1，正如上面提到的，它将真正是Windows-1252。
尽管如此，即使修复了显示，也要注意数据库中有错误的数据，因为U+99实际上不是UTF-8列中的商标符号。如果数据是Windows-1252，则需要通过读取所有数据并将U+80到U+9F范围内的任何字符替换为它们可能是的字符来清理数据。如果您不确定数据最初的字符集是什么——那么这些数据只是垃圾。
关于更改表的字符集
在插入数据后转换字符集和表的排序规则将转换列，但是，当然，任何已经插入的数据都已经丢失了原始字符集不能表示的任何字符。
请注意ALTER TABLE foo CONVERT TO CHARACTER SET ...和ALTER TABLE foo CHARACTER SET ...之间的区别，后者只更改表的默认字符集，并且不会更改任何列，即使它们在创建时设置为默认值。（MySQL只在列创建时使用默认值，它不记得给定的列是“默认”的，而不是保持与表的默认值同步。）