mysql3升级到mysql4乱码问题知识汇总(转载)

作者:Wupei  |  发表时间:  |  所属分类:网站开发

最近解决了mysql3与mysql4的乱码问题,先共享下文章,相关文章可以在 "网站开发类别" 中寻找

先转载两篇文章:

均来自: http://a-wei.net/

MySQL latin1 轉 utf8

相信 MySQL 的編碼對很多人來說 … 一直是個相當令人頭痛的問題 … 今天所要做的介紹是如何把資料庫的資料, 由 latin1 轉成 utf8..

一般 .. MySQL 裝起來後(用 rpm 安裝) ,系統的預設編碼是 latin1.

而很多人在安裝一些網頁的系統時,如 wordpress、LifeType、phpBB … 等等,都會選擇 utf8 。

這時 … 系統一樣可以正常運作 … 只是當用 phpmyadmin 進入管理資料庫時,就會發現 .. 怎麼中文字的部分都變成了歪七扭八 ..

或者一些鬼畫符的文字。如:????o??…?????·¥???è??èμ·

此現象就是 utf8 的文字以 latin1形式儲存,phpmyadmin 以 utf8 的資料讀取方式讀取 … 讀出來的資料就是這種鬼畫符…><。

若要解決 phpmyadmin 讀出的鬼畫符 … 有兩個方法:

1. 進入 phpmyadmin 內一個名為 libraries 的子目錄 .. 編輯 select_lang.lib.php. 找到 $mysql_charset_map 這一段下方 ..

‘utf-8′ => ‘utf8′,
把它改成

‘utf-8′ => ‘latin1′,

然後存檔 … 這時候就可以發現原先的鬼畫符 … 這時候又都正常了.

2. 把資料庫的編碼轉成 utf8 …

步驟:

a. 把資料庫 dump 出來

mysqldump -u xxx -p database > database.sql –default-character-set=latin1

這時候 dump 出來的 database.sql 是 latin1 的檔案格式,然而是 utf8 的文字資料,因此這時若用 vi 開檔看它 …

還是會發現中文字是鬼畫符 … 這時不要被眼前的假象所騙 … 以為自己做錯 .. 幾接著做下一步驟。

b. 把 dump 出來的 database.sql 下載回去 .. 用 emEditor(網路上可免費下載,是個支援 utf-8 的編輯器)把 database.sql 打開,

它可以正常識別 utf8 的文字 ..用取代的功能,把 latin1 都取代成 utf8 ,之後直接另存新檔 .. 這時把檔案類型設定儲存成 UTF-8。

c. 再把 database-utf8.sql 上傳到 server .. 這時我們用 vi 開啟它 .. 就可以看見是正常的中文字 .. 這就表示檔案沒問題囉。

d. 把檔案匯入資料庫

mysql database < database-utf8.sql -u xxx -p –default-character-set=utf8
如果資料量不是很大 … 那麼很快就可以完成這個步驟 .. 這時候若沒有錯誤訊息出現 .. 那麼恭喜你 ..

你已經完成了資料庫轉換的工作了。如果有錯誤訊息出現 .. 主要有兩個情形 ..

1. 文件檔內的中文字,用 vi 看是亂碼 ..文件檔的格式不是 utf-8。

2. 匯入的時候漏掉指定採用 utf8 的資料編碼匯入。

以上的作業是在 資料庫系統都是處於 latin1 的環境底下,也就是沒有在 my.cnf 指定 default-character-set=utf8。

—————————————–

你好,
我上去看了,是個 phpMyAdmin 的管理介面,這是代管系統嗎?
mysql 預設的編碼是 latin1_swedish_ci.

因此建議你,直接修改 phpMyAdmin 的預設編碼,改成 latin1。
而不要修改資料庫編碼。

因為即使你修改了資料庫編碼,但資料庫連線的編碼還是會使用 latin1.
到時你會落的兩邊都不是。

mysql 資料庫的編碼系統有三種類型。
1. 前端資料編碼 (網頁)
2. 資料庫連線編碼(網頁與資料庫的連線)
3. 資料庫儲存編碼(把資料儲存在資料庫內的編碼)

你現在的情況應該是這樣.
1. utf-8
2. latin1
3. utf8

前端資料是 utf-8 的編碼,但是在資料庫連線建立後轉成了 latin1 ,再儲存在 utf8 的資料庫內,因此存在 utf8資料庫內的「資料」是 latin1 編碼,而不是 utf8。

phpMyadmin 的管理程式的設定值是這樣

1. utf-8
2. utf8
3. don’t care
這也就是我前面所說得第一個方法,改 phpMyadmin 的編碼,指的就是改第2項。

要把第2項也改成 utf8 編碼的話,必需要在程式內 mysql_connect() 之後接著下這個命令「@mysql_query(’SET NAMES UTF8′)」
這是在你無法變更 mysql 系統的預設編碼狀態下,唯一能夠使用的方法。
也就是說,到時你要更改你 blog 系統內的資料庫連線,把這段程式碼加上去,才能完整的使用 utf8。

但是 … 如果現在就貿然的把 wordpress 資料庫連線編碼變更,新寫入的資料在phpMyadmin 會看的見正常編碼,但是舊的還是「亂碼」 ?

這也就是為什麼我會說,要先把資料庫的資料轉碼。
而轉碼的方法就是 telnet 或 ssh 到 server.. 直接下命令把資料庫 dump 出來,
轉碼之後再回存資料庫。

之後編輯 wordpress 目錄內的 wp-include\wp-db.php 這個檔案。
找到「
$this->dbh = @mysql_connect($dbhost, $dbuser, $dbpassword);」
在它下方加入這一行 ..
@mysql_query(”SET NAMES UTF8″);

然後儲存。
以上的程序可能很繁瑣,建議你比較簡單的方式是 wordpress 資料庫刪除重建,重新開始。
先把這行修正資料庫連線的語法加進去,就不用理會轉碼了。

case close.

 

—————————————-

乱码出现的一种情况(但非mysql3到mysql4乱码问题)

这种问题一般出现在服务器或mysql配置不当,甚至本身网页程序有问题,但关注一下也比较好

很多时候,浏览器并不按照指定的编码来显示页面。 导致乱码。其实这和http头中的内容协商机制有关系: Content-Type:
text/html; charset=utf-8 当http头中有这一行的时候,浏览器总是按照这个头指示的编码来显示页面内容,而忽略
tag中的设置。如果Meta和Content-Type
的charset一致时,一切都是正常的,而一旦不一样,那就会出现问题。而apache本身是可以通过AddDefaultCarset
XXX来来设置 http头中的默认字符编码,但是当apache和php在一起的时候,还有一个设置会影响这个http头的默认编码:
default_charset = “utf-8″ 而这个default_charset
的设置会覆盖apache的AddDefaultCarset配置,当然也可以在每个php里面手动调用
header(”content-type:text/html; charset=xxx”) 来覆盖default_charset
的值,这么看来一共有四个地方 会对php的执行结果产生影响: 优先级别从高到低:
php的header(”content-type:text/html; charset=xxx”)函数
php.ini里面的default_charset 设置 httpd.conf
中的AddDefaultCarset设置最后才是html代码中的:META tag
其实最简单的办法是把php.ini中的default_charset和httpd.conf中的AddDefaultCarset置空。通过Meta
tag来指定编码,header只是临时性的改变编码的最后关口。 

 

—————————————– 


[转载]apache+php 乱码问题解决
个人认为这个也不是mysql3-mysql4乱码问题,跟第一类相同

转载自:忘忧草

如果你在网上搜索 “apache配置”,搜到的页面大多都会建议你在httpd.conf中加上这么一句:AddDefaultCharset GB2312。对于新手而且是只用GB2312编码的开发人来说,这么做是ok的。

但是如果要想使用UTF-8字符集的话,比如 在test.php文件中需要有
meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″
这段代码。这时你再打开浏览器访问test.php页面的话,你看到的是正确的页面。但是如果实际上浏览器还是以GB2312编码解释从服务器返回的
response,为什么呢?原因是浏览器是根据http应答消息头部中的 Content-type: text/html;
charset=GB2312 来决定使用何种编码解释应答,也就是说apache服务器仍然用GB2312编码传递数据。

所以说如果apache的默认字符集被设置成了GB2312,即使在页面中声明使用UTF-8编码,apache服务器还是会按照GB2312编码来传送http response。

没关系,我们把AddDefaultCharset GB2312 改成 AddDefaultCharset
UTF-8,看看什么结果?如果你看到乱码恭喜你,你还知道是乱码问题;如果你看到是空白页面,那么你就惨了,你可能会以为这是其他什么原因造成的,而不
会从编码的角度去考虑怎么解决问题。这是为什么?

原因在于php文件本身是用系统字符集来编码的,中文的windows
XP都是用GB2312,每一个文件头部都有字段指示该文件是用何种方式编码的。当apache接到浏览器的请求后,会让php去解释所请求的页面,比如
test.php。php会识别出test.php的编码方式是GB2312后(就像我们用javac编译java源文件时,编译器默认用系统编码读源文
件里的内容。如果源文件不是用系统编码来保存的,可以用命令javac
-encoding指定具体的编码),把数据以GB2312的编码格式传递给apache,而apache服务器不会改变从php传来的数据,只是在应答
消息头部中把字符集设置成UTF-8: Content-type: text/html; charset=UTF-8.
也就是说你传递的是GB2312编码的数据,而浏览器却以UTF-8编码来解释应答消息。

由于UTF-8为3个字节表示一个汉子,而普通的GB2312或BIG5是两个。页面输出时,由于上述原因,出现半个汉字的情况,这时该半个汉字会
和的 >结合成一个乱码字,导致IE无法读完的话,会发现实际上整个叶面全部已经输出了。如果使用的是Mozilla、Mozilla
Firefox、Sarafi的浏览器这不会造成这个问题,而是一堆乱码。这是由于Firefox浏览器和IE解析网页编码的策略不同产生的。

OK,我们把test.php以UTF-8保存,再用浏览器访问时,就没有问题了。可这样做,会使得apache目录下的所有web应用只能用同一种编码。如何搞定?

解决办法:

首先,可以使用AddDefaultCharset
off来关闭默认文件编码,这样apache服务器就不会在http应答消息头部设置charset,只是设置Content-type:
text/html.
而浏览器就会依靠html文件中设置的harset来决定编码。其次,脚本php.ini文件中的default_charset =
“UTF-8″作用同httpd.conf文件,把该行注释掉,使php自动识别文件的编码方式。

这样不论你用什么编码方式,只要test.php中的
meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ 与你test.php文件编码方式相同,就不会产生乱码问题。

用户提交数据的编码

浏览器提交的字符编码由客户端的characher
encoding决定。例如,当前浏览器的编码是Gb2312,用户提交数据后,无论apache设置的编码方式是GB2312还是UTF-8,这时在服
务器端接收到的仍是以Gb2312编码的数据。如果要在返回页面上显示用户刚才提交的数据,而该页面是用UTF-8编码的,或者要在数据库中存储的用户提
交的数据,而数据库是UTF-8编码的,那就要做字符转换了。

 

Trackback from your site.

请在这里留言: