fonction setlocale en C

Bonsoir,

Quand on disait sur l’autre sujet que setlocale n’a pas d’influence sur la sortie en console, ton exemple montre de toute évidence le contraire. Alors, à défaut d’explications logiques, essayons de décortiquer.

Premier exemple.
L’affichage de Ã, correspondant au caractère 195 de la table CP1252, est correct parce que la table par défaut pour le français correspond avec l’encodage actuel de ta console.
Au code 132 correspond bien „ en CP850 et CP1152.

Second exemple:
Le ├ correspond au caractère 195 de la table CP437
Le ä correspond aussi au code 132 de la table CP437

Troisième exemple:
Au code 195 de la table CP1253 correspond en réalité le gamma majuscule

IL y a donc bien une traduction de page de code quand on affiche des caractères en console. Par contre, si tu envoies la sortie vers un fichier, tu verras que setlocale n’a aucune influence, les octets 0xC3 et 0x84 seront trois fois inchangés.

Maintenant, pourquoi le „ et le gamma majuscule ne s’affichent pas ? Les deux ont un point de code unicode >255, donc ils ne peuvent pas s’afficher quand ta console est réglée en CP850 ou CP1252. Par contre ils sont correctement affichés si tu bascules la console en UTF-8 (chcp 65001). Plutot que d’afficher un vilain carré quand un caractère n’est pas affichable, il semble exister un mapping de caractères visuellement proches. G et " sont choisis à la place du gamma majuscule et de „.

En conclusion, tout le truc est assez foireux. Je fais l’hypothèse suivante:

1. Tu envoies l’octet 195, qu’on suppose être en CP1252, car c’est l’encodage OEM natif de ton windows
2. IL y a une traduction de CP1252 vers CP850, car le CP850 est l’encodage MS-DOS associé à la locale française
3. IL y a une traduction de CP850 vers la page de code actuellement définie dans ta console, CP850 par défaut (donc pas de traduction), ou bien CP1252, ou encore CP65001 pour l’UTF-8.

Voilà. Je laisse les experts confirmer ou infirmer.

@QuentinC Je ne sais pas si tu as tout juste, mais j’ai réfléchis sur ta proposition et elle me semble très pertinente. En effet, je fais le test suivant :

int main()
{
	SetConsoleOutputCP(1252);
	printf("GetConsoleOutputCP() : %d\n\n", GetConsoleOutputCP());

	char* encodage = setlocale(LC_ALL, "French_France.1252");
	if (encodage != NULL) printf("locale    : %s\n", encodage);
	afficherChaine();

	return 0;
}

Je n’ai changé que le main, tout le reste est identique au code donné dans le message initial. Retour :

GetConsoleOutputCP() : 1252

locale    : French_France.1252
chaine[0] : C3, Ç
chaine[1] : 84, 

Cela apporte un élément flagrant allant dans ton sens, car 0xC3 (195) est un Ã dans la table 1252. Ce même caractère est codé C7 dans la table 850. Quand on revient dans la table 1252… Le 0xC7 est un Ç !!

Je pense qu’en effet cela prouve qu’en l’occurrence, j’essaye de tout mettre en 1252, pourtant il y a bien des traductions dans la page 850 qui viennent s’incruster toutes seules.

Je pousse le test plus loin J’ai choisi consciencieusement la table CP1258 pour ma locale (une table obscure peu utilisée), j’ai mis mon terminal en CP1252 et enfin j’ai envoyé le caractère 0xC1. Si tu veux faire le test, il faut changer ces lignes dans le programme : char chaine[TAILLE] = "\xC1";, char* encodage = setlocale(LC_ALL, "french_france.1258");.

C’est un Á en 1258, qui est converti en 850, ce qui donne 0xB5 pour le même caractère. Enfin, l’octet est déchiffré avec la console en 1252 ce qui donne un µ. Merveilleux, c’est ce que m’affiche mon terminal.

Pour reformuler ton idée :

• on regarde la locale du programme et l’octet correspondant au caractère à afficher est éventuellement modifié pour correspondre à un caractère identique dans la table CP850.
• la page de code en vigueur dans le terminal détermine comment sera affiché l’octet précédemment obtenu : on associe bêtement le caractère associé à l’octet dans la table et on l’affiche.

Merci pour votre aide aussi bien ceux qui ont aidé sur le précédent sujet et particulièrement à @QuentinC qui je pense m’a épargné quelques heures de recherches

Si toutefois vous avez des ressources à proposer qui vont dans le détail de ce sujet je suis toujours preneur. En dépit de nombreuses recherches sur le net, je n’ai pas réussi à trouver de la documentation donnant une réponse "officielle" à ma question.

CONCLUSION : il est parfaitement inutile de changer la page de code de la console, cela n’amène que des complications. Je pense qu’il faut laisser la page en 850 par défaut, et mettre la locale du programme à french. Comme ça, Windows se charge tout seul de convertir les caractères dans la page du terminal et c’est réglé. De plus, il apparaît que la locale du programme n’affecte pas vraiment le comportement de printf, c’est Windows qui me semble-t-il, fait la conversion vers les caractères qui collent, compte tenue de la locale du programme. Cette conclusion est rassurante car en effet, je n’avais jamais vu nulle part que le comportement de printf était affecté par setlocale.