问题描述
旧服务器db = MySQL v4.0.21新服务器db = MySQL v5.0.45
Old server db = MySQL v4.0.21New server db = MySQL v5.0.45
我正在将一个应用程序移至新服务器，并复制了数据库.
I am moving an app to a new server, and I copied over the database.
该应用程序会发送当天的议程，并且每当有双人和时；单引号 " '，它们显示为问号?
The app sends an agenda for the day and whenever there are double & single quotes " ', they show up as question marks ?
在被转移到的服务器上是这样出现的?种族恐怖:HBO?的真爱?
这是基于原始服务器应用程序的外观:种族恐怖:HBO 的真爱"
This is what it looks like on the original server app was built on: "The Horror of Race: HBO’s True Blood"
带有 phpmyadmin 的数据库截图 http://grab.by/2EsU(原始服务器 mysql v4.0.21) 和 http://grab.by/2EtN(新服务器 mysql 5.0.45)
Screenshot of database w/i phpmyadmin http://grab.by/2EsU (original server mysql v4.0.21) and http://grab.by/2EtN (new server mysql 5.0.45)
数据存储表的屏幕截图:http://grab.by/2Et2(仅发生在 body 列中)
Screenshot of table the data is stored within: http://grab.by/2Et2 (it only happens w/i the body column)
新服务器表中数据的屏幕截图:http://grab.by/2Etb(您将注意问号?)
Screenshot of data within new server table: http://grab.by/2Etb (you'll notice the question marks ?)
原始服务器表中的数据截图:http://grab.by/2Etl
Screenshot of data within original server table: http://grab.by/2Etl
该应用程序是用 PHP 构建的，它会像 nl2br($body);
The app is built w/ PHP, and it prints the body like nl2br($body);
字符串在插入数据库表之前与 $body 变量一起存储，如下所示:$body=addslashes($_POST['body']);
The string is stored w/i the $body variable before being inserted into the db table, like this: $body=addslashes($_POST['body']);
有关为什么显示 的任何帮助?用双引号和单引号代替标记会有所帮助 - 非常感谢.
Any help as to why it is displaying the ? marks in the place of double and single quotes, would be helpful - much appreciated.
推荐答案
这很可能是由于字符编码设置的不同造成的.这可能在几个地方有效.我建议您登录两台服务器并执行以下操作:
Thhis is most likely due to a difference in character encoding settings. This may be in effect in a couple of places. I would advise you to log into both servers and do:
mysql> show variables like '%character%';
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | D:\Servers\MySQL\MySQL_5_1_36\share\charsets\ |
+--------------------------+-----------------------------------------------+
8 rows in set (0.00 sec)
看看你有没有发现那里有什么不同.例如，如果新服务器的默认连接字符集不同，您可能会得到这些结果.
See if you see any difference there. For example, if the default connection characterset is different for the new server, you could get these results.
您还应该确保列的字符编码设置:执行 SHOW CREATE TABLE <table-name> 并检查列级别的字符集是否仍然相同mysql>
You should also ensure the character encoding settings for the columns: do a SHOW CREATE TABLE <table-name> and check if the character sets are still the same at the column levelmysql>
编辑或者，正如 Martin 在评论中指出的那样，您可能正在处理以您没有预料到的编码方式编码的 SQL 转储.这里有更多相关信息:http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_default-character-set.在这种情况下，您可以尝试使用 iconv (http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html)
EDITAlternatively, as Martin pointed out in the comments, you could be dealing with a SQL dump that is encoded in an encoding you didn't anticipate. Here's some more information on that: http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_default-character-set. In this case you could try to re-encode the dump file using a tool like iconv (http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html)
这篇关于数据库编码问题?双引号和单引号显示带问号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！