Trouver le point de code de "ç" et de "€"

>>> ord("ç"), hex(ord("ç"))
(231, '0xe7')
>>> ord("€"), hex(ord("€"))
(8364, '0x20ac')

Donc "ç" est U+00E7 et "€" est U+20AC.

ç : son point de code $231$ est inférieur à $256$, il tient dans un octet — latin-1 le représente sans difficulté, par l'octet E7.

€ : son point de code $8364$ dépasse $255$. Latin-1 n'a que $256$ places, toutes attribuées en 1987 — le signe euro n'existait pas encore. La conversion échoue :

>>> "ç".encode("latin-1")
b'\xe7'
>>> "€".encode("latin-1")
UnicodeEncodeError: 'latin-1' codec can't encode character
'€' in position 0: ordinal not in range(256)
>>> "€".encode("utf-8")
b'\xe2\x82\xac'

Et c'est une bonne nouvelle. L'exception vaut infiniment mieux qu'un remplacement silencieux : elle signale que le texte ne peut pas être écrit dans cet encodage, au lieu de produire un fichier discrètement faux. C'est exactement la précondition annoncée par la docstring de convertir dans le cours.

Prolongement : le problème fut si gênant qu'une norme a été créée pour lui, ISO-8859-15 (« latin-9 »), qui sacrifie un caractère peu utilisé pour loger l'euro à la place A4. On vérifie : "€".encode("iso-8859-15") rend b'\xa4'. Un octet, une norme de plus, et un argument supplémentaire en faveur d'Unicode.