si je crée "à la main" au terminal, une dir (ou un fichier) contenant
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
y aurait'il une lib de "wstat" (stat en wchar_t) ???
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
si je crée "à la main" au terminal, une dir (ou un fichier) contenant
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
y aurait'il une lib de "wstat" (stat en wchar_t) ???
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
si je crée "à la main" au terminal, une dir (ou un fichier) contenant
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
y aurait'il une lib de "wstat" (stat en wchar_t) ???
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
si je crée "à la main" au terminal, une dir (ou un fichier) contenant
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
j'imagine comme en entrée du stat c'est un char * qui est demandé, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
y aurait'il une lib de "wstat" (stat en wchar_t) ???
si je crée "à la main" au terminal, une dir (ou un fichier) contenant
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
j'imagine comme en entrée du stat c'est un char * qui est demandé, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
y aurait'il une lib de "wstat" (stat en wchar_t) ???
si je crée "à la main" au terminal, une dir (ou un fichier) contenant
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
j'imagine comme en entrée du stat c'est un char * qui est demandé, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
y aurait'il une lib de "wstat" (stat en wchar_t) ???
Aujourd'hui, il est considéré comme raisonnable de tout passer en
UTF-8
(ie. locale bloquée sur UTF-8 au niveau système) pour justement éviter
les petits problèmes de manipulation de fichiers dont on ne peut pas
"voir" le nom :p
Aujourd'hui, il est considéré comme raisonnable de tout passer en
UTF-8
(ie. locale bloquée sur UTF-8 au niveau système) pour justement éviter
les petits problèmes de manipulation de fichiers dont on ne peut pas
"voir" le nom :p
Aujourd'hui, il est considéré comme raisonnable de tout passer en
UTF-8
(ie. locale bloquée sur UTF-8 au niveau système) pour justement éviter
les petits problèmes de manipulation de fichiers dont on ne peut pas
"voir" le nom :p
Bloquer un local sur UTF-8 au niveau du système est problématique, car
il y a des séquences UTF-8 illégales
De plus, quand on monte des volumes amovibles ou quand on transfer des
fichiers via Internet, on peut se retrouver avec des noms utilisant
des encodages différents dans le même système.
Bloquer un local sur UTF-8 au niveau du système est problématique, car
il y a des séquences UTF-8 illégales
De plus, quand on monte des volumes amovibles ou quand on transfer des
fichiers via Internet, on peut se retrouver avec des noms utilisant
des encodages différents dans le même système.
Bloquer un local sur UTF-8 au niveau du système est problématique, car
il y a des séquences UTF-8 illégales
De plus, quand on monte des volumes amovibles ou quand on transfer des
fichiers via Internet, on peut se retrouver avec des noms utilisant
des encodages différents dans le même système.
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Un open() avec une chaîne invalide renvoi donc un code d'erreur ?
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Un open() avec une chaîne invalide renvoi donc un code d'erreur ?
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Un open() avec une chaîne invalide renvoi donc un code d'erreur ?
Le 14/08/07 15:35, dans <f9sb37$5ai$, « Xavier Roche »
a écrit :Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Le 14/08/07 15:35, dans <f9sb37$5ai$1@news.httrack.net>, « Xavier Roche »
<xroche@free.fr.NOSPAM.invalid> a écrit :
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Le 14/08/07 15:35, dans <f9sb37$5ai$, « Xavier Roche »
a écrit :Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
unbewust writes:si je crée "à la main" au terminal, une dir (ou un fichier) contena nt
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
Il faut t'assurer que l'encodage utilisé par ton clavier et par le
shell soit le même que celui utilisé par le source de ton programme.j'imagine comme en entrée du stat c'est un char * qui est demandé, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
En effet. Pour un système POSIX, les chemins sont des vecteurs
d'octets, avec seulement deux valeurs spéciales:
0 qui termine le chemin.
47 qui sépare les répertoires.
Quand tu tape:
int fd=open("/tmp/myapp/tmpfile",...);
le système ne voit que:
47 116 109 112 47 109 121 97 112 112 47 116 109 112 102 105 108 101 0
Il découpe donc en trois parties:
116 109 112 109 121 97 112 112 116 109 112 102 105 108 101ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
La façon de base de s'assurer que les encodages correspond est de
régler les variables d'environnement LC_*. Par exemple:
LC_CTYPE=fr_FR.UTF-8
export LC_CTYPE
Mais il faut aussi configurer son terminal pour qu'il envoit les
caractères accentués dans l'encodage indiqué, et pour qu'il les
affiche correctement. Il faut aussi configurer son éditeur pour qu'il
utilise ce même encodage. Avec emacs, on peut simplement mettre un
commentaire sur la première ligne, comme:
/* -*- coding:utf-8 -*- */
Aussi, avec UTF-8 il y a un piège. Si un programme travaille
simplement avec une séquence d'octet, il pourra sembler fonctionner
avec une séquence encodée en UTF-8, mais sans se rendre compte des
caractères unicodes. Le même problème peut aussi se produire avec
d'autres couples d'encodage (eg ISO-8859-2 avec ISO-8859-1, etc).
Alors on peut avoir l'impression que ça marche alors que ça ne marche
pas. Heureusement, dans ton cas, tu t'es rendu compte que ça ne
marchait pas.y aurait'il une lib de "wstat" (stat en wchar_t) ???
Tu n'aurais besoin d'utiliser les fonctions d'encodage/décodage wchar
que si le source du programme n'utilisait pas le même encodage que le
reste. (Ou si tu veux pouvoir travailler avec plusieurs encodages
différents).
Je ne sais pas s'il y a déjà une telle bibliothèque,
mais c'est vraiment trivial d'écrire ces fonctions qui combinent
seulement deux fonctions...
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
unbewust <yvon.thora...@gmail.com> writes:
si je crée "à la main" au terminal, une dir (ou un fichier) contena nt
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
Il faut t'assurer que l'encodage utilisé par ton clavier et par le
shell soit le même que celui utilisé par le source de ton programme.
j'imagine comme en entrée du stat c'est un char * qui est demandé, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
En effet. Pour un système POSIX, les chemins sont des vecteurs
d'octets, avec seulement deux valeurs spéciales:
0 qui termine le chemin.
47 qui sépare les répertoires.
Quand tu tape:
int fd=open("/tmp/myapp/tmpfile",...);
le système ne voit que:
47 116 109 112 47 109 121 97 112 112 47 116 109 112 102 105 108 101 0
Il découpe donc en trois parties:
116 109 112 109 121 97 112 112 116 109 112 102 105 108 101
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
La façon de base de s'assurer que les encodages correspond est de
régler les variables d'environnement LC_*. Par exemple:
LC_CTYPE=fr_FR.UTF-8
export LC_CTYPE
Mais il faut aussi configurer son terminal pour qu'il envoit les
caractères accentués dans l'encodage indiqué, et pour qu'il les
affiche correctement. Il faut aussi configurer son éditeur pour qu'il
utilise ce même encodage. Avec emacs, on peut simplement mettre un
commentaire sur la première ligne, comme:
/* -*- coding:utf-8 -*- */
Aussi, avec UTF-8 il y a un piège. Si un programme travaille
simplement avec une séquence d'octet, il pourra sembler fonctionner
avec une séquence encodée en UTF-8, mais sans se rendre compte des
caractères unicodes. Le même problème peut aussi se produire avec
d'autres couples d'encodage (eg ISO-8859-2 avec ISO-8859-1, etc).
Alors on peut avoir l'impression que ça marche alors que ça ne marche
pas. Heureusement, dans ton cas, tu t'es rendu compte que ça ne
marchait pas.
y aurait'il une lib de "wstat" (stat en wchar_t) ???
Tu n'aurais besoin d'utiliser les fonctions d'encodage/décodage wchar
que si le source du programme n'utilisait pas le même encodage que le
reste. (Ou si tu veux pouvoir travailler avec plusieurs encodages
différents).
Je ne sais pas s'il y a déjà une telle bibliothèque,
mais c'est vraiment trivial d'écrire ces fonctions qui combinent
seulement deux fonctions...
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
unbewust writes:si je crée "à la main" au terminal, une dir (ou un fichier) contena nt
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
Il faut t'assurer que l'encodage utilisé par ton clavier et par le
shell soit le même que celui utilisé par le source de ton programme.j'imagine comme en entrée du stat c'est un char * qui est demandé, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
En effet. Pour un système POSIX, les chemins sont des vecteurs
d'octets, avec seulement deux valeurs spéciales:
0 qui termine le chemin.
47 qui sépare les répertoires.
Quand tu tape:
int fd=open("/tmp/myapp/tmpfile",...);
le système ne voit que:
47 116 109 112 47 109 121 97 112 112 47 116 109 112 102 105 108 101 0
Il découpe donc en trois parties:
116 109 112 109 121 97 112 112 116 109 112 102 105 108 101ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
La façon de base de s'assurer que les encodages correspond est de
régler les variables d'environnement LC_*. Par exemple:
LC_CTYPE=fr_FR.UTF-8
export LC_CTYPE
Mais il faut aussi configurer son terminal pour qu'il envoit les
caractères accentués dans l'encodage indiqué, et pour qu'il les
affiche correctement. Il faut aussi configurer son éditeur pour qu'il
utilise ce même encodage. Avec emacs, on peut simplement mettre un
commentaire sur la première ligne, comme:
/* -*- coding:utf-8 -*- */
Aussi, avec UTF-8 il y a un piège. Si un programme travaille
simplement avec une séquence d'octet, il pourra sembler fonctionner
avec une séquence encodée en UTF-8, mais sans se rendre compte des
caractères unicodes. Le même problème peut aussi se produire avec
d'autres couples d'encodage (eg ISO-8859-2 avec ISO-8859-1, etc).
Alors on peut avoir l'impression que ça marche alors que ça ne marche
pas. Heureusement, dans ton cas, tu t'es rendu compte que ça ne
marchait pas.y aurait'il une lib de "wstat" (stat en wchar_t) ???
Tu n'aurais besoin d'utiliser les fonctions d'encodage/décodage wchar
que si le source du programme n'utilisait pas le même encodage que le
reste. (Ou si tu veux pouvoir travailler avec plusieurs encodages
différents).
Je ne sais pas s'il y a déjà une telle bibliothèque,
mais c'est vraiment trivial d'écrire ces fonctions qui combinent
seulement deux fonctions...
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.