---
slug: "mysql-80-client-django-character-set-latin1-utf8mb4"
title: "When Connecting to a MySQL 5.7 Server Using a MySQL 8.0 Client, Charset Specification Cannot Be Done from the Client"
description: "When a MySQL 8.0 client connects to a MySQL 5.7 server, the client overrides charset to utf8mb4 and breaks Japanese on a latin1 server — here is the fix."
url: "https://www.ytyng.com/en/blog/mysql-80-client-django-character-set-latin1-utf8mb4"
publish_date: "2021-08-07T07:03:55Z"
created: "2021-08-07T07:03:55Z"
updated: "2026-05-11T13:07:32.895Z"
categories: []
keywords: ""
featured_image_url: "https://media.ytyng.com/resize/20230812/f230b38a422d4478a7e22499907c6640.png.webp?width=768"
has_video: false
has_music: false
video_urls: []
music_urls: []
lang: "en"
---

# When Connecting to a MySQL 5.7 Server Using a MySQL 8.0 Client, Charset Specification Cannot Be Done from the Client

<p></p>
<p><a href="https://blog.kamipo.net/entry/2021/02/21/193128" target="_blank">When connecting to a MySQL 5.7 server with a MySQL 8.0 client, the charset may not be set</a></p>
<p>&uarr; Detailed explanation available here. As described in the title, the character set cannot be specified from the client side.</p>
<p></p>
<h2>Overview</h2>
<p>When I upgraded Ubuntu from 18 to 20 and retrieved data from MySQL 5.7 RDS using Django running on it, all Japanese characters were displayed as ????????.</p>
<p></p>
<h2>Library Version</h2>
<pre>$ cat /etc/issue<br />Ubuntu 20.04.2 LTS \n \l<br /><br />$ apt list --installed | grep mysql<br /><br />WARNING: apt does not have a stable CLI interface. Use with caution in scripts.<br /><br />default-libmysqlclient-dev/focal,now 1.0.5ubuntu2 amd64 [installed]<br />libmysqlclient-dev/focal-updates,focal-security,now 8.0.26-0ubuntu0.20.04.2 amd64 [installed,automatic]<br />libmysqlclient21/focal-updates,focal-security,now 8.0.26-0ubuntu0.20.04.2 amd64 [installed,automatic]<br />mysql-client-core-8.0/focal-updates,focal-security,now 8.0.26-0ubuntu0.20.04.2 amd64 [installed]<br />mysql-common/focal,now 5.8+1.0.5ubuntu2 all [installed,automatic]</pre>
<p></p>
<h2>Investigation</h2>
<p>As a test,</p>
<pre>./manage.py dbshell</pre>
<p>and then,</p>
<pre class="p1">mysql&gt; show variables like "%chara%";</pre>
<p>it shows</p>
<pre>mysql&gt; show variables like "%chara%";<br />+--------------------------+-------------------------------------------+<br />| Variable_name | Value |<br />+--------------------------+-------------------------------------------+<br />| character_set_client | latin1 |<br />| character_set_connection | latin1 |<br />| character_set_database | utf8mb4 |<br />| character_set_filesystem | binary |<br />| character_set_results | latin1 |<br />| character_set_server | latin1 |<br />| character_set_system | utf8 |<br />| character_sets_dir | /rdsdbbin/mysql-5.7.33.R2/share/charsets/ |<br />+--------------------------+-------------------------------------------+<br />8 rows in set (0.01 sec)</pre>
<p>This is the result.</p>
<p></p>
<p>Ideally, character_set_client and other character sets should be set to utf8mb4. In fact, doing the same thing on ubuntu18 results in utf8mb4.</p>
<p></p>
<p>Also, this phenomenon of character sets becoming <code>latin1</code> does not change even if you add <code>--default-character-set=utf8mb4</code> to the <code>mysql</code> command on ubuntu18 or write character set settings in <code>/etc/mysql/conf.d/mysql.cnf</code>.</p>
<p></p>
<h2>How to forcefully handle it on the client side</h2>
<p>After connecting to mysql,</p>
<pre>SET NAMES utf8mb4</pre>
<p>then the Japanese characters will not be garbled.</p>
<p>Incidentally, since it is undesirable to issue unnecessary SQL commands in a production environment, this is not done in production. However, in Django, this can be achieved by setting the DB configuration as follows:</p>
<pre>DATABASES = {<br />  'default': {<br />    'ENGINE': 'django.db.backends.mysql',<br />    ...<br />    'OPTIONS': {<br />        'charset': 'utf8mb4',<br />        'init_command': 'set names utf8mb4',<br />    },<br />  },<br />}</pre>
<p></p>
<h2>Solution</h2>
<p>In this state, it seems impossible to avoid it with client-side settings (other than the above SET NAMES utf8mb4), so <strong>set the character set on the server side</strong>. In the case of RDS, in the parameter group,</p>
<pre>character_set_client<br />character_set_connection<br />character_set_database<br />character_set_results<br />character_set_server</pre>
<p>set all of these to <code>utf8mb4</code>.</p>
<p>In reality, since there is usually no reason to use a character set other than utf8mb4, it feels like this should have been done from the beginning.</p>
<p>These parameters have a dynamic attribute, so they can be applied without restarting RDS after setting.</p>
<p></p>
