Discussion :

[ShinobiX1]

Bonjour

Je cherche comment afficher les caractères étendus en c++ dans la console
Comment faire ça?


Merci d'avance

[bacelar]

"caractères étendus", c'est très vague.

Il n'y a rien de standard.

Il faut être rigoureux avec l'encodage et la police utilisé.

[ShinobiX1]

Bonjour

Je voudrais pouvoir afficher ces symboles



comment faire ?

Merci

[Luc Hermitte]

Configure ta console pour travailler en CodePage1252 au lieu de l'OEM 850. -> chcp 1252
Ou ne te prends pas le choix avec ça, cela n'en vaut pas la peine.

[ShinobiX1]

comment on configure la console?
je n'ai aucune idée

[ShinobiX1]

J'ai trouvé comment afficher les symbols ! donc mon problème est résolu

[LittleWhite]

Ça serait sympa de transmettre la méthode que vous avez trouvé.

[ShinobiX1]

voici la méthode pour afficher les symboles

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#include <windows.h>
#include <iostream>
 
using namespace std;
 
int main()
{
    for (int i=1; i<256; ++i)  
        cout<<  (char) i ;
    }
return 0;
}

[Bousk]

Tout ce que je vois c'est une boucle qui affiche les 255 caractères ASCII.
Et qu'il faudrait écrire for (unsigned char c = 0; c < 256; ++c).

[Médinoc]

il faudrait écrire for (unsigned char c = 0; c < 256; ++c).

Je n'ai pas testé, mais ça sent la boucle infinie, ça... Le code avec int était correct.

[ternel]

pour information, l'ASCII ne contient que 128 caractères, les 128 suivants étant fortement dépendant de la "locale".

[Bousk]

effectivement, p-e plutôt comme ça en jouant sur l'overflow
for (unsigned char c = 1; c; ++c)

[Médinoc]

Je me demande si c'est défini, par contre...

[fenkys]

pour information, l'ASCII ne contient que 128 caractères, les 128 suivants étant fortement dépendant de la "locale".

L'expérience m'a montré une situation pire que cela. Pour les caractères supérieurs à 128, le bits de poids fort n'est pas forcement conservé selon le compilateur et les optimisations. J'ai récemment eu le cas d'un bug causé par un 0xC7 se transformant 0x57 lors de la transmission d'un char en paramètre de fonction.

Utiliser des char pour des caractères non ascii est vraiment une mauvaise idée.

[Neckara]

Bonjour,

J'ai récemment eu le cas d'un bug causé par un 0xC7 se transformant 0x57 lors de la transmission d'un char en paramètre de fonction

C'est vraiment étrange, d'autant plus qu'un char est avant tout un entier.
Est-ce que ce cas c'est produit dans le monde de l'embarqué ? Ils ne respectent pas toujours les normes .

[gl]

C'est vraiment étrange, d'autant plus qu'un char est avant tout un entier.
Est-ce que ce cas c'est produit dans le monde de l'embarqué ? Ils ne respectent pas toujours les normes .

Vu de la norme, la plage garantie pour un char est [0, 127] ([0,255] pour les unsigned char et [-127, 127] pour les signed char). Y mettre autre chose qu'une de cas valeurs entières ou qu'un des caractères définis par la norme n'est pas portable.

En particulier, considéré qu'un plain char est signé est une source classique de problème même dans les environnements respectant la norme (dans ce cas, c'est le code qui n'est pas conforme pas l'environnement).

[Neckara]

D'accord, je pensais que la norme imposait que le char soit un signed char ou un unsigned char (avec conversion implicite).

Mais comme char est un entier, le comportement me paraît tout de même étrange.
La norme indique une plage minimale, mais si on dépasse cette plage, je pense que le comportement devrait rester cohérent et garanti par la norme.

Si on donne, dans l'implémentation, une plage [[0 127]], on fait en sorte que le char ne puisse contenir que des valeurs de la plage [[0 127]]. Si on tente de lui mettre 128, on fait en sorte qu'il contienne 0.

Sinon, cela voudrait dire qu'il serait possible d'avoir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
char c = 128;
char d = c;
if (c != d)
     ; // on se retrouve ici.

Ou pour être plus "clair", c'est comme si 0x80 en mémoire pouvait avoir deux valeurs : 0x80 ou 0x00 selon l'optimisation du compilateur/où on est dans le code.

Ce serait complètement illogique.

[Jean-Marc.Bourguet]

L'expérience m'a montré une situation pire que cela. Pour les caractères supérieurs à 128, le bits de poids fort n'est pas forcement conservé selon le compilateur et les optimisations. J'ai récemment eu le cas d'un bug causé par un 0xC7 se transformant 0x57 lors de la transmission d'un char en paramètre de fonction.

ECM? La meilleure explication que je vois est que le comportement observé n'est pas celui que tu décris. Il y a bien la possibilité de l'utilisation d'un compilateur non comforme qui utilise des char sur 7 bits. J'en connais même un mais je vois mal quelqu'un 1/ utiliser cette plateforme (PDP-10), 2/ la programmer en C et pas en assembleur, BLISS ou Fortran, 3/ utiliser le flag qui active ce comportement non conforme et 4/ considérer le résultat comme un bug.

Un compilateur pour n'importe quelle plateforme a moitié raisonable va conserver le bit de poid fort, meme s'il ne compile que du C K&R (il y a eu beaucoup de problemes pour rendre "8 bit clean" les programmes écrits en C, mais c'est parce qu'une technique habituelle -- meme emacs un des rois des programmes portables en C l'utilisait -- etait de utiliser ce 8ieme bit comme flag et donc un compilo qui modifierait dans le code genere ou dans sa lib standard ce 8ieme bit aurait cause des problemes il y a bien longtemps).

Utiliser des char pour des caractères non ascii est vraiment une mauvaise idée.

Je fais ça depuis 20 ans, meme avec des jeux multi-bytes, j'ai jamais eu de problemes une fois que j'ai compris le modele que le C utilise pour sa gestion des jeux de caracteres (j'admets avoir mis plus de temps que je l'aurais voulu avant d'avoir compris ce modele).

Ça serait sympa de transmettre la méthode que vous avez trouvé.

La table qu'il a donne est celle la CP 850. Si je comprends bien le message de Luc, c'est celle par defaut de la console et donc il n'y a pas besoin de la configurer. (Je suppose que Luc pensait que l'OP avait un code source écrit avec CP 1252 et ne voyait donc pas des littéraux correctement).

(En passant, "Code Page" -- CP -- est la classification IBM reprise par Microsoft de ce qu'on appelle ailleurs des jeux de caracteres code, coded character set, charset, codeset. Il y en a une serie qui sont basee sur l'EBCDIC.)

[Luc Hermitte]

Oui, c'était bien mon idée. Aujourd'hui les OP écrivent en CP1252 mais exécutent sur la console de Windows qui est toujours en OEM850.

[Médinoc]

À noter que la table affichée n'est pas la 850 (Europe occidentale), mais la 437 (États-Unis): Elle comporte des coins mixtes qui ont été remplacés par d'autres caractères dans la 850.