4 byte emoji chars displayed as ?? when Japanese characters included
Posted by: Stuart McClune
Date: January 08, 2017 03:00PM

I have a table where I am able to correctly store 4 byte emoji characters along with english text, but when there is Japanese content in the text along with an emoji, the Japanese is stored correctly, but the 4-byte emoji is stored as ??.



I am using mysql version 5.5.41-37.0-25.11 and y server settings are as follows:
mysql> show global variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | utf8mb4 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/Percona-XtraDB-Cluster-5.5.41-rel37.0-25.11.853.Linux.x86_64/share/charsets/ |
+--------------------------+-------------------------

The table I am inserting into looks like :

CREATE TABLE `Post_emoji` (
`postId` bigint(20) NOT NULL,
`content` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
PRIMARY KEY (`postId`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

I am inserting into the table via java inputstream using

LOAD DATA CONCURRENT LOCAL INFILE


The sample content that is giving me trouble is :
'Seeing something odd あかさたなは ☠️😬😁😅'

which when inserted looks like 'Seeing something odd あかさたなは ☠️??????' with a hex value to match of '536565696E672012736F6D657468696E6720126F64642012E38182E3818BE38195E3819FE381AA12E381AF2012E298A012EFB88F123F123F123F123F123F123F12'

Again, I can insert the emojis when they are on their own (or with english text for example), it just seems like something goes off the rails when Japanese is included.

Any help would be appreciated !

Thanks,

Stuart

Options: ReplyQuote




Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.