> J'imagine que l'encodage du nom du fichier n'est pas precise
Juste. Le noyau n'a aucune contrainte sauf une. Le nom du fichier doit se terminer par (char)'0' (doit être un "char *"). Pas un (int)0 ou (int16)0. D'où l'utilisation de utf8 qui respecte ça. utf8, ucs, utf16, utf32 c'est le même charset, c'est unicode. Mais c'est différente façon de représenter unicode. utf8 est compact et compatible "char *".
> En fait, ce qu'il faudrait, c'est des metadata pour preciser l'encodage du nom...
Ce qui est une erreur.
Premièrement, le noyau ne ferait rien de ça.
Deuxièmement les applis ne ferait rien de ça aussi. Sauf lors de l'affichage.
Troisièmement, tar/cpio/etc se stockent pas les attributs étendus. iso9660 n'a pas d'attribut étendu, etc.
Et pourquoi pas ajouter le codage du document aussi ?
Et pourquoi pas ajouter le type mime ?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 1.
Juste. Le noyau n'a aucune contrainte sauf une. Le nom du fichier doit se terminer par (char)'0' (doit être un "char *"). Pas un (int)0 ou (int16)0. D'où l'utilisation de utf8 qui respecte ça. utf8, ucs, utf16, utf32 c'est le même charset, c'est unicode. Mais c'est différente façon de représenter unicode. utf8 est compact et compatible "char *".
> En fait, ce qu'il faudrait, c'est des metadata pour preciser l'encodage du nom...
Ce qui est une erreur.
Premièrement, le noyau ne ferait rien de ça.
Deuxièmement les applis ne ferait rien de ça aussi. Sauf lors de l'affichage.
Troisièmement, tar/cpio/etc se stockent pas les attributs étendus. iso9660 n'a pas d'attribut étendu, etc.
Et pourquoi pas ajouter le codage du document aussi ?
Et pourquoi pas ajouter le type mime ?
Bref, c'est une erreur de faire ça.