Pourquoi la limite de caractères des légendes TikTok se mesure en runes UTF-16

Quelle est la limite de caractères des légendes TikTok ?

Officiellement, la limite de caractères des légendes TikTok est de 2200 runes UTF-16 pour une légende de vidéo et de 90 runes UTF-16 pour le titre d'un post photo, plus un champ de description distinct de 4000 runes que seuls les posts photo possèdent. Les trois chiffres viennent de la référence de la Content Posting API de TikTok, et les trois sont exprimés en runes plutôt qu'en caractères. Tout ce qui suit décrit l'API, parce que c'est le seul endroit où TikTok publie un nombre.

Le mot « caption » n'est le nom d'aucun champ de l'API. Sur une vidéo, la légende va dans title. Sur un post photo, title est un titre court et le texte de la légende appartient à description. Même application, même personne, même geste d'écrire une légende, deux noms de champs dont les limites sont séparées par un facteur vingt-quatre.

La troisième ligne piège beaucoup de monde. L'endpoint d'upload qui dépose une vidéo dans la boîte de réception TikTok du créateur n'accepte aucun texte. Son corps de requête contient source, video_size, chunk_size, total_chunk_count et video_url, et rien d'autre. TikTok le dit aux intégrateurs : « You should inform users that they must click on inbox notifications to continue the editing flow in TikTok and complete the post. » Si votre planificateur publie par cet endpoint, la légende ne quitte jamais votre base de données.

Qu'est-ce qu'une rune UTF-16 ?

TikTok ne le dit pas. L'expression « UTF-16 runes » apparaît dans les descriptions de champs sans définition, sans lien et sans exemple, et elle soude deux unités venues de deux traditions différentes. Une rune est le nom que Go donne à un point de code Unicode. UTF-16 est un encodage dont l'unité de mesure est l'unité de code, et les caractères astraux en prennent deux. Donc « UTF-16 rune » se lit soit comme « code point », soit comme « UTF-16 code unit », et ce sont deux nombres différents.

Ce sont les mêmes nombres pour de l'anglais simple. Ils divergent pour tout ce qui se situe au-dessus de U+FFFF, c'est-à-dire là où vivent tous les emoji pictographiques.

Les écritures non latines ne sont pas le problème qu'on imagine. Les kana japonais se trouvent dans le plan multilingue de base, donc cinq kana coûtent cinq selon les deux lectures. Ce qui coûte double, c'est tout ce qui est encodé au-dessus de U+FFFF : emoji, écritures historiques, certains blocs d'extension CJC, caractères alphanumériques mathématiques.

Je lis l'ambiguïté comme un signe en faveur des unités de code, parce que c'est le nombre qu'un serveur obtient gratuitement : String.prototype.length en JavaScript et String.length() en Java renvoient tous deux des unités de code. C'est une supposition sur l'implémentation de TikTok, pas une affirmation de TikTok, alors traitez 2200 et 90 comme des plafonds sous lesquels vous restez plutôt que comme des cibles à atteindre.

Combien un seul emoji coûte-t-il sur la limite ?

Entre 1 et 11, et le lecteur voit un seul glyphe dans les deux cas. Le coût, c'est le nombre de points de code de l'emoji selon une lecture, et la somme de leurs largeurs UTF-16 selon l'autre. Chaque point de code au-dessus de U+FFFF occupe 2 unités de code. Les zero width joiners et les sélecteurs de variante valent 1 chacun.

Le portail torii est le cas à part. C'est un symbole du BMP portant un sélecteur de variante, donc les deux lectures s'accordent sur 2 alors que le lecteur en voit 1. L'emoji famille est le plus cher avec 11 unités de code, ce qui, sur un titre de photo de 90 runes, représente plus d'un dixième du champ.

Un titre de photo qui passe une lecture et échoue à l'autre

Prenez ce titre de post photo : Autumn in Kyoto: the twelve quiet corners we walked before dawn, day 1 🍁🍂🏯🌄👘🎋⛩️👩‍👩‍👧‍👦. Ce sont 71 caractères ASCII et huit emoji. Une personne qui le lit compte 79 choses, confortablement sous 90.

Lisez « UTF-16 runes » comme des points de code et le titre fait 86, ce qui rentre. Lisez-le comme des unités de code UTF-16 et il fait 96, ce qui ne rentre pas. Une chaîne, une limite documentée de 90, deux lectures défendables, des réponses opposées. Remplacez l'emoji famille par 👪 U+1F46A et le même titre tombe à 87 selon la lecture stricte et se publie selon les deux.

Pourquoi la même légende casse-t-elle sur un post photo ?

Parce qu'une légende de vidéo dispose de 2200 runes et qu'un titre de photo en a 90. Un outil qui stocke une légende par post programmé et la mappe sur title aux deux endpoints s'en sort pour la vidéo et dépasse le budget de 24 fois pour la photo. Soit il rogne la chaîne avant l'envoi, en supprimant l'essentiel de la légende sans prévenir, soit TikTok rejette l'appel.

Si TikTok rejette, la réponse n'est pas précise. Aucune des deux références ne publie d'erreur nommée pour une légende trop longue. Le fourre-tout est invalid_param en HTTP 400, décrit comme « Check error message for details », et les autres codes documentés couvrent d'autres terrains : spam_risk_too_many_posts, reached_active_user_cap, url_ownership_unverified, privacy_level_option_mismatch, scope_not_authorized, rate_limit_exceeded. La validation de longueur doit se faire dans votre code, parce que l'API ne vous dira pas quel champ était trop long.

Le bon mappage traite les posts photo comme deux champs plutôt qu'un. Gardez le titre court dans title et mettez le corps de la légende dans description, qui à 4000 runes est le champ de texte le plus vaste de toute la Content Posting API. Le champ nommé description sur un post photo contient presque le double de ce que contient le champ nommé title sur une vidéo. Les noms sont inversés par rapport aux tailles.

Les hashtags forment une seconde asymétrie. TikTok documente l'analyse pour le seul champ vidéo, dans une phrase livrée avec une coquille : « Hashtags (#) and mentions (@) will be matched, or deliminated by spaces or new lines. » Aucune phrase équivalente n'apparaît dans la référence photo, pour aucun des deux champs. Qu'un #tag saisi dans une description de photo devienne un vrai tag n'est pas documenté, alors testez-le d'abord sur un post SELF_ONLY.

Comment compter une légende TikTok avant de l'envoyer ?

Calculez les trois nombres et validez contre le plus grand. Intl.Segmenter vous donne le compte du lecteur dans Node et dans le navigateur sans dépendance, et les deux autres sont natifs.

const segmenter = new Intl.Segmenter('en', { granularity: 'grapheme' });
 
const readings = (text) => ({
  reader: [...segmenter.segment(text)].length,
  codePoints: [...text].length,
  utf16Units: text.length,
});
 
const LIMITS = { videoTitle: 2200, photoTitle: 90, photoDescription: 4000 };
 
const fits = (text, field) => readings(text).utf16Units <= LIMITS[field];

text.length est la lecture stricte, donc valider contre elle vous garde en sécurité quelle que soit l'interprétation. N'allez pas chercher Buffer.byteLength(text, 'utf8') ici. Les octets UTF-8 sont une troisième unité, qui facture 3 par kana et 4 par emoji astral, et rien dans la documentation de TikTok ne les réclame. Cette règle appartient à Threads. Confondre les deux fait rejeter des légendes que TikTok aurait acceptées.

La limite dans l'application est-elle la même que celle de l'API ?

TikTok ne publie aucun chiffre pour l'application, il n'y a donc rien à comparer. La référence de la Content Posting API indique 2200, 90 et 4000 pour les trois champs de l'API et ne dit rien de l'éditeur intégré à l'application. Les articles du centre d'aide qui le couvriraient se trouvent à des URL que je n'ai pas pu atteindre. Les chiffres qui circulent pour l'éditeur de l'application remontent à des billets marketing et non à TikTok, alors je ne les répète pas.

Traitez les deux comme distincts tant que TikTok ne documente pas le contraire. Une légende tapée dans l'application et une légende envoyée via /v2/post/publish/video/init/ empruntent des chemins différents, et un seul des deux a un chiffre publié.

Une contrainte de plus est documentée, sur une autre page. Les règles de partage de contenu de TikTok exigent que « API Clients must allow users to enter or select the following metadata for a post: a. Title », et que « Preset text, including any text in the title field or hashtags, should be allowed to be edited by the user before posting content. » Un outil qui génère une légende et la publie sans laisser la moindre chance de la modifier n'est pas conforme, quel que soit le nombre de runes utilisées.

Où adaptlypost intervient

adaptlypost publie sur TikTok via la même Content Posting API, donc 2200, 90 et 4000 s'appliquent à un post programmé exactement comme à un post tapé à la main. Les limites de plateforme appartiennent à TikTok. Ce que la planification change, c'est le moment où vous les découvrez, parce qu'une légende rédigée dans un calendrier de contenu peut être mesurée des jours avant son heure d'envoi plutôt qu'à l'instant où l'API renvoie invalid_param.

L'écart se creuse dès qu'un brouillon part vers plusieurs réseaux, ce qui est le cas ordinaire en publication multiplateforme. Chaque réseau définit sa propre unité de comptage, donc une légende dimensionnée pour l'un n'est pas automatiquement sûre sur le suivant. Si vous écrivez avec le générateur de légendes IA, l'habitude utile consiste à garder les emoji à la fin, là où les couper ne vous coûte rien.

Pour la planification, voyez le planificateur de posts TikTok. Pour les endpoints, voyez l'API de publication TikTok, et pour savoir ce que les posts ont donné ensuite, les statistiques TikTok.

Questions fréquentes

Quelle est la longueur maximale d'une légende TikTok dans l'API ?

2200 runes UTF-16 pour une légende de vidéo, que la référence de la Content Posting API de TikTok place dans le champ title de /v2/post/publish/video/init/. Les posts photo sont différents : title est plafonné à 90 runes UTF-16 et description à 4000, tous deux sur /v2/post/publish/content/init/.

Que veut dire TikTok par runes UTF-16 ?

TikTok ne définit pas le terme. Une rune est le mot de Go pour un point de code Unicode, tandis qu'UTF-16 mesure en unités de code, et les deux lectures diffèrent pour chaque caractère au-dessus de U+FFFF. Validez contre le compte d'unités de code, soit text.length en JavaScript, parce que c'est le plus grand des deux et qu'il vous garde sous la limite dans les deux lectures.

Pourquoi la limite d'une légende de photo TikTok n'est-elle que de 90 caractères ?

Le plafond de 90 runes porte sur title, qui est un champ de titre sur les posts photo et non la légende. Le corps de la légende appartient à description, qui autorise 4000 runes UTF-16. Un outil qui mappe une seule légende stockée sur title aux endpoints vidéo et photo bute sur les 90 et n'a plus qu'à tronquer.

Combien de caractères un emoji consomme-t-il dans une légende TikTok ?

Entre 1 et 11 selon sa construction. Un emoji à point de code unique comme 😀 coûte 1 en point de code et 2 en unités de code UTF-16. L'emoji famille à quatre personnes 👩‍👩‍👧‍👦 est fait de sept points de code soudés par des zero width joiners, soit 7 ou 11 selon la lecture, pour quelque chose que le lecteur voit comme un seul glyphe.

Quelle erreur TikTok renvoie-t-il quand une légende est trop longue ?

TikTok ne publie aucune erreur nommée pour une légende trop longue. Le fourre-tout est invalid_param en HTTP 400, documenté comme « Check error message for details », et les autres codes publiés couvrent le risque de spam, les quotas, la propriété d'URL non vérifiée, le désaccord de confidentialité et l'autorisation. Vérifiez la longueur vous-même avant d'appeler l'endpoint.

La limite des légendes TikTok dans l'application est-elle la même que celle de l'API ?

TikTok ne publie pas de chiffre pour l'éditeur de l'application, les deux ne peuvent donc pas être comparés à partir de la documentation. Les valeurs 2200, 90 et 4000 sont indiquées pour les seuls champs de l'API, dans la référence de la Content Posting API. Tout chiffre sur l'application trouvé ailleurs ne vient pas de TikTok.

Peut-on ajouter une légende en publiant une vidéo TikTok dans les brouillons ?

L'endpoint qui dépose une vidéo dans la boîte de réception TikTok du créateur, /v2/post/publish/inbox/video/init/, n'a aucun champ de texte. Son corps de requête n'accepte que source, video_size, chunk_size, total_chunk_count et video_url. TikTok attend que le créateur ajoute la légende dans l'application après avoir touché la notification de la boîte de réception, car une légende envoyée par votre outil de planification n'atteint jamais cet endpoint.

TikTok analyse-t-il les hashtags sur un post photo comme sur une vidéo ?

TikTok documente l'analyse des hashtags et des mentions uniquement pour le champ title de la vidéo, dans une phrase qui les décrit comme "matched, or deliminated by spaces or new lines". La référence photo ne comporte aucune phrase équivalente, ni pour title ni pour description. Le fait qu'un #tag saisi dans une légende photo devienne un vrai tag n'est pas documenté, donc testez-le d'abord sur un post SELF_ONLY.

Un outil de planification peut-il publier une légende TikTok sans vous laisser la modifier avant ?

Les directives de partage de contenu de TikTok l'excluent. Elles exigent que les clients de l'API laissent les utilisateurs saisir ou choisir un titre, et que le texte préréglé dans le champ titre ou dans les hashtags reste modifiable avant la publication. Un outil qui génère une légende et la publie sans possibilité de modification n'est pas conforme, quel que soit le nombre de runes utilisées.

Faut-il compter une légende TikTok en octets UTF-8 ?

Les octets UTF-8 ne sont pas la bonne unité pour TikTok. Les limites documentées par TikTok sont exprimées en runes UTF-16, pas en octets, et l'UTF-8 compte 3 octets par caractère kana et 4 par emoji au-delà du plan de base, des chiffres que la documentation de TikTok ne demande jamais. Cette règle des octets appartient à Threads ; les confondre fait rejeter des légendes que TikTok aurait acceptées.