My b2evolution Version: 2.x

/**
 * The internal charset. It's used to convert user INPUT/OUTPUT and database data into for
 * internal use.
 *
 * Setting it to an empty string means "follow the user's charset", which gets
 * taken off his locale (INPUT/OUTPUT charset; {@link $io_charset}).
 *
 * If you don't know, don't change this setting.
 *
 * This should be supported by {@link mb_list_encodings()}.
 */
$evo_charset = '';

/**
 * Request a specific charset for the client connection.
 *
 * This will issue a MySQL SET NAMES command. This must be a MySQL charset. Example: 'latin1' or 'utf8'
 *
 * If left empty, the default charset will be used. The default here is
 * the default set your MySQL Server.
 *
 * This should match the charset you are using internally in b2evolution.
 * This allows b2evo to work internally in a different charset from the database charset.
 * Example: b2evo will use latin1 whereas the database uses utf8.
 *
 * TODO: This gets overridden anyway with "SET NAMES $evo_charset" in init_charsets() and gets only used until that!
 *       So, does it make sense to configure it here? Or shouldn't it get overridden, if set explicitly here?
 */
$db_config['connection_charset'] = 'utf8';

Question:
HTML proper format is utf-8, while
MySQL format is utf8

If $db_config... gets overridden by $evo_charset, which is taken from the user's localle setting, where the format is HTML (thus it is utf-8 not utf8), then $db_config becomes utf-8, which the MySQL doesn't recognize (I presume).

Seems a conflict to me if I understood it correctly (and presumed correctly).

Any clarifications?

If I explicitly set $evo_charset to utf-8, it will also override $db_config... if I set it to utf8, its not the proper way for HTML (although it works because browsers have a "fall-back" for typos).