Ne sachant pas taper ce "f" un peu bizarre, j'ai édité le script dans le
Terminale, et ai fait un "drag 'n' drop" du répertoire depuis le Finder.
En voici le résultat ...
Sans surprise, quand j'exécute le script, il me sort qu'il n'y a aucun
fichier nommé "?~R".
Des idées? Je crains que renommer le dossier ne nuise au fonctionnement
de MT-NewsWatcher, et me dis qu'il doit y avoir une astuce pour
enregistrer ce genre de fichier/répertoire.
Merci.
Y.
--
yitzhak
mac mini 1,83 ghz | mac os x 10.4.11
Le 18/07/08 16:31, dans , « Patrick Stadelmann » a écrit :
In article <C4A662A2.D2BF2%, Eric Levenez wrote:
Alors si la question est sur le texte en mémoire dans un programme, alors oui, il y a un encodage associé, et c'est le système et le programmeur qui en décide. Le plus typique est l'UTF-8. Mais au moment de "sortir" une chaîne du programme, c'est le programmeur qui utilise une API particulière pour encoder son texte dans le bon format (par exemple en UTF-8), et cela quelque soit l'encodage interne des chaînes de caractères.
Si le texte en mémoire est lié à un encodage, il suffit d'employer le même pour envoyer le message et on aura aucun problème ,
Je ne pense pas qu'il y ait un et un seul encodage pour un message. Un message est constitué de 36 blocs de texte mis bout à bout. En utilisant Cocoa, je suppose que la plupart de ces bouts seront encodés en interne en UTF-8, mais ce n'est pas forcément le cas.
On veut très bien lire du code d'un message qui a été codé en UTF-8 et ajouter par couper/coller du texte en Mac OS Roman ou en UTF-16...
Je pense que la plupart des programmeurs Mac OS X codent en interne en UTF-8 (pas sûr que MacSOUP soit dans ce cas...).
puisqu'il est impossible de se retrouver dans la situation que tu évoquais, à savoir avoir des caractères qui ne sont représentable dans l'encodage choisi.
En UTF-8, oui.
Parce que je ne vois pas quel est l'avantage de déterminer dynamiquement l'encodage comme proposé plus haut.
Il n'y a aucun avantage, c'est juste une technique pour être compatible avec le plus de monde possible. Par défaut on essaye l'ASCII, si cela n'est pas suffisant, on essaye l'ISO-8859, sinon on utilise l'UTF-8. Cela n'est qu'une rustine pour les programmes qui ne savent pas gérer l'UTF-8.
Comme je l'ai dit, la seule solution viable sera quand tout le monde utilisera le même encodage : l'UTF-8.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 18/07/08 16:31, dans
<Patrick.Stadelmann-BABE2B.16313018072008@individual.net>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <C4A662A2.D2BF2%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Alors si la question est sur le texte en mémoire dans un programme, alors
oui, il y a un encodage associé, et c'est le système et le programmeur qui
en décide. Le plus typique est l'UTF-8. Mais au moment de "sortir" une
chaîne du programme, c'est le programmeur qui utilise une API particulière
pour encoder son texte dans le bon format (par exemple en UTF-8), et cela
quelque soit l'encodage interne des chaînes de caractères.
Si le texte en mémoire est lié à un encodage, il suffit d'employer le
même pour envoyer le message et on aura aucun problème ,
Je ne pense pas qu'il y ait un et un seul encodage pour un message. Un
message est constitué de 36 blocs de texte mis bout à bout. En utilisant
Cocoa, je suppose que la plupart de ces bouts seront encodés en interne en
UTF-8, mais ce n'est pas forcément le cas.
On veut très bien lire du code d'un message qui a été codé en UTF-8 et
ajouter par couper/coller du texte en Mac OS Roman ou en UTF-16...
Je pense que la plupart des programmeurs Mac OS X codent en interne en UTF-8
(pas sûr que MacSOUP soit dans ce cas...).
puisqu'il est
impossible de se retrouver dans la situation que tu évoquais, à savoir
avoir des caractères qui ne sont représentable dans l'encodage choisi.
En UTF-8, oui.
Parce que je ne vois pas quel est l'avantage de déterminer dynamiquement
l'encodage comme proposé plus haut.
Il n'y a aucun avantage, c'est juste une technique pour être compatible avec
le plus de monde possible. Par défaut on essaye l'ASCII, si cela n'est pas
suffisant, on essaye l'ISO-8859, sinon on utilise l'UTF-8. Cela n'est qu'une
rustine pour les programmes qui ne savent pas gérer l'UTF-8.
Comme je l'ai dit, la seule solution viable sera quand tout le monde
utilisera le même encodage : l'UTF-8.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 18/07/08 16:31, dans , « Patrick Stadelmann » a écrit :
In article <C4A662A2.D2BF2%, Eric Levenez wrote:
Alors si la question est sur le texte en mémoire dans un programme, alors oui, il y a un encodage associé, et c'est le système et le programmeur qui en décide. Le plus typique est l'UTF-8. Mais au moment de "sortir" une chaîne du programme, c'est le programmeur qui utilise une API particulière pour encoder son texte dans le bon format (par exemple en UTF-8), et cela quelque soit l'encodage interne des chaînes de caractères.
Si le texte en mémoire est lié à un encodage, il suffit d'employer le même pour envoyer le message et on aura aucun problème ,
Je ne pense pas qu'il y ait un et un seul encodage pour un message. Un message est constitué de 36 blocs de texte mis bout à bout. En utilisant Cocoa, je suppose que la plupart de ces bouts seront encodés en interne en UTF-8, mais ce n'est pas forcément le cas.
On veut très bien lire du code d'un message qui a été codé en UTF-8 et ajouter par couper/coller du texte en Mac OS Roman ou en UTF-16...
Je pense que la plupart des programmeurs Mac OS X codent en interne en UTF-8 (pas sûr que MacSOUP soit dans ce cas...).
puisqu'il est impossible de se retrouver dans la situation que tu évoquais, à savoir avoir des caractères qui ne sont représentable dans l'encodage choisi.
En UTF-8, oui.
Parce que je ne vois pas quel est l'avantage de déterminer dynamiquement l'encodage comme proposé plus haut.
Il n'y a aucun avantage, c'est juste une technique pour être compatible avec le plus de monde possible. Par défaut on essaye l'ASCII, si cela n'est pas suffisant, on essaye l'ISO-8859, sinon on utilise l'UTF-8. Cela n'est qu'une rustine pour les programmes qui ne savent pas gérer l'UTF-8.
Comme je l'ai dit, la seule solution viable sera quand tout le monde utilisera le même encodage : l'UTF-8.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
filh
Eric Levenez wrote:
Le 18/07/08 12:15, dans , « FiLH » a écrit :
> Eric Levenez writes: > >> Oui, bien sûr, c'est TRÈS simple à coder. > > Un détecteur de codage ? > > Ah.. Intéressant. > > Comment tu fais pour savoir si le texte réduit au caractère 0xA3 est > en iso-latin-1 ou en iso-latin-2 ?
Je vois que comme d'habitude, tu n'a rien lu et tu t'es contenté de sauté à une mauvaise conclusion. Relis mes posts et tu sauras que tu t'es, encore une fois, fourvoyé.
Disons « Pour une fois » :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Eric Levenez <usenet@levenez.com> wrote:
Le 18/07/08 12:15, dans <uxtzenh523.fsf@shadow.enseirb.fr>, « FiLH »
<filh@filh.org> a écrit :
> Eric Levenez <usenet@levenez.com> writes:
>
>> Oui, bien sûr, c'est TRÈS simple à coder.
>
> Un détecteur de codage ?
>
> Ah.. Intéressant.
>
> Comment tu fais pour savoir si le texte réduit au caractère 0xA3 est
> en iso-latin-1 ou en iso-latin-2 ?
Je vois que comme d'habitude, tu n'a rien lu et tu t'es contenté de sauté à
une mauvaise conclusion. Relis mes posts et tu sauras que tu t'es, encore
une fois, fourvoyé.
Disons « Pour une fois » :)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
> Eric Levenez writes: > >> Oui, bien sûr, c'est TRÈS simple à coder. > > Un détecteur de codage ? > > Ah.. Intéressant. > > Comment tu fais pour savoir si le texte réduit au caractère 0xA3 est > en iso-latin-1 ou en iso-latin-2 ?
Je vois que comme d'habitude, tu n'a rien lu et tu t'es contenté de sauté à une mauvaise conclusion. Relis mes posts et tu sauras que tu t'es, encore une fois, fourvoyé.
Disons « Pour une fois » :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Thomas
In article <C4A662A2.D2BF2%, Eric Levenez wrote:
[...] Soit le fichier est en texte "pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par exemple essaye de deviner l'encodage des fichiers textes purs, mais c'est assez souvent faux, bien entendu.
et dans les (nombreux) cas où c'est faux, on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient juste d'ouvrir par double-clic : il est même pas capable de nous le mettre sous la main ... :-( ) ? on ne peut pas lui demander de relire le même fichier en utilisant un autre encodage pour le décoder (comme on peut le faire avec TextWrangler) ?
In article <C4A662A2.D2BF2%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
[...] Soit le fichier est en texte
"pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par exemple
essaye de deviner l'encodage des fichiers textes purs, mais c'est assez
souvent faux, bien entendu.
et dans les (nombreux) cas où c'est faux,
on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient
juste d'ouvrir par double-clic : il est même pas capable de nous le
mettre sous la main ... :-( ) ?
on ne peut pas lui demander de relire le même fichier en utilisant un
autre encodage pour le décoder (comme on peut le faire avec
TextWrangler) ?
[...] Soit le fichier est en texte "pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par exemple essaye de deviner l'encodage des fichiers textes purs, mais c'est assez souvent faux, bien entendu.
et dans les (nombreux) cas où c'est faux, on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient juste d'ouvrir par double-clic : il est même pas capable de nous le mettre sous la main ... :-( ) ? on ne peut pas lui demander de relire le même fichier en utilisant un autre encodage pour le décoder (comme on peut le faire avec TextWrangler) ?
[...] Soit le fichier est en texte "pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par exemple essaye de deviner l'encodage des fichiers textes purs, mais c'est assez souvent faux, bien entendu.
et dans les (nombreux) cas où c'est faux, on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient juste d'ouvrir par double-clic : il est même pas capable de nous le mettre sous la main ... :-( ) ?
Si tu as double-cliqué sur l'icône du fichier, il ne doit pas être bien loin, et dans ce cas un simple glisser/déposé de cette icône dans la fenêtre d'ouverture de TextEdit le sélectionne.
on ne peut pas lui demander de relire le même fichier en utilisant un autre encodage pour le décoder (comme on peut le faire avec TextWrangler) ?
Si ton TextWrangler sait faire cela, et si cela t'es important (vu le titre de ce message), alors il faut l'utiliser.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/09/08 16:53, dans
<fantome.forums.tDeContes-753338.16531420092008@news.free.fr>, « Thomas »
<fantome.forums.tDeContes@free.fr.invalid> a écrit :
In article <C4A662A2.D2BF2%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
[...] Soit le fichier est en texte
"pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par exemple
essaye de deviner l'encodage des fichiers textes purs, mais c'est assez
souvent faux, bien entendu.
et dans les (nombreux) cas où c'est faux,
on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient
juste d'ouvrir par double-clic : il est même pas capable de nous le
mettre sous la main ... :-( ) ?
Si tu as double-cliqué sur l'icône du fichier, il ne doit pas être bien
loin, et dans ce cas un simple glisser/déposé de cette icône dans la fenêtre
d'ouverture de TextEdit le sélectionne.
on ne peut pas lui demander de relire le même fichier en utilisant un
autre encodage pour le décoder (comme on peut le faire avec
TextWrangler) ?
Si ton TextWrangler sait faire cela, et si cela t'es important (vu le titre
de ce message), alors il faut l'utiliser.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
[...] Soit le fichier est en texte "pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par exemple essaye de deviner l'encodage des fichiers textes purs, mais c'est assez souvent faux, bien entendu.
et dans les (nombreux) cas où c'est faux, on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient juste d'ouvrir par double-clic : il est même pas capable de nous le mettre sous la main ... :-( ) ?
Si tu as double-cliqué sur l'icône du fichier, il ne doit pas être bien loin, et dans ce cas un simple glisser/déposé de cette icône dans la fenêtre d'ouverture de TextEdit le sélectionne.
on ne peut pas lui demander de relire le même fichier en utilisant un autre encodage pour le décoder (comme on peut le faire avec TextWrangler) ?
Si ton TextWrangler sait faire cela, et si cela t'es important (vu le titre de ce message), alors il faut l'utiliser.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Thomas
In article <C4FAE726.D8BB7%, Eric Levenez wrote:
Le 20/09/08 16:53, dans , « Thomas » a écrit :
> In article <C4A662A2.D2BF2%, > Eric Levenez wrote: > >> [...] Soit le fichier est en texte >> "pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par >> exemple >> essaye de deviner l'encodage des fichiers textes purs, mais c'est assez >> souvent faux, bien entendu. > > et dans les (nombreux) cas où c'est faux, > on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient > juste d'ouvrir par double-clic : il est même pas capable de nous le > mettre sous la main ... :-( ) ?
Si tu as double-cliqué sur l'icône du fichier, il ne doit pas être bien loin, et dans ce cas un simple glisser/déposé de cette icône dans la fenêtre d'ouverture de TextEdit le sélectionne.
ok merci enfin ça reste moins pratique que tout en un clic ...
et c'est encore plus compliqué quand on ouvre un fichier en pj dans un msg, aussi
> on ne peut pas lui demander de relire le même fichier en utilisant un > autre encodage pour le décoder (comme on peut le faire avec > TextWrangler) ?
Si ton TextWrangler sait faire cela, et si cela t'es important (vu le titre de ce message), alors il faut l'utiliser.
c'est pas moi qui ai écrit le titre et c'est pour qqn qui veut lire mes fichiers (qui sont en utf-8) et qui ne veut pas forcement utiliser TextWrangler
mais bon, je vais lui indiquer les différentes possibilités :-)
In article <C4FAE726.D8BB7%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Le 20/09/08 16:53, dans
<fantome.forums.tDeContes-753338.16531420092008@news.free.fr>, « Thomas »
<fantome.forums.tDeContes@free.fr.invalid> a écrit :
> In article <C4A662A2.D2BF2%usenet@levenez.com>,
> Eric Levenez <usenet@levenez.com> wrote:
>
>> [...] Soit le fichier est en texte
>> "pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par
>> exemple
>> essaye de deviner l'encodage des fichiers textes purs, mais c'est assez
>> souvent faux, bien entendu.
>
> et dans les (nombreux) cas où c'est faux,
> on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient
> juste d'ouvrir par double-clic : il est même pas capable de nous le
> mettre sous la main ... :-( ) ?
Si tu as double-cliqué sur l'icône du fichier, il ne doit pas être bien
loin, et dans ce cas un simple glisser/déposé de cette icône dans la fenêtre
d'ouverture de TextEdit le sélectionne.
ok merci
enfin ça reste moins pratique que tout en un clic ...
et c'est encore plus compliqué quand on ouvre un fichier en pj dans un
msg, aussi
> on ne peut pas lui demander de relire le même fichier en utilisant un
> autre encodage pour le décoder (comme on peut le faire avec
> TextWrangler) ?
Si ton TextWrangler sait faire cela, et si cela t'es important (vu le titre
de ce message), alors il faut l'utiliser.
c'est pas moi qui ai écrit le titre
et c'est pour qqn qui veut lire mes fichiers (qui sont en utf-8) et qui
ne veut pas forcement utiliser TextWrangler
mais bon, je vais lui indiquer les différentes possibilités :-)
> In article <C4A662A2.D2BF2%, > Eric Levenez wrote: > >> [...] Soit le fichier est en texte >> "pur" et là rien ne peu indiquer l'encodage du contenu. TextEdit par >> exemple >> essaye de deviner l'encodage des fichiers textes purs, mais c'est assez >> souvent faux, bien entendu. > > et dans les (nombreux) cas où c'est faux, > on est obligé de faire "ouvrir" (et de rechercher le fichier qu'on vient > juste d'ouvrir par double-clic : il est même pas capable de nous le > mettre sous la main ... :-( ) ?
Si tu as double-cliqué sur l'icône du fichier, il ne doit pas être bien loin, et dans ce cas un simple glisser/déposé de cette icône dans la fenêtre d'ouverture de TextEdit le sélectionne.
ok merci enfin ça reste moins pratique que tout en un clic ...
et c'est encore plus compliqué quand on ouvre un fichier en pj dans un msg, aussi
> on ne peut pas lui demander de relire le même fichier en utilisant un > autre encodage pour le décoder (comme on peut le faire avec > TextWrangler) ?
Si ton TextWrangler sait faire cela, et si cela t'es important (vu le titre de ce message), alors il faut l'utiliser.
c'est pas moi qui ai écrit le titre et c'est pour qqn qui veut lire mes fichiers (qui sont en utf-8) et qui ne veut pas forcement utiliser TextWrangler
mais bon, je vais lui indiquer les différentes possibilités :-)
