在MySQL导出/导入中丢失特殊字符

我试图将MySQL 3.23.58数据库移动到运行5.5.19的不同服务器。在MySQL导出/导入中丢失特殊字符

旧的具有latin1编码指定，并且据我所知底层数据的确是老实拉丁。我已经尝试了很多东西，主要是：

从终端输出mysqldump和latin1编码标志。
在vim中编辑将“TYPE = InnoDB”更改为“ENGINE = InnoDB”以实现MySQL 5的兼容性。
从终端导入到新的服务器。

浏览旧服务器（在续集的Mac Pro，或MySQL查询在PC浏览器），特殊字符不会总是显示正常，但他们在那里（看着十六进制二进制）。（在任何情况下，它都适用于PHP Web应用程序。）

浏览新服务器时，所有特殊字符似乎都被问号所代替。我知道如果指定了错误的编码，有时候特殊字符会显示为问号（或）。但是这些似乎是二进制级别的真正的直接编码的ASCII问号。在出口/进口中，特殊字符（主要是曲线的引号和破折号）似乎已经丢失或被破坏。

任何想法为什么？

我知道有许多事情可能会出错编码，有很多不同的事情有错。我已经阅读了几天（在这里和其他地方），并尝试设置所有正确的字符编码，尝试UTF-8，尝试铸造和转换，尝试过Sequel Pro的导出/导入（而不是终端）等。我很难过。

来源

2012-06-25 Toph

如果您导出为SQL语句，您是否看到相同的问题？从你的问题，它听起来像导出的文件是好的（你已经在十六进制编辑器），但这是导致问题的导入。我无法明白为什么SQL INSERT语句会失败，如果它是磁盘上的纯文本文件并且所有字符都以UTF-8或latin1表示。试一下你遇到的一条记录。 – Brad

这是一个撇号（或右单引号）看起来像在VIM（截图）导出的文件：http://cl.ly/1C2m0d1M2y0g1J1C3d0P - 一个<92>。那是一种vim有向图吗？（？Quadgraph）这里并不匹配任何东西：http://vimdoc.sourceforge.net/htmldoc/digraph.html#digraph-table – Toph

而且一个破折号显示为<97>。 – Toph

好，看起来我们已经缩小了您的问题。我发现this post

如果你的文本编辑器VIM，那么最有可能的“< 92>”是一个扩展ASCII字符的十六进制代码。在这种情况下，它是“右单引号标记”的十六进制（92）或十月（222）或十二月（146）的 ;不要混淆“单引号”，这是ASCII码十二月删除所有非ASCII字符从您的文件可能是39

一种方式 -

perl -plne 's/[^[:ascii:]]//g' <your_file>

否则只是搜索和替换“< 92>”和“< 97>”，并带有适当的字符。

[编辑]

我不是一个VIM用户，但这篇文章解决了replacing the <92> smart quote characters

问题对于每个您在文件中看到价值，只是做一个字符串替换，像这样：

:%s/<93>/\’/g
当然
，你不能只键入< 93>在那里，所以得到它在有您使用

CTRL-V X 93

其插入六角93到位。

在最近从excel中导出的CSV文件中，我看到了十六进制的91-97。

来源

2012-06-26 09:35:50 Brad

感谢您的帮助布拉德。不幸的是，删除所有非ASCII字符不是一个选项。搜索和替换可以工作，但我还没有弄清楚它如何在vim中使用扩展的ASCII字符。如果我只输入<92>等，就找不到它们。 – Toph

[编辑]评论：啊，非常好，非常感谢！我也不得不设置文件编码在vim中UTF8它保存（也许这一直都被一个问题吗？我认为我会照顾它），并确保集名称“UTF8”为MySQL，但固定关键在于它。看起来不错。 – Toph

在MySQL导出/导入中丢失特殊字符

回答

相关问题