1

我最近工作的一个网站的数据库出现了问题，显然当他们恢复表时，它被损坏了任何带有奇怪符号（例如半符号和度数符号）的文本字段，文本字段在该符号之前的字符处停止）。我有一份表格，并将其提炼成以下代码：

    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 来恢复它我不知道这是否有区别。

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

4

1 回答 1

5

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

DPM 912 是大 3? 数字

谷歌搜索“DPM 912”的一点点向我表明，字符应该是粗俗的二分之一分数，½。

许多字符集使用 byte 对该字符进行编码0xBD，但有一个特别突出：windows-1252——这不仅是（Unicode 之前的）Windows 世界中的默认代码页，而且还是MySQL 的默认编码。您的数据以windows-1252.

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

字符串文字可能有一个可选的字符集介绍器和COLLATE子句：

[_charset_name]'string' [COLLATE collat​​ion_name]

它接着说：

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

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

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

该文档还指出：

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

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

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

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

我的建议是让转储文件尽可能可移植，将其添加SET NAMES 'latin1'到它的顶部。

于 2012-05-02T15:48:23.863 回答