chr() Python - Convertir un entier en caractère Unicode sans erreur

Noël Besnard .

12 mai 2026

Exemples de la fonction chr() en Python : chr(65) donne 'A', chr(97) donne 'a', chr(124) donne '|'.

Convertir un entier en caractère Unicode paraît simple, mais c’est précisément le genre de détail qui peut faire dérailler un script dès qu’on mélange texte, encodage et données externes. Ici, je montre comment fonctionne chr() en Python, quand l’utiliser, quelles valeurs elle accepte et comment éviter les erreurs les plus fréquentes. J’ajoute aussi des exemples concrets, parce qu’en pratique la différence entre un point de code et un caractère visible n’est pas toujours évidente.

Les points clés à garder en tête avant d’utiliser chr()

  • chr() transforme un entier en chaîne Unicode d’un seul caractère, pas en octet et pas en “lettre” au sens vague du terme.
  • La plage valide va de 0 à 0x10FFFF, soit 1 114 112 points de code possibles.
  • ord() fait l’opération inverse et renvoie le point de code d’un caractère unique.
  • Si la valeur vient d’une API, d’un fichier ou d’un utilisateur, mieux vaut la valider avant conversion.
  • Quand le caractère est connu à l’avance, un littéral Unicode est souvent plus lisible que chr().

Ce que fait réellement chr() en Python

Python ne possède pas de type “caractère” distinct comme certains autres langages. Un caractère Unicode est simplement une chaîne str de longueur 1, et chr() sert à fabriquer cette chaîne à partir d’un entier représentant un point de code.

Autrement dit, chr(97) renvoie 'a', parce que 97 est le point de code Unicode de la lettre a. La fonction ne traduit pas un encodage binaire et ne lit pas des octets : elle prend un nombre, vérifie qu’il est dans la plage Unicode, puis retourne le caractère correspondant. L’opération inverse est ord(), qui récupère le point de code d’une chaîne d’un seul caractère.

Le point important, c’est que chr() travaille sur des points de code, pas sur ce que l’œil perçoit toujours comme un seul symbole. Cette nuance devient utile dès qu’on manipule des accents composés, des emojis ou des données textuelles issues d’un système externe. Une fois cette base posée, les exemples concrets sont beaucoup plus parlants.

Exemples de la fonction chr() en Python : chr(65) donne 'A', chr(97) donne 'a', et chr(124) donne '|'.

Des exemples concrets qui reviennent souvent

Dans les scripts d’automatisation, les parseurs ou les outils de génération de texte, on utilise souvent chr() pour produire un caractère à partir d’une valeur numérique calculée dynamiquement. Voici quelques cas simples qui montrent bien le comportement attendu.

Valeur Notation hexadécimale Résultat Usage typique
65 0x41 'A' ASCII, génération de séquences simples
8364 0x20AC '€' Symboles monétaires, interfaces multilingues
9731 0x2603 '☃' Tests Unicode, affichage de symboles
128512 0x1F600 '😀' Emojis et jeux de données modernes
print(chr(65))        # A
print(chr(8364))      # €
print(chr(9731))      # ☃
print(chr(0x1F600))   # 😀

Je recommande de regarder ces exemples avec un œil pratique : dès qu’une valeur est calculée, extraite d’un protocole ou convertie depuis une base de données, chr() devient un outil simple et fiable. En revanche, si le caractère est déjà connu au moment d’écrire le code, il existe souvent une option plus lisible.

Les erreurs que je vois le plus souvent

La première erreur consiste à passer une valeur hors plage. Python accepte uniquement les entiers compris entre 0 et 0x10FFFF. En dehors de cette plage, chr() lève une ValueError, ce qui est utile, mais seulement si vous l’anticipez dans votre logique métier.

La deuxième erreur est de confondre entier et texte. chr('97') ne fonctionne pas, parce qu’une chaîne n’est pas un entier. Si la valeur vient d’un formulaire, d’un fichier JSON ou d’une API, il faut d’abord la convertir proprement avec int(), puis seulement appeler chr().

La troisième erreur, plus subtile, est de croire que chr() “décode” des octets. Ce n’est pas son rôle. Pour passer de bytes à du texte, il faut utiliser decode() avec le bon encodage, souvent utf-8. Le réflexe inverse, convertir un entier en caractère, reste du ressort de chr().

Enfin, il y a un piège sémantique que je préfère signaler clairement : un caractère affiché à l’écran n’est pas toujours un seul point de code. Certains symboles visibles peuvent être composés de plusieurs éléments Unicode. Cette distinction est souvent négligée au début, puis elle devient critique dès qu’on traite des données réelles.

Ces erreurs étant posées, il devient plus simple de choisir la bonne méthode selon le contexte exact du code.

Quand utiliser chr() et quand choisir une autre approche

Je raisonne souvent en fonction du moment où la valeur est connue. Si elle apparaît à l’exécution, chr() est généralement le bon choix. Si elle est fixe, un littéral Unicode est plus direct. Et si je manipule des octets ou des noms de caractères, j’utilise un autre outil.

Situation Méthode adaptée Pourquoi
La valeur numérique est calculée à l’exécution chr(codepoint) Conversion claire d’un entier vers un caractère Unicode
Le caractère est connu à l’avance dans le code Littéral Unicode, par exemple '€', '\u20AC' ou '\U0001F600' Meilleure lisibilité quand il ne s’agit pas d’une donnée dynamique
On part d’octets reçus d’un fichier ou d’un réseau bytes.decode('utf-8') On passe du binaire au texte, pas d’un entier à un caractère
On connaît le nom Unicode du caractère unicodedata.lookup() Pratique pour des noms explicites et des jeux de caractères spécialisés

Ce tableau résume bien ma règle de base : je réserve chr() aux conversions numériques dynamiques, et je préfère les littéraux quand la valeur n’a pas vocation à changer. Cette séparation rend le code plus lisible et évite d’introduire des conversions inutiles. Reste une question concrète : comment sécuriser la conversion quand la donnée vient de l’extérieur ?

Une manière propre de sécuriser la conversion

Quand l’entrée n’est pas totalement maîtrisée, je préfère être explicite. Certes, chr() lève déjà des exceptions si la valeur est invalide, mais j’aime souvent contrôler le type et la plage moi-même pour produire un message d’erreur plus clair dans le contexte du projet.

def codepoint_to_char(value: int) -> str:
    if not isinstance(value, int):
        raise TypeError("Le point de code doit être un entier")
    if not 0 <= value <= 0x10FFFF:
        raise ValueError("Point de code Unicode hors plage")
    return chr(value)

Cette approche a un intérêt simple : dans un script de traitement, d’API ou d’automatisation, l’erreur devient plus lisible à diagnostiquer. Si je reçois une chaîne, un flottant ou un entier trop grand, je sais immédiatement pourquoi la conversion échoue. En revanche, si les données sont déjà fiables, je n’ajoute pas de logique superflue et j’appelle directement chr().

Je garde aussi en tête un détail pratique : valider ne veut pas dire surprotéger partout. Il vaut mieux contrôler les frontières du système, c’est-à-dire l’endroit où la donnée entre dans le code, plutôt que de disperser les vérifications dans chaque fonction. Cette discipline change vraiment la qualité d’un projet.

Transformer un point de code en texte sans se tromper de niveau

La bonne façon de retenir le sujet est simple : chr() transforme un entier valide en caractère Unicode, rien de plus, rien de moins. C’est un outil précis, utile, et très propre quand on travaille avec des protocoles, des générateurs de texte ou des données codées numériquement.

Le vrai piège n’est pas chr() lui-même, mais la confusion entre point de code, caractère affiché, encodage et octets. Dès qu’on distingue ces niveaux, le code devient plus lisible, les erreurs sont plus faciles à diagnostiquer et les manipulations Unicode cessent d’être mystérieuses. C’est exactement le genre de détail qui fait gagner du temps dans un projet Python sérieux.

Si je devais résumer mon conseil en une seule phrase : utilisez chr() pour convertir un entier en caractère, validez les entrées externes, et n’oubliez pas qu’un symbole visible peut parfois représenter plusieurs points de code.

Questions fréquentes

La fonction `chr()` en Python permet de convertir un entier (un point de code Unicode) en une chaîne de caractères Unicode d'un seul caractère. Par exemple, `chr(97)` renvoie 'a'.
La fonction `chr()` accepte les entiers compris entre 0 et 0x10FFFF (soit 1 114 112 points de code possibles). Toute valeur en dehors de cette plage entraînera une `ValueError`.
`chr()` convertit un entier en caractère Unicode, tandis que `ord()` fait l'opération inverse : elle renvoie le point de code Unicode (un entier) d'un caractère donné. Par exemple, `ord('a')` renvoie 97.
Validez toujours les entrées externes avec `isinstance()` et vérifiez la plage de valeurs (0 à 0x10FFFF) avant d'appeler `chr()`. Ne confondez pas les entiers avec les chaînes de caractères et n'utilisez pas `chr()` pour décoder des octets.
Utilisez `chr()` lorsque la valeur numérique est calculée dynamiquement à l'exécution. Si le caractère est connu à l'avance dans votre code, un littéral Unicode (ex: '€', '\u20AC') est souvent plus lisible et direct.

Évaluer l'article

Moyenne: 0.0 / 5 · 0 évaluations

Tags

chr python python chr int to char python chr exemples python chr erreurs courantes python chr vs ord
Autor Noël Besnard
Noël Besnard
Je suis Noël Besnard, un analyste de l'industrie passionné par les domaines de la technologie, notamment le web, l'intelligence artificielle, les réseaux et la sécurité. Avec plus de dix ans d'expérience dans l'analyse des tendances du marché technologique, j'ai acquis une expertise approfondie qui me permet d'explorer les innovations et les défis auxquels notre monde numérique est confronté. Mon approche consiste à simplifier des données complexes et à fournir une analyse objective, ce qui me permet de rendre les sujets techniques accessibles à tous. Je m'engage à offrir des informations précises et à jour, en vérifiant rigoureusement les faits pour garantir la fiabilité de chaque article que je publie. Mon objectif est d'aider les lecteurs à naviguer dans cet univers en constante évolution, en leur fournissant les outils nécessaires pour comprendre les enjeux technologiques contemporains.

Commentaires (0)

Ajouter un commentaire