path en Unicode et stat...

Le
unbewust
si je crée un dossier avec des caractères Unicode :

$> mkdir été

ou :

$> touch été.txt

si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui
a conçu le mdls (?)


le mdls confirme que touch et mkdir "passent" avec des caractères
unicode

mdls affiche d'ailleurs de deux maniers ce path :

été ou "e' te' "

par contre si je fais un stat dessus, stat trouve que le répertoire
comme le fichier n'existent pas, j'imagine que c'est du à une
comparaison interne (???) bien sûr pour passer l'argument du path je
suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir
wchar_t)


donc ma question, est-ce qu'il existe des fonctions telles que stat
and Co en wchar_t ??? comme il existe des fonctions pour les strings
en multi-bytes.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Eric Levenez
Le #495896
Le 14/08/07 15:08, dans

si je crée un dossier avec des caractères Unicode :

$> mkdir été

ou :

$> touch été.txt

si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui
a conçu le mdls (?)


le mdls confirme que touch et mkdir "passent" avec des caractères
unicode

mdls affiche d'ailleurs de deux maniers ce path :

été ou "e' te' "

par contre si je fais un stat dessus, stat trouve que le répertoire
comme le fichier n'existent pas, j'imagine que c'est du à une
comparaison interne (???) bien sûr pour passer l'argument du path je
suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir
wchar_t)


Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16
en un encodage ASCII ou autre ?

Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom
du fichier et donc ne pas utiliser les wchar_t.

donc ma question, est-ce qu'il existe des fonctions telles que stat
and Co en wchar_t ??? comme il existe des fonctions pour les strings
en multi-bytes.


Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.

unbewust
Le #495895
On 14 août, 16:28, Eric Levenez
Le 14/08/07 15:08, dans



si je crée un dossier avec des caractères Unicode :

$> mkdir été

ou :

$> touch été.txt

si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui
a conçu le mdls (?)

le mdls confirme que touch et mkdir "passent" avec des caractères
unicode

mdls affiche d'ailleurs de deux maniers ce path :

été ou "e' te' "

par contre si je fais un stat dessus, stat trouve que le répertoire
comme le fichier n'existent pas, j'imagine que c'est du à une
comparaison interne (???) bien sûr pour passer l'argument du path je
suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir
wchar_t)


Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16
en un encodage ASCII ou autre ?


ah non pas du tout...


Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom
du fichier et donc ne pas utiliser les wchar_t.


AH, alors là, je ne pige pas, comment ça se débrouille, mais tant
mieux, c'est plus simple.


donc ma question, est-ce qu'il existe des fonctions telles que stat
and Co en wchar_t ??? comme il existe des fonctions pour les strings
en multi-bytes.


Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.


tant mieux mais le seul truc que je ne vois pas c'est comment les
comparaisons se font...


Eric Levenez
Le #495894
Le 14/08/07 17:35, dans

On 14 août, 16:28, Eric Levenez
Le 14/08/07 15:08, dans

donc ma question, est-ce qu'il existe des fonctions telles que stat
and Co en wchar_t ??? comme il existe des fonctions pour les strings
en multi-bytes.


Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.


tant mieux mais le seul truc que je ne vois pas c'est comment les
comparaisons se font...


Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être
encodé de plusieurs manières (type et ordre des caractères d'échappement).
Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pour qu'un
caractère soit toujours codé de la même manière), et c'est seulement après
que la comparaison est faite.

qu'Apple utilise le NFD.

Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ainsi
quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open
est normalisée et comparé à l'UTF-16 interne déjà normalisé.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.



unbewust
Le #495893
On 14 août, 18:23, Eric Levenez
Le 14/08/07 17:35, dans

On 14 août, 16:28, Eric Levenez
Le 14/08/07 15:08, dans

donc ma question, est-ce qu'il existe des fonctions telles que stat
and Co en wchar_t ??? comme il existe des fonctions pour les strings
en multi-bytes.


Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.


tant mieux mais le seul truc que je ne vois pas c'est comment les
comparaisons se font...


Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être
encodé de plusieurs manières (type et ordre des caractères d'écha ppement).
Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pou r qu'un
caractère soit toujours codé de la même manière), et c'est seulem ent après
que la comparaison est faite.

qu'Apple utilise le NFD.

Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ain si
quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open
est normalisée et comparé à l'UTF-16 interne déjà normalisé.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.




oui, oui, je suis d'accord, je pense que la norme unix en ce qui
concerne l'encodage (d'après ce que j'ai lu) est UTF-8 et évite
effectivement certains pbs liés au codages multiple d'autant qu'aucun
multi-byte ne peut commence par un "0" (fin de chaine en C)

donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant
plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais
dit oui ou non que mon fichier "été.txt" existe bien...

mdls (sans doute une fonction écrite par Apple) se débriouille très
bien avec ça en tout cas.


mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement
représenté,

dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt"
quand je fais un ls -al sur le rep en question...


mais ce n'est peut-être pas le même pb...

A+

Yvon




Eric Levenez
Le #495892
Le 14/08/07 18:32, dans


oui, oui, je suis d'accord, je pense que la norme unix en ce qui
concerne l'encodage (d'après ce que j'ai lu) est UTF-8


Je ne pense pas. Lors de la certification Unix (passée par Leopard), le
fournisseur donne liste des encodage qu'il utilise. Je ne pense pas que quoi
que ce soit ne soit imposé.

et évite
effectivement certains pbs liés au codages multiple d'autant qu'aucun
multi-byte ne peut commence par un "0" (fin de chaine en C)


L'UTF-8 est très bien pour sa compatibilité mais pose énormément de
problèmes pour les séquences mal formées, qui, si elles ne sont pas bien
traitées, peuvent entraîner des plantages applicatifs, et donc des trous de
sécurité. Apple a corrigé depuis la sortie de Mac OS X 10.0 beaucoup de
problèmes là dessus.

donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant
plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais
dit oui ou non que mon fichier "été.txt" existe bien...

mdls (sans doute une fonction écrite par Apple) se débriouille très
bien avec ça en tout cas.


mdls est bien sûr l'oeuvre d'Apple car cette commande repose sur les
technologies Apple.

mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement
représenté,


Mais si, aucun problème avec Terminal. Aucune idée avec iTerm.

dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt"
quand je fais un ls -al sur le rep en question...


Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal"
pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi
laisser l'encodage de Terminal en UTF-8 bien sûr.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.

Vincent Lefevre
Le #495890
Dans l'article Eric Levenez
Le 14/08/07 18:32, dans
[...]

dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt"
quand je fais un ls -al sur le rep en question...


Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal"
pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi
laisser l'encodage de Terminal en UTF-8 bien sûr.


Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils)
qu'une option (-w) posant des problèmes de sécurité.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Eric Levenez
Le #495889
Le 15/08/07 4:03, dans Lefevre »
Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils)
qu'une option (-w) posant des problèmes de sécurité.


Le "ls" de Mac OS X n'est pas buggé, l'option -w est voulue. Et le problème
de sécurité sur l'exécution de code est vraiment limite et existe sur tout
les ls en mode raw.

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.

Patrick Stadelmann
Le #495887
In article Vincent Lefevre
qu'une option (-w) posant des problèmes de sécurité.


C'est à dire ?

Patrick
--
Patrick Stadelmann
unbewust
Le #495651
On 14 août, 18:56, Eric Levenez
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls - wal"
pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi
laisser l'encodage de Terminal en UTF-8 bien sûr.



OK, c'est bon, en fait lstat marche trè bien sur de l'UTF-8 pourvu
qu'on ne passe pas en wchar_t...


merci, A+

Yvon

unbewust
Le #495650
On 15 août, 04:03, Vincent Lefevre
Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils)
qu'une option (-w) posant des problèmes de sécurité.



c'est lequel celui-là ???

car je viens de m'apercevoir que le ls que j'utilise ne correspond pas
à celui du man...

sans doute le MAN_PATh n'est pas dans le même ordre que le PATH...

Publicité
Poster une réponse
Anonyme