Re: bash et UTF-8

Erwan David

03/08/2004 à 13:40

Le Tue 3/08/2004, denis31.barbier disait

Ce que tu décris avec wchar est autre chose, mais les
ayatollahs de l'UTF-8 sont contre car ça permet aux
codages existants (8-bit ou multibyte) de continuer à
être supportés, alors qu'il faudrait les éradiquer.

Sauf qu'on est actuellement obligé de les supporter. Par exemple au
boulot je pourrais passer en tout UTF-8, mais ça foutrais la merde
quand mon code serait compilé sous windows... Il faut donc que les
sources que j'édite (au moins) soient en iso-8859-1.

--
Erwan

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Laurent Giroud

03/08/2004 à 14:00

On Tue, 3 Aug 2004 13:38:03 +0200, Erwan David wrote:

Le Tue 3/08/2004, denis31.barbier disait

> Ce que tu décris avec wchar est autre chose, mais les
> ayatollahs de l'UTF-8 sont contre car ça permet aux
> codages existants (8-bit ou multibyte) de continuer à
> être supportés, alors qu'il faudrait les éradiquer.

Sauf qu'on est actuellement obligé de les supporter. Par exemple au
boulot je pourrais passer en tout UTF-8, mais ça foutrais la merde
quand mon code serait compilé sous windows... Il faut donc que les
sources que j'édite (au moins) soient en iso-8859-1.

Sous Debian, le système des locales permet de gérer n'importe quel encodage en entrée de façon transparente pour peu que le logiciel utilise correctement les caractères multi-bytes. Si ta locale est en 8859-1, tes softs gèreront automatiquement des fichiers en 8859-1.

La contrainte n'est pas sur les sources, elle est sur l'utilisateur qui doit sélectionner la locale en fonction du type d'encodage des fichiers manipulés.

Laurent

--
Pensez

Erwan David

03/08/2004 à 14:00

Le Tue 3/08/2004, Laurent Giroud disait

On Tue, 3 Aug 2004 13:38:03 +0200, Erwan David wrote:

> Le Tue 3/08/2004, denis31.barbier disait
>
> > Ce que tu décris avec wchar est autre chose, mais les
> > ayatollahs de l'UTF-8 sont contre car ça permet aux
> > codages existants (8-bit ou multibyte) de continuer à
> > être supportés, alors qu'il faudrait les éradiquer.
>
> Sauf qu'on est actuellement obligé de les supporter. Par exemple au
> boulot je pourrais passer en tout UTF-8, mais ça foutrais la merde
> quand mon code serait compilé sous windows... Il faut donc que les
> sources que j'édite (au moins) soient en iso-8859-1.

Sous Debian, le système des locales permet de gérer n'importe quel
encodage en entrée de façon transparente pour peu que le logiciel
utilise correctement les caractères multi-bytes. Si ta locale est en
8859-1, tes softs gèreront automatiquement des fichiers en 8859-1.

eh oh y'a autre chose que debian dans la vie. En particulier mes
sources C et Java doivent compiler sous windows...

--
Erwan

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Laurent Giroud

03/08/2004 à 14:20

> [Laurent Giroud]
> Ca c'est bizarre.
> L'UTF-8 est calqué quasiment identiquement sur
> l'iso-8859-15 pour les 8 premiers bits.

Tu confonds la table des caractères et le codage utilisé.

Pas tout à fait, j'ai cru me souvenir que l'ISO-8859-15 était un sous ensemble de l'UTF-8, alors que c'est l'ASCII qui en est un.
Mais bon, je me suis gourré c'est clair :)

> Ce n'est pas l'utilisation d'un "il suffit" qui permet
> de dire que c'est irréaliste, c'est l'ampleur de la
> tâche que ça représente.

C'est bien beau de se documenter, encore faut-il passer à
la pratique ;)

Si tout ce qui t'intéresse est de fournir un bon support
pour l'UTF-8, la solution la plus simple est de conserver
des char et de changer les routines de calcul de
longueur de chaînes, recherche d'expressions, etc. C'est
ce que fait la majorité des programmeurs, avec
éventuellement conversion du codage si l'utilisateur
n'est pas en UTF-8.

Effectivement, c'est mieux qu'utiliser les wchar car ceux-ci sont de taille fixe et donc moins souples et surtout imposent un encodage unicode alors que conserver des char permet de gérer n'importe quel type d'encodage supporté par la locale (via la libc).
La quantité de travail est équivalente en revanche.

Ce que tu décris avec wchar est autre chose, mais les
ayatollahs de l'UTF-8 sont contre car ça permet aux
codages existants (8-bit ou multibyte) de continuer à
être supportés, alors qu'il faudrait les éradiquer.

L'éradication me parait un objectif assez utopiste et implique de toute manière qu'on dispose toujours de convertisseurs local->unicode en cas de rencontre d'un fichier non encodé dans un des divers formats unicode. Donc entre le système des locales et ça mon coeur balance... :)

Les 2 approches requièrent beaucoup plus de travail que
tu ne sembles l'imaginer.

C'est très possible, en effet comme tu l'indiques, je ne suis pas passé de la documentation à la pratique pour l'instant ;)

Mais néanmoins, la libc et gettext gèrent déjà automatiquement l'encodage en fonction de la locale, si la lib de recherche d'expressions le gère également, c'est autant de travail en moins (j'ose espérer que tout le monde ne réécrit pas ses propres routines de gestion de chaînes dans son coin).
L'essentiel du travail me semble assez simple si la gestion des caractères textuels a été écrite de façon relativement neutre.

Je vais coder sous peu des trucs en liaison avec tout ça, donc si je me trompe je ne manquerais pas de te donner raison ;)

Hop,
Laurent

PS : ceci dit, on dérive un peu non ? c'est plus trop debian comme discussion ;)

--
Pensez

> [Laurent Giroud]
> Ca c'est bizarre.
> L'UTF-8 est calqué quasiment identiquement sur
> l'iso-8859-15 pour les 8 premiers bits.

Tu confonds la table des caractères et le codage utilisé.

Pas tout à fait, j'ai cru me souvenir que l'ISO-8859-15 était un sous ensemble de l'UTF-8, alors que c'est l'ASCII qui en est un.
Mais bon, je me suis gourré c'est clair :)

> Ce n'est pas l'utilisation d'un "il suffit" qui permet
> de dire que c'est irréaliste, c'est l'ampleur de la
> tâche que ça représente.

C'est bien beau de se documenter, encore faut-il passer à
la pratique ;)

Si tout ce qui t'intéresse est de fournir un bon support
pour l'UTF-8, la solution la plus simple est de conserver
des char et de changer les routines de calcul de
longueur de chaînes, recherche d'expressions, etc. C'est
ce que fait la majorité des programmeurs, avec
éventuellement conversion du codage si l'utilisateur
n'est pas en UTF-8.

Effectivement, c'est mieux qu'utiliser les wchar car ceux-ci sont de taille fixe et donc moins souples et surtout imposent un encodage unicode alors que conserver des char permet de gérer n'importe quel type d'encodage supporté par la locale (via la libc).
La quantité de travail est équivalente en revanche.

Ce que tu décris avec wchar est autre chose, mais les
ayatollahs de l'UTF-8 sont contre car ça permet aux
codages existants (8-bit ou multibyte) de continuer à
être supportés, alors qu'il faudrait les éradiquer.

L'éradication me parait un objectif assez utopiste et implique de toute manière qu'on dispose toujours de convertisseurs local->unicode en cas de rencontre d'un fichier non encodé dans un des divers formats unicode. Donc entre le système des locales et ça mon coeur balance... :)

Les 2 approches requièrent beaucoup plus de travail que
tu ne sembles l'imaginer.

C'est très possible, en effet comme tu l'indiques, je ne suis pas passé de la documentation à la pratique pour l'instant ;)

Mais néanmoins, la libc et gettext gèrent déjà automatiquement l'encodage en fonction de la locale, si la lib de recherche d'expressions le gère également, c'est autant de travail en moins (j'ose espérer que tout le monde ne réécrit pas ses propres routines de gestion de chaînes dans son coin).
L'essentiel du travail me semble assez simple si la gestion des caractères textuels a été écrite de façon relativement neutre.

Je vais coder sous peu des trucs en liaison avec tout ça, donc si je me trompe je ne manquerais pas de te donner raison ;)

Hop,
Laurent

PS : ceci dit, on dérive un peu non ? c'est plus trop debian comme discussion ;)

--
Pensez

Vous avez filtré cet utilisateur ! Consultez son message

> [Laurent Giroud]
> Ca c'est bizarre.
> L'UTF-8 est calqué quasiment identiquement sur
> l'iso-8859-15 pour les 8 premiers bits.

Tu confonds la table des caractères et le codage utilisé.

Pas tout à fait, j'ai cru me souvenir que l'ISO-8859-15 était un sous ensemble de l'UTF-8, alors que c'est l'ASCII qui en est un.
Mais bon, je me suis gourré c'est clair :)

> Ce n'est pas l'utilisation d'un "il suffit" qui permet
> de dire que c'est irréaliste, c'est l'ampleur de la
> tâche que ça représente.

C'est bien beau de se documenter, encore faut-il passer à
la pratique ;)

Si tout ce qui t'intéresse est de fournir un bon support
pour l'UTF-8, la solution la plus simple est de conserver
des char et de changer les routines de calcul de
longueur de chaînes, recherche d'expressions, etc. C'est
ce que fait la majorité des programmeurs, avec
éventuellement conversion du codage si l'utilisateur
n'est pas en UTF-8.

Effectivement, c'est mieux qu'utiliser les wchar car ceux-ci sont de taille fixe et donc moins souples et surtout imposent un encodage unicode alors que conserver des char permet de gérer n'importe quel type d'encodage supporté par la locale (via la libc).
La quantité de travail est équivalente en revanche.

Ce que tu décris avec wchar est autre chose, mais les
ayatollahs de l'UTF-8 sont contre car ça permet aux
codages existants (8-bit ou multibyte) de continuer à
être supportés, alors qu'il faudrait les éradiquer.

L'éradication me parait un objectif assez utopiste et implique de toute manière qu'on dispose toujours de convertisseurs local->unicode en cas de rencontre d'un fichier non encodé dans un des divers formats unicode. Donc entre le système des locales et ça mon coeur balance... :)

Les 2 approches requièrent beaucoup plus de travail que
tu ne sembles l'imaginer.

C'est très possible, en effet comme tu l'indiques, je ne suis pas passé de la documentation à la pratique pour l'instant ;)

Mais néanmoins, la libc et gettext gèrent déjà automatiquement l'encodage en fonction de la locale, si la lib de recherche d'expressions le gère également, c'est autant de travail en moins (j'ose espérer que tout le monde ne réécrit pas ses propres routines de gestion de chaînes dans son coin).
L'essentiel du travail me semble assez simple si la gestion des caractères textuels a été écrite de façon relativement neutre.

Je vais coder sous peu des trucs en liaison avec tout ça, donc si je me trompe je ne manquerais pas de te donner raison ;)

Hop,
Laurent

PS : ceci dit, on dérive un peu non ? c'est plus trop debian comme discussion ;)

--
Pensez

Erwan David

03/08/2004 à 14:30

Le Tue 3/08/2004, Laurent Giroud disait

Effectivement, c'est mieux qu'utiliser les wchar car ceux-ci sont de
taille fixe et donc moins souples et surtout imposent un encodage
unicode alors que conserver des char permet de gérer n'importe quel
type d'encodage supporté par la locale (via la libc). La quantité
de travail est équivalente en revanche.

1)
la gestion des locales ce n'est *pas* le boulot d'une libc. C'est
dans la glibc mais elle n'est pas partout (et heureusement...)

2) la locale a une granularité trop grande et mélange tout : jeux de
caracyères, langue des messages, formats numériques, etc...

> Ce que tu décris avec wchar est autre chose, mais les
> ayatollahs de l'UTF-8 sont contre car ça permet aux
> codages existants (8-bit ou multibyte) de continuer à
> être supportés, alors qu'il faudrait les éradiquer.

L'éradication me parait un objectif assez utopiste et implique de
toute manière qu'on dispose toujours de convertisseurs
local->unicode en cas de rencontre d'un fichier non encodé dans un
des divers formats unicode. Donc entre le système des locales et ça
mon coeur balance... :)

> Les 2 approches requièrent beaucoup plus de travail que
> tu ne sembles l'imaginer.

C'est très possible, en effet comme tu l'indiques, je ne suis pas
passé de la documentation à la pratique pour l'instant ;)

Mais néanmoins, la libc et gettext gèrent déjà automatiquement
l'encodage en fonction de la locale, si la lib de recherche
d'expressions le gère également, c'est autant de travail en moins
(j'ose espérer que tout le monde ne réécrit pas ses propres routines
de gestion de chaînes dans son coin). L'essentiel du travail me
semble assez simple si la gestion des caractères textuels a été
écrite de façon relativement neutre.

Je vais coder sous peu des trucs en liaison avec tout ça, donc si je
me trompe je ne manquerais pas de te donner raison ;)

la Glibc, pas la libc. Une libc ne devrait conteni_r *que* ce qui est
défini par la norme du C : les jeux de caractère n'ont rien à y faire;
D'ailleurs sit tu veux que ton code soit autre chose qu'une linuxerie
fermée, va falloir y faire gaffe...

--
Erwan

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Le Tue 3/08/2004, Laurent Giroud disait

Effectivement, c'est mieux qu'utiliser les wchar car ceux-ci sont de
taille fixe et donc moins souples et surtout imposent un encodage
unicode alors que conserver des char permet de gérer n'importe quel
type d'encodage supporté par la locale (via la libc). La quantité
de travail est équivalente en revanche.

1)
la gestion des locales ce n'est *pas* le boulot d'une libc. C'est
dans la glibc mais elle n'est pas partout (et heureusement...)

2) la locale a une granularité trop grande et mélange tout : jeux de
caracyères, langue des messages, formats numériques, etc...

> Ce que tu décris avec wchar est autre chose, mais les
> ayatollahs de l'UTF-8 sont contre car ça permet aux
> codages existants (8-bit ou multibyte) de continuer à
> être supportés, alors qu'il faudrait les éradiquer.

L'éradication me parait un objectif assez utopiste et implique de
toute manière qu'on dispose toujours de convertisseurs
local->unicode en cas de rencontre d'un fichier non encodé dans un
des divers formats unicode. Donc entre le système des locales et ça
mon coeur balance... :)

> Les 2 approches requièrent beaucoup plus de travail que
> tu ne sembles l'imaginer.

C'est très possible, en effet comme tu l'indiques, je ne suis pas
passé de la documentation à la pratique pour l'instant ;)

Mais néanmoins, la libc et gettext gèrent déjà automatiquement
l'encodage en fonction de la locale, si la lib de recherche
d'expressions le gère également, c'est autant de travail en moins
(j'ose espérer que tout le monde ne réécrit pas ses propres routines
de gestion de chaînes dans son coin). L'essentiel du travail me
semble assez simple si la gestion des caractères textuels a été
écrite de façon relativement neutre.

Je vais coder sous peu des trucs en liaison avec tout ça, donc si je
me trompe je ne manquerais pas de te donner raison ;)

la Glibc, pas la libc. Une libc ne devrait conteni_r *que* ce qui est
défini par la norme du C : les jeux de caractère n'ont rien à y faire;
D'ailleurs sit tu veux que ton code soit autre chose qu'une linuxerie
fermée, va falloir y faire gaffe...

--
Erwan

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Le Tue 3/08/2004, Laurent Giroud disait

Effectivement, c'est mieux qu'utiliser les wchar car ceux-ci sont de
taille fixe et donc moins souples et surtout imposent un encodage
unicode alors que conserver des char permet de gérer n'importe quel
type d'encodage supporté par la locale (via la libc). La quantité
de travail est équivalente en revanche.

1)
la gestion des locales ce n'est *pas* le boulot d'une libc. C'est
dans la glibc mais elle n'est pas partout (et heureusement...)

2) la locale a une granularité trop grande et mélange tout : jeux de
caracyères, langue des messages, formats numériques, etc...

> Ce que tu décris avec wchar est autre chose, mais les
> ayatollahs de l'UTF-8 sont contre car ça permet aux
> codages existants (8-bit ou multibyte) de continuer à
> être supportés, alors qu'il faudrait les éradiquer.

L'éradication me parait un objectif assez utopiste et implique de
toute manière qu'on dispose toujours de convertisseurs
local->unicode en cas de rencontre d'un fichier non encodé dans un
des divers formats unicode. Donc entre le système des locales et ça
mon coeur balance... :)

> Les 2 approches requièrent beaucoup plus de travail que
> tu ne sembles l'imaginer.

C'est très possible, en effet comme tu l'indiques, je ne suis pas
passé de la documentation à la pratique pour l'instant ;)

Mais néanmoins, la libc et gettext gèrent déjà automatiquement
l'encodage en fonction de la locale, si la lib de recherche
d'expressions le gère également, c'est autant de travail en moins
(j'ose espérer que tout le monde ne réécrit pas ses propres routines
de gestion de chaînes dans son coin). L'essentiel du travail me
semble assez simple si la gestion des caractères textuels a été
écrite de façon relativement neutre.

Je vais coder sous peu des trucs en liaison avec tout ça, donc si je
me trompe je ne manquerais pas de te donner raison ;)

la Glibc, pas la libc. Une libc ne devrait conteni_r *que* ce qui est
défini par la norme du C : les jeux de caractère n'ont rien à y faire;
D'ailleurs sit tu veux que ton code soit autre chose qu'une linuxerie
fermée, va falloir y faire gaffe...

--
Erwan

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Vincent Lefevre

03/08/2004 à 15:10

On 2004-08-03 13:38:03 +0200, Erwan David wrote:

Sauf qu'on est actuellement obligé de les supporter. Par exemple au
boulot je pourrais passer en tout UTF-8, mais ça foutrais la merde
quand mon code serait compilé sous windows... Il faut donc que les
sources que j'édite (au moins) soient en iso-8859-1.

Ça fout la merde pour ceux qui sont en ASCII ou en EBC-DIC. Pour des
sources C, dans l'idéal, il ne faut utiliser que le jeu de caractères
de base.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Laurent Giroud

03/08/2004 à 15:20

> 2) la locale a une granularité trop grande et mélange tout : jeux de
caracyères, langue des messages, formats numériques, etc...

100% d'accord sur ce point, ça mériterait une refonte.
Le format du clavier, l'encodage des caractères, le format de la date, et la langue de l'interface sont des variables qui n'ont aucun rapport entre elles (sauf peut être les deux dernières et encore) et qui devraient être séparés plus clairement.
(et je passe sur l'absurdité qui consiste à séparer fr et )

la Glibc, pas la libc. Une libc ne devrait conteni_r *que* ce qui est
défini par la norme du C : les jeux de caractère n'ont rien à y faire;
D'ailleurs sit tu veux que ton code soit autre chose qu'une linuxerie
fermée, va falloir y faire gaffe...

Oui, la glibc effectivement, deuxième impair de ma part. Remplacer libc par glibc dans tous mes messages précédents ;)

Laurent

--
Pensez

Vincent Lefevre

03/08/2004 à 15:20

On 2004-08-03 13:47:27 +0200, Laurent Giroud wrote:

La contrainte n'est pas sur les sources, elle est sur l'utilisateur
qui doit sélectionner la locale en fonction du type d'encodage des
fichiers manipulés.

Si c'était comme ça, on ne s'en sortirait pas.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Erwan David

03/08/2004 à 15:40

Le Tue 3/08/2004, Vincent Lefevre disait

On 2004-08-03 13:38:03 +0200, Erwan David wrote:
> Sauf qu'on est actuellement obligé de les supporter. Par exemple au
> boulot je pourrais passer en tout UTF-8, mais ça foutrais la merde
> quand mon code serait compilé sous windows... Il faut donc que les
> sources que j'édite (au moins) soient en iso-8859-1.

Ça fout la merde pour ceux qui sont en ASCII ou en EBC-DIC. Pour des
sources C, dans l'idéal, il ne faut utiliser que le jeu de caractères
de base.

c'est pire pour Java, et malheuresuement mes collègues n'ontpas voulu
accepter "ascii only"....

--
Erwan

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Vincent Lefevre

03/08/2004 à 15:50

On 2004-08-03 14:24:08 +0200, Erwan David wrote:

Le Tue 3/08/2004, Laurent Giroud disait
> Effectivement, c'est mieux qu'utiliser les wchar car ceux-ci sont de
> taille fixe et donc moins souples et surtout imposent un encodage
> unicode alors que conserver des char permet de gérer n'importe quel
> type d'encodage supporté par la locale (via la libc). La quantité
> de travail est équivalente en revanche.

1)
la gestion des locales ce n'est *pas* le boulot d'une libc. C'est
dans la glibc mais elle n'est pas partout (et heureusement...)

Le support des locales fait partie de la bibliothèque C standard.
Après, comment c'est implémenté, ce n'est pas le problème du
développeur.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Re: bash et UTF-8

10 réponses

Veuillez sélectionner un problème