Charset

 Codage de la base de données

Le codage des bases de données était autrefois en iso ; mais l’habitude s’est définie en SPIP 1.9 d’encoder la base en UTF-8, et une action automatisait ce traitement en SPIP 2.x.

Car on constate que des bases de données encore encodées en iso peuvent bloquer l’exécution de SPIP : il est donc vivement conseillé depuis 2.1 d’utiliser l’utf, et c’est supposé effectif en SPIP 3.

Un récent article sur Contrib rappelle le moyen d’effectuer cette transformation, si vous êtes encore dans ce cas...

 Le charset des squelettes

Votre navigateur sélectionne par défaut l’encodage utilisé pour afficher les pages HTML en fonction de vos paramètres système (sur le poste client du visiteur).
Pour garantir une bonne présentation des textes contenus dans la base de données, il est possible de forcer l’encodage à lui faire utiliser avec l’option #CHARSET dans votre head .

 Le codage des squelettes

Les squelettes de SPIP sont des fichiers HTML, qui n’acceptent que des caractères ASCII 7 bits, or ils sont encodés sur le poste du webmestre, et particulièrement en France, les libellés utilisent des caractères spéciaux (nos lettres accentuées..) :
 il est donc nécessaire de les encoder, et la norme en HTML utilise des combinaisons de codes encadrés entre un & au début, et un ; en fin :
par exemple nos minuscules accentuées ( à , é ou è ) seront expressément codées en à , é ou è...
 si vous utilisez des chaines de langues, vous aurez remarqué la meme contrainte,
alors que vous n’y avez jamais pr^té attention en écrivant vos articles sous SPIP.

 Encodage divers dans des tables

Il s’agit ici d’un exemple apparue sur la liste

Cependant, la base et les tables sont en CHARACTER SET utf8 COLLATE
utf8_unicode_ci ;

Ma base SPIP est quand à elle en utf8_general_ci ;

on pourrait tenter dans fichier de connection dans /config, essaie peut être d’y insérer :
mysql_query("SET NAMES ’utf8’") ; (comme derniere instruction)

L’explication de Gildas
Les deux sont UTF8 (c’est l’encodage des textes) donc pas de
souci/différence de traitement des textes qui sont encodés
pareillement. (CHARACTER SET) : La collation (COLLATE) indique trois
choses :
 Le jeu de caractères dans dans lequel les résultats sont servis
(ceci normalement n’est utile que si les tables/bases ont des jeux de
caractères différents et/ou quand le client ne précise pas son jeu de
caractères, sinon c’est ce dernier qui l’emportait.) ici, pas de souci
puisqu’on reste en UTF8
 L’ordre alphabétique de tri (c’est essentiellement pour la clause
ORDER BY, mais ça peut dans certains cas influencer les critères de
comparaison ou les groupements). Dans ton cas, tu as une base qui
utilise l’interclassement général/générique (pour les encodages ISO
Latin ou ASCII c’est l’équivalent du tri de base appelé parfois C et
qui s’appuie sur les codes des caractères) et l’autre qui utilise
l’interclassement Unicode (en général ça s’appuie sur les points de
code aussi —et il n’y a pas de différence quand on encode en UTF ou
UCS— avec quelques exceptions/subtilités qui ne concernent pas
vraiment nos alphabets...) Cela ne devrait pas poser de souci ici
(d’où je ne vois pas trop ton inquiétude même si j’aimerais aussi
avoir la réponse à la question)
 La sensibilité à la casse (cs) ou non (ci) comme ici. Cela influence
surtout les opérations de comparaison (donc le tri dans ce cas précis)
surtout lors de l’usage du critère LIKE. Ici les deux ont la
sensibilité à la casse qui est inactive donc pas de souci pour les
résultats des requêtes.