Seu título em árabe não está corrompido — a loja está lendo em outra direção

Quando um título em árabe, persa ou urdu chega a uma loja com o parêntese do lado errado, o crédito de "feat." empurrado para a outra ponta, ou um número de catálogo flutuando onde não deveria, nada foi corrompido. Os bytes que você digitou são, quase sempre, os bytes que chegaram. O que mudou foi a direção base da caixa em que o texto está sendo desenhado, e isso é decidido pela página da loja, não pelo seu título. Este artigo explica o mecanismo com precisão suficiente para que você consiga prever quais dos seus títulos vão quebrar antes de entregá-los.

Uma coisa a dizer logo no começo, porque é a posição honesta: não temos conhecimento de nenhuma medição publicada de taxas de erro em metadados em escrita árabe em nenhum ponto da indústria. O problema é vivido universalmente e não está quantificado de forma alguma. Nenhum número aparece abaixo, porque não há número a dar.

Ordem lógica e ordem de exibição são duas coisas diferentes

O Unicode armazena texto em ordem lógica — a ordem em que você fala, digita e lê em voz alta. A ordem de exibição é calculada a partir dela no momento da renderização, pelo Algoritmo Bidirecional do Unicode, definido no Unicode Standard Annex #9 (UAX #9). O anexo é direto quanto a essa separação: "The Unicode Standard prescribes a memory representation order known as logical order" e "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected".

Essa única frase explica o fenômeno que faz artistas de escrita árabe acreditarem que os seus metadados estão assombrados: a string armazenada pode estar perfeitamente correta enquanto a exibição está errada, e pode estar visualmente correta enquanto os bytes armazenados estão errados — e na tela as duas falhas parecem idênticas. Isso não dá para auditar olhando. Nem você, nem o atendente de suporte da sua distribuidora.

Por que um token latino dentro de uma string RTL se move

O UAX #9 atribui a cada caractere um tipo bidirecional. Letras árabes, persas e urdu são AL (letras árabes da direita para a esquerda). Letras latinas são L. Dígitos ASCII são EN (European Number), dígitos arábico-índicos são AN (Arabic Number). Espaços e a maior parte da pontuação — incluindo parênteses, colchetes, o hífen e o ponto final — são neutros, ou seja, não têm direção própria e herdam uma do entorno.

Dois grupos de regras causam o estrago.

Direção do parágrafo, regras P2–P3. O algoritmo procura o primeiro caractere direcional forte e define a direção base a partir dele. Um título que começa com uma palavra latina recebe direção base da esquerda para a direita mesmo que tudo depois dela esteja em persa.

Resolução de neutros, regras N1–N2. Regra N1: "A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction". Regra N2: neutros sem consenso assumem a direção do parágrafo. Depois a regra L2 reordena para exibição — "reverse any contiguous sequence of characters that are at that level or higher".

Junte tudo isso e a falha é determinística, não aleatória. Um token latino — o nome de um remixador, feat., Vol. 2, um número de catálogo, um ano — fica num nível de encaixe diferente do árabe ao redor. Os neutros nas suas fronteiras (o espaço, o parêntese de abertura) têm árabe de um lado e latim do outro, então a N1 não encontra consenso e a N2 lhes entrega a direção do parágrafo. Um parêntese que se resolveu de um jeito no seu editor de texto da direita para a esquerda se resolve do outro jeito numa página de loja da esquerda para a direita, e o parêntese se solta e vira.

Então نام آهنگ (Nima Remix) não está quebrado. É uma string sendo resolvida em dois contextos. Direção base é contexto, não conteúdo, e o contexto da loja não é o seu.

A única coisa que você nunca deve fazer

Não "conserte" a exibição digitando os caracteres de trás para a frente até a prévia ficar certa.

Isso produz uma string errada na ordem lógica, certa em exatamente um contexto de renderização e quebrada em todos os outros — inclusive na busca, na ordenação, no pareamento de artista e em toda loja cuja página tenha direção base diferente da ferramenta em que você "consertou". Você terá convertido um problema de exibição, que é recuperável, num problema de dados, que não é.

O UAX #9 de fato define caracteres para controlar isso explicitamente: os isolates LRI, RLI, FSI e PDI, e as marcas LRM, RLM e ALM. Eles são a correção tecnicamente certa. Também são caracteres de formatação invisíveis, e muitos fluxos de entrega removem caracteres de formatação invisíveis sem avisar. Trate-os como pouco confiáveis num campo de metadados.

A correção estrutural: tirar o token latino do meio

A mitigação que funciona em todo lugar, em qualquer renderizador, sem caracteres invisíveis, é estrutural. Em ordem de preferência:

• Use campos separados em vez de strings de direção mista sempre que o modelo de dados oferecer. Um artista convidado pertence ao nível de papel de artista, não ao título. O Music Metadata Style Guide da Music Biz recomenda creditar artistas convidados no nível de papel de artista e não acrescentar esse dado ao título da faixa ou do lançamento; a orientação pública do Spotify é "You shouldn't include any artists' names in your track or release titles". Uma versão pertence ao campo de versão, cuja função inteira é distinguir duas gravações que compartilham um título. Cada token latino que você move para o próprio campo é uma fronteira bidirecional que deixa de existir.
• Mantenha qualquer token latino inevitável fora da primeira posição. A primeira posição define a direção do parágrafo pelas regras P2–P3. Um título em persa que abre com uma palavra latina é um parágrafo da esquerda para a direita contendo persa, o que não é o que você quis dizer.
• Evite pontuação decorativa nas fronteiras de direção. Travessões, barras, pipes e colchetes empilhados são neutros situados exatamente onde o algoritmo tem menos informação.

Onde um contrato realmente exigir o crédito no título, as convenções são fixas e vale segui-las à risca. Music Biz, sobre "feat." e "with": "when included in the title are generally lowercase and in English". Guia de estilo da Apple: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets". Esse "not localized" está fazendo trabalho de verdade aqui — não traduza "feat." para árabe, persa ou urdu num campo de título. É um token legível por máquina, não uma palavra.

Dígitos, e por que os seus podem não ser os que você pensa

Três conjuntos de dígitos estão em jogo:

Não são variantes estilísticas. São pontos de código diferentes e, segundo o Unicode Character Database, nem sequer compartilham a mesma classe bidirecional. A regra W2 do UAX #9 reclassifica um número europeu como número árabe quando o caractere forte precedente mais próximo é uma letra árabe, de modo que dentro de texto persa os dois podem se comportar igual no momento da exibição — mas nunca na ordenação, na busca ou na comparação de strings, porque são caracteres diferentes. Um "Vol. 2" digitado com um ۲ arábico-índico estendido e um "Vol. 2" digitado com um 2 ASCII são duas strings diferentes que parecem quase idênticas.

Escolha um conjunto de dígitos por catálogo e nunca misture conjuntos dentro de uma mesma string.

Como conferir o que você de fato digitou

A exibição não é confiável, então confira os bytes. Três coisas valem a pena antes de cada entrega:

1. Leia a string como pontos de código, não como glifos. Qualquer ferramenta que mostre valores U+ vai lhe dizer na hora se aquilo é um ی persa (U+06CC) ou um ي árabe (U+064A), um ک persa (U+06A9) ou um ك árabe (U+0643) — uma distinção que a maioria das fontes achata e que nenhum revisor consegue ver. O mesmo vale para um tatweel perdido (U+0640), que nenhuma forma de normalização Unicode remove, e para um non-joiner de largura zero (U+200C) que um campo de formulário engoliu em silêncio.
2. Cole o título num contexto da esquerda para a direita e num da direita para a esquerda e compare. Se a pontuação cair em lugares diferentes nos dois, você tem uma string de direção mista e um token latino que deveria estar no próprio campo.
3. Compare com o seu lançamento anterior, caractere a caractere, não a olho. Catálogos divididos em escrita árabe quase sempre são causados por uma diferença invisível: um lançamento digitado num layout de teclado persa, o seguinte num árabe.

As ferramentas da Mazufa rodam inteiramente no seu navegador — nenhum áudio e nenhum texto é enviado — e definem dir="rtl" automaticamente quando um título é da direita para a esquerda, de modo que o que você vê enquanto digita corresponde ao contexto para o qual a string foi escrita. mazufa.com também hospeda um verificador de metadados gratuito que roda no seu próprio dispositivo e sinaliza vários dos casos invisíveis: conjuntos de dígitos misturados, tatweel, ZWNJ perdido ou faltante, yeh e kaf árabes contra persas, e strings fora de NFC.

O que fazer antes de entregar

Pegue o título e o nome de artista do seu próximo lançamento e faça quatro coisas. Mova todo token latino que puder para o próprio campo — artistas convidados para o papel de artista, versões para o campo de versão. Garanta que nada comece com uma palavra latina. Padronize o seu conjunto de dígitos e remova qualquer tatweel. Depois leia a string como pontos de código uma vez, e guarde essa string exata como a grafia canônica que você vai reutilizar em todo lançamento futuro, sem redigitar.

Se um título ainda tiver que carregar um token latino no meio, entregue assim e aceite que ele vai renderizar de formas diferentes em lugares diferentes. Isso é um resultado de exibição, não um dano. A string está correta. Redigitá-la de trás para a frente para deixar uma prévia bonita é a única maneira de torná-la genuinamente errada.

Fontes

• 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 — propriedades de caracteres: classe bidirecional, mapeamentos de decomposição — 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/

O corpus fornece as versões e as datas de revisão desses documentos, conforme listado acima, e não registra uma data de leitura separada para eles.