Bonjour à tous,
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
Journal L'utf-8 et les décideurs
21
nov.
2007
# Re:
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 6.
>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
# Hmm
Posté par gnumdk (site web personnel) . Évalué à 4.
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...
[^] # Re: Hmm
Posté par PiT (site web personnel) . Évalué à 1.
Ç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 . Évalué à 2.
J'utilise iconv (fournit avec glibc).
[^] # Re: Hmm
Posté par matthieu . Évalué à 2.
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 . Évalué à 8.
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 B16F4RV4RD1N . Évalué à 2.
"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...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Hmm
Posté par calandoa . Évalué à 2.
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 Anonyme . Évalué à 1.
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.
[^] # iconv
Posté par Cyber Kobold (site web personnel) . Évalué à 4.
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
[^] # Re: iconv
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: iconv
Posté par B16F4RV4RD1N . Évalué à 2.
(je l'ai fait pour le type de fichier que j'utilise le plus...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Re:
Posté par IsNotGood . Évalué à 5.
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 . Évalué à 2.
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 . Évalué à 3.
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.
[^] # Re: Re:
Posté par seginus . Évalué à 4.
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 . Évalué à 1.
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...)
[^] # Re: Re:
Posté par B16F4RV4RD1N . Évalué à 4.
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.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Re:
Posté par wismerhill . Évalué à 2.
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 (site web personnel) . Évalué à 4.
Boarf c'est commun sous Windows, MS Exchange met bien les boites aux lettres des utilisateurs dans « Program files »...
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
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 . Évalué à 3.
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).
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Mais t'as raison.
[^] # Re: Re:
Posté par timid . Évalué à 2.
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
# Heu... oui mais non !
Posté par omnikron . Évalué à 1.
Ouai bon... :-D
# .
Posté par ccomb (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
Merci!
# la lenteur extraordinaire d'utf8
Posté par Annah C. Hue (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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
Posté par lasher . Évalué à 4.
Euh, si. Je suis en latin9, et j'ai absolument aucun problème pour faire des exposants jusqu'à 3...
[^] # Re: la lenteur extraordinaire d'utf8
Posté par timid . Évalué à 4.
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
test comptage des lignes (wc)
Fichier ne contenant que des caractères ASCII
utf-8 : 0.403 sec
ascii : 0.416 sec
Fichier ne contenant que des caractères non ASCII
utf-8 : 1.114 sec
sjis : 0.943 sec
eucjp : 0.766 sec
Test grep
Fichier ASCII
utf-8 : 0.612 sec
ascii : 0.621 sec
Fichier non ASCII
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 (site web personnel) . Évalué à 2.
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 . Évalué à 0.
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 . Évalué à 4.
Du lien :
Encore une victime de Debian...
[^] # Re: la lenteur extraordinaire d'utf8
Posté par tinodeleste . Évalué à 2.
[^] # Re: la lenteur extraordinaire d'utf8
Posté par wismerhill . Évalué à 2.
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 . Évalué à 1.
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 (Mastodon) . Évalué à 2.
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 timid . Évalué à 2.
# Windows Powa
Posté par spiral . Évalué à -4.
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 B16F4RV4RD1N . Évalué à 4.
(hint : j'ai entré exprès des Ã+©)...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Windows Powa
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: Windows Powa
Posté par spiral . Évalué à -1.
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 . Évalué à 5.
[^] # Re: Windows Powa
Posté par BAud (site web personnel) . Évalué à 3.
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
Posté par or zax . Évalué à 2.
_ 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 . Évalué à 2.
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 . Évalué à 3.
[^] # Re: au quotidien
Posté par Putifuto . Évalué à 2.
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.
[^] # Re: au quotidien
Posté par tinodeleste . Évalué à 3.
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 Putifuto . Évalué à 2.
[^] # Re: au quotidien
Posté par briaeros007 . Évalué à 3.
C'est moins bien que le txt, mais mieux que l'email en .doc avec dedans une image du texte.
[^] # Re: au quotidien
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.