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 13:00, dans <1g69nvp.lcm7jee4wnpsN%, « Thomas Bazalgette » a écrit :
Est-ce-que ce serait word qui encode un Mac OS Roman non conforme ???
Cela n'a pas de sens, toutes suite d'octets est conforme dans tous les encodages 8 bits, et donc toute suite d'octets peut représenter du Mac OS Roman. Cela n'est pas le cas en UTF-8.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/12/03 13:00, dans
<1g69nvp.lcm7jee4wnpsN%yotabaza_anti_spam_@ifrance.com.invalid>, « Thomas
Bazalgette » <yotabaza_anti_spam_@ifrance.com.invalid> a écrit :
Est-ce-que ce serait word qui encode un Mac OS Roman non conforme ???
Cela n'a pas de sens, toutes suite d'octets est conforme dans tous les
encodages 8 bits, et donc toute suite d'octets peut représenter du Mac OS
Roman. Cela n'est pas le cas en UTF-8.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/12/03 13:00, dans <1g69nvp.lcm7jee4wnpsN%, « Thomas Bazalgette » a écrit :
Est-ce-que ce serait word qui encode un Mac OS Roman non conforme ???
Cela n'a pas de sens, toutes suite d'octets est conforme dans tous les encodages 8 bits, et donc toute suite d'octets peut représenter du Mac OS Roman. Cela n'est pas le cas en UTF-8.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 20/12/03 13:06, dans <1g69o89.12hhqujkfr2f3N%, « Thomas Bazalgette » a écrit :
Éric Lévénez 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.
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.
Il y a des apostrophes qui sont codables en Unicode, mais pas sous certains encodages 8 bits, effectivement.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/12/03 13:06, dans
<1g69o89.12hhqujkfr2f3N%yotabaza_anti_spam_@ifrance.com.invalid>, « Thomas
Bazalgette » <yotabaza_anti_spam_@ifrance.com.invalid> a écrit :
É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.
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.
Il y a des apostrophes qui sont codables en Unicode, mais pas sous certains
encodages 8 bits, effectivement.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/12/03 13:06, dans <1g69o89.12hhqujkfr2f3N%, « Thomas Bazalgette » a écrit :
Éric Lévénez 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.
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.
Il y a des apostrophes qui sont codables en Unicode, mais pas sous certains encodages 8 bits, effectivement.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 20/12/03 13:15, dans <1g69olq.dyzhqw1pcpdp0N%, « Yvon Thoraval » a écrit :
Éric Lévénez 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 ?
où as-tu appris cela ?
Appris quoi ? J'ai dit "peut-être". Pour le palpage UTF-8, quand ça merde, le texte décodé est vide. Un exemple est l'historique des mises à jour sous Panther qui n'arrive pas à lire le fichier Jaguar encodé différemment.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/12/03 13:15, dans
<1g69olq.dyzhqw1pcpdp0N%yvon.thoravalNO@SPAMfree.fr>, « Yvon Thoraval »
<yvon.thoravalNO@SPAMfree.fr> a écrit :
É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 ?
où as-tu appris cela ?
Appris quoi ? J'ai dit "peut-être". Pour le palpage UTF-8, quand ça merde,
le texte décodé est vide. Un exemple est l'historique des mises à jour sous
Panther qui n'arrive pas à lire le fichier Jaguar encodé différemment.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/12/03 13:15, dans <1g69olq.dyzhqw1pcpdp0N%, « Yvon Thoraval » a écrit :
Éric Lévénez 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 ?
où as-tu appris cela ?
Appris quoi ? J'ai dit "peut-être". Pour le palpage UTF-8, quand ça merde, le texte décodé est vide. Un exemple est l'historique des mises à jour sous Panther qui n'arrive pas à lire le fichier Jaguar encodé différemment.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 20/12/03 13:19, dans <1g69or8.hcu5lkegpfy8N%, « Yvon Thoraval » a écrit :
É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 ?
Quel rapport entre le système et un fichier texte qui n'est qu'une suite d'octets ?
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...
Comme tu le dis, certains types de fichiers définissent cet encodage. Mais il n'y a pas de norme de fichiers valable pour tous les fichiers sur toutes les platformes.
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.
Où as-tu vu cela ? Jamais eu de problème.
perso je trouve ça très bizarre que cela n'ait pas été prévu...
Prévu où, par qui, par quoi, comment ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/12/03 13:19, dans <1g69or8.hcu5lkegpfy8N%yvon.thoravalNO@SPAMfree.fr>,
« Yvon Thoraval » <yvon.thoravalNO@SPAMfree.fr> a écrit :
É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 ?
Quel rapport entre le système et un fichier texte qui n'est qu'une suite
d'octets ?
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...
Comme tu le dis, certains types de fichiers définissent cet encodage. Mais
il n'y a pas de norme de fichiers valable pour tous les fichiers sur toutes
les platformes.
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.
Où as-tu vu cela ? Jamais eu de problème.
perso je trouve ça très bizarre que cela n'ait pas été prévu...
Prévu où, par qui, par quoi, comment ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/12/03 13:19, dans <1g69or8.hcu5lkegpfy8N%, « Yvon Thoraval » a écrit :
É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 ?
Quel rapport entre le système et un fichier texte qui n'est qu'une suite d'octets ?
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...
Comme tu le dis, certains types de fichiers définissent cet encodage. Mais il n'y a pas de norme de fichiers valable pour tous les fichiers sur toutes les platformes.
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.
Où as-tu vu cela ? Jamais eu de problème.
perso je trouve ça très bizarre que cela n'ait pas été prévu...
Prévu où, par qui, par quoi, comment ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 20/12/03 13:19, dans <1g69oyt.1fcquxq1i5cbd4N%, « Yvon Thoraval » a écrit :
É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...
Là on parle d'UTF-8 et autres encodages du même type. Cela indique donc qu'il faut choisir un autre encodage, du type 8 bits.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/12/03 13:19, dans
<1g69oyt.1fcquxq1i5cbd4N%yvon.thoravalNO@SPAMfree.fr>, « Yvon Thoraval »
<yvon.thoravalNO@SPAMfree.fr> a écrit :
É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...
Là on parle d'UTF-8 et autres encodages du même type. Cela indique donc
qu'il faut choisir un autre encodage, du type 8 bits.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
cette feature de TextEdit qui ne convertit pas si perte ? -- Yvon Thoraval
yvon.thoravalNO
Éric Lévénez wrote:
franchement si le système était moins CON, il y aurait, dans l'en-tête du fichier l'encodage non ?
Quel rapport entre le système et un fichier texte qui n'est qu'une suite d'octets ?
je ne parlais pas du système comme operating system, mais dy "système de fichiers" (vacabulaire peu approprié).
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...
Comme tu le dis, certains types de fichiers définissent cet encodage. Mais il n'y a pas de norme de fichiers valable pour tous les fichiers sur toutes les platformes.
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.
Où as-tu vu cela ? Jamais eu de problème.
je pense que cela arrive très souvent, sur mozilla aussi, peut-être est-ce lié à l'absence concommitente de doctype ?
perso je trouve ça très bizarre que cela n'ait pas été prévu...
Prévu où, par qui, par quoi, comment ?
par une norme, comme il y a une norme pour l'utf-8 ou l'iso-8859-1, par exemple, cette norme aurait du prévoir que les encodés en utf-8 le précise qqpart ? comme éventuellement le bom.
-- Yvon Thoraval
Éric Lévénez <news@levenez.com> wrote:
franchement si le système était moins CON, il y aurait, dans l'en-tête
du fichier l'encodage non ?
Quel rapport entre le système et un fichier texte qui n'est qu'une suite
d'octets ?
je ne parlais pas du système comme operating system, mais dy "système de
fichiers" (vacabulaire peu approprié).
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...
Comme tu le dis, certains types de fichiers définissent cet encodage. Mais
il n'y a pas de norme de fichiers valable pour tous les fichiers sur toutes
les platformes.
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.
Où as-tu vu cela ? Jamais eu de problème.
je pense que cela arrive très souvent, sur mozilla aussi, peut-être
est-ce lié à l'absence concommitente de doctype ?
perso je trouve ça très bizarre que cela n'ait pas été prévu...
Prévu où, par qui, par quoi, comment ?
par une norme, comme il y a une norme pour l'utf-8 ou l'iso-8859-1, par
exemple, cette norme aurait du prévoir que les encodés en utf-8 le
précise qqpart ? comme éventuellement le bom.
franchement si le système était moins CON, il y aurait, dans l'en-tête du fichier l'encodage non ?
Quel rapport entre le système et un fichier texte qui n'est qu'une suite d'octets ?
je ne parlais pas du système comme operating system, mais dy "système de fichiers" (vacabulaire peu approprié).
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...
Comme tu le dis, certains types de fichiers définissent cet encodage. Mais il n'y a pas de norme de fichiers valable pour tous les fichiers sur toutes les platformes.
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.
Où as-tu vu cela ? Jamais eu de problème.
je pense que cela arrive très souvent, sur mozilla aussi, peut-être est-ce lié à l'absence concommitente de doctype ?
perso je trouve ça très bizarre que cela n'ait pas été prévu...
Prévu où, par qui, par quoi, comment ?
par une norme, comme il y a une norme pour l'utf-8 ou l'iso-8859-1, par exemple, cette norme aurait du prévoir que les encodés en utf-8 le précise qqpart ? comme éventuellement le bom.
-- Yvon Thoraval
yotabaza_anti_spam_
Éric Lévénez wrote:
Il y a des apostrophes qui sont codables en Unicode, mais pas sous certains encodages 8 bits, effectivement.
Voilà, c'est ça.
J'ai retrouvé un document Word : je le converti Mac OS Roman dans TextEdit, les apostrophes sont comme ça : ' Résultat, impossible d'enregistrer en ISO Latin 1.
Si je change l'apostrope en : ' , aucun problème pour convertir en ISO Latin 1
Par contre dans le premier cas je peux enregistrer en Windows Latin 1. Ça veut dire que Windows Latin 1 contient cette apostrophe spéciale mais pas ISO Latin 1 ?
Il y a des apostrophes qui sont codables en Unicode, mais pas sous certains
encodages 8 bits, effectivement.
Voilà, c'est ça.
J'ai retrouvé un document Word : je le converti Mac OS Roman dans
TextEdit, les apostrophes sont comme ça : '
Résultat, impossible d'enregistrer en ISO Latin 1.
Si je change l'apostrope en : ' , aucun problème pour convertir en ISO
Latin 1
Par contre dans le premier cas je peux enregistrer en Windows Latin 1.
Ça veut dire que Windows Latin 1 contient cette apostrophe spéciale mais
pas ISO Latin 1 ?
Il y a des apostrophes qui sont codables en Unicode, mais pas sous certains encodages 8 bits, effectivement.
Voilà, c'est ça.
J'ai retrouvé un document Word : je le converti Mac OS Roman dans TextEdit, les apostrophes sont comme ça : ' Résultat, impossible d'enregistrer en ISO Latin 1.
Si je change l'apostrope en : ' , aucun problème pour convertir en ISO Latin 1
Par contre dans le premier cas je peux enregistrer en Windows Latin 1. Ça veut dire que Windows Latin 1 contient cette apostrophe spéciale mais pas ISO Latin 1 ?
