MySQL 8.0 FAQ: MySQL Chinese, Japanese, and Korean Character Sets As you can see by comparing the differing results from  SHOW VARIABLES , the server ignores the client’s initial settings if the  --skip-character-set-client-handshake  option is used. For  LIKE  searches, there is a very simple problem with binary string column types such as  BINARY and  BLOB : we must know where characters end. With multibyte character sets, different characters might have different octet lengths. For example, in  utf8 ,  A  requires one byte but  ペ  requires three bytes, as shown here: If we do not know where the first character in a string ends, we do not know where the second character begins, in which case even very simple searches such as  LIKE ’_A%’  fail. The solution is to use a nonbinary string column type defined to have the proper CJK character set. For example: mycol TEXT CHARACTER SET sjis . Alternatively, convert to a CJK character set before comparing. This is one reason why MySQL cannot permit encodings of nonexistent characters. If it is not strict about rejecting bad input, it has no way of knowing where characters end. For  FULLTEXT  searches, we must know where words begin and end. With Western languages, this is rarely a problem because most (if not all) of these use an easy-to-identify word boundary: the space character. However, this is not usually the case with Asian writing. We could use arbitrary halfway measures, like assuming that all Han characters represent words, or (for Japanese) depending on changes from Katakana to Hiragana due to grammatical endings. However, the only sure solution requires a comprehensive word list, which means that we would have to include a dictionary in the server for each Asian language supported. This is simply not feasible. The majority of simplified Chinese and basic nonhalfwidth Japanese Kana characters appear in all CJK character sets. The following stored procedure accepts a  UCS-2  Unicode character, converts it to other character sets, and displays the results in hexadecimal. DELIMITER // CREATE PROCEDURE p_convert(ucs2_char CHAR(1) CHARACTER SET ucs2) BEGIN CREATE TABLE tj (ucs2 CHAR(1) character set ucs2, utf8 CHAR(1) character set utf8, big5 CHAR(1) character set big5, cp932 CHAR(1) character set cp932, eucjpms CHAR(1) character set eucjpms, euckr CHAR(1) character set euckr, gb2312 CHAR(1) character set gb2312, gbk CHAR(1) character set gbk, sjis CHAR(1) character set sjis, ujis CHAR(1) character set ujis); INSERT INTO tj (ucs2) VALUES (ucs2_char); UPDATE tj SET utf8=ucs2, big5=ucs2, +-------------------------+---------------------------+ | OCTET_LENGTH(_utf8 ’A’) | OCTET_LENGTH(_utf8 ’ ペ ’) | +-------------------------+---------------------------+ | 1 | 3 | +-------------------------+---------------------------+ A.11.11. Why do some  LIKE  and  FULLTEXT  searches with CJK characters fail? A.11.12. How do I know whether character  X  is available in all character sets? 5266