Por qué el límite de caracteres de la descripción de TikTok se mide en runas UTF-16

¿Cuál es el límite de caracteres de la descripción de TikTok?

Según la documentación, el límite de caracteres de la descripción de TikTok es de 2200 runas UTF-16 para la descripción de un video y 90 runas UTF-16 para el título de una publicación de fotos, más un campo de descripción aparte de 4000 runas que solo tienen las publicaciones de fotos. Las tres cifras salen de la referencia de la Content Posting API de TikTok, y las tres se expresan en runas y no en caracteres. Todo lo que sigue describe la API, porque es el único sitio donde TikTok publica un número.

La palabra "caption" no es el nombre de ningún campo de la API. En un video, la descripción va en title. En una publicación de fotos, title es un titular corto y el texto de la descripción va en description. La misma app, la misma persona, el mismo acto de escribir una descripción, dos nombres de campo cuyos límites se separan por un factor de veinticuatro.

La tercera fila pilla a mucha gente. El endpoint de subida que deja un video en la bandeja de entrada de TikTok del creador no acepta texto alguno. Su cuerpo de petición contiene source, video_size, chunk_size, total_chunk_count y video_url, y nada más. TikTok se lo dice así a quienes integran: "You should inform users that they must click on inbox notifications to continue the editing flow in TikTok and complete the post." Si tu programador publica por ese endpoint, la descripción nunca sale de tu base de datos.

¿Qué es una runa UTF-16?

TikTok no lo dice. La expresión "UTF-16 runes" aparece en las descripciones de los campos sin definición, sin enlace y sin ejemplo, y suelda dos unidades de dos tradiciones distintas. Una runa es el nombre que Go le da a un punto de código Unicode. UTF-16 es una codificación cuya unidad de medida es la unidad de código, y los caracteres astrales ocupan dos. Así que "UTF-16 rune" se lee como "code point" o como "UTF-16 code unit", y son números distintos.

Son el mismo número para el inglés simple. Divergen en todo lo que está por encima de U+FFFF, que es donde viven todos los emoji pictográficos.

Los alfabetos no latinos no son el problema que la gente supone. Los kana japoneses están en el Plano Multilingüe Básico, así que cinco kana cuestan cinco con las dos lecturas. Lo que cuesta el doble es cualquier cosa codificada por encima de U+FFFF: emoji, escrituras históricas, algunos bloques de extensión CJK, caracteres alfanuméricos matemáticos.

Yo leo la ambigüedad como una señal hacia las unidades de código, porque es el número que un servidor obtiene gratis: String.prototype.length en JavaScript y String.length() en Java devuelven ambos unidades de código. Eso es una suposición sobre la implementación de TikTok, no algo que TikTok afirme, así que trata 2200 y 90 como techos por debajo de los cuales te mantienes y no como objetivos que alcanzas.

¿Cuánto cuesta un emoji contra el límite?

Entre 1 y 11, y quien lee ve una sola figura en cualquiera de los dos casos. El coste es el número de puntos de código del emoji con una lectura, y la suma de sus anchos UTF-16 con la otra. Cada punto de código por encima de U+FFFF ocupa 2 unidades de código. Los zero width joiners y los selectores de variación ocupan 1 cada uno.

La puerta torii es la rara. Es un símbolo del BMP que lleva un selector de variación, así que las dos lecturas coinciden en 2 mientras quien lee ve 1. El emoji de familia es el caro, con 11 unidades de código, que en un título de foto de 90 runas es más de una décima parte del campo.

Un título de foto que pasa una lectura y falla la otra

Toma este título de una publicación de fotos: Autumn in Kyoto: the twelve quiet corners we walked before dawn, day 1 🍁🍂🏯🌄👘🎋⛩️👩‍👩‍👧‍👦. Son 71 caracteres ASCII y ocho emoji. Una persona que lo lee cuenta 79 cosas, cómodamente dentro de 90.

Lee "UTF-16 runes" como puntos de código y el título son 86, que caben. Léelo como unidades de código UTF-16 y son 96, que no caben. Una cadena, un límite documentado de 90, dos lecturas defendibles, respuestas opuestas. Cambia el emoji de familia por 👪 U+1F46A y el mismo título baja a 87 con la lectura estricta y se publica con las dos.

¿Por qué se rompe la misma descripción en una publicación de fotos?

Porque la descripción de un video tiene 2200 runas para gastar y el título de una foto tiene 90. Una herramienta que guarda una descripción por publicación programada y la asigna a title en los dos endpoints va bien con el video y se pasa 24 veces del presupuesto con la foto. O recorta la cadena antes de enviarla, tirando casi toda la descripción sin avisar, o TikTok rechaza la llamada.

Si TikTok la rechaza, la respuesta no es específica. Ninguna de las dos referencias publica un error con nombre para una descripción demasiado larga. El comodín es invalid_param con HTTP 400, descrito como "Check error message for details", y el resto de códigos documentados cubren otros terrenos: spam_risk_too_many_posts, reached_active_user_cap, url_ownership_unverified, privacy_level_option_mismatch, scope_not_authorized, rate_limit_exceeded. La validación de longitud tiene que ocurrir en tu código, porque la API no te dirá qué campo era demasiado largo.

La asignación correcta trata las publicaciones de fotos como dos campos y no como uno. Deja el titular corto en title y pon el cuerpo de la descripción en description, que con 4000 runas es el campo de texto más amplio de toda la Content Posting API. El campo llamado description de una publicación de fotos admite casi el doble que el campo llamado title de un video. Los nombres están al revés respecto a los tamaños.

Los hashtags son una segunda asimetría. TikTok documenta el análisis solo para el campo del video, en una frase que se publica con una errata: "Hashtags (#) and mentions (@) will be matched, or deliminated by spaces or new lines." No aparece ninguna frase equivalente en la referencia de fotos para ninguno de los dos campos. Que un #tag escrito en la descripción de una foto acabe siendo una etiqueta real está sin documentar, así que pruébalo primero en una publicación SELF_ONLY.

¿Cómo se cuenta una descripción de TikTok antes de enviarla?

Calcula las tres cifras y valida contra la mayor. Intl.Segmenter te da el recuento de quien lee en Node y en el navegador sin dependencias, y las otras dos vienen de serie.

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 es la lectura estricta, así que validar contra ella te mantiene a salvo con cualquiera de las dos interpretaciones. No recurras aquí a Buffer.byteLength(text, 'utf8'). Los bytes UTF-8 son una tercera unidad, que cobra 3 por kana y 4 por emoji astral, y nada en la documentación de TikTok los pide. Esa regla es de Threads. Confundir las dos rechaza descripciones que TikTok habría aceptado.

¿El límite de la descripción dentro de la app es el mismo que el de la API?

TikTok no publica una cifra para dentro de la app, así que no hay nada que comparar. La referencia de la Content Posting API indica 2200, 90 y 4000 para los tres campos de la API y no dice nada del editor dentro de la app. Los artículos del centro de ayuda que lo cubrirían están en URLs que no pude alcanzar. Las cifras que circulan sobre el editor de la app se remontan a publicaciones de marketing y no a TikTok, así que no las repito.

Trátalos como dos cosas separadas hasta que TikTok documente lo contrario. Una descripción escrita en la app y una descripción enviada por /v2/post/publish/video/init/ recorren caminos distintos, y solo uno de ellos tiene una cifra publicada.

Hay otra restricción documentada, en una página distinta. Las directrices de TikTok sobre compartir contenido exigen que "API Clients must allow users to enter or select the following metadata for a post: a. Title", y que "Preset text, including any text in the title field or hashtags, should be allowed to be edited by the user before posting content." Una herramienta que genera una descripción y la publica sin dar opción a editarla incumple la norma por muchas runas que haya usado.

Dónde encaja adaptlypost

adaptlypost publica en TikTok a través de la misma Content Posting API, así que 2200, 90 y 4000 se aplican a una publicación programada igual que a una escrita a mano. Los límites de plataforma son de TikTok. Lo que cambia al programar es cuándo te enteras de ellos, porque una descripción redactada en un calendario de contenido se puede medir días antes de su hora de envío en lugar de en el momento en que la API devuelve invalid_param.

El desajuste se agudiza en cuanto un borrador va a varias redes, que es el caso habitual en la publicación multiplataforma. Cada red define su propia unidad de recuento, así que una descripción dimensionada para una no es automáticamente segura en la siguiente. Si escribes con el generador de descripciones con IA, la costumbre útil es dejar los emoji al final, donde recortarlos no te cuesta nada.

Para programar, mira el programador de publicaciones de TikTok. Para los endpoints, mira la API de publicación de TikTok, y para saber qué hicieron después las publicaciones, la analítica de TikTok.

Preguntas frecuentes

¿Cuál es la longitud máxima de una descripción de TikTok en la API?

2200 runas UTF-16 para la descripción de un video, que la referencia de la Content Posting API de TikTok sitúa en el campo title de /v2/post/publish/video/init/. Las publicaciones de fotos son distintas: title está limitado a 90 runas UTF-16 y description a 4000, ambos en /v2/post/publish/content/init/.

¿Qué quiere decir TikTok con runas UTF-16?

TikTok no define el término. Una runa es la palabra que usa Go para un punto de código Unicode, mientras que UTF-16 mide en unidades de código, y las dos lecturas difieren en cada carácter por encima de U+FFFF. Valida contra el recuento de unidades de código, que en JavaScript es text.length, porque es el mayor de los dos y te mantiene dentro del límite con cualquiera de las lecturas.

¿Por qué el límite de la descripción de una foto en TikTok es de solo 90 caracteres?

El tope de 90 runas es de title, que en las publicaciones de fotos es un campo de titular y no la descripción. El cuerpo de la descripción va en description, que permite 4000 runas UTF-16. Una herramienta que asigna una única descripción guardada a title en los endpoints de video y de foto choca con los 90 y no le queda más que truncar.

¿Cuántos caracteres consume un emoji en una descripción de TikTok?

Entre 1 y 11 según cómo esté construido. Un emoji de un solo punto de código como 😀 cuesta 1 como punto de código y 2 como unidades de código UTF-16. El emoji de familia de cuatro personas 👩‍👩‍👧‍👦 son siete puntos de código soldados por zero width joiners, o sea 7 u 11 según la lectura, para algo que quien lee ve como una sola figura.

¿Qué error devuelve TikTok cuando una descripción es demasiado larga?

TikTok no publica ningún error con nombre para una descripción demasiado larga. El comodín es invalid_param con HTTP 400, documentado como "Check error message for details", y el resto de códigos publicados cubren riesgo de spam, cuotas, propiedad de URL sin verificar, desajuste de privacidad y autorización. Comprueba tú mismo la longitud antes de llamar al endpoint.

¿El límite de la descripción de TikTok dentro de la app es el mismo que el de la API?

TikTok no publica una cifra para el editor de la app, así que los dos no se pueden comparar a partir de la documentación. Las cifras 2200, 90 y 4000 se indican solo para campos de la API, en la referencia de la Content Posting API. Cualquier número sobre la app que encuentres en otro sitio no viene de TikTok.

¿Puedes añadir una descripción al publicar un video de TikTok en los borradores?

El endpoint que sube un video a la bandeja de entrada de TikTok del creador, /v2/post/publish/inbox/video/init/, no tiene ningún campo de texto. Su cuerpo de solicitud solo acepta source, video_size, chunk_size, total_chunk_count y video_url. TikTok espera que el creador añada la descripción dentro de la app después de tocar la notificación de la bandeja de entrada, porque una descripción enviada desde tu programador nunca llega a este endpoint.

¿TikTok interpreta los hashtags en una publicación de fotos igual que en un video?

TikTok documenta el análisis de hashtags y menciones solo para el campo title del video, en una frase que los describe como "matched, or deliminated by spaces or new lines". La referencia de fotos no tiene una frase equivalente, ni para title ni para description. Si un #tag escrito en una descripción de foto se convierte en una etiqueta real no está documentado, así que pruébalo primero en una publicación SELF_ONLY.

¿Puede una herramienta de programación publicar una descripción de TikTok sin dejarte editarla antes?

Las directrices de contenido compartido de TikTok lo prohíben. Exigen que los clientes de la API permitan a los usuarios ingresar o seleccionar un título, y que el texto preestablecido en el campo de título o en los hashtags se pueda editar antes de publicar. Una herramienta que genera una descripción y la publica sin opción de editarla incumple esto sin importar cuántas runas haya usado.

¿Deberías contar una descripción de TikTok en bytes UTF-8?

Los bytes UTF-8 son la unidad equivocada para TikTok. Los límites documentados de TikTok están en runas UTF-16, no en bytes, y UTF-8 cobra 3 bytes por carácter kana y 4 por emoji astral, cifras que la documentación de TikTok nunca pide. Esa regla de bytes pertenece a Threads; mezclar las dos rechaza descripciones que TikTok habría aceptado.