Handbuch:$wgDBmysql5

MySQL-spezifisch: $wgDBmysql5
Set to true to set MySQL connection into UTF-8 encoding (experimental)
Eingeführt in Version:	1.5.1 (r11508)
Veraltet in Version:	1.31.0 (Gerrit change 437312; git #7271d50b)
Entfernt in Version:	1.33.0 (Gerrit change 498644; git #26118ad0)
Erlaubte Werte:	(Wahrheitswert)
Standardwert:	false
Andere Einstellungen: Alphabetisch | Nach Funktion

Details

Beachte vorab: Egal, was du hier einstellst, MediaWiki verwendet intern immer die UTF-8-Kodierung. Everything MediaWiki sends to the database is always in UTF-8 encoding.

Set to true to send 'SET NAMES=utf8;' on connect. If set to false, 'SET NAMES binary;' will be used, which is the default and so recommended. Generally you should not change this value once installed -- if you created the wiki in Binary or UTF-8 schemas, you should keep this off. The feature is experimental and with your settings the data is sent (and so also finally saved) with the right encoding anyway.

When your database columns do not use UTF-8 or binary encoding, but e.g. latin1, then setting $wgDBmysql5 to true is important. Grund: MediaWiki internally always uses UTF-8 encoding. Everything MediaWiki sends to the database is always in UTF-8 encoding. If your DB now does not use UTF-8 or binary, but something else (like latin1), the UTF-8 content from MediaWiki will be written into latin1 columns. When in that case you set $wgDBmysql5 to true, MySQL will convert the UTF-8 data coming from MediaWiki and will store it in the encoding, which is correct for the database columns. But if in that case you set $wgDBmysql5 to false, MySQL will see all data coming from MediaWiki as binary (thus not having any encoding) and will write it into the database columns without charset conversion. So then you would end up with UTF-8 content in latin1 columns and that is what you do not want!

(See also $wgDBTableOptions which in recentish versions will include the table type and character set used when creating tables.)

May break if you're upgrading an existing wiki and then change this setting. Symptoms of brokenness are likely to include incorrect behavior with page titles, usernames, comments etc containing non-ASCII characters. Might also cause failures on the object cache and other things.

If you are still using MySQL 4, your wiki was created with the old "MySQL 4 backwards-compatible UTF-8" schema and $wgDBmysql5 should stay off; your MySQL version does not support it anyway.