Quando un titolo in arabo, persiano o urdu arriva a uno store con la parentesi dal lato sbagliato, il credito «feat.» spinto all'estremità opposta o un numero di catalogo che fluttua dove non dovrebbe, non si è corrotto niente. I byte che hai digitato sono quasi sempre i byte arrivati. Quello che è cambiato è la direzione di base del riquadro in cui il testo viene disegnato, e a deciderla è la pagina dello store, non il tuo titolo. Questo articolo spiega il meccanismo con precisione sufficiente perché tu possa prevedere quali dei tuoi titoli si romperanno prima di consegnarli.
Una cosa da dire subito, perché è la posizione onesta: non ci risulta alcuna misurazione pubblicata dei tassi di errore sui metadati in scrittura araba, in nessun punto del settore. Il problema è vissuto universalmente e del tutto non quantificato. Qui sotto non compare alcuna cifra, perché non c'è alcuna cifra da dare.
Ordine logico e ordine di visualizzazione sono due cose diverse
Unicode memorizza il testo in ordine logico — l'ordine in cui lo dici, lo digiti e lo leggi ad alta voce. L'ordine di visualizzazione viene calcolato da quello al momento del rendering, tramite l'Algoritmo Bidirezionale Unicode definito nello Unicode Standard Annex #9 (UAX #9). L'annex è netto su questa separazione: «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».
Quella sola frase spiega il fenomeno che fa credere agli artisti di scrittura araba che i loro metadati siano stregati: la stringa memorizzata può essere perfettamente corretta mentre la visualizzazione è sbagliata, e può essere visivamente corretta mentre i byte memorizzati sono sbagliati — e sullo schermo i due guasti sono identici. Non puoi verificarlo guardando. E non può farlo nemmeno l'addetto all'assistenza del tuo distributore.
Perché un token latino dentro una stringa RTL si sposta
UAX #9 assegna a ogni carattere un tipo bidirezionale. Le lettere arabe, persiane e urdu sono AL (lettere arabe da destra a sinistra). Le lettere latine sono L. Le cifre ASCII sono EN (European Number), le cifre arabo-indiane sono AN (Arabic Number). Gli spazi e la maggior parte della punteggiatura — parentesi tonde, quadre, il trattino e il punto compresi — sono neutri, cioè non hanno una direzione propria e la ereditano da ciò che li circonda.
A fare il danno sono due gruppi di regole.
Direzione del paragrafo, regole P2–P3. L'algoritmo cerca il primo carattere direzionale forte e da quello imposta la direzione di base. Un titolo che comincia con una parola latina ottiene direzione di base da sinistra a destra anche se tutto ciò che segue è in persiano.
Risoluzione dei neutri, regole N1–N2. Regola N1: «A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction». Regola N2: i neutri senza consenso assumono la direzione del paragrafo. Poi la regola L2 riordina per la visualizzazione — «reverse any contiguous sequence of characters that are at that level or higher».
Metti insieme queste cose e il guasto è deterministico, non casuale. Un token latino — il nome di un remixer, feat., Vol. 2, un numero di catalogo, un anno — si trova a un livello di embedding diverso da quello dell'arabo che lo circonda. I neutri ai suoi confini (lo spazio, la parentesi aperta) hanno arabo da un lato e latino dall'altro, quindi N1 non trova consenso e N2 assegna loro la direzione del paragrafo. Una parentesi che nel tuo editor di testo da destra a sinistra si risolveva in un modo si risolve nell'altro su una pagina di store da sinistra a destra, e la parentesi si stacca e si ribalta.
Quindi نام آهنگ (Nima Remix) non è rotto. È una stringa risolta in due contesti. La direzione di base è contesto, non contenuto, e il contesto dello store non è il tuo.
L'unica cosa che non devi mai fare
Non «aggiustare» la visualizzazione digitando i caratteri al contrario finché l'anteprima non sembra giusta.
Questo produce una stringa sbagliata in ordine logico, giusta in esattamente un contesto di rendering e rotta ovunque altrove — ricerca, ordinamento, abbinamento dell'artista e ogni store la cui pagina abbia una direzione di base diversa da quella dello strumento in cui l'hai «aggiustata». Avrai convertito un problema di visualizzazione, che è recuperabile, in un problema di dati, che non lo è.
UAX #9 definisce sì dei caratteri per controllare tutto questo in modo esplicito: gli isolate LRI, RLI, FSI e PDI e i mark LRM, RLM e ALM. Sono la soluzione tecnicamente corretta. Sono anche caratteri di formattazione invisibili, e molte catene di consegna eliminano i caratteri di formattazione invisibili senza dirtelo. Considerali inaffidabili in un campo di metadati.
La soluzione strutturale: togli il token latino da metà stringa
La mitigazione che funziona ovunque, in ogni renderer, senza caratteri invisibili, è strutturale. In ordine di preferenza:
- Usa campi separati anziché stringhe a direzione mista, ovunque il modello dei dati te lo consenta. Un artista ospite va al livello del ruolo artistico, non nel titolo. La Music Metadata Style Guide di Music Biz raccomanda di accreditare gli artisti ospiti al livello del ruolo artistico e di non aggiungere quel dato al titolo della traccia o della pubblicazione; l'indicazione pubblica di Spotify è «You shouldn't include any artists' names in your track or release titles». Una versione va nel campo versione, il cui unico compito è distinguere due registrazioni che condividono un titolo. Ogni token latino che sposti in un campo proprio è un confine bidirezionale che smette di esistere.
- Tieni ogni token latino inevitabile fuori dalla prima posizione. La prima posizione imposta la direzione del paragrafo secondo P2–P3. Un titolo persiano che si apre con una parola latina è un paragrafo da sinistra a destra contenente del persiano, che non è quello che intendevi.
- Evita la punteggiatura decorativa sui confini di direzione. Trattini, barre, pipe e parentesi impilate sono neutri collocati esattamente dove l'algoritmo ha meno informazioni.
Dove un contratto imponga davvero l'accredito nel titolo, le convenzioni sono fissate e vale la pena seguirle alla lettera. Music Biz, su «feat.» e «with»: «when included in the title are generally lowercase and in English». La guida di stile di Apple: «Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets». Quel «not localized» qui fa un lavoro concreto — non tradurre «feat.» in arabo, persiano o urdu in un campo titolo. È un token leggibile dalla macchina, non una parola.
Le cifre, e perché le tue potrebbero non essere quelle che credi
Sono in gioco tre insiemi di cifre:
| Insieme | Code point | Usato in | Classe bidi |
|---|---|---|---|
| ASCII | 0–9 | ovunque | EN |
| Arabo-indiane | U+0660–U+0669 (٠١٢٣٤٥٦٧٨٩) | arabo | AN |
| Arabo-indiane estese | U+06F0–U+06F9 (۰۱۲۳۴۵۶۷۸۹) | persiano, urdu | EN |
Non sono varianti stilistiche. Sono code point diversi e, secondo lo Unicode Character Database, non condividono nemmeno la classe bidirezionale. La regola W2 di UAX #9 riclassifica un numero europeo come numero arabo quando il carattere forte precedente più vicino è una lettera araba, quindi dentro un testo persiano i due possono comportarsi allo stesso modo in visualizzazione — ma mai nell'ordinamento, nella ricerca o nel confronto tra stringhe, perché sono caratteri diversi. Un «Vol. 2» scritto con un ۲ arabo-indiano esteso e un «Vol. 2» scritto con un 2 ASCII sono due stringhe diverse che sembrano quasi identiche.
Scegli un solo insieme di cifre per catalogo e non mischiare mai insiemi dentro una stessa stringa.
Come verificare che cosa hai digitato davvero
La visualizzazione non è affidabile, quindi verifica i byte. Tre cose valgono la pena prima di ogni consegna:
- Leggi la stringa come code point, non come glifi. Qualsiasi strumento che ti mostri i valori U+ ti dirà all'istante se quella è una ی persiana (U+06CC) o una ي araba (U+064A), una ک persiana (U+06A9) o una ك araba (U+0643) — una distinzione che la maggior parte dei font appiattisce e che nessun revisore può vedere. Lo stesso vale per un tatweel vagante (U+0640), che nessuna forma di normalizzazione Unicode rimuove, e per un non-joiner a larghezza zero (U+200C) che un campo di modulo si è mangiato in silenzio.
- Incolla il titolo in un contesto da sinistra a destra e in uno da destra a sinistra e confrontali. Se la punteggiatura cade in modo diverso nei due, hai una stringa a direzione mista e un token latino che dovrebbe stare in un campo proprio.
- Confrontala con la tua pubblicazione precedente, carattere per carattere, non a occhio. I cataloghi spaccati in scrittura araba sono quasi sempre causati da una differenza invisibile: una pubblicazione digitata su un layout di tastiera persiano, la successiva su uno arabo.
Gli strumenti di Mazufa funzionano interamente nel tuo browser — nessun audio e nessun testo viene caricato — e impostano dir="rtl" automaticamente quando un titolo è da destra a sinistra, così quello che vedi mentre scrivi corrisponde al contesto per cui la stringa è stata scritta. mazufa.com ospita anche un verificatore di metadati gratuito che gira sul tuo dispositivo e segnala diversi dei casi invisibili: insiemi di cifre mischiati, tatweel, ZWNJ vaganti o mancanti, yeh e kaf arabe rispetto a quelle persiane e stringhe non in NFC.
Che cosa fare prima di consegnare
Prendi il titolo e il nome d'arte della tua prossima pubblicazione e fai quattro cose. Sposta in un campo proprio ogni token latino che puoi — gli artisti ospiti al ruolo artistico, le versioni nel campo versione. Assicurati che niente cominci con una parola latina. Uniforma l'insieme di cifre e rimuovi ogni tatweel. Poi leggi la stringa come code point una volta, e salva quella stringa esatta come grafia canonica da riusare in ogni pubblicazione futura, senza ridigitarla.
Se un titolo deve comunque portare un token latino in mezzo, consegnalo e accetta che verrà reso in modo diverso in posti diversi. È un esito di visualizzazione, non un danno. La stringa è corretta. Ridigitarla al contrario per far sembrare giusta un'anteprima è l'unico modo per renderla davvero sbagliata.
Fonti
- 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 — proprietà dei caratteri: classe bidirezionale, mappature di decomposizione — 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/
Il corpus fornisce le date di versione e revisione di questi documenti, come elencato sopra, e non registra per essi una data di lettura separata.