Oui on peut dire cela même si c’est un peu plus compliqué sinon ça ne serait pas marrant 
Pour les curieux :
Au début d’Unicode tout était stocké sur deux octets. Cet encodage, déprécié aujourd’hui, existe toujours. Il se nomme UCS-2 et est de longueur fixe. Il ne permet pas de représenter l’ensemble des caractères Unicode, mais seulement les 65536 premiers, qui sont les plus courants (mais pas d’emojis par exemple).
La plupart des langues latines utilisent que très peu de signe non ASCII et donc il y avait une perte d’espace mémoire alors que pour les langues utilisant des signes ne faisant pas partie de l’ASCII c’était bien pratique.
De plus On savait que le besoin mondial dépasserait la limite de ce qui est représentable sur 16 bits (65536 glyphes) et aujourd’hui le standard Unicode est constitué d'un répertoire contenant un peu moins de 150 000 symboles. Comment est-ce possible si on se limite à 16 bits ?
Le comité à proposé une solution qui convient à tous et en Unicode, la dénomination d’un symbole (son codepoint) et son encodage sont deux choses distinctes.
En pratique il y a une table Unicode gigantesque attribuant un numéro unique à chaque glyph : c’est son codepoint.
Cette table est divisée en 17 plans (de 0 à 16) de deux octets chacun, soit 65 536 points de code par plan.
Ces plans permettent de grouper facilement des symboles et le premier plan (plan 0) est connu sous le nom de Basic Multinlingual Plane (ou BMP) et regroupe les 65536 symboles les plus courants. Les plans de 1 à 16 sont des plans supplémentaires. Unicode peut donc représenter 65 536 x 17 = 1 114 112 glyphes, on est très loin d’avoir saturée la table.
Tous les caractères qui sont en dehors de la BMP n’étaient pas représentables en UCS-2 et c’est pourquoi aujourd’hui cet encodage ne fait plus parti de la norme Unicode.
En échange le consortium a standardisé plusieurs encodages connus sous les noms UTF-n ou n est un nombre. La différence entre ces encodages est la longueur minimale d’octets nécessaires à la représentation d’un caractère.
Par exemple l’UTF-32 est le seul encodage à taille fixe qui ne soit pas déprécié et qui permet de représenter l’intégralité des caractères Unicode sur 32 bits, soit quatre octets glyphe. C’est coûteux mais on a tout avec une taille connue. il n’est presque jamais utilisé pour representer un fichier texte dans votre éditeur mais sert plutôt dans des API de langages de programmation pour avoir un outil uniforme mondial. Python 3 utilise UTF32 pour représenter les variables de texte en mémoire par exemple.
Ensuite il y a deux encodages à taille variables sont dans la norme Unicode, l’UTF-8 et l’UTF-16. Leur maximum est de quatre octets chacun mais la taille minimum d’un glyphe est de un octet en UTF-8 et deux octets en UTF-16.
L’UTF-8 est le plus utilisé aujourd’hui, tant pour le stockage que le transfert d’informations. Sa taille minimale est de huit bits (mais il peut monter jusqu’à quatre octets pour certains signes) et il a la particularité d’être totalement compatible avec l’ASCII et pas sensible au boutisme puisque lisible octet par octet : l’information sur le nombre d’octets nécessaires au codage est contenu dans le premier octet du glyphe.
C’est ce qui a été retenu dan l’IDE arduino et si vous tapez une chaîne dans l’éditeur de code, sa représentation mémoire est en UTF-8. On ne peut donc pas dire qu’il y a 2 octets par symbole, il y en a entre 1 et 4. Ça complique donc un peu la donne car la fonction strlen() retourne le nombre d’octets et pas le nombre de glyphes à l’écran (le symbole € par exemple est sur 2 octets mais occupera l’espace d’un caractère à l’affichage.
Pour être un peu plus complet (si vous avez lu jusqu’ici), en UTF-16 on a donc une longueur variable avec des mots sur 16 bits et un glyphe fait soit deux soit quatre octets. L’UTF-16 n’est pas compatible avec l’ASCII ni avec l’UTF-8 mais rétro-compatible avec l’UCS-2 si on se limite à la BMP, car l’UTF-16 permet d’encoder l’ensemble des caractère de la table Unicode : comme en UCS-2 pour les 65536 premiers sur deux octets et le million de glyphes possibles restants nécessitent l’usage d’un second mot de 2 octets.
En Java et JavaScript, le type String est représenté en interne en UTF-16. Dans ce cadre la méthode length compte le nombre de mots UTF-16 (comme strlen comptait les octets) et si vous êtes au delà de la BMP alors vous aurez aussi une différence entre le nombre de glyphes et la longueur lue.
.
