OVH Cloud OVH Cloud

TextEdit et encodage

4 réponses
Avatar
romer
Hi,

J'envoie un fichier texte encodé en unicode utf-8 et un ami qui a
TextEdit peut difficilement le lire car le texte et la mise ne page
apparaissent comme de la bouillie pour chat.
Explications au téléphone pour lui expliquer qu'il suffit qu'il règle
l'ouverture de fichiers en utf-8. Et évidemment ça a fonctionné.

Mais alors pourquoi ne pas avoir fait une reconnaissance automatique de
l'encodage. Est-ce complexe à faire ou même imposssible ?
Cela simplifierait les choses...
--
A+

Romer

4 réponses

Avatar
filh
Bernd wrote:

Mais alors pourquoi ne pas avoir fait une reconnaissance automatique de
l'encodage. Est-ce complexe à faire ou même imposssible ?
Cela simplifierait les choses...


Théoriquement c'est impossible.

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

Avatar
Eric Levenez
Le 9/07/06 10:15, dans <1hi7dk4.1kgfe5u1ixjb3hN%,
« Bernd » a écrit :

Est-ce complexe à faire ou même imposssible ?


Les 2 mon capitaine. Un fichier avec un encodage 8 bits (style ISO 8859-1)
est une suite d'octets qui peuvent prendre des valeurs de 0 à 255. Un
fichier avec un encodage UTF-8 est aussi une suite d'octets, mais avec des
limites (certaines séquences sont invalides et ne devraient pas
apparaîtrent). Alors en théorie il est possible de soupçonner un encodage
UTF-8 (en regardant si l'encodage est conforme et sans erreur de séquence),
mais en pratique une telle suite valide en UTF-8 peut aussi représenter
n'importe quel encodage ISO 8859 (par exemple).

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Avatar
romer
Eric Levenez wrote:

Les 2 mon capitaine. Un fichier avec un encodage 8 bits (style ISO 8859-1)
est une suite d'octets qui peuvent prendre des valeurs de 0 à 255. Un
fichier avec un encodage UTF-8 est aussi une suite d'octets, mais avec des
limites (certaines séquences sont invalides et ne devraient pas
apparaîtrent). Alors en théorie il est possible de soupçonner un encodage
UTF-8 (en regardant si l'encodage est conforme et sans erreur de séquence),
mais en pratique une telle suite valide en UTF-8 peut aussi représenter
n'importe quel encodage ISO 8859 (par exemple).


Thanks - Bien dommage. Mais à la suite de ces quelques échanges je viens
de faire un petit test avec BBedit pour en avoir le coeur net. En effet
si l'encodage d'ouverture n'est pas spécifié comme étant le même que
celui du fichier récupéré, ça ne marche pas.

--
A+

Romer

Avatar
Eric Levenez
Le 9/07/06 11:33, dans
<1hi7hb9.17whrk0zxbf9cN%jose.campos+, « José Campos »
<jose.campos+ a écrit :

Y a-t-il des raisons historiques qui font que les fichiers "texte"
ne comportent pas d'en-tête (comme les fichiers "graphiques" ou HTML)
qui pourraient en indiquer le codage?


Historiquement sous unix, un fichier texte n'est qu'une suite d'octets.
Aucun en-tête, aucune données cachées dans des ressources ou dans le nom du
fichier, rien ne peut indiquer l'encodage du texte, ni même si c'est du
texte ou du binaire.

C'est pour cela que si l'on veut sous unix créer un fichier de texte avec un
encodage donné, il faut créer une structure _dans_ le fichier texte comme le
fait le HTML, le RTF ou tout autre format de fichier.

Ceci est identique à ce qui se passe avec un fichier image : c'est dans le
contenu du fichier que l'on trouve la structure et l'encodage de l'image.
Idem pour un fichier son.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.