Hors programme. UTF-8 code un point de code compris entre U+0080 et…

À la main. $\text{0x03C0}=960$ s'écrit sur $11$ bits ${\overline{01111000000}}^2$. On le coupe en $5+6$ : 01111 et 000000. On préfixe : ${\overline{11001111}}^2=\text{CF}$ et ${\overline{10000000}}^2=\text{80}$. Donc $\pi$ s'écrit CF 80 en UTF-8.

def utf8_deux_octets(pc):
    """Encode a la main un point de code sur deux octets.

    Precondition : 0x80 <= pc <= 0x7FF. On place les 5 bits de poids
    fort derriere le prefixe 110, les 6 suivants derriere 10.
    """
    assert 0x80 <= pc <= 0x7FF, "hors du domaine a deux octets"
    o1 = 0b11000000 | (pc >> 6)
    o2 = 0b10000000 | (pc & 0b111111)
    return bytes([o1, o2])

>>> utf8_deux_octets(0x03C0)
b'\xcf\x80'
>>> chr(0x03C0).encode("utf-8")
b'\xcf\x80'
>>> utf8_deux_octets(0x00E9), "é".encode("utf-8")
(b'\xc3\xa9', b'\xc3\xa9')

Pourquoi ces préfixes. Ils rendent l'encodage auto-synchronisant : un octet commençant par $0$ est un caractère ASCII, un octet commençant par $11$ ouvre une séquence, un octet commençant par $10$ la continue. En tombant au hasard au milieu d'un fichier, on retrouve la frontière du caractère suivant en reculant de quelques octets — impossible avec un encodage sans marqueur. C'est aussi ce qui fait échouer proprement le décodage d'octets latin-1 lus comme de l'UTF-8.

Contrôle : les deux octets produits coïncident avec ceux de Python. Piège : oublier le & 0b111111 sur le second octet — les bits de poids fort écraseraient alors le préfixe 10, et le résultat ne serait plus de l'UTF-8 valide.