Discussion :

[hurukan]

Bonjour,

Je suis en train de me prendre la tête avec la fonction wprintf() qui est censée apporter une amélioration concernant le traitement des caractères accentués dans les chaines de caractères en C. Le constat est le suivant: quand nous essayons d'aligner des champs (type formulaire) avec mes élèves, si nous avions le malheur d'avoir un caractère accentué dans la chaine de caractères à afficher, nous avons un ou plusieurs décalages vers la gauche résultant du fait que printf() fait la conversion unicode (2 bytes si je ne me trompe pas) --> ascii (1 byte) et ne restitue pas le byte perdu dans la chaine.
Ainsi une chaine de 30 caractères devient une chaine de 29 caractères après être passée dans le printf(). Ce qui explique le décalage dans les champs de formulaires alignés...

Je ne sais pas vous faire un topo dans cette misère de contrôle où il est impossible d'aligner les champs (la faute à php ????)

Mais en gros:

Nom: [ chaine de 30 caractères alignée sur la droite]
Adresse [ chaine de 30 caractères qui contient des accents]

Le champs Nom et Adresse ne sont plus alignés (et pour cause la chaine contenant l'adresse ne fait plus 30 caractères mais une taille inférieure correspondant à 30-nombre de caractères accentués.).

Nous essayons de nous "dépatouiller" avec [B]wprintf[()/B] mais c'est encore pire, là lorsque nous essayons d'afficher la chaine, la fonction wprintf() n'affiche que la première lettre ou remplace les accents par '?'... pénible...

Devrais-je abondonner C et passer à Java en mode console ?
Ou obliger mes élèves (moi ça va je maitrise) à écrire tous leurs programmes en anglais ^^

Je n'ai pas encore bien cherché sur le net, et dans la littérature, disons que ça me gonfle.

[kwariz]

bonsoir,

ça gonfle un prof de chercher un peu sur le net ou dans «la littérature» ???

Enfin bref, le plus simple (s'il ne s'agit que d'un exercice dont le thème central n'est pas unicode et compagnie) est d'utiliser un encodage monobyte en mode console, style ISO8859-1 par exemple.

[gangsoleil]

Bonjour,

Pour information, dans toutes les entreprises ou j'ai travaille, il est strictement interdit d'utiliser les caracteres accentues dans le code. Pas plus d'ailleurs que de mettre des commentaires en cyrillique ou en grec.

[Jean-Marc.Bourguet]

0/ Les problemes d'encodage sont complexes, tout le monde les fuit autant que possible.
1/ Il faut travailler avec des wchar_t si on ne veut pas avoir a gerer des encodages multibytes. Mais attention, avec les caracteres combinants (utilises par Unicode pour gerer les accents), une lettre et un accent dessus peuvent etre encode comme deux caracteres.
2/ Normalement, si on fait un setlocale(LC_ALL, "") en debut de programme et que tout est correctement configure, ca devrait marcher
3/ Ma comprehension est que s'attendre a ce que quelqu'un configure correctement les choses sous Windows pour qu'une application console fonctionne correctement sans code supplementaire specifique a Windows est illusoire.

[matafan]

Aussi, printf() n'est pas sensé faire de conversion. Il affiche la chaîne qui lui est passée (après traitement des %), point.

[Jean-Marc.Bourguet]

Aussi, printf() n'est pas sensé faire de conversion. Il affiche la chaîne qui lui est passée (après traitement des %), point.

Il peut faire une conversion (la plus courante etant l'insertion de CR avant chaque LF pour les fichiers textes, on peut envisager aussi une conversion UTF-8 vers UTF-16 ou l'ajout d'un BOM).

[matafan]

Tu as raison. J'avais toujours pensé que c'était le compilo qui convertissait les \n en CR LF, mais ce n'est effectivement pas le cas puisque le standard précise explicitement que les caractères spéciaux comme \n doivent pouvoir être stockés dans un seul char. La conversion est faite par les routines d'affichage :

Each of these escape sequences shall produce a unique implementation-defined value which can be stored in a single char object. The external representations in a text file need not be identical to the internal representations, and are outside the scope of this International Standard.

[Jean-Marc.Bourguet]

En passant, meme la representation physique des fichiers binaires n'est pas specifiee, uniquement le round trip (et encore, on peut avoir des NUL en plus a la fin du fichier, tout comme on peut avoir des espaces en plus a la fin des lignes avec les fichiers textes). Mais la, je ne connais pas de cas ou on fait reellement qqch, je suppose que ca sert pour les mainframes qui ont des systemes de fichiers beaucoup plus structures qu'un flux de bytes.

[hurukan]

bonsoir,

ça gonfle un prof de chercher un peu sur le net ou dans «la littérature» ???

Oui quand on passe déjà 2/3 de son temps à chercher des informations pour les exercices, vérifier que les exercices fonctionnent et introduire tout cela dans un projet à court terme pour que les élèves aient au moins l'impression que ces exercices aient un sens. De plus dans les forums il faut faire un tri, dans la littérature aussi, je donne cours dans le secondaire (collège) et mes étudiants ne sont pas des programmeurs avertis, ils débutent en programmation, 'faut pas que je les terrorise non plus ^^ du coup, oui ça me gonfle de chercher un peu sur le net, et dans la littérature ^^
Maintenant, merci, j'ai des débuts de réponses... sur ce forum ^^

[hurukan]

Bonjour,

Pour information, dans toutes les entreprises ou j'ai travaille, il est strictement interdit d'utiliser les caracteres accentues dans le code. Pas plus d'ailleurs que de mettre des commentaires en cyrillique ou en grec.

J'ai connu ça aussi, mais mes petits aiment la langue de voltaire et non la langue de shakespeare ^^
"Dans le code" j'espère bien ne jamais mettre un nom de variable avec des caractères accentués (ou le c cédille)... par contre dans les commentaires... je ne m'en prive pas.
Je n'ai jamais travaillé avec des russes ni des grecs donc mes commentaires sont soit en anglais soit en français... mais j'aimerais bien voir un code source C avec des caractères cyrilliques ou grecs dedans, surtout à la compilation...
Est-ce que les commentaires passent ? Normalement oui tout ce qui est entre /* */ ou // est censé être ignoré (au niveau du pré-processing si mes souvenirs sont bons)...

...s'attendre a ce que quelqu'un configure correctement les choses sous Windows pour qu'une application console fonctionne correctement sans code supplementaire specifique a Windows est illusoire.

lol ^^ le problème des caractères accentués est résolu par chez toi ^^
A moins que tu sois sur un clavier qwerty où c'est galère pour obtenir ces foutus caractères accentués...

...Tu as raison...

Ce n'est pas moi qui est raison, c'est le man de printf... ^^
(section The conversion specifier)

[hurukan]

Je me demande si nous ne confondons pas trop souvent "conversion" et "substitution" ce n'est pas la même chose...

[Jean-Marc.Bourguet]

J
lol ^^ le problème des caractères accentués est résolu par chez toi ^^
A moins que tu sois sur un clavier qwerty où c'est galère pour obtenir ces foutus caractères accentués...

Gagné. Quand j'utilise un clavier azerty, les accents sont là.

Je me demande si nous ne confondons pas trop souvent "conversion" et "substitution" ce n'est pas la même chose...

Une conversion peut se résumer à des substitutions.

[Bktero]

par contre dans les commentaires... je ne m'en prive pas.

Est-ce que les commentaires passent ? Normalement oui tout ce qui est entre /* */ ou // est censé être ignoré (au niveau du pré-processing si mes souvenirs sont bons)...

Tu as tord de te faire plaisir ^^

J'ai eu le cas une fois (et ça m'a vacciné pour toujours) où les accents dans un fichier source, en étant passé à un autre environnement, ont été changé par d'autres caractères. Pas gênant quand "était" devient "@$ait". Beaucoup plus gênant quand "donné\n" devient "donn@$" (on remarquera la suppression du \n !!!).

Conséquence ? Des lignes de codes remontaient sur des lignes de commentaires et échouaient lamentablement.

Il s'agissait ici de traitement en PL/SQL, un langage interprété et donc l’exécution plantait, remontant des erreurs non reproductibles sur d'autres environnements. En langage compilé comme le C, la compilation n'aurait pas fonctionné et ça aurait été diagnostiquable rapidement, certes.

J'en ai tiré la leçon de ne jamais mettre des accents dans du code ou alors en étant extrêmement prudent.

[pfeuh]

"Dans le code" j'espère bien ne jamais mettre un nom de variable avec des caractères accentués (ou le c cédille)...

Le compilo générerait une erreur de toute façon.

par contre dans les commentaires... je ne m'en prive pas.

Sans vouloir en rajouter une couche, je m'efforçais (je ne m'efforce plus car c'est devenu naturel) de mettre mes noms de variables/fonctions et mes commentaires en anglais pour plusieurs raisons:

- Il n'y a aucun problème d'accentuation.
- C'est parlé par la majorité des gens utilisant mes sources.
- la plupart des mots-clefs utilisés en informatique sont anglais.
- Même si on ne comprend pas tout, la syntaxe informatique est si simple que google-traduction fait souvent bien sont boulot. Sauf si l'on s'amuse à essayer de faire de belles phrases, ce qui n'est pas le but d'un commentaire.

A+

Pfeuh

[hurukan]

...Il s'agissait ici de traitement en PL/SQL, un langage interprété...

j'imagine bien la galère...

[hurukan]

Dans mon laboratoire mes étudiants utilisent soit Linux soit Windows XP.
Le principal soucis en ligne de commande sous Windows ce sont les caractères accentués qui partent en sucette (apparement, j'ai pas encore essayé) si on utilise une police true type et la commande chcp il est possible de résoudre le soucis.
Par contre et là je ne vois pas du tout comment solutionner le soucis c'est que cet exemple-ci sous Linux en mode console (utf8)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include<stdio.h>
 
unsigned char test1[25]="Autre donnée\0";
unsigned char test2[25]="Autre donnee\0";
void main(void)
{
        printf("[%15s]\n",test1);
        printf("[%15s]\n",test2);
        printf("[%s]\n",test1);
        printf("[%s]\n",test2);
}

génère

Code :

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

1
2
3
4
[  Autre donnée]
[   Autre donnee]
[Autre donnée]
[Autre donnee]

Remarquez le décallage du crochet droit dans la deuxième ligne (c'est ça qui me pose problème).
J'ai essayé de voir avec mbrtowc(), mbsrtowcs(), si il y avait moyen de contourner le soucis mais c'est tout neuf pour moi et j'ai un peu de mal...
Je voudrais écrire une fonction qui permette de ne pas avoir ce décallage vers la gauche quand on utilise des caractères accentués en mode console...
Si quelqu'un à déjà rencontré ce genre de soucis...je suis prenneur...

[pythéas]

Bonjour,

Il serait peut être préférable d'ouvrir un nouveau topic pour plus de lisibilité.

Pour ton problème, tu donnes toi même la cause, tu es en utf8, les caractères accentués sont donc codés sur deux "char", ainsi pour un même nombre de lettres le résultat de strlen sera différent en fonction du nombre de caractères accentués.

Pour l'affichage, il est normal que le système, qui est supposé affiché sur 15 caractères, supprime un espace "de remplissage" lorsque la chaine qu'il affiche ne fait plus 12 caractères mais un de plus.

J'ai tendance à me dire que ce problème concerne tellement de monde qu'il doit exister une solution implémentée par quelqu'un quelque part, mais je ne suis jamais tombé dessus.
Sinon tu peux, tout simplement, compter toi même les lettres dans ta chaîne (avec l ta lettre (enfin test1[i]), si l<0x80 char -> caratère codée sur un char, si l==0xC2 -> caratère (mais, très vraissemblablement, pas lettre) codée sur un char, si l==0xC3 -> lettre codée sur deux char -bien sûr dans les deux derniers cas, ne pas lire le caractère suivant mais celui d'après)

[ternel]

Une possibilité est d'utiliser une fonction qui compterai les vrais caractères affichés, et de créer la chaine de format du printf avec un sprintf intermédiaire.

J'imagine un strlen, mais je pense que ce n'est pas la bonne fonction. (étant porté sur le C++ ces temps-ci, je ne saurai pas dire mieux)

[Jean-Marc.Bourguet]

Dans mon laboratoire mes étudiants utilisent soit Linux soit Windows XP.
Le principal soucis en ligne de commande sous Windows ce sont les caractères accentués qui partent en sucette (apparement, j'ai pas encore essayé) si on utilise une police true type et la commande chcp il est possible de résoudre le soucis.
Par contre et là je ne vois pas du tout comment solutionner le soucis c'est que cet exemple-ci sous Linux en mode console (utf8)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include<stdio.h>
 
unsigned char test1[25]="Autre donnée\0";
unsigned char test2[25]="Autre donnee\0";
void main(void)
{
        printf("[%15s]\n",test1);
        printf("[%15s]\n",test2);
        printf("[%s]\n",test1);
        printf("[%s]\n",test2);
}

génère

Code :

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

1
2
3
4
[  Autre donnée]
[   Autre donnee]
[Autre donnée]
[Autre donnee]

Remarquez le décallage du crochet droit dans la deuxième ligne (c'est ça qui me pose problème).
J'ai essayé de voir avec mbrtowc(), mbsrtowcs(), si il y avait moyen de contourner le soucis mais c'est tout neuf pour moi et j'ai un peu de mal...
Je voudrais écrire une fonction qui permette de ne pas avoir ce décallage vers la gauche quand on utilise des caractères accentués en mode console...
Si quelqu'un à déjà rencontré ce genre de soucis...je suis prenneur...

On se repete:

1/ Il faut travailler avec des wchar_t si on ne veut pas avoir a gerer des encodages multibytes. Mais attention, avec les caracteres combinants (utilises par Unicode pour gerer les accents), une lettre et un accent dessus peuvent etre encode comme deux caracteres.

Donc:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
#include <stdio.h>
#include <locale.h>
#include <wchar.h>
 
int main()
{
    wchar_t test1[] = L"Autre donnée";
    wchar_t test2[] = L"Autre donnee";
 
    setlocale(LC_ALL, "");
 
    wprintf(L"[%15ls]\n", test1);
    wprintf(L"[%15ls]\n", test2);
 
    return 0;
}

doit fonctionner comme tu veux. Les caracteres accentues que tu desires ont une forme precomposee et je doute que la forme decomposee soit courante.

[hurukan]

Un grand merci, Jean-Marc !!

Bon ça fait un bail que je n'étais plus venu faire un petit tour, je pense avoir capté l'utilisation des wprintf et consors... encore une fois grand merci... je désire te citer comme source dans mes notes de référence pour mon cours de programmation en C.

Encore une fois merci...