J'ai des fichiers que je suppose avoir été écrits sous windows
et dont les accents ne passent pas dans TextEdit, BBedit , TexShop etc..
Dans TexEdit en choisissant Occidental( Windows Latin 1) je récupère
les accents, dans BBedit alors le décodage automatique ne fonctionne
pas, je dois lui indiquer à la main; même chose dans ItexMac et dans
Texshop je n'ai pas trouvé le windows Latin ?
Qui peut m'expliquer pourquoi les logiciels qui proposent de trouver
automatiquement l'encodage, ne le font pas ? c'est de la faute à qui ?
à moi ? au fichier ? au programme ?
Dans les informations du fichier, pourquoi n'a-t-on pas l'encodage ?
Existe-t-il une méthode genre script permettant de trouver l'encodage
utilisé dans un document, de le modifier le cas échéant ?
On peut bien sûr en tatonnant trouver l'encodage avec textedit puis
sauvegarder en le modifiant mais c'est lourd.
S' il y a une moulinette graphique qui fait cela, ce serait pas mal non
plus.
Le 20/12/03 0:24, dans <bs01c4$7ni8k$, « Ego » a écrit :
J'ai des fichiers que je suppose avoir été écrits sous windows et dont les accents ne passent pas dans TextEdit, BBedit , TexShop etc..
Dans TexEdit en choisissant Occidental( Windows Latin 1) je récupère les accents, dans BBedit alors le décodage automatique ne fonctionne pas, je dois lui indiquer à la main; même chose dans ItexMac et dans Texshop je n'ai pas trouvé le windows Latin ?
Qui peut m'expliquer pourquoi les logiciels qui proposent de trouver automatiquement l'encodage, ne le font pas ? c'est de la faute à qui ? à moi ? au fichier ? au programme ?
Ce n'est techniquement pas possible pour certains encodages. Il faut comprendre comment ça marche. Supposons donc un encodage 8 bits des caractères. Une suite de codes 8 bits sera affiché différemment suivant les encodages que l'on prend. Par exemple le code A4 dira Currency Sign en ISO-8859-1 (Latin 1), mais il dira Euro en Latin 15, ou IE en Ukrainien (ISO 8859-5). Comment un programme pourrait trouver cela tout seul ? Peut être avec une dictionnaire de toutes les langues de tous les pays, et en comparant le texte avec tous les encodages il pourrait trouver celui qui a un sens dans une langue donnée. Mais là c'est du décryptage, et ce n'est pas simple.
La détection automatique marche généralement pour des encodages type UTF-8 ou UTF-16 où les caractères on un encodage sur plusieurs octets, et il est possible de vérifier si le fichier respecte cet encodage.
Dans les informations du fichier, pourquoi n'a-t-on pas l'encodage ?
Parce que ce n'est pas une métadata standardisée. Certains document précisent en interne leur encodage, comme par exemple les pages HTML.
Existe-t-il une méthode genre script permettant de trouver l'encodage utilisé dans un document, de le modifier le cas échéant ?
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
On peut bien sûr en tatonnant trouver l'encodage avec textedit puis sauvegarder en le modifiant mais c'est lourd.
Oui, et tu fais ce travail de décryptage. Mais essaye de la faire avec du texte chinois, russe, danois, Lithuanien... tu auras plus de mal.
S' il y a une moulinette graphique qui fait cela, ce serait pas mal non plus.
Oui, ce serait bien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/12/03 0:24, dans <bs01c4$7ni8k$1@ID-216145.news.uni-berlin.de>,
« Ego » <ego@free.fr> a écrit :
J'ai des fichiers que je suppose avoir été écrits sous windows
et dont les accents ne passent pas dans TextEdit, BBedit , TexShop etc..
Dans TexEdit en choisissant Occidental( Windows Latin 1) je récupère
les accents, dans BBedit alors le décodage automatique ne fonctionne
pas, je dois lui indiquer à la main; même chose dans ItexMac et dans
Texshop je n'ai pas trouvé le windows Latin ?
Qui peut m'expliquer pourquoi les logiciels qui proposent de trouver
automatiquement l'encodage, ne le font pas ? c'est de la faute à qui ?
à moi ? au fichier ? au programme ?
Ce n'est techniquement pas possible pour certains encodages. Il faut
comprendre comment ça marche. Supposons donc un encodage 8 bits des
caractères. Une suite de codes 8 bits sera affiché différemment suivant les
encodages que l'on prend. Par exemple le code A4 dira Currency Sign en
ISO-8859-1 (Latin 1), mais il dira Euro en Latin 15, ou IE en Ukrainien (ISO
8859-5). Comment un programme pourrait trouver cela tout seul ? Peut être
avec une dictionnaire de toutes les langues de tous les pays, et en
comparant le texte avec tous les encodages il pourrait trouver celui qui a
un sens dans une langue donnée. Mais là c'est du décryptage, et ce n'est pas
simple.
La détection automatique marche généralement pour des encodages type UTF-8
ou UTF-16 où les caractères on un encodage sur plusieurs octets, et il est
possible de vérifier si le fichier respecte cet encodage.
Dans les informations du fichier, pourquoi n'a-t-on pas l'encodage ?
Parce que ce n'est pas une métadata standardisée. Certains document
précisent en interne leur encodage, comme par exemple les pages HTML.
Existe-t-il une méthode genre script permettant de trouver l'encodage
utilisé dans un document, de le modifier le cas échéant ?
Pour le trouver cela relève du décryptage, et pour le modifier, il y a
TextEdit en GUI ou iconv en CLI.
On peut bien sûr en tatonnant trouver l'encodage avec textedit puis
sauvegarder en le modifiant mais c'est lourd.
Oui, et tu fais ce travail de décryptage. Mais essaye de la faire avec du
texte chinois, russe, danois, Lithuanien... tu auras plus de mal.
S' il y a une moulinette graphique qui fait cela, ce serait pas mal non
plus.
Oui, ce serait bien.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/12/03 0:24, dans <bs01c4$7ni8k$, « Ego » a écrit :
J'ai des fichiers que je suppose avoir été écrits sous windows et dont les accents ne passent pas dans TextEdit, BBedit , TexShop etc..
Dans TexEdit en choisissant Occidental( Windows Latin 1) je récupère les accents, dans BBedit alors le décodage automatique ne fonctionne pas, je dois lui indiquer à la main; même chose dans ItexMac et dans Texshop je n'ai pas trouvé le windows Latin ?
Qui peut m'expliquer pourquoi les logiciels qui proposent de trouver automatiquement l'encodage, ne le font pas ? c'est de la faute à qui ? à moi ? au fichier ? au programme ?
Ce n'est techniquement pas possible pour certains encodages. Il faut comprendre comment ça marche. Supposons donc un encodage 8 bits des caractères. Une suite de codes 8 bits sera affiché différemment suivant les encodages que l'on prend. Par exemple le code A4 dira Currency Sign en ISO-8859-1 (Latin 1), mais il dira Euro en Latin 15, ou IE en Ukrainien (ISO 8859-5). Comment un programme pourrait trouver cela tout seul ? Peut être avec une dictionnaire de toutes les langues de tous les pays, et en comparant le texte avec tous les encodages il pourrait trouver celui qui a un sens dans une langue donnée. Mais là c'est du décryptage, et ce n'est pas simple.
La détection automatique marche généralement pour des encodages type UTF-8 ou UTF-16 où les caractères on un encodage sur plusieurs octets, et il est possible de vérifier si le fichier respecte cet encodage.
Dans les informations du fichier, pourquoi n'a-t-on pas l'encodage ?
Parce que ce n'est pas une métadata standardisée. Certains document précisent en interne leur encodage, comme par exemple les pages HTML.
Existe-t-il une méthode genre script permettant de trouver l'encodage utilisé dans un document, de le modifier le cas échéant ?
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
On peut bien sûr en tatonnant trouver l'encodage avec textedit puis sauvegarder en le modifiant mais c'est lourd.
Oui, et tu fais ce travail de décryptage. Mais essaye de la faire avec du texte chinois, russe, danois, Lithuanien... tu auras plus de mal.
S' il y a une moulinette graphique qui fait cela, ce serait pas mal non plus.
Oui, ce serait bien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
yotabaza_anti_spam_
Éric Lévénez wrote:
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en Mac OS Roman. Par contre il veut bien le faire en Windows Latin 1, qui est à quelques caractères près le même si j'ai bien suivi, ce qui permet de contourner le problème.
Pour le trouver cela relève du décryptage, et pour le modifier, il y a
TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en
Mac OS Roman.
Par contre il veut bien le faire en Windows Latin 1, qui est à quelques
caractères près le même si j'ai bien suivi, ce qui permet de contourner
le problème.
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en Mac OS Roman. Par contre il veut bien le faire en Windows Latin 1, qui est à quelques caractères près le même si j'ai bien suivi, ce qui permet de contourner le problème.
Le 20/12/03 12:46, dans <1g69nbz.1s86fos1v0991cN%, « Thomas Bazalgette » a écrit :
Éric Lévénez wrote:
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en Mac OS Roman. Par contre il veut bien le faire en Windows Latin 1, qui est à quelques caractères près le même si j'ai bien suivi, ce qui permet de contourner le problème.
Il y a une incompatibilité ou c'est un bug ?
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait peut-être cette vérification, et c'est bien. J'ai testé la conversion sous TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier ayant des caractères communs aux 2 encodages.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/12/03 12:46, dans
<1g69nbz.1s86fos1v0991cN%yotabaza_anti_spam_@ifrance.com.invalid>, « Thomas
Bazalgette » <yotabaza_anti_spam_@ifrance.com.invalid> a écrit :
Éric Lévénez <news@levenez.com> wrote:
Pour le trouver cela relève du décryptage, et pour le modifier, il y a
TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en
Mac OS Roman.
Par contre il veut bien le faire en Windows Latin 1, qui est à quelques
caractères près le même si j'ai bien suivi, ce qui permet de contourner
le problème.
Il y a une incompatibilité ou c'est un bug ?
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque
jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un
autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait
peut-être cette vérification, et c'est bien. J'ai testé la conversion sous
TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier
ayant des caractères communs aux 2 encodages.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/12/03 12:46, dans <1g69nbz.1s86fos1v0991cN%, « Thomas Bazalgette » a écrit :
Éric Lévénez wrote:
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en Mac OS Roman. Par contre il veut bien le faire en Windows Latin 1, qui est à quelques caractères près le même si j'ai bien suivi, ce qui permet de contourner le problème.
Il y a une incompatibilité ou c'est un bug ?
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait peut-être cette vérification, et c'est bien. J'ai testé la conversion sous TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier ayant des caractères communs aux 2 encodages.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
yotabaza_anti_spam_
Thomas Bazalgette wrote:
Éric Lévénez wrote:
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en Mac OS Roman. Par contre il veut bien le faire en Windows Latin 1, qui est à quelques caractères près le même si j'ai bien suivi, ce qui permet de contourner le problème.
Il y a une incompatibilité ou c'est un bug ?
Humm, je viens de réessayer en créant fichier Mac OS Roman avec TextEdit et il a bien voulu l'enregistrer en ISO Latin 1. Bizarre...
Le problème se posait avec des fichiers Word que j'exportais en texte depuis Word (qui ne donne pas le choix de l'encodage et met en MacOs Roman) pour les utiliser avec latex que j'ai configuré en ISO Latin 1. TextEdit ne voulait pas les passer en ISO Latin 1 (pas proposé dans la liste et si je forçait le choix l'enregistrement échouait).
Est-ce-que ce serait word qui encode un Mac OS Roman non conforme ???
Thomas Bazalgette <yotabaza_anti_spam_@ifrance.com.invalid> wrote:
Éric Lévénez <news@levenez.com> wrote:
Pour le trouver cela relève du décryptage, et pour le modifier, il y a
TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en
Mac OS Roman.
Par contre il veut bien le faire en Windows Latin 1, qui est à quelques
caractères près le même si j'ai bien suivi, ce qui permet de contourner
le problème.
Il y a une incompatibilité ou c'est un bug ?
Humm, je viens de réessayer en créant fichier Mac OS Roman avec TextEdit
et il a bien voulu l'enregistrer en ISO Latin 1. Bizarre...
Le problème se posait avec des fichiers Word que j'exportais en texte
depuis Word (qui ne donne pas le choix de l'encodage et met en MacOs
Roman) pour les utiliser avec latex que j'ai configuré en ISO Latin 1.
TextEdit ne voulait pas les passer en ISO Latin 1 (pas proposé dans la
liste et si je forçait le choix l'enregistrement échouait).
Est-ce-que ce serait word qui encode un Mac OS Roman non conforme ???
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
Chez moi TextEdit refuse de réenregistrer en ISO Latin 1 un fichier en Mac OS Roman. Par contre il veut bien le faire en Windows Latin 1, qui est à quelques caractères près le même si j'ai bien suivi, ce qui permet de contourner le problème.
Il y a une incompatibilité ou c'est un bug ?
Humm, je viens de réessayer en créant fichier Mac OS Roman avec TextEdit et il a bien voulu l'enregistrer en ISO Latin 1. Bizarre...
Le problème se posait avec des fichiers Word que j'exportais en texte depuis Word (qui ne donne pas le choix de l'encodage et met en MacOs Roman) pour les utiliser avec latex que j'ai configuré en ISO Latin 1. TextEdit ne voulait pas les passer en ISO Latin 1 (pas proposé dans la liste et si je forçait le choix l'enregistrement échouait).
Est-ce-que ce serait word qui encode un Mac OS Roman non conforme ???
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait peut-être cette vérification, et c'est bien. J'ai testé la conversion sous TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier ayant des caractères communs aux 2 encodages.
Ok pourtant c'était du texte tout ce qu'il y a de plus classique. Maintenant que j'y repense il me semble que c'étaient les apostrophes mises par Word qui posaient problème.
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque
jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un
autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait
peut-être cette vérification, et c'est bien. J'ai testé la conversion sous
TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier
ayant des caractères communs aux 2 encodages.
Ok pourtant c'était du texte tout ce qu'il y a de plus classique.
Maintenant que j'y repense il me semble que c'étaient les apostrophes
mises par Word qui posaient problème.
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait peut-être cette vérification, et c'est bien. J'ai testé la conversion sous TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier ayant des caractères communs aux 2 encodages.
Ok pourtant c'était du texte tout ce qu'il y a de plus classique. Maintenant que j'y repense il me semble que c'étaient les apostrophes mises par Word qui posaient problème.
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait peut-être cette vérification, et c'est bien. J'ai testé la conversion sous TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier ayant des caractères communs aux 2 encodages.
très bonne feature MAIS, est-ce que TextEdit donne la raison de son refus qd il y a perte ? peut-on passer outre ?
où as-tu appris cela ? -- Yvon Thoraval
Éric Lévénez <news@levenez.com> wrote:
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque
jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un
autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait
peut-être cette vérification, et c'est bien. J'ai testé la conversion sous
TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier
ayant des caractères communs aux 2 encodages.
très bonne feature MAIS, est-ce que TextEdit donne la raison de son
refus qd il y a perte ? peut-on passer outre ?
Bin non. Avec un codage 8 bits, il y a 256 caractères maximum dans chaque jeu (en fait moins). Alors si un caractère d'un jeu n'existe pas dans un autre encodage, la conversion sans perte ne peut avoir lieu. TextEdit fait peut-être cette vérification, et c'est bien. J'ai testé la conversion sous TextEdit de Mac OS Roman vers ISO Latin 1, et ça a marché avec un fichier ayant des caractères communs aux 2 encodages.
très bonne feature MAIS, est-ce que TextEdit donne la raison de son refus qd il y a perte ? peut-on passer outre ?
où as-tu appris cela ? -- Yvon Thoraval
Ego
Éric Lévénez a écrit:
Oui, et tu fais ce travail de décryptage. Mais essaye de la faire avec du texte chinois, russe, danois, Lithuanien... tu auras plus de mal.
S' il y a une moulinette graphique qui fait cela, ce serait pas mal non plus.
Oui, ce serait bien.
Sur la liste [Mac OS TEX] on m'a conseillé :
"Recoder" from http://www.nebulous.org/handy/
qui a l'air de fonctionner correctement !
A+ Ego
Éric Lévénez <news@levenez.com> a écrit:
Oui, et tu fais ce travail de décryptage. Mais essaye de la faire avec du
texte chinois, russe, danois, Lithuanien... tu auras plus de mal.
S' il y a une moulinette graphique qui fait cela, ce serait pas mal non
plus.
Oui, et tu fais ce travail de décryptage. Mais essaye de la faire avec du texte chinois, russe, danois, Lithuanien... tu auras plus de mal.
S' il y a une moulinette graphique qui fait cela, ce serait pas mal non plus.
Oui, ce serait bien.
Sur la liste [Mac OS TEX] on m'a conseillé :
"Recoder" from http://www.nebulous.org/handy/
qui a l'air de fonctionner correctement !
A+ Ego
yvon.thoravalNO
Éric Lévénez wrote:
Comment un programme pourrait trouver cela tout seul ?
franchement si le système était moins CON, il y aurait, dans l'en-tête du fichier l'encodage non ?
comme on a %pdf pour le pdf
la "norme" des fichiers aurait du prévoir une mension de l'encodage, aucun logiciel n'aurait eu à deviner...
d'ailleurs ca ne marche pas pour le html, quand on spécifie l'encodage dans le fichier, le navigateur, safari, s'il est en auto, peut très bien choisir autre chose.
perso je trouve ça très bizarre que cela n'ait pas été prévu... -- Yvon Thoraval
Éric Lévénez <news@levenez.com> wrote:
Comment un programme pourrait trouver cela tout seul ?
franchement si le système était moins CON, il y aurait, dans l'en-tête
du fichier l'encodage non ?
comme on a %pdf pour le pdf
la "norme" des fichiers aurait du prévoir une mension de l'encodage,
aucun logiciel n'aurait eu à deviner...
d'ailleurs ca ne marche pas pour le html, quand on spécifie l'encodage
dans le fichier, le navigateur, safari, s'il est en auto, peut très bien
choisir autre chose.
perso je trouve ça très bizarre que cela n'ait pas été prévu...
--
Yvon Thoraval
Comment un programme pourrait trouver cela tout seul ?
franchement si le système était moins CON, il y aurait, dans l'en-tête du fichier l'encodage non ?
comme on a %pdf pour le pdf
la "norme" des fichiers aurait du prévoir une mension de l'encodage, aucun logiciel n'aurait eu à deviner...
d'ailleurs ca ne marche pas pour le html, quand on spécifie l'encodage dans le fichier, le navigateur, safari, s'il est en auto, peut très bien choisir autre chose.
perso je trouve ça très bizarre que cela n'ait pas été prévu... -- Yvon Thoraval
yvon.thoravalNO
Éric Lévénez wrote:
Existe-t-il une méthode genre script permettant de trouver l'encodage utilisé dans un document, de le modifier le cas échéant ?
Pour le trouver cela relève du décryptage, et pour le modifier, il y a TextEdit en GUI ou iconv en CLI.
TextEdit ne marche pas dès qu'il y a une erreur d'encodage, il vaut mieux utiliser Pepper...
-- Yvon Thoraval
Éric Lévénez <news@levenez.com> wrote:
Existe-t-il une méthode genre script permettant de trouver l'encodage
utilisé dans un document, de le modifier le cas échéant ?
Pour le trouver cela relève du décryptage, et pour le modifier, il y a
TextEdit en GUI ou iconv en CLI.
TextEdit ne marche pas dès qu'il y a une erreur d'encodage, il vaut
mieux utiliser Pepper...
