recherche d'un element suivant la valeur d'un des champs

Alain Naigeon

07/10/2004 à 19:16

"Fabien LE LEZ" a écrit dans le message news:

On Thu, 7 Oct 2004 01:18:35 +0200, "Alain Naigeon" :

Comment on dit "nivellement par le bas", en Anglais ?

"Pragmatism" ?

Note que le mot "Anglais" désigne exclusivement un habitant de
l'Angleterre, et pas du tout une langue.

Bah si, les Américains disent d'eux-mêmes qu'ils parlent Anglais,
même si ça fait rigoler les Anglais.

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

Loïc Joly

07/10/2004 à 22:35

Arnaud Meurgues wrote:

Michel Michaud wrote:

C'est quoi, le jeu de caractères naturel d'une machine ?
Sur la mienne, je peux changer quand je veux son "jeu de caractères
naturel".

J'aurais dû dire « courant » alors. Si j'utilise un jeu de
caractères, que mon éditeur me permet d'écrire le programme avec
ce jeu, j'aimerais que le compilateur l'accepte aussi.

Ben oui, mais c'est compliqué. Notamment à cause du principe des disques
partagés : tout le monde n'a pas forcément le même charset « courant »
et le compilateur va se retrouver avec des fichiers divers et variés
dont il ne pourra pas connaître ni charset ni encoding.

La solution en python est d'indiquer au tout début du fichier l'encoding
de ce fichier. Ca me semble être une solution applicable en C++, non ?

--
Loïc

Loïc Joly

07/10/2004 à 22:44

Arnaud Meurgues wrote:

wrote:

Si je régarde autour de moi ici, personne ne se sent obligé à lire
l'anglais pour rester à jour dans le domaine bancaire. Et si personne
n'aurait de problème pour trouver des symboles comme oldState ou
loopCount, même moi, j'aurais du mal à trouver de l'anglais qui
conviendrait à « affectation », « titre » ou « obligation » (dans leurs
signification boursière). Et c'est justement sur ces termes qu'un à peu
près peut préter à la plus de confusion.

Par ailleurs, je ne suis pas certain de comprendre les termes de finance
en français non plus. Alors l'apprendre en anglais ou en français, pour
moi, c'est kif-kif.

Oui, mais les gens du métier qui vont te faire les specs et
éventuellement t'expliquer ce qu'il convient de faire, ils vont plutôt
te parler en français, et donc ce n'est pas forcément kif-kif.

--
Loïc

Gabriel Dos Reis

08/10/2004 à 01:04

"Michel Michaud" writes:

| > Évidemment, s'il ne s'agit que de permettre les caractères
| > alphabétiques de ISO 8859-1... La norme en exige beaucoup plus.
|
| En fait, je crois que permettre le jeu de caractères naturel de
| la machine est un minimum.

Et qu'est-ce que c'est ?

-- Gaby

Fabien LE LEZ

08/10/2004 à 02:05

On 07 Oct 2004 18:04:15 -0500, Gabriel Dos Reis :

Et qu'est-ce que c'est ?

Le "Français (Canada)" des options de Windows ?

--
;-)

kanze

08/10/2004 à 09:28

"Michel Michaud" wrote in message
news:<wFb9d.31742$...

Dans le message 4164f5b5$0$22834$,
Michel Michaud wrote:
En fait, je crois que permettre le jeu de caractères naturel de la
machine est un minimum.

C'est quoi, le jeu de caractères naturel d'une machine ? Sur la
mienne, je peux changer quand je veux son "jeu de caractères
naturel".

J'aurais dû dire « courant » alors. Si j'utilise un jeu de caractères,
que mon éditeur me permet d'écrire le programme avec ce jeu,
j'aimerais que le compilateur l'accepte aussi.

Mais qu'est-ce que tu entends par « jeu de caractères courant » ? Mes
éditeurs à moi ont en fait une connaissance très faible du jeu de
caractères, et cette « connaissance » change même selon la mode (c-à-d
que je saisis un programme C++ ou que je saisis du texte). En plus, la
connaissance qu'à l'éditeur est indépendante de la façon qu'affiche le
caractère -- je pourrais très facilement configurer mon système pour que
le caractère que l'éditeur croit un ' ' s'affiche comme un 'a', par
exemple.

Si tu parles du caractère que je vois sur l'écran, ça dépend non de
l'éditeur, mais de la police de caractères utilisés. Or, si c'est vrai
que l'éditeur peut (en général) savoir quelle police sert, voire même la
contrôler, le compilateur n'a aucune façon à savoir quelle police à
servir lors de l'édition du programme. J'ai bien, actuellement,
plusieurs fenêtres ouvertes avec des polices différentes, et il m'est
arrivé de lancer (sous Linux) deux éditeurs, un avec une police UTF-8,
et l'autre avec une police ISO 8859-1.

Si je régarde ici, on écrit du code qui serait compilé sur trois
systèmes : Windows, Solaris et Linux. Typiquement, ICI, l'encodage
Windows est UTF-16LE, Solaris est ISO 8859-1 (ou parfois 8859-15) et
Linux est UTF-8. Or, il n'y a qu'une seule copie du fichier -- le
compilateur lit le code sur un disque monté. Alors, comment veux-tu que
le compilateur dévine pour chaque fichier où il a été saisi. (N'oublie
pas non plus que les compilations de production ont normalement lieu
dans un groupe de processus déconnecté de tout écran.)

Tout ça ne marche, évidemment, que parce que nous ne nous servons que
des caractères de base, et l'encodage des caractères de base est
identique dans les trois encodages.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

"Michel Michaud" <mm@gdzid.com> wrote in message
news:<wFb9d.31742$HO1.1232737@news20.bellglobal.com>...

Dans le message 4164f5b5$0$22834$626a14ce@news.free.fr,

Michel Michaud wrote:

En fait, je crois que permettre le jeu de caractères naturel de la
machine est un minimum.

C'est quoi, le jeu de caractères naturel d'une machine ? Sur la
mienne, je peux changer quand je veux son "jeu de caractères
naturel".

J'aurais dû dire « courant » alors. Si j'utilise un jeu de caractères,
que mon éditeur me permet d'écrire le programme avec ce jeu,
j'aimerais que le compilateur l'accepte aussi.

Mais qu'est-ce que tu entends par « jeu de caractères courant » ? Mes
éditeurs à moi ont en fait une connaissance très faible du jeu de
caractères, et cette « connaissance » change même selon la mode (c-à-d
que je saisis un programme C++ ou que je saisis du texte). En plus, la
connaissance qu'à l'éditeur est indépendante de la façon qu'affiche le
caractère -- je pourrais très facilement configurer mon système pour que
le caractère que l'éditeur croit un ' ' s'affiche comme un 'a', par
exemple.

Si tu parles du caractère que je vois sur l'écran, ça dépend non de
l'éditeur, mais de la police de caractères utilisés. Or, si c'est vrai
que l'éditeur peut (en général) savoir quelle police sert, voire même la
contrôler, le compilateur n'a aucune façon à savoir quelle police à
servir lors de l'édition du programme. J'ai bien, actuellement,
plusieurs fenêtres ouvertes avec des polices différentes, et il m'est
arrivé de lancer (sous Linux) deux éditeurs, un avec une police UTF-8,
et l'autre avec une police ISO 8859-1.

Si je régarde ici, on écrit du code qui serait compilé sur trois
systèmes : Windows, Solaris et Linux. Typiquement, ICI, l'encodage
Windows est UTF-16LE, Solaris est ISO 8859-1 (ou parfois 8859-15) et
Linux est UTF-8. Or, il n'y a qu'une seule copie du fichier -- le
compilateur lit le code sur un disque monté. Alors, comment veux-tu que
le compilateur dévine pour chaque fichier où il a été saisi. (N'oublie
pas non plus que les compilations de production ont normalement lieu
dans un groupe de processus déconnecté de tout écran.)

Tout ça ne marche, évidemment, que parce que nous ne nous servons que
des caractères de base, et l'encodage des caractères de base est
identique dans les trois encodages.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

"Michel Michaud" wrote in message
news:<wFb9d.31742$...

Dans le message 4164f5b5$0$22834$,
Michel Michaud wrote:
En fait, je crois que permettre le jeu de caractères naturel de la
machine est un minimum.

C'est quoi, le jeu de caractères naturel d'une machine ? Sur la
mienne, je peux changer quand je veux son "jeu de caractères
naturel".

J'aurais dû dire « courant » alors. Si j'utilise un jeu de caractères,
que mon éditeur me permet d'écrire le programme avec ce jeu,
j'aimerais que le compilateur l'accepte aussi.

Mais qu'est-ce que tu entends par « jeu de caractères courant » ? Mes
éditeurs à moi ont en fait une connaissance très faible du jeu de
caractères, et cette « connaissance » change même selon la mode (c-à-d
que je saisis un programme C++ ou que je saisis du texte). En plus, la
connaissance qu'à l'éditeur est indépendante de la façon qu'affiche le
caractère -- je pourrais très facilement configurer mon système pour que
le caractère que l'éditeur croit un ' ' s'affiche comme un 'a', par
exemple.

Si tu parles du caractère que je vois sur l'écran, ça dépend non de
l'éditeur, mais de la police de caractères utilisés. Or, si c'est vrai
que l'éditeur peut (en général) savoir quelle police sert, voire même la
contrôler, le compilateur n'a aucune façon à savoir quelle police à
servir lors de l'édition du programme. J'ai bien, actuellement,
plusieurs fenêtres ouvertes avec des polices différentes, et il m'est
arrivé de lancer (sous Linux) deux éditeurs, un avec une police UTF-8,
et l'autre avec une police ISO 8859-1.

Si je régarde ici, on écrit du code qui serait compilé sur trois
systèmes : Windows, Solaris et Linux. Typiquement, ICI, l'encodage
Windows est UTF-16LE, Solaris est ISO 8859-1 (ou parfois 8859-15) et
Linux est UTF-8. Or, il n'y a qu'une seule copie du fichier -- le
compilateur lit le code sur un disque monté. Alors, comment veux-tu que
le compilateur dévine pour chaque fichier où il a été saisi. (N'oublie
pas non plus que les compilations de production ont normalement lieu
dans un groupe de processus déconnecté de tout écran.)

Tout ça ne marche, évidemment, que parce que nous ne nous servons que
des caractères de base, et l'encodage des caractères de base est
identique dans les trois encodages.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

kanze

08/10/2004 à 09:32

Loïc Joly wrote in message
news:<4165a872$0$17801$...

Arnaud Meurgues wrote:
Michel Michaud wrote:

C'est quoi, le jeu de caractères naturel d'une machine ? Sur la
mienne, je peux changer quand je veux son "jeu de caractères
naturel".

J'aurais dû dire « courant » alors. Si j'utilise un jeu de
caractères, que mon éditeur me permet d'écrire le programme avec ce
jeu, j'aimerais que le compilateur l'accepte aussi.

Ben oui, mais c'est compliqué. Notamment à cause du principe des
disques partagés : tout le monde n'a pas forcément le même charset «
courant » et le compilateur va se retrouver avec des fichiers divers
et variés dont il ne pourra pas connaître ni charset ni encoding.

La solution en python est d'indiquer au tout début du fichier
l'encoding de ce fichier. Ca me semble être une solution applicable en
C++, non ?

Applicable, mais non appliqué. Je verrais bien un espèce de
#pragma codeset iso_8859_1
par exemple.

Une autre possibilité que j'ai considéré, c'est un fichier de
configuration dans le répertoire, du genre .codeset. Si ce fichier est
présent, le compilateur lirait tous les fichiers du répertoire avec cet
encodage. (L'avantage, c'est qu'on peut le faire après le coup, sans
modifier les fichiers sources, et que les compilateurs qui ne
connaissent pas l'astuce ne verrait rien.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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

kanze

08/10/2004 à 10:11

"Michel Michaud" wrote in message
news:<oHb9d.31744$...

Dans le message ,
"Michel Michaud" wrote in message
news:<rjZ8d.15516$...
En fait, je crois que permettre le jeu de caractères naturel de la
machine est un minimum.

Tu vis trop dans le monde fermé de Windows. J'ai actuellement des
fenêtres ouvertes sur quatre machines différentes, qui tournent sous
trois OS différentes, sur deux architectures différentes. Une
utilise UTF-16, une autre UTF-8 et deux ISO 8859-1. Et évidemment,
les fichiers que j'édite ne se trouvent sur aucun de ces machines,
mais sur encore une autre machine.

Dans ce contexte, quel est le jeu de caractères naturel ?

Je pensais surtout à « courant » (naturel au sens que c'est celui qui
est actuellement utilisé si je ne fais rien pour le changer).

C-à-d ASCII 7 bits ?

En fait, il y a pas moins de trois encodages indépendamment courants à
la fois :

- Il y a celui que utilise le système, pour des choses comme les
séparateurs de répertoires dans les chemins. Mais c'est un peu
difficile à dire ce que c'est comme encodage, parce que pour la
plupart des caractères, le système se contente d'être transparent.
Donc, par exemple, dans un nom de fichier, le système cherche des
'/' et un '' ; tout encodage qui donne le bon code à ces deux
caractères est bon. Et si mon nom de fichier contient la suite 0xC3
0x89, le système ne sais pas si c'est un é en UTF-8 ou un Ã suivi
d'une tabulation avec justification en ISO 8859-1.

Donc, celui-là ne nous aide pas.

- Il y a celui qui sert dans la logique à l'intérieur des programmes,
pour déterminer si un caractère donné est un blanc ou un chiffre,
par exemple. Ici, ça dépend du programme -- beaucoup de programmes
utilise la même stratégie que le système, en limitant les caractères
qui l'intéresse à un petit ensemble dont l'encodage ne varient pas.
Mais si le programme va plus loin, cet encodage dépend du locale.

Et sur les systèmes dont je me sers, le locale par défaut dépend des
variables d'environement, qui sont propre à chaque utilisateur.
Donc, si le compilateur veut savoir l'encodage, il faut qu'il sache
qui a écrit le fichier. Et encore -- s'il détermine que c'est
l'utilisateur jakan (c'est mon identificateur ici) qui l'a écrit, il
doit encore régarder quel shell j'utilise (dans /etc/passwd), et en
fonction du shell, lire le fichier d'initialisation qui convient.
Sauf qu'il y a deux problèmes de taille avec cette politique :

. Il n'a généralement pas le droit de lire mes fichiers à moi, et

. Même s'il peut les lire, il s'avère que la seule chose que je
fais avec mon shell de login, c'est lancer mon desktop, et dans
le desktop, j'ai configuré les menus, etc., pour utiliser
directement un autre shell. Il va donc trouver que mon shell,
c'est ksh, il va lire donc .profile, et il va trouver donc que
je ne position ni LC_ALL ni LC_CTYPE, et que donc, l'encodage
est celui qui correspond au locale "C", c-à-d ASCII 7 bits.
Seulement à partir des menus, j'invoque des xterm, des éditeurs,
etc. toujours à travers des scripts en bash, qui lisent
.bash_profile, où je positionne bien LC_CTYPE à iso_8859_1, ce
qui veut dire que l'éditeur, et tous les autres programmes chez
moi, vont travailler en ISO 8859-1, et non ASCII.

- Il y a celui des caractères que tu vois sur l'écran. Et celui dépend
uniquement de la police utilisée à l'affichage. Lors de
l'affichage ; à titre d'expériment, j'ai déjà affiché un nom de
fichier dans deux fenêtres différentes avec deux polices
différentes. Et le nom du fichier apparaissait bien différent, alors
que c'était le même fichier.

Typiquement, en ce qui nous concerne, c'est celui qui serait la plus
intéressant. Si je vois un é dans mon code, c'est que je veux que le
compilateur le comprend comme un é, c-à-d une lettre qui est légale
dans un identificateur.

Normalement, j'aurais pris soin que l'encodage utilisé internalement
par l'éditeur (celui donné par LC_CTYPE) correspond à celui utilisé
par les polices d'affichage de l'éditeur (donné par des propriétés
X) (mais curieusement, je ne crois pas que l'éditeur le vérifie,
alors qu'il pourrait). (Je dis normalement, parce que ce n'est pas
toujours simple. Les propriétés X qui détermine la police sont lues
sur la machine qui affiche la fenêtre, tandis que l'environement est
lu sur la machine sur laquelle execute le programme.)

Le problème se passe lors que mon collègue sous Linux compile mon code.
Lui, il travaille exclusivement en UTF-8. Or, le compilateur 1) ne sais
pas que c'est moi qui a écrit le code, et 2) même s'il savait, n'a pas
la possibilité de savoir ni l'encodage interne qu'a utilisé mon éditeur,
ni encore moins l'encodage de la police d'affichage lors ce que je
éditait le fichier.

Si tu peux éditer ton programme sur plusieurs de ces machines,
j'aimerais simplement que les compilateurs de ces machines acceptent
aussi le code que ton éditeur produit.

Le problème, c'est que l'encodage n'est pas forcement le même sur des
machines différentes. En fait, si on parle de l'encodage de l'affichage,
il n'est pas forcement le même sur la même machine, selon que je me
loggue en locale ou en remote. (En remote, la police est toujours celle
de la machine où apparaît la fenêtre.)

Et c'est un problème, indépendamment du compilateur. Si toutes les
polices installées sur les machines Linux sont UTF-8, et toutes les
polices installées sur les machines Solaris sont ISO 8859-1, même les
éditeurs ne vont pas pouvoir affichés correctement sur une machine ce
qui a été écrit sur l'autre.

Et en passant, si je n'ai pas de problèmes entre Solaris et Windows (et
en fait, avec Linux non plus, parce qu'on a installé les polices 8859-1
là aussi), c'est parce que les premiers 256 positions de UTF-16 sont
identiques à 8859-1. Si je travaillé à Prague, plutôt qu'à Paris,
j'aurais des problèmes là aussi.

Mais bon, je peux rêver :-)

Si tu t'attends que quoique ce soit soit simple avec les encodages non
US, effectivement, tu rêve.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

"Michel Michaud" <mm@gdzid.com> wrote in message
news:<oHb9d.31744$HO1.1234056@news20.bellglobal.com>...

Dans le message d6652001.0410070026.38f8d631@posting.google.com,

"Michel Michaud" <mm@gdzid.com> wrote in message
news:<rjZ8d.15516$HO1.929619@news20.bellglobal.com>...

En fait, je crois que permettre le jeu de caractères naturel de la
machine est un minimum.

Tu vis trop dans le monde fermé de Windows. J'ai actuellement des
fenêtres ouvertes sur quatre machines différentes, qui tournent sous
trois OS différentes, sur deux architectures différentes. Une
utilise UTF-16, une autre UTF-8 et deux ISO 8859-1. Et évidemment,
les fichiers que j'édite ne se trouvent sur aucun de ces machines,
mais sur encore une autre machine.

Dans ce contexte, quel est le jeu de caractères naturel ?

Je pensais surtout à « courant » (naturel au sens que c'est celui qui
est actuellement utilisé si je ne fais rien pour le changer).

C-à-d ASCII 7 bits ?

En fait, il y a pas moins de trois encodages indépendamment courants à
la fois :

- Il y a celui que utilise le système, pour des choses comme les
séparateurs de répertoires dans les chemins. Mais c'est un peu
difficile à dire ce que c'est comme encodage, parce que pour la
plupart des caractères, le système se contente d'être transparent.
Donc, par exemple, dans un nom de fichier, le système cherche des
'/' et un '' ; tout encodage qui donne le bon code à ces deux
caractères est bon. Et si mon nom de fichier contient la suite 0xC3
0x89, le système ne sais pas si c'est un é en UTF-8 ou un Ã suivi
d'une tabulation avec justification en ISO 8859-1.

Donc, celui-là ne nous aide pas.

- Il y a celui qui sert dans la logique à l'intérieur des programmes,
pour déterminer si un caractère donné est un blanc ou un chiffre,
par exemple. Ici, ça dépend du programme -- beaucoup de programmes
utilise la même stratégie que le système, en limitant les caractères
qui l'intéresse à un petit ensemble dont l'encodage ne varient pas.
Mais si le programme va plus loin, cet encodage dépend du locale.

Et sur les systèmes dont je me sers, le locale par défaut dépend des
variables d'environement, qui sont propre à chaque utilisateur.
Donc, si le compilateur veut savoir l'encodage, il faut qu'il sache
qui a écrit le fichier. Et encore -- s'il détermine que c'est
l'utilisateur jakan (c'est mon identificateur ici) qui l'a écrit, il
doit encore régarder quel shell j'utilise (dans /etc/passwd), et en
fonction du shell, lire le fichier d'initialisation qui convient.
Sauf qu'il y a deux problèmes de taille avec cette politique :

. Il n'a généralement pas le droit de lire mes fichiers à moi, et

. Même s'il peut les lire, il s'avère que la seule chose que je
fais avec mon shell de login, c'est lancer mon desktop, et dans
le desktop, j'ai configuré les menus, etc., pour utiliser
directement un autre shell. Il va donc trouver que mon shell,
c'est ksh, il va lire donc .profile, et il va trouver donc que
je ne position ni LC_ALL ni LC_CTYPE, et que donc, l'encodage
est celui qui correspond au locale "C", c-à-d ASCII 7 bits.
Seulement à partir des menus, j'invoque des xterm, des éditeurs,
etc. toujours à travers des scripts en bash, qui lisent
.bash_profile, où je positionne bien LC_CTYPE à iso_8859_1, ce
qui veut dire que l'éditeur, et tous les autres programmes chez
moi, vont travailler en ISO 8859-1, et non ASCII.

- Il y a celui des caractères que tu vois sur l'écran. Et celui dépend
uniquement de la police utilisée à l'affichage. Lors de
l'affichage ; à titre d'expériment, j'ai déjà affiché un nom de
fichier dans deux fenêtres différentes avec deux polices
différentes. Et le nom du fichier apparaissait bien différent, alors
que c'était le même fichier.

Typiquement, en ce qui nous concerne, c'est celui qui serait la plus
intéressant. Si je vois un é dans mon code, c'est que je veux que le
compilateur le comprend comme un é, c-à-d une lettre qui est légale
dans un identificateur.

Normalement, j'aurais pris soin que l'encodage utilisé internalement
par l'éditeur (celui donné par LC_CTYPE) correspond à celui utilisé
par les polices d'affichage de l'éditeur (donné par des propriétés
X) (mais curieusement, je ne crois pas que l'éditeur le vérifie,
alors qu'il pourrait). (Je dis normalement, parce que ce n'est pas
toujours simple. Les propriétés X qui détermine la police sont lues
sur la machine qui affiche la fenêtre, tandis que l'environement est
lu sur la machine sur laquelle execute le programme.)

Le problème se passe lors que mon collègue sous Linux compile mon code.
Lui, il travaille exclusivement en UTF-8. Or, le compilateur 1) ne sais
pas que c'est moi qui a écrit le code, et 2) même s'il savait, n'a pas
la possibilité de savoir ni l'encodage interne qu'a utilisé mon éditeur,
ni encore moins l'encodage de la police d'affichage lors ce que je
éditait le fichier.

Si tu peux éditer ton programme sur plusieurs de ces machines,
j'aimerais simplement que les compilateurs de ces machines acceptent
aussi le code que ton éditeur produit.

Le problème, c'est que l'encodage n'est pas forcement le même sur des
machines différentes. En fait, si on parle de l'encodage de l'affichage,
il n'est pas forcement le même sur la même machine, selon que je me
loggue en locale ou en remote. (En remote, la police est toujours celle
de la machine où apparaît la fenêtre.)

Et c'est un problème, indépendamment du compilateur. Si toutes les
polices installées sur les machines Linux sont UTF-8, et toutes les
polices installées sur les machines Solaris sont ISO 8859-1, même les
éditeurs ne vont pas pouvoir affichés correctement sur une machine ce
qui a été écrit sur l'autre.

Et en passant, si je n'ai pas de problèmes entre Solaris et Windows (et
en fait, avec Linux non plus, parce qu'on a installé les polices 8859-1
là aussi), c'est parce que les premiers 256 positions de UTF-16 sont
identiques à 8859-1. Si je travaillé à Prague, plutôt qu'à Paris,
j'aurais des problèmes là aussi.

Mais bon, je peux rêver :-)

Si tu t'attends que quoique ce soit soit simple avec les encodages non
US, effectivement, tu rêve.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

"Michel Michaud" wrote in message
news:<oHb9d.31744$...

Dans le message ,
"Michel Michaud" wrote in message
news:<rjZ8d.15516$...
En fait, je crois que permettre le jeu de caractères naturel de la
machine est un minimum.

Tu vis trop dans le monde fermé de Windows. J'ai actuellement des
fenêtres ouvertes sur quatre machines différentes, qui tournent sous
trois OS différentes, sur deux architectures différentes. Une
utilise UTF-16, une autre UTF-8 et deux ISO 8859-1. Et évidemment,
les fichiers que j'édite ne se trouvent sur aucun de ces machines,
mais sur encore une autre machine.

Dans ce contexte, quel est le jeu de caractères naturel ?

Je pensais surtout à « courant » (naturel au sens que c'est celui qui
est actuellement utilisé si je ne fais rien pour le changer).

C-à-d ASCII 7 bits ?

En fait, il y a pas moins de trois encodages indépendamment courants à
la fois :

- Il y a celui que utilise le système, pour des choses comme les
séparateurs de répertoires dans les chemins. Mais c'est un peu
difficile à dire ce que c'est comme encodage, parce que pour la
plupart des caractères, le système se contente d'être transparent.
Donc, par exemple, dans un nom de fichier, le système cherche des
'/' et un '' ; tout encodage qui donne le bon code à ces deux
caractères est bon. Et si mon nom de fichier contient la suite 0xC3
0x89, le système ne sais pas si c'est un é en UTF-8 ou un Ã suivi
d'une tabulation avec justification en ISO 8859-1.

Donc, celui-là ne nous aide pas.

- Il y a celui qui sert dans la logique à l'intérieur des programmes,
pour déterminer si un caractère donné est un blanc ou un chiffre,
par exemple. Ici, ça dépend du programme -- beaucoup de programmes
utilise la même stratégie que le système, en limitant les caractères
qui l'intéresse à un petit ensemble dont l'encodage ne varient pas.
Mais si le programme va plus loin, cet encodage dépend du locale.

Et sur les systèmes dont je me sers, le locale par défaut dépend des
variables d'environement, qui sont propre à chaque utilisateur.
Donc, si le compilateur veut savoir l'encodage, il faut qu'il sache
qui a écrit le fichier. Et encore -- s'il détermine que c'est
l'utilisateur jakan (c'est mon identificateur ici) qui l'a écrit, il
doit encore régarder quel shell j'utilise (dans /etc/passwd), et en
fonction du shell, lire le fichier d'initialisation qui convient.
Sauf qu'il y a deux problèmes de taille avec cette politique :

. Il n'a généralement pas le droit de lire mes fichiers à moi, et

. Même s'il peut les lire, il s'avère que la seule chose que je
fais avec mon shell de login, c'est lancer mon desktop, et dans
le desktop, j'ai configuré les menus, etc., pour utiliser
directement un autre shell. Il va donc trouver que mon shell,
c'est ksh, il va lire donc .profile, et il va trouver donc que
je ne position ni LC_ALL ni LC_CTYPE, et que donc, l'encodage
est celui qui correspond au locale "C", c-à-d ASCII 7 bits.
Seulement à partir des menus, j'invoque des xterm, des éditeurs,
etc. toujours à travers des scripts en bash, qui lisent
.bash_profile, où je positionne bien LC_CTYPE à iso_8859_1, ce
qui veut dire que l'éditeur, et tous les autres programmes chez
moi, vont travailler en ISO 8859-1, et non ASCII.

- Il y a celui des caractères que tu vois sur l'écran. Et celui dépend
uniquement de la police utilisée à l'affichage. Lors de
l'affichage ; à titre d'expériment, j'ai déjà affiché un nom de
fichier dans deux fenêtres différentes avec deux polices
différentes. Et le nom du fichier apparaissait bien différent, alors
que c'était le même fichier.

Typiquement, en ce qui nous concerne, c'est celui qui serait la plus
intéressant. Si je vois un é dans mon code, c'est que je veux que le
compilateur le comprend comme un é, c-à-d une lettre qui est légale
dans un identificateur.

Normalement, j'aurais pris soin que l'encodage utilisé internalement
par l'éditeur (celui donné par LC_CTYPE) correspond à celui utilisé
par les polices d'affichage de l'éditeur (donné par des propriétés
X) (mais curieusement, je ne crois pas que l'éditeur le vérifie,
alors qu'il pourrait). (Je dis normalement, parce que ce n'est pas
toujours simple. Les propriétés X qui détermine la police sont lues
sur la machine qui affiche la fenêtre, tandis que l'environement est
lu sur la machine sur laquelle execute le programme.)

Le problème se passe lors que mon collègue sous Linux compile mon code.
Lui, il travaille exclusivement en UTF-8. Or, le compilateur 1) ne sais
pas que c'est moi qui a écrit le code, et 2) même s'il savait, n'a pas
la possibilité de savoir ni l'encodage interne qu'a utilisé mon éditeur,
ni encore moins l'encodage de la police d'affichage lors ce que je
éditait le fichier.

Si tu peux éditer ton programme sur plusieurs de ces machines,
j'aimerais simplement que les compilateurs de ces machines acceptent
aussi le code que ton éditeur produit.

Le problème, c'est que l'encodage n'est pas forcement le même sur des
machines différentes. En fait, si on parle de l'encodage de l'affichage,
il n'est pas forcement le même sur la même machine, selon que je me
loggue en locale ou en remote. (En remote, la police est toujours celle
de la machine où apparaît la fenêtre.)

Et c'est un problème, indépendamment du compilateur. Si toutes les
polices installées sur les machines Linux sont UTF-8, et toutes les
polices installées sur les machines Solaris sont ISO 8859-1, même les
éditeurs ne vont pas pouvoir affichés correctement sur une machine ce
qui a été écrit sur l'autre.

Et en passant, si je n'ai pas de problèmes entre Solaris et Windows (et
en fait, avec Linux non plus, parce qu'on a installé les polices 8859-1
là aussi), c'est parce que les premiers 256 positions de UTF-16 sont
identiques à 8859-1. Si je travaillé à Prague, plutôt qu'à Paris,
j'aurais des problèmes là aussi.

Mais bon, je peux rêver :-)

Si tu t'attends que quoique ce soit soit simple avec les encodages non
US, effectivement, tu rêve.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

kanze

08/10/2004 à 10:45

"Michel Michaud" wrote in message
news:<9Rb9d.31751$...

Dans le message 416524d4$0$25729$,
Nous sommes bien d'accord, alors. Rien dans la norme d'oblige à
accepter
ChercherValeur(int p_valeurCherchée)
: m_valeurCherchée(p_valeurCherchée)
{}

C-à-d avec é représenté par 0xE9 ? Non. Ni avec é représenté par 0xC3,
0x89.

À ce que j'ai compris de plusieurs discussions, on ne peut
imposer que ce soit accepté tel quel, c'est pourquoi il y
a les u. Mais si la plate-forme le permet, l'idée est
clairement de les accepter tel quel.

L'intention, je crois, c'était bien que les implémentations l'acceptent.
Sauf qu'une fois de plus, on a normalisé dans la vide, sans avoir de la
pratique pour savoir ce qu'on faisait. C'est bien beau de dire que
l'intention est que l'implémentation accepte des caractères accentués
(et des Kanji, et des ...) si le système le permettait, il faut d'abord
savoir exactement ce que ça veut dire.

En passant, je ne crois pas que c'est le comité qui voulait tant innové
à cette occasion ; je crois plutôt qu'il était politiquement obligé.
Mais c'est juste une impression que j'ai eu ; il faudrait vérifier avec
des personnes qui y étaient à l'époque. (Si Gaby a envie de faire un peu
de récherche, je serais intéressé à savoir quand les UCN ont apparu dans
les drafts pour la première fois, et quand ils ont été proposés. J'ai
l'impression qu'ils y étaient déjà dans le premier draft que j'ai lu,
environ 1993, mais c'est une impression encore plus vague qu'un
souvenir -- c-à-d qu'à vrai dire, je ne sais pas.)

En fait, pour des petits systèmes, développés par une ou deux personnes
dans un environement homogène, je crois que c'est jouable. Java le fait.
En revanche, je ne sais pas comment les développeurs en Java en sortent
dans des grands projets dans des environements hétérogènes. (Je ne sais
même pas s'il existe de tels projets en Java.) Peut-être ils interdisent
des caractères accentués. (Note que plus un projet est grand, plus il y
a des chances qu'il soit international, et donc, plus il y a de chances
que la langue du projet soit l'anglais, où le problème des caractères
accentués ne se pose pas.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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

"Michel Michaud" <mm@gdzid.com> wrote in message
news:<9Rb9d.31751$HO1.1238959@news20.bellglobal.com>...

Dans le message 416524d4$0$25729$636a15ce@news.free.fr,

Nous sommes bien d'accord, alors. Rien dans la norme d'oblige à
accepter
ChercherValeur(int p_valeurCherchée)
: m_valeurCherchée(p_valeurCherchée)
{}

C-à-d avec é représenté par 0xE9 ? Non. Ni avec é représenté par 0xC3,
0x89.

À ce que j'ai compris de plusieurs discussions, on ne peut
imposer que ce soit accepté tel quel, c'est pourquoi il y
a les u. Mais si la plate-forme le permet, l'idée est
clairement de les accepter tel quel.

L'intention, je crois, c'était bien que les implémentations l'acceptent.
Sauf qu'une fois de plus, on a normalisé dans la vide, sans avoir de la
pratique pour savoir ce qu'on faisait. C'est bien beau de dire que
l'intention est que l'implémentation accepte des caractères accentués
(et des Kanji, et des ...) si le système le permettait, il faut d'abord
savoir exactement ce que ça veut dire.

En passant, je ne crois pas que c'est le comité qui voulait tant innové
à cette occasion ; je crois plutôt qu'il était politiquement obligé.
Mais c'est juste une impression que j'ai eu ; il faudrait vérifier avec
des personnes qui y étaient à l'époque. (Si Gaby a envie de faire un peu
de récherche, je serais intéressé à savoir quand les UCN ont apparu dans
les drafts pour la première fois, et quand ils ont été proposés. J'ai
l'impression qu'ils y étaient déjà dans le premier draft que j'ai lu,
environ 1993, mais c'est une impression encore plus vague qu'un
souvenir -- c-à-d qu'à vrai dire, je ne sais pas.)

En fait, pour des petits systèmes, développés par une ou deux personnes
dans un environement homogène, je crois que c'est jouable. Java le fait.
En revanche, je ne sais pas comment les développeurs en Java en sortent
dans des grands projets dans des environements hétérogènes. (Je ne sais
même pas s'il existe de tels projets en Java.) Peut-être ils interdisent
des caractères accentués. (Note que plus un projet est grand, plus il y
a des chances qu'il soit international, et donc, plus il y a de chances
que la langue du projet soit l'anglais, où le problème des caractères
accentués ne se pose pas.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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

"Michel Michaud" wrote in message
news:<9Rb9d.31751$...

Dans le message 416524d4$0$25729$,
Nous sommes bien d'accord, alors. Rien dans la norme d'oblige à
accepter
ChercherValeur(int p_valeurCherchée)
: m_valeurCherchée(p_valeurCherchée)
{}

C-à-d avec é représenté par 0xE9 ? Non. Ni avec é représenté par 0xC3,
0x89.

À ce que j'ai compris de plusieurs discussions, on ne peut
imposer que ce soit accepté tel quel, c'est pourquoi il y
a les u. Mais si la plate-forme le permet, l'idée est
clairement de les accepter tel quel.

L'intention, je crois, c'était bien que les implémentations l'acceptent.
Sauf qu'une fois de plus, on a normalisé dans la vide, sans avoir de la
pratique pour savoir ce qu'on faisait. C'est bien beau de dire que
l'intention est que l'implémentation accepte des caractères accentués
(et des Kanji, et des ...) si le système le permettait, il faut d'abord
savoir exactement ce que ça veut dire.

En passant, je ne crois pas que c'est le comité qui voulait tant innové
à cette occasion ; je crois plutôt qu'il était politiquement obligé.
Mais c'est juste une impression que j'ai eu ; il faudrait vérifier avec
des personnes qui y étaient à l'époque. (Si Gaby a envie de faire un peu
de récherche, je serais intéressé à savoir quand les UCN ont apparu dans
les drafts pour la première fois, et quand ils ont été proposés. J'ai
l'impression qu'ils y étaient déjà dans le premier draft que j'ai lu,
environ 1993, mais c'est une impression encore plus vague qu'un
souvenir -- c-à-d qu'à vrai dire, je ne sais pas.)

En fait, pour des petits systèmes, développés par une ou deux personnes
dans un environement homogène, je crois que c'est jouable. Java le fait.
En revanche, je ne sais pas comment les développeurs en Java en sortent
dans des grands projets dans des environements hétérogènes. (Je ne sais
même pas s'il existe de tels projets en Java.) Peut-être ils interdisent
des caractères accentués. (Note que plus un projet est grand, plus il y
a des chances qu'il soit international, et donc, plus il y a de chances
que la langue du projet soit l'anglais, où le problème des caractères
accentués ne se pose pas.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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

kanze

08/10/2004 à 10:52

Fabien LE LEZ wrote in message
news:...

On Wed, 6 Oct 2004 23:58:20 -0400, "Michel Michaud" :

Je crois que le raisonnement est à l'envers. Si je veux compiler un
code avec un certain compilateur, je lui donne le code dans le jeu de
caractères qu'il connaît.

Du coup, tu n'as pas besoin que le compilo comprenne les caractères
non-ASCII, il suffit de modifier ton code en entrée. Par exemple :

a-zA-Z restent tels quels
_ devient _005F
é devient _00E9
à devient _00E0
rho minuscule devient _03C1

Et zou, tu tapes les caractères que tu veux, tu passes la moulinette,
et le compilo n'y voit que du feu. Reste à passer les messages
d'erreurs à la moulinette inverse, et le tour est joué.

Qu'est-ce qui se passe avec :

void
f()
{
int été ;
int _00E9t_00E9 ;
}

?

--
James Kanze GABI Software http://www.gabi-soft.fr
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

recherche d'un element suivant la valeur d'un des champs

10 réponses

Veuillez sélectionner un problème