problème avec le code ascii

kanze

31/05/2005 à 09:37

HALLES wrote:

la logique du clavier est assez simple une touche un code par
touche

C'est un peu plus compliqué. Typiquement, tu as un « scan
code », qui indique la touche tappée, plus des bits qui indique
l'état des touches du genre shift, contrôle, alt, etc. (En fait,
je crois que le plupart des claviers aujourd'hui sont
programmable, et on peut leur démander de signaler chaque
évenemment : touche appuyée, touche rélachée, avec indication de
la touche. Ensuite, c'est au logiciel du système de faire le
tri, de convertir touche shift appuyée en état interne, plutôt
que de l'envoyer vers le programme utilisateur.)

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..

Le clavier standard prévoie 96 touches, si je ne me trompe pas.
L'information est envoyé sur 16 bits, un octet pour identifier
la touche, et un octet pour les autres informations (état de
shift, etc., et s'il s'agit d'une appuie ou d'une rélachement).

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).

L'ordinateur fait encore plus. Le clavier envoie l'information
que c'est la touche no. n, qui correspond à la troisième touche
du deuxième rang, par exemple. C'est le pilote du système (voire
même le gestionnaire de fenêtrage) qui traduit la position, plus
les autres informations (shift, etc.) en code caractère.

Sous Windows, on installe autant de pilotes de clavier qu'on
veut. Dès qu'on en a installé plus d'un, il y a un petit carré
qui apparaît en bas à droit de l'écran (dans la partie de la
barre d'état qui contient l'eur, etc.) qui affiche le clavier
actif. On change de clavier actif en cliquant dessus, ou au
moyen des hot keys.

Sous Unix (ou plutôt sous X), la traduction s'effectue au moyen
d'une table dit modmap. Il existe un programme, xmodmap, pour le
changer. Sous Solaris (CDE), c'est assez facile à l'invoquer à
partir des entrées dans les menus. Avec KDE sous Linux, ils ont
emballé cette fonctionnalité dans une interface qui ressemble
énormement à ce que fait Windows.

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.

Je n'ai pas beaucoup d'expérience avec les langues orientales
(où on a besoin des milliers de « caractères ») ; d'après ce que
j'ai entendu dire, on entre le mot phonétiquement, le logiciel
de saisi le reconnaît, et affiche le choix des caractères qui
correspond. L'utilisateur choisit alors celui qu'il veut.

En ce qui concerne les autres langues (que CJK), tu en connais
qui ont plus d'une centaine de caractères ? (Peut-être les
langues syllabique de l'Inde. Mais là aussi, je m'attendrais à
ce qu'on entre la consonne, puis la voyelle, et que ce soit le
logiciel qui en fait la composition. Comme c'est le logiciel qui
fait la composition des caractères arabes en fonction du
contexte.) Avec 96 touches, on s'en tire très bien.

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.

Dans certains cas, évidemment, il faut se rabattre à des
photographies de la source. Je ne connais pas de polices
actuellement avec un support pour tous les raccourcies et les
liaisons du texte gohique, par exemple. Si une présentation
exacte de la source initiale est importante, alors, à peu près
la seule solution disponible est le scanner, et d'incorporer les
images dans le texte.

Non, je parle de langues qui peuvent avoir des visions
differentes des choses que l'on pense universelles.

Il n'y a pas de langue universelle.

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.

Je ne comprends pas. Ça veut dire quoi : « avoir été agit ».
Même pas en essayant de le traduir mot-à-mot en anglais : « to
have been act » n'a pas de sense en anglais, pas plus que
« avoir été agit » en français.

Mais peut-être tu penses au simple passé du passif (« has been
done ») en anglais. Dans ce cas-là, « on a fait » est une
traduction plus que serviable -- en anglais (et encore plus en
allemand), on se cache derrière le passif, en français, derrière
« on ». Mais ça revient au même la plupart du temps. Mais il
existe un passif en français aussi, qui apparaît parfois dans
les documents techniques. Sans oublier les refléchis : « il
s'est passer » et les tournures nominales : « La rémise en état
a été effectuée », et des choses pareilles.

Si on veut éviter de préciser l'agent, je ne connais pas de
langue où ce n'est pas possible. (Du point de vue stylistique, à
part peut-être l'allemand, et encore, c'est mieux de les éviter.
Les tourures sont lourdes et manque de précision.)

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.

Le compilateur ne connaît pas de clavier. Et les fonctions sont
écrites en C++, qui n'est pas du tout le langage courant de la
plupart des américains. Les commentaires et les noms de
variables sont dans la langue que tu veux ; le compilateur s'en
fout. Tout au plus faut-il faire attention aux encodages -- si
tu saisis le programme en UTF-8, mais tu dis au compilateur que
c'est du ISO 8859-1, il va y avoir des problèmes.

Quant au programme même, évidemment, tu y fais ce que tu veux.
Beaucoup de programmes aujourd'hui utilsent UCS-4 ou UCS-2 en
interne. (UCS-2 est même l'encodage standard de Windows.)
D'autres, surtout dans le monde Unix, utilise UTF-8, qui est
aussi devenu l'encodage standard du reseau. (Mais c'est vrai que
le support pour UTF-8 dans la bibliothèque standard est plutôt
limité. Il y a du travail à faire, si ça t'intéresse.)

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 le monde est plus complexe
que ne peux l imaginer un ordinateur géré par un compilateur.

Certainement. Personne ne pourrait prétendre le contraire.
L'ordinateur peut très bien gérer tout le texte que tu peux
écrire, mais entre gérer et comprendre, il y a un monde de
différence.

--
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

HALLES wrote:

la logique du clavier est assez simple une touche un code par
touche

C'est un peu plus compliqué. Typiquement, tu as un « scan
code », qui indique la touche tappée, plus des bits qui indique
l'état des touches du genre shift, contrôle, alt, etc. (En fait,
je crois que le plupart des claviers aujourd'hui sont
programmable, et on peut leur démander de signaler chaque
évenemment : touche appuyée, touche rélachée, avec indication de
la touche. Ensuite, c'est au logiciel du système de faire le
tri, de convertir touche shift appuyée en état interne, plutôt
que de l'envoyer vers le programme utilisateur.)

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..

Le clavier standard prévoie 96 touches, si je ne me trompe pas.
L'information est envoyé sur 16 bits, un octet pour identifier
la touche, et un octet pour les autres informations (état de
shift, etc., et s'il s'agit d'une appuie ou d'une rélachement).

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).

L'ordinateur fait encore plus. Le clavier envoie l'information
que c'est la touche no. n, qui correspond à la troisième touche
du deuxième rang, par exemple. C'est le pilote du système (voire
même le gestionnaire de fenêtrage) qui traduit la position, plus
les autres informations (shift, etc.) en code caractère.

Sous Windows, on installe autant de pilotes de clavier qu'on
veut. Dès qu'on en a installé plus d'un, il y a un petit carré
qui apparaît en bas à droit de l'écran (dans la partie de la
barre d'état qui contient l'eur, etc.) qui affiche le clavier
actif. On change de clavier actif en cliquant dessus, ou au
moyen des hot keys.

Sous Unix (ou plutôt sous X), la traduction s'effectue au moyen
d'une table dit modmap. Il existe un programme, xmodmap, pour le
changer. Sous Solaris (CDE), c'est assez facile à l'invoquer à
partir des entrées dans les menus. Avec KDE sous Linux, ils ont
emballé cette fonctionnalité dans une interface qui ressemble
énormement à ce que fait Windows.

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.

Je n'ai pas beaucoup d'expérience avec les langues orientales
(où on a besoin des milliers de « caractères ») ; d'après ce que
j'ai entendu dire, on entre le mot phonétiquement, le logiciel
de saisi le reconnaît, et affiche le choix des caractères qui
correspond. L'utilisateur choisit alors celui qu'il veut.

En ce qui concerne les autres langues (que CJK), tu en connais
qui ont plus d'une centaine de caractères ? (Peut-être les
langues syllabique de l'Inde. Mais là aussi, je m'attendrais à
ce qu'on entre la consonne, puis la voyelle, et que ce soit le
logiciel qui en fait la composition. Comme c'est le logiciel qui
fait la composition des caractères arabes en fonction du
contexte.) Avec 96 touches, on s'en tire très bien.

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.

Dans certains cas, évidemment, il faut se rabattre à des
photographies de la source. Je ne connais pas de polices
actuellement avec un support pour tous les raccourcies et les
liaisons du texte gohique, par exemple. Si une présentation
exacte de la source initiale est importante, alors, à peu près
la seule solution disponible est le scanner, et d'incorporer les
images dans le texte.

Non, je parle de langues qui peuvent avoir des visions
differentes des choses que l'on pense universelles.

Il n'y a pas de langue universelle.

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.

Je ne comprends pas. Ça veut dire quoi : « avoir été agit ».
Même pas en essayant de le traduir mot-à-mot en anglais : « to
have been act » n'a pas de sense en anglais, pas plus que
« avoir été agit » en français.

Mais peut-être tu penses au simple passé du passif (« has been
done ») en anglais. Dans ce cas-là, « on a fait » est une
traduction plus que serviable -- en anglais (et encore plus en
allemand), on se cache derrière le passif, en français, derrière
« on ». Mais ça revient au même la plupart du temps. Mais il
existe un passif en français aussi, qui apparaît parfois dans
les documents techniques. Sans oublier les refléchis : « il
s'est passer » et les tournures nominales : « La rémise en état
a été effectuée », et des choses pareilles.

Si on veut éviter de préciser l'agent, je ne connais pas de
langue où ce n'est pas possible. (Du point de vue stylistique, à
part peut-être l'allemand, et encore, c'est mieux de les éviter.
Les tourures sont lourdes et manque de précision.)

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.

Le compilateur ne connaît pas de clavier. Et les fonctions sont
écrites en C++, qui n'est pas du tout le langage courant de la
plupart des américains. Les commentaires et les noms de
variables sont dans la langue que tu veux ; le compilateur s'en
fout. Tout au plus faut-il faire attention aux encodages -- si
tu saisis le programme en UTF-8, mais tu dis au compilateur que
c'est du ISO 8859-1, il va y avoir des problèmes.

Quant au programme même, évidemment, tu y fais ce que tu veux.
Beaucoup de programmes aujourd'hui utilsent UCS-4 ou UCS-2 en
interne. (UCS-2 est même l'encodage standard de Windows.)
D'autres, surtout dans le monde Unix, utilise UTF-8, qui est
aussi devenu l'encodage standard du reseau. (Mais c'est vrai que
le support pour UTF-8 dans la bibliothèque standard est plutôt
limité. Il y a du travail à faire, si ça t'intéresse.)

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 le monde est plus complexe
que ne peux l imaginer un ordinateur géré par un compilateur.

Certainement. Personne ne pourrait prétendre le contraire.
L'ordinateur peut très bien gérer tout le texte que tu peux
écrire, mais entre gérer et comprendre, il y a un monde de
différence.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

HALLES wrote:

la logique du clavier est assez simple une touche un code par
touche

C'est un peu plus compliqué. Typiquement, tu as un « scan
code », qui indique la touche tappée, plus des bits qui indique
l'état des touches du genre shift, contrôle, alt, etc. (En fait,
je crois que le plupart des claviers aujourd'hui sont
programmable, et on peut leur démander de signaler chaque
évenemment : touche appuyée, touche rélachée, avec indication de
la touche. Ensuite, c'est au logiciel du système de faire le
tri, de convertir touche shift appuyée en état interne, plutôt
que de l'envoyer vers le programme utilisateur.)

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..

Le clavier standard prévoie 96 touches, si je ne me trompe pas.
L'information est envoyé sur 16 bits, un octet pour identifier
la touche, et un octet pour les autres informations (état de
shift, etc., et s'il s'agit d'une appuie ou d'une rélachement).

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).

L'ordinateur fait encore plus. Le clavier envoie l'information
que c'est la touche no. n, qui correspond à la troisième touche
du deuxième rang, par exemple. C'est le pilote du système (voire
même le gestionnaire de fenêtrage) qui traduit la position, plus
les autres informations (shift, etc.) en code caractère.

Sous Windows, on installe autant de pilotes de clavier qu'on
veut. Dès qu'on en a installé plus d'un, il y a un petit carré
qui apparaît en bas à droit de l'écran (dans la partie de la
barre d'état qui contient l'eur, etc.) qui affiche le clavier
actif. On change de clavier actif en cliquant dessus, ou au
moyen des hot keys.

Sous Unix (ou plutôt sous X), la traduction s'effectue au moyen
d'une table dit modmap. Il existe un programme, xmodmap, pour le
changer. Sous Solaris (CDE), c'est assez facile à l'invoquer à
partir des entrées dans les menus. Avec KDE sous Linux, ils ont
emballé cette fonctionnalité dans une interface qui ressemble
énormement à ce que fait Windows.

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.

Je n'ai pas beaucoup d'expérience avec les langues orientales
(où on a besoin des milliers de « caractères ») ; d'après ce que
j'ai entendu dire, on entre le mot phonétiquement, le logiciel
de saisi le reconnaît, et affiche le choix des caractères qui
correspond. L'utilisateur choisit alors celui qu'il veut.

En ce qui concerne les autres langues (que CJK), tu en connais
qui ont plus d'une centaine de caractères ? (Peut-être les
langues syllabique de l'Inde. Mais là aussi, je m'attendrais à
ce qu'on entre la consonne, puis la voyelle, et que ce soit le
logiciel qui en fait la composition. Comme c'est le logiciel qui
fait la composition des caractères arabes en fonction du
contexte.) Avec 96 touches, on s'en tire très bien.

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.

Dans certains cas, évidemment, il faut se rabattre à des
photographies de la source. Je ne connais pas de polices
actuellement avec un support pour tous les raccourcies et les
liaisons du texte gohique, par exemple. Si une présentation
exacte de la source initiale est importante, alors, à peu près
la seule solution disponible est le scanner, et d'incorporer les
images dans le texte.

Non, je parle de langues qui peuvent avoir des visions
differentes des choses que l'on pense universelles.

Il n'y a pas de langue universelle.

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.

Je ne comprends pas. Ça veut dire quoi : « avoir été agit ».
Même pas en essayant de le traduir mot-à-mot en anglais : « to
have been act » n'a pas de sense en anglais, pas plus que
« avoir été agit » en français.

Mais peut-être tu penses au simple passé du passif (« has been
done ») en anglais. Dans ce cas-là, « on a fait » est une
traduction plus que serviable -- en anglais (et encore plus en
allemand), on se cache derrière le passif, en français, derrière
« on ». Mais ça revient au même la plupart du temps. Mais il
existe un passif en français aussi, qui apparaît parfois dans
les documents techniques. Sans oublier les refléchis : « il
s'est passer » et les tournures nominales : « La rémise en état
a été effectuée », et des choses pareilles.

Si on veut éviter de préciser l'agent, je ne connais pas de
langue où ce n'est pas possible. (Du point de vue stylistique, à
part peut-être l'allemand, et encore, c'est mieux de les éviter.
Les tourures sont lourdes et manque de précision.)

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.

Le compilateur ne connaît pas de clavier. Et les fonctions sont
écrites en C++, qui n'est pas du tout le langage courant de la
plupart des américains. Les commentaires et les noms de
variables sont dans la langue que tu veux ; le compilateur s'en
fout. Tout au plus faut-il faire attention aux encodages -- si
tu saisis le programme en UTF-8, mais tu dis au compilateur que
c'est du ISO 8859-1, il va y avoir des problèmes.

Quant au programme même, évidemment, tu y fais ce que tu veux.
Beaucoup de programmes aujourd'hui utilsent UCS-4 ou UCS-2 en
interne. (UCS-2 est même l'encodage standard de Windows.)
D'autres, surtout dans le monde Unix, utilise UTF-8, qui est
aussi devenu l'encodage standard du reseau. (Mais c'est vrai que
le support pour UTF-8 dans la bibliothèque standard est plutôt
limité. Il y a du travail à faire, si ça t'intéresse.)

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 le monde est plus complexe
que ne peux l imaginer un ordinateur géré par un compilateur.

Certainement. Personne ne pourrait prétendre le contraire.
L'ordinateur peut très bien gérer tout le texte que tu peux
écrire, mais entre gérer et comprendre, il y a un monde de
différence.

--
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

HALLES

31/05/2005 à 14:51

Bonjour !
Scan code 9 bits 8 de code un bit de parite !

HALLES

HALLES

31/05/2005 à 14:53

Les polices sont pas en jeu, je peux en faire des perso au format
unicode.

HALLES

HALLES

31/05/2005 à 15:01

Les polices sont pas en jeu, je peux en faire des perso au format
unicode.

========
L Anglais comme l ancien Norvegien connait des sujet qui ne font pas l
action mais sont Fatalement mené a agir vers ce qui va devenir l
action.

C'est different en français et en d autres langues, le sujet fait l
action.
========
Quant au compilateurs si il y en a un qui connaisse Unicode, je
veuxbien réapprendre a programmer.
J en suis resté a TP 7.
Et les langages machines a commande numerique.

Un ordinateur ne deviendra pas intelligent mais on peut lui donner des
choses plus intelligentes a faire.

Mais pas si on reste avec un code d entré restreint.
Machine logiques : code + logique de base et operateurs.

Code restreint pas beaucoup depossibilite ex un compilateur en 8 bits
par rapport a un compilateur en 64 bits.

HALLES

kanze

31/05/2005 à 18:49

HALLES wrote:

Les polices sont pas en jeu, je peux en faire des perso au
format unicode.

========
L Anglais comme l ancien Norvegien connait des sujet qui ne
font pas l action mais sont Fatalement mené a agir vers ce qui
va devenir l action.

C'est different en français et en d autres langues, le sujet
fait l action.
========

Tu as des exemples ? Et au fait, qu'est-ce qui fait l'action
dans « il faut » ? Ou « le programme a été écrit » ?

Quant au compilateurs si il y en a un qui connaisse Unicode,
je veux bien réapprendre a programmer.

VC++, d'après ce que j'ai entendu dire.

[...]

Mais pas si on reste avec un code d entré restreint.

Beaucoup de programmes acceptent de l'Unicode en entrée
maintenant. Soit en forme to UCS-2, soit en forme de UTF-8.

Machine logiques : code + logique de base et operateurs.

Code restreint pas beaucoup depossibilite ex un compilateur en
8 bits par rapport a un compilateur en 64 bits.

Je ne comprends pas cette phrase. Un compilateur travaille
surtout avec des données binaires. Donc, en général, à la
taille de la machine hôte (typiquement 32 ou 64 bits
aujourd'hui).

--
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

HALLES

31/05/2005 à 19:02

Bonjour.
supposons un jongleur qui jongle avec 8 balles (un processeur a 8 bits)
et un jongleur qui jongle avec 64 balles (cpu 64 bits). On peut
facilement penser que les figures du jongleurs qui a 64 balles seront
plus difficiles que celles du jongleur a 8 balles.

Exemple encore, pour gerer du RGB 32 bits c est bien, 16 bits c'est
difficilement gerable, on gerera du noir et du gris et du blanc en 16
bits pas de couleurs avec une grande palette de nuance.

HALLES
Est ce que vous jouez au Tarot ?

problème avec le code ascii

6 réponses

Veuillez sélectionner un problème