l'UTF-8 sur Usenet-fr

[JL Picard]

Article posté sur fud, fr.soc.culture.[japon|chine] et
fr.comp.normes.unicode. Suivi sur fud, merci de le respecter.


Bonjour à tous,

Près de 80 articles en réponse au message titré "Test Code".. content de
voir que le sujet suscite l'attention.
Je me permet un petit résumé de la discussion, un peu à la manière d'un
message titré [AAD N+1] sur fufe :

Jean-Victor Gruat a signalé un filtrage nouveau sur le serveur de
free : impossible de poster en UTF-8 sur fr.soc.culture.chine et
fr.soc.culture.japon. En effet, les règles en vigueur sur fr.* ne
permettent pas de poster en UTF-8 en dehors de quelques forums de
fr.lettres.langue.*, et François Pétillon (newsmaster chez free.fr) a
décidé de respecter ces règles à la lettre [A].

Ce fût donc l'occasion de rappeler qu'il est bien difficile de parler
de la culture d'une région ou d'un peuple, sans pouvoir utiliser sa
langue et, a fortiori, représenter son écriture.
L'utilisation d'iso-8859-1(5), en vigueur sur fr, est incompatible avec
la représentation des caractères non-latins utilisés dans les parties du
monde en question. L'utilisation de jeux de caractères locaux (GB, BIG5,
JIS, ..) est proscrite, car bien trop difficile à harmoniser, et de
toutes façons incompatible avec un codage correct des particularités de
l'écriture française (lettres accentuées, cédille, ligature, ..).

Une solution semble pointer le bout de son nez : permettre, quand celà
est nécessaire, l'utilisation d'UTF-8 - UTF-8 étant un codage d'Unicode,
offrant la possibilité de coder les caractères latins d'iso-8859-1 et
iso-8859-15, mais aussi les caractères non latins des langues grecque,
arabe, chinoise, japonaise, ...
L'inconvénient d'Unicode est que quelques utilisateurs (dont je fais,
pour le moment, partie) ne peuvent pas le lire, et voient les accents
français remplacés par des é et autres à.

Les articles postés dans fr.* sont, d'après les regles de la hiéarchie,
censés être postés en iso-8859-1 (ou, par défaut en ASCII). Pour
certains groupes, la charte prévoit qu'un autre jeu de caractère comme
l'UTF soit utilisable.

Au passage, j'en profite pour répondre à quelques remarques qui ont

Non, sinon d'un point de vue plus large et en mettant Free à part,
certes, l'iso 8859-1 / 15 est en règles, mais ne serait-il pas temps
d'accepter que l'Unicode puisse être utilisée sur toute la hiérarchie ?

Aucun intéret d'étendre Unicode à toute la hiérarchie pour le moment,
il me semble. Unicode présente un inconvénient : il n'est pas
(complètement) décodable par tout le monde. La grande majorité des
intervenants d'Usenet-fr écrivent en Français uniquement, et se fichent
des avantages apportés par Unicode ; cela me parrait inutile de leur
imposer l'inconvénient donné un peu plus haut.

Pour ce qui est des articles en Français, et ne nécessitant pas d'écrire
des caractères non-latins, Florent Faessel pose la bonne quesiton dans

Et ça apporterait quoi de plus par rapport à l'iso-8859-15 ?

=> rien.

Michel Guillou enfonce le clou dans

l'utilisaient déjà en 97 mais il y avait toujours un dino énervé,
perfide et
rétif à tout progrès pour faire la remarque de l'inutilité des
accents.

Si je puis me permettre, c'est aussi en soit le cas pour l'unicode.

Non, aucun rapport. Fr est francophone, ce qui légitimait l'utilisation
d'une table sur 8 bits. Le français n'a pas besoin d'Unicode.

A propos de l'encodage des caractères :

Justin Pochard, malgré la grande pertinence à laquelle il nous avait

Le codage n'est pas important: c'est que qui est exprimé avec qui doit
primé.

Oui mais non.
Si je veux parler de certains aspects de la culture chinoise, et
illustrer mon propos par quelques exemples, l'iso-8859-1 est parfois
une vraie limitation. Certes, il restera toujours la possibilité de
transcrire en pinyin, mais c'est tout à fait insuffisant pour exprimer
certains concepts.

Je donne un exemple : certains jeux de mots chinois consistent à
utiliser des mots dont les prononciations sont proches (forte ambiguïté),
mais dont l'écriture et le sens sont tout à fait différents.
Une transcription Pinyin montrera deux phrases quasiment identiques, et
rendra la subtilité quasiment impossible à comprendre pour le lecteur.
Là, utiliser un codage adapté représente une vraie valeur ajoutée !

(si vous ne comprennez pas ce que je veux dire, essayez de faire un jeu
de mot français sans utiliser la langue française, pour voir...)

Oui ben ce sera non. Unicode c'est 2 octets par caractère et les
lecteurs actuels ne le supportent pas, tandis que l'ISO-truc est
compatible.

C'est complètement faux. Unicode ne prend pas 2 octets par caractère,
d'une part parce qu'Unicode n'est pas un système de codage mais une
(des) table(s) de caractères, ensuite parceque les caractères ASCII
standards (0-127 dans la table ASCII) sont représentés de la même façon
(donc 1 octet/caractère) et enfin parce que les caractères "exotiques"
peuvent être codés sur plus de 2 octets.

Voir la réponse de Denis Liégeois dans <***@neottia.net>.

En gros, un texte en français comprenant 5% de caractères n'appartenants
pas à la table ASCII standard pèsera 5% de plus. Si cela génait vraiment
qui que ce soit, les signatures seraient limitées à 2 lignes de 40
caractères :-)

Ou alors il est grand temps de mettre son
lecteur de news favori (ou son système d'exploitation) à jour...

Pourquoi faire ?
Première règle de l'utilisateur : quand ça marche, ne toucher à RIEN.

Justement : actuellement, ca ne marche pas, donc il faudrait envisager
de toucher un peu.
Il est admis qu'UTF-8 est une bonne solution pour les forums traitant
des langues ne disposant pas d'un système d'écriture latin.
Ca n'est pas le cas pour les forums ou l'on parle de la culture d'un pays
qui utilise ce même type de systèmes d'écriture.

Pourquoi ?
Pourquoi fllj peut-il accueillir de l'utf-8, et pas fscj ?

J'ai beau retourner la question dans tous les sens, je ne vois aucune
bonne raison.

Répéter à tous les messages
qu'unicode est l'avenir n'en fera pas une vérité pour autant. Vous n'en
savez strictement rien.

Absolument.
Cependant, actuellement, c'est la solution la plus aboutie et efficace.
Je ne vois aucune alternative possible, dans les 2 ou 3 années à venir.
Et vous ?



Pour conclure :

Ne pensez-vous pas que l'on pourrait permettre l'UTF-8 dans les forums
qui en ont vraiment besoin ?

Pensez-vous que l'on puisse arriver à un consensus (et éventuellement à
la rédaction ou la modification d'un document) sur fr.usenet.divers, ou
faudrait-il envisager un passage sur fufe, avec modification de charte à
la clef ?


Merci de vos suggestions et commentaires.

[Lo' (par cybercafe)]

Forum d'origine : fr.usenet.divers "fud" et voir ci-dessous (Asie
orientale) après la ligne
« in message <news:3ff6a3a9$0$28702$***@news.free.fr>... »

[[ Attention, publication "non conforme" puisque non seulement sur "fud",
mais aussi sur le forum concernant Unicode (fr.comp.normes.unicode),
et aussi : sur les forums de /langues/ d'Asie orientale (en tout 4 forums)

-- le suivi est lui aussi "non conforme" car non seulement sur "fud" mais
aussi, vu son contenu, sur fr.comp.normes.unicode
mais vous pouvez librement modifier ce suivi car je ne participe
actuellement pas souvent aux forums, à cause d'un handicap (surtout
visuel) --

J'indique aux personnes "abonnées" aux forums de chinois et de japonais que
ce forum sur Unicode, assez petit, peut (généralement) être obtenu en
cliquant sur ce lien : news:fr.comp.normes.unicode
et pour "fud" ce lien : news:fr.usenet.divers ]]

Post by JL Picard
Article posté sur fud, fr.soc.culture.[japon|chine] et
fr.comp.normes.unicode. Suivi sur fud, merci de le respecter.
(...)
Jean-Victor Gruat a signalé un filtrage nouveau sur le serveur de
free : impossible de poster en UTF-8 sur fr.soc.culture.chine et
fr.soc.culture.japon.(...)
Ne pensez-vous pas que l'on pourrait permettre l'UTF-8 dans les forums
qui en ont vraiment besoin ? (...)

Ma suggestion (conclusion du présent article) :

- Expliquer Unicode au public,

- le plus simplement possible,

- hors d'Internet,

c'est-à-dire par un livre imprimé ou, plus modestement (pour commencer), par
des "lettres de lecteur", voire des articles pour des revues, notamment
d'informatique ou lesdites "revues Internet"

(ou, bein sûr : hors d'Internet /aussi/).

___

Je ne pourrais pas, par cybercafé (avoir le temps de) lire l'intégralité du
fil de discussion situé dans le forum fr.usenet.divers [fil qui a commencé
le 3 janvier et, ce jeudi 29, est encore lisible [téléchargeable] en entier
même avec un serveur relativement "éphémère", je veux dire celui de
Wanadoo].

J'ai lu tous les articles de fin de fils partiels, et ai remarqué une
suggestion de Vincent Ramos (date : le 5 janvier, heure "d'Europe
occidentale") évoquant le forum portant sur Unicode.

Je comprends bien que la question posée porte sur le système de forums
publics (Usenet), cependant

-- comme j'ai, à propos d'Unicode, depuis longtemps, une suggestion, restée
non formulée publiquement, car difficile à réaliser --

je note aussi, par le hasard de mon passage en cybercafé,

une réponse de "Claude" (nom d'auteur en capitales) qui est, les
"sinologues" doivent s'en douter, très qualifié en chinois et traduction ;
c'est peu dire ; veuillez -- j'espère pouvoir vous faire confiance -- ne pas
commenter ce point, peut-être personnel, en forum.

Que dit-il ? « Après avoir lu tout ça, je n'ai rien compris. Faut dire que
je suis nul. » Ce qui pose la question du contact avec les utilisateurs (ou
utilisateurs potentiels) d'Unicode, et par suite celui de sa diffusion, et
finalement de sa facilité d'utilisation (pour donner un exemple : tant
qu'Unicode ne sera pas plus célèbre, il sera difficile de lire des
caractères "asiatiques", et encore plus d'écrire, en cybercafé, puisque
(dans le cas de Windows XP) la "prise en charge" de ces langues nécessite un
cédérom que le/la patron/ne du cybercafé hésite à confier (risque de vol par
client indélicat) et même hésite à permettre cette prise en charge à cause
du risque d'installation ratée, pouvant déstabiliser un poste (ordinateur).

N'oublions pas que les utilisateurs asiatiques eux-mêmes (surtout dans leurs
pays) utilisent bien souvent des systèmes antérieurs à Unicode. Mais peu
importe : il ne s'agit pas de "convertir" Chine ou Japon à Unicode, mais
plus modestement de faciliter des échanges franco-asiatiques (exemple :
permettre aux lycéens puis étudiants de bénéficier d'Unicode, sans que cela
semble trop compliqué ; voir par exemple le "Parisien" (quotidien) de ce
jeudi 29 janvier qui signale les progrès du chinois en France, journal
généralement en lecture publique dans les cafés en Île-de-France.

J'ai, plus d'une fois, recherché en kiosque une revue (francophone) qui
évoquerait Unicode. Je note que même les revues -- généralement des numéros
spéciaux, trimestriels par exemple -- qui disent présenter "les meilleurs
sites", ne prévoient pas de rubrique "Langues", tout au plus les langues
sont-elles citées dans la rubrique "Voyages" ou "Tourisme".

J'ai notamment regardé et même parfois acheté des revues sur le Macintosh
(moi qui connais mieux l'univers des PC que celui des Macintosh), car je
crois bien que les systèmes d'exploitation les plus récents d'Apple sont
parfaitement compatibles avec Unicode. Or, jamais je n'ai vu ce "talent"
cité dans une revues portant sur Macintosh.

Bien au contraire, j'y ai lu une lettre de lecteur (dans "À vos Mac") se
plaignant de la présence de trop nombreux documents ("fichiers") liés à des
langues d'Asie orientale, le coréen notamment. J'ai même vu une réponse d'un
journaliste (toujours dans "À vos Mac", mais il y a au moins un an) qui
confondait, sur une copie d'écran envoyée par un lecteur, le coréen et le
japonais. Pourtant, sans vraiment connaître ces deux langues (et c'est mon
cas), le coréen est assez facilement reconnaissable par la présence, assez
fréquente, de petits cercles dans les caractères. Cette confusion entre deux
langues, de la part d'un journaliste et non d'un simple lecteur, me semble
indiquer un manque d'intérêt (des revues francophones) pour les langues
étrangères (sauf l'anglais).

Étant affecté de troubles psychologiques (et visuels) parfois légers parfois
plus graves, je ne pense pas être en mesure d'écrire moi-même des lettres à
des journaux (il m'arrive de ne pouvoir retrouver timbres ou enveloppes,
quant à Internet il n'est pour l'instant pas question que je l'utilise à
domicile).

En revanche, il existe parmi les participants des forums dans lesquels le
présent message (article) est publié, des personnes passionnées par les
langues et également capables d'expliquer Unicode. Pour l'instant

[pardonnez l'éventuel manque de suite logique mais l'écriture par clavier
m'est devenue difficile et je dois donc abréger],

il existe à ma connaissance en français *un* livre sur Unicode, livre écrit
par un professeur anglais, prénommé Ken, et qui est un exposé complet sur
Unicode.

Encore ne trouve-t-on ce livre que dans les grandes villes (pour moi Paris),
et non en grande surface : en hypermarché, on trouve des "grands livres de
Windows" (hélas pour le Mac on ne trouve même pas une explication du clavier
[touches simples et non uniquement touches de fonction], je "rappelle" que
le clavier Mac est celui des "bornes internet", voir à ce propos
http://www.netanoo.com/ ). Tous ces "grands livres" sont très évasifs sur la
question des langues (notamment des langues d'Asie orientale).
___

Bien qu'il puisse sembler irréaliste de proposer de but en blanc (par cet
article) la rédaction (collective, je suppose) d'un livre, je propose
seulement que chacun[e] d'entre vous (notamment les personnes étudiant
chinois ou japonais, mais aussi d'autres langues non "latines" du point de
vue alphabétique) observe les revues (surtout les revues portant sur
Internet) et n'hésite pas à répondre à tout article portant sur Unicode ou
un sujet apparenté (les langues étrangères hormis l'anglais).

La difficulté est (pour le chinois et le japonais, plus particulièrement) de
donner des exemples très simples de "structure" d'une langue étrangère
réputée hermétique. Il faudrait par exemple écrire « En chinois, le mot qui
signifie "une personne" ou "des gens" est désigné par un caractère en forme
de chapeau pointu ; ce caractère est, dans le système Unicode, identifié par
le numéro [ici le code, de préférence décimal, du caractère chinois usuel
qui se prononce à peu près "gêne"] ». À vous de voir s'il faut "parler" de
la prononciation d'un caractère, car -- surtout dans une lettre de lecteur à
une revue -- votre espace sera limité].

Cependant, des caractères chinois (hors photos de T-shirts, tatouages, etc.)
commencent à apparaître dans des revues non liées à Internet, et ce fut
récemment le cas de la revue "Espace". Si cela (une aide à la diffusion de
langues étrangères auprès du grand public francophone) vous intéresse, je
vous conseille de ne pas oublier de feuilleter les revues pour
préadolescents et jeunes filles (à savoir les revues qui parlent de tubes
musicaux et chanteurs), voire les revues pour enfants. Il y a actuellement
(en France) une revue pour jeunes, bilingue franco-arabe, cependant peu
utilisable sans la présence prolongée d'un parent, car l'arabe qui y est
imprimé ne comporte pas les voyelles ( les "signes vocaliques").

J'arrête [presque] ici mon article car je me sens un peu fatigué (et... ai
froid aux mains ! en cybercafé, porte parfois ouverte aux courants d'air)

et [comme c'est souvent le cas avec Internet : parler d'un autre sujet que
celui que l'on avait prévu] je n'étais pas venu en cybercafé pour ce sujet.
Si possible, ne répondez pas en découpant l'article en petits morceaux (et
notez, surtout, qu'il se peut que je ne réponde pas dans le délai "habituel"
en forum). Prenez votre temps (évitez de répondre par impulsion non
réfléchie) et ainsi peut-être [ce dont je doute parfois] le système des
forums (Usenet) permettra-t-il une construction, une réalisation, qui ne se
limite pas à ses propres utilisateurs.

[Vincent Ramos]

Lo' (par cybercafe) a écrit :


[À propos de la faible représentation des livres et revues traitant,
directement ou non, d'Unicode.]

Je tiens à signaler qu'un ouvrage universitaire, le /Handbook of the
International Phonetic Association/ (Cambridge University Press),
consacre tout un chapitre à l'écriture électronique des caractères
phonétiques avec Unicode, donnant un historique de la chose, les
problèmes soulevés, les solutions, ainsi qu'une série de tables de
concordances entre les glyphes de l'API et les emplacements UCS.

Ce n'est pas rien car cet ouvrage est une référence dans le domaine
de la notation phonétique. D'ailleurs, le site web de l'IPA consacre
une de ses pages à la question, traitée brièvement ; de sorte, dans
le milieu universitaire, les problèmes de codage commencent à être
connus.

[Jean-Marc Desperrier]

[...] de sorte, dans
le milieu universitaire, les problèmes de codage commencent à être
connus.

Ce qui serait bien c'est que les *solutions* de codage soient connus.

Si l'image retirée est que ça marche pas bien, ya plein de trucs
compliqués à faire, le résultat ne risque pas d'être de pousser les gens
vers cette solution.
En fait dans une vulgarisation, ça me rassurerait plus de voir que l'on
parle de l'état de l'art, de comment cela marche, plutôt que de
l'historique et des problèmes qu'il y a pu avoir.

Il est vrai qu'il reste *un* problème significatif, comment accèder aux
caractère qui ne sont pas présent sur un clavier, et là on se retrouve à
être obligé de connaître des valeurs de code, qui ne devrait idéalement
absolument pas concerner ceux qui seront uniquement utilisateur du produit.

Un utilisateur normal ne sait pas que le code ASCII de 'A' est 65, et
celui de 'a' 97, et il n'a *pas* à le savoir.
Les caractères de l'API ne setont vraiment utilisable que si on arrive
au même niveau.

[Erwan David]

Post by Jean-Marc Desperrier

[...] de sorte, dans
le milieu universitaire, les problèmes de codage commencent à être
connus.

Ce qui serait bien c'est que les *solutions* de codage soient connus.
Si l'image retirée est que ça marche pas bien, ya plein de trucs
compliqués à faire, le résultat ne risque pas d'être de pousser les
gens vers cette solution.
En fait dans une vulgarisation, ça me rassurerait plus de voir que
l'on parle de l'état de l'art, de comment cela marche, plutôt que de
l'historique et des problèmes qu'il y a pu avoir.
Il est vrai qu'il reste *un* problème significatif, comment accèder
aux caractère qui ne sont pas présent sur un clavier, et là on se
retrouve à être obligé de connaître des valeurs de code, qui ne
devrait idéalement absolument pas concerner ceux qui seront uniquement
utilisateur du produit.

CÇa c'est complètement se leurrer et se mettre la tête sous le
sable. Il reste plein de programmes qui ne peuvent pas marcher ou qui
marchent en mode très dégradé en utf-8.

[Erwan David]

Post by Jean-Marc Desperrier

[...] de sorte, dans
le milieu universitaire, les problèmes de codage commencent à être
connus.

Ce qui serait bien c'est que les *solutions* de codage soient connus.
Si l'image retirée est que ça marche pas bien, ya plein de trucs
compliqués à faire, le résultat ne risque pas d'être de pousser les
gens vers cette solution.
En fait dans une vulgarisation, ça me rassurerait plus de voir que
l'on parle de l'état de l'art, de comment cela marche, plutôt que de
l'historique et des problèmes qu'il y a pu avoir.
Il est vrai qu'il reste *un* problème significatif, comment accèder
aux caractère qui ne sont pas présent sur un clavier, et là on se
retrouve à être obligé de connaître des valeurs de code, qui ne
devrait idéalement absolument pas concerner ceux qui seront uniquement
utilisateur du produit.

Ça c'est complètement se leurrer et se mettre la tête sous le
sable. Il reste plein de programmes qui ne peuvent pas marcher ou qui
marchent en mode très dégradé en utf-8.

[JL Picard]

Post by Erwan David

Post by Jean-Marc Desperrier
En fait dans une vulgarisation, ça me rassurerait plus de voir que
l'on parle de l'état de l'art, de comment cela marche, plutôt que de
l'historique et des problèmes qu'il y a pu avoir.

[...]
Ça c'est complètement se leurrer et se mettre la tête sous le
sable.

Allons bon, voilà qui va manifestement donner envie à JMD de vous
répondre..

Post by Erwan David
Il reste plein de programmes qui ne peuvent pas marcher ou qui
marchent en mode très dégradé en utf-8.

Tout comme il reste plein de gens qui ne savent pas coder correctement
en C. Ca n'est pas pour ça que l'on fait un historique exhaustif de
l'histoire des langages de programmation, la théorie des langages, une
étude comparative des différents langages disponbles sur le marché, ...
à quelqu'un quand on veut lui apprendre le C.

Un poil d'histoire, c'est bien. Mais se concentrer sur les possibilités
*existantes*, en donnant envie aux gens de s'investir dans la
technologie en question, plutôt que de leur faire peur ou de les
gonfler... et bien je trouve ça mieux.

Faut-il attendre que slrn supporte l'UTF-8 pour en parler ?
On va attendre longtemps !

[Erwan David]

Post by JL Picard

Post by Erwan David

Post by Jean-Marc Desperrier
En fait dans une vulgarisation, ça me rassurerait plus de voir que
l'on parle de l'état de l'art, de comment cela marche, plutôt que de
l'historique et des problèmes qu'il y a pu avoir.

[...]
Ça c'est complètement se leurrer et se mettre la tête sous le
sable.

Allons bon, voilà qui va manifestement donner envie à JMD de vous
répondre..

Post by Erwan David
Il reste plein de programmes qui ne peuvent pas marcher ou qui
marchent en mode très dégradé en utf-8.

Tout comme il reste plein de gens qui ne savent pas coder correctement
en C. Ca n'est pas pour ça que l'on fait un historique exhaustif de
l'histoire des langages de programmation, la théorie des langages, une
étude comparative des différents langages disponbles sur le marché, ...
à quelqu'un quand on veut lui apprendre le C.
Un poil d'histoire, c'est bien. Mais se concentrer sur les possibilités
*existantes*, en donnant envie aux gens de s'investir dans la
technologie en question, plutôt que de leur faire peur ou de les
gonfler... et bien je trouve ça mieux.

Ben justement les possibilités *existantes* c'est que imposer l'UTF-8
revient en général à imposer un ensemble réduit de logiciels, et
rarement les meilleurs.

[JL Picard]

Post by Erwan David
Ben justement les possibilités *existantes* c'est que imposer l'UTF-8
revient en général à imposer un ensemble réduit de logiciels, et
rarement les meilleurs.

Se concentrer sur Unicode/UTF-8 n'empêche absolument pas de comprendre
les mécanismes des autres tables/système d'encodage.
Au contraire.

[Erwan David]

Post by JL Picard

Post by Erwan David
Ben justement les possibilités *existantes* c'est que imposer l'UTF-8
revient en général à imposer un ensemble réduit de logiciels, et
rarement les meilleurs.

Se concentrer sur Unicode/UTF-8 n'empêche absolument pas de comprendre
les mécanismes des autres tables/système d'encodage.
Au contraire.

Mais faire croire que UTF-8 est *la* solution c'est gravement leurrer
ceux à qui on le dit. UTF-8 *sera* peut-être une solution, en est une
dans quelques cadres bien précis et limités, mais n'a piour l'instant
*rien* d'universel.

[JL Picard]

Post by Erwan David

Post by JL Picard
Se concentrer sur Unicode/UTF-8 n'empêche absolument pas de comprendre
les mécanismes des autres tables/système d'encodage.
Au contraire.

Mais faire croire que UTF-8 est *la* solution c'est gravement leurrer
ceux à qui on le dit. UTF-8 *sera* peut-être une solution, en est une
dans quelques cadres bien précis et limités, mais n'a piour l'instant
*rien* d'universel.

UTF-8 est la meilleure solution actuelle pour les problèmes d'encodages
de caractères n'appartenants pas à votre jeu de caractère local.
C'est aussi la meilleure solution actuelle pour l'échange d'information
entre deux systèmes n'utilisant pas, par défaut, les mêmes systèmes
d'écritures.
C'est également la meilleure solution lorsque l'on souhaite mélanger des
caractères appartenant à des jeux différents.

[Jean-Marc Desperrier]

Post by Erwan David
Ça c'est complètement se leurrer et se mettre la tête sous le
sable. Il reste plein de programmes qui ne peuvent pas marcher

Les linux récents sont livrés avec une locale en UTF-8.

Je suis en train de me rendre compte, et ce n'est pas l'option que
j'aurais choisi, mais je commence à croire que c'est effectivement
finalement la meilleure façon de faire, qu'une certain sous-ensemble des
dévelopeurs ne se décident à mettre à jour leurs appli que quand ils
n'ont plus le choix.
Et c'est ce qui est en train de se passer.

En attendant il faudra peut-être utiliser Pine à la place de SLRN :-)

Post by Erwan David
ou qui marchent en mode très dégradé en utf-8.

C'est quoi un mode très dégradé ?
C'est bug dès qu'on sort de l'ASCII pur ?

[Erwan David]

Post by Jean-Marc Desperrier

Post by Erwan David
Ça c'est complètement se leurrer et se mettre la tête sous le
sable. Il reste plein de programmes qui ne peuvent pas marcher

Les linux récents sont livrés avec une locale en UTF-8.

Et ? encore faut-il que les programmes utilisé puisse travailler avec.

Par exemple le shell. Entre utiliser un shell limité en fonctionnalité
mais qui comprends l'UTF-8 et un shell qui a les fonctionalités que je
veux mais ne le comprends pas y'aura pas photo. Et pour l'instant il
n'y a *aucun* shell potable qui soit compatible UTF-8 (non bash n'est
*pas* à mon sens un shell potable).

Post by Jean-Marc Desperrier
Je suis en train de me rendre compte, et ce n'est pas l'option que
j'aurais choisi, mais je commence à croire que c'est effectivement
finalement la meilleure façon de faire, qu'une certain sous-ensemble
des dévelopeurs ne se décident à mettre à jour leurs appli que quand
ils n'ont plus le choix.

Le boulot n'est pas forcément *facile*.

Post by Jean-Marc Desperrier
C'est quoi un mode très dégradé ?
C'est bug dès qu'on sort de l'ASCII pur ?

Non, à partir du moment ou un caractère n'a pas une taille fixe...

Ce qui casse un certain nombre de choses.

[JL Picard]

Post by Erwan David
Par exemple le shell. Entre utiliser un shell limité en fonctionnalité
mais qui comprends l'UTF-8 et un shell qui a les fonctionalités que je
veux mais ne le comprends pas y'aura pas photo.

UTF-8 n'est pas un gadget, C'EST une fonctionnalité.

Post by Erwan David

Post by Jean-Marc Desperrier
C'est bug dès qu'on sort de l'ASCII pur ?

Non, à partir du moment ou un caractère n'a pas une taille fixe...
Ce qui casse un certain nombre de choses.

En quoi l'UTF-8 change la "fixitude" de la taille d'un caractère ?

[Erwan David]

Post by JL Picard
En quoi l'UTF-8 change la "fixitude" de la taille d'un caractère ?

En UTF-8 un caractère fait entre 1 et 6 octets de long...

[Olivier Miakinen]

Post by Erwan David

Post by JL Picard
En quoi l'UTF-8 change la "fixitude" de la taille d'un caractère ?

En UTF-8 un caractère fait entre 1 et 6 octets de long...

Tu voulais donc parler de la taille de l'encodage. Je crois qu'on est au
moins deux à avoir compris que tu parlais de la taille du caractère affiché.

[Erwan David]

Post by Olivier Miakinen

Post by Erwan David

Post by JL Picard
En quoi l'UTF-8 change la "fixitude" de la taille d'un caractère ?

En UTF-8 un caractère fait entre 1 et 6 octets de long...

Tu voulais donc parler de la taille de l'encodage. Je crois qu'on est au
moins deux à avoir compris que tu parlais de la taille du caractère affiché.

Oui je voulais parler de la taille de la donnée en
mémoire. L'affichage n'est pas gênant, par contre pour les
manipulations de données en mémoire, ça fout un bronx pas possible.

[Pablo Saratxaga]

Kaixo!
Li 05 Feb 2004 17:53:49 GMT,
JL Picard <***@public.jeru.orgi.invalid> scrijheut:

JP> En quoi l'UTF-8 change la "fixitude" de la taille d'un caractère ?

Il parle taille en octets, et non pas taille à l'écran.

Un caractère a trois sortes de tailles:
- taille en octets
- taille en colonnes (pour l'affichage en mode espacemment fixe;
valeurs=0,1,2)
- taille phyisque, en pixels (ou mm, etc) que sa representation prendra
à l'écran/sur papier, ça depends de la fonte et du support, tandis que
les deux premières tailles ne dependent que du caractère.

Pendant longtemps, avec l'ascii, on a cru que la taille 1 et la taille 2
c'était la même chose, et on eu comme résultat ces aberrations que sont
strlen() strcp() et compagnie (qui ne travaillent pas, malgré ce que
leur nom laisserait croire, sur des caractères ou des chaînes des
caractères, mais sur des octets).

UTF-8 mets de l'ordre là dendans, en interdissant la grossière
approximation de 1 caractère = 1 colonne = 1 octet (qui n'est valable
que pour une petite fraction des caractères existants)

[Jean-Marc Desperrier]

[...]. Et pour l'instant il
n'y a *aucun* shell potable qui soit compatible UTF-8 (non bash n'est
*pas* à mon sens un shell potable).

C'est quoi un shell potable ?

Et qu'il y a-t-il que bash ne sait pas faire ?
(par opposition à avoir une syntaxe peut-être un peu moins clair que le
shell que tu préfère).

Et puis comment font les japonais (qui utilise depuis des années des
jeux de caractère de longueur variable, plus chiants à gérer que UTF-8)
?

Tu es sur qu'il n'y a pas une version localisée de ton shell qui gère
UTF-8 ?

[Erwan David]

Post by Jean-Marc Desperrier

[...]. Et pour l'instant il
n'y a *aucun* shell potable qui soit compatible UTF-8 (non bash n'est
*pas* à mon sens un shell potable).

C'est quoi un shell potable ?

Un shell qui fait ce que je veux.

Post by Jean-Marc Desperrier
Et qu'il y a-t-il que bash ne sait pas faire ?

expansion récursive, facilités d'historique, etc... Des petites
choses qui deviennent indispensables quand on y a gouté/

Post by Jean-Marc Desperrier
(par opposition à avoir une syntaxe peut-être un peu moins clair que
le shell que tu préfère).
Et puis comment font les japonais (qui utilise depuis des années des
jeux de caractère de longueur variable, plus chiants à gérer que UTF-8)
?

Je ne sais pas.

Post by Jean-Marc Desperrier
Tu es sur qu'il n'y a pas une version localisée de ton shell qui gère
UTF-8 ?

Oui.

[Jean-Marc Desperrier]

Post by Erwan David

Post by Jean-Marc Desperrier
Et qu'il y a-t-il que bash ne sait pas faire ?

expansion récursive, facilités d'historique, etc... Des petites
choses qui deviennent indispensables quand on y a gouté/

Bon laissons tomber le renvoi sur fr.comp.os.unix si tu ne souhaite pas
y discuter.

Dans tout cela, je ne sais pas de quel shell tu parle.

Ni ce que l'on peut reprocher à l'historique de bash.

Post by Erwan David

Post by Jean-Marc Desperrier
Tu es sur qu'il n'y a pas une version localisée de ton shell qui gère
UTF-8 ?

Oui.

Si jamais tu parle de zsh, il y a quand même ceci :
http://www.gufi.org/~gmarco/pepo/pkg.pl?dirname=shells%2Fzsh%2Beuc_hack

C'est pas UTF-8, et c'est pas une solution complète.
Mais c'est un début de quelquechose :-)

[Stephane Chazelas]

Post by Jean-Marc Desperrier

[...]. Et pour l'instant il
n'y a *aucun* shell potable qui soit compatible UTF-8 (non bash n'est
*pas* à mon sens un shell potable).

C'est quoi un shell potable ?

Une fois qu'on a gouté zsh (le shell dont on parle sans le
nommer dans ce thread apparemment), il ne reste malheureusement
pas beaucoup de choix.

Post by Jean-Marc Desperrier
Et qu'il y a-t-il que bash ne sait pas faire ?

C'est vrai qu'un jour, il faudra essayer de poster ici une liste
exhaustive des features qu'apporte zsh par rapport à bash. Ça
risque de faire long. Les principales sont quand-meme sa
completion, son globbing, son editeur de ligne de commande et sa
syntaxe beaucoup plus cohérente et intuitive (après, suivant les
besoins, zsh a plein d'à coté très utiles).

Post by Jean-Marc Desperrier
Et puis comment font les japonais (qui utilise depuis des années des
jeux de caractère de longueur variable, plus chiants à gérer que UTF-8)
?

Plus chiants dans quel sens?

Post by Jean-Marc Desperrier
Tu es sur qu'il n'y a pas une version localisée de ton shell qui gère
UTF-8 ?

UTF-8 est encore sur la TODO list de zsh (le premier des deux
items de la liste), malheureusement.

Sinon, on peut compiler "rc" et "es" avec la libreadline (qui
supporte l'UTF-8, rc et es non par contre). Leur syntaxe est
bien plus cohérente que celle des dérivés du Bourne shell.
Malheureusement, côté fonctionnalités d'utilisation interactive,
on est loin de zsh, même de bash ou tcsh.

Cela dit, ne pas croire que le support UTF-8 de bash ou de
libreadline soit au point.

Essayer:
bind 'é:"foo"'
et taper é (dans une locale UTF8 bien sûr)

bash-2.05b$ a='é'
bash-2.05b$ echo "${#a}"
2

(bon, admettons que ${#a} compte le nombre de bytes, ça semble
d'ailleurs plus utile), mais

$ printf %s "${a#?}" | od -tu1
0000000 169
0000001

(OK, '?' représente un byte) mais alors comment expliquer:

bash-2.05b$ [[ $a = ? ]] && echo "$a contient 1 byte"
é contient 1 byte

Bref, en UTF-8, les notions de byte et character sont encore pas
mal enchevétrées en bash.

en ksh93, ça déconne encore pas mal, mais c'est un poil plus
cohérent (de ce côté-là):

$ a=$(/bin/printf '\u00E9')
$ echo "$a"
é
$ echo "${#a}"
1
$ [[ a = ? ]] && echo yes
yes
$ printf %s "${a#?}" | od -tu1
0000000
$

On peut toujours utiliser zsh dans les locales UTF-8, mais il
faut éviter d'avoir à taper des caractères non-ascii au prompt.

On a pas mal de problèmes aussi avec les noms de fichiers
non-ASCII, et c'est difficilement résoluble comme problème,
quand des fichiers de provenances différentes avec des
conventions de charset differentes s'échangent.

[Jean-Marc Desperrier]

Stephane Chazelas wrote:
[snip zsh]

Post by Stephane Chazelas

Post by Jean-Marc Desperrier
Et puis comment font les japonais (qui utilise depuis des années des
jeux de caractère de longueur variable, plus chiants à gérer que UTF-8)
?

Plus chiants dans quel sens?

Ca c'est en thème sur fcnu. UTF-8 est le meilleur encodage de longueur
variables, surtout par le fait qu'il a quelques propriétés très
appréciables :
- Il est resynchronisable sur le premier octet représentant un début de
caractère. Cad si tu saute des octets au milieu d'un flux UTF-8, et te
retrouve n'importe où, dès que tu verras arriver un octet qui représente
un début de caractère, tu le reconnaitra et pourra afficher correctement.
Tout ce que tu verra avant le premier caractère correct sera identifié
comme invalide et au maximum ce sera 3/5 octets de long.
Ca veut dire en pratique que tu peux réafficher correctement
instantanément.

Les encodages japonais sont eux resynchronisables sur les caractères
ASCII ou sur les retour chariot (retour chariot uniquement pour JIS).

- Toute valeur inférieure à 0x80 présente dans un flux UTF-8 représente
forcément le caractère ASCII correspondant. EUC respecte cela, mais pas
SJIS ou JIS.

- (implique le précédent) Une recherche sur un bloc d'octet représentant
une chaine de caractère en UTF-8 ne peut "matcher" que sur un bloc
d'octet qui représente effectivement cette chaîne.

Ca a pour conséquence qu'une recherche type grep non-compatible UTF-8
marche correctement sur un fichier UTF-8 sans aucune adaptations (hors
expressions régulières).

On voit aussi facilement que ça a pour conséquence moins de travail pour
que les applis s'adaptent à UTF-8, et moins de bugs où on a oublié un cas.

Post by Stephane Chazelas

Post by Jean-Marc Desperrier
Tu es sur qu'il n'y a pas une version localisée de ton shell qui gère
UTF-8 ?

[...]

Post by Stephane Chazelas
Cela dit, ne pas croire que le support UTF-8 de bash ou de
libreadline soit au point.

Utilisable pour les taches de tous les jours, et c'est justement
*uniquement* quand on commence à l'utliser pour des taches de tous les
jours que commence à apparaître le type de problème que tu signale.

On ne peut pas les voir sur des tests à taille réduite, et donc on ne
les corrige jamais. Et donc on arrive *jamais* au stade où c'est
vraiment utilisable.

Post by Stephane Chazelas
bash-2.05b$ echo "${#a}"

[...]

Post by Stephane Chazelas
(bon, admettons que ${#a} compte le nombre de bytes, ça semble
d'ailleurs plus utile), mais

C'est documenté comme étant le nombre de caractère.
J'ai peur que cela soit interprété comme signifiant que le comportement
que tu décris est un bug, alors qu'en pratique il faudrait voir lequel
des deux comportement est le plus utile.

Sachant que quand on gère complètement UTF-8, un "caractère" est une
notion très floue, et qu'il est finalement plus propre d'éviter de s'y
attaquer.
Mieux vaut définir clairement qu'on ne fait pas quelquechose, plutôt que
dire qu'on le fait, et découvrir qu'il y a des cas sans solution.
Même une définition de caractère comme "ce qui va chasser de une
position dans un affichage non-proportionnel" laisse des pièges dans une
langue comme le devanagari.

Post by Stephane Chazelas
$ printf %s "${a#?}" | od -tu1

'?' représente un caractère, sinon c'est plus utilisable.

Oui, comme j'ai dit plus haut, cela va dire qu'il y a des langues, des
cas dans lesquels ça va être difficile.

Post by Stephane Chazelas
bash-2.05b$ [[ $a = ? ]] && echo "$a contient 1 byte"
é contient 1 byte

Celui là est juste, le précédent bogue.
Reste qu'à rentrer un rapport de bug là où il faut.

Post by Stephane Chazelas
Bref, en UTF-8, les notions de byte et character sont encore pas
mal enchevétrées en bash.

Pour simplement définir le bon comportement, il faudra de la réflection.

Le gros problème, c'est les expression régulière, mais cela ne date pas
de UTF-8.

Les expression régulière posent un problème avec les règles de tri même
dans une locale comme fr_FR.ISO-8859-1.

Post by Stephane Chazelas
en ksh93, ça déconne encore pas mal, mais c'est un poil plus
$ [[ a = ? ]] && echo yes
yes
$ printf %s "${a#?}" | od -tu1
0000000

Ce comportement me semble indiquer que '?' /match/ 'a' dans "a = ?",
mais plus dans "${a#?}". Je ne trouve pas cela terrible comme cohérence.

Post by Stephane Chazelas
On a pas mal de problèmes aussi avec les noms de fichiers
non-ASCII, et c'est difficilement résoluble comme problème,
quand des fichiers de provenances différentes avec des
conventions de charset differentes s'échangent.

Là, c'est pas relié à unicode du tout.
C'est le problème de stocker des données dans un encodage local, et de
ne rien avoir qui définit cet encodage local.

Le problème est que les utilisateurs ne voient pas à quel point c'est
une erreur, tant que l'encodage local ne change pas.
Usenet reproduit la même erreur quand on conseille d'envoyer des
en-têtes de message en 8 bits plutôt qu'en encodant.

Mais en regardant le problème, apparemment il y a peut-être des trucs
qui déconnent, au moins dans le cas du kernel Linux, s'il considère
qu'il est faisable de recevoir des trucs du monde user sans savoir dans
quel encodage c'est (en ne connaisant pas LC_CTYPE).

[Stephane Chazelas]

2004-02-06, 18:16(+01), Jean-Marc Desperrier:
[...]

Post by Jean-Marc Desperrier
- Il est resynchronisable sur le premier octet représentant un début de
caractère.

[...]

Post by Jean-Marc Desperrier
Les encodages japonais sont eux resynchronisables sur les caractères
ASCII ou sur les retour chariot (retour chariot uniquement pour JIS).

[...]

Ok, merci pour ces précisions. J'ignorais tout des charsets
Japonais jusque là, je pensais pas qu'on pouvait faire plus
chiant qu'UTF8.

[...]

Post by Jean-Marc Desperrier
Sachant que quand on gère complètement UTF-8, un "caractère" est une
notion très floue, et qu'il est finalement plus propre d'éviter de s'y
attaquer.
Mieux vaut définir clairement qu'on ne fait pas quelquechose, plutôt que
dire qu'on le fait, et découvrir qu'il y a des cas sans solution.
Même une définition de caractère comme "ce qui va chasser de une
position dans un affichage non-proportionnel" laisse des pièges dans une
langue comme le devanagari.

Ou, rien qu'en Français avec les "combining accent".
Que devrait donner
[[ $(printf '\u00E9') = $(printf 'e\u0301') ]] ?

encore une affaire de choix. Je trouve ça pas très malin d'avoir
permit plusieurs représentations possibles d'un même caractère.

Post by Jean-Marc Desperrier

Post by Stephane Chazelas
$ printf %s "${a#?}" | od -tu1

'?' représente un caractère, sinon c'est plus utilisable.

Ben sauf si on veut manipuler des chaines de bytes. Vu ce qu'on
manipule avec des variables en shell en général (des noms de
fichier), on s'en fout de savoir ce que c'est qu'un caractère.
Ce qui importe, c'est les bytes '/' (et '.' à la rigueur si on
veut manipuler des extensions), ce qu'il y a entre, on ne se
pose pas trop la question de savoir ce que ça représente.

(pour l'affichage, ça peut poser des problèmes toutefois. Tiens
d'ailleurs:
bash-2.05b$ printf '<%4s>\n' a é b
< a>
< é>
< b>
encore raté...)

[...]

Post by Jean-Marc Desperrier
Les expression régulière posent un problème avec les règles de tri même
dans une locale comme fr_FR.ISO-8859-1.

Meme en ASCII, si on va par la.

Dans mon dictionnaire d'espagnol, "llorar" est après "luna" (la
lettre (enfin le collating element) "ll" après la lettre "l").

Post by Jean-Marc Desperrier

Post by Stephane Chazelas
en ksh93, ça déconne encore pas mal, mais c'est un poil plus
$ [[ a = ? ]] && echo yes
yes
$ printf %s "${a#?}" | od -tu1
0000000

Ce comportement me semble indiquer que '?' /match/ 'a' dans "a = ?",
mais plus dans "${a#?}". Je ne trouve pas cela terrible comme cohérence.

Si si ${a#?}, ça enlève le premier character de $a. Donc ? a
bien matché "é", puisqu'od indique un output vide.

Post by Jean-Marc Desperrier

Post by Stephane Chazelas
On a pas mal de problèmes aussi avec les noms de fichiers
non-ASCII, et c'est difficilement résoluble comme problème,
quand des fichiers de provenances différentes avec des
conventions de charset differentes s'échangent.

Là, c'est pas relié à unicode du tout.
C'est le problème de stocker des données dans un encodage local, et de
ne rien avoir qui définit cet encodage local.

Tu veux dire qu'il faudrait que les fichiers s'appellents:
/saison/?ISO-8859-1?Q?=E9t=E9?=.txt par exemple ? ou tout autre
moyen de stocker dans le fichier ou son nom le charset utilisé
pour l'écrire ?

[Jean-Marc Desperrier]

Post by Stephane Chazelas

Post by Jean-Marc Desperrier

Post by Stephane Chazelas
On a pas mal de problèmes aussi avec les noms de fichiers
non-ASCII, et c'est difficilement résoluble comme problème,
quand des fichiers de provenances différentes avec des
conventions de charset differentes s'échangent.

Là, c'est pas relié à unicode du tout.
C'est le problème de stocker des données dans un encodage local, et de
ne rien avoir qui définit cet encodage local.

/saison/?ISO-8859-1?Q?=E9t=E9?=.txt par exemple ? ou tout autre
moyen de stocker dans le fichier ou son nom le charset utilisé
pour l'écrire ?

Non, ce n'est pas vraiment ce que je souhaitais dire.
Désolé d'avoir mélangé deux sujets et porté à ce genre d'interprétation.

Sauf évolution récente, un noyau comme celui de linux sur un système de
fichier type ext2 gère les noms de fichiers de façon transparente.
Soit : je reçois des octets que j'écris tel quel, idem dans le sesn
inverse, et je ne sais *rien* sur ce que représente réellement ces données.

Ca ne marche que si au niveau application, on s'assure que le LC_CTYPE
au moment où l'on écrit les données et celui où on les lit est identique.

Donc, il n'y a pas vraiment de bug à corriger dans les noms de fichiers.
C'est plutôt le système qui par construction se lave les mains de gérer
quoi que ce soit concernant les jeux de caractères.

Et si on souhaite que le cas où le jeux de caractère peut changer soit
traité sans que ce soit au niveau applicatif, dans ce cas, il faut
ajouter une couche de service au noyau.
Celui devra savoir dans quel jeu de caractère l'utilisateur lui parle
dans un fopen (donc gérer LC_CTYPE), savoir dans quel jeu de caractère
il doit parler au disque (idéalement en unicode quand même), et savoir
faire la conversion.

Si j'ai bien compris, le Linux actuel avec les options de "mount"
"iocharset", "codepage" ne fait pas mieux ou même fait pire :-)
Avec ces options là, j'ai peux de comprendre qu'il applique des tables
de conversion "à l'aveugle", sans savoir s'il y a vraiment une
correspondance entre le jeux de caractère de l'utilisateur et ce que
disent ces tables ...

[Stephane CHAZELAS]

2004-02-09, 12:10(+01), Jean-Marc Desperrier:
[...]

Post by Jean-Marc Desperrier
Sauf évolution récente, un noyau comme celui de linux sur un système de
fichier type ext2 gère les noms de fichiers de façon transparente.

[...]

Je ne pense pas que ext2 gère quoi que ce soit. Un nom de
fichier reste une séquence de bytes (0x00 et 0x2F mis à part).

[...]

Post by Jean-Marc Desperrier
Si j'ai bien compris, le Linux actuel avec les options de "mount"
"iocharset", "codepage" ne fait pas mieux ou même fait pire :-)

[...]

iocharset, c'est pour monter les systèmes Microsoft qui ont des
noms de fichiers en Unicode.

Toute l'API Unix est basé sur des noms de fichiers représentés
par une chaine de bytes 0 terminated. Donc, ces noms de fichiers
Microsoft avec des non-bytes dedans, il faut bien les faire
correspondre. Mais le fait qu'on puisse choisir un charset me
laisse perplexe, je me demande bien comment ces noms de fichiers
sont gérés sous Windows.

Mettons que j'aie un fichier: 10€.gif (10 euros.gif) stocké sur
un CDROM avec un filesystem Microsoft (donc, avec les caractères
unicode '1', '0', '.', '\u20AC', '.', 'g', 'i', 'f') et que j'ai
aussi un fichier HTML (fichier.html) qui contient « voici un
billet de <img src="[je mets quoi, là?]" alt="10 &euro;"> ».

Une URL est toujours une séquence de bytes. Windows a-t-il un
moyen unifié d'accéder aux fichiers au moyen d'une séquence de
bytes (par exemple, en utilisant que UTF8, src="10%e2%82%ac.gif"
alors, serait toujours correct sur mon exemple, mais en ce cas,
le iocharset de linux ne fait aucun sens, ça devrait toujours
être iocharset=utf-8, sans quoi le lien de ma page HTML ne
marcherait pas) ?

Windows a-t-il aussi une API où on accède au fichier au moyen
d'autre chose qu'une chaine de bytes ?

Je viens de faire des tests avec mkisofs.

Je crée une image de CD avec 10€.gif. Je vois bien:
00 31 00 30 20 AC 00 2E 00 67 00 69 00 66
1 0 € . g i f
(de l'Unicode sur 16 bits).

$ sudo mount -v -t iso9660 -o ro,loop,joliet ./a.iso /mnt
mount: on se prépare à utiliser le périphérique de type loop /dev/loop0
/home/ftp/mp3/install/a.iso on /mnt type iso9660 (ro,loop=/dev/loop0,joliet)
$ ls /mnt | od -tx1
0000000 31 30 3f 2e 74 78 74 0a
0000010
$ lsmod | grep nls
nls_iso8859-1 2812 1 (autoclean)

(2e, c'est '?'. C'est monté en latin1 par défaut! Donc, mon lien
ne marche pas).

$ sudo umount /mnt
$ sudo mount -v -t iso9660 -o ro,loop,utf8,joliet ./a.iso /mnt
mount: on se prépare à utiliser le périphérique de type loop /dev/loop0
/home/ftp/mp3/install/a.iso on /mnt type iso9660 (ro,loop=/dev/loop0,utf8,joliet)
$ ls /mnt | od -tx1
0000000 31 30 e2 82 ac 2e 74 78 74 0a
0000012

Là, c'est OK pour mon lien en UTF-8.

[Pablo Saratxaga]

Dins l' messaedje fr.comp.normes.unicode,
Stephane CHAZELAS <***@free.fr> scrijheut:

SC> Une URL est toujours une séquence de bytes. Windows a-t-il un
SC> moyen unifié d'accéder aux fichiers au moyen d'une séquence de
SC> bytes

ben oui, la sequence d'octets correspondant au nom en UTF-16 :)

l'avantage est de pouvoir acceder au nom du fichier via
une locale non-unicode, et d'avoir le même nom visible, au lieu de n'y
voir qu'une sequence icomprehensible.
(bon, je ne sais pas comment ça gère le cas où un caractère n'est pas
codé dans le jeu de caractère non-unicode mais present dans le nom)

Si on n'utilise jamais qu'un seul et unique encodage, partout et
toujours, ça n'a aucun interêt; mais ce n'est pas le cas, on
est en pleine phase de transition, et dans ce cas un tel système est
très interessant.
notamment sous windows les anciens programmes (win16) ne geraient pas du
tout unicode, et utilisaient une api totalement differente; pour que les
nouveaux programmes, utilisant unicode, et les anciens, ne l'utilisant
pas, manipulent le même nom de fichier (le "même" au niveau de ce que
l'utilisateur voit, non pas dans la suite d'octets).

Sous GNU/Linux c'est l'inverse: on manipule la même suite d'octets
quitte à avoir des representations visuelles differentes.
Enfin, pas tout à fait, très tôt le besoin de convertir vers l'encodage
locale lorsqu'on monte des partitions avec des noms de fichiers d'un
autre encodage s'est faite sentir, d'où le iocharset de la commande
mount.

L'avantage de savoir l'encodage utilisé par le système de fichiers (soit
un encodage fixé (cad de vfat), soit l'encodage indiqué dans une
méta-donnée du fs) c'est qu'on peut choisir le filtre de conversion à
appliquer.
Car pour choisir un tel filtre il faut savoir à quoi on veut arriver
(ça, on le sait, puisque c'est ce qu'on veut :) ), mais aussi, d'où on
vient; et là s'il n'y a pas cette info dans le fs, on ne le sait pas...
on peut essayer de deviner, de supposer,... mais le résultat n'est pas
garanti; alors que pour un fs vfat je SAIS qu'il est en unicode, donc je
peux toujours arriver au résutat voulu, en aveugle.

SC> Windows a-t-il aussi une API où on accède au fichier au moyen
SC> d'autre chose qu'une chaine de bytes ?

oui, les anciennes api.

SC> $ sudo mount -v -t iso9660 -o ro,loop,utf8,joliet ./a.iso /mnt

SC> Là, c'est OK pour mon lien en UTF-8.

Oui; la seule solution à tous ces casse têtes c'est de tout passer en
UTF-8. Et tout deviens soudain plus simple.

[Stephane Chazelas]

Post by Pablo Saratxaga
Dins l' messaedje fr.comp.normes.unicode,
SC> Une URL est toujours une séquence de bytes. Windows a-t-il un
SC> moyen unifié d'accéder aux fichiers au moyen d'une séquence de
SC> bytes
ben oui, la sequence d'octets correspondant au nom en UTF-16 :)

Little Endian, big Endian ? (10€.gif == 00 31 00 30 20 ac 00 2e
00 67 00 69 00 66 ?)

Pour en revenir au cas de mon lien HTML. Pour qu'il soit valide
sur un CD monté sur un système Microsoft, il faut donc que je
mette:

<img src="%001%000%20%AC.gif"> ? Ça me semble peut plausible.

Post by Pablo Saratxaga
l'avantage est de pouvoir acceder au nom du fichier via
une locale non-unicode, et d'avoir le même nom visible, au lieu de n'y
voir qu'une sequence icomprehensible.
(bon, je ne sais pas comment ça gère le cas où un caractère n'est pas
codé dans le jeu de caractère non-unicode mais present dans le nom)

Pas sûr de comprendre pas la phrase.

Ça veut dire que sous Windows, si le système est dans une locale
iso-8859-15, je peux accéder à mon fichier 10€.gif par 10%A4.gif
et si c'est iso-8859-1, je peux pas y accéder ? Donc ma page
HTML qui se trouve sur mon CD-ROM ne marchera que sur les
systèmes qui ont l'encodage que j'ai choisi pour écrire le lien ?

[...]

Post by Pablo Saratxaga
SC> $ sudo mount -v -t iso9660 -o ro,loop,utf8,joliet ./a.iso /mnt
SC> Là, c'est OK pour mon lien en UTF-8.
Oui; la seule solution à tous ces casse têtes c'est de tout passer en
UTF-8. Et tout deviens soudain plus simple.

Mais, est-ce que mon lien sera valide si mon CDROM est monté sur
un système Microsoft ?

[Jean-Marc Desperrier]

[...]>

Post by Stephane Chazelas
Little Endian, big Endian ? (10€.gif == 00 31 00 30 20 ac 00 2e
00 67 00 69 00 66 ?)

Toujours du LE sous windows.

Post by Stephane Chazelas
Pour en revenir au cas de mon lien HTML. Pour qu'il soit valide
sur un CD monté sur un système Microsoft, il faut donc que je
<img src="%001%000%20%AC.gif"> ? Ça me semble peut plausible.

Les interfaces d'ouverture de fichier attendent une chaîne de caractère
dans un jeux de caractère donné, et c'est elle qui feront la conversion
pour y accéder correctement.

Dans le cas assez spécifique du fichier HTML, quand il est interprété,
le browser doit savoir dans quel jeu de caractère il est, et c'est à lui
de convertir vers le jeux de caractère ad-hoc pour ouvrir le fichier.

Même sous Unix d'ailleurs, sur la couche application qui interprète le
HTML avant de la passer à fopen, ça doit marcher de manière similaire.

Si tu as un HTML en ISO-8859-2 avec un lien qui utilise un caractère
accentué, ton bvrowser est censé convertir la chaîne représentant le nom
vers LC_CTYPE (donc disons ISO-8859-1) avant d'essayer de l'ouvrir avec
fopen.
Si tu changer le LC_CTYPE avant de lancer l'appli, tu devrais obtenir
des résultats intéressants. A tester de manière plus complète.

Post by Stephane Chazelas
Ça veut dire que sous Windows, si le système est dans une locale
iso-8859-15, je peux accéder à mon fichier 10€.gif par 10%A4.gif
et si c'est iso-8859-1, je peux pas y accéder ?

Ce cas là ne pourra pas bloquer, car Windows ne connait ni iso-8859-15,
ni iso-8859-1 comme locale, seulement windows-1252 qui contient tous les
caractères de l'un et de l'autre.

Post by Stephane Chazelas
Donc ma page
HTML qui se trouve sur mon CD-ROM ne marchera que sur les
systèmes qui ont l'encodage que j'ai choisi pour écrire le lien ?

Tu peux effectivement arriver à des situations bloquantes dans certain
cas, quand tu mélanges des encodages vraiment incompatibles, genre
japonais-européen, ou russe-européen, si tu essaie d'ouvrir les fichiers
avec une appli qui utilise la version ANSI des fonctions de gestion de
fichier. A tester pour voir aussi.

Sur un système de fichier qui stocke les noms en ANSI, les noms sont
réinterprété en ANSI sur l'autre système, et comme dans le cas de
cp-1252, aucun caractère n'est illégal, on a n'importe quoi, mais on
peut ouvrir quand même.

Par exemple, ton CD-ROM aura le nom long en Joliet (tu es bloqué), mais
aussi un nom court en ISO-9660, sans indication de jeux de caractère,
donc en t'arrangeant pour spécifier le nom court, tu peux l'ouvrir.

[Stephane CHAZELAS]

2004-02-10, 11:20(+01), Jean-Marc Desperrier:
[...]

Post by Jean-Marc Desperrier
Dans le cas assez spécifique du fichier HTML, quand il est interprété,
le browser doit savoir dans quel jeu de caractère il est, et c'est à lui
de convertir vers le jeux de caractère ad-hoc pour ouvrir le fichier.
Même sous Unix d'ailleurs, sur la couche application qui interprète le
HTML avant de la passer à fopen, ça doit marcher de manière similaire.
Si tu as un HTML en ISO-8859-2 avec un lien qui utilise un caractère
accentué, ton bvrowser est censé convertir la chaîne représentant le nom
vers LC_CTYPE (donc disons ISO-8859-1) avant d'essayer de l'ouvrir avec
fopen.
Si tu changer le LC_CTYPE avant de lancer l'appli, tu devrais obtenir
des résultats intéressants. A tester de manière plus complète.

[...]

Les URL dans une page HTML n'ont en principe rien à voir avec
le charset de la page; le chemin, dans une URL est une sequence
de bytes. En principe, seul certains caractères ASCII sont
autorisés dans une URL, les autres sont censés etre encodés sous
la forme de %HH. Ça ne ferait pas de sens que le charset de la
page influe sur la representation du nom du fichier, vu que le
charset du nom du fichier va dépendre du charset sur le systeme
de fichiers sur la machine correspondante, pas de la page HTML en
cours. Par exemple, on peut très bien envisager 3 liens dans une
page HTML en UTF8 vers trois fichiers, un sur un systeme grec,
un sur une system japonais, et un sur un system russe. Le
&euro; sera different sur les trois (il faut trois requetes
HTTP differentes pour demander un fichier /10€.html sur ces
trois serveurs HTTP).

Dans une page HTML, je mets:

href="10%A4.html"
href="10%E2%82%AC.html"
(10 euros en 8859-15 ou UTF8)

Qui sera traduit par le browser en une requete HTTP
GET /path/to/10%A4.html HTTP/1.0
GET /path/to/10%E2%82%AC.html HTTP/1.0

Les problemes qu'il peut y avoir, c'est au niveau de l'affichage
du chemin du fichier pour l'utilisateur, mais au niveau HTTP, on
reste au niveau de chaines de bytes.

[...]

Post by Jean-Marc Desperrier
Par exemple, ton CD-ROM aura le nom long en Joliet (tu es bloqué), mais
aussi un nom court en ISO-9660, sans indication de jeux de caractère,
donc en t'arrangeant pour spécifier le nom court, tu peux l'ouvrir.

OK, où est l'interet d'un nom en UTF-16 alors? Ça en fait une
information non-echangeable (si je download le fichier, je perds
le nom long).

Et, de ce que j'ai cru comprendre, ça ne marchera pas pour NTFS.

[Sylvain Collange]

Bonjour,

Post by Stephane Chazelas

Post by Pablo Saratxaga
Dins l' messaedje fr.comp.normes.unicode,
SC> Une URL est toujours une séquence de bytes. Windows a-t-il un
SC> moyen unifié d'accéder aux fichiers au moyen d'une séquence de
SC> bytes
ben oui, la sequence d'octets correspondant au nom en UTF-16 :)

Je dirais plutôt que non : sous Windows NT on accède toujours au fichier
en UTF-16LE, puis le système s'occupe de l'éventuelle conversion vers le
codage utilisé par le système de fichiers (UTF-16BE, Windows1252, ...).

Plus exactement il y a deux manières d'accéder aux fichiers :
1- avec les fonctions de Windows NT, en UTF-16
2- avec les fonctions de rétrocompatibilité avec les programmes ne
gèrant pas Unicode : ces fonctions se basent sur la locale en cours pour
convertir le nom en UTF-16 et appeler la fonction 1 correspondante.

Post by Stephane Chazelas
Pour en revenir au cas de mon lien HTML. Pour qu'il soit valide
sur un CD monté sur un système Microsoft, il faut donc que je
<img src="%001%000%20%AC.gif"> ? Ça me semble peut plausible.

J'imagine que ça ouvrira le fichier '10 ¬.gif' si la page est en
ISO-8859-1 (%00 ignorés)
Pour une page en UTF-16 BE, ça a une chance de marcher.

Post by Stephane Chazelas
[...]
Ça veut dire que sous Windows, si le système est dans une locale
iso-8859-15, je peux accéder à mon fichier 10€.gif par 10%A4.gif
et si c'est iso-8859-1, je peux pas y accéder ? Donc ma page
HTML qui se trouve sur mon CD-ROM ne marchera que sur les
systèmes qui ont l'encodage que j'ai choisi pour écrire le lien ?

En effet. De même si le navigateur n'est pas compatible Unicode (au sens
Windows).

Post by Stephane Chazelas

Post by Pablo Saratxaga
Oui; la seule solution à tous ces casse têtes c'est de tout passer en
UTF-8. Et tout deviens soudain plus simple.

Mais, est-ce que mon lien sera valide si mon CDROM est monté sur
un système Microsoft ?

Tant que la page HTML aussi est en UTF-8, oui.

[Suivi sur fr.comp.normes.unicode]

--
Sylvain Collange

[Pablo Saratxaga]

Dins l' messaedje fr.comp.normes.unicode,

Post by Pablo Saratxaga
SC> Une URL est toujours une séquence de bytes. Windows a-t-il un
SC> moyen unifié d'accéder aux fichiers au moyen d'une séquence de
SC> bytes
ben oui, la sequence d'octets correspondant au nom en UTF-16 :)

SC> Little Endian, big Endian ? (10¤.gif == 00 31 00 30 20 ac 00 2e
SC> 00 67 00 69 00 66 ?)

Comme j'oublie toujours lequel des deux c'est j'ai préféré éviter
soigneusement d'en parler.
Un des deux.

SC> Pour en revenir au cas de mon lien HTML. Pour qu'il soit valide
SC> sur un CD monté sur un système Microsoft, il faut donc que je
SC> mette:

SC> <img src="%001%000%20%AC.gif"> ? Ça me semble peut plausible.

ça depends en fait du navigateur.
MS-IE semble tout re-convertir en UTF-8, même quand ce ne l'est pas
dans la page html (c'est ce que me disaient mes logs, quand j'avais des
liens en iso-8859-1, dans une page html annoncée comme iso-8859-1,
MS-IE s'obstinait à demander en UTF-8 (avec les octets en pourcents là)
et bien sûr ça ratait.

En tout cas, MS-IE fait ça lorsqu'il demande à un serveur web; pour un
lien local, il doit passer par l'api windows, autremment dit c'est
opaque, et on devrait pouvoir coder le nom dans n'importe quel encodage
indiqué dans le ficheir html et ça devrait marcher.
Si le nom est côdé en octets-pourcents, je ne sais pas ce que fait
windows (je ne connais pas et ne m'en porte pas plus mal), mais il me
semblerait logique qu'il n'y aie pas de conversion dans ce cas...

quelqu'un avec un windows sous la main pourraît essayer, ce serait
interessant.

Post by Pablo Saratxaga
(bon, je ne sais pas comment ça gère le cas où un caractère n'est pas
codé dans le jeu de caractère non-unicode mais present dans le nom)

SC> Ça veut dire que sous Windows, si le système est dans une locale
SC> iso-8859-15, je peux accéder à mon fichier 10¤.gif par 10%A4.gif
SC> et si c'est iso-8859-1, je peux pas y accéder ?

On pourra sans dotue y acceder, mais je ne sais pas comment celà est
presenté. (en passant, je n'ai jamais vu de locale iso-8859-* sous
windows)

SC> Donc ma page
SC> HTML qui se trouve sur mon CD-ROM ne marchera que sur les
SC> systèmes qui ont l'encodage que j'ai choisi pour écrire le lien ?

cela dependra du navigareur aussi il me semble.
en l'etat il vaut mieux éviter en effet; ça ne marchera pas partout.
Quand utf-8 sera la norme alors ça marchera partout.
note que même en ascii ça ne marche pas partout; sous windows
tu peux avoir un fichier "Toto.GIF" et le referencer par "toto.gif" et
ça marchera; pas sous Unix; et je ne parle même pas des "\" (tu n'as
jamais été sur une page web où aucun lien et aucune image ne fonctionne
parcequ'ils utilisent tous des "\" alors que le serveur (un Unix
inmanquablement) utilise "/". (je suppose que MS-IE en cas d'échec
re-essaye avec des "/", je ne peux pas croire qu'il y aie tellement
de gens qui laissent continuellement leurs pages non fonctionnelles)

Post by Pablo Saratxaga
SC> Là, c'est OK pour mon lien en UTF-8.
Oui; la seule solution à tous ces casse têtes c'est de tout passer en
UTF-8. Et tout deviens soudain plus simple.

SC> Mais, est-ce que mon lien sera valide si mon CDROM est monté sur
SC> un système Microsoft ?

Il faudrait essayer.
Mais je dirais à priori oui.

SC> --
SC> Stéphane ["Stephane.Chazelas" arobase "free.fr"]

[Jean-Marc Desperrier]

Post by Pablo Saratxaga
MS-IE semble tout re-convertir en UTF-8, même quand ce ne l'est pas
dans la page html (c'est ce que me disaient mes logs, quand j'avais des
liens en iso-8859-1, dans une page html annoncée comme iso-8859-1,
MS-IE s'obstinait à demander en UTF-8 (avec les octets en pourcents là)
et bien sûr ça ratait.
En tout cas, MS-IE fait ça lorsqu'il demande à un serveur web; pour un
lien local, il doit passer par l'api windows, autremment dit c'est
opaque, et on devrait pouvoir coder le nom dans n'importe quel encodage
indiqué dans le ficheir html et ça devrait marcher.
Si le nom est côdé en octets-pourcents, je ne sais pas ce que fait
windows (je ne connais pas et ne m'en porte pas plus mal), mais il me
semblerait logique qu'il n'y aie pas de conversion dans ce cas...

cf RFC ad-hoc, j'ai oublié le numéro mais c'est sur la représentation
des url, qui recommende de coder les url en UTF-8 quand on fait une
requête à un serveur web. Et il y a une option dans IE pour savoir si on
le fait ou pas.

Les navigateurs tentent aussi d'envoyer les octets de la requête en
brut, mais c'est pour la compatibilité ascendante ...

[Stephane CHAZELAS]

2004-02-10, 18:46(-00), Pablo Saratxaga:
[...]

Post by Pablo Saratxaga
MS-IE semble tout re-convertir en UTF-8, même quand ce ne l'est pas
dans la page html (c'est ce que me disaient mes logs, quand j'avais des
liens en iso-8859-1, dans une page html annoncée comme iso-8859-1,
MS-IE s'obstinait à demander en UTF-8 (avec les octets en pourcents là)
et bien sûr ça ratait.

[...]

Il n'a ni raison, ni tord, ça ne doit pas être spécifié de
toutes les façons. Une URL ne devrait pas contenir de caractères
non-ASCII.

C'est le drame du Web, il a été pourri par les comportements
permissifs de netscape puis IE. Si pour chaque truc non
spécifiés, une erreur était reportée par tous les navigateurs,
on aurait un Web beaucoup plus propre. Au lieu de ça, les 3/4
des sites aujourd'hui ne sont visibles correctement qu'avec
mozilla ou IE, parce qu'ils s'appuient sur des comportements non
spécifiés de ces navigateurs (ça a commencé très tot avec
netscape qui se servait de ça pour emprisonner ses utilisateurs,
pour une fois, ce n'est pas Microsoft qui a donné le mauvais
exemple).

[...]

Post by Pablo Saratxaga
SC> Ça veut dire que sous Windows, si le système est dans une locale
SC> iso-8859-15, je peux accéder à mon fichier 10€.gif par 10%A4.gif
SC> et si c'est iso-8859-1, je peux pas y accéder ?
On pourra sans dotue y acceder, mais je ne sais pas comment celà est
presenté. (en passant, je n'ai jamais vu de locale iso-8859-* sous
windows)

De ce que j'ai lu dans ce thread, apparemment (sauf à utiliser
le nom court pour joliet ou vfat), on ne peut pas acceder à un
fichier dont le nom contient un caractère Unicode qui n'a pas de
correspondance dans la codepage du systeme par l'API non
Unicode.

[Antoine Leca]

Post by Stephane CHAZELAS
De ce que j'ai lu dans ce thread, apparemment (sauf à utiliser
le nom court pour joliet ou vfat), on ne peut pas acceder à un
fichier dont le nom contient un caractère Unicode qui n'a pas de
correspondance dans la codepage du systeme par l'API non
Unicode.

Oui.
Et encore, même avec le nom court, il y a des cas où cela ne passe pas: si
le caractère original (disons, un à) a été encodé (en À sur un VFAT cp850)
dans un caractère qui n'existe pas dans la page de codes système actuelle
(qui serait évidemment VFAT cp437!)

Ce problème existe depuis longtemps avec DOS (3.3+), et est surtout gênant
quand on échange des fichiers entre des personnes n'utilisant pas l'alphabet
latin et d'autres qui l'utilisent. C'est similaire conceptuellement au
problème que l'on pourrait avoir pour accéder à un fichier dont le nom
contient \x2F ou \0 sous Unix (et c'est beaucoup plus gênant dans la
pratique, évidemment).


Antoine

[Antoine Leca]

Bona vesperada,

Stephane Chazelas va escriure: > Ça veut dire que sous Windows, si le
système est dans une locale

Post by Pablo Saratxaga
iso-8859-15, je peux accéder à mon fichier 10¤.gif par 10%A4.gif
et si c'est iso-8859-1, je peux pas y accéder ?

Exact.
En fait, cela m'est arrivé des milliers de fois: j'avais des disques
encodés avec DOS, en utilisant des caractères qui n'existait pas sous
Windows (3.x): résultat, impossible de les utiliser depuis Windows.
Je m'en suis même servi comme moyen de protection!

Post by Pablo Saratxaga
Donc ma page
HTML qui se trouve sur mon CD-ROM ne marchera que sur les
systèmes qui ont l'encodage que j'ai choisi pour écrire le lien ?

Oui; ça, c'est pas nouveau: on recommande d'utiliser toujours le
plus petit commun dénominateur pour les données persistantes...

Post by Pablo Saratxaga
Mais, est-ce que mon lien sera valide si mon CDROM est monté sur
un système Microsoft ?

Oui.
C'est toujours cela, non? ;-)


Antoine

[Jean-Marc Desperrier]

Post by Stephane CHAZELAS
[...]

Post by Jean-Marc Desperrier
Sauf évolution récente, un noyau comme celui de linux sur un système de
fichier type ext2 gère les noms de fichiers de façon transparente.

[...]
Je ne pense pas que ext2 gère quoi que ce soit. Un nom de
fichier reste une séquence de bytes (0x00 et 0x2F mis à part).

Oui, mais j'ai trouvé des traces de discussion pour améliorer cela.
Et je serais surpris que Solaris ne soit pas un peu plus propre.

Post by Stephane CHAZELAS
[...]

Post by Jean-Marc Desperrier
Si j'ai bien compris, le Linux actuel avec les options de "mount"
"iocharset", "codepage" ne fait pas mieux ou même fait pire :-)

[...]
iocharset, c'est pour monter les systèmes Microsoft qui ont des
noms de fichiers en Unicode.
[...]. Mais le fait qu'on puisse choisir un charset me
laisse perplexe, je me demande bien comment ces noms de fichiers
sont gérés sous Windows.

En vfat, ils sont stockés dans la page de code du système (appelé ANSI)
pour les noms court, et en unicode pour les noms longs.

En NTFS, ils sont stockés uniquement en unicode.

Post by Stephane CHAZELAS
[...]
Windows a-t-il aussi une API où on accède au fichier au moyen
d'autre chose qu'une chaine de bytes ?

J'ai coupé tout le reste car en fait c'est cela ta question.

La réponse est que Windows n'a *pas* d'API permettant d'accéder au
fichier au moyen d'une chaîne de bytes.

Windows a deux API, l'une sur laquelle sont d'ailleurs dirigées les
fonctions d'ouverture de fichier type libc, qui interprète le nom comme
étant dans le jeux de caractère ANSI sélectionné pour le sytème et
l'autre dans laquelle les noms sont en unicode UTF16LE.

Il y a même en fait quand l'appli est de type console une possibilité de
choisir dans le premier cas que l'interface interprète en ANSI ou bien
en OEM le jeux de caratère propriétaire d'IBM (cp437/cp850).

Et à chaque fois, la conversion est faite à l'intérieur du système pour
parler au système de fichier correctement.

[Jean-Marc Desperrier]

Post by Jean-Marc Desperrier
[...]
En NTFS, ils sont stockés uniquement en unicode.

Je ne suis pas 100% sur qu'il ne traîne pas un nom court en ANSI aussi.

[Stephane CHAZELAS]

Post by Jean-Marc Desperrier

Post by Stephane CHAZELAS
[...]

Post by Jean-Marc Desperrier
Sauf évolution récente, un noyau comme celui de linux sur un système de
fichier type ext2 gère les noms de fichiers de façon transparente.

[...]
Je ne pense pas que ext2 gère quoi que ce soit. Un nom de
fichier reste une séquence de bytes (0x00 et 0x2F mis à part).

Oui, mais j'ai trouvé des traces de discussion pour améliorer cela.
Et je serais surpris que Solaris ne soit pas un peu plus propre.

Ca ne fait pas de sens. Soit c'est different, soit c'est moins
propre. L'API POSIX (et à peu près tous les protocoles internet
et d'interoperabilité) supporte uniquement des chaines de bytes
zero-terminated pour les noms de fichiers.

Les systèmes peuvent utiliser internalement ce qu'ils veulent
pour stocker le nom du fichier, mais ils doivent pouvoir etre
accessibles au travers d'un nom sous forme de chaine de bytes.

[...]

Post by Jean-Marc Desperrier
En vfat, ils sont stockés dans la page de code du système (appelé ANSI)
pour les noms court, et en unicode pour les noms longs.

Quel nonsense !

Post by Jean-Marc Desperrier
En NTFS, ils sont stockés uniquement en unicode.

En UTF-16BE (et non LE comme dit ailleurs) pour etre precis. Je
ne vois pas trop l'interet d'UTF-16 par rapport à UTF-8, si ce
n'est pour nuire à l'interoperabilité.

[...]

Post by Jean-Marc Desperrier
La réponse est que Windows n'a *pas* d'API permettant d'accéder au
fichier au moyen d'une chaîne de bytes.
Windows a deux API, l'une sur laquelle sont d'ailleurs dirigées les
fonctions d'ouverture de fichier type libc, qui interprète le nom comme
étant dans le jeux de caractère ANSI sélectionné pour le sytème et
l'autre dans laquelle les noms sont en unicode UTF16LE.
Il y a même en fait quand l'appli est de type console une possibilité de
choisir dans le premier cas que l'interface interprète en ANSI ou bien
en OEM le jeux de caratère propriétaire d'IBM (cp437/cp850).
Et à chaque fois, la conversion est faite à l'intérieur du système pour
parler au système de fichier correctement.

Quelle merveille.

[Antoine Leca]

Bona vesperada,

Post by Stephane CHAZELAS
Toute l'API Unix est basé sur des noms de fichiers représentés
par une chaine de bytes 0 terminated.

Joie. Donc, la signification du nom du fichier dépend du jeu de
caractères en cours, qui lui-même dépend (pour faire général):
a) de la configuration actuelle (pour le processus) de LANG
LC_CTYPE et LC_ALL;
b) du bon vouloir placer un ordre setlocale() au début de l'image
en cours d'exécution; sinon, c'est utilisation d'un autre locale,
avec une sémantique différente.

Bon, je me moques. Mais si tu essayes de lire un CD gravé il y a
quelques années, avec (au hasard) les noms de tes chansons MP3 en
format iso-8859-1, en étant avec un locale fr_ES.utf8, tu vas
comprendre, et même toucher du doigt, les problèmes des
Microsoftiens...

Post by Stephane CHAZELAS
Donc, ces noms de fichiers
Microsoft avec des non-bytes dedans, il faut bien les faire
correspondre. Mais le fait qu'on puisse choisir un charset me
laisse perplexe, je me demande bien comment ces noms de fichiers
sont gérés sous Windows.

Tu as demandé!

C'est différent avec NT et avec 9X. Et en plus cela dépend du FS.
Avec NT: tout est géré en Unicode (UTF-16) interne, donc le nom
Unicode (quand il existe, cf.infra) est utilisé d'un bout à
l'autre, il n'y a jamais de problème;
Avec 9X: en interne on utilise le DOS, donc le codage base 8bits
avec les codepages (le fameux OEM); le noyau Windows (VMM) quant
à lui utilise un autre codage, lui aussi 87 bits, appelé Ansi;
donc le système n'arrête pas de manipuler des transcodages, c'est
le souk; c'est une des raisons qui font que Win9X est un animal
en état de mort cérébrale, uniquement maintenu en survie parce
que l'on ne peut pas faire autrement ;-)

Dépendance des FS, et raison d'être de iocharset: les anciens
systèmes de fichiers (avant VFAT et NTFS) n'avait pas Unicode,
même problème en fait qu'avec Unix: donc il est nécessaire
d'indiquer comment faire pour lire les noms de fichiers; la
différence, c'est qu'il n'y a pas de choix laissé à l'utilisateur
(ou presque pas): tu as un "encodage système" qui dicte la
table de traduction à utiliser. Résultat, il est impossible de
lire en même temps (sans rebooter) une vieille disquette russe
*et* un vieux cédérom japonais.
J'ajoute que j'ai testé, mais que je suis persuadé que je suis
une exception ! normalement, personne ne rencontre ce genre de
problème.

Post by Stephane CHAZELAS
Mettons que j'aie un fichier: 10¤.gif (10 euros.gif) stocké sur
un CDROM avec un filesystem Microsoft (donc, avec les caractères
unicode '1', '0', '.', '\u20AC', '.', 'g', 'i', 'f') et que j'ai
aussi un fichier HTML (fichier.html) qui contient « voici un
billet de <img src="[je mets quoi, là?]" alt="10 &euro;"> ».

Bon, réglons le problème HTML: src de IMG est du CDATA, donc tu
peux mettre &euro; ou &#<qui-va-bien>;

Bien sûr, ce n'est pas ta question. Tu veux savoir ce qu'il faut
pour un navigateur donné. Parce que en fait, c'est le navigateur
qui va devoir faire la traduction. Avec nécessité de compromis.

Comme j'ai expliqué, avec NT tout est de manière interne en
Unicode. Donc le "bon" appel a open() [OK, CreateFileW()] doit
être L'10\u20AC.gif'. Si le navigateur est "optimisé NT", il va
prendre la chaîne, la convertir tout de suite en UTF-16, et voilà!

Seulement, comme 1) 9x ne possède pas CreateFileW, et 2) les
navigateurs ont éte écrit au temps où 9x régnait, tu as du code
(des quantités dans le cas de Mozilla) qui "s'amuse" à comprendre
ton nom de fichier, et qui le passe à CreateFileA en forme de
chaîne 8bits, dans le code ANSI "qui va bien" (ou plutôt, celui que
le navigateur pense qui va bien aller, c'est une source de bogues
sans fin), y compris et surtout si on tourne sur NT.
Résultat, te prédire le code qu'il faut mettre pour obtenir ce que
tu veux relève de la voyance, pas de l'informatique.

Post by Stephane CHAZELAS
Je viens de faire des tests avec mkisofs.

<couic>

Post by Stephane CHAZELAS
([3f], c'est '?'. C'est monté en latin1 par défaut! Donc, mon lien
ne marche pas).

<re-couic>

Post by Stephane CHAZELAS
Là, c'est OK pour mon lien en UTF-8.

La seule chose que tu as démontré, c'est qu'avec Unix, tu es obligé
de faire des contortions pour obtenir que le jeu de caractères que
tu utilises pour accéder à ton cédérom, ce soit utf8; pour le FS du
cédérom (avec Joliet), pas de pépin, c'est clairement un euro, et
grâce à Unicode il n'y a qu'une seule manière de l'encoder.


Antoine

[Erwan David]

Post by Antoine Leca
Bon, je me moques. Mais si tu essayes de lire un CD gravé il y a
quelques années, avec (au hasard) les noms de tes chansons MP3 en
format iso-8859-1, en étant avec un locale fr_ES.utf8, tu vas
comprendre, et même toucher du doigt, les problèmes des
Microsoftiens...

Je ne suis pas sûr qu'iso-9660 n'impose pas un jeu de
caractères. Maintenant si tu sors de la spec...

[Jean-Marc Desperrier]

Post by Erwan David

Post by Antoine Leca
Bon, je me moques. Mais si tu essayes de lire un CD gravé il y a
quelques années, avec (au hasard) les noms de tes chansons MP3 en
format iso-8859-1, en étant avec un locale fr_ES.utf8, tu vas
comprendre, et même toucher du doigt, les problèmes des
Microsoftiens...

Je ne suis pas sûr qu'iso-9660 n'impose pas un jeu de
caractères. Maintenant si tu sors de la spec...

Oups !! Je pensais que rien n'était défini, mais j'avais oublié le "iso"
dans "iso-9660".

Sonnez tambour, résonnez trompettes, le *vrai* jeu de caractère à
utiliser sur iso-9660 est bien évident iso-2022.

Non, pas iso-2022-jp, que j'ai évoqué avant, mais le iso-2022 complet.
Bon, évidemment tout iso-2022 ne doit pas être autorisé, il semble
d'après le morceau de standard iso-9660 trainant sur le réseau queje
viens de voir que ce soit iso-4873 qui définit les restriction à
apporter à iso-2022 dans ce cas-ci.

Par chance, iso-2022 et iso-4873 ont une double identité sous la forme
de ECMA-43 (pour ISO 4873) et ECMA-35 (pour ISO-2022) qui sont
disponibles en ligne :
http://www.ecma-international.org/publications/standards/Ecma-043.htm
http://www.ecma-international.org/publications/standards/Ecma-035.htm

En fait, le problème est que ISO-4873 ne tient pas debout tout seul, il
faut un doc en plus pour définir le niveau d'implémentation et ce qu'on
met dans G1, les autres jeux si on ne se restreint pas à G1.

Tiens, le résultat final pourrait même être ISO-8859-1, si on définit
l'implémentation comme level 1, et G1 comme étant ISO-IR 100.
cf : http://www.itscj.ipsj.or.jp/ISO-IR/2-3.htm

[Antoine Leca]

Post by Erwan David
Je ne suis pas sûr qu'iso-9660 n'impose pas un jeu de
caractères. Maintenant si tu sors de la spec...

Joliet, c'est pas fait pour cela ?

<URL:http://msdn.microsoft.com/library/en-us/w98ddk/hh/w98ddk/storage_5o6x.asp>


Antoine

[Erwan David]

Post by Antoine Leca

Post by Erwan David
Je ne suis pas sûr qu'iso-9660 n'impose pas un jeu de
caractères. Maintenant si tu sors de la spec...

Joliet, c'est pas fait pour cela ?
<URL:http://msdn.microsoft.com/library/en-us/w98ddk/hh/w98ddk/storage_5o6x.asp>

Joliet est une extension entièrement propriétaire de microsoft. Rien d'autre.

[Antoine Leca]

Post by Erwan David

Post by Antoine Leca

Post by Erwan David
Je ne suis pas sûr qu'iso-9660 n'impose pas un jeu de
caractères. Maintenant si tu sors de la spec...

Joliet, c'est pas fait pour cela ?

Joliet est une extension entièrement propriétaire de microsoft. Rien d'autre.

Bin si justement. C'est le standard qu'utilise tout le monde pour
encoder un nom de fichier Unicode sur un cédérom (de la même façon
qu'on utilise Rockridge pour encoder des noms de fichier longs).

C'est exact que cela ne fait pas partie de la norme ISO 9660.
Mais (au moins la partie qui nous intéresse, le fait de coder en
Unicode) est fait de manière compatible et expressement autorisée
par ISO 9660 (voir en particulier 8.5.6).

Maintenant, on peut discuter que ce n'était pas l'intention de
ISO 9660, qu'il fallait comprendre que c'est destiné seulement à
utiliser des caractères 8 bits, bref que le comité s'est trompé et
aurait dû écrire 4873 (cf. message de Jean-Marc). Stérile. C'est
bien plus intelligent de coder les noms en Unicode ; et en 2004,
sur un cédérom, il faut le faire avec Joliet.


Antoine

[Jean-Marc Desperrier]

Antoine Leca wrote:
[...]

Post by Antoine Leca
Mais (au moins la partie qui nous intéresse, le fait de coder en
Unicode) est fait de manière compatible et expressement autorisée
par ISO 9660 (voir en particulier 8.5.6).
Maintenant, on peut discuter que ce n'était pas l'intention de
ISO 9660, qu'il fallait comprendre que c'est destiné seulement à
utiliser des caractères 8 bits, bref que le comité s'est trompé et
aurait dû écrire 4873 (cf. message de Jean-Marc). Stérile. [...]

Je n'ai accès pas à iso-9660 ! Je ne peut pas voir ce chapitre 8.5.6 !
Le tout petit morceau que j'en avais montrait une référence explicite à
4873, visiblement ma conclusion que c'était cela qui définissait les
noms de fichiers était erronée. (par ailleurs, iso-4873 ne restreint
absolument pas à une table de caractère maximale de 256 positions,
iso-2022-jp repose sur ces même mécanismes et inclut tous les caractères
japonais).

[Antoine Leca]

Post by Jean-Marc Desperrier
Je n'ai accès pas à iso-9660 ! Je ne peut pas voir ce chapitre 8.5.6 !

Tu n'as pas dû chercher, alors.
Moi non plus, je n'y ai pas accès. Mais comme tout le monde le sait,
aujourd'hui, les normes de technologie de l'information, surtout les normes
« intéressantes », sont développées avec des processus semi-ouverts ; ce qui
fait que les projets de normes, y compris généralement le dernier projet,
sont disponibles sur le web.

Alors hier, j'ai fait ce que l'on fait dans ces cas-là: j'ai lancé 2 ou 3
requêtes sur Google. Et j'ai appris que ISO 9660:1988 était dupliqué par la
norme ECMA 119, librement consultable.
Et le projet de révision de 1999 de ISO 9660 est disponible
<URL:http://www.y-adagio.com/public/standards/iso_cdromr/tocont.htm>

Post by Jean-Marc Desperrier
Le tout petit morceau que j'en avais montrait une référence explicite
à 4873, visiblement ma conclusion que c'était cela qui définissait les
noms de fichiers était erronée. (par ailleurs, iso-4873 ne restreint
absolument pas à une table de caractère maximale de 256 positions,
iso-2022-jp repose sur ces même mécanismes et inclut tous les
caractères japonais).

Sauf que ISO/CEI 4873 repose sur des codets de 8 bits, ce qui est clairement
incompatible avec le schéma Unicode (au moins celui de Microsoft). ISO/CEI
2022, au contraire de 4873, accepte l'existence d'autres jeux de caractères
(dont évidemment EBCDIC), et décrit une manière de les englober. Ce dont a
profité les ingénieurs de Microsoft en spécifiant Joliet. Ensuite, le simple
fait que cette spécification n'ai pas été reprise en 1999 par le comité
chargé de la révision de ISO 9660 montre que cette astuce n'a pas dû leur
plaire plus que cela. Mais ils n'ont pas pu l'empêcher (et en fait la
révision de 1999 cherche à être compatible Joliet; un peu trop d'ailleurs,
mais c'est une autre histoire).


Antoine

[Stephane CHAZELAS]

2004-02-17, 20:50(+01), Antoine Leca:
[...]

Post by Antoine Leca

Post by Erwan David
Joliet est une extension entièrement propriétaire de microsoft. Rien d'autre.

Bin si justement. C'est le standard qu'utilise tout le monde pour
encoder un nom de fichier Unicode sur un cédérom (de la même façon
qu'on utilise Rockridge pour encoder des noms de fichier longs).

[...]

Avec Rockridge, tu peux encoder un nom de fichier Unicode en
UTF-8 qui sera compréhensible par tout le monde (dans la mesure
où on sait que c'est de l'UTF-8).

Avec Joliet, tu encodes un nom de fichier Unicode en UTF-16
qui ne sera lisible que par des systèmes Microsoft récents (et
encore tant qu'on reste dans les parties du système qui causent
Unicode) ou au moyen de contorsions (recodage en un truc 8 bits)
sur les autres systemes.

[Pablo Saratxaga]

Dins l' messaedje fr.comp.normes.unicode,
Stephane CHAZELAS <***@free.fr> scrijheut:

SC> Avec Joliet, tu encodes un nom de fichier Unicode en UTF-16
SC> qui ne sera lisible que par des systèmes Microsoft récents (et

Et les systèmes Unix recents aussi (sur GNU/Linux ça fait des années
qu'on sait lire parfaitemment aussi les CD joliet)

[Stephane Chazelas]

Post by Pablo Saratxaga
Dins l' messaedje fr.comp.normes.unicode,
SC> Avec Joliet, tu encodes un nom de fichier Unicode en UTF-16
SC> qui ne sera lisible que par des systèmes Microsoft récents (et
Et les systèmes Unix recents aussi (sur GNU/Linux ça fait des années
qu'on sait lire parfaitemment aussi les CD joliet)

Tu as coupé la partie du texte où je disais la même chose:

« ou au moyen de contorsions (recodage en un truc 8 bits)
sur les autres systemes. »

C'est à dire que sur les autres systèmes, on n'accède pas au nom
UTF-16 mais à un autre nom variable suivant le système et les
options de montage, ce qui est le problème.

[Antoine Leca]

Post by Stephane CHAZELAS
[...]

Post by Antoine Leca

Post by Erwan David
Joliet est une extension entièrement propriétaire de microsoft. Rien d'autre.

Bin si justement. C'est le standard qu'utilise tout le monde pour
encoder un nom de fichier Unicode sur un cédérom (de la même façon
qu'on utilise Rockridge pour encoder des noms de fichier longs).
[...]

Avec Rockridge, tu peux encoder un nom de fichier Unicode en
UTF-8 qui sera compréhensible par tout le monde (dans la mesure
où on sait que c'est de l'UTF-8).

Ce que j'aime bien, c'est ce qu'il y a dans la parenthèse. Surtout quand 6
minutes plus tôt on me dit que mon CD gravé il y a quelques années, avec un
charset iso-8859-1, est lui aussi compréhensible par tout le monde.

D'autre part, jusqu'à récemment, je n'arrivais pas à lire sur une station
Windows un nom de fichier encodé en Rockridge utf8. Ce qui n'est pas un
argument, mais qui restreint le « compréhensible par tout le monde ».

Post by Stephane CHAZELAS
Avec Joliet, tu encodes un nom de fichier Unicode en UTF-16
qui ne sera lisible que par des systèmes Microsoft récents (et
encore tant qu'on reste dans les parties du système qui causent
Unicode) ou au moyen de contorsions (recodage en un truc 8 bits)
sur les autres systemes.

a) Windows 9x a recours, depuis 1994, aux dites contortions. Par contre,
pour NT (qui évite les contortions), il faut qu'ils sachent lire Joliet (je
pense que ce sera 3.51 et +). Dans tous les cas, c'est un peu béton de dire
"systèmes récents", non?

b) j'ai souvenir de problèmes entre Joliet et Unix, mais c'était en 1998.
Sauf si "systèmes récents" signifie postérieur à 1995 (c'est-à-dire,
incluant la dernière génération des machines qui sont à la casse), je me
dois de conclure que tu fais allusion à des systèmes Unix de vendeurs (et là
je pense très fort à SCO) qui se préoccupent beaucoup de leur compte de
résultat et beaucoup moins des besoins de leurs clients.
Ou alors de certains qui font exprès de rester incompatibles avec Microsoft
ou d'autres, avec des arguments du genre « ce n'est pas une norme » pour ne
pas accepter un standard, et qui aboutissent comme seul résultat tangible à
la solitude de leur tour d'ivoire. Le débat Joliet-Rockridge était
d'actualité il y a 5 ans. Aujourd'hui, il faut tourner la page.

c) tu laisses à penser que le fait que les systèmes de fichiers des années
1970 et 80, encore largement utilisé dans les environnements IBM ou Unix, et
fondés sur des noms encodés avec des jeux de caractères 8 bits plus une
métadonnée (souvent peu ou mal spécifiée) qui indique de quel jeu il s'agit,
représente une meilleure solution technique que le fait de spécifier que les
noms de fichiers sont stockés suivant la norme Unicode (avec l'encodage que
l'on veut); je ne peux pas être d'accord avec cela. Pour moi, un nom de
fichier est plus qu'une chaîne d'octets, c'est une donnée persistante. Avec
un signifiant.


Antoine

[Stephane CHAZELAS]

2004-02-16, 12:11(-08), Antoine Leca:
[...]

Post by Antoine Leca

Post by Stephane CHAZELAS
Toute l'API Unix est basé sur des noms de fichiers représentés
par une chaine de bytes 0 terminated.

Joie. Donc, la signification du nom du fichier dépend du jeu de
a) de la configuration actuelle (pour le processus) de LANG
LC_CTYPE et LC_ALL;
b) du bon vouloir placer un ordre setlocale() au début de l'image
en cours d'exécution; sinon, c'est utilisation d'un autre locale,
avec une sémantique différente.

Pas de problème particulier si tout est chaine de byte. Le
problème se situe essentiellement au niveau des interactions
avec l'utilisateur (affichage et input), mais le système
continue de marcher vu qu'on ne prete pas internalement
attention à la signification des bytes.

Post by Antoine Leca
Bon, je me moques. Mais si tu essayes de lire un CD gravé il y a
quelques années, avec (au hasard) les noms de tes chansons MP3 en
format iso-8859-1, en étant avec un locale fr_ES.utf8, tu vas
comprendre, et même toucher du doigt, les problèmes des
Microsoftiens...

Pas de problème particulier, sauf si tu as gravé un CD joliet
avec des noms longs (apparemment).

Les seuls problèmes se situeront au niveau de l'affichage du nom
des fichiers.

[...]

Post by Antoine Leca

Post by Stephane CHAZELAS
Mettons que j'aie un fichier: 10€.gif (10 euros.gif) stocké sur
un CDROM avec un filesystem Microsoft (donc, avec les caractères
unicode '1', '0', '.', '\u20AC', '.', 'g', 'i', 'f') et que j'ai
aussi un fichier HTML (fichier.html) qui contient « voici un
billet de <img src="[je mets quoi, là?]" alt="10 &euro;"> ».

Bon, réglons le problème HTML: src de IMG est du CDATA, donc tu
peux mettre &euro; ou &#<qui-va-bien>;

Tu peux mettre si tu veux, ça sera valide au niveau HTML/XML,
pas au niveau URL et ça ne fait pas de sens.

Post by Antoine Leca
Bien sûr, ce n'est pas ta question. Tu veux savoir ce qu'il faut
pour un navigateur donné. Parce que en fait, c'est le navigateur
qui va devoir faire la traduction. Avec nécessité de compromis.
Comme j'ai expliqué, avec NT tout est de manière interne en
Unicode. Donc le "bon" appel a open() [OK, CreateFileW()] doit
être L'10\u20AC.gif'. Si le navigateur est "optimisé NT", il va
prendre la chaîne, la convertir tout de suite en UTF-16, et voilà!

Convertir une chaine de bytes (sans information de charset) en
UTF-16 ?!

[...]

Post by Antoine Leca
La seule chose que tu as démontré, c'est qu'avec Unix, tu es obligé
de faire des contortions pour obtenir que le jeu de caractères que
tu utilises pour accéder à ton cédérom, ce soit utf8; pour le FS du
cédérom (avec Joliet), pas de pépin, c'est clairement un euro, et
grâce à Unicode il n'y a qu'une seule manière de l'encoder.

[...]

Non, avec UNIX, il n'y a que des chaines de bytes. Il n'y a de
probleme qu'avec l'interoperabilité avec les FS Microsoft, au
niveau de l'acces aux fichiers.

Les LC_*, c'est pour l'interaction avec l'utilisateur pour les
applications qui prennent en comptes ces variables
d'environnement, on est à un autre niveau, le passage de
caractère à byte se fait à un niveau qui ne met pas en cause le
bon fonctionnement du système.

Pour représenter un fichier à l'utilisateur, c'est vrai qu'on va
devoir avoir recours à des conventions et que c'est à
l'utilisateur (ou l'administrateur, ou l'application, le cas
échéant) de gérer, le système s'en dédouane (et c'est très
important au niveau interoperabilité que ça se passe comme ça).
Chaque application qui crée un fichier peut avoir ses propres
conventions, au moins, elle est assurée que le nom qu'elle
fournit au système est sans ambiguité et ne dépend pas des
options de montage du fs ou de la locale courante du système
(sauf quand on a affaire à des systèmes de fichiers Microsoft).

Ce n'est certes pas parfait, et il serait souhaitable que tout
le monde dans le monde s'entende sur un seul moyen de passer
d'une chaine de bytes (qui est à l'heure actuelle le moyen
standard d'echanger le nom d'un fichier entre systèmes, entre
applications et au niveau de la plupart des API, fichiers de
confs et autres formats de fichiers...) et des caractères (au
sens de la signification et de la representation à
l'utilisateur).

Les choix de Microsoft et d'Unix souffrent tous les deux des
mêmes genres de problèmes mais à différents niveaux. Il est
probable que Microsoft ait fait délibéremment le choix du frein
à l'interopérabilité car je ne vois pas quel plus ce choix
apporte techniquement.

[Antoine Leca]

Post by Stephane CHAZELAS
[...]

Post by Antoine Leca

Post by Stephane CHAZELAS
Toute l'API Unix est basé sur des noms de fichiers représentés
par une chaine de bytes 0 terminated.

Joie. Donc, la signification du nom du fichier dépend du jeu de

Pas de problème particulier si tout est chaine de byte.
Le problème se situe

Problème ou pas problème ?

Post by Stephane CHAZELAS
Le problème se situe essentiellement au niveau des interactions
avec l'utilisateur (affichage et input),

Voui.

Post by Stephane CHAZELAS
mais le système continue de marcher vu qu'on ne prete pas
internalement attention à la signification des bytes.

Si par « système » tu parles exclusivement de la partie du noyau qui gère
VFS, à l'exclusion des modules pour chacun des types de systèmes de
fichiers, et surtout à l'exclusion de libc et de tout ce qui intervient dans
l'interface avec l'utilisateur, d'accord.
Mon interprétation est plus large (tout en étant beaucoup moins large que
celle des « utilisateurs lambda » pour qui l'ensemble des processus
sous-jacents sont « le système »). Dans mon interprétation, on peut avoir
des noms de fichiers (encodés réellement en iso-8859-1, mais ce n'est pas
dit), chaînes d'octets fournis par le système (read() sur le répertoire),
qu'un programme avec un locale "qq_XX.utf8" a bien du mal à traiter.
Et le résultat, ce n'est pas ce que j'appelle « marcher ».

Post by Stephane CHAZELAS

Post by Antoine Leca
Bon, je me moques. Mais si tu essayes de lire un CD gravé il y a
quelques années, avec (au hasard) les noms de tes chansons MP3 en
format iso-8859-1, en étant avec un locale fr_ES.utf8, tu vas
comprendre, et même toucher du doigt, les problèmes des
Microsoftiens...

Pas de problème particulier, sauf si tu as gravé un CD joliet
avec des noms longs (apparemment).
Les seuls problèmes se situeront au niveau de l'affichage du nom
des fichiers.

Elle est très bonne.
Supposons donc que je n'ai pas gravé le descripteur Joliet, « pour éviter
les problèmes ». Comment fais-je, dans l'interface utilisateur (utf8) pour
sélectionner un nom de fichier qui est « apparement » illégal (donc mal
lisible) ? Comment est-ce que je fais pour extraire du nom le titre de la
chanson, pour pouvoir l'indexer? Et comment, une fois indexé le titre plein
de caractères illégaux (comme c'est une chaîne d'octets, on peut le faire),
comment en extraire une substantifique consistance?

Solution, traiter, en plus des chaînes de caractères légales, les illégales.
Et « comme c'est juste un problème d'affichage », on se retrouve avec
partout du code blindé, qui passe son temps à retraiter les chaînes pour
manipuler les chaînes illégales (et comme chacun le fait à ssa manière,
c'est une mine de bogues sans fin...)

Bien sûr, l'autre solution, « la bonne », c'est de changer de locale pour
lire les noms de fichiers sur le CD, faire la conversion, et rechanger de
locale pour suivre ce que dit l'utilisateur actuel. Aucun problème
particulier.

Post by Stephane CHAZELAS

Post by Antoine Leca
Bon, réglons le problème HTML: src de IMG est du CDATA, donc tu
peux mettre &euro; ou &#<qui-va-bien>;

Tu peux mettre si tu veux, ça sera valide au niveau HTML/XML,
pas au niveau URL et ça ne fait pas de sens.

C'est vrai que j'avais oublié qu'en 2004 on ne s'était pas encore mis
d'accord sur un moyen d'encoder les données non-ASCII dans les URIs, et donc
qu'il reste interdit, prohibido, verboten, de s'exprimer avec des langages
non autorisés et surtout des lettres non autorisées.

Et que bien que le W3C ait spécifiquement explicité une procédure pour
résoudre ce problème dans le cadre de HTML (annexe B.2.1), et que d'après
eux « this is supported by all major browsers in newer versions »
<URL:http://www.w3.org/International/O-URL-and-ident.html>, cela n'en reste
pas moins parfaitement illégal au sens strict.

Post by Stephane CHAZELAS

Post by Antoine Leca
Comme j'ai expliqué, avec NT tout est de manière interne en
Unicode. Donc le "bon" appel a open() [OK, CreateFileW()] doit
être L'10\u20AC.gif'. Si le navigateur est "optimisé NT", il va
prendre la chaîne, la convertir tout de suite en UTF-16, et voilà!

Convertir une chaine de bytes (sans information de charset) en
UTF-16 ?!

Bien sûr, si la chaîne d'octets est indépendanntes d'un jeu de caractères
donné. C'est tout l'intérêt des entités en SGML/HTML, ou des UCNs en
Java/C++/C.

Post by Stephane CHAZELAS
Chaque application qui crée un fichier peut avoir ses propres
conventions, au moins, elle est assurée que le nom qu'elle
fournit au système est sans ambiguité et ne dépend pas des
options de montage du fs ou de la locale courante du système

Tu décris le cas général, où la métadonnée (le jeu de caractères utilisé
pour les noms sur ce support-là) est entièrement volatile, donc sous le
contrôle exclusif de l'application. D'abord, c'est pas toujours exact,
parfois l'application doit collaborer avec d'autres. Mais surtout, comme els
noms de fichiers sont persistants, cela signifie que la métadonnée l'est
aussi. Et le problème, c'est comment est assurée cette persistance.
Dans l'idée des concepteurs de l'idée de locale, c'était cet unique
paramètre qui gardait, entre autres, cette métadonnée. Ce modèle n'a pas,
ÀMHA, resisté à la réalité.

Pour pallier le problème, certains ont eu l'idée de ranger cette métadonnée
(charset) avec le support (ce qui permet d'éviter le problème de l'option de
montage); c'est le cas par exemple de MIME (pour le contenu, pas pour les
noms, mais le raisonnement devrait apparaître clairement); mais alors on a
le problème de savoir quoi présenter à l'utilisateur, ce qui impose donc un
comportement dépendant de la locale...

Post by Stephane CHAZELAS
(sauf quand on a affaire à des systèmes de fichiers Microsoft).

As-tu déjà travaillé avec un système de fichiers monté sur un ordinateur
IBM?

Post by Stephane CHAZELAS
Ce n'est certes pas parfait, et il serait souhaitable

[couic]
Je ne sais qu'ajouter...

Post by Stephane CHAZELAS
Les choix de Microsoft et d'Unix souffrent tous les deux des
mêmes genres de problèmes mais à différents niveaux.

Oui! Là nous sommes d'accord.

Post by Stephane CHAZELAS
je ne vois pas quel plus ce choix [M$] apporte techniquement.

Non? Et tu ne penses pas que l'on aurait moins de problèmes si tout le monde
utilisait des noms en Unicode *exclusivement* (dans une forme de
normalisation à définir, je ne dis pas que la solution de M$ soit optimale,
bien au contraire; idem pour le stockage, dans bien des cas UTF-16 est un
gâchis, tandis que UTF-8 permet une migration beaucoup plus aisée)?


Antoine

[Pablo Saratxaga]

Dins l' messaedje fr.comp.normes.unicode,
Jean-Marc Desperrier <***@alussinan.org> scrijheut:

JD> Les encodages japonais sont eux resynchronisables sur les caractères
JD> ASCII ou sur les retour chariot (retour chariot uniquement pour JIS).

Non, EUC a la même propriété que UTF-8 (EUC-JP a d'ailleurs des
caractères de 1, 2 ou *3* octets; bien que ces derniers soient très
rarement supportés).
En fait c'est EUC qui m'a fait comprendre comment fonctionnait UTF-8;
UTF-8 c'est une sorte d'EUC étendu (couvrant un plage de caractères
differents, et dans un autre ordre, mais le principe est le même).

(en passant, EUC signifie Extendend Unix Code, comem d'hab les bonnes
choses viennent toujours de là)

Par contre Microsoft et Apple ont préféré utiliser Shit-JIS plutôt, qui
combine toutes les mauvaises idées et est le pire encodage pour le
japonais (outre la non synchronisabilité, il y a les kana de
demi-largeur, incompatibles avec le reste, et la redefinition du
caractère "\" (backslash))

[ol.g+ (Olivier Gutknecht)]

Post by Pablo Saratxaga
Par contre Microsoft et Apple ont préféré utiliser Shit-JIS plutôt, qui
combine toutes les mauvaises idées et est le pire encodage pour le
japonais (outre la non synchronisabilité, il y a les kana de
demi-largeur, incompatibles avec le reste, et la redefinition du
caractère "\" (backslash))

Plus maintenant pour ce qui est de MacOS X en tout cas. EUC et Shift-JIS
ont le même niveau de support (ainsi que l'antédiluvien Mac-Japanese,
mais c'est une autre histoire).

Ol.

[Jean-Marc Desperrier]

Post by Pablo Saratxaga
Dins l' messaedje fr.comp.normes.unicode,
JD> Les encodages japonais sont eux resynchronisables sur les caractères
JD> ASCII ou sur les retour chariot (retour chariot uniquement pour JIS).
Non, EUC a la même propriété que UTF-8

Désolé de te contredire, mais peut-être qu'il y a une confusion sur ce
dont on parle.
Comme on part dans le hors-sujet sur fr.comp.os.unix, je propose de
restreindre le suivi sur fr.comp.normes.unicode.

Je vais donner un exemple précis pour être sur qu'il n'y ait pas de
confusion.

Le caractère unicode U963F a pour code EUC B0A4.
Le caractère unicode U920E a pour code EUC B3C3.
Le caractère unicode U3072 a pour code EUC A4D2.

Le caractère unicode U3053 a pour code EUC A4B3.
Le caractère unicode U8FB0 a pour code EUC C3A4.

Quand je trouve la chaine en octet au milieu d'un fichier EUC :
XX-B0-A4-B3-C3-A4-D2-XX ...

Je ne peux pas savoir si elle représente les caractères :
XXXX - B0A4 - B3C3 - A4D2 - XXXX
ou bien les caractères :
XXB0 - A4B3 - C3A4 - D2XX

sans être synchronisé correctement dans le flux du fichier.

Et si je recherche les endroits où se trouve le caractère EUC B3C3 avec
un grep ne gérant pas EUC, il va croire qu'il l'a trouvé à un endroit où
se trouve en réalité les caractères EUC A4B3 et EUC C3A4 accolé.

[Pablo Saratxaga]

Dins l' messaedje fr.comp.normes.unicode,

Post by Pablo Saratxaga
Non, EUC a la même propriété que UTF-8

JD> Désolé de te contredire, mais peut-être qu'il y a une confusion sur ce
JD> dont on parle.

Effectivemment tu as raison.
En fait 0x00-0x9f est exclu du premier octet; mais effectivement il y a
un nombre assez important de valuers pouvant être sur le premier ou
autres octets.

Je suis un peu gêné là.

[Jean-Marc Desperrier]

Post by Pablo Saratxaga
En fait 0x00-0x9f est exclu du premier octet; mais effectivement il y a
un nombre assez important de valuers pouvant être sur le premier ou
autres octets.

Mais comme pour EUC-JP, 0x00-0x9f est exclu aussi du deuxième octet,
presque tous les deuxièmes octets sont des valeurs valables pour un
premier octet. D'où le fait qu'on ne pourra se resynchroniser
pratiquement que sur le prochain caractère ASCII.
Bon, ça c'est EUC-JP, comme l'exemple que j'ai cité, il y a peut-être
d'autres variantes de EUC que je connais moins où le problème est moins
critique.

Post by Pablo Saratxaga
Je suis un peu gêné là.

kobo ni mo fude no ayamari

Et tu mérite la comparaison à kobo plus qu'à un singe ;-)

[Pablo Saratxaga]

Kaixo!
Li Tue, 10 Feb 2004 10:23:14 +0100,
Jean-Marc Desperrier <***@alussinan.org> scrijheut:

JD> kobo ni mo fude no ayamari

JD> Et tu mérite la comparaison à kobo plus qu'à un singe ;-)

ça fait moins mal aussi que de tomber d'un arbre.

[Emmanuel Dreyfus]

Post by Jean-Marc Desperrier
Et qu'il y a-t-il que bash ne sait pas faire ?

Supporter un bind ^I=complete-file sans y perdre la touche f du clavier
(c'est un très vieux bug, si quelqu'un peut m'expliquer, ca m'ammusera).

[Erwan David]

Post by Emmanuel Dreyfus

Post by Jean-Marc Desperrier
Et qu'il y a-t-il que bash ne sait pas faire ?

Supporter un bind ^I=complete-file sans y perdre la touche f du clavier
(c'est un très vieux bug, si quelqu'un peut m'expliquer, ca m'ammusera).

Il y a aussi le ** (* mais récursif dans les répertoires), quelques
commandes d'historique (esc-p : cherche dans l'historique la première
commande qui matche ce qu'on a tapé).