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 ?
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 /
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
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 /
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
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 /
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Antoine Leca
Thomas écrivit :
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 ?
La seconde option, cf. Erwan.
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26×2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _ (ne pas confondre avec le jeu portable de caractères, qui est autre chose.)
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.
Antoine
Thomas écrivit :
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 ?
La seconde option, cf. Erwan.
De plus, la norme Posix définit un jeu de caractères portable pour les
noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui
se restreint aux 26×2 lettres de l'alphabet, aux 10 chiffres et aux 3
caractères . - et _ (ne pas confondre avec le jeu portable de
caractères, qui est autre chose.)
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.
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 ?
La seconde option, cf. Erwan.
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26×2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _ (ne pas confondre avec le jeu portable de caractères, qui est autre chose.)
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.
Antoine
Thomas
In article , Erwan David wrote:
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 /
donc ça c'est la norme, merci :-)
à propos, qu'est ce que la norme dit au sujet de la possibilité de nommer un dossier en terminant son nom par "/" ?
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
"utilisable" et "restreindre", c'est totalement variable en fonction des usages, des environnements d'utilisation des logiciels, etc ? ou est ce que t'as une idée précise en disant ça, ou il y a un usage chez les developpeurs ?
In article <8739oi1xo0.fsf@nez-casse.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
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 /
donc ça c'est la norme,
merci :-)
à propos,
qu'est ce que la norme dit au sujet de la possibilité de nommer un
dossier en terminant son nom par "/" ?
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
"utilisable" et "restreindre", c'est totalement variable en fonction des
usages, des environnements d'utilisation des logiciels, etc ?
ou est ce que t'as une idée précise en disant ça, ou il y a un usage
chez les developpeurs ?
> 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 /
donc ça c'est la norme, merci :-)
à propos, qu'est ce que la norme dit au sujet de la possibilité de nommer un dossier en terminant son nom par "/" ?
Après si on veut que ce soit utilisable, faut un peu plus restreindre...
"utilisable" et "restreindre", c'est totalement variable en fonction des usages, des environnements d'utilisation des logiciels, etc ? ou est ce que t'as une idée précise en disant ça, ou il y a un usage chez les developpeurs ?
Thomas écrivit : > 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 ?
La seconde option, cf. Erwan.
vu
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _
ça fait pas lourd, quand même :-/ (même pas l'espace !)
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 /" ? genre les caractères de contrôle, ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par rapport à ceux qui seraient susceptibles de produire des noms de fichier illisibles en utf-8 ?
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
In article <ihjier$h9b$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Thomas écrivit :
> 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 ?
La seconde option, cf. Erwan.
vu
De plus, la norme Posix définit un jeu de caractères portable pour les
noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui
se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3
caractères . - et _
ça fait pas lourd, quand même :-/
(même pas l'espace !)
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 /" ?
genre les caractères de contrôle,
ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par
rapport à ceux qui seraient susceptibles de produire des noms de fichier
illisibles en utf-8 ?
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
Thomas écrivit : > 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 ?
La seconde option, cf. Erwan.
vu
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _
ça fait pas lourd, quand même :-/ (même pas l'espace !)
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 /" ? genre les caractères de contrôle, ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par rapport à ceux qui seraient susceptibles de produire des noms de fichier illisibles en utf-8 ?
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
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.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
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.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
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.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Erwan David
Thomas écrivait :
In article <ihjier$h9b$, Antoine Leca wrote:
Thomas écrivit : > 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 ?
La seconde option, cf. Erwan.
vu
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _
ça fait pas lourd, quand même :-/ (même pas l'espace !)
Si ton fichier est manipulé par des scripts, l'espace est un risque...
[...]
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 /" ? genre les caractères de contrôle, ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par rapport à ceux qui seraient susceptibles de produire des noms de fichier illisibles en utf-8 ?
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait :
In article <ihjier$h9b$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Thomas écrivit :
> 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 ?
La seconde option, cf. Erwan.
vu
De plus, la norme Posix définit un jeu de caractères portable pour les
noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui
se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3
caractères . - et _
ça fait pas lourd, quand même :-/
(même pas l'espace !)
Si ton fichier est manipulé par des scripts, l'espace est un risque...
[...]
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 /" ?
genre les caractères de contrôle,
ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par
rapport à ceux qui seraient susceptibles de produire des noms de fichier
illisibles en utf-8 ?
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Thomas écrivit : > 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 ?
La seconde option, cf. Erwan.
vu
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _
ça fait pas lourd, quand même :-/ (même pas l'espace !)
Si ton fichier est manipulé par des scripts, l'espace est un risque...
[...]
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 /" ? genre les caractères de contrôle, ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par rapport à ceux qui seraient susceptibles de produire des noms de fichier illisibles en utf-8 ?
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Tonton Th
On 01/26/2011 03:46 AM, Thomas wrote:
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _
ça fait pas lourd, quand même :-/ (même pas l'espace !)
Surtout _pas_ l'espace !
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 01/26/2011 03:46 AM, Thomas wrote:
De plus, la norme Posix définit un jeu de caractères portable pour les
noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui
se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3
caractères . - et _
ça fait pas lourd, quand même :-/
(même pas l'espace !)
Surtout _pas_ l'espace !
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
De plus, la norme Posix définit un jeu de caractères portable pour les noms de fichiers [Posix:2009 : vol.1 3.276; Posix:2003 : XBD 3.276], qui se restreint aux 26*2 lettres de l'alphabet, aux 10 chiffres et aux 3 caractères . - et _
ça fait pas lourd, quand même :-/ (même pas l'espace !)
Surtout _pas_ l'espace !
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Thomas
In article , Erwan David wrote:
Thomas écrivait :
> 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 /" ? > genre les caractères de contrôle, > ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par > rapport à ceux qui seraient susceptibles de produire des noms de fichier > illisibles en utf-8 ?
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
amha, raison de plus pour avoir des recommandations officielles sur la meilleure façon de faire
In article <87y668nol7.fsf@nez-casse.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait :
> 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 /" ?
> genre les caractères de contrôle,
> ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par
> rapport à ceux qui seraient susceptibles de produire des noms de fichier
> illisibles en utf-8 ?
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
amha, raison de plus pour avoir des recommandations officielles sur la
meilleure façon de faire
> 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 /" ? > genre les caractères de contrôle, > ou qqch qui régulerais les fs qui utilisent uniquement utf-8, par > rapport à ceux qui seraient susceptibles de produire des noms de fichier > illisibles en utf-8 ?
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
amha, raison de plus pour avoir des recommandations officielles sur la meilleure façon de faire
À (at) Wed, 26 Jan 2011 17:37:52 +0100, Thomas écrivait (wrote):
In article , Erwan David wrote:
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
amha, raison de plus pour avoir des recommandations officielles sur la meilleure façon de faire
c'est quoi ces 2 formes d'UTF-8 ?
En UTF-8, le caractère 'à' peut être représenté par le caractère 'à' lui-même (LATIN SMALL LETTER A WITH GRAVE) ou via les deux caractères 'a' et '`' (LATIN SMALL LETTER A + COMBINING GRAVE ACCENT).
On peut appeler la première méthode "représentation composée" et la seconde "représentation décomposée".
Les séquences d'octets résutantes ne sont évidement pas identiques.
Il se trouve que Linux et Windows ont choisi la représentation composée (le caractère 'à' lui-même) alors que Mac OS X a choisi le représentation décomposée (un 'a' suivi d'un accent combinant).
Il se trouve aussi que Linux comme Windows accepte de lire les noms de fichiers avec représentation décomposée mais que Mac OS X n'accepte pas les noms de fichiers avec représentation composée.
Résultat des courses : on peut lire une partition NTFS sur Mac OS X grâce à Fuse mais des fichiers dont les noms contiennent des accents et crées par Linux ou Windows ne sont pas reconnus. À l'inverse, un Linux ou un Windows pourra lire des fichiers avec accents créés par Mac OS X mais si ils sont copiés (ou juste renommé), ils ne seront plus reconnus par Mac OS X.
Le plus éotnnant, c'est qu'en passant par les couches basses des OS, on peut tout faire (jusqu'à utiliser des suites d'octets invalides en UTF-8 - on retombe sur la limite tout sauf / et 0) : ce ne sont donc pas des limites des noyaux ou des file systems. Ce sont juste des limites des interfaces (graphiques ou non) au-dessus.
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 !
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 26 Jan 2011 17:37:52 +0100,
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait (wrote):
In article <87y668nol7.fsf@nez-casse.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
amha, raison de plus pour avoir des recommandations officielles sur la
meilleure façon de faire
c'est quoi ces 2 formes d'UTF-8 ?
En UTF-8, le caractère 'à' peut être représenté par le caractère 'à'
lui-même (LATIN SMALL LETTER A WITH GRAVE) ou via les deux caractères
'a' et '`' (LATIN SMALL LETTER A + COMBINING GRAVE ACCENT).
On peut appeler la première méthode "représentation composée" et la
seconde "représentation décomposée".
Les séquences d'octets résutantes ne sont évidement pas identiques.
Il se trouve que Linux et Windows ont choisi la représentation composée
(le caractère 'à' lui-même) alors que Mac OS X a choisi le
représentation décomposée (un 'a' suivi d'un accent combinant).
Il se trouve aussi que Linux comme Windows accepte de lire les noms de
fichiers avec représentation décomposée mais que Mac OS X n'accepte pas
les noms de fichiers avec représentation composée.
Résultat des courses : on peut lire une partition NTFS sur Mac OS X
grâce à Fuse mais des fichiers dont les noms contiennent des accents et
crées par Linux ou Windows ne sont pas reconnus. À l'inverse, un Linux
ou un Windows pourra lire des fichiers avec accents créés par Mac OS X
mais si ils sont copiés (ou juste renommé), ils ne seront plus reconnus
par Mac OS X.
Le plus éotnnant, c'est qu'en passant par les couches basses des OS, on
peut tout faire (jusqu'à utiliser des suites d'octets invalides en UTF-8
- on retombe sur la limite tout sauf / et 0) : ce ne sont donc pas des
limites des noyaux ou des file systems. Ce sont juste des limites des
interfaces (graphiques ou non) au-dessus.
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 !
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 26 Jan 2011 17:37:52 +0100, Thomas écrivait (wrote):
In article , Erwan David wrote:
UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
Là encore on tombe sur un problème.
amha, raison de plus pour avoir des recommandations officielles sur la meilleure façon de faire
c'est quoi ces 2 formes d'UTF-8 ?
En UTF-8, le caractère 'à' peut être représenté par le caractère 'à' lui-même (LATIN SMALL LETTER A WITH GRAVE) ou via les deux caractères 'a' et '`' (LATIN SMALL LETTER A + COMBINING GRAVE ACCENT).
On peut appeler la première méthode "représentation composée" et la seconde "représentation décomposée".
Les séquences d'octets résutantes ne sont évidement pas identiques.
Il se trouve que Linux et Windows ont choisi la représentation composée (le caractère 'à' lui-même) alors que Mac OS X a choisi le représentation décomposée (un 'a' suivi d'un accent combinant).
Il se trouve aussi que Linux comme Windows accepte de lire les noms de fichiers avec représentation décomposée mais que Mac OS X n'accepte pas les noms de fichiers avec représentation composée.
Résultat des courses : on peut lire une partition NTFS sur Mac OS X grâce à Fuse mais des fichiers dont les noms contiennent des accents et crées par Linux ou Windows ne sont pas reconnus. À l'inverse, un Linux ou un Windows pourra lire des fichiers avec accents créés par Mac OS X mais si ils sont copiés (ou juste renommé), ils ne seront plus reconnus par Mac OS X.
Le plus éotnnant, c'est qu'en passant par les couches basses des OS, on peut tout faire (jusqu'à utiliser des suites d'octets invalides en UTF-8 - on retombe sur la limite tout sauf / et 0) : ce ne sont donc pas des limites des noyaux ou des file systems. Ce sont juste des limites des interfaces (graphiques ou non) au-dessus.
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 !
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Thomas
In article , Paul Gaborit wrote:
À (at) Wed, 26 Jan 2011 17:37:52 +0100, Thomas écrivait (wrote):
> In article , > Erwan David wrote: > >> >> UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ? >> >> Là encore on tombe sur un problème. > > amha, raison de plus pour avoir des recommandations officielles sur la > meilleure façon de faire > > c'est quoi ces 2 formes d'UTF-8 ?
En UTF-8, le caractère 'à' peut être représenté par le caractère 'à' lui-même (LATIN SMALL LETTER A WITH GRAVE) ou via les deux caractères 'a' et '`' (LATIN SMALL LETTER A + COMBINING GRAVE ACCENT).
On peut appeler la première méthode "représentation composée" et la seconde "représentation décomposée".
Les séquences d'octets résutantes ne sont évidement pas identiques.
merci pour les détails :-)
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 !
In article <wt9zkqn1tit.fsf@enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Wed, 26 Jan 2011 17:37:52 +0100,
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait (wrote):
> In article <87y668nol7.fsf@nez-casse.rail.eu.org>,
> Erwan David <erwan@rail.eu.org> wrote:
>
>>
>> UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ?
>>
>> Là encore on tombe sur un problème.
>
> amha, raison de plus pour avoir des recommandations officielles sur la
> meilleure façon de faire
>
> c'est quoi ces 2 formes d'UTF-8 ?
En UTF-8, le caractère 'à' peut être représenté par le caractère 'à'
lui-même (LATIN SMALL LETTER A WITH GRAVE) ou via les deux caractères
'a' et '`' (LATIN SMALL LETTER A + COMBINING GRAVE ACCENT).
On peut appeler la première méthode "représentation composée" et la
seconde "représentation décomposée".
Les séquences d'octets résutantes ne sont évidement pas identiques.
merci pour les détails :-)
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 !
À (at) Wed, 26 Jan 2011 17:37:52 +0100, Thomas écrivait (wrote):
> In article , > Erwan David wrote: > >> >> UTF-8 en forme normale composée (linux, FreeBSD) ou décomposée (Apple) ? >> >> Là encore on tombe sur un problème. > > amha, raison de plus pour avoir des recommandations officielles sur la > meilleure façon de faire > > c'est quoi ces 2 formes d'UTF-8 ?
En UTF-8, le caractère 'à' peut être représenté par le caractère 'à' lui-même (LATIN SMALL LETTER A WITH GRAVE) ou via les deux caractères 'a' et '`' (LATIN SMALL LETTER A + COMBINING GRAVE ACCENT).
On peut appeler la première méthode "représentation composée" et la seconde "représentation décomposée".
Les séquences d'octets résutantes ne sont évidement pas identiques.
merci pour les détails :-)
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 !
