Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6566

Different INSERT behaviour on bad bytes with and without character set conversion

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.3.12, 5.5.39, 10.0.13
    • 10.1.4
    • Character Sets
    • None

    Description

      If I run this SQL script in a utf8 client:

      SET NAMES utf8;
      DROP TABLE IF EXISTS t1;
      CREATE TABLE t1 (
        a VARCHAR(10) CHARACTER SET ucs2,
        b VARCHAR(10) CHARACTER SET utf8
      );
      INSERT INTO t1 SELECT 'a �� b', 'a �� b';
      SHOW WARNINGS;
      SELECT * FROM t1;

      It displays the following warnings:

      +---------+------+----------------------------------------------------------------------+
      | Level   | Code | Message                                                              |
      +---------+------+----------------------------------------------------------------------+
      | Warning | 1300 | Invalid utf8 character string: '\xF0\x9F\x98\x81 b'                  |
      | Warning | 1300 | Invalid utf8 character string: '\xF0\x9F\x98\x81 b'                  |
      | Warning | 1366 | Incorrect string value: '\xF0\x9F\x98\x81 b' for column 'a' at row 1 |
      | Warning | 1265 | Data truncated for column 'b' at row 1                               |
      +---------+------+----------------------------------------------------------------------+

      with the following results:

      +----------+------+
      | a        | b    |
      +----------+------+
      | a ???? b | a    |
      +----------+------+

      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
      prefix.

      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.

      Attachments

        Issue Links

          Activity

            People

              bar Alexander Barkov
              bar Alexander Barkov
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.