Linux? - Page 106

L'utilisation d'une normalisation pour les comparaisons n'est qu'un "should" et pas un "must".

Oui, tu n'es pas obligé de normaliser pour comparer, mais tu dois quand même donner la bonne réponse Simplement, passer par une normalisation préalable est une méthode possible pour simplifier le boulot...

D'après wikipedia :
The implementation of Unicode string searches and comparisons in text processing software *must* take into account the presence of equivalent code points. In the absence of this feature, users searching for a particular code point sequence would be unable to find other visually indistinguishable glyphs that have a different, but canonically equivalent, code point representation.

Ce qui est la moindre des choses, vu que ce sont simplement des *représentations* différentes du *même* caractère unicode.

t'as qu'à utiliser java pour trier tes fichiers bizarres. au moins, lui, il supporte l'unicode correctement

Unicode est quand même vraiment une unsine à gaz merdique à base de compromis foireux. C'est dommage, l'idée n'était pas mauvaise au départ, mais la mise en œuvre...

Plan9 met tres bien l'UTF8/Unicode en oeuvre

(page précédente Pas de dual boot d'un même système d'exploitation?? Non mais on rêve, là!

Je ne comprends pas le débat en cours ?
Pour la question de l'encodage pour son résultat Apache, pourquoi Flan n'utilise pas systématiquement UTF-8 NFC, vu que c'est la norme en vigueur sur son système ?

Si une application crée des fichiers avec d'autres normes, c'est un bug et il suffit de soumettre un rapport de bug, non ?

pas besoin de ça, c'est juste qu'on peut, alors il essaye (je peux comprendre )

Yoshi Noir (./3128) :

Kevin Kofler (./3126) :

Yoshi Noir (./3124) :
Il a été créé assez récemment, et j'avais uniquement un Live CD 10.10 : http://forum.ubuntu-fr.org/viewtopic.php?pid=4725991 (mai 2011)
Cela dit, YannUbuntu mérite un prout d'or pour avoir transformé quelque chose de trivial en quelque chose de contraignant

Et tu mérites le prout de platine (PEBKAC!) pour ne pas avoir cherché plus loin et trouvé la solution d'une ligne.

Et l'idée ne t'a pas effleuré que d'une part, « boot-repair », c'est la réponse que j'obtiens en premier lieu via Google et que d'autre part, mes connaissances en Linux ne peuvent être aussi étendues que les tiennes et que d'autre part encore, j'ai essayé la commande « grub-install » sans succès ? Parle de respect envers les utilisateurs après cette sortie !

J'ai eu un problème équivalent avec des machines qui bootaient en UEFI et avec des disques partitionnées en GPT. Ni Boot-repair, ni un "grub-install" n'ont réglé le problème.
Le Grub a corrompu la partition en fat de 200Mo qui se trouve au début du disque. Seule solution viable, enlever le flag "boot" de cette partition et en créer une autre à côté avec ce même flag actif. Ainsi le grub écrira dans celui-là et laisserai tranquille le Windows Boot Manager sans tout foutre en l'air. Hum... Je ne sais pas si je suis très clair...

Godzil (./3155) :
Plan9 met tres bien l'UTF8/Unicode en oeuvre

Je ne parle pas de la mise en œuvre d'Unicode par les différents logiciels, je parle des divers standards Unicode en tant que mise en œuvre des idées de départ ^^

spectras (./3157) :
Je ne comprends pas le débat en cours ?
Pour la question de l'encodage pour son résultat Apache, pourquoi Flan n'utilise pas systématiquement UTF-8 NFC, vu que c'est la norme en vigueur sur son système ?

Si une application crée des fichiers avec d'autres normes, c'est un bug et il suffit de soumettre un rapport de bug, non ?

Tu es en train dire que la superbe feature permettant d'avoir un encodage différent pour chaque nom de fichier est un bug quand on s'en sert ?

Et que tu proposes d'avoir des fichiers qui vont devenir inutilisables par simple mise à jour d'une partie des logiciels parce que le nom sera devenu illisible ?
C'est vrai, c'est beaucoup plus pratique de devoir mettre à jour tous les noms de fichiers et tous les logiciels quand un nouvel encodage sort, plutôt que de simplement reformater la partition si tu veux vraiment en tirer partie.


Au passage, est-ce que ça te parle, les notions de disques amovibles, multi-boot, disques réseau, multi-utilisateur ? Je sais que ce sont des trucs assez peu utilisés, mais qui sont autant d'occasions d'avoir des encodages différents.

Curieusement, je ne suis pas sûr que tu aurais tenu le même discours s'il s'était agi de Windows…

Sally (./3160) :
Je ne parle pas de la mise en œuvre d'Unicode par les différents logiciels, je parle des divers standards Unicode en tant que mise en œuvre des idées de départ ^^

Oh, il y a quand même pas mal de bonnes idées Les deux décompositions, par exemple, c'est souvent bien pratique — quand on a un vrai OS sachant gérer l'Unicode.

Ouh là, je vais pas si loin. Je demandais simplement pourquoi, sachant que la plateforme utilise un standard, tu n'utilisais pas simplement ce standard.
C'est vrai que ça sera pas compatible avec d'autres standards, mais est-ce que tu prévois vraiment de supporter d'autres standards ? Par exemple si tu prends un disque amovible dont les noms sont encodés, en CP1047 ou Windows-1251, ça marcherait ? Et quid des caractères Unicode supérieurs à 65535 ?

Accessoirement, Windows a le même problème quand tu traites des caractères non latins : tu peux créer un fichier ?.txt et ?.txt dans le même répertoire, alors qu'il est supposé être insensible à la casse.
Tu peux également faire créer un fichier [U+DC01][U+D801].txt avec CreateFile, alors que c'est supposé être interdit (caractère illégal).

En fait le problème viens du FS qui accepte n'importe quoi comme type de codage de chaine, alors qu'il devrait le forcer et c'est le VFS qui devrait faire la conversion. C'est ce qui se passe avec le NTFS, et le HFS, le codage est forcé au niveau du FS, et si on utilise plusieurs locale, c'est le VFS qui traduit!

./2783>
En fait Flanker, ce qui est très drole, c'est que si tu lances le petit script sous Windows 7, t'as le même résultat que sous GNU/Linux.
Windows ne fait pas davantage de normalisation, et donne la même explication :

the file system treats path and file names as an opaque sequence of WCHARs— MSDN

Je crois que ça met fin au troll. Retour à la question : comment tu fais pour gérer ça.
(il existe des utilitaires capables de normaliser récursivement tous les noms d'un dossier, ça peut être une piste)

Je dois être trop habitué aux OS modernes, alors ^^

-os modernes +osx?

(sérieux, ça me semble quand même être la moindre des choses de ne pas avoir à se préoccuper de l'encodage des noms de fichiers…)

non mais ok mais t'as des idées tordues à la base, en voulant pas faire la normalisation normale de monsieur tout le monde

comment t'es tombé dessus en fait?

squalyl (./3168) :
non mais ok mais t'as des idées tordues à la base, en voulant pas faire la normalisation normale de monsieur tout le monde

comment t'es tombé dessus en fait?

En jouant avec mod_xsendfile (*), qui demande d'ajouter aux headers de ta réponse HTTP le chemin du fichier à envoyer, fichier qui comportait des accents.

Je ne sais pas pourquoi, quand j'ai fait un ma_string_unicode.encode('utf-8') — ce qui encode en UTF-8 mais sans choisir de normalisation particulière —, ça n'a pas fonctionné. J'ai donc essayé NFD et NFC pour trouver la bonne méthode.



(*) C'est un module d'Apache bien sympa quand c'est un script PHP/Python/... qui envoie un fichier : normalement, c'est ton script qui lit le fichier et qui l'écrit sur la sortie standard. Avec mod_xsendfile, tu mets le chemin absolu dans l'en-tête HTTP, et c'est Apache qui lit le fichier (donc plus rapide qu'en PHP/Python/..., consomme moins de mémoire, etc.), tout en permettant un contrôle super fin sur les droits d'accès.

Moui, enfin OSX a parfois un comportement chelou avec sa gestion des fichiers, par exemple si tu crées une archive tar sans avoir préalablement défini une variable d'environnement obscure (il s'agit donc d'un comportement par défaut) il la remplit de fichiers vides avec des noms commençant par ._, c'est vachement pratique . Donc ouais ok ils gèrent bien les noms unicode mais ils ont d'autres progrès à faire sur la gestion des fichiers...

flanker (./3167) :
(sérieux, ça me semble quand même être la moindre des choses de ne pas avoir à se préoccuper de l'encodage des noms de fichiers…)

En fait je ne comprends pas bien le "troll", que le noyau ou le VFS veuille gérer ça sous forme de séquences de byte[] ce n'est pas bête (il n'en sait rien à priori, un nom c'est générique). Après il me semble que le filesystem lui-même devrait choisir un encodage et s'y tenir, en garantissant qu'un fichier, qu'il soit désigné par "chié" ou "chi´e" soit accessible de la même manière.

Bin oui, on est donc d'accord ^^

tsoin tsoin

La normalisation de OS X sux aussi parce que c'est de la NFD alors que le reste du monde utilise la NFC. (Ça doit être de là aussi que vient ce problème:

flanker (./3169) :
Je ne sais pas pourquoi, quand j'ai fait un ma_string_unicode.encode('utf-8') — ce qui encode en UTF-8 mais sans choisir de normalisation particulière —, ça n'a pas fonctionné. J'ai donc essayé NFD et NFC pour trouver la bonne méthode.

– fichier créé par OS X et donc en la mauvaise normalisation?)

Bin d'après l'expérience de Flanker, au contraire, seul os x a un comportement correct vis-à-vis du nommage des fichiers.

Ok, alors effectivement c'est bizarre que le FS ne soit pas fichu de garantir ça. Mais quand on dit OS X ce n'est que le HFS qui fait ça correctement ?