centos 7 網站前端中文亂碼分析、解決辦法

2019-03-28html


 

一、網站前端中文文字亂碼主要緣由有兩點:前端

 (1)mysql數據庫內部存儲的數據自己處於亂碼狀態java

 (2)前端與數據庫傳輸數據的字符集與數據庫內部字符集不一致致使mysql

二、查找形成中文亂碼緣由android

  登陸數據庫,查看數據庫編碼 ios

mysql> SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
| collation_connection     | latin1_swedish_ci          |
| collation_database       | utf8_general_ci            |
| collation_server         | utf8_general_ci            |
+--------------------------+----------------------------+
11 rows in set (0.01 sec)

  以上須要咱們注意的參數有五個,分別是如下參數:sql

character_set_client             #主要用來設置客戶端使用的字符集。
character_set_connection         #主要用來設置鏈接數據庫時的字符集,若是程序中沒有指明鏈接數據庫使用的字符集類型則按照這個字符集設置。
character_set_database           #主要用來設置默認建立數據庫的編碼格式,若是在建立數據庫時沒有設置編碼格式,就按照這個格式設置。
character_set_results            #數據庫給客戶端返回時使用的編碼格式,若是沒有指明,使用服務器默認的編碼格式。
character_set_server             #服務器安裝時指定的默認編碼格式,這個變量建議由系統本身管理,不要人爲定義。

  (1)查看使用的數據庫的表格內中文字符是否亂碼數據庫

  (2)查看鏈接數據庫代碼使用哪一種字符集,是否與character_set_client;character_set_results ;character_set_connection一致服務器

  而後排查緣由post

三、解決網站中文亂碼

  首先,查看已經建立的數據庫使用的默認字符集

mysql> select schema_name,default_character_set_name from information_schema.schemata where schema_name = 'test03';
+-------------+----------------------------+
| schema_name | default_character_set_name |
+-------------+----------------------------+
| test03      | utf8                       |
+-------------+----------------------------+
1 row in set (0.00 sec)

  假如默認字符集不支持utf8編碼,也就是數據庫內的中文顯示亂碼,建議從新建立默認字符集爲utf8的數據庫,不然以後插入的中文數據仍然是亂碼。如下是建立默認字符集爲utf8的數據庫命令

mysql> create database if not exists test03 default character set = 'utf8';
Query OK, 1 row affected (0.00 sec)

  假如數據庫支持的默認字符集是utf8,那就修改數據庫配置文件/etc/my.cnf內的如下參數

在[client]下添加

default-character-set=utf8

  而後重啓數據庫便可。固然,有不少文章修改的參數要多一個,以下

編輯/etc/my.cnf

在[mysqld]下添加

default-character-set=utf8

在[client]下添加

default-character-set=utf8

  爲何咱們修改的參數要比較少呢,讓咱們實際分析一下

mysqld 下的default_character_set=utf8;,這個須要嗎?答案是不須要

它的做用是:當啓動mysqld時,根據使用的初始選項設置來肯定服務器字符集和 校對規則。可使用--default-character-set設置字符集;

若是在CREATE TABLE語句中沒有指定表字符集和校對規則,則使用數據庫字符集和校對規則做爲默認值。默認數據庫的字符集和校對規則能夠用做character_set_database和 collation_database系統變量。不管什麼時候默認數據庫更改了,服務器都設置這兩個變量的值。若是沒有 默認數據庫,這兩個變量與相應的服務器級別的變量(character_set_server和collation_server)具備相同的值。

大白話就是:若是你建表的時候沒有指定字符編碼,則會使用character_set_database,若是character_set_database也沒有設值,則使用character_set_server

client 下的default_character_set=utf8; 它是須要的,但是它的做用是幹嘛的?

它的做用等同執行如下3個命令

SET character_set_client = utf8

SET character_set_results = utf8;

SET character_set_connection = utf8;

 

這3個參數的做用以下

 

  以上修改以後,基本不會出現中文亂碼了,可是也有例外狀況,那麼遇到例外狀況,該怎麼作呢?

  這就要咱們在配置Connection URL時,加上?useUnicode=true&characterEncoding=utf-8,這個配置有什麼做用呢?

它的做用就是指定character_set_client和character_set_connection的值,而在jdbc連接中使用characterSetResults=UTF-8,便可設置character_set_results的值

可是如上所述,當你配置了client的default_character_set以後,characterEncoding和characterSetResults這兩個變量你設置與否都不重要了。

  因此咱們能夠作一個結論:

  遇到中文亂碼問題

  若是你只願意配置服務器的話:

  在[client]下添加

  default-character-set=utf8便可

  若是你只願意配置客戶端的話:

  你可使用jdbc:mysql://localhost:3306/test? characterEncoding=UTF-8&characterSetResults=UTF-8便可

四、已有的庫和表更改成utf8

  以上的修改只對咱們修改完成以後創建的數據庫生效,對於已有的庫和表是不產生影響的,須要咱們單獨進行轉換

#更改數據庫編碼:
ALTER DATABASE 數據庫名 CHARACTER SET utf8 COLLATE utf8mb4_general_ci;

#更改表編碼:
ALTER TABLE 表名CONVERT TO CHARACTER SET utf8 COLLATE utf8mb4_general_ci; 
若有必要,還能夠更改列的編碼

 

五、utf8與utf8mb4的區別(轉載文章:https://www.cnblogs.com/beyang/p/7580814.html) 

  MySQL在5.5.3以後增長了這個utf8mb4的編碼,mb4就是most bytes 4的意思,專門用來兼容四字節的unicode。好在utf8mb4是utf8的超集,除了將編碼改成utf8mb4外不須要作其餘轉換。固然,爲了節省空間,通常狀況下使用utf8也就夠了。

  內容描述

   那上面說了既然utf8可以存下大部分中文漢字,那爲何還要使用utf8mb4呢? 原來mysql支持的 utf8 編碼最大字符長度爲 3 字節,若是遇到 4 字節的寬字符就會插入異常了。三個字節的 UTF-8 最大能編碼的 Unicode 字符是 0xffff,也就是 Unicode 中的基本多文種平面(BMP)。也就是說,任何不在基本多文本平面的 Unicode字符,都沒法使用 Mysql 的 utf8 字符集存儲。包括 Emoji 表情(Emoji 是一種特殊的 Unicode 編碼,常見於 ios 和 android 手機上),和不少不經常使用的漢字,以及任何新增的 Unicode 字符等等。

  問題根源

   最初的 UTF-8 格式使用一至六個字節,最大能編碼 31 位字符。最新的 UTF-8 規範只使用一到四個字節,最大能編碼21位,正好可以表示全部的 17個 Unicode 平面。

   utf8 是 Mysql 中的一種字符集,只支持最長三個字節的 UTF-8字符,也就是 Unicode 中的基本多文本平面。

   Mysql 中的 utf8 爲何只支持持最長三個字節的 UTF-8字符呢?我想了一下,多是由於 Mysql 剛開始開發那會,Unicode 尚未輔助平面這一說呢。那時候,Unicode 委員會還作着 「65535 個字符足夠全世界用了」的好夢。Mysql 中的字符串長度算的是字符數而非字節數,對於 CHAR 數據類型來講,須要爲字符串保留足夠的長。當使用 utf8 字符集時,須要保留的長度就是 utf8 最長字符長度乘以字符串長度,因此這裏理所固然的限制了 utf8 最大長度爲 3,好比 CHAR(100)  Mysql 會保留 300字節長度。至於後續的版本爲何不對 4 字節長度的 UTF-8 字符提供支持,我想一個是爲了向後兼容性的考慮,還有就是基本多文種平面以外的字符確實不多用到。

   要在 Mysql 中保存 4 字節長度的 UTF-8 字符,須要使用 utf8mb4 字符集,但只有 5.5.3 版本之後的才支持(查看版本: select version();)。我以爲,爲了獲取更好的兼容性,應該老是使用 utf8mb4 而非 utf8.  對於 CHAR 類型數據,utf8mb4 會多消耗一些空間,根據 Mysql 官方建議,使用 VARCHAR  替代 CHAR。

參考文章:

https://www.cnblogs.com/beiyeren/p/3835412.html

https://blog.csdn.net/javandroid/article/details/81235387

相關文章
相關標籤/搜索