L' decode
méthode de chaînes unicode n'est pas vraiment toutes les applications (sauf si vous avez des non-données de texte dans une chaîne unicode pour une raison -- voir ci-dessous). C'est essentiellement pour des raisons historiques, je pense. En Python 3, il est complètement disparu.
unicode().decode()
effectuera implicite de l' encodage de l' s
à l'aide de la valeur par défaut (ascii) codec. Vérifiez cette façon:
>>> 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 le contraire, il tente implicitement de décodage d' s
avec le codage 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 cela, str().encode()
est également superflu.
Mais il est une autre application de cette dernière méthode qui est utile: il y a des codages qui n'ont rien à voir avec les jeux de caractères, et peuvent donc être appliquées à 8 chaînes de bits d'une manière significative:
>>> s.encode('zip')
'x\x9c;\xbc\r\x00\x02>\x01z'
Vous avez raison, cependant: l'ambiguïté de l'utilisation de "l'encodage" pour ces deux applications est... awkard. Encore une fois, avec distinct byte
et string
types de Python 3, ce n'est plus un problème.