If I run this SQL script in a utf8 client:
It displays the following warnings:
with the following results:
Notice, the character '��' is "U+1F601 GRINNING FACE WITH SMILING EYES". It is outside of the BMP range supported by MariaDB character sets "utf8" and "ucs2".
The two columns worked differently:
- The ucs2 column correctly treated '��' as an invalid sequence of four bytes,
converted it into four question marks, and appended the character 'b' after them.
- The utf8 column just stopped on this character and lost the trailing 'b'.
The warnings are also different for the two columns.
As "utf8" and "ucs2" are equitable character sets that support exactly the
same character range and repertoire (just with a different encoding),
it would be fair to expect the same behaviour of the two columns.
The column "a" exposes a better behaviour: it preserves as much
information as possible.
The column "b" should be fixed to work in the same way with "a".
The reason of the failure is that the conversion code that is activated
for the column "a" (with conversion) uses an mb_wc()..mb_wc() loop, while the
code activated for the column "b" (without conversion) copies only a well formed
The code without conversion should not stop on a bad byte sequence
and try to copy as much data as possible, like the conversion code does.