Lorsque je mets des accents dans mes chaines de caractères, j'ai un warning généré par python. Normal.
J'aimerais supprimer ce warning mais je n'y arrive pas.
Je suis sous windows. J'utilise Eclipse 3.1 avec le plug-in PyDev.
Je mets le commentaire qui va bien au début de mon fichier pour dire que j'ai des caractères de type UTF-8. J'enregistre mon fichier au format UTF-8 (ou du moins je pense que c'est le cas). J'ai bien mes caractères accentués dans le fichier source mais à l'exécution j'ai 2 caractères bizarres à chaque lettre accentuée. Je suppose que ces deux caractères correspondent au code UTF-8 non "décodé". Ce qui est étrange c'est que dès que je mets le commentaire de type d'encodage au début du fichier, Eclipse sauvegarde automatiquement le fichier dans le nouvel encodage. Comme si Eclipse connaissait cette "instruction". Peut-être que c'est PyDev qui fait ça ?
Quelqu'un a t-il déjà eu ce genre problème ? Et éventuellement une solution ?
Si tu veux des accents les chaînes Unicode sont la (meilleure) solution.
Ça confirme les bonnes pratiques qu'on lit maintenant et les changements possibles pour les futures versions de Python.
La présentation de la conférence donnée par l'expert sur la question, Marc-André Lemburg aux RMLL 2005 : http://www.egenix.com/files/python/LSM2005-Developing-Unicode-aware-applications-in-Python.pdf
-- Hervé Cauwelier http://www.oursours.net/
Si tu veux des accents les chaînes Unicode
sont la (meilleure) solution.
Ça confirme les bonnes pratiques qu'on lit maintenant et les changements
possibles pour les futures versions de Python.
La présentation de la conférence donnée par l'expert sur la question,
Marc-André Lemburg aux RMLL 2005 :
http://www.egenix.com/files/python/LSM2005-Developing-Unicode-aware-applications-in-Python.pdf
Si tu veux des accents les chaînes Unicode sont la (meilleure) solution.
Ça confirme les bonnes pratiques qu'on lit maintenant et les changements possibles pour les futures versions de Python.
La présentation de la conférence donnée par l'expert sur la question, Marc-André Lemburg aux RMLL 2005 : http://www.egenix.com/files/python/LSM2005-Developing-Unicode-aware-applications-in-Python.pdf
-- Hervé Cauwelier http://www.oursours.net/
Sylvain Thenault
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Do Re Mi chel La Si Do wrote:
...ça reconnait la différence entre de utf-8 et de l'iso-8859-1
A condition que le fichier UTF-8 ait été enregistré sous une forme respectueuse (cf les 4 premiers octets).
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte (-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou little endian pour un encodage sur un byte. L'ajout systématique d'un "BOM" (qui n'en n'est en fait pas un...) au début des fichiers encodés en UTF-8 est une spécialité MS Windows - et peut s'avérer une parfaite nuisance sur d'autres systèmes. Bref, ce n'est en rien une "forme respectueuse" en ce qui concerne l'UTF-8.
ça doit pourtant pouvoir servir, UTF-8 étant un encodage à taille variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le latin1, et 4 pour les autres).
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Do Re Mi chel La Si Do wrote:
...ça reconnait la différence entre de utf-8 et de l'iso-8859-1
A condition que le fichier UTF-8 ait été enregistré sous une forme
respectueuse (cf les 4 premiers octets).
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à
préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte
(-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou
little endian pour un encodage sur un byte. L'ajout systématique d'un
"BOM" (qui n'en n'est en fait pas un...) au début des fichiers encodés
en UTF-8 est une spécialité MS Windows - et peut s'avérer une parfaite
nuisance sur d'autres systèmes. Bref, ce n'est en rien une "forme
respectueuse" en ce qui concerne l'UTF-8.
ça doit pourtant pouvoir servir, UTF-8 étant un encodage à taille
variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le
latin1, et 4 pour les autres).
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Do Re Mi chel La Si Do wrote:
...ça reconnait la différence entre de utf-8 et de l'iso-8859-1
A condition que le fichier UTF-8 ait été enregistré sous une forme respectueuse (cf les 4 premiers octets).
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte (-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou little endian pour un encodage sur un byte. L'ajout systématique d'un "BOM" (qui n'en n'est en fait pas un...) au début des fichiers encodés en UTF-8 est une spécialité MS Windows - et peut s'avérer une parfaite nuisance sur d'autres systèmes. Bref, ce n'est en rien une "forme respectueuse" en ce qui concerne l'UTF-8.
ça doit pourtant pouvoir servir, UTF-8 étant un encodage à taille variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le latin1, et 4 pour les autres).
Mais ce n'est pas un bug. Si tu veux des accents les chaînes Unicode sont la (meilleure) solution.
Les choses sont claires maintenant.
bruno modulix
Sylvain Thenault wrote:
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Do Re Mi chel La Si Do wrote:
...ça reconnait la différence entre de utf-8 et de l'iso-8859-1
A condition que le fichier UTF-8 ait été enregistré sous une forme respectueuse (cf les 4 premiers octets).
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte (-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou little endian pour un encodage sur un byte. (snip)
ça doit pourtant pouvoir servir,
Pas pour le Byte Order...
UTF-8 étant un encodage à taille variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le latin1, et 4 pour les autres).
Le système d'encodage d'UTF-8 est indépendant de l'ordre des bytes, cf
http://www.unicode.org/faq/utf_bom.html#3
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Sylvain Thenault wrote:
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Do Re Mi chel La Si Do wrote:
...ça reconnait la différence entre de utf-8 et de l'iso-8859-1
A condition que le fichier UTF-8 ait été enregistré sous une forme
respectueuse (cf les 4 premiers octets).
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à
préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte
(-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou
little endian pour un encodage sur un byte.
(snip)
ça doit pourtant pouvoir servir,
Pas pour le Byte Order...
UTF-8 étant un encodage à taille
variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le
latin1, et 4 pour les autres).
Le système d'encodage d'UTF-8 est indépendant de l'ordre des bytes, cf
http://www.unicode.org/faq/utf_bom.html#3
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Do Re Mi chel La Si Do wrote:
...ça reconnait la différence entre de utf-8 et de l'iso-8859-1
A condition que le fichier UTF-8 ait été enregistré sous une forme respectueuse (cf les 4 premiers octets).
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte (-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou little endian pour un encodage sur un byte. (snip)
ça doit pourtant pouvoir servir,
Pas pour le Byte Order...
UTF-8 étant un encodage à taille variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le latin1, et 4 pour les autres).
Le système d'encodage d'UTF-8 est indépendant de l'ordre des bytes, cf
http://www.unicode.org/faq/utf_bom.html#3
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Sylvain Thenault
On Tue, 23 Aug 2005 14:32:51 +0200, bruno modulix wrote:
Sylvain Thenault wrote:
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte (-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou little endian pour un encodage sur un byte. (snip)
ça doit pourtant pouvoir servir,
Pas pour le Byte Order...
UTF-8 étant un encodage à taille variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le latin1, et 4 pour les autres).
Le système d'encodage d'UTF-8 est indépendant de l'ordre des bytes, cf
http://www.unicode.org/faq/utf_bom.html#3
je vois je vois, merci pour la correction. -- Sylvain Thénault LOGILAB, Paris (France).
On Tue, 23 Aug 2005 14:32:51 +0200, bruno modulix wrote:
Sylvain Thenault wrote:
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à
préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte
(-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou
little endian pour un encodage sur un byte.
(snip)
ça doit pourtant pouvoir servir,
Pas pour le Byte Order...
UTF-8 étant un encodage à taille
variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le
latin1, et 4 pour les autres).
Le système d'encodage d'UTF-8 est indépendant de l'ordre des bytes, cf
http://www.unicode.org/faq/utf_bom.html#3
je vois je vois, merci pour la correction.
--
Sylvain Thénault LOGILAB, Paris (France).
On Tue, 23 Aug 2005 14:32:51 +0200, bruno modulix wrote:
Sylvain Thenault wrote:
On Tue, 23 Aug 2005 11:29:10 +0200, bruno modulix wrote:
Le Byte Order Mark sert à l'origine - et comme son nom l'indique - à préciser l'ordre des bytes quand l'encodage se fait sur plus d'un byte (-> utf-16 et plus) - il n'y a pas lieu de préciser si on est en big ou little endian pour un encodage sur un byte. (snip)
ça doit pourtant pouvoir servir,
Pas pour le Byte Order...
UTF-8 étant un encodage à taille variable, de 1 à 4 octets (1 octet pour les caractères ascii, 2 pour le latin1, et 4 pour les autres).
Le système d'encodage d'UTF-8 est indépendant de l'ordre des bytes, cf
http://www.unicode.org/faq/utf_bom.html#3
je vois je vois, merci pour la correction. -- Sylvain Thénault LOGILAB, Paris (France).
Attention à ne pas confondre l'encodage, et l'affichage.
Si un caractère "é" apparaît correctement dans le code-source, c'est que l'éditeur est capable de l'afficher sous cette forme. Lorsqu'il est enregistré dans le fichier, il occupe 1 ou 2 octets, selon l'encodage du fichier-source. Python connaît cet encodage, ce qui lui permet de gérer le caractère.
Lorsque Python effectue un print, il envoie une chaîne d'octets (1 ou 2), sur la sortie. Si l'affichage, à ce stade, semble incorrect, c'est un problème d'adéquation entre Python et le dispositif de sortie.
En allant plus loin, il se peut, aussi, que la sortie puisse comprendre le caractère, mais soit incapable de l'afficher. C'est un cas très fréquent, avec les consoles, aussi bien sous windows que sous linux, ou sous d'autres OS.
Donc, je me répète, il ne s'agit pas d'un problème Python, mais de concordance, entre Python et le dispositif de sortie.
@-salutations
Michel Claveau
Bonjour !
Alors pourquoi ce caractère "é" s'affiche mal
Attention à ne pas confondre l'encodage, et l'affichage.
Si un caractère "é" apparaît correctement dans le code-source, c'est que
l'éditeur est capable de l'afficher sous cette forme. Lorsqu'il est
enregistré dans le fichier, il occupe 1 ou 2 octets, selon l'encodage du
fichier-source. Python connaît cet encodage, ce qui lui permet de gérer le
caractère.
Lorsque Python effectue un print, il envoie une chaîne d'octets (1 ou 2),
sur la sortie. Si l'affichage, à ce stade, semble incorrect, c'est un
problème d'adéquation entre Python et le dispositif de sortie.
En allant plus loin, il se peut, aussi, que la sortie puisse comprendre le
caractère, mais soit incapable de l'afficher. C'est un cas très fréquent,
avec les consoles, aussi bien sous windows que sous linux, ou sous d'autres
OS.
Donc, je me répète, il ne s'agit pas d'un problème Python, mais de
concordance, entre Python et le dispositif de sortie.
Attention à ne pas confondre l'encodage, et l'affichage.
Si un caractère "é" apparaît correctement dans le code-source, c'est que l'éditeur est capable de l'afficher sous cette forme. Lorsqu'il est enregistré dans le fichier, il occupe 1 ou 2 octets, selon l'encodage du fichier-source. Python connaît cet encodage, ce qui lui permet de gérer le caractère.
Lorsque Python effectue un print, il envoie une chaîne d'octets (1 ou 2), sur la sortie. Si l'affichage, à ce stade, semble incorrect, c'est un problème d'adéquation entre Python et le dispositif de sortie.
En allant plus loin, il se peut, aussi, que la sortie puisse comprendre le caractère, mais soit incapable de l'afficher. C'est un cas très fréquent, avec les consoles, aussi bien sous windows que sous linux, ou sous d'autres OS.
Donc, je me répète, il ne s'agit pas d'un problème Python, mais de concordance, entre Python et le dispositif de sortie.
@-salutations
Michel Claveau
Do Re Mi chel La Si Do
Bonsoir
au début des fichiers encodés en UTF-8 est une spécialité MS Windows
Qui écrit le début des fichiers ? Des programmes (éditeurs, IDE, langages, etc.). Python lui-même ajoute le BOM, lorsque l'on "write" un fichier. Windows n'a rien à voir avec ça. La citation est intempestive.
D'autre part, moi, j'apprécie beaucoup ce BOM. Sinon, lorsque j'ai un fichier ANSI, qui contient, parmi d'autres caractères, un "A majuscule tilde", et en l'absence de BOM, comment un éditeur saurait-il que ce n'est pas de l'UTF-8 ?
Comment, en l'absence de BOM, distinguer un fichier ASCII (low), d'un UTF-8 ? Bon d'accord, le contenu est identique. Mais le risque, c'est lors de l'ajout de caractère accentués (par exemple), si l'on ne fait pas attention à l'encodage qu'à retenu l'éditeur. Je me suis déjà fait avoir plusieurs fois à ce piège...
@-salutations
Michel Claveau
Bonsoir
au début des fichiers encodés en UTF-8 est une spécialité MS Windows
Qui écrit le début des fichiers ? Des programmes (éditeurs, IDE, langages,
etc.). Python lui-même ajoute le BOM, lorsque l'on "write" un fichier.
Windows n'a rien à voir avec ça. La citation est intempestive.
D'autre part, moi, j'apprécie beaucoup ce BOM. Sinon, lorsque j'ai un
fichier ANSI, qui contient, parmi d'autres caractères, un "A majuscule
tilde", et en l'absence de BOM, comment un éditeur saurait-il que ce n'est
pas de l'UTF-8 ?
Comment, en l'absence de BOM, distinguer un fichier ASCII (low), d'un UTF-8
? Bon d'accord, le contenu est identique. Mais le risque, c'est lors de
l'ajout de caractère accentués (par exemple), si l'on ne fait pas attention
à l'encodage qu'à retenu l'éditeur. Je me suis déjà fait avoir plusieurs
fois à ce piège...
au début des fichiers encodés en UTF-8 est une spécialité MS Windows
Qui écrit le début des fichiers ? Des programmes (éditeurs, IDE, langages, etc.). Python lui-même ajoute le BOM, lorsque l'on "write" un fichier. Windows n'a rien à voir avec ça. La citation est intempestive.
D'autre part, moi, j'apprécie beaucoup ce BOM. Sinon, lorsque j'ai un fichier ANSI, qui contient, parmi d'autres caractères, un "A majuscule tilde", et en l'absence de BOM, comment un éditeur saurait-il que ce n'est pas de l'UTF-8 ?
Comment, en l'absence de BOM, distinguer un fichier ASCII (low), d'un UTF-8 ? Bon d'accord, le contenu est identique. Mais le risque, c'est lors de l'ajout de caractère accentués (par exemple), si l'on ne fait pas attention à l'encodage qu'à retenu l'éditeur. Je me suis déjà fait avoir plusieurs fois à ce piège...
@-salutations
Michel Claveau
nico
Bonjour !
Alors pourquoi ce caractère "é" s'affiche mal
Attention à ne pas confondre l'encodage, et l'affichage.
Si un caractère "é" apparaît correctement dans le code-source, c'est que l'éditeur est capable de l'afficher sous cette forme. Lorsqu'il est enregistré dans le fichier, il occupe 1 ou 2 octets, selon l'encodage du fichier-source. Python connaît cet encodage, ce qui lui permet de gérer le caractère.
Lorsque Python effectue un print, il envoie une chaîne d'octets (1 ou 2), sur la sortie. Si l'affichage, à ce stade, semble incorrect, c'est un problème d'adéquation entre Python et le dispositif de sortie.
En allant plus loin, il se peut, aussi, que la sortie puisse comprendre le caractère, mais soit incapable de l'afficher. C'est un cas très fréquent, avec les consoles, aussi bien sous windows que sous linux, ou sous d'autres OS.
Donc, je me répète, il ne s'agit pas d'un problème Python, mais de concordance, entre Python et le dispositif de sortie.
@-salutations
Michel Claveau
Ah non ! Là, il s'agit bien d'un problème de language. Si la chaine de caractères n'est pas déclarée unicode, Python interprète tout le contenu binaire formant la chaine de caractères comme de l'ASCII. Quelquesoit l'encodage du fichier. Alors que si l'on déclare la chaine de caractère en unicode, Python interprète bien son contenu. Je trouve ça plutôt limite bug. Mais une fois qu'on le sait, y a plus de problèmes.
Nicolas
Bonjour !
Alors pourquoi ce caractère "é" s'affiche mal
Attention à ne pas confondre l'encodage, et l'affichage.
Si un caractère "é" apparaît correctement dans le code-source, c'est que
l'éditeur est capable de l'afficher sous cette forme. Lorsqu'il est
enregistré dans le fichier, il occupe 1 ou 2 octets, selon l'encodage du
fichier-source. Python connaît cet encodage, ce qui lui permet de gérer le
caractère.
Lorsque Python effectue un print, il envoie une chaîne d'octets (1 ou 2),
sur la sortie. Si l'affichage, à ce stade, semble incorrect, c'est un
problème d'adéquation entre Python et le dispositif de sortie.
En allant plus loin, il se peut, aussi, que la sortie puisse comprendre le
caractère, mais soit incapable de l'afficher. C'est un cas très fréquent,
avec les consoles, aussi bien sous windows que sous linux, ou sous d'autres
OS.
Donc, je me répète, il ne s'agit pas d'un problème Python, mais de
concordance, entre Python et le dispositif de sortie.
@-salutations
Michel Claveau
Ah non ! Là, il s'agit bien d'un problème de language. Si la chaine de caractères n'est pas déclarée unicode, Python interprète tout le contenu binaire formant la chaine de caractères comme de l'ASCII. Quelquesoit l'encodage du fichier. Alors que si l'on déclare la chaine de caractère en unicode, Python interprète bien son contenu. Je trouve ça plutôt limite bug. Mais une fois qu'on le sait, y a plus de problèmes.
Attention à ne pas confondre l'encodage, et l'affichage.
Si un caractère "é" apparaît correctement dans le code-source, c'est que l'éditeur est capable de l'afficher sous cette forme. Lorsqu'il est enregistré dans le fichier, il occupe 1 ou 2 octets, selon l'encodage du fichier-source. Python connaît cet encodage, ce qui lui permet de gérer le caractère.
Lorsque Python effectue un print, il envoie une chaîne d'octets (1 ou 2), sur la sortie. Si l'affichage, à ce stade, semble incorrect, c'est un problème d'adéquation entre Python et le dispositif de sortie.
En allant plus loin, il se peut, aussi, que la sortie puisse comprendre le caractère, mais soit incapable de l'afficher. C'est un cas très fréquent, avec les consoles, aussi bien sous windows que sous linux, ou sous d'autres OS.
Donc, je me répète, il ne s'agit pas d'un problème Python, mais de concordance, entre Python et le dispositif de sortie.
@-salutations
Michel Claveau
Ah non ! Là, il s'agit bien d'un problème de language. Si la chaine de caractères n'est pas déclarée unicode, Python interprète tout le contenu binaire formant la chaine de caractères comme de l'ASCII. Quelquesoit l'encodage du fichier. Alors que si l'on déclare la chaine de caractère en unicode, Python interprète bien son contenu. Je trouve ça plutôt limite bug. Mais une fois qu'on le sait, y a plus de problèmes.
Nicolas
bruno modulix
Do Re Mi chel La Si Do wrote:
Bonsoir
au début des fichiers encodés en UTF-8 est une spécialité MS Windows
Qui écrit le début des fichiers ? Des programmes (éditeurs, IDE, langages, etc.). Python lui-même ajoute le BOM, lorsque l'on "write" un fichier.
quand on "write" quoi ? de l'utf-8 ? Je n'ai jamais constaté ce comportement... Peux-tu nous poster un exemple concret, STP ? (NB : il est possible que ce soit le cas sous Windows et pas sous unix, cf plus bas... donc ma demande n'est pas réthorique du tout)
Windows n'a rien à voir avec ça.
http://www.unicode.org/faq/utf_bom.html#31 """ A particular protocol (e.g. Microsoft conventions for .txt files) may require use of the BOM on certain Unicode data streams, such as files. When you need to conform to such a protocol, use a BOM. """
La citation est intempestive.
Pourquoi ? En quoi est-ce "intempestif" de remarquer qu'un comportement particulier est constaté dans un cadre particulier ?
Si j'affirme ici que l'utilisation de la séquence 'rn' comme marqueur EOL est spécifique à MS Windows, tu va aussi me dire que Windows n'a rien à voir avec ça, que ce sont les programmes qui font ça, et que la citation est intempestive ?
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Do Re Mi chel La Si Do wrote:
Bonsoir
au début des fichiers encodés en UTF-8 est une spécialité MS Windows
Qui écrit le début des fichiers ? Des programmes (éditeurs, IDE, langages,
etc.). Python lui-même ajoute le BOM, lorsque l'on "write" un fichier.
quand on "write" quoi ? de l'utf-8 ? Je n'ai jamais constaté ce
comportement... Peux-tu nous poster un exemple concret, STP ?
(NB : il est possible que ce soit le cas sous Windows et pas sous unix,
cf plus bas... donc ma demande n'est pas réthorique du tout)
Windows n'a rien à voir avec ça.
http://www.unicode.org/faq/utf_bom.html#31
"""
A particular protocol (e.g. Microsoft conventions for .txt files) may
require use of the BOM on certain Unicode data streams, such as files.
When you need to conform to such a protocol, use a BOM.
"""
La citation est intempestive.
Pourquoi ? En quoi est-ce "intempestif" de remarquer qu'un comportement
particulier est constaté dans un cadre particulier ?
Si j'affirme ici que l'utilisation de la séquence 'rn' comme marqueur
EOL est spécifique à MS Windows, tu va aussi me dire que Windows n'a
rien à voir avec ça, que ce sont les programmes qui font ça, et que la
citation est intempestive ?
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
au début des fichiers encodés en UTF-8 est une spécialité MS Windows
Qui écrit le début des fichiers ? Des programmes (éditeurs, IDE, langages, etc.). Python lui-même ajoute le BOM, lorsque l'on "write" un fichier.
quand on "write" quoi ? de l'utf-8 ? Je n'ai jamais constaté ce comportement... Peux-tu nous poster un exemple concret, STP ? (NB : il est possible que ce soit le cas sous Windows et pas sous unix, cf plus bas... donc ma demande n'est pas réthorique du tout)
Windows n'a rien à voir avec ça.
http://www.unicode.org/faq/utf_bom.html#31 """ A particular protocol (e.g. Microsoft conventions for .txt files) may require use of the BOM on certain Unicode data streams, such as files. When you need to conform to such a protocol, use a BOM. """
La citation est intempestive.
Pourquoi ? En quoi est-ce "intempestif" de remarquer qu'un comportement particulier est constaté dans un cadre particulier ?
Si j'affirme ici que l'utilisation de la séquence 'rn' comme marqueur EOL est spécifique à MS Windows, tu va aussi me dire que Windows n'a rien à voir avec ça, que ce sont les programmes qui font ça, et que la citation est intempestive ?
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Do Re Mi chel La Si Do
Bonsoir !
Voilà l'exemple :
# -*- coding: utf-8 -*- a=u'éèëê' open('ess1.txt','wb').write(a.encode('utf-8')) #taille de ess1.txt : 8 octets open('ess2.txt','wb').write(a.encode('cp1252')) #taille de ess2.txt : 4 octets
Comme il est assez compliqué, j'espère que tu arriveras à t'en dépêtrer, sans EPO...
Pour l'intempestif, je maintiens. La phrase : "Un protocole particulier (e.g. Microsoft conventions for .txt files) PEUT avoir besoin..." ne cite pas Windows, n'a pas un caractère systématique, ni obligatoire.
En fait je pense que tu as cru voir l'opportunité d'envoyer un petit coup de griffe à windows...
@-salutations
MCI
Bonsoir !
Voilà l'exemple :
# -*- coding: utf-8 -*-
a=u'éèëê'
open('ess1.txt','wb').write(a.encode('utf-8')) #taille de ess1.txt : 8
octets
open('ess2.txt','wb').write(a.encode('cp1252')) #taille de ess2.txt : 4
octets
Comme il est assez compliqué, j'espère que tu arriveras à t'en dépêtrer,
sans EPO...
Pour l'intempestif, je maintiens. La phrase : "Un protocole particulier
(e.g. Microsoft conventions for .txt files) PEUT avoir besoin..."
ne cite pas Windows, n'a pas un caractère systématique, ni obligatoire.
En fait je pense que tu as cru voir l'opportunité d'envoyer un petit coup de
griffe à windows...
# -*- coding: utf-8 -*- a=u'éèëê' open('ess1.txt','wb').write(a.encode('utf-8')) #taille de ess1.txt : 8 octets open('ess2.txt','wb').write(a.encode('cp1252')) #taille de ess2.txt : 4 octets
Comme il est assez compliqué, j'espère que tu arriveras à t'en dépêtrer, sans EPO...
Pour l'intempestif, je maintiens. La phrase : "Un protocole particulier (e.g. Microsoft conventions for .txt files) PEUT avoir besoin..." ne cite pas Windows, n'a pas un caractère systématique, ni obligatoire.
En fait je pense que tu as cru voir l'opportunité d'envoyer un petit coup de griffe à windows...
