phpemojimysql

㈠ 爬蟲寫入mysql表裡的數據都是這種Unicode編碼，怎麼轉為可讀文字

unicode emoji是4個位元組的，存不進MySQL里，找到一個轉義的庫code.iamcal.com/php/emoji/，但是轉為Unicode之後，還是4個位元組，一樣存不進，應該說根本沒轉。轉為其他格式的emoji又怕以後新增了表情不好做，你們在不改資料庫編碼的前提下，是怎麼弄的？
方法1：base_encode64
這種方法是可以，但是舊數據沒有經過encode操作，取數據的時候如果統一進行decode的話，舊數據會丟失的。
方法2：urlencode
這個似乎可以，對沒有經過encode的數據進行decode也不會有影響，而且多次decode似乎也不會有影響。

㈡ MySQL與PostgreSQL相比哪個更好

MySQL
MySQL聲稱自己是最流行的開源資料庫。LAMP中的M指的就是MySQL。構建在LAMP上的應用都會使用MySQL，如WordPress、Drupal等大多數php開源程序。MySQL最初是由MySQL AB開發的，然後在2008年以10億美金的價格賣給了Sun公司，Sun公司又在2010年被Oracle收購。Oracle支持MySQL的多個版本：Standard、Enterprise、Classic、Cluster、Embedded與Community。其中有一些是免費下載的，另外一些則是收費的。其核心代碼基於GPL許可，由於MySQL被控制在Oracle，社區擔心會對MySQL的開源會有影響，所以開發了一些分支，比如： MariaDB和Percona。
PostgreSQL
PostgreSQL標榜自己是世界上最先進的開源資料庫。PostgreSQL的一些粉絲說它能與Oracle相媲美，而且沒有那麼昂貴的價格和傲慢的客服。最初是1985年在加利福尼亞大學伯克利分校開發的，作為Ingres資料庫的後繼。PostgreSQL是完全由社區驅動的開源項目。它提供了單個完整功能的版本，而不像MySQL那樣提供了多個不同的社區版、商業版與企業版。PostgreSQL基於自由的BSD/MIT許可，組織可以使用、復制、修改和重新分發代碼，只需要提供一個版權聲明即可。
MySQL與PostgreSQL的對比
MySQL的背後是一個成熟的商業公司，而PostgreSQL的背後是一個龐大的志願開發組。這使得MySQL的開發過程更為慎重，而PostgreSQL的反應更為迅速。這樣的兩種背景直接導致了各自固有的優點和缺點。
PostgreSQL相對於MySQL的優勢
1)不僅僅是關系型資料庫
除了存儲正常的數據類型外，還支持存儲：
array，不管是一位數組還是多為數組均支持
json(hStore)和jsonb，相比使用text存儲接送要高效很多
json和jsonb之間的區別
jsonb和json在更高的層面上看起來幾乎是一樣的，但在存儲實現上是不同的。
json存儲完的文本，json列會每次都解析存儲的值，它不支持索引，但你可以為查詢創建表達式索引。
jsonb存儲的二進制格式，避免了重新解析數據結構。它支持索引，這意味著你可以不使用指定的索引就能查詢任何路徑。
當我們比較寫入數據速度時，由於數據存儲的方式的原因，jsonb會比json稍微的慢一點。json列會每次都解析存儲的值，這意味著鍵的順序要和輸入的時候一樣。但jsonb不同，以二進制格式存儲且不保證鍵的順序。因此，如果你有軟體需要依賴鍵的順序，jsonb可能不是你的應用的最佳選擇。使用jsonb的優勢還在於你可以輕易的整合關系型數據和非關系型數據， PostgreSQL對於mongodb這類的基於文檔的資料庫是個不小的威脅，畢竟如果一個表中只有一列數據的類型是半結構化的，沒有必要為了遷就它而整個表的設計採用schemaless的結構。
2)支持地理信息處理擴展
PostGIS 為PostgreSQL提供了存儲空間地理數據的支持，使PostgreSQL成為了一個空間資料庫，能夠進行空間數據管理、數量測量與幾何拓撲分析。在功能上，和MYSQL對比，PostGIS具有下列優勢：

O2O業務場景中的LBS業務使用PostgreSQL + PostGIS有無法比擬的優勢。
3)可以快速構建REST API
PostgREST 可以方便的為任何 PostgreSQL 資料庫提供完全的 RESTful API 服務。
4)支持樹狀結構
支持R-trees這樣可擴展的索引類型，可以更方便地處理一些特殊數據。MySQL 處理樹狀的設計會很復雜, 而且需要寫很多代碼, 而 PostgreSQL 可以高效處理樹結構。
5)有極其強悍的 SQL 編程能力
支持遞歸，有非常豐富的統計函數和統計語法支持。
MySQL：支持 CREATE PROCEDURE 和 CREATE FUNCTION 語句。存儲過程可以用 SQL 和 C++ 編寫。用戶定義函數可以用 SQL、C 和 C++ 編寫。
PostgreSQL：沒有單獨的存儲過程，都是通過函數實現的。用戶定義函數可以用 PL/pgSQL(專用的過程語言)、PL/Tcl、PL/Perl、PL/Python 、SQL 和 C 編寫。
6)外部數據源支持
可以把 70 種外部數據源 (包括 Mysql, Oracle, CSV, hadoop …) 當成自己資料庫中的表來查詢。Postgres有一個針對這一難題的解決方案：一個名為「外部數據封裝器(Foreign Data Wrapper，FDW)」的特性。該特性最初由PostgreSQL社區領袖Dave Page四年前根據SQL標准SQL/MED(SQL Management of External Data)開發。FDW提供了一個SQL介面，用於訪問遠程數據存儲中的遠程大數據對象，使DBA可以整合來自不相關數據源的數據，將它們存入Postgres資料庫中的一個公共模型。這樣，DBA就可以訪問和操作其它系統管理的數據，就像在本地Postgres表中一樣。例如，使用FDW for MongoDB，資料庫管理員可以查詢來自文檔資料庫的數據，並使用SQL將它與來自本地Postgres表的數據相關聯。藉助這種方法，用戶可以將數據作為行、列或JSON文檔進行查看、排序和分組。他們甚至可以直接從Postgres向源文檔資料庫寫入(插入、更細或刪除)數據，就像一個一體的無縫部署。也可以對Hadoop集群或MySQL部署做同樣的事。FDW使Postgres可以充當企業的中央聯合資料庫或「Hub」。
7)沒有字元串長度限制
一般關系型資料庫的字元串有限定長度8k左右，無限長 TEXT 類型的功能受限，只能作為外部大數據訪問。而PostgreSQL的 TEXT 類型可以直接訪問，SQL語法內置正則表達式，可以索引，還可以全文檢索，或使用xml xpath。MySQL 的各種text欄位有不同的限制，要手動區分 small text, middle text, large text… PostgreSQL 沒有這個限制，text 能支持各種大小。
8)支持圖結構數據存儲
沒有具體使用過，具體可以自己搜索下。參考鏈接：https://mp.weixin.qq.com/s/cjor82wgDu5gzDvTYpLDWw
9)支持窗口函數
窗口函數提供跨行相關的當前查詢行集執行計算的能力。僅當調用跟著OVER子句的聚集函數，作為窗口函數;否則它們作為常規的聚合函數。窗口也是一種分組，但和 group by 的分組不同。窗口，可以提供分組之外，還可以執行對每個窗口進行計算。可以相像成是group by 後，然後對每個分組進行計算，而不像Group by ，只是單純地分組。MySQL 不支持 OVER 子句, 而PostgreSQL支持。OVER 子句能簡單的解決 「每組取 top 5」 的這類問題。MySQL支持的SQL語法(ANSI SQL標准)的很小一部分。不支持遞歸查詢、通用表表達式(Oracle的with 語句)或者窗口函數(分析函數)。
10)對索引的支持更強
PostgreSQL 的可以使用函數和條件索引，這使得PostgreSQL資料庫的調優非常靈活，mysql就沒有這個功能，條件索引在web應用中很重要。對於索引類型：
MySQL：取決於存儲引擎。MyISAM：BTREE，InnoDB：BTREE。
PostgreSQL：支持 B-樹、哈希、R-樹和 Gist 索引。
InnoDB的表和索引都是按相同的方式存儲。也就是說表都是索引組織表。這一般要求主鍵不能太長而且插入時的主鍵最好是按順序遞增，否則對性能有很大影響。PostgreSQL不存在這個問題。
索引類型方面，MySQL取決於存儲引擎。MyISAM：BTREE，InnoDB：BTREE。PostgreSQL支持 B-樹、哈希、R-樹和 Gist 索引。
11)集群支持更好
Mysql Cluster可能與你的想像有較大差異。開源的cluster軟體較少。復制(Replication)功能是非同步的並且有很大的局限性。例如，它是單線程的(single-threaded)，因此一個處理能力更強的Slave的恢復速度也很難跟上處理能力相對較慢的Master。
PostgreSQL有豐富的開源cluster軟體支持。plproxy 可以支持語句級的鏡像或分片，slony 可以進行欄位級的同步設置，standby 可以構建WAL文件級或流式的讀寫分離集群，同步頻率和集群策略調整方便，操作非常簡單。
另外，PostgreSQL的主備復制屬於物理復制，相對於MySQL基於binlog的邏輯復制，數據的一致性更加可靠，復制性能更高，對主機性能的影響也更小。對於WEB應用來說，復制的特性很重要，mysql到現在也是非同步復制，pgsql可以做到同步，非同步，半同步復制。還有mysql的同步是基於binlog復制，類似oracle golden gate,是基於stream的復制，做到同步很困難，這種方式更加適合異地復制，pgsql的復制基於wal，可以做到同步復制。同時，pgsql還提供stream復制。
12)事務隔離做的更好
MySQL 的事務隔離級別 repeatable read 並不能阻止常見的並發更新, 得加鎖才可以, 但悲觀鎖會影響性能, 手動實現樂觀鎖又復雜. 而 PostgreSQL 的列里有隱藏的樂觀鎖 version 欄位, 默認的 repeatable read 級別就能保證並發更新的正確性, 並且又有樂觀鎖的性能。
13)對於字元支持更好一些
MySQL 里需要 utf8mb4 才能顯示 emoji 的坑, PostgreSQL 沒這個坑。
14)對表連接支持較完整
對表連接支持較完整，MySQL只有一種表連接類型:嵌套循環連接(nested-loop),不支持排序-合並連接(sort-merge join)與散列連接(hash join)。PostgreSQL都支持。
15)存儲方式支持更大的數據量
PostgreSQL主表採用堆表存放，MySQL採用索引組織表，能夠支持比MySQL更大的數據量。
16)時間精度更高
MySQL對於時間、日期、間隔等時間類型沒有秒以下級別的存儲類型，而PostgreSQL可以精確到秒以下。
17)優化器的功能較完整
MySQL對復雜查詢的處理較弱，查詢優化器不夠成熟，explain看執行計劃的結果簡單。性能優化工具與度量信息不足。
PostgreSQL很強大的查詢優化器，支持很復雜的查詢處理。explain返回豐富的信息。提供了一些性能視圖，可以方便的看到發生在一個表和索引上的select、delete、update、insert統計信息，也可以看到cache命中率。網上有一個開源的pgstatspack工具。
18)序列支持更好
MySQL 不支持多個表從同一個序列中取 id, 而 PostgreSQL 可以。
19)對子查詢支持更好
對子查詢的支持。雖然在很多情況下在SQL語句中使用子查詢效率低下，而且絕大多數情況下可以使用帶條件的多表連接來替代子查詢，但是子查詢的存在在很多時候仍然不可避免。而且使用子查詢的SQL語句與使用帶條件的多表連接相比具有更高的程序可讀性。幾乎任何資料庫的子查詢 (subquery) 性能都比 MySQL 好。
20)增加列更加簡單
MySQL表增加列，基本上是重建表和索引，會花很長時間。PostgreSQL表增加列，只是在數據字典中增加表定義，不會重建表.
MySQL相對於PostgreSQL的優勢
1)MySQL比PostgreSQL更流行
流行對於一個商業軟體來說，也是一個很重要的指標，流行意味著更多的用戶，意味著經受了更多的考驗，意味著更好的商業支持、意味著更多、更完善的文檔資料。易用，很容易安裝。第三方工具，包括可視化工具，讓用戶能夠很容易入門。
2)回滾實現更優
innodb的基於回滾段實現的MVCC機制，相對PG新老數據一起存放的基於XID的MVCC機制，是占優的。新老數據一起存放，需要定時觸發VACUUM，會帶來多餘的IO和資料庫對象加鎖開銷，引起資料庫整體的並發能力下降。而且VACUUM清理不及時，還可能會引發數據膨脹。
3)在Windows上運行更可靠
與PostgreSQL相比，MySQL更適宜在Windows環境下運行。MySQL作為一個本地的Windows應用程序運行(在 NT/Win2000/WinXP下，是一個服務)，而PostgreSQL是運行在Cygwin模擬環境下。PostgreSQL在Windows下運行沒有MySQL穩定，應該是可以想像的。
4)線程模式相比進程模式的優勢
MySQL使用了線程，而PostgreSQL使用的是進程。在不同線程之間的環境轉換和訪問公用的存儲區域顯然要比在不同的進程之間要快得多。
進程模式對多CPU利用率比較高。進程模式共享數據需要用到共享內存，而線程模式數據本身就是在進程空間內都是共享的，不同線程訪問只需要控制好線程之間的同步。
線程模式對資源消耗比較少。所以MySQL能支持遠比PostgreSQL多的更多的連接。但PostgreSQL中有優秀的連接池軟體軟體，如pgbouncer和pgpool，所以通過連接池也可以支持很多的連接。
5)許可權設置上更加完善
MySQL在許可權系統上比PostgreSQL某些方面更為完善。PostgreSQL只支持對於每一個用戶在一個資料庫上或一個數據表上的 INSERT、SELECT和UPDATE/DELETE的授權，而MySQL允許你定義一整套的不同的數據級、表級和列級的許可權。對於列級的許可權， PostgreSQL可以通過建立視圖，並確定視圖的許可權來彌補。MySQL還允許你指定基於主機的許可權，這對於目前的PostgreSQL是無法實現的，但是在很多時候，這是有用的。
6)存儲引擎插件化機制
MySQL的存儲引擎插件化機制，使得它的應用場景更加廣泛，比如除了innodb適合事務處理場景外，myisam適合靜態數據的查詢場景。
7)適應24/7運行
MySQL可以適應24/7運行。在絕大多數情況下，你不需要為MySQL運行任何清除程序。PostgreSQL目前仍不完全適應24/7運行，這是因為你必須每隔一段時間運行一次VACUUM。
8)更加試用於簡單的場景
PostgreSQL只支持堆表，不支持索引組織表，Innodb只支持索引組織表。
索引組織表的優勢：表內的數據就是按索引的方式組織，數據是有序的，如果數據都是按主鍵來訪問，那麼訪問數據比較快。而堆表，按主鍵訪問數據時，是需要先按主鍵索引找到數據的物理位置。
索引組織表的劣勢：索引組織表中上再加其它的索引時，其它的索引記錄的數據位置不再是物理位置，而是主鍵值，所以對於索引組織表來說，主鍵的值不能太大，否則佔用的空間比較大。
對於索引組織表來說，如果每次在中間插入數據，可能會導致索引分裂，索引分裂會大大降低插入的性能。所以對於使用innodb來說，我們一般最好讓主鍵是一個無意義的序列，這樣插入每次都發生在最後，以避免這個問題。
由於索引組織表是按一個索引樹，一般它訪問數據塊必須按數據塊之間的關系進行訪問，而不是按物理塊的訪問數據的，所以當做全表掃描時要比堆錶慢很多，這可能在OLTP中不明顯，但在數據倉庫的應用中可能是一個問題。
總結
MySQL從一開始就沒有打算做所有事情，因而它在功能方面有一定的局限性，並不能滿足一些先進應用程序的要求。MySQL對某些功能(例如引用、事務、審計等)的實現方式使得它與其他的關系型資料庫相比缺少了一些可靠性。對於簡單繁重的讀取操作，使用PostgreSQL可能有點小題大做，同時性能也比MySQL這樣的同類產品要差。除非你需要絕對的數據完整性，ACID遵從性或者設計復雜，否則PostgreSQL對於簡單的場景而言有點多餘。
如何你確定只在MySQL和PostgreSQL中進行選擇，以下規則總是有效的：
如果你的操作系統是Windows，你應該使用MySQL。
當絕對需要可靠性和數據完整性的時候，PostgreSQL是更好的選擇。
如果需要資料庫執行定製程序，那麼可擴展的PostgreSQL是更好的選擇。
你的應用處理的是地理數據，由於R-TREES的存在，你應該使用PostgreSQL。
如果你對資料庫並不了十分了解，甚至不知道事務、存儲過程等究竟是什麼，你應該使用MySQL。

㈢ php調用微信用戶信息介面昵稱裡面的emoji表情怎麼存儲到mysql中

emoji表情 是四位元組的需要utf-8mb4來存儲，mysql5.6以上才支持utf-8mb4

㈣ php調用微信用戶信息介面昵稱裡面的emoji表情怎麼存儲到mysql中

經過測試雖然utf8mb4能夠將數據存儲到資料庫中，但是還是有問題的：如果微信昵稱前後面都有表情，中間有文字的時候，資料庫中只能將前面的表情保存，後面的表情變成了空格，經過幾番周折還是使用了utf8來保存下圖藍色條選中的那樣字元串來保存，在前端對字元串進行去"處理，保證用戶的昵稱不被破壞

㈤ 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過濾ios的Emoji表情的方法，如果字元串中包含Emoji表情就刪除。

網上已經有開源的了！http://code.iamcal.com/php/emoji/ 你參考下

iOS 5.0之前，蘋果都是採用3個位元組來承接 emoji 表情，Java 的普通 char 可以支持顯示。但 iOS 5.0 之後， 蘋果升級了系統自帶的 emoji 表情輸入法，用的 Unicode 6 標准來統一，是採用4個 bytes 來承接一個 emoji 表情。如果不做處理的話，這種表情直接存儲到 mysql5.5 以下的資料庫是會報錯的。就像這兩個表情一樣：口口, 在 Windows 8 以下估計都不支持顯示，可能會顯示成框框，可能壓根就是空白， 你可以在 Mac 中使用Safari 瀏覽器中，就可以看到。經過測試，在 Mac 就算用 Chrome 瀏覽器(Version 25.0.1364.172)也是不行的。
這種數據在 Mysql 5.5 之前，UTF-8 支持1-3個位元組的編碼，從 Mysql5.5 開始後，可以支持4個位元組的 UTF 編碼，但要特殊標記。修改 Mysql 相應存儲欄位為 utf8mb4 。修改語句如下：
1 ALTER TABLE table_name
2 MODIFY COLUMN content varchar(500) CHARACTER
3 SET utf8mb4 COLLATE utf8mb4_unicode_ci
4 DEFAULT NULL COMMENT 'content of message';
在某種業務情景下，我們可以選擇過濾掉這種「非法」的字元。我採用的方式是，在字元上面做操作，下面是Java示例代碼，核心的代碼附上，應該是 無法直接下載就能夠編譯，你得小小的做一些微調，沒有額外的依賴：
01 public class EmojiFilter {
02
03 /**
04 * 檢測是否有emoji字元
05 * @param source
06 * @return 一旦含有就拋出
07 */
08 public static boolean containsEmoji(String source) {
09 if (StringUtils.isBlank(source)) {
10 return false;
11 }
12
13 int len = source.length();
14
15 for (int i = 0; i < len; i++) {
16 char codePoint = source.charAt(i);
17
18 if (isEmojiCharacter(codePoint)) {
19 //do nothing，判斷到了這里表明，確認有表情字元
20 return true;
21 }
22 }
23
24 return false;
25 }
26
27 private static boolean isEmojiCharacter(char codePoint) {
28 return (codePoint == 0x0) ||
29 (codePoint == 0x9) ||
30 (codePoint == 0xA) ||
31 (codePoint == 0xD) ||
32 ((codePoint >= 0x20) && (codePoint <= 0xD7FF)) ||
33 ((codePoint >= 0xE000) && (codePoint <= 0xFFFD)) ||
34 ((codePoint >= 0x10000) && (codePoint <= 0x10FFFF));
35 }
36
37 /**
38 * 過濾emoji 或者 其他非文字類型的字元
39 * @param source
40 * @return
41 */
42 public static String filterEmoji(String source) {
43
44 if (!containsEmoji(source)) {
45 return source;//如果不包含，直接返回
46 }
47 //到這里鐵定包含
48 StringBuilder buf = null;
49
50 int len = source.length();
51
52 for (int i = 0; i < len; i++) {
53 char codePoint = source.charAt(i);
54
55 if (isEmojiCharacter(codePoint)) {
56 if (buf == null) {
57 buf = new StringBuilder(source.length());
58 }
59
60 buf.append(codePoint);
61 } else {
62 }
63 }
64
65 if (buf == null) {
66 return source;//如果沒有找到 emoji表情，則返回源字元串
67 } else {
68 if (buf.length() == len) {//這里的意義在於盡可能少的toString，因為會重新生成字元串
69 buf = null;
70 return source;
71 } else {
72 return buf.toString();
73 }
74 }
75
76 }
77 }
還有優化的空間，但是已經能夠滿足大多數情況的需求，附上單元測試(JUnit4):
01 public class EmojiFilterTest {
02
03
04 /**
05 * 測試emoji表情
06 */
07 @Test
08 public void fileterEmoji() {
09 String s = "<body>口口213這是一個有各種內容的消息, Hia Hia Hia !!!! xxxx@@@...*)!" +
10 "(@*$&@(&#!)@*)!&$!)@^%@(!&#. 口口口], ";
11 String c = Utils.filterEmoji(s);
12 assertFalse(s.equals(c));
13 String expected = "<body>213這是一個有各種內容的消息, Hia Hia Hia !!!! xxxx@@@...*)" +
14 "!(@*$&@(&#!)@*)!&$!)@^%@(!&#. ], ";
15 assertEquals(expected, c);
16 // assertSame(c, expected);
17 assertSame(expected, "<body>213這是一個有各種內容的消息, Hia Hia Hia !!!! xxxx@@@...*)" +
18 "!(@*$&@(&#!)@*)!&$!)@^%@(!&#. ], ");
19 assertSame(c, Utils.filterEmoji(c));
20 }
21
22 }

㈦ 怎樣查看mysql自定義資料庫的編碼字元集

分不同的類型，可按以下三種方式查詢：

一、查看MySQL資料庫伺服器和資料庫MySQL字元集。

命令：

mysql>showvariableslike'%char%';

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

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

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

㈨ 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，終於找到靠譜能用的代碼：

㈩ ios開發怎麼處理蘋果自帶表情

蘋果系統一直在更新優化中，其中ios內置表情也在不斷新增，近日有消息曝光稱ios10將加入一系列新表情，ios10默認表情有哪些?下面帶來蘋果ios10系統新增表情一覽。 ios10默認表情有哪些?蘋果ios10系統新增表情一覽 iOS9.1固件刺激更多iPhone和iPad用戶更新了設備系統。該固件更新提升系統穩定性與性能，讓用戶使用設備運行更加順暢。在iOS9.1中蘋果公司可能還進行很多工程方面改進，但是其中有一個功能備受關註：那就是新表情符號。據悉iOS10中可能會加入更多表情符號。 統一碼協會(Unicode Consortium)此前已經通過了 74 個全新表情符號的審核，而這些表情符號可能很快就會出現在蘋果的 iOS 10 系統之中。這些新的表情符號已經確定引入將在 2016 年中發布的 Unicode 9.0 中。而蘋果公司通常都會在每年 6 月份發布新的 iOS 操作系統，從時間上來說，蘋果很有可能在新的操作系統中引入這些新的表情符號。 從理論上來說，這 74 個新的表情符號已經獲得統一碼技術委員會審核通過，但是要真正引入到 Unicode 9.0 之中還需要經過一個步驟。 iOS 10 的開發者預覽版有望在今年 6 月份發布，而正式上線時間應該是在今年的 9 或者 10 月份，屆時也是蘋果新款智能手機上市的時間。也就是說要將這些新的表情符號引入 iOS 10 之中，蘋果還有很多時間來做准備。 如圖就是這些新表情符號的一部分，不知道你是否喜歡。當然目前我們也無法完全確定這 74 個新的表情會全部出現在 iOS 10 和 iPhone 上。但是iOS 9.1 中增加了某些新的表情符號後，用戶當中還是因為這些新的表情符號而產生了一陣不小的討論，從這一點來說蘋果或許很有可能會考慮在 iOS 10 中豐富表情符號。 之前有消息稱蘋果已經開始對 iOS 10 系統進行測試，該系統會在今年 6 月時的 WWDC 開發者大會上亮相，隨後發給開發者測試，真正面向用戶的時候估計要等到 iPhone 7 發布的時候了。 雖然 iOS 9 發布的時候依舊保持了對老設備的支持，但這不代表接下來蘋果的系統都會支持老設備。消息中稱，iOS 10 對運行內存的要求會在512MB 以上，然而像 iPhone 4s 和 iPad 2 這樣的大齡朋友恐怕就要被淘汰掉了。 在功能方面，iOS10也帶來全面的提升。這次Siri也許能真正成為你的私人助理，幫你處理語音郵件同時化身iCloud語音信箱。3DTouch將被融入到更多應用與設置中，控制中心或將實現根據用戶的喜好自行定製。對於不同音量控制開關也會進行調整，旋屏方向和緩存清理問題也會得到解決。至於全新的iOS10究竟會如何改變，讓我們共同期待吧。 ios10默認表情有哪些?蘋果ios10系統新增表情一覽就為大家介紹到這里，更多軟體教程歡迎關注。