Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL)
-
None
Description
I start a 8-bit console.
In gnome-terminal I make sure that the console character set is properly set to iso-8859-1:
Terminal -> Character Set Encoding -> Western (ISO-8859-1).
Now I run this command in shell:
$ LANG=en_US.iso88591 mysql test
|
and check that the client correctly detected the session character set as latin1:
SHOW VARIABLES LIKE 'character\_set\_%'; |
+--------------------------+--------+
|
| Variable_name | Value |
|
+--------------------------+--------+
|
| character_set_client | latin1 | <--
|
| character_set_connection | latin1 | <--
|
| character_set_database | latin1 |
|
| character_set_filesystem | binary |
|
| character_set_results | latin1 | <--
|
| character_set_server | latin1 |
|
| character_set_system | utf8 |
|
+--------------------------+--------+
|
Now I run:
SELECT HEX('ä'); |
+----------+
|
| HEX('ä') |
|
+----------+
|
| E4 |
|
+----------+
|
It correctly returns 0xE4, which is a latin1 code for "U+00E4 SMALL LETTER A WITH DIAERESIS".
Now I use a prepared statement with a user variable as a source:
SET @src='SELECT HEX(''ä'')'; |
PREPARE stmt FROM @src; EXECUTE stmt; |
+----------+
|
| HEX('ä') |
|
+----------+
|
| E4 |
|
+----------+
|
It also returns the same latin1 code. So far so good.
Now I use a prepared statement with a string literal as a source:
PREPARE stmt FROM 'SELECT HEX(''ä'')'; |
EXECUTE stmt; |
+-----------+
|
| HEX('ä') |
|
+-----------+
|
| C3A4 |
|
+-----------+
|
It returns a different result. C3A4 is a utf8 code for "U+00E4 SMALL LETTER A WITH DIAERESIS". Conversion from latin1 to utf8 happened.