en fait, pour commencer,
est ce que la norme UNIX donne une liste de caractères autorisés dans
les noms de fichiers, et/ou une liste de caractères interdits ?
> j'ai posé cette question pour savoir quoi dire à celui qui gère > dl.free.fr, qui interdit un tas de caractères quand on envoie les > fichiers par ftp (dont notamment l'espace), et qui a indiqué (d'après > mes souvenirs) être limité par des pbs de fs
FTP a ses propres limites en caractères spéciaux dans les noms des fichiers, ceci indépendamment du système de fichier.
merci pour la précision :-)
du coup, même question : une liste de caractères interdits ?
(au moins, l'espace fait partie de ce qui est autorisé, non ?)
In article <4d3fb8d1$0$8419$426a74cc@news.free.fr>,
Éric Lévénez <usenet@levenez.com> wrote:
Le 26/01/11 03:46, Thomas a écrit :
> j'ai posé cette question pour savoir quoi dire à celui qui gère
> dl.free.fr, qui interdit un tas de caractères quand on envoie les
> fichiers par ftp (dont notamment l'espace), et qui a indiqué (d'après
> mes souvenirs) être limité par des pbs de fs
FTP a ses propres limites en caractères spéciaux dans les noms des
fichiers, ceci indépendamment du système de fichier.
merci pour la précision :-)
du coup, même question : une liste de caractères interdits ?
(au moins, l'espace fait partie de ce qui est autorisé, non ?)
> j'ai posé cette question pour savoir quoi dire à celui qui gère > dl.free.fr, qui interdit un tas de caractères quand on envoie les > fichiers par ftp (dont notamment l'espace), et qui a indiqué (d'après > mes souvenirs) être limité par des pbs de fs
FTP a ses propres limites en caractères spéciaux dans les noms des fichiers, ceci indépendamment du système de fichier.
merci pour la précision :-)
du coup, même question : une liste de caractères interdits ?
(au moins, l'espace fait partie de ce qui est autorisé, non ?)
FTP a ses propres limites en caractères spéciaux dans les noms des fichiers, ceci indépendamment du système de fichier.
merci pour la précision :-)
du coup, même question : une liste de caractères interdits ?
Je n'ai jamais regardé exactement ce qui est autorisé par la norme et ce qui est réellement implémenté avec les clients et les serveurs.
L'exemple typique est le fichier caché "Iconr" (avec un CR en fin de nom), que Mac OS X utilisait il y a quelques temps. Avec FTP on pouvait envoyer ce fichier sur un serveur FTP (pour mettre à jour un site web par exemple), mais on ne pouvait plus le supprimer. Le seul moyen était de demander au webmaster de le supprimer à la main directement sur le serveur...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 26/01/11 18:44, Thomas a écrit :
In article<4d3fb8d1$0$8419$426a74cc@news.free.fr>,
Éric Lévénez<usenet@levenez.com> wrote:
FTP a ses propres limites en caractères spéciaux dans les noms des
fichiers, ceci indépendamment du système de fichier.
merci pour la précision :-)
du coup, même question : une liste de caractères interdits ?
Je n'ai jamais regardé exactement ce qui est autorisé par la norme et ce
qui est réellement implémenté avec les clients et les serveurs.
L'exemple typique est le fichier caché "Iconr" (avec un CR en fin de
nom), que Mac OS X utilisait il y a quelques temps. Avec FTP on pouvait
envoyer ce fichier sur un serveur FTP (pour mettre à jour un site web
par exemple), mais on ne pouvait plus le supprimer. Le seul moyen était
de demander au webmaster de le supprimer à la main directement sur le
serveur...
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
FTP a ses propres limites en caractères spéciaux dans les noms des fichiers, ceci indépendamment du système de fichier.
merci pour la précision :-)
du coup, même question : une liste de caractères interdits ?
Je n'ai jamais regardé exactement ce qui est autorisé par la norme et ce qui est réellement implémenté avec les clients et les serveurs.
L'exemple typique est le fichier caché "Iconr" (avec un CR en fin de nom), que Mac OS X utilisait il y a quelques temps. Avec FTP on pouvait envoyer ce fichier sur un serveur FTP (pour mettre à jour un site web par exemple), mais on ne pouvait plus le supprimer. Le seul moyen était de demander au webmaster de le supprimer à la main directement sur le serveur...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Erwan David
Paul Gaborit écrivait :
Un bon test consiste à créer dans un même répertoire deux fichiers portant le même nom mais l'un avec une représentation composée des accents et l'autre avec une représentation décomposée. Ensuite on présente cela à différents logiciels sur différents OS et on admire le résulat... en rigolant ou en pleurant selon l'humeur du moment !
Ajoutons : * le problème des systèmes de fichier insensibles à la casse. (ce qui me fait penser que Posix est trop laxiste : pour être portable il faut éviter d'avoir toto.c et TOTO.C)
* les noms interdits (n'utilisez pas un fichier aux.h sous windows, il serait mélangé avec le port série...)
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
Un bon test consiste à créer dans un même répertoire deux fichiers
portant le même nom mais l'un avec une représentation composée des
accents et l'autre avec une représentation décomposée. Ensuite on
présente cela à différents logiciels sur différents OS et on admire le
résulat... en rigolant ou en pleurant selon l'humeur du moment !
Ajoutons :
* le problème des systèmes de fichier insensibles à la casse. (ce qui me
fait penser que Posix est trop laxiste : pour être portable il
faut éviter d'avoir toto.c et TOTO.C)
* les noms interdits (n'utilisez pas un fichier aux.h sous windows, il
serait mélangé avec le port série...)
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Un bon test consiste à créer dans un même répertoire deux fichiers portant le même nom mais l'un avec une représentation composée des accents et l'autre avec une représentation décomposée. Ensuite on présente cela à différents logiciels sur différents OS et on admire le résulat... en rigolant ou en pleurant selon l'humeur du moment !
Ajoutons : * le problème des systèmes de fichier insensibles à la casse. (ce qui me fait penser que Posix est trop laxiste : pour être portable il faut éviter d'avoir toto.c et TOTO.C)
* les noms interdits (n'utilisez pas un fichier aux.h sous windows, il serait mélangé avec le port série...)
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Antoine Leca
Thomas écrivit :
In article <ihjier$h9b$, Antoine Leca wrote:
Qui plus est, dans les versions antérieures à l'actuelle, il y a avait une recommandation [Posix:2003 : XBD 3.170 "Filename Portability"] pour utiliser ce jeu réduit de 65 caractères ; cette recommandation a été apparemment supprimée dans la version actuelle de la norme.
ouf !
par contre, cette recommandation qui était trop contraignante pour l'usage moyen actuel de l'informatique, elle n'a pas été remplacée par une autre recommandation qui serais un tout petit peu plus contraignante que "Tout sauf 0 et /" ?
Pas sûr que tu vas aimer la réponse...
La recommandation (qui n'était donc qu'un conseil sans frais) est devenue une "shall clause" (désolé, je ne connais pas le terme français correspondant), sous le numéro 4.7, "Filename Portability" For a filename to be portable across implementations conforming to POSIX.1-2008, it shall consist only of the portable filename character set as defined in Portable Filename Character Set . (autrement dit, le même contenu que précédement.)
Cela étant, les choses n'ont pas beaucoup changé, je pense que le fait d'être « portable entre implémentations » n'est une contrainte effective que pour la commande pax (tar. cpio) et les formats de fichiers correspondants : en particulier, une application strictement conforme Posix (2.2.1) n'est pas contrainte à ce niveau ; note néanmoins que les applications conformes XSI (2.2.4, l'échelon le plus «libéral») n'offrent aucune liberté supplémentaire à ce niveau :-(. Comme l'explique l'introduction, cette notion de « portable entre implémentations » correspond plutôt à l'objectif initial de l'effort de normalisation Posix, à la ligne directrice.
Cependant, le fait que la "shall clause" soit maintenant plus visible (un des 22 concepts généraux au lieu d'être perdue dans les 440 et quelques définitions), pourrait donner l'idée à certains organismes qui se base sur Posix (comme les obligations imposées aux fournisseurs contractuels du gouvernement américain, qui furent historiquement les artisans du succès de Posix dans les années 90), de la rendre partie intégrante des contraintes d'échanges entre systèmes ouverts...
j'ai posé cette question pour savoir quoi dire à celui qui gère dl.free.fr, qui interdit un tas de caractères quand on envoie les fichiers par ftp (dont notamment l'espace),
L'espace dans les noms de fichiers est du point de vue de la portabilité une engeance, dont chaque administrateur voudrait être débarrassé autant que faire ce peu (même dans le monde Windows, où pourtant ils sont nettement plus fréquents).
Autrement dit, je sympathise avec l'administrateur de Free... et je comprend bien ton insistance !
Antoine
Thomas écrivit :
In article <ihjier$h9b$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Qui plus est, dans les versions antérieures à l'actuelle, il y a avait
une recommandation [Posix:2003 : XBD 3.170 "Filename Portability"] pour
utiliser ce jeu réduit de 65 caractères ; cette recommandation a été
apparemment supprimée dans la version actuelle de la norme.
ouf !
par contre, cette recommandation qui était trop contraignante pour
l'usage moyen actuel de l'informatique, elle n'a pas été remplacée par
une autre recommandation qui serais un tout petit peu plus contraignante
que "Tout sauf 0 et /" ?
Pas sûr que tu vas aimer la réponse...
La recommandation (qui n'était donc qu'un conseil sans frais) est
devenue une "shall clause" (désolé, je ne connais pas le terme français
correspondant), sous le numéro 4.7, "Filename Portability"
For a filename to be portable across implementations conforming
to POSIX.1-2008, it shall consist only of the portable
filename character set as defined in Portable Filename
Character Set .
(autrement dit, le même contenu que précédement.)
Cela étant, les choses n'ont pas beaucoup changé, je pense que le fait
d'être « portable entre implémentations » n'est une contrainte effective
que pour la commande pax (tar. cpio) et les formats de fichiers
correspondants : en particulier, une application strictement conforme
Posix (2.2.1) n'est pas contrainte à ce niveau ; note néanmoins que les
applications conformes XSI (2.2.4, l'échelon le plus «libéral»)
n'offrent aucune liberté supplémentaire à ce niveau :-(.
Comme l'explique l'introduction, cette notion de « portable entre
implémentations » correspond plutôt à l'objectif initial de l'effort de
normalisation Posix, à la ligne directrice.
Cependant, le fait que la "shall clause" soit maintenant plus visible
(un des 22 concepts généraux au lieu d'être perdue dans les 440 et
quelques définitions), pourrait donner l'idée à certains organismes qui
se base sur Posix (comme les obligations imposées aux fournisseurs
contractuels du gouvernement américain, qui furent historiquement les
artisans du succès de Posix dans les années 90), de la rendre partie
intégrante des contraintes d'échanges entre systèmes ouverts...
j'ai posé cette question pour savoir quoi dire à celui qui gère
dl.free.fr, qui interdit un tas de caractères quand on envoie les
fichiers par ftp (dont notamment l'espace),
L'espace dans les noms de fichiers est du point de vue de la portabilité
une engeance, dont chaque administrateur voudrait être débarrassé autant
que faire ce peu (même dans le monde Windows, où pourtant ils sont
nettement plus fréquents).
Autrement dit, je sympathise avec l'administrateur de Free... et je
comprend bien ton insistance !
Qui plus est, dans les versions antérieures à l'actuelle, il y a avait une recommandation [Posix:2003 : XBD 3.170 "Filename Portability"] pour utiliser ce jeu réduit de 65 caractères ; cette recommandation a été apparemment supprimée dans la version actuelle de la norme.
ouf !
par contre, cette recommandation qui était trop contraignante pour l'usage moyen actuel de l'informatique, elle n'a pas été remplacée par une autre recommandation qui serais un tout petit peu plus contraignante que "Tout sauf 0 et /" ?
Pas sûr que tu vas aimer la réponse...
La recommandation (qui n'était donc qu'un conseil sans frais) est devenue une "shall clause" (désolé, je ne connais pas le terme français correspondant), sous le numéro 4.7, "Filename Portability" For a filename to be portable across implementations conforming to POSIX.1-2008, it shall consist only of the portable filename character set as defined in Portable Filename Character Set . (autrement dit, le même contenu que précédement.)
Cela étant, les choses n'ont pas beaucoup changé, je pense que le fait d'être « portable entre implémentations » n'est une contrainte effective que pour la commande pax (tar. cpio) et les formats de fichiers correspondants : en particulier, une application strictement conforme Posix (2.2.1) n'est pas contrainte à ce niveau ; note néanmoins que les applications conformes XSI (2.2.4, l'échelon le plus «libéral») n'offrent aucune liberté supplémentaire à ce niveau :-(. Comme l'explique l'introduction, cette notion de « portable entre implémentations » correspond plutôt à l'objectif initial de l'effort de normalisation Posix, à la ligne directrice.
Cependant, le fait que la "shall clause" soit maintenant plus visible (un des 22 concepts généraux au lieu d'être perdue dans les 440 et quelques définitions), pourrait donner l'idée à certains organismes qui se base sur Posix (comme les obligations imposées aux fournisseurs contractuels du gouvernement américain, qui furent historiquement les artisans du succès de Posix dans les années 90), de la rendre partie intégrante des contraintes d'échanges entre systèmes ouverts...
j'ai posé cette question pour savoir quoi dire à celui qui gère dl.free.fr, qui interdit un tas de caractères quand on envoie les fichiers par ftp (dont notamment l'espace),
L'espace dans les noms de fichiers est du point de vue de la portabilité une engeance, dont chaque administrateur voudrait être débarrassé autant que faire ce peu (même dans le monde Windows, où pourtant ils sont nettement plus fréquents).
Autrement dit, je sympathise avec l'administrateur de Free... et je comprend bien ton insistance !
Antoine
Jo Engo
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas écrivait :
> bonjour :-) > > > en fait, pour commencer, > est ce que la norme UNIX donne une liste de caractères autorisés > dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
-- Tous les paranoïaques me persécutent (Umberto Eco)
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait :
> bonjour :-)
>
>
> en fait, pour commencer,
> est ce que la norme UNIX donne une liste de caractères autorisés
> dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash
~/tests$ ls -l
total 0
-rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Après si on veut que ce soit utilisable, faut un peu plus
restreindre...
--
Tous les paranoïaques me persécutent (Umberto Eco)
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas écrivait :
> bonjour :-) > > > en fait, pour commencer, > est ce que la norme UNIX donne une liste de caractères autorisés > dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
-- Tous les paranoïaques me persécutent (Umberto Eco)
Alain Montfranc
Jo Engo a utilisé son clavier pour écrire :
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas écrivait :
bonjour :-)
en fait, pour commencer, est ce que la norme UNIX donne une liste de caractères autorisés dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Marche pas sur mon nunux...
Jo Engo a utilisé son clavier pour écrire :
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait :
bonjour :-)
en fait, pour commencer,
est ce que la norme UNIX donne une liste de caractères autorisés
dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash
~/tests$ ls -l
total 0
-rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas écrivait :
bonjour :-)
en fait, pour commencer, est ce que la norme UNIX donne une liste de caractères autorisés dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Marche pas sur mon nunux...
Stephane CHAZELAS
2011-09-12, 19:35(+02), Alain Montfranc:
Jo Engo a utilisé son clavier pour écrire :
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas écrivait :
bonjour :-)
en fait, pour commencer, est ce que la norme UNIX donne une liste de caractères autorisés dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Marche pas sur mon nunux...
C'est parce que tu n'as pas copy-pasté. Le / ci-dessus est un division slash (U+2215) (qui d'ailleurs n'a rien de special pour le shell non-plus, donc le "" n'est pas necessaire).
-- Stephane
2011-09-12, 19:35(+02), Alain Montfranc:
Jo Engo a utilisé son clavier pour écrire :
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait :
bonjour :-)
en fait, pour commencer,
est ce que la norme UNIX donne une liste de caractères autorisés
dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash
~/tests$ ls -l
total 0
-rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Marche pas sur mon nunux...
C'est parce que tu n'as pas copy-pasté. Le / ci-dessus est un
division slash (U+2215) (qui d'ailleurs n'a rien de special pour
le shell non-plus, donc le "" n'est pas necessaire).
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
Thomas écrivait :
bonjour :-)
en fait, pour commencer, est ce que la norme UNIX donne une liste de caractères autorisés dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Marche pas sur mon nunux...
C'est parce que tu n'as pas copy-pasté. Le / ci-dessus est un division slash (U+2215) (qui d'ailleurs n'a rien de special pour le shell non-plus, donc le "" n'est pas necessaire).
-- Stephane
Stephane CHAZELAS
2011-09-13, 11:00(+02), Antoine Leca:
Jo Engo écrivit :
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
est ce que la norme UNIX donne une liste de caractères autorisés dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Et ?
La question était, « norme [...] autoris[e] ». La norme n'autorisant pas /, Erwan est fondé dans sa réponse.
La norme autorise u2215 (division slash) en utf8 puisque la sequence d'octet correspondante ne contient ni ASCII NUL (0) ni ASCII SLASH (0x2F). ∕
Tu aurais plus de poids si tu montrais un cas où une machine certifiée n'autorisait pas un caractère (en dehors de et /)
[...]
Attention de ne pas confondre caractère et byte dans ce contexte. Par exemple, on peut concevoir un character encoding (par exemple UTF16/UCS2) ou certains caracteres contiennent les bytes 0 ou 0x2F et ces caracteres poseraient probleme aussi.
-- Stephane
2011-09-13, 11:00(+02), Antoine Leca:
Jo Engo écrivit :
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
est ce que la norme UNIX donne une liste de caractères autorisés
dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash
~/tests$ ls -l
total 0
-rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Et ?
La question était, « norme [...] autoris[e] ». La norme n'autorisant pas
/, Erwan est fondé dans sa réponse.
La norme autorise u2215 (division slash) en utf8 puisque la
sequence d'octet correspondante ne contient ni ASCII NUL (0) ni
ASCII SLASH (0x2F).
∕
Tu aurais plus de poids si tu montrais un cas où une machine certifiée
n'autorisait pas un caractère (en dehors de et /)
[...]
Attention de ne pas confondre caractère et byte dans ce
contexte. Par exemple, on peut concevoir un character encoding
(par exemple UTF16/UCS2) ou certains caracteres contiennent les
bytes 0 ou 0x2F et ces caracteres poseraient probleme aussi.
Un lundi de 2011, Erwan (David) dans fr.comp.os.unix :
est ce que la norme UNIX donne une liste de caractères autorisés dans les noms de fichiers, et/ou une liste de caractères interdits ?
Tout est autorisé sauf 0 et /
~/tests$ touch ∕slash ~/tests$ ls -l total 0 -rw-r--r-- 1 yjml yjml 0 12 sept. 18:47 ∕slash
Et ?
La question était, « norme [...] autoris[e] ». La norme n'autorisant pas /, Erwan est fondé dans sa réponse.
La norme autorise u2215 (division slash) en utf8 puisque la sequence d'octet correspondante ne contient ni ASCII NUL (0) ni ASCII SLASH (0x2F). ∕
Tu aurais plus de poids si tu montrais un cas où une machine certifiée n'autorisait pas un caractère (en dehors de et /)
[...]
Attention de ne pas confondre caractère et byte dans ce contexte. Par exemple, on peut concevoir un character encoding (par exemple UTF16/UCS2) ou certains caracteres contiennent les bytes 0 ou 0x2F et ces caracteres poseraient probleme aussi.
-- Stephane
Antoine Leca
Stephane CHAZELAS écrivit :
Attention de ne pas confondre caractère et byte dans ce
Oui
contexte. Par exemple, on peut concevoir un character encoding (par exemple UTF16/UCS2) ou certains caracteres contiennent les bytes 0 ou 0x2F et ces caracteres poseraient probleme aussi.
Non, pas de problème si on ne confond pas. Certaines implémentations de la norme Posix-90 utilisent justement cet encodage pour les caractères, et bien que les noms de fichiers contiennent les octets 0 ou 0x2F, cela ne pose pas de problème, c'est le travail de l'implémentation de faire le tri.
Depuis la norme de 2001 le problème ne se pose plus, car cette révision force les caractères à être codés sur une base de 8 bits (CHAR_BIT==8), en utilisant éventuellement les multiplets (pour être compatible avec l'interface de programmation réseau, sockets et compagnie). Donc les encodages genre UTF-16 ne sont plus valides au niveau de l'interface de programmation, il faut recoder par exemple en UTF-8 (comme dans le message de « Jo Engo ») ou en UCN (comme dans les tiens). Et là on voit bien qu'il n'y a plus de problème :^)
Antoine
Stephane CHAZELAS écrivit :
Attention de ne pas confondre caractère et byte dans ce
Oui
contexte. Par exemple, on peut concevoir un character encoding
(par exemple UTF16/UCS2) ou certains caracteres contiennent les
bytes 0 ou 0x2F et ces caracteres poseraient probleme aussi.
Non, pas de problème si on ne confond pas.
Certaines implémentations de la norme Posix-90 utilisent justement cet
encodage pour les caractères, et bien que les noms de fichiers
contiennent les octets 0 ou 0x2F, cela ne pose pas de problème, c'est le
travail de l'implémentation de faire le tri.
Depuis la norme de 2001 le problème ne se pose plus, car cette révision
force les caractères à être codés sur une base de 8 bits (CHAR_BIT==8),
en utilisant éventuellement les multiplets (pour être compatible avec
l'interface de programmation réseau, sockets et compagnie).
Donc les encodages genre UTF-16 ne sont plus valides au niveau de
l'interface de programmation, il faut recoder par exemple en UTF-8
(comme dans le message de « Jo Engo ») ou en UCN (comme dans les tiens).
Et là on voit bien qu'il n'y a plus de problème :^)
Attention de ne pas confondre caractère et byte dans ce
Oui
contexte. Par exemple, on peut concevoir un character encoding (par exemple UTF16/UCS2) ou certains caracteres contiennent les bytes 0 ou 0x2F et ces caracteres poseraient probleme aussi.
Non, pas de problème si on ne confond pas. Certaines implémentations de la norme Posix-90 utilisent justement cet encodage pour les caractères, et bien que les noms de fichiers contiennent les octets 0 ou 0x2F, cela ne pose pas de problème, c'est le travail de l'implémentation de faire le tri.
Depuis la norme de 2001 le problème ne se pose plus, car cette révision force les caractères à être codés sur une base de 8 bits (CHAR_BIT==8), en utilisant éventuellement les multiplets (pour être compatible avec l'interface de programmation réseau, sockets et compagnie). Donc les encodages genre UTF-16 ne sont plus valides au niveau de l'interface de programmation, il faut recoder par exemple en UTF-8 (comme dans le message de « Jo Engo ») ou en UCN (comme dans les tiens). Et là on voit bien qu'il n'y a plus de problème :^)
