How to Fix MySQL Error 1115: Unknown Character Set

ERROR 1115 (42000): Unknown character set: '<name>' is raised when a SQL statement or client connection references a character set name that MySQL does not recognize or has not loaded. The error symbol is ER_UNKNOWN_CHARACTER_SET.

Impact

The statement that triggered the error is rejected immediately and no changes are made to the schema or data. Attempts to create or alter a table with an unsupported character set, set a session character set, or establish a connection using an unknown charset will all fail with this error.

Developers commonly encounter this when migrating a schema dump from one MySQL version or distribution to another, when a client driver requests a character set that the target server does not have compiled in, or when a CREATE TABLE script is written against a newer MySQL version and run against an older one (for example, using utf8mb4 on a MySQL 5.0 server that predates its introduction).

Common Causes

Typo or incorrect character set name. MySQL character set names are specific strings such as utf8mb4, latin1, utf8, ascii, binary. A misspelling like utf-8, UTF8MB4 (MySQL names are case-insensitive but the name itself must be valid), or unicode will trigger the error.
Character set not available on the target server. utf8mb4 was introduced in MySQL 5.5.3. Running a schema dump that uses utf8mb4 against MySQL 5.0 or 5.1 will raise error 1115.
Minimal or stripped MySQL installation. Some stripped-down builds or container images omit character set data files (/usr/share/mysql/charsets/). If the --character-sets-dir path is missing or the .xml files are absent, MySQL cannot load those character sets.
Client SET NAMES or charset() call with an unsupported name. Application code or ORM configuration that issues SET NAMES utf8mb4 on a server that doesn't support it will fail at connection time, causing frameworks like Laravel, Django, and ActiveRecord to throw a wrapped version of this error.
mysqldump or schema file with an explicit DEFAULT CHARSET clause. Dump files often include lines like DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci. Replaying this dump against an older or restricted server fails if the charset is unavailable.

Troubleshooting and Resolution Steps

Check which character sets the server supports.
```
SHOW CHARACTER SET;
-- or filter:
SHOW CHARACTER SET LIKE 'utf8%';
```
If the character set you need is not in the output, the server either doesn't support it or hasn't loaded it.

Verify the exact character set name in the failing statement. Check for common mistakes:

-- Wrong (hyphen, not supported):
CREATE TABLE t (c VARCHAR(100)) CHARSET=utf-8;

-- Correct:
CREATE TABLE t (c VARCHAR(100)) CHARSET=utf8mb4;

Check MySQL server version when using utf8mb4.
```
SELECT VERSION();
```
utf8mb4 requires MySQL 5.5.3 or later. If the version is older, use utf8 as a workaround (with the caveat that MySQL's utf8 is a 3-byte subset of UTF-8 and cannot store characters outside the Basic Multilingual Plane).
Substitute the character set in a dump file before replaying it. If you received a dump from a newer MySQL instance:
```
sed 's/DEFAULT CHARSET=utf8mb4/DEFAULT CHARSET=utf8/g; s/COLLATE=utf8mb4_unicode_ci/COLLATE=utf8_unicode_ci/g' dump.sql > dump_compat.sql
mysql -u root -p mydb < dump_compat.sql
```
Only do this if you have confirmed the data contains no 4-byte Unicode characters (emoji, certain CJK ideographs, etc.).
Verify the character set data directory exists and is populated.
```
SHOW VARIABLES LIKE 'character_sets_dir';
```
Then check that the directory exists and contains .xml files (e.g., utf8mb4.xml). On Linux:
```
ls /usr/share/mysql/charsets/
```
On Debian/Ubuntu-based systems, reinstalling the package restores missing files:
```
sudo apt-get install --reinstall mysql-server
```

Fix application-level SET NAMES configuration. For ORM connection configuration, use the character set name exactly as MySQL expects it:

# SQLAlchemy (Python)
engine = create_engine(
    "mysql+pymysql://user:pass@host/db?charset=utf8mb4"
)

// Laravel database.php
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',

Additional Information

The SQLSTATE code 42000 indicates a syntax or access rule violation, which is the same class used for general SQL syntax errors.
A related error is ER_UNKNOWN_COLLATION (1273), which fires when the character set itself is valid but the specified collation (e.g., utf8mb4_0900_ai_ci) is not available on that server version. MySQL 8.0 introduced several new collations that do not exist on 5.7.
MySQL's utf8 character set is a legacy alias for a 3-byte-only variant of UTF-8. Code that must store emoji or supplementary characters should use utf8mb4. MySQL 8.0 changed the default server character set to utf8mb4.
When using mysql CLI flags, the charset is specified as --default-character-set=utf8mb4. An invalid value here will surface as error 1115 before any SQL is executed.
Docker images based on minimal base images (Alpine, distroless) may omit the charsets directory. The official mysql and mariadb Docker Hub images include full charset support.

Frequently Asked Questions

Why does my dump import work locally but fail on the production server? The two servers are likely running different MySQL versions. A dump generated from MySQL 5.7 or 8.0 often includes utf8mb4 charset declarations that don't exist on older 5.0/5.1 servers. Run SELECT VERSION() on both servers and compare. If the production server is older, either upgrade it or edit the dump to use a compatible charset.

Is utf8 a valid character set in MySQL? Yes, utf8 is valid but it is a 3-byte subset of real UTF-8, not full Unicode. It cannot store characters with code points above U+FFFF (emoji, some CJK characters). Use utf8mb4 for full UTF-8 support on MySQL 5.5.3+.

Can I add a missing character set to MySQL without upgrading? No. Character set support is compiled into or distributed with the MySQL server. You cannot install additional character sets at runtime. Your options are to upgrade the server, use a different available character set, or switch to a MySQL distribution that includes the required charset.

My ORM throws a different exception — how do I tell if it is error 1115 underneath? Enable query logging or check the underlying database error code. In Python with PyMySQL, inspect e.args[0] on a pymysql.err.OperationalError; the first element is the MySQL error number. In Java with JDBC, call e.getErrorCode() on the SQLException. If the code is 1115, the character set name in your connection string or schema DDL is the problem.