[OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Philippe Verdy]

Cette page ne parle que de l'encoding, tel que défini dans une
bibliothèque de base Python. Elle ne parle pas des objets "chaines de
caractères" qui sont triatés en interne par Python. Ma remarque était
juste car tu disais "Python utilise en interne" ce qui est faux
justement car en interne il est totalement neutre au regard des
encodages et ne vot ces chaines QUE comme des chaines d'octets sans
rien imposer de plus.

Ce qui fait alors que justement Pythin peut travailler avec des tas de
codages différents, y compris incompatibles avec Unicode, et même
manipuler des fichiers binaires comme des images bitmap au sein même
de ses chaines, ou via ses API I/O. En cela Python n'est pas différent
non plus de C/C++, Java, PHP, Javascrript, etc

Et ce n'est donc pas un "problème" comme tu le dis, mais plutôt une
fonctionnalité qui le rend très versatile (mais alors il faut faire
attention aux APIs utilisées qui peuvent ou non imposer un encodage
particulier si on doit les utiliser pour traiter du texte). Quand àç
son langage de programmation, il offre quelques facilités syntaxiques
pour Unicode mais c'est lié au compilateur, pas au traitement interne
à l'exécution.

(Notes: Javascript est un peu particulier car il n'a pas d'objet
"chaine d'octets" mais juste "chaine de mots 16-bits" ; Java n'a pas
directement de "chaines" d'octets mais sait gérer des "ByteBuffers"
dans des tableaux d'octets signés, alors que son type String est à la
base un tableau de mots 16-bits non signés, eux aussi non restreints à
l'Unicode seul ; un problème de Java est cependant que son type
"String" est malheureusement déclaré "final" donc non dérivable en une
sous-classe pour éviter d'avoir à suivre l'encodage utilisé dans les
APIs dans une variable séparée, avec poir conséquence que toutes les
conversions d'encodage doivent être explicités à chaque fois).

Le 28 mars 2013 23:13, Sylvain Maillard <sylvain.maillard at gmail.com> a écrit :
> http://docs.python.org/2/howto/unicode.html
>
> "Encodings don’t have to handle every possible Unicode character, and most
> encodings don’t. For example, Python’s default encoding is the ‘ascii’
> encoding. The rules for converting a Unicode string into the ASCII encoding
> are simple; for each code point:
>
> If the code point is < 128, each byte is the same as the value of the code
> point.
> If the code point is 128 or greater, the Unicode string can’t be represented
> in this encoding. (Python raises a UnicodeEncodeError exception in this
> case.)"
>
> => ça ressemble quand même vachement au problème initial ...
>
> Il s'agit peut-être d'un problème d'api au sein de python, je n'ai pas été
> regarder, mais le résultat est le même : tout appel à un module qui n'est
> pas explicitement écrit de manière à gérer l'unicode, utilisera l'encodage
> par défaut qui est l'ascii et générera ce genre d'erreurs !