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来恢复它我不知道是否有所作为。< / p>

如果无法导入数据，我会很高兴有人能告诉我如何将编码数据读入文本，然后我可以手动剪切和粘贴。

Answer 1

将前32个字节解码为ASCII，我们有（其中?是MySQL抱怨的0xBD字节）：

The DPM 912 is a large 3? Digit

一点点谷歌搜索“DPM 912”suggests to me该角色应该是粗俗的一半，½。

A number of character sets使用字节0xBD编码该字符，但特别是跳出一个字符：windows-1252 - 这不仅是（前Unicode）Windows世界中的默认代码页，但也是MySQL's default encoding。我们很好地猜测您的数据是以windows-1252编码的。

如the MySQL manual中所述，您可以通过在其前面加上编码名称来指定字符串文字的编码：

字符串文字可能有一个可选的字符集介绍人和COLLATE子句：
[_charset_name]'string' [COLLATE collation_name]

接着说：

在标准十六进制文字和数字十六进制文字符号（x'literal'和0xnnnn）之前，或者在位字段文字符号（b'literal'和0bnnnn之前，介绍人也是合法的）。

因此（并且因为MySQL将windows-1252称为latin1），您可以将INSERT命令更改为：

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

文档还说明：

对于简单语句SELECT 'string'，字符串具有由character_set_connection和collation_connection系统变量定义的字符集和排序规则。

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

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

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

我的推荐，即使转储文件尽可能可移植，将SET NAMES 'latin1'添加到其顶部。

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

1 个答案: