MySQL connection not set to UTF-8?

I believe, Ghost does not set the connection to utf8 when connecting to the MySQL server, which results in UTF-8 characters being displayed as “?” or similar characters, if the MySQL server itself is not configured to use UTF-8 as default. I am not 100% sure if this is an issue with Ghost or something else, but I’ve got the feeling that it is a Ghost problem.

I have converted my Ghost database to MySQL locally. Everything was fine there. Then I moved the database to a different server, where the characters where then interpreted wrongly.

I tripple-checked that the database and the tables used for Ghost were set to UTF-8, that the data in the tables were correctly encoded, that the output HTML page is served with UTF-8 encoding etc. Everything was as it should be.

The only difference between my local MySQL server and the production server was that in the server configuration itself the local server had all its defaults set to utf8 and the production server was set to Latin-1. Only when I changed the production MySQL server config and restarted it, the content was displayed correctly. I did not have to change anything else or re-import the tables.

Because the only way to fix this was to change the MySQL server config and any other MySQL client could read the UTF-8 encoded data correctly without the defaults being changed, I believe that Ghost doesn’t set the connection to UTF-8, something like SET NAMES utf8.

My database object in the config.js file:

database: {
    client: 'mysql',
    connection: {
        host: '...',
        port: '...',
        user: '...',
        password: '...',
        database: '...',
        charset: 'utf8'
    }
}

I could solve this issue, so that’s no personal problem for me, but I think it should always work for anybody, no matter what the MySQL default settings are. Some users may not have access to the config or must use a shared MySQL server where they can’t change the defaults.

[ErisDS]

I was just re-reading this and figured I should point out, the steps above only work if your database was set to latin1 - there are other possibilities so you should check what your DB was set to before running anything like this as you could end up triple-encoding 🤐

[kirrg001]

Closing. We have opened a migration path issue, which keeps track of the notes here, see #8141.