phputf8mb4

Ⅰ thinkphp5 連訪問資料庫時報錯utf-8編碼錯誤

thinkphp5連訪問資料庫時報錯utf-8編碼錯誤，出現中文亂碼的原因就是字元編碼不統一，出現中文亂碼需要添加如下代碼。

在D:phpStudyPHPTutorialMySQL下的my.ini中的mysqld下加如下語句：

character-set-server = utf8mb4

collation-server = utf8mb4_unicode_ci

示例代碼如下：

(1)phputf8mb4擴展閱讀：

thinkphp5 連訪問資料庫時報錯utf-8編碼錯誤可能出錯的地方：

1. 代碼文件（判斷查看文件編碼的最簡單的辦法是：用記事本打開，然後點擊「另存為」，出現的窗口下方有「編碼」字樣，若不是你想要的編碼，改為你的編碼後保存覆蓋原來的文件即可）。

2. html 文件頭部應加上 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ，把 utf-8 改為你要同意的編碼即可。

3. 資料庫連接代碼應選擇對應字元編碼，mySql 的選擇字元編碼的代碼為：mysql_query("SET NAMES 'utf-8';"); 其他資料庫的代碼請自行查詢。

4. 後台程序代碼 php 需要註明字元編碼，header('Content-Type:text/html。

Ⅱ MySQL為什麼使用utf8mb4還會亂碼，插入數據還是報錯

伺服器端
修改資料庫配置文件/etc/my.cnf
character-set-server=utf8mb4
collation_server=utf8mb4_unicode_ci
重啟MySQL（按照官方文檔，這兩個選項都是可以動態設置的，但是實際的經驗是Server必須重啟一下）
已有的表修改編碼為utf8mb4
ALTER TABLE
tbl_name
CONVERT TO CHARACTER SET
charset_name；
使用下面這個語句只是修改了表的default編碼
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4;
客戶端
jdbc的連接字元串不支持utf8mb4，這個 這種方式 來解決的，如果伺服器端設置了character_set_server=utf8mb4，則客戶端會自動將傳過去的utf-8視作utf8mb4。
Connector/J did not support utf8mb4 for servers 5.5.2 and newer.
Connector/J now auto-detects servers configured with character_set_server=utf8mb4 or treats the Java encoding utf-8 passed using characterEncoding=... as utf8mb4 in the SET NAMES= calls it makes when establishing the connection. (Bug #54175)
其他的client端，比如php、python需要看下client是否支持，如果不能在連接字元串中指定的話，可以在獲取連接之後，執行」set names utf8mb4″來解決這個問題；
因為utf8mb4是utf8的超集，理論上即使client修改字元集為utf8mb4，也會不會對已有的utf8編碼讀取產生任何問題。

Ⅲ xampp-win32-1.7.4-VC6 中phpmyadmin mysql 資料庫中字元集 utf8mb4是啥玩意，和utf8有啥區別謝謝

以下是官方說明，大概意思是UTF8存儲每個字元最大使用3個位元組，而utf8mb4存儲每個字元 最大可以使用4個位元組。有些UTF8無法存儲的utf8mb4就可以。下面的英文可以自己再看一下
The utf8mb4 Character Set (Four-Byte UTF-8 Unicode Encoding)

The character set named utf8 uses a maximum of three bytes per character and contains only BMP characters. As of MySQL 5.5.3, the utf8mb4 character set uses a maximum of four bytes per character supports supplemental characters:

•
For a BMP character, utf8 and utf8mb4 have identical storage characteristics: same code values, same encoding, same length.
•
For a supplementary character, utf8 cannot store the character at all, while utf8mb4 requires four bytes to store it. Since utf8 cannot store the character at all, you do not have any supplementary characters in utf8 columns and you need not worry about converting characters or losing data when upgrading utf8 data from older versions of MySQL.

Ⅳ PHP怎麼處理移動端提交的表情字元

需設置 mysql 的字元集為 utf8mb4
在實行sql server 向 mysql 遷移數據時，報錯：
Incorrect string value: '\xF0\x9F\x98\x8A'
原因是mysql 採用的是 utf8 的字元集，而該字元集最多佔用三個位元組，而一些 表情 需要佔用 4個位元組，所以需要將 utf8 改成 utf8mb4。
原始配置為：
#mysql 5.5 新增參數
character_set_server=utf8
collation_server=utf8_bin
我將 character_set_server=utf8 改為：character_set_server=utf8mb4，重啟mysql 卻報錯：
發生系統錯誤 1067 進程意外終止
但是查看錯誤日誌，卻沒有顯示是什麼錯誤信息。有倒騰了一會兒，想到是不是 collation_server 也要修改成 utf8mb4_bin，測試的結果果然如此。
所以要注意在將 MySQL字元集 utf8 改為 utf8mb4 時，一定要注意 collation_server 也要同時修改！
乾脆將 default-character-set=utf8mb4 也改成了算了。
最後的字元配置如下：
[mysql]
default-character-set=utf8mb4
init_connect='set names utf8mb4'
[mysqld]
character_set_server=utf8mb4
collation_server=utf8mb4_bin
修改之後，啟動成功。

Ⅳ php 怎麼處理 emoji表情

1、使用utf8mb4字元集
如果你的mysql版本>=5.5.3，你大可直接將utf8直接升級為utf8mb4字元集
這種4位元組的utf8編碼可完美兼容舊的3位元組utf8字元集，並且可以直接存儲emoji表情，是最好的解決方案
至於位元組增大帶來的性能損耗，我看過一些評測，幾乎是可以忽略不計的
2、使用base64編碼
如果你因為某些原因無法使用utf8mb4的話，你還可以使用base64來曲線救國
使用例如base64_encode之類的函數編碼過後的emoji可以直接存儲在utf8位元組集的數據表中，取出時decode一下即可
3、幹掉emoji表情
emoji表情是個麻煩的東西，即使你能存儲，也不一定能完美顯示。在iOS以外的平台上，例如PC或者Android。如果你需要顯示emoji，就得准備一大堆emoji圖片並使用第三方前端類庫才行。即便如此，還是可能因為emoji圖片不夠全而出現無法顯示的情況在大多數業務場景下，emoji也不是非要不可的。我們可以適當地考慮幹掉它，節約各種成本
經過一番苦苦的google，終於找到靠譜能用的代碼：

Ⅵ php存入emoji表情出現亂碼，資料庫已經改為utf8mb4編碼了依然亂碼

你插入數據的時候寫的insert中欄位數據的編碼不對。你要轉換成相應的字元編碼才可以的。
<?php
header("Content-type:text/html;charset=utf8");
//你的代碼
//也可以用notepad++將文件格式改為UTF8
?>

插入資料庫需要
1
mysql_query("SET NAMES UTF8");

Ⅶ 登陸phpmyadmin總是出現這個問題：錯誤 MySql返回：#1273 - Unknown collation: 'utf8mb4_general_ci'

編碼不要選擇這個，utf8有很多種

Ⅷ 請教thinkphp如何使用utf8mb4

數據連接配置為
'DB_CHARSET'=> 'utf8mb4',
欄位字元集 也需修改為 uf8mb4
才能正常存儲

Ⅸ php創建mysql數據表，怎麼選擇UTF8字元集

一、轉碼失敗
在數據寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的數據亂碼。
針對這種情況，前幾篇文章介紹過客戶端發送請求到服務端。
其中任意一個編碼不一致，都會導致表裡的數據存入不正確的編碼而產生亂碼。
比如下面簡單一條語句：
set @a = "文本字元串";
insert into t1 values(@a);

• 變數 @a 的字元編碼是由參數 CHARACTER_SET_CLIENT 決定的，假設此時編碼為 A，也就是變數 @a 的編碼。

2. 寫入語句在發送到 MySQL 服務端之前的編碼由 CHARACTER_SET_CONNECTION 決定，假設此時編碼為 B。

3. 經過 MySQL 一系列詞法，語法解析等處理後，寫入到表 t1，表 t1 的編碼為 C。
那這里編碼 A、編碼 B、編碼 C 如果不兼容，寫入的數據就直接亂碼。


二、客戶端亂碼
表數據正常，但是客戶端展示後出現亂碼。
這一類場景，指的是從 MySQL 表裡拿數據出來返回到客戶端，MySQL 里的數據本身沒有問題。客戶端發送請求到 MySQL，表的編碼為 D，從 MySQL 拿到記錄結果傳輸到客戶端，此時記錄編碼為 E（CHARACTER_SET_RESULTS）。
那以上編碼 E 和 D 如果不兼容，檢索出來的數據就看起來亂碼了。但是由於數據本身沒有被破壞，所以換個兼容的編碼就可以獲取正確的結果。
這一類又分為以下三個不同的小類：

1)欄位編碼和表一致，客戶端是不同的編碼
比如下面例子， 表數據的編碼是 utf8mb4，而 SESSION 1 發起的連接編碼為 gbk。那由於編碼不兼容，檢索出來的數據肯定為亂碼。

2）表編碼和客戶端的編碼一致，但是記錄之間編碼存在不一致的情形
比如表編碼是 utf8mb4，應用端編碼也是 utf8mb4，但是表裡的數據可能一半編碼是 utf8mb4，另外一半是 gbk。那麼此時表的數據也是正常的，不過此時採用哪種編碼都讀不到所有完整的數據。這樣數據產生的原因很多，比如其中一種可能性就是表編碼多次變更而且每次變更不徹底導致（變更不徹底，我之前的篇章里有介紹）。舉個例子，表 t3 的編碼之前是 utf8mb4，現在是 gbk，而且兩次編碼期間都被寫入了正常的數據。

3）每個欄位的編碼不一致，導致亂碼和第二點一樣的場景。不同的是：非記錄間的編碼不統一，而是每個欄位編碼不統一。舉個例子，表 c1 欄位 a1,a2。a1 編碼 gbk，a2 編碼是 utf8mb4。那每個欄位單獨讀出來數據是完整的，但是所有欄位一起讀出來，數據總會有一部分亂碼。


三、LATIN1
還有一種情形就是以 LATIN1 的編碼存儲數據
估計大家都知道字元集 LATIN1，LATIN1 對所有字元都是單位元組流處理，遇到不能處理的位元組流，保持原樣，那麼在以上兩種存入和檢索的過程中都能保證數據一致，所以 MySQL 長期以來默認的編碼都是 LATIN1。這種情形，看起來也沒啥不對的點，數據也沒亂碼，那為什麼還有選用其他的編碼呢？原因就是對字元存儲的位元組數不一樣，比如 emoji 字元 "❤"，如果用 utf8mb4 存儲，佔用 3 個位元組，那 varchar(12) 就能存放 12 個字元，但是換成 LATIN1，只能存 4 個字元。

Ⅹ php存入emoji表情出現亂碼，資料庫已經改為utf8mb4編碼了

你插入數據的時候寫的insert中欄位數據的編碼不對。你要轉換成相應的字元編碼才可以的。