Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de farvardin :
- [13/10@21:56] Amor : le Pop !
- [04/10@22:26] Le EEE se rapproche à grand pas !
- [03/10@10:28] Evolution cassé sur AMD64, comment revenir avant ?
- [06/09@22:00] (troll du vendredi) Configuration à l'envers ?
- [18/08@16:06] Speed IF : une aventure textuelle réalisée en 2 heures !
- [18/08@13:57] Gmail, ses standards, et les standards du web
- [05/08@07:07] Problèmes de window scaling ? Quelle est la meilleure solution face à cela ?
- [17/07@19:04] Créer un livre dont vous êtes le héros avec des outils libres + question sur les regex
- [15/06@20:15] "Lieux Communs", jeu d'aventure libre
- [08/04@09:05] Création commune d'un jeu d'aventure textuel basé sur le mythe de Cthulhu
- [31/03@09:59] SmultroNET, une adaptation originale de TRON
- [01/02@19:50] [ma vie] Je refuse de rentrer dans la boulangerie...
- [13/01@13:29] Radio France et ogg : cela semble terminé
- [04/01@17:55] Inde 2007, migrations importantes vers Linux
- [11/12@07:49] moteurs de jeux d'aventure (2D) sous Linux, où en est-on ?
- [08/12@17:09] du nouveau du Pacte Ecologique (Flash vs Html)
- [05/12@15:12] OpenOffice, l'adversaire numéro un de Microsoft Office 2007, avec Sophie Gautier sur O1net
- [27/10@12:32] Distributions Linux, vers un éclatement des formats de paquetages ?
- [08/08@22:40] site perso hacké à plusieurs reprises
- [02/08@21:19] Un gestionnaire de fenêtres par semaine... GPE et Opie.
je suis actuellement en train de pousser dans mon entourage pour pouvoir utiliser l'utf-8 (au lieu de l'iso-machin-trucmuche).
Les bonnes raisons pour utiliser l'utf-8 sont:
* c'est le futur (comme hurd, opensolaris et l'ipv6)
* cela me permettra de manipuler plus facilement du texte dans des langues que je ne connais pas, dont je ne soupçonne même pas l'existence et que je n'apprendrais sans doute jamais (le basque septentrional, l'indo-araméen, l'elfique sylvain, l'orque commun, le völäsperäntido...)
Les trois quatre trois gros obstacles que je rencontre dans mon argumentation sont:
* l'iso-machin-trucmuche saylargementsuffisant pour le franco-français (sans arguments c'est plus facile)
* l'utf-8 c'est pas fiable parce que cela va me mettre des caractères bizarres partout si je me gourre dans mes scripts de conversion et que je ne fais pas cela correctement.
* on trouve facilement des valseurs alors que personne ne danse l'utf-8 (eu non, pas vraiment là)
* je risque de me faire kicker sur irc si je visite des canaux intégristes (genre #linuxfr) et que je l'ouvre un peu trop.
J'imagine que je ne suis pas le premier qui se retrouve face à ce genre de problème, mais si vous avez des vrais arguments, ça m'intéresse aussi.
En fait plus sérieusement, malgré mon appel à l'aide sur des sites pointus ( http://linuxfr.org/forums/12/23500.html ), j'ai dû sauvegarder toutes mes données et réinstaller mon système, ce qui n'était pas forcément un mal puisque cela m'a permis de mieux réorganiser mes partitions (on oublie les 8 partitions de 15 Go chacune, et on n'en fait qu'une grosse à la place... c'est plus facilement gérable).
Étant donné que j'ai tout sauvegardé, et que je vais recopier toutes mes données persos, autant essayer de passer en utf-8, c'est le bon moment pour cela.
Ne vous inquiétez pas, j'ai commencé à lire en long, en large et en travers les sites à ce sujet, mais je voulais également avoir votre retour d'expérience sur le sujet, est-ce qu'il y a des programmes qui ne fonctionnent pas trop bien avec cela, des vices cachés, des pièges à éviter etc. ?
Pour les accents dans les titres de fichier, ce n'est pas trop un problème, car cela fait des années déjà que j'essaye de les éviter. Mais vu que j'utilise beaucoup de fichier texte, j'espère ne pas laisser de plume dans les conversions à l'intérieur des fichiers. Est-ce que ce n'est pas trop fastidieux de tout convertir ?
De plus j'utilise un programme (inform 6) qui ne traite pas le code source en utf-8, en ce cas cela veut dire que je ne peux pas généraliser la conversion sur tout mon système. Conseillerez-vous donc de convertir les fichiers au coup par coup, l'exemple donné restant assez isolé ?
D'autre part j'ai vu que des programmes comme gedit faisaient la conversion de manière transparente, c'est à dire que les fichiers iso-8859 sont ouverts avec le bon filtre, mais du coup on ne sait pas trop où on en est.
Pour les fichiers du genre openoffice, l'encodage ne pose pas de problème (peut-être que les données sont déjà en utf8 et reconverties à la volée suivant le système utilisé ?), sinon je voulais savoir, il me semble que mac os x est en unicode, mais je crois que windows xp ne l'est pas, qu'en est-il de vista ? (quid de solaris, *bsd ?)
Sinon si vous voulez déverser votre fiel à propos d'une mauvaise expérience avec utf-8, ou iso-trucmuche-dont-j'oublie-toujours-le-numéro, vous pouvez en profiter également...
ps : oui je sais l'unicode c'est aussi un iso, ISO 10646
> Lire le journal (53 commentaires, moyenne: 2,5).
Re:
>mais je crois que windows xp ne l'est pas, qu'en est-il de vista ? (quid
>de solaris, *bsd ?)
pour le coup, si windows est unicode depuis au moins Windows 2000. Juste il est plus utf-16 que utf-8.
Quand à utiliser un poste en utf-8 c'est bien, ça ne pose pas trop de problème.
Gérer depuis ce poste tout un ensemble de machine dont la configuration n'est pas des plus uniformes c'est une autre histoire ...
J'ai encore des soucis avec des debian/sarges dont les locales ne semblent pas compatibles avec des debian/etch et plus récent, ou
des machines non utf-8 compatible, ou il ne faut surtout pas taper de caractères non acii 7bits (sauf a être en iso) car après il est impossible de les supprimer
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
Hmm
Pour son sytème de fichier, Windows depuis 2000 (NT 4?) utilise Unicode pour les nom de fichiers de partitions NTFS/lecteurs réseau (il suffit d'utiliser Samba sur une sarge pour s'en rendre compte ou de monter une partoche ntfs sous linux)
Pour Wordpad,notepad, ca peut ouvrir de l'utf8 mais il me semble qu'il enregistre par défaut en cp 1250 ou un Windowserie du genre...
Sinon, j'ai migré en UTF8 sans trop de problemes y'a quelque mois, j'avais utilisé un script python pour la convertion des noms de fichier il me semble...
Agogo
-
[^]Re: Hmm
Posté par PiT (page perso, ) le 21/11/2007 à 22:31. (lien). Évalué à 1.Sinon, j'ai migré en UTF8 sans trop de problemes y'a quelque mois, j'avais utilisé un script python pour la convertion des noms de fichier il me semble...
Ça veut bien dire que tu convertis tes locales et ensuite tu moulines tous tes fichiers via ton script (iconvlike) ? Ça ne me donne pas tout de suite l'envie d'y passer ...
Oops à la relecture, je vois "noms de fichiers". Ceux-là ne devraient pas me poser de problème, ils ne sont pas accentués. Mais comment as-tu fait pour le contenu de tes fichiers ?-
[^]Re: Hmm
Posté par IsNotGood () le 21/11/2007 à 23:13. (lien). Évalué à 2.> Mais comment as-tu fait pour le contenu de tes fichiers ?
J'utilise iconv (fournit avec glibc).-
[^]Re: Hmm
Posté par matthieu () le 21/11/2007 à 23:40. (lien). Évalué à 2.En fait tout va bien si tu es sûr du jeu de caractère source.
Mais si comme tu dis, tu as commencer à ouvrir une partie des fichier avec un ide qui fait la conversion, ou que les fichiers proviennent de plusieurs sources, là ça devient moins sympatique.
-
[^]Re: Hmm
Posté par seginus () le 22/11/2007 à 07:06. (lien). Évalué à 8.Basé dessus, il y a convmv.
C'est simple et puissant. par exemple pour un dossier
convmv -r -f iso-8859-15 -t utf8 .
avec :
-r : récursif
-f : from
-t : to
Cela affiche tout les changement qui vont être effectués et si c'est bon, on rajoute juste --notest-
[^]Re: Hmm
Posté par Farvardin (page perso, ) le 22/11/2007 à 09:04. (lien). Évalué à 2.http://freshmeat.net/projects/convmv/
"convmv converts filenames (not file content)"
"convmv convertit les noms de fichiers (pas le contenu)"
mais pour le moment je n'ai utilisé ni l'un ni l'autre...--
Tous ensemble contre l'esclavitude des logiciels privateurs !
-
[^]Re: Hmm
Posté par calandoa () le 22/11/2007 à 22:58. (lien). Évalué à 2.Et pour reconnaitre le charset d'un fichier, et eventuellement le convertir: utrac
Qui peut d'ailleurs être assez utile avec convmv: « find | utrac -p » pour reconnaitre le charset d'un répertoire (par exemple un zip qu'on vient de récupérer de nul part) puis un coup de convmv comme décrit ci dessus, et hop!
http://utrac.sourceforge.net/-
[^]Re: Hmm
Posté par Aurélien Le Provost - Ribaltch (page perso, ) le 23/11/2007 à 16:19. (lien). Évalué à 1.À l'époque de ma conversion à l'UTF8, j'avais fait un billet pour partager un script basé sur utrac :
http://aurelp.fr.eu.org/blog/index.php?2006/11/10/32-passer-(...)
Qui fait la conversion pour les noms de fichiers, et un autre qui s'occupe de leur contenu.--
Encryption is not magic pixie dust to sprinkle on things to make them more secure.
-
-
-
-
-
[^]iconv
Posté par Kobold Cyber (Jabber id, page perso, ) le 21/11/2007 à 22:38. (lien). Évalué à 4.Ce petit script converti de l'iso machin chose en UTF8 des fichiers textes.
je l'ai utilisé pour convertir mes fortunes qui étaient en ISO-bidule alors que mon système (mandriva) est en UTF-8
#!/bin/sh
for ii in *.txt
do
iconv -f ISO-8859-15 -t UTF-8 "$ii" -o "$ii.utf8"
done--
http://kobold.hd.free.fr/-
[^]Re: iconv
Posté par Farvardin (page perso, ) le 22/11/2007 à 21:32. (lien). Évalué à 2.j'ai essayé de modifier ce script pour déplacer les anciens fichiers dans un dossier de sauvegarde, et surtout tester avant de convertir si le fichier est bien en iso-8859. Malheureusement je suis nul en bash, et je n'y arrive pas :
#!/bin/sh
mkdir backup.iso8859
chemin="$1"
for ii in "$chemin"
do
tt=`file "$ii" | grep ISO-8859`
if [ $tt -ne '' ]
then
iconv -f ISO-8859-15 -t UTF-8 "$ii" -o "$ii.utf8"
mv "$ii" "backup.iso8859/$ii.iso8859.old"
mv "$ii.utf8" "$ii"
fi
done
--
Tous ensemble contre l'esclavitude des logiciels privateurs !-
[^]Re: iconv
Posté par Farvardin (page perso, ) le 24/11/2007 à 12:59. (lien). Évalué à 2.cette fois-ci cela fonctionne, je n'ai pas réussi à le faire sans passer par utrac (sans doute possible avec file et cut) :
#!/bin/sh
# http://utrac.sourceforge.net/ est nécessaire pour ce script
mkdir backup.iso8859
#chemin=`pwd`
for ii in *.t2t *.txt *.php *.htm*
do
# tt=`file "$ii" | grep ISO-8859`
tt=`utrac -p "$ii"`
if [ "$tt" == ISO-8859-1 ] || [ "$tt" == ISO-8859-15 ]
then
echo "$ii est en $tt, il sera converti en utf8"
iconv -f ISO-8859-15 -t UTF-8 "$ii" -o "$ii.utf8"
mv "$ii" "backup.iso8859/$ii.iso8859.old"
mv "$ii.utf8" "$ii"
else
echo "$ii est déjà en $tt, il ne sera pas modifié"
fi
done
echo "Vos anciens fichiers ont été archivé dans backup.iso8859"
(je l'ai fait pour le type de fichier que j'utilise le plus...--
Tous ensemble contre l'esclavitude des logiciels privateurs !
-
-
Re:
> * l'iso-machin-trucmuche saylargementsuffisant pour le franco-français (sans arguments c'est plus facile)
Mouaif. Il y en a aussi qui utilise des claviers qwerty et ne foutent jamais un accent...
> * l'utf-8 c'est pas fiable parce que cela va me mettre des caractères bizarres partout si je me gourre dans mes scripts de conversion et que je ne fais pas cela correctement.
Si utf-8 n'est pas fiable, alors les autres charsets le sont moins.
> J'imagine que je ne suis pas le premier qui se retrouve face à ce genre de problème, mais si vous avez des vrais arguments, ça m'intéresse aussi.
Vrai argument : unicode ce n'est pas le futur, c'est le présent. C'est le futur pour ceux qui sont restés dans le passé.
Red Hat pousse utf-8 depuis RH8.0 (activé par défaut). Depuis des années tout tourne en utf-8 et basta.
Il est ridicule qu'il reste aujourd'hui des distributions qui ne sont pas passées à unicode alors que Windows l'a fait depuis des années. M'enfin, Windows n'est pas une référence car il y a encore plein d'applis (même des applis de MS) qui merdent avec utf-8.
> on oublie les 8 partitions de 15 Go chacune, et on n'en fait qu'une grosse à la place... c'est plus facilement gérable
C'est effectivement beaucoup moins con. J'ignore pourquoi il y a encore tant de personnes qui recommandent de faire plein de partitions...
> Pour les accents dans les titres de fichier, ce n'est pas trop un problème, car cela fait des années déjà que j'essaye de les éviter.
Mois ça fait des années que je ne les évites plus car ça marche.
> Est-ce que ce n'est pas trop fastidieux de tout convertir ?
Convertir un "bête" fichier texte ne pose pas de problème. Et la conversion vers utf-8 est réversible.
> Pour les fichiers du genre openoffice
OOo utilise de l'unicode.
> Sinon si vous voulez déverser votre fiel à propos d'une mauvaise expérience avec utf-8
Désolé, il y a rien qui vient.
-
[^]Re: Re:
Posté par Cereal Killer (Jabber id, ) le 22/11/2007 à 05:49. (lien). Évalué à 2.> on oublie les 8 partitions de 15 Go chacune, et on n'en fait qu'une grosse à la place... c'est plus facilement gérable
C'est effectivement beaucoup moins con. J'ignore pourquoi il y a encore tant de personnes qui recommandent de faire plein de partitions...
pour ça par exemple => http://www.us.debian.org/doc/manuals/securing-debian-howto/c(...)
ou pour ça aussi => http://www.us.debian.org/doc/manuals/securing-debian-howto/c(...)
... bon ok, madame michu elle s'en tape, mais pour un serveur ça peut toujours être utile.-
[^]Re: Re:
Posté par briaeros007 () le 22/11/2007 à 07:04. (lien). Évalué à 3.les 3 petits points à la fin montrent que c'était ironique ;)
Au risque d'en faire hurler certains, sur mon poste de travail (au boulot), et sur les serveurs de "tests" que j'utilise (toujours au boulot), c'est tout en une partition.
Pourquoi ?
Parce que :
1°) je sais pas quel va être le ratio système/home/var/tmp
2°) j'ai la flemme de m'amuser avec LVM
3°) parce que normalement je sauvegarde ce qu'il y a d'important.
4°) parce que ça marche très bien comme pour une utilisation courante (non en prod), et que j'ai pas envie de regarder si j'ai pas dépasser la taille (encore une fois, pour des tests, et pour mon usage courant).
5°) d'après mes expérience, si j'ai un probleme de fs, je peux réussir a récup ce qu'il y a.
Si c'est un problème de dd localisé, je peux récupérer ce qu'il y a (merci aux superblocks ;))
Si c'est un problème de dd général -> seul le backup peut aider.
Bref, comme le dis Cereal Killer, ca dépend des usages.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Re:
Posté par seginus () le 22/11/2007 à 07:24. (lien). Évalué à 4.>> les 3 petits points à la fin montrent que c'était ironique ;)
Je me disais bien aussi.
Sinon, sans parlé du sécuritaire (j'ai pas tout lu la page debian là) je pense que le home séparer est un minimum.
-- Ça gagne un temps fou en cas de réinstallation du système. (parce que tout le monde ne sauvegarde pas ses 50Go de musiques, ce qui est normal vu qu'ils ont les originaux)
-- Même si Linux fragmente très peu, mettre le système à part au début du disque doit accélérer un peu les temps d'accès.
Le problème sous windows, c'est que la gestion des partitions est catastrophique et les logiciels mal conçu pour ça.
Donc même si on met « Mes documents » sur une partition à part, il y a plein de merde qui vont quand même se placer ailleurs (je n'y ai pas cru au début quand j'ai vu un logiciel de p2p plaçant les documents en téléchargement dans « Program files »
Sinon côté partitionnement, les PC de marque (chez moi, c'est péjoratif) ont des partitionnements de plus en plus étrange (j'ai déjà eu plusieurs cas de disque complètement coupé en deux)-
[^]Re: Re:
Posté par briaeros007 () le 22/11/2007 à 09:44. (lien). Évalué à 1.-- Ça gagne un temps fou en cas de réinstallation du système. (parce que tout le monde ne sauvegarde pas ses 50Go de musiques, ce qui est normal vu qu'ils ont les originaux)
Mais ... Mais ... on est pas sous windows. On réinstalle pas quand il y a un problème! :P (ce message est bien entendu ironique, les gens font ce qu'ils veulent ... non pas avec leurs cheveux mais leur système...)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Re:
Posté par Farvardin (page perso, ) le 22/11/2007 à 21:44. (lien). Évalué à 4.là je suis bien d'accord. Je ne comprends pas sur certains forums on lit "j'ai fait la mise à jour de mon linux suite à la sortie de la *.**, j'ai tout réinstallé".
Par contre dans mon cas vu que j'avais détruit la table des partitions, je n'ai pas eu trop de choix...
À l'époque faire de multiples partitions me semblait plus rationnel, mais maintenant j'ai 20 Go pour le système, et tout le reste pour le /home (dans lequel je mets également /opt).
Quand au partitionnement multiple pour /var , /boot /usr etc, c'est valable peut-être pour un serveur aux besoins précis, mais pour un usage de bureau cela n'a pas beaucoup d'intérêt je pense. C'est bien beau ces docs sur la sécurité, le système debian et compagnie, dommage seulement qu'ils ne précisent pas clairement que ces conseils sont avant tout pour un usage de serveur.--
Tous ensemble contre l'esclavitude des logiciels privateurs !-
[^]Re: Re:
Posté par wismerhill (page perso, ) le 23/11/2007 à 19:21. (lien). Évalué à 2.Par contre dans mon cas vu que j'avais détruit la table des partitions, je n'ai pas eu trop de choix...
On a toujours le choix
http://home.pages.de/~michab/gpart/
Il me semble qu'il est sur la knoppix et je sais d'expérience qu'il est dans le mode rescue de la mandriva car ce programme m'a déjà sauvé la mise une fois.
-
-
-
[^]Re: Re:
Posté par Thomas DEBESSE (page perso, ) le 23/11/2007 à 22:06. (lien). Évalué à 4.je n'y ai pas cru au début quand j'ai vu un logiciel de p2p plaçant les documents en téléchargement dans « Program files »
Boarf c'est commun sous Windows, MS Exchange met bien les boites aux lettres des utilisateurs dans « Program files »...--
† In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.
-
-
[^]Re: Re:
Posté par IsNotGood () le 22/11/2007 à 10:58. (lien). Évalué à 2.> c'est tout en une partition.
Pareil.
Sauf, évidemment, pour les backups. Ils sont faits sur autre chose (disque, machine, etc). Backups indispensables quelque soit le partitionnement.
> j'ai pas envie de regarder si j'ai pas dépasser la taille
Pour une bécane de production, il y a les quotas. Et il n'y a pas de raisons qu'ils marchent moins bien ou soient moins sûr qu'un partitionnement.-
[^]Re: Re:
Posté par briaeros007 () le 22/11/2007 à 11:23. (lien). Évalué à 3.y'a un grand intérêt dans un truc en prod pour le partitionnement (suivant les services offert bien sur) :
c'est de pouvoir mettre noexec,nodev,nosuid . Comme ca si quelqu'un arrive a mettre un fichier quelconque la ou il devrait y avoir des données, il ne "devrait" pas arriver a faire grand chose.
Ensuite c'est suivant l'intérêt des admins etc... (oui je sais selinux devrait pouvoir faire la meme chose, mais selinux je touche pas trop pour l'instant).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Re:
-
-
-
-
-
[^]Re: Re:
Posté par Kévin FERRARE (page perso, ) le 22/11/2007 à 07:47. (lien). Évalué à 2.> Sinon si vous voulez déverser votre fiel à propos d'une mauvaise expérience avec utf-8
Désolé, il y a rien qui vient.
Globalement je l'utilise partout, sauf pour les mails non HTML.
Contrairement à la pluspart programmes, le outlook japonais n'aime pas l'UTF8, ca fait du mojibake.
Comme la pluspart des gens ici l'utilisent, la seule solution c'est d'envoyer en iso-2022-jp
.
L'UTF-8 n'est pas seulement le futur, c'est le présent et le passé ! Il est utilisé par défaut dans tous les OS depuis pas mal de temps, et il est très bien pris en charge par quasiment tous les programmes. Par contre en 2003 ce n'était pas le cas et j'avais un peu lutté pour pouvoir l'utiliser par défaut. (entre autres dans les VTs)
J'en avais profité pour écrire un minuscule script python qui renomme tous les fichiers de manière récursive, (je l'ai réécrit cette année après m'être mis un peu plus sérieusement à python) :
http://ccomb.free.fr/wiki/wakka.php?wiki=UtfConvert
Si ça peut servir... (il est en mode dummy par défaut pour juste voir le résultat sans renommer)
-
[^]Re: .
Posté par gnumdk (page perso, ) le 22/11/2007 à 17:21. (lien). Évalué à 2.Je savais bien que j'avais utilisé un script python ;)
Merci!--
Agogo
la lenteur extraordinaire d'utf8
Que penser de cette page : http://sam.zoy.org/writings/utf8/
En gros : l'utf8 c'est lent, entre 10 et 6000 fois la vitesse des mêmes traitements qu'avec un codage normal.
Pour tester :
yes aaaaaaaaaaaaaaa | head -131072 >foo.txt
time LC_CTYPE=fr_FR.UTF-8 wc foo.txt >/dev/null
time LC_CTYPE=fr_FR wc foo.txt >/dev/null
time LC_CTYPE=fr_FR.UTF-8 grep "." foo.txt >/dev/null
time LC_CTYPE=fr_FR grep "." foo.txt >/dev/null
-
[^]Re: la lenteur extraordinaire d'utf8
Posté par Aldoo (Jabber id, ) le 22/11/2007 à 13:37. (lien). Évalué à 2.Que penser de cette page ?
Que debian est un dinosaure pas fichu de traiter de l'utf8 aussi vite que de l'ISO trucmuche ?¹²
Nan, parce que là chez moi, pas de différence notable... enfin, de l'ordre de 10%, c'est pas la mort.
¹ En fait j'utilise aussi debian... c'était juste pour le plaisir de troller un peu.
² N'empêche que sans l'unicode, je ne pourrais pas faire ces zolis renvois !-
[^]Re: la lenteur extraordinaire d'utf8
-
-
[^]Re: la lenteur extraordinaire d'utf8
Posté par Kévin FERRARE (page perso, ) le 22/11/2007 à 14:20. (lien). Évalué à 4.Les chiffres donnés sur le site de ton lien me surprennent un peu.
J'ai fait par curiosité mes propres tests et je trouve des résultats bien différents.
Les performances entre ascii, utf-8, sjis et eucjp sont pour moi très similaires.
Voici les résultats (si quelqu'un a envie de s'amuser à retester, ne pas oublier de changer l'encodage de la console à sjis ou eucjp pour les tests de grep) :
Préparation des fichiers de test
# yes 隣の客はよくカキ食う客や | head -1000000>foo-utf8.txt
# yes aaaaaaaaaaaa | head -1000000>ascii.txt
# iconv -f utf8 -t sjis foo-utf8.txt >foo-sjis.txt
# iconv -f utf8 -t eucjp foo-utf8.txt >foo-eucjp.txt
test comptage des lignes (wc)
Fichier ne contenant que des caractères ASCII
# time LC_CTYPE=ja_JP.UTF-8 wc ascii.txt>/dev/null
real 0m0.220s user 0m0.173s sys 0m0.010s
# time LC_CTYPE=ja_JP.ASCII wc ascii.txt>/dev/null
real 0m0.222s user 0m0.167s sys 0m0.016s
utf-8 : 0.403 sec
ascii : 0.416 sec
Fichier ne contenant que des caractères non ASCII
# time LC_CTYPE=ja_JP.UTF-8 wc foo-utf8.txt>/dev/null
real 0m0.576s user 0m0.499s sys 0m0.039s
# time LC_CTYPE=ja_JP.SJIS wc foo-sjis.txt>/dev/null
real 0m0.492s user 0m0.432s sys 0m0.019s
# time LC_CTYPE=ja_JP.EUCJP wc foo-eucjp.txt >/dev/null
real 0m0.402s user 0m0.337s sys 0m0.027s
utf-8 : 1.114 sec
sjis : 0.943 sec
eucjp : 0.766 sec
Test grep
Fichier ASCII
# time LC_CTYPE=ja_JP.UTF-8 grep "a" ascii.txt>/dev/null
real 0m0.327s user 0m0.285s sys 0m0.009s
# time LC_CTYPE=ja_JP.ASCII grep "a" ascii.txt>/dev/null
real 0m0.323s user 0m0.277s sys 0m0.012s
utf-8 : 0.612 sec
ascii : 0.621 sec
Fichier non ASCII
# time LC_CTYPE=ja_JP.UTF-8 grep "の" foo-utf8.txt>/dev/null
real 0m0.404s user 0m0.332s sys 0m0.038s
# time LC_CTYPE=ja_JP.SJIS grep "の" foo-sjis.txt>/dev/null
real 0m0.350s user 0m0.287s sys 0m0.030s
# time LC_CTYPE=ja_JP.EUCJP grep "の" foo-eucjp.txt>/dev/null
real 0m0.347s user 0m0.298s sys 0m0.018s
utf-8 : 0.774 sec
sjis : 0.667 sec
eucjp : 0.663 sec
La machine de test est un pentium M 1.6Ghz sous gentoo-
[^]Re: la lenteur extraordinaire d'utf8
Posté par Annah C. Hue (page perso, ) le 22/11/2007 à 15:39. (lien). Évalué à 2.J'ai effectué les tests sur une vieille redhat ES4 et j'obtiens des résultats similaires au lien ci-dessus :
time LC_CTYPE=fr_FR.UTF-8 wc foo.txt >/dev/null
real 0m0.385s
time LC_CTYPE=fr_FR wc foo.txt >/dev/null
real 0m0.055s
time LC_CTYPE=fr_FR.UTF-8 grep . foo.txt >/dev/null
real 0m0.138s
time LC_CTYPE=fr_FR grep . foo.txt >/dev/null
real 0m0.062s
Par contre sur ma debian perso qui est très moderne, les temps sont similaires entre utf8 et pas utf8. On peut donc penser qu'il y a eu de belles améliorations sur le support d'utf8...
-
-
[^]Re: la lenteur extraordinaire d'utf8
Posté par IsNotGood () le 22/11/2007 à 15:44. (lien). Évalué à 0.> Pour tester :
Ben testons (athlon 1,2 GHz) :
[admin@one tmp]$ time LC_CTYPE=fr_FR.UTF-8 wc foo.txt >/dev/null
real 0m0.432s
user 0m0.420s
sys 0m0.007s
[admin@one tmp]$ time LC_CTYPE=fr_FR wc foo.txt >/dev/null
real 0m0.057s
user 0m0.044s
sys 0m0.007s
[admin@one tmp]$
[admin@one tmp]$ time LC_CTYPE=fr_FR.UTF-8 grep "." foo.txt >/dev/null
real 0m0.160s
user 0m0.148s
sys 0m0.006s
[admin@one tmp]$ time LC_CTYPE=fr_FR grep "." foo.txt >/dev/null
real 0m0.065s
user 0m0.054s
sys 0m0.008s
[admin@one tmp]$
> En gros : l'utf8 c'est lent, entre 10 et 6000 fois la vitesse des mêmes traitements qu'avec un codage normal.
Des fantasmes...
utf8 est compatible ASCII. Tant que tes fichiers ont de l'ASCII c'est un peu plus lent. Par contre si tu fais un grep "Ǥ®¾™⅀⅋℠" ça va être lent. Ça n'est pas beaucoup plus lent puis qu'avec l'autre codage tu ne peux pas le faire.
-
[^]Re: la lenteur extraordinaire d'utf8
Posté par IsNotGood () le 22/11/2007 à 16:24. (lien). Évalué à 4.> http://sam.zoy.org/writings/utf8/
Du lien :
Notes: I have been using GNU grep 2.5.1, wc 5.2.1 on a glibc 2.3.2 system.
Encore une victime de Debian...-
[^]Re: la lenteur extraordinaire d'utf8
Posté par tinodeleste () le 22/11/2007 à 20:09. (lien). Évalué à 2.la 2.3.2 avait moins de deux ans à l'écriture de ladite page, et la 2.3.4 n'était pas encore sortie. Malheureusement, peu de développeurs debian utilisent la version stable. D'un autre côté, on ne sait pas comment ils développeraient sinon.
-
-
[^]Re: la lenteur extraordinaire d'utf8
Posté par wismerhill (page perso, ) le 22/11/2007 à 19:24. (lien). Évalué à 2.Normal que ce soit plus lent: l'UTF-8 n'a pas une longueur fixe de caractère (suivant les cas, un caractère fait 1 2 ou 4 octets) donc si on veut le xme caractère on ne peut pas faire un saut direct à la position, il faut compter tous les caractères avant, et du coup des algorithme qui peuvent être très rapides avec un encodage de taille constante vont devenir tout à coup lamentablement lents.
Refait le test avec de l'UTF-16, tu verra que l'unicode n'a pas de problème de vitesse.
l'UTF-8 est juste là pour éviter de doubler la taile de fichiers qui contiennent essentiellement de l'ASCII.-
[^]Re: la lenteur extraordinaire d'utf8
Posté par IsNotGood () le 22/11/2007 à 20:32. (lien). Évalué à 1.> suivant les cas, un caractère fait 1 2 ou 4 octets
ucs2 tient sur 2 octets.ucs4 (supporté depuis assez longtemps par la glibc) tient sur 4 octets. Par contre le codage de usc4 en utf-8 tient sur 1 à 6 octets. Si c'est de l'ASCII, ça tient sur 1 octet et c'est la même valeur que ASCII.
> l'UTF-8 est juste là pour éviter de doubler la taile de fichiers qui contiennent essentiellement de l'ASCII.
Voir quadripler.
En passant, UTF-16 ne code pas forcément les caractères sur 2 octets. Pour le codage de usc2 c'est le cas, ce n'est plus le cas pour usc4.-
[^]Re: la lenteur extraordinaire d'utf8
Posté par rewind () le 27/11/2007 à 17:39. (lien). Évalué à 2.Tu confonds encore point de code et représentation informatique de ces points de code. Alors on va recommencer...
UCS-{2,4} définissent des points de codes, c'est à dire qu'ils assignent à chaque caractère des numéros, rien de plus. UCS-2 (sur 2 octets) ne contient que les points de codes inférieurs à 65535, logique, donc pas tous les caractères. UCS-4 (sur 4 octets) contient plus plus de points de codes, logique aussi, et même tous les points de codes.
UTF-{8,16,32} est une manière de représenter les points de code informatiquement. Les caractères en UTF-8 peut avoir 4 octets au maximum, pas 6. En UTF-16, c'est 4 octets maximum aussi et en UTF-32, c'est 4 octets tout le temps.
-
-
[^]Re: la lenteur extraordinaire d'utf8
Posté par Kévin FERRARE (page perso, ) le 23/11/2007 à 05:01. (lien). Évalué à 2.Mais UTF-8 n'est pas significativement plus lent ...
-
[+] Windows Powa
Je viens de voir cet article dans mes RSS au travail sous Windows (avec Firefox), et on dirait qu'il aime pas l'utf8 justement : tous les é sont affichés comme des Ã(C).
J'ai testé avec IE aussi, c'est pareil...
Je ne peux pas dire si ça vient du proxy au boulot ou si c'est une joyeuseté windows, je n'ai pas de Windows chez moi pour tester...
-
[^]Re: Windows Powa
Posté par Farvardin (page perso, ) le 22/11/2007 à 18:36. (lien). Évalué à 4.désolé chez moi cela marche bien pourtant !
(hint : j'ai entré exprès des Ã+©)...--
Tous ensemble contre l'esclavitude des logiciels privateurs !
-
[^]Re: Windows Powa
Posté par yellowiscool (Jabber id, page perso, ) le 22/11/2007 à 20:29. (lien). Évalué à 4.Il me semble que c'est de l'humour ;)
-
[+] [^]Re: Windows Powa
Posté par spiral () le 23/11/2007 à 14:39. (lien). Évalué à -1.Non non, ce n'est pas de l'humour je vous assure... Si ça vous fait plaisir de me moinser continuez, n'hésitez-pas, ça me confortera encore plus pour me dire que mon compte dlfp ne me sert à rien. Mais bon... Les é ne passent vraiment pas...
En regardant le code de la page tel que Firefox me le donne j'ai <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />
Je ne sais pas si c'est pareil chez vous ou pas, mais bon, avec un charset à iso8859-15, je ne suis pas étonné que des accents utf8 chient dans la colle.-
[^]Re: Windows Powa
Posté par Moogle (page perso, ) le 23/11/2007 à 15:03. (lien). Évalué à 5.L'humour, c'est dans le journal d'origine, où l'auteur a volontairement inséré des caractères en UTF-8. Parce que c'est mieux de prôner l'usage de l'UTF-8 en l'utilisant là où c'est pas censé passer :)
-
[^]Re: Windows Powa
Posté par baud123 (Jabber id, page perso, ) le 23/11/2007 à 23:06. (lien). Évalué à 3.mon compte dlfp ne me sert à rien
c'est plutôt ton humour qui ne te sert à rien :)
le compte dlfp il ne s'use que si l'on ne s'en sert pas...
-
-
au quotidien
Le fait de passer en utf-8 ne pose aucun souci, si tu prends quelques précautions qui sont valable en réalité pour les encodage latin9 :
_ quand tu codes : en anglais, donc dans la pratique ton fichier sera ASCII, car si tu es sûre de la configuration de ta machine, tu ne l'es pas des machines des gens pouvant de relire. Même pour les messages de logs si tu fais des applications serveurs ou des applications web.
_ man : en français les encodages ne sont pas uniformes donc ne t'attends pas à tout avoir nickel à l'affichage
_ quand tu transmet un fichier à quelqu'un, vires les accents espace et compagnie.
En fait la vrai distinction c'est si les données sortent de chez toi ou pas. Si oui prend des précautions pour être sûre que la personne en face n'ai pas de problème.
Sinon cela ne change rien, et je pense même que tel encodage ou tel autre pour les besoins courant cela n'apporte rien, par contre quand tu as plusieurs machines ou un parc, lance un dé : si c'est pair tout en latin, si c'est impair tout en utf8. le principal c'est que tu puisses manipuler tes données facilement, même si çà transit entre plusieurs machines du parc, donc vaut mieux que ce soit uniforme.
-
[^]Re: au quotidien
Posté par Tonton Benoit (Jabber id, ) le 23/11/2007 à 12:26. (lien). Évalué à 2.Tant que le langage roff ne supportera pas une commande ".ENCODING" ou qu'on utilisera pas autre chose (pourquoi pas docbook ?) les pages man aurons un comportement catastrophique dans un environnement Unicode !
Perso avec groff-utf8 et un petit script j'arrive à avoir 100% de rendu correct sur les pages man en français, mais ça ne marche pas si bien avec les autres langues !
-
[^]Re: au quotidien
Posté par Thomas Douillard () le 23/11/2007 à 12:42. (lien). Évalué à 3.Mouais, la vraie précaution quand tu sors de chez toi devrait plutôt être de tout mettre en utf-8 de nos jour, et pas de se limiter au plus petit dénominateur commun qu'es l'ascii. Et encore, c'est justement pas le plus petit dénominateur commun.
-
[^]Re: au quotidien
Posté par Plop () le 23/11/2007 à 13:39. (lien). Évalué à 2.quand tu transmet un fichier à quelqu'un, vires les accents espace et compagnie.
Sans déconner, tu fais vraiment ça ? et le mec qui reçoit ton fichier les ajoutent à la main ???
On est au 21ème siècle. Tout fichier doit spécifier dans son entête l'encoding utilisé. Il n'y a que comme ça qu'on s'en sortira.
Et pour les fichiers de type txt, on met dans la première ligne -*- coding: utf-8 -*- comme ça, emacs gère ça tout seul. et ca donne une info pour le pauvre destinataire qui recevera le fichier.--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: au quotidien
Posté par tinodeleste () le 23/11/2007 à 19:24. (lien). Évalué à 3.Et pour les fichiers de type txt, on met dans la première ligne -*- coding: utf-8 -*- comme ça, emacs gère ça tout seul. et ca donne une info pour le pauvre destinataire qui recevera le fichier.
il y a beaucoup de tes destinataires qui savent ce qu'il faut faire d'une telle première ligne ???-
[^]Re: au quotidien
Posté par Plop () le 24/11/2007 à 14:28. (lien). Évalué à 2.non, du coup, je préfère envoyé mes mails en .doc /o\
--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: au quotidien
Posté par briaeros007 () le 25/11/2007 à 20:56. (lien). Évalué à 3.fait le html.
C'est moins bien que le txt, mais mieux que l'email en .doc avec dedans une image du texte.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
[^]Re: au quotidien
Posté par Farvardin (page perso, ) le 23/11/2007 à 23:42. (lien). Évalué à 3.non je pense qu'il voulait dire "dans le titre du fichier", pas dans le corps du fichier. De toute façon tous les fichiers que je créé actuellement on l'espace remplacé par _ et pas d'accent, cela évite bien des problèmes.
--
Tous ensemble contre l'esclavitude des logiciels privateurs !
-
Cette page a été générée par Templeet en 0.1726s (dont 0.0142 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.