Cuando un título en árabe, persa o urdu llega a una tienda con el paréntesis del lado equivocado, el crédito de "feat." empujado al extremo opuesto o un número de catálogo flotando donde no debería, no se ha corrompido nada. Los bytes que escribiste son, casi siempre, los bytes que llegaron. Lo que cambió es la dirección base de la caja en la que se dibuja el texto, y eso lo decide la página de la tienda, no tu título. Este artículo explica el mecanismo con la precisión suficiente para que puedas predecir cuáles de tus títulos se van a romper antes de entregarlos.
Una cosa que conviene decir de entrada, porque es la posición honesta: no conocemos ninguna medición publicada de las tasas de error en metadatos en escritura árabe en ningún punto de la industria. El problema lo sufre todo el mundo y no está cuantificado en absoluto. Abajo no aparece ninguna cifra, porque no hay ninguna cifra que dar.
El orden lógico y el orden de visualización son dos cosas distintas
Unicode almacena el texto en orden lógico — el orden en que lo dices, lo escribes y lo lees en voz alta. El orden de visualización se calcula a partir de ese, en el momento de renderizar, mediante el Algoritmo Bidireccional de Unicode definido en el Unicode Standard Annex #9 (UAX #9). El anexo es tajante sobre esa separación: "El Estándar Unicode prescribe un orden de representación en memoria conocido como orden lógico" y "Al trabajar con texto bidireccional, los caracteres se siguen interpretando en orden lógico; solo se ve afectada la visualización".
Esa sola frase explica el fenómeno que hace creer a los artistas de escritura árabe que sus metadatos están embrujados: la cadena almacenada puede ser perfectamente correcta mientras la visualización está mal, y puede verse correcta mientras los bytes almacenados están mal — y en pantalla los dos fallos son idénticos. No puedes auditar esto mirando. Tampoco puede hacerlo el agente de soporte de tu distribuidora.
Por qué un fragmento latino dentro de una cadena RTL se mueve
El UAX #9 asigna a cada carácter un tipo bidireccional. Las letras árabes, persas y urdus son AL (letras árabes de derecha a izquierda). Las letras latinas son L. Los dígitos ASCII son EN (número europeo) y los dígitos arábigo-índicos son AN (número árabe). Los espacios y la mayoría de los signos de puntuación — incluidos los paréntesis, los corchetes, el guion y el punto — son neutros, es decir, no tienen dirección propia y heredan una de su entorno.
Dos grupos de reglas hacen el daño.
Dirección del párrafo, reglas P2–P3. El algoritmo busca el primer carácter direccional fuerte y fija a partir de él la dirección base. Un título que empieza con una palabra latina recibe dirección base de izquierda a derecha aunque todo lo que venga después sea persa.
Resolución de neutros, reglas N1–N2. Regla N1: "Una secuencia de [neutros] toma la dirección del texto fuerte que la rodea si el texto de ambos lados tiene la misma dirección". Regla N2: los neutros sin consenso toman la dirección del párrafo. Después, la regla L2 reordena para la visualización: "invierte cualquier secuencia contigua de caracteres que estén en ese nivel o en uno superior".
Junta todo eso y el fallo es determinista, no aleatorio. Un fragmento latino — el nombre de un remixer, feat., Vol. 2, un número de catálogo, un año — queda en un nivel de incrustación distinto del árabe que lo rodea. Los neutros en sus límites (el espacio, el paréntesis de apertura) tienen árabe de un lado y latín del otro, así que N1 no encuentra consenso y N2 les entrega la dirección del párrafo. Un paréntesis que se resolvía de una manera en tu editor de texto de derecha a izquierda se resuelve de la otra en una página de tienda de izquierda a derecha, y el paréntesis se despega y se voltea.
Así que نام آهنگ (Nima Remix) no está roto. Es una misma cadena resuelta en dos contextos. La dirección base es contexto, no contenido, y el contexto de la tienda no es el tuyo.
Lo único que jamás debes hacer
No "arregles" la visualización escribiendo los caracteres al revés hasta que la vista previa se vea bien.
Eso produce una cadena equivocada en orden lógico, correcta en exactamente un contexto de renderizado y rota en todos los demás — incluidos la búsqueda, el ordenamiento, la coincidencia de artistas y toda tienda cuya página tenga una dirección base distinta de la de la herramienta donde lo "arreglaste". Habrás convertido un problema de visualización, que es recuperable, en un problema de datos, que no lo es.
El UAX #9 sí define caracteres para controlar esto de forma explícita: los aisladores LRI, RLI, FSI y PDI, y las marcas LRM, RLM y ALM. Son la solución técnicamente correcta. También son caracteres de formato invisibles, y muchas cadenas de entrega eliminan los caracteres de formato invisibles sin avisarte. Trátalos como poco fiables dentro de un campo de metadatos.
La solución estructural: sacar el fragmento latino del medio
La mitigación que funciona en todas partes, en cualquier renderizador y sin caracteres invisibles, es estructural. En orden de preferencia:
- Usa campos separados en lugar de cadenas de dirección mixta siempre que el modelo de datos los ofrezca. Un artista invitado va en el nivel del rol de artista, no en el título. La Music Metadata Style Guide de Music Biz recomienda acreditar a los artistas invitados en el nivel del rol de artista y no añadir ese dato al título del tema ni del lanzamiento; la guía pública de Spotify dice: "No deberías incluir el nombre de ningún artista en los títulos de tus temas ni de tus lanzamientos". Una versión va en el campo de versión, cuyo trabajo entero es distinguir dos grabaciones que comparten título. Cada fragmento latino que muevas a su propio campo es un límite bidireccional que deja de existir.
- Mantén cualquier fragmento latino inevitable fuera de la primera posición. La primera posición fija la dirección del párrafo según P2–P3. Un título en persa que abre con una palabra latina es un párrafo de izquierda a derecha que contiene persa, que no es lo que querías.
- Evita la puntuación decorativa en los límites de dirección. Guiones, barras, barras verticales y paréntesis anidados son neutros situados justo donde el algoritmo tiene menos información.
Cuando un contrato exige de verdad que la acreditación vaya en el título, las convenciones son fijas y conviene seguirlas al pie de la letra. Music Biz, sobre "feat." y "with": "cuando se incluyen en el título van generalmente en minúsculas y en inglés". La guía de estilo de Apple: "El formato de 'feat.' y 'with' debe ir en minúsculas, en inglés, sin localizar, y entre paréntesis o corchetes". Esa instrucción de "sin localizar" está haciendo un trabajo real aquí: no traduzcas "feat." al árabe, al persa ni al urdu en un campo de título. Es un token legible por máquina, no una palabra.
Los dígitos, y por qué los tuyos pueden no ser los que crees
Hay tres conjuntos de dígitos en juego:
| Conjunto | Puntos de código | Usado en | Clase bidi |
|---|---|---|---|
| ASCII | 0–9 | en todas partes | EN |
| Arábigo-índico | U+0660–U+0669 (٠١٢٣٤٥٦٧٨٩) | árabe | AN |
| Arábigo-índico extendido | U+06F0–U+06F9 (۰۱۲۳۴۵۶۷۸۹) | persa, urdu | EN |
No son variantes estilísticas. Son puntos de código distintos y, según la Unicode Character Database, ni siquiera comparten clase bidireccional. La regla W2 del UAX #9 reclasifica un número europeo como número árabe cuando el carácter fuerte precedente más cercano es una letra árabe, así que dentro de texto persa los dos pueden comportarse igual al mostrarse — pero nunca en ordenamiento, búsqueda ni comparación de cadenas, porque son caracteres distintos. Un "Vol. 2" escrito con un ۲ arábigo-índico extendido y un "Vol. 2" escrito con un 2 ASCII son dos cadenas distintas que se ven casi idénticas.
Elige un conjunto de dígitos por catálogo y nunca mezcles conjuntos dentro de una misma cadena.
Cómo comprobar qué escribiste en realidad
No se puede confiar en la visualización, así que hay que revisar los bytes. Tres cosas que vale la pena hacer antes de cada entrega:
- Lee la cadena como puntos de código, no como glifos. Cualquier herramienta que te muestre los valores U+ te dirá al instante si eso es una ی persa (U+06CC) o una ي árabe (U+064A), una ک persa (U+06A9) o una ك árabe (U+0643) — una distinción que la mayoría de las tipografías aplana y que ningún corrector puede ver. Lo mismo vale para un tatwil suelto (U+0640), que ninguna forma de normalización Unicode elimina, y para un no-unidor de ancho cero (U+200C) que un campo de formulario se comió en silencio.
- Pega el título en un contexto de izquierda a derecha y en otro de derecha a izquierda y compara. Si la puntuación cae distinto en los dos, tienes una cadena de dirección mixta y un fragmento latino que debería estar en su propio campo.
- Compáralo con tu lanzamiento anterior, carácter por carácter, no a ojo. Los catálogos partidos en escritura árabe casi siempre los causa una diferencia invisible: un lanzamiento escrito con una distribución de teclado persa y el siguiente con una árabe.
Las herramientas de Mazufa funcionan por completo en tu navegador — no se sube ningún audio ni ningún texto — y aplican dir="rtl" automáticamente cuando un título es de derecha a izquierda, de modo que lo que ves mientras escribes coincide con el contexto para el que se escribió la cadena. mazufa.com también aloja un verificador de metadatos gratuito que corre en tu propio dispositivo y señala varios de los casos invisibles: conjuntos de dígitos mezclados, tatwil, ZWNJ ausente o de más, yeh y kaf árabes frente a persas, y cadenas que no están en NFC.
Qué hacer antes de entregar
Toma el título y el nombre de artista de tu próximo lanzamiento y haz cuatro cosas. Mueve a su propio campo cada fragmento latino que puedas — artistas invitados al rol de artista, versiones al campo de versión. Asegúrate de que nada empiece con una palabra latina. Normaliza tu conjunto de dígitos y elimina cualquier tatwil. Luego lee la cadena como puntos de código una vez, y guarda esa cadena exacta como la grafía canónica que reutilizarás en cada lanzamiento futuro, sin volver a teclearla.
Si un título tiene que llevar de todos modos un fragmento latino en medio, entrégalo y asume que se va a mostrar distinto en distintos lugares. Eso es un resultado de visualización, no un daño. La cadena es correcta. Volver a escribirla al revés para que una vista previa se vea bien es la única manera de dejarla verdaderamente mal.
Fuentes
- Unicode Standard Annex #9, Unicode Bidirectional Algorithm (Revision 51, Unicode 17.0.0, 2025-08-13) — https://www.unicode.org/reports/tr9/
- Unicode Standard Annex #15, Unicode Normalization Forms (Version 57, Unicode 17.0.0, 2025-07-30) — https://www.unicode.org/reports/tr15/
- Unicode Character Database — propiedades de carácter: clase bidireccional, correspondencias de descomposición — https://www.unicode.org/ucd/
- Music Business Association, Music Metadata Style Guide v2.1 — https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
- Apple Music Style Guide — https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
- Spotify for Artists, Music metadata guidelines — https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/
El corpus da las fechas de versión y revisión de estos documentos, tal como se listan arriba, y no registra para ellos una fecha de lectura aparte.