insoler社群網站的MySQL Server資料庫伺服器，到目前爲止都是使用BOONEX預設的utf8_general_ci（只有某些資料表bx_dolphcon_accounts、bx_facebook_accounts、bx_shoutbox_messages會使用utf8_unicode_ci）。為什麼會同時使用utf8_general_ci與utf8_unicode_ci兩種？可能是BOONEX有某些考量。在Wiki的UTF8裡面只有簡單的說明。我想絕大多數的人看過以後，還是不知道這兩種編碼方式有什麼差異？

utf8_unicode_ci和utf8_general_ci區別
在資料庫系統MySQL或MariaDB中有多種字元集，其中utf8_unicode_ci和utf8_general_ci是最常用的，但是utf8_general_ci對某些語言的支援有一些小問題，如果可以接受，那最好使用utf8_general_ci，因為它速度快。否則，請使用較為精確的utf8_unicode_ci，不過速度會慢一些。

在MySQL的原廠網站上，有比較詳細的說明。畢竟是原廠網站，肯用心寫使用說明。雖然對很多人來說，MySQL寫的使用說明太過艱深，很多人還是有看沒有懂。

10.1.10.1 Unicode Character Sets

MySQL supports multiple Unicode character sets:

utf8 and ucs2 support Basic Multilingual Plane (BMP) characters. utf8mb4, utf16, utf16le, and utf32 support BMP and supplementary characters.

This section describes the collations available for Unicode character sets and their differentiating properties. For general information about Unicode, see Section 10.1.9, “Unicode Support”.

Most Unicode character sets have a general collation (indicated by _general in the name or by the absence of a language specifier), a binary collation (indicated by _bin in the name), and several language-specific collations (indicated by language specifiers). For example, for utf8, utf8_general_ci and utf8_bin are its general and binary collations, and utf8_danish_ci is one of its language-specific collations.

我用Bing翻譯一下以上的內容。我不使用Google翻譯是因為Google翻譯的結果，其實完全是「簡體中國語言的繁體字版本」而不是真正「繁體中文」！

10.1.10.1 Unicode 字元集

MySQL 支援多個 Unicode 字元集：

• utf8：對 Unicode 字元集進行 UTF-8 編碼, 每個字元使用1到3個位元組。

• ucs2：Unicode 字元集的 UCS-2 編碼, 每個字元使用2個位元組。

• utf8mb4：對 Unicode 字元集進行 UTF-8 編碼, 每個字元使用1到4個位元組。

• utf16：用於 Unicode 字元集的 UTF-16 編碼, 每個字元使用2個或4個位元組。像是 ucs2, 但對補充字元擴展。

• utf16le：Unicode 字元集的 UTF-16LE 編碼。像是 utf16, 但是、是小位元組, 而不是大位元組。

• utf32：用於 Unicode 字元集的 UTF-32 編碼, 每個字元使用4個位元組。

utf8 和 ucs2 支援基本多語言平面 (BMP) 字元。utf8mb4、utf16、utf16le 和 utf32 支援 BMP 和輔助字元。

本章節介紹對 Unicode 字元集及其區分屬性可用的歸類。有關 unicode 的一般資訊, 請參見10.1.9 的 "unicode 支援" 部分。

大多數 Unicode 字元集都有一個常規歸類 (由 _general 在名稱中或在缺少語言說明符時指示)、二進位歸類 (由 _bin 在名稱中指示) 和幾種特定語言的排序規則 (由語言表示)。例如, 對於 utf8, utf8_general_ci 和 utf8_bin 是它的常規和二進位歸類, 而 utf8_danish_ci 是其特定語言的排序規則之一。

簡單的說，雖然都是「Unicode 字元集」，但是UTF8系列的utf8_general_ci或是utf8_unicode_ci編碼是「UTF-8 編碼, 每個字元使用1到3個位元組」，而新的utf8mb4系列則是「UTF-8 編碼, 每個字元使用1到4個位元組」。為什麼會這麼複雜？其實在30幾年前，只有Apple II個人電腦時代，電腦一開始的編碼系統，其實只有「8 bits」8位元，或是稱為「1 byte」的「1個位元組」。因為當時的電腦只有4位元，最多只有「8位元」的關係，所以電腦早期的編碼系統是使用「ASCII編碼」系統，在Wiki有提到：

ASCII的局限在於只能顯示26個基本拉丁字母、阿拉伯數目字和英式標點符號，因此只能用於顯示現代美國英語（而且在處理英語當中的外來詞如naïve、café、élite等等時，所有重音符號都不得不去掉，即使這樣做會違反拼寫規則）。而EASCII雖然解決了部分西歐語言的顯示問題，但對更多其他語言依然無能為力。因此現在的軟體系統大多採用Unicode。

「ASCII編碼」的「8位元」編碼，雖然可以表達0〜255的數字範圍，但其實只能顯示127個字，在128以後就沒有定義。幾年後的Apple II到了必須想辦法可以顯示中文字的時候，只好從基本的「ASCII編碼」擴展到使用2個bytes的「BIG-5」所謂「大5碼」編碼方式。不過2個位元組的「BIG-5」最多只能記錄0〜65535個數字。雖然對中文字來說，基本上已經足夠使用。但卻無法同時收錄簡體中文、日本與、韓語... 等多國語系。

所以到了16位元電腦的時代，「統一碼聯盟在1991年首次發布了The Unicode Standard。Unicode的開發結合了國際標準化組織所制定的ISO/IEC 10646，即通用字元集。」而且「位於美國加州的Unicode組織允許任何願意支付會費的公司和個人加入，其成員包含了主要的電腦軟硬體廠商，例如奧多比系統、蘋果公司、惠普、IBM、微軟、全錄等。」

Unicode為了向下相容最早期的ASCII編碼，收錄的文字又必須超過2個bytes的「BIG-5」所以8 bits編碼的「UTF-8 編碼」才會變成「每個字元使用1到3個位元組」。3個位元組就有8bit x 3 = 24bit。可以記錄多達16777216的數字，每個數字都可以對應一個文字編碼。也就是可以顯示「1千6百萬」個各國文字。

雖然「1千6百萬」個字應該已經可以儲存全世界各國語言的文字。但其實還是不夠使用，而且如果想要使用「圖形文字」的話，也會無法收錄。所以才會再從「每個字元使用1到3個位元組」擴充到「每個字元使用1到4個位元組」這就是utf8mb4。這是「4位元組UTF-8編碼」的縮寫：

utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding)

因此4個位元組就可以有8bit x 4 = 32bit。可以記錄高達4294967296的數字，可以顯示「42.9億」將近「43億」個各國文字。我想Unicode，就算再過100年以後應該不會繼續擴充到「5個位元組」。世界各國人類的文字應該不可能超過「43億」以上。

因為「每個字元使用1到3個位元組」已經可以記錄「1千6百萬」個各國文字，基本上已經相當夠用，對於收錄全部的繁體中文、簡體中文、日本語、日文漢字（只有日本才使用的漢字）、韓語（雖然已經不使用漢字），但是無法對應新的「圖形文字」的「繪文字」！

utf8mb4的4個位元組Unicode與「繪文字」

新的Unicode已經發展到10.0版，而且是今年2017年6月才剛剛修正、發表。這次新增了136,755個文字。

如果你是使用新的Windows 10應該在輸入文字的時候，會看到「圖形文字」的「繪文字」。例如輸入「蘋果」的時候，除了「蘋果」以及與「果」相同發音的文字，還會看到一個「🍎」的「繪文字」。

再按一下「2」就會看到圖形的「🍎」的1個繪文字，而不是「蘋果」的這2個字。

同樣的，在輸入「電腦」的時候，除了「電腦」這2個字以外，也可以點選「🖥」的這1個繪文字。

圖形文字不是只有「🍏💻」而已，還包括常用的「表情符號」。原本在MSN Messenger、iMessage與一些通訊軟體裡面才能使用的「表情符號」其實是由多個文字符號，例如「 ;-) 」來表示一個「😊」的笑臉符號。現在也新增到4位元組的Unicode編碼裡面。

當然，輸入「哭」的時候，也可以像以前MSN Messenger等通訊軟體的「:-(」顯示一個哭的臉的「😢」圖形文字。雖然「繪文字」是圖形文字，但不是「動態圖形」，而是「靜態圖形」，所以不像MSN Messenger、iMessage那樣，繪文字的「😊、😢」並不會看到任何動作。

在insoler社群網站以及許多討論區上的「動態表情符號」，例如笑臉的「😊」可以顯示成動態的「」，哭臉的「😢」可以顯示成「」的動態圖形，這是因為是使用非常老舊的「GIF」這種總共只有256種顏色的動態圖形格式。所以會看到動態的圖片，而不是靜態圖片。

以上只是說明「1-3個位元組的UTF-8」以及「1-4個位元組的utf8mb4編碼」的差異，但是真正想要把運作中的insoler資料庫從目前的utf8_general_ci轉成新的utf8mb4_bin並不是那麼簡單的事！另外雖然也有utf8mb4_general_ci與utf8mb4_general_ci，但是會遇到沒有精確比較4位元組內容的問題，會造成資料搜尋錯誤，所以只好改用區分英文字大小寫的utf8mb4_bin。這個編碼的缺點是「區分英文字大小寫」，在搜尋討論區內容的時候，如果輸入「apple」會變成找不到「Apple」的相關資料！

想要把utf8_general_ci轉成utf8mb4_bin，最常見的問題就是這個：

Specified key was too long; max key length is 1000 bytes錯誤訊息

使用「MyISAM」這種資料庫格式的話，會遇到「索引鍵」的索引碼長度不可以超過1000個位元組的問題！

Mysql::Error: Specified key was too long; max key length is 1000 bytes

Error: Specified key was too long; max key length is 1000 bytes

如果是InnoDB就更慘，會遇到「索引鍵」的索引碼長度不可以超過767個位元組的問題！

Specified key was too long; max key length is 767 bytes

#1071 - Specified key was too long; max key length is 767 bytes

在MySQL的網頁上有說明：

13.1.14 CREATE INDEX Syntax

Prefix support and lengths of prefixes (where supported) are storage engine dependent. For example, a prefix can be up to 767 bytes long for InnoDB tables or 3072 bytes if the innodb_large_prefix option is enabled. For MyISAM tables, the prefix limit is 1000 bytes. The NDB storage engine does not support prefixes (see Section 21.1.6.6, “Unsupported or Missing Features in NDB Cluster”).

同樣的，這樣的說明對很多人來說，一樣是「有字天書」有看沒有懂！MySQL的工程師寫的說明文件，雖然是有寫很多內容，但是絕大多數都是等於沒寫！因為看不懂。

簡單的說，在my.cnf設定檔案裡面設定 innodb_large_prefix = ON 就可以解決767 bytes long的問題，可以延伸到3072 bytes。但是在MyISAM卻有一個非常可笑的1000 bytes「1千位元組」整數的限制。

在許多的資料庫（不只是insoler）對於輸入姓、名，討論區標題等資料表欄位，大多都是使用最大的255字元這樣的設定：

varchar(255) NOT NULL

在3個位元的UTF-8編碼的utf8_general_ci格式的時候，實際儲存的資料長度是：

255字元 x 3位元 = 765位元。（這也是上面767 bytes long的理由）。

但是改成新的「4個位元組的utf8mb4編碼」的話，就會變成：

255字元 x 4位元 = 1020位元。（這也是上面limit is 1000 bytes的理由），剛好超過20個位元！

我不知道MySQL哪個笨蛋工程師把MyISAM限制設定在整數的「1000位元組」！完全忽略「255字元 x 4位元 = 1020位元」這件事！

如果MySQL的笨蛋工程師喜歡把長度限制在整數的話，另外一種就不應該是「767位元組」，應該是「limit is 500 bytes」以及「limit is 1000 bytes」才對。

我不想等到MySQL的笨蛋工程師，在MySQL 8.0版，或是MySQL 10.0版本的時候，才想要修正這個問題，現在唯一的手段就是變更BOONEX資料表裡面，全部的字元欄位長度！從原本的：

varchar(255) NOT NULL

改成比較短的：

varchar(250) NOT NULL

這樣的話，雖然少了5個位元，但是250個字的姓氏、名字、部落格標題、討論區標題等，也已經非常夠用，非常長了。通常的標題長度不會超過250個字以上才對（無論是英文字母，或是中文字的一個漢字）。這樣的話：

250字元 x 4位元 = 1000位元。剛剛好等於limit is 1000 bytes的極限！這樣就不會出錯，而且250個字元長度應該也很夠用。不過，光是修改資料庫長度，卻沒有修改PHP與HTML程式碼的話，可以輸入255個字，但是資料庫卻不能接受250個字以上的長度，將來會發生資料庫錯誤的問題。不過，在insoler會員不多（其實是只有幾隻貓）的情況下，我可以有很多時間繼續慢慢改PHP與HTML程式碼。

如果你看得懂MySQL的資料表結構的話，實際舉例子說明要怎樣從utf8轉換成utf8mb4編碼，會更容易理解。這是原本使用utf8編碼的資料表，用在每一張照片底下的「評論」：

--
-- Table structure for table `bx_photos_cmts`
--

DROP TABLE IF EXISTS `bx_photos_cmts`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `bx_photos_cmts` (
  `cmt_id` int(11) NOT NULL AUTO_INCREMENT,
  `cmt_parent_id` int(11) NOT NULL DEFAULT '0',
  `cmt_object_id` int(10) unsigned NOT NULL DEFAULT '0',
  `cmt_author_id` int(10) unsigned NOT NULL DEFAULT '0',
  `cmt_text` text NOT NULL,
  `cmt_mood` tinyint(4) NOT NULL DEFAULT '0',
  `cmt_rate` int(11) NOT NULL DEFAULT '0',
  `cmt_rate_count` int(11) NOT NULL DEFAULT '0',
  `cmt_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `cmt_replies` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`cmt_id`),
  KEY `cmt_object_id` (`cmt_object_id`,`cmt_parent_id`)
) ENGINE=MyISAM AUTO_INCREMENT=3351 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

你可以看到，這裡並沒有使用varchar(255)這種文字格式，這是因為照片底下的「評論」（或是稱為回應、討論），不需要標題，只需要寫想要說的事情，或是問題的內容即可。所以可以直接改成這樣的utf8mb4格式：

--
-- Table structure for table `bx_photos_cmts`
--

DROP TABLE IF EXISTS `bx_photos_cmts`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8mb4 */;
CREATE TABLE `bx_photos_cmts` (
  `cmt_id` int(11) NOT NULL AUTO_INCREMENT,
  `cmt_parent_id` int(11) NOT NULL DEFAULT '0',
  `cmt_object_id` int(10) unsigned NOT NULL DEFAULT '0',
  `cmt_author_id` int(10) unsigned NOT NULL DEFAULT '0',
  `cmt_text` text NOT NULL,
  `cmt_mood` tinyint(4) NOT NULL DEFAULT '0',
  `cmt_rate` int(11) NOT NULL DEFAULT '0',
  `cmt_rate_count` int(11) NOT NULL DEFAULT '0',
  `cmt_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `cmt_replies` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`cmt_id`),
  KEY `cmt_object_id` (`cmt_object_id`,`cmt_parent_id`)
) ENGINE=MyISAM AUTO_INCREMENT=3351 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
/*!40101 SET character_set_client = @saved_cs_client */;

但是在主要記錄每張照片資料的bx_photos_main的資料表裡面，就會看到有varchar(255)這個文字格式，用來儲存照片的標題，通常是照片的檔名。普通的照片的檔案名稱其實還是使用老舊的FAT的「8.3」的命名格式，所以其實只會有「IMG_3518」這樣的主檔名，以及「CR2」或是「JPG」的副檔名。

因為照片的檔名只有8個字元，其實不需要最大的varchar(255)這種格式，頂多只需要varchar(8)就可以了。另外，「Tags」標籤也使用varchar(255)這個文字格式，因為「Tags」標籤（通常是拍攝地點，或是照片的分類方式）是由使用者自行輸入的文字，所以需要比較長的文字長度。但是通常不可能超過250個字以上！

--
-- Table structure for table `bx_photos_main`
--

DROP TABLE IF EXISTS `bx_photos_main`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `bx_photos_main` (
  `ID` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `Categories` text NOT NULL
  `Owner` int(10) unsigned DEFAULT NULL,
  `Ext` varchar(4) DEFAULT '',
  `Size` varchar(10) DEFAULT '',
  `Title` varchar(255) DEFAULT '',
  `Uri` bigint(20) unsigned NOT NULL,
  `Desc` text NOT NULL,
  `Tags` varchar(255) NOT NULL DEFAULT '',
  `Date` int(11) unsigned NOT NULL DEFAULT '0',
  `Views` int(11) unsigned DEFAULT '0',
  `Rate` float NOT NULL DEFAULT '0',
  `RateCount` int(11) unsigned NOT NULL DEFAULT '0',
  `CommentsCount` int(11) unsigned NOT NULL DEFAULT '0',
  `Featured` tinyint(4) NOT NULL DEFAULT '0',
  `Status` enum('approved','disapproved','pending') NOT NULL DEFAULT 'pending',
  `Hash` varchar(32) NOT NULL DEFAULT '',
  PRIMARY KEY (`ID`),
  UNIQUE KEY `Hash` (`Hash`),
  UNIQUE KEY `Uri` (`Uri`),
  KEY `Owner` (`Owner`),
  KEY `Date` (`Date`),
  FULLTEXT KEY `ftMain` (`Title`,`Tags`,`Desc`,`Categories`),
  FULLTEXT KEY `ftTags` (`Tags`),
  FULLTEXT KEY `ftCategories` (`Categories`)
) ENGINE=MyISAM AUTO_INCREMENT=140768 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

所以我把原本的「varchar(255)」改成「varchar(250)」縮短5個字元，原本的資料表的預設編碼是「MyISAM DEFAULT CHARSET=utf8」（實際上是utf8_general_ci）就可以修改成新的「DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;」。

--
-- Table structure for table `bx_photos_main`
--

DROP TABLE IF EXISTS `bx_photos_main`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8mb4 */;
CREATE TABLE `bx_photos_main` (
  `ID` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `Categories` text NOT NULL,
  `Owner` int(10) unsigned DEFAULT NULL,
  `Ext` varchar(4) DEFAULT '',
  `Size` varchar(10) DEFAULT '',
  `Title` varchar(250) DEFAULT '',
  `Uri` bigint(20) unsigned NOT NULL,
  `Desc` text NOT NULL,
  `Tags` varchar(250) NOT NULL DEFAULT '',
  `Date` int(11) unsigned NOT NULL DEFAULT '0',
  `Views` int(11) unsigned DEFAULT '0',
  `Rate` float NOT NULL DEFAULT '0',
  `RateCount` int(11) unsigned NOT NULL DEFAULT '0',
  `CommentsCount` int(11) unsigned NOT NULL DEFAULT '0',
  `Featured` tinyint(4) NOT NULL DEFAULT '0',
  `Status` enum('approved','disapproved','pending') NOT NULL DEFAULT 'pending',
  `Hash` varchar(32) NOT NULL DEFAULT '',
  PRIMARY KEY (`ID`),
  UNIQUE KEY `Hash` (`Hash`),
  UNIQUE KEY `Uri` (`Uri`),
  KEY `Owner` (`Owner`),
  KEY `Date` (`Date`),
  FULLTEXT KEY `ftMain` (`Title`,`Tags`,`Desc`,`Categories`),
  FULLTEXT KEY `ftTags` (`Tags`),
  FULLTEXT KEY `ftCategories` (`Categories`)
) ENGINE=MyISAM AUTO_INCREMENT=140768 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
/*!40101 SET character_set_client = @saved_cs_client */;

如果資料表只有這些，當然可以用「手動」的方式修改，但是從MySQL Workbench匯出的「只有資料結構」的insoelr_table.sql檔案的長度有4470行！這麼長的資料表，一行一行檢查，一行一行修改，變成一個非常痛苦的事情，而且還可能會有手動修改錯誤的問題。所以我其實是使用BBEdit編輯器的「搜尋、取代」來大量搜尋、取代。

由於使用MySQL Workbench匯入新的「只有資料結構」的insoelr_table.sql檔案，只會看到不知所云的錯誤訊息，所以我是使用phpMyAdmin 4.7.4（現在的最新版本）來匯入「只有資料結構」的insoelr_table.sql檔案，在這裡就可以看到詳細的MySQL錯誤訊息，再根據錯誤訊息來修正insoelr_table.sql檔案。

這些事情當然是不能直接拿正式運作的insoler網站來做各種實驗，所以我是在備用的Mac mini Server（主機的規格、配備與正式的MySQL伺服器主機完全相同），以及另外建立的地下社群網站來做改造「utf8轉換成utf8mb4編碼」的實驗，確定成功以後，才能在正式運作的insoler網站的MySQL伺服器上進行相同的改造動作。

難用的MySQL Workbench導致操作錯誤

雖然這次終於把整個資料庫轉成「utf8mb4編碼系統」成功了，但因為MySQL Workbench操作複雜，一不小心操作錯誤，導致只好用4天前備份的insoler.sql資料庫重新處理，所以才會導致遺失了4天的資料內容。

運作中的insoler當然不可能直接拿來進行轉換實驗，所以我是使用另外一台備用的Mac mini Server主機與地下社群網站來進行轉換實驗，把整個資料庫分別匯出為「只有資料結構」與「只有資料」。因為如果把整個資料庫全部匯出到一個insoler.sql，會得到一個300MB左右的純文字檔案，這麼大的檔案，幾乎找不到可以很流暢編輯、修改內容的編輯程式。

然後用BBEdit編輯器修改「只有資料結構」的insoler_table.sql，縮減不需要的varchar(255)長度，改成varchar(250)，修改了許多資料結構與預設編碼，最後才終於得到可以正常匯入的空白資料表insoler_table.sql，而且是改用utf8mb4編碼。某些無法改用utf8mb4編碼的資料表，因為是系統本身使用，使用者不會使用到那些資料表，就維持原本舊的utf8_general_ci編碼。

因為整個資料表編碼、許多改成varchar(250) 的資料長度都不太一樣，所以只能刪除現在使用的insoler資料庫，用utf8mb4_bin重新建立一個空白資料庫，匯入新的空白資料表結構，最後再匯入「只有資料」的insoler_data.sql到新的資料庫，這樣才能轉換成功。

不幸的是，在進行實驗之前，我早就停止mysqldump自動備份！因為這個指令會造成Aborted_connects中斷，最後會導致MySQL因為經常中斷導致不斷出錯，最後就會導致insoler網站無法連接MySQL資料庫。

在地下社群網站與備用Mac mini Server主機實驗成功以後，當然決定更新正式運作的insoler網站。非常不幸的是，MySQL Workbench對於分別匯出「只有資料結構」與「只有資料」操作複雜，而且因為資料庫結構不會經常改變，所以就偷懶沒有從正式運作的insoler網站，再重新匯出一次。

MySQL Workbench操作錯誤的下場，就是沒有在操作前再備份一次最新的資料（萬一操作錯誤還可以還原），過於信心滿滿，就直接操作的結果，就是一開始就匯入失敗，然後就損失現在的整個資料庫內容！

所以只好從4天前備份的資料庫還原，再重新操作一次。匯入新的utf8mb4編碼的空白資料庫結構，再匯入純資料內容。

幾個月以前就有在insoler正式運作的網站上，直接做過類似的動作，但是因為當時找不到解決辦法，所以只好用實驗以前，事先備份的資料還原。這次則是過於信心滿滿，沒有再一次進行備份，再開始改造資料庫，所以才會又再次失敗！雖然轉換utf8mb4編碼成功，卻遺失了4天的資料內容。

因為整個資料庫除了部分無法使用utf8mb4編碼，其他都是使用utf8mb4_bin編碼，所以在部落格裡面，在討論區裡面也可以輸入🍎🖥😊😢、🍔... 等許多的繪文字了。