problème avec le code ascii

"wawaye" <wawaye@wanadoo.fr> writes:

je programme sous linux, et j'ai un problème, c'est que le code
ascii des caractères de l'ascii étendu (lettres accentuées, etc) qui
m'est retourné (j'utilise des fonctions classiques) est négatif.

En quoi est-ce un probleme?

D'où celà peut il venir ?

Il n'est pas specifie si char est signe ou non (par ce que c'est comme
ca en C et c'est commme ca en C parce que les premieres
implementations ont eu des comportements differents et depuis les deux
possibilites ont continue a etre choisies regulierement par les
implementations).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"wawaye" <wawaye@wanadoo.fr> wrote:

bonjour,
je programme sous linux, et j'ai un problème, c'est que le code ascii
des caractères de l'ascii étendu (lettres accentuées, etc) qui m'est
retourné (j'utilise des fonctions classiques) est négatif. D'où celà
peut il venir ?

Par définition du langage toutes les fonctions "classiques" comme

int fgetc(FILE* stream);

retournent des valeurs >=0 si elles retournent des "caractères" (sous
la condition que sizeof(int)>1). La seule valeur négative retournée
par fgetc est EOF.

Le code ASCII étendu de tous les caractères est positiv, mais si tu
affectes un code >127 à une variable du type char et le type char est
signé par défaut alors là (et seulement là) il est converti en un
nombre négativ.


char c = 133;

printf("%dn",c);

/* -124 si char est signé par défault */
/* 133 si char est non signé par défault */

--
Horst

--
Lâche pas la patate!

wawaye wrote:

je programme sous linux, et j'ai un problème, c'est que le
code ascii des caractères de l'ascii étendu (lettres
accentuées, etc) qui m'est retourné (j'utilise des fonctions
classiques) est négatif. D'où celà peut il venir ?

Une erreur dans la spécification du langage. Qui fait qu'il faut
attention ce qu'on fait avec des caractères, et comment.

Grosso modo, les caractères apparaissent dans deux formes, dans
des int, et dans les char. Dans les int, ce sont des valeurs
renvoyées par des fonctions comme istream::get() (sans
paramètres), ou dans l'interface de std::streambuf, et toutes
les classes qui en dérivent. Pour la reste, en C++, on se sert
de char. (En C, les int apparaissent bien plus souvent.) Or,
pour des raisons historiques, un char est souvent 8 bits, signé.
Du coup, si le bit 7 est positionné, la valeur numérique en est
négative.

La plupart du temps, ça ne fait rien. Il y a quand même deux
exceptions, où il faut éventuellement faire attention :

-- La plus importante, de loin, c'est quand tu convertis un
char en int, par exemple pour le passer à un streambuf, où
la convention, c'est que la fonction est définie que pour
des valeurs entre 0 et UCHAR_MAX et EOF. La ligne
officielle, c'est qu'il faut se servir de la fonction
std::char_traits<char>::to_int_type() pour ce faire. Dans la
pratique, une conversion en unsigned char avant la
conversion en int (qui est en général implicite) fait
l'affaire, mais il ne faut pas l'oublier. Quelque chose
comme « sb->sputc( 'ÿ' ) » risque de ne pas faire ce que tu
veux.

Note que le problème est beaucoup plus sérieux en C : non
seulement fgetc renvoie un int, mais que toutes les
fonctions dans <ctype.h> (et donc dans <ctype>) prenent un
int, et qu'il faut donc écrire :
if ( isupper( (unsigned char)ch ) ) ...
Mais évidemment, en C++, on préfèrerait :
if ( std::isupper( ch, std::locale() ) ) ...
qui n'a pas ce problème.

-- Dans l'ordre naïf de collation, les caractères accentués se
placent en tête. Si tu stockes des lignes de texte *avec* le
'n' final, une ligne comme "abc" viendrait *après* "abcé".
Dans l'ensemble, chaque fois que je me suis trouvé à définir
un ordre sur des chaînes, il me fallait une fonction de
comparaison spéciale. (Note en revanche que la plupart du
temps quand on se sert de std::map ou std::set sur des
chaînes, on n'est pas réelement intéressé par l'ordre. Il le
faut, parce que la collection l'exige, mais en ce qui
concerne l'application, tous les ordres valent. Dans ces
cas-là, évidemment, la comparaison naïve, telle que fournie
par la norme, fait aussi bien l'affaire que n'importe quoi
d'autre.)

En passant, puisque tu as cité Linux : fais gaffe à l'encodage.
Beaucoup d'applications Linux utilise UTF-8. Ce qui est bien à
beaucoup d'égards, mais qui signifie que tu as à faire avec des
caractères composés (multibyte characters, en anglais). Regarde
bien ce que tu as dans tes variables d'environment (« env | grep
LC_ »).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bonjour !
ASCII 256 char et souvent des pilotes qui n atteignent quels 127
premiers chars.

Passionné par l ancien DOS des années 1987, j'ai évolué vers plus
de besoins.

J'ai toujours de vieilles machines Win avec proc 400Mhz, mais les OS et
les applications restent pareilles, elle gérent les 255 char a travers
de bidouilles pour Works Notepad etc.. Sans parler de HTML...

Etant polyglotte et fauché, c'est récent le fauché, j'étais
polyglotte avant aussi.
J'écris en plusieurs langues .... et je rêve d un vrai OS qui soit
pas une contruction de brics et de brocs ..

Unicode existe pourquoi pas le faire gérer au bon niveau EN AMONT.
HTML existe pourquoi pas gérer tous les char d un police UNICODE
depuis un clavier avec des vrai pilotes au bon niveau EN AMONT des
programmes.

Bien sur il faut repenser l'architecture physique des claviers ADC et
DAC pour gerer 65 000 possibiltes avec bits dparité et tout le
tremblement..


MAIS VOILA !
il parait que cela est impossible.

HALLES

HALLES wrote:

ASCII 256 char et souvent des pilotes qui n atteignent quels
127 premiers chars.

ASCII a, et a toujours eu, 128 caractères. Mais plus personne ne
se sert d'ASCII, tout au plus en locale "C".

Passionné par l ancien DOS des années 1987, j'ai évolué vers
plus de besoins.

J'ai toujours de vieilles machines Win avec proc 400Mhz, mais
les OS et les applications restent pareilles, elle gérent les
255 char a travers de bidouilles pour Works Notepad etc.. Sans
parler de HTML...

Les Windows modernes (à partir de NT dans la gamme
professionnelle -- je ne sais pas à partir de quand pour la
gamme personnelle, mais au moins XP) utilisent l'UTF-16. Une
représentation de Unicode, avec plus d'une million de
caractères.

Linux utilise UTF-8. Une autre représentation de Unicode (et
donc aussi avec plus d'une million de caractères).

Etant polyglotte et fauché, c'est récent le fauché, j'étais
polyglotte avant aussi. J'écris en plusieurs langues .... et
je rêve d un vrai OS qui soit pas une contruction de brics et
de brocs ..

Windows me semble convenir. De même que Mac-OS.

Unicode existe pourquoi pas le faire gérer au bon niveau EN
AMONT. HTML existe pourquoi pas gérer tous les char d un
police UNICODE depuis un clavier avec des vrai pilotes au bon
niveau EN AMONT des programmes.

Bien sur il faut repenser l'architecture physique des claviers
ADC et DAC pour gerer 65 000 possibiltes avec bits dparité et
tout le tremblement..

C'est vrai qu'un clavier avec prèsqu'une million de touches
serait bien peu commode. Mais les Chinois et les Japonais
arrivent à s'en sortir avec des claviers 96 touches aussi : le
système de saisi n'est pas aussi direct qu'il l'est en français,
mais apparamment, ça marche pas mal. (En gros, on saisit la
phonétique du mot, puis l'ordinateur affiche les idéogrammes qui
pourrait convenir, et on en choisit celui qui convient.)

MAIS VOILA !
il parait que cela est impossible.

Qu'est-ce qui est impossible ? Je ne comprends pas ce que tu
démandes.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bonjour.

Je reve d un clavier qui puisse acceder aux alphabets de plusieurs
dizaines de langues Surtout les langues Européennes.

Par malchance en europe on a l Alphabet Latin et l'alphabte Grec et les
divers autres alphabets Cyrilliques.

Mon souhait UN éditeur qui puisse ecrire dans n importe quelle langue
Européenne, donc ilfaut un nouveau clavier et son driver et une "TTF"
Européenne qui inclurait ces alphabets plus l alphabet Phonétique
International.
Je peux mettre ces alpahbets dans un seul TTF.

Mais je sais pas comment faire cet editeur de texte, ni faire le driver
cote soft.
Par contre je pourrai dirigier un équipe qui pondrait un nouveau
clavier Pan Européen, coté Hard.

Si on prend pas la mesure de standardiser les echanges informatiques,
on restera avec ASCII et TTF géré comme maintenant.

Or je pense qu il faudrait au prix d une petite complexité vite
oubliée, donner la possibilté aux européens d'écrire plus
facilement des documents multilingues.

Bon c est vrai j'ai pas de sponsors ni de banque derriere moi, atendez
je regarde une fois de plus. Non ! Pas de banquier.

Perso, je parle plusieurs langues,et j ai des soucis avec les documents
multilingues.


HALLES

On 30 May 2005 11:17:06 -0700, "HALLES" <slan_a_gael@yahoo.fr>:

Je reve d un clavier qui puisse acceder aux alphabets de plusieurs
dizaines de langues Surtout les langues Européennes.

Tu veux dire que tu sais écrire dans plusieurs dizaines de langues ?
:-o

Mon souhait UN éditeur qui puisse ecrire dans n importe quelle langue
Européenne, donc ilfaut un nouveau clavier et son driver et une "TTF"
Européenne qui inclurait ces alphabets plus l alphabet Phonétique
International.

Note que certaines polices fournies avec Windows (Arial, Courier New,
etc.) contiennent déjà un sacré paquet d'alphabets (latin, arabe,
grec, cyrillique, hébraïque).
Et un éditeur de texte gère déjà Unicode (et tous ces alphabets) : le
bloc-notes, lui aussi fourni en standard avec Windows.

Quant au clavier, c'est encore plus simple : tu peux passer du clavier
français au clavier grec par une simple combinaison de touches,
configurable à ta guise. Si tu ne veux pas faire l'effort de te
souvenir des différentes configurations de clavier, tu peux aussi
brancher deux claviers (il faut qu'au moins un des deux soit USB).

Je ne connais pas Linux ni MacOSX, mais ça m'étonnerait beaucoup
qu'ils gèrent Unicode moins bien que Windows.

En fait, je ne comprends pas bien ce que tu cherches à faire, à part
réinventer ce qui existe déjà ?

HALLES wrote:

Je reve d un clavier qui puisse acceder aux alphabets de
plusieurs dizaines de langues Surtout les langues Européennes.

C'est le cas de tous les claviers que je connais. En fait, le
clavier ne génère qu'un code qui indique la position de la
touche ; ensuite, c'est le logiciel du système qui s'en occupe.
Et que ce soit Windows ou Unix, c'est assez simple à charger les
pilotes et à avoir le clavier qu'on veut.

[...]

Perso, je parle plusieurs langues, et j ai des soucis avec les
documents multilingues.

J'écris assez regulièrement des documents en trois langues, sans
problème. En fait, j'installe un pilote de clavier américain
(parce que j'écris beaucoup plus du C++ ou des scripts de shell
qu'autre chose) ; que ce soit emacs ou vim, il y a des modes
pour entrer n'importe quel caractère accentué à partir d'un
clavier US. En revanche, quand je suis amené à me servir de Open
Office, ou quelque chose de semblable, j'active le pilote pour
le clavier qui correspond à la langue que j'utilise.

(Mais je ne vois pas le rapport avec le C++. Pour le C++, le
clavier américain convient parfaitement.)

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Bonjour,
la logique du clavier est assez simple une touche un code par touche et
un codeur par exemple pour 21 bits on pourrait acceder a 200 000
caracteres, plus des bits de parite des bits de verification etc.. et
une liaison qui mene cela a l ordinateur qui lui trie (fonction du
driver, reconnaissance du type de caractere Cyrillique, Araméen, Grec
etc.. et qui passe le bon caractere a l editeur qui lui l affiche).

C'est assez simple.
Sauf qu un clavier de 200 000 touches evrait etre assez lourd, alors on
reduits a
2 000 le nombre de caracteres et on limite le clavier a 200 touches...
Cela reste possible.

Suivant les langues, et suivant aussi le niveau de langage on se doit
d'être très précis.
Surtout quand on fait des recherches sur le dechiffement des langues.
Je parle pas de recherche de codes, c 'est assez facile, il y a pas mal
de gens qui ont travaillé sur cela.
Non, je parle de langues qui peuvent avoir des visions differentes des
choses que l on pense universelles.

Par exemple en Anglais il est juste de se prétendre : avoir été
agit, en fançais on ne prend pas cette précaution là, et on accepte
facielment d endosser une responsabilité qui ne parait pas évidente a
un Anglais vu qe la structure de sa langue permet le : avoir été
agit.

Ainsi, on voit que ce qu on perçoit comme possiblement universel ne l
est pas .

<< Mais je ne vois pas le rapport avec le C++. Pour le C++, le
clavier américain convient parfaitement!>>

Là est le probléme, le compilateur connait bien le clavier americain
et les fonctions sont ecrites en americain/anglais.
Plus est restreint le nombre de données gérées par un compilateur,
par exemple un seul alphabet Latin version anglo saxonne excluant les
accents, au plus est restreint le nombre de solutions logiques.

Et on ne m otera pas de l idée que lemonde est plus complexe que ne
peux l imaginer un ordinateur géré par un compilateur.

HALLES

Fabien LE LEZ wrote:

On 30 May 2005 11:17:06 -0700, "HALLES" <slan_a_gael@yahoo.fr>:

Je reve d un clavier qui puisse acceder aux alphabets de plusieurs
dizaines de langues Surtout les langues Européennes.

Tu veux dire que tu sais écrire dans plusieurs dizaines de
langues ? :-o

Mon souhait UN éditeur qui puisse ecrire dans n importe
quelle langue Européenne, donc ilfaut un nouveau clavier et
son driver et une "TTF" Européenne qui inclurait ces
alphabets plus l alphabet Phonétique International.

Note que certaines polices fournies avec Windows (Arial,
Courier New, etc.) contiennent déjà un sacré paquet
d'alphabets (latin, arabe, grec, cyrillique, hébraïque).

C'est pareil sous Unix. Ou au moins sous Solaris et sous Linux.
Encore qu'il faut avoir installer ces polices -- la plupart des
polices sous Solaris ont encore un encodage huit bits. (Mais la
plupart des logiciels savent utiliser plusieurs polices
apparentées, un pour le 8859-1, un pour le 8859-2, etc.)

Et un éditeur de texte gère déjà Unicode (et tous ces
alphabets) : le bloc-notes, lui aussi fourni en standard avec
Windows.

Pareil pour vim et emacs.

Quant au clavier, c'est encore plus simple : tu peux passer du
clavier français au clavier grec par une simple combinaison de
touches, configurable à ta guise.

Sous Unix (ou plutôt X), il y a xmodmap pour rémapper le
clavier. (Quelque part chez moi, je dois encore avoir des veuix
modmap pour mapper le clavier US du Sparc en clavier français ou
clavier allemand. La fonctionnalité est integré dans KDE, à peu
près de la même façon que sous Windows.)

En plus, et vim et emacs ont des façons internes de composer les
caractères. Ce qui fait que la plupart du temps, je reste avec
le clavier programmé en US, même quand je tappe du français ou
de l'allemand. (Mais c'est en partie parce que j'utilise TeX
comme outil de formattage de la page. Et il partage avec C++ et
les shells Unix une prédilection pour des caractères spéciaux,
genre , { et }.)

Si tu ne veux pas faire l'effort de te souvenir des
différentes configurations de clavier, tu peux aussi brancher
deux claviers (il faut qu'au moins un des deux soit USB).

Si on est capable de mémoiriser la vocabulaire d'une dizaines de
langues, on doit être capable de mémoriser une configuration de
clavier, non ? :-)

Je ne connais pas Linux ni MacOSX, mais ça m'étonnerait
beaucoup qu'ils gèrent Unicode moins bien que Windows.

Un tout petit peu moins bien, mais la différence aujourd'hui est
negligeable.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34