あなたのアラビア語タイトルは壊れていません。ストアが別の方向で読んでいるだけです

アラビア語、ペルシア語、ウルドゥー語のタイトルが、括弧が反対側に付いた状態で、あるいは「feat.」のクレジットが端まで押し出された状態で、あるいはカタログ番号があるべきでない位置に浮いた状態でストアに届いたとき、壊れているものは何もありません。あなたが打ったバイト列は、ほぼ必ずそのまま届いたバイト列です。変わったのは、そのテキストが描かれる箱の基準方向であり、それを決めているのはストアのページであって、あなたのタイトルではありません。この記事は、どのタイトルが崩れるかを納品前に予測できる程度には正確に、その仕組みを説明します。

最初にひとつ述べておきます。それが誠実な立場だからです。アラビア文字のメタデータのエラー率について公表された測定値を、業界のどこにも当社は知りません。 この問題は誰もが経験していて、まったく定量化されていません。以下に数字は一つも出てきません。出せる数字が存在しないからです。

論理順と表示順は別のもの

Unicode はテキストを 論理順 で保存します。あなたが口に出し、打ち込み、声に出して読む順序です。表示順は、描画のときにそこから計算されます。計算するのは Unicode Standard Annex #9（UAX #9） で定義された Unicode 双方向アルゴリズムです。この附属書は、この分離について率直です。"The Unicode Standard prescribes a memory representation order known as logical order"（Unicode 標準は、論理順として知られる メモリ上の 表現順序を規定する）、そして "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."（双方向テキストを扱うとき、文字は依然として論理順で解釈される。影響を受けるのは表示だけである。）

この一文が、アラビア文字圏のアーティストに自分のメタデータは呪われていると思わせる現象を説明します。保存された文字列が完全に正しいまま表示が誤っていることもあれば、見た目が正しいまま保存されたバイト列が誤っていることもあります。そして画面上では、この二つの失敗は見分けがつきません。 目で見て監査することはできません。あなたのディストリビューターのサポート担当にもできません。

RTL の文字列の中でラテン文字が動く理由

UAX #9 はすべての文字に双方向タイプを与えます。アラビア語、ペルシア語、ウルドゥー語の文字は AL（右から左に進むアラビア文字）です。ラテン文字は L です。ASCII の数字は EN（European Number）、アラビア・インド数字は AN（Arabic Number）です。空白とほとんどの約物 — 丸括弧、角括弧、ハイフン、ピリオドを含む — は 中立 で、自分の方向を持たず、周囲から方向を受け継ぎます。

損害を与えるのは二つの規則群です。

段落方向、規則 P2–P3。 アルゴリズムは 最初の強い 方向性文字を探し、そこから基準方向を決めます。ラテン語の単語で始まるタイトルは、その後がすべてペルシア語であっても、左から右の基準方向になります。

中立文字の解決、規則 N1–N2。 規則 N1：「[中立文字] の連なりは、両側のテキストが同じ方向であれば、周囲の強いテキストの方向を取る」。規則 N2：合意のない中立文字は段落方向を取る。そして規則 L2 が表示のために並べ替えます — 「そのレベル以上にある連続した文字列を反転する」。

これらを合わせると、失敗はランダムではなく決定的です。ラテン文字のかたまり — リミキサーの名前、feat.、Vol. 2、カタログ番号、年号 — は、周囲のアラビア文字とは異なる埋め込みレベルに置かれます。その境界にある中立文字（空白、開き括弧）は片側にアラビア文字、もう片側にラテン文字を持つので、N1 は合意を見つけられず、N2 がそれらに段落方向を与えます。あなたの右から左のテキストエディタで一方向に解決された括弧は、左から右のストアページでは逆方向に解決され、括弧は離れて反転します。

ですから نام آهنگ (Nima Remix) は壊れていません。一つの文字列が、二つの文脈で解決されているだけです。基準方向は内容ではなく文脈であり、ストアの文脈はあなたの文脈ではありません。

絶対にしてはいけないこと

プレビューが正しく見えるまで文字を逆向きに打ち込んで、表示を「直す」のはやめてください。

それが生むのは、論理順では誤っていて、ちょうど一つの描画文脈でだけ正しく、それ以外のあらゆる場所で壊れている文字列です。検索も、ソートも、アーティストの名寄せも、あなたが直したツールとは違う基準方向のページを持つすべてのストアも含めてです。回復可能な表示の問題を、回復不能なデータの問題に変えたことになります。

UAX #9 は、これを明示的に制御するための文字を定義しています。分離子の LRI、RLI、FSI、PDI、そしてマークの LRM、RLM、ALM です。技術的にはこれが正しい解です。同時にこれらは不可視の書式制御文字であり、多くの納品パイプラインは不可視の書式制御文字を、何も告げずに取り除きます。メタデータのフィールドでは信頼できないものとして扱ってください。

構造的な解決策：ラテン文字を真ん中から外に出す

どんな描画環境でも、不可視文字なしで機能する緩和策は、構造的なものです。望ましい順に、

• データモデルが用意しているところでは、方向の混ざった文字列ではなく別フィールドを使ってください。 フィーチャリングのアーティストは、タイトルの中ではなくアーティスト・ロールの階層に属します。Music Biz の Music Metadata Style Guide は、フィーチャリングのアーティストはアーティスト・ロールの階層でクレジットし、そのデータをトラックやアルバムのリリースタイトルに加えないよう助言しています。Spotify の公開ガイダンスは "You shouldn't include any artists' names in your track or release titles."（トラックやリリースのタイトルにアーティスト名を含めるべきではありません。）です。バージョンはバージョン・フィールドに属します。そのフィールドの仕事はまさに、同じタイトルを共有する二つの原盤を区別することです。自分のフィールドに移したラテン文字のかたまりの数だけ、双方向の境界が消えていきます。
• 避けられないラテン文字のかたまりは、先頭に置かないでください。 先頭の位置は P2–P3 のもとで段落方向を決めます。ラテン語の単語で始まるペルシア語のタイトルは、ペルシア語を含む左から右の段落であり、あなたが意図したものではありません。
• 方向の境界に装飾的な約物を置かないでください。 ダッシュ、スラッシュ、縦線、入れ子の括弧は、アルゴリズムが最も情報を持たない場所に置かれた中立文字です。

契約上どうしてもタイトルにクレジットを入れる必要がある場合、慣習は定まっていて、そのとおりに従う価値があります。Music Biz は「feat.」と「with」についてこう述べています。"when included in the title are generally lowercase and in English."（タイトルに含める場合、一般に小文字で英語とする。）Apple のスタイルガイドは、"Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets."（「feat.」と「with」の表記は小文字、英語、ローカライズせず、丸括弧または角括弧に入れること。）です。この "not localized"（ローカライズしない）という指示はここで実際に働いています。タイトル・フィールドの中で「feat.」をアラビア語、ペルシア語、ウルドゥー語に訳さないでください。これは機械可読なトークンであって、単語ではありません。

数字、そしてあなたの数字が思っている数字ではないかもしれない理由

三つの数字体系が関わっています。

これらは字体の違いではありません。別のコードポイントであり、Unicode 文字データベースによれば双方向クラスすら共有していません。UAX #9 の規則 W2 は、直前の最も近い強い文字がアラビア文字である場合に European Number を Arabic Number に再分類するので、ペルシア語のテキストの中では、表示の時点では両者が同じように振る舞うことがあります。しかしソートでも検索でも文字列比較でも、決して同じにはなりません。別の文字だからです。拡張アラビア・インド数字の ۲ で打った「Vol. 2」と、ASCII の 2 で打った「Vol. 2」は、ほとんど見分けのつかない、二つの別の文字列です。

カタログごとに数字体系を一つ選び、一つの文字列の中で体系を混ぜないでください。

自分が実際に何を打ったのかを確認する方法

表示は信用できないので、バイト列を確認します。納品のたびに、三つやる価値があります。

1. 文字列をグリフとしてではなくコードポイントとして読んでください。 U+ の値を見せてくれるツールなら、それがペルシア語の ی（U+06CC）なのかアラビア語の ي（U+064A）なのか、ペルシア語の ک（U+06A9）なのかアラビア語の ك（U+0643）なのかを、即座に教えてくれます。ほとんどのフォントが潰してしまい、どんな校正者にも見えない区別です。同じことが、迷い込んだタトウィール（U+0640）— どの Unicode 正規化形式でも除去されません — や、入力フィールドが黙って飲み込んだゼロ幅非接合子（U+200C）にも当てはまります。
2. タイトルを左から右の文脈と右から左の文脈に貼り付けて、比べてください。 二つで約物の位置が変わるなら、それは方向の混ざった文字列であり、独立したフィールドに置くべきラテン文字のかたまりがあるということです。
3. 前作と、目視ではなく一文字ずつ比較してください。 アラビア文字でカタログが分裂する原因は、ほぼ必ず見えない差です。あるリリースはペルシア語のキーボード配列で、次はアラビア語の配列で打たれた、というような。

Mazufa のツールは完全にあなたのブラウザ上で動き — 音源もテキストもアップロードされません — タイトルが右から左のときには自動で dir="rtl" を設定するので、入力中に見えているものが、その文字列が書かれた文脈と一致します。mazufa.com には、あなたの端末上で動いて見えない事例のいくつかを検出する無料のメタデータチェッカーもあります。数字体系の混在、タトウィール、余分なまたは欠けた ZWNJ、アラビア語とペルシア語のヤーとカーフの違い、NFC でない文字列を検出します。

納品前にやること

次のリリースのタイトルとアーティスト名を取り、四つのことをしてください。移せるラテン文字のかたまりはすべて自分のフィールドに移す — フィーチャリングのアーティストはアーティスト・ロールへ、バージョンはバージョン・フィールドへ。ラテン語の単語で始まっていないことを確かめる。数字体系を統一し、タトウィールを取り除く。そのうえで文字列を一度コードポイントとして読み、その正確な文字列を、今後のすべてのリリースで打ち直さずに再利用する正典の表記として保存してください。

それでもタイトルが真ん中にラテン文字のかたまりを抱えざるをえないなら、そのまま納品して、場所によって描画が変わることを受け入れてください。それは表示の結果であって、損傷ではありません。文字列は正しいのです。一つのプレビューを正しく見せるために逆向きに打ち直すことこそ、それを本当に誤らせる唯一の方法です。

出典

• 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 — 文字プロパティ：双方向クラス、分解マッピング — 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/

当社の資料は、これらの文書について上に挙げたバージョンと改訂日を記録しており、それとは別の読み取り日は記録していません。