MySQL 无法从备份中恢复表 - #1366 - 不正确的字符串值

Question

我最近工作的一个站点的数据库出现问题，显然当他们恢复表格时数据库已损坏任何带有奇怪符号(例如半符号和度数符号)的文本字段文本字段停止在该字符之前象征)。我得到了该表的副本并将其提炼为以下代码:

    CREATE TABLE `products2` (
      `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
      `description` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
      PRIMARY KEY (`id`)
    ) DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


    insert  into products2 values  
(25, 0x5468652044504D203931322069732061206C617267652033BD204469676974204C434420566F6C746D657465722E20546865207369676E616C206265696E67206D6561737572656420697320616C736F207573656420746F20706F77657220746865206D657465722C20696E636C7564696E6720746865206261636B6C696768742E20546865206D657465722066656174757265732061203320746F20363056206D6561737572656D656E742072616E67652C20776974682061207265736F6C7574696F6E206F662031306D56206265747765656E20332E303020616E642031392E39395620616E64203130306D56206265747765656E2032302E3020616E642036302E30562E205768656E2074686520766F6C746167652064726F70732062656C6F772033562C204C4F20697320646973706C617965642028646F776E20746F20322E38562C207768656E2074686520646973706C61792077696C6C207475726E206F6666292E209148499220697320646973706C61796564207768656E2074686520766F6C7461676520676F65732061626F7665203630562E0D0A0D0A5363726577207465726D696E616C7320616C6C6F7720666F7220717569636B20616E64206561737920636F6E6E656374696F6E2E20546865206D6574657220697320686F7573656420696E206120726F6275737420636172726965722077686963682063616E20626520626F6C74656420696E20706C616365206F722070616E656C206D6F756E746564207573696E6720746865206C6F772070726F6669206C652062657A656C20616E6420636C6970732070726F76696465642E20416E2049503637202F204E454D412034582062657A656C20697320616C736F20617661696C61626C6520666F722070726F74656374696F6E20616761696E7374206475737420616E64206D6F6973747572652E0D0A0D0A417320746869732069732061206E65772064657369676E2077652073756767657374207468617420796F7520636F6E74616374204C617363617220666F7220757020746F2064617465206C6561642D74696D6520696E666F726D6174696F6E206265666F7265206F72646572696E67206F6E6C696E652E0D0A)

这会引发错误:

#1366 - Incorrect string value: '\xBD Digi...' for column 'description' at row 1 

在 stackoverflow 和网络上调查这个问题似乎是编码问题，我尝试将描述字段上的排序规则更改为 utf_unicode_ci 并将表的排序规则更改为 utf_bin(以及这些的所有组合) 都无济于事。

我无法重做转储，因为它是备份。我不明白系统如何输出转储但不接受它 - 大概是通过命令行进行备份(不确定)并且我正在使用 PHPMyAdmin 来恢复它我不知道这是否有所作为。

如果无法导入数据，请告诉我如何将编码数据读入文本，然后我可以手动剪切和粘贴，我将不胜感激。

Answer 1

将前 32 个字节解码为 ASCII，我们得到(? 是 MySQL 提示的 0xBD 字节):

The DPM 912 is a large 3? Digit 

A little bit of Googling for "DPM 912" suggests to me that character should be the vulgar one-half fraction, ½.

A number of character sets encode that character with the byte 0xBD, but one in particular jumps out: windows-1252—which was not only the default codepage in the (pre-Unicode) Windows world, but is also MySQL's default encoding. It'd be a good guess that your data is encoded in windows-1252.

As explained in the MySQL manual, you can specify the encoding of a string literal by prefixing it with the encoding name:

A character string literal may have an optional character set introducer and COLLATE clause:

[_charset_name]'string' [COLLATE collation_name]

It goes on to say:

An introducer is also legal before standard hex literal and numeric hex literal notation (x'literal' and 0xnnnn), or before bit-field literal notation (b'literal' and 0bnnnn).

Therefore (and because MySQL refers to windows-1252 as latin1), you could change your INSERT command to:

INSERT INTO products2 VALUES (25, _latin1 0x5468652044504D203931322069...);

文档还指出:

For the simple statement SELECT 'string', the string has the character set and collation defined by the character_set_connection and collation_connection system variables.

也就是说，如果省略了这样的介绍人(就像在您的原始 INSERT 语句中一样)，则假定字符集是由 character_set_connection 系统定义的变量。

如前所述here ，有多种设置该变量的方法(包括在客户端连接时指定它，在 phpMyAdmin 中，使用 [DefaultCharset] 配置选项设置，在 v3 之前默认为 latin1 .4，但从那以后一直是 utf8 - 也许这一变化是您问题的根源；您还可以使用 [Import][charset] 指定导入文件的字符集。如果在连接时没有指定所需的字符集，则在连接之后但在 INSERT 命令之前发出这些命令中的任何一个都会修复它(例如，您可以将其中一个添加到你的转储文件):

SET NAMES 'latin1';
SET CHARACTER SET latin1;
SET character_set_connection = latin1;

我的建议是在其顶部添加 SET NAMES 'latin1'，这使得转储文件尽可能可移植。