MySQL command‑line client shows garbled Unicode characters in error messages and help output
0 reputation · 30 Sept 2021, 22:52 UTC
0 reputation · 30 Sept 2021, 22:52 UTC
Goal: verify that Unicode characters typed at the mysql prompt are echoed correctly and that error messages and help text display without replacement symbols, assuming a MySQL 8.0 client connected to a server whose default character set is latin1.
Constraints: the client’s --default-character-set option only affects the connection character set after the handshake; the server may still send results in its own charset unless session variables are changed, and the pager command does not re‑encode output for external pagers. Additionally, terminal transliteration can interact with MySQL’s encoding, making it unclear which combination of client flags and session settings reliably restores proper UTF‑8 display across all interactive features.
Questions: Does specifying --default-character-set=utf8mb4 alone ensure correct echo of Unicode input and proper rendering of error messages? Is it also required to execute SET NAMES utf8mb4 (or set character_set_client/results) after connection to fix server‑side encoding? When using the pager command with an external program such as less, must the terminal’s LESSCHARSET or the client’s character_set_results be aligned to prevent loss of accented characters in piped output?
35275 reputation · 01 Oct 2021, 04:27 UTC
Specifying --default-character-set=utf8mb4 alone does **not** guarantee correct Unicode echo or error‑message display. It only sets the client‑side character set for the initial handshake; the server may still return results in its own charset (latin1) unless the session variables are overridden after connection.
--default-character-set for the handshake, which sets character_set_client, character_set_connection and character_set_results to the given value.SET NAMES (or individual SET character_set_* statements).character_set_results; therefore they will appear garbled if that variable remains latin1 while the terminal expects UTF‑8.pager command with an external program such as less, the client’s character_set_results must match the terminal’s encoding, and the pager’s LESSCHARSET should be left unset or explicitly set to utf-8 to avoid double re‑encoding.LANG=en_US.UTF-8) is required; otherwise even correct MySQL settings will show replacement symbols.mysql --default-character-set=utf8mb4 -u your_user -pSET NAMES utf8mb4;
(Equivalent: SET character_set_client=utf8mb4, character_set_results=utf8mb4, character_set_connection=utf8mb4;)STATUS;
Look for Character set: utf8mb4 under Server characterset and Client characterset.INSERT INTO test (col) VALUES ('😀','é','中');
SELECT * FROM test;
The characters should appear correctly in the terminal.pager less -R
Then run a query that returns Unicode data; less should display the characters without replacement symbols. If you see mojibake, check:
echo $LANG – should end with .UTF-8 or .utf8.echo $LESSCHARSET – ideally unset or set to utf-8.nopager
Verify Unicode works, then re‑enable the pager and compare.If the terminal locale is not UTF‑8 (e.g., LANG=C), then even correct MySQL settings will show garbled output. In that case you must adjust the terminal’s locale or launch the terminal in a UTF‑8 locale before proceeding.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.