La decode
méthode des chaînes Unicode n'a vraiment aucune application (à moins que vous n'ayez des données non textuelles dans une chaîne Unicode pour une raison quelconque - voir ci-dessous). Il est principalement là pour des raisons historiques, je pense. Dans Python 3, il a complètement disparu.
unicode().decode()
effectuera un encodage implicite de l' s
utilisation du codec par défaut (ascii). Vérifiez ceci comme ceci:
>>> s = u'ö'
>>> s.decode()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0:
ordinal not in range(128)
>>> s.encode('ascii')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0:
ordinal not in range(128)
Les messages d'erreur sont exactement les mêmes.
Pour str().encode()
c'est l'inverse - il tente un implicite décodage d' s
avec l'encodage par défaut:
>>> s = 'ö'
>>> s.decode('utf-8')
u'\xf6'
>>> s.encode()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0:
ordinal not in range(128)
Utilisé comme ça, str().encode()
est également superflu.
Mais il y a une autre application de cette dernière méthode qui est utile: il y a des encodages qui n'ont rien à voir avec les jeux de caractères, et peuvent donc être appliqués aux chaînes de 8 bits de manière significative:
>>> s.encode('zip')
'x\x9c;\xbc\r\x00\x02>\x01z'
Vous avez raison, cependant: l'utilisation ambiguë du "codage" pour ces deux applications est ... maladroite. Encore une fois, avec des types séparés byte
et string
dans Python 3, ce n'est plus un problème.