وقتی عنوانی عربی، فارسی یا اردو به فروشگاهی میرسد و پرانتز در سمت اشتباه نشسته، اعتبار «feat.» به دورترین گوشه رانده شده، یا شمارهٔ کاتالوگ جایی شناور است که نباید باشد، هیچ چیز خراب نشده است. بایتهایی که تایپ کردهاید تقریباً همیشه همان بایتهایی هستند که رسیدهاند. آنچه تغییر کرده جهت پایهٔ کادری است که متن در آن ترسیم میشود، و این را صفحهٔ فروشگاه تعیین میکند، نه عنوان شما. این مقاله سازوکار را آنقدر دقیق شرح میدهد که بتوانید پیش از تحویل پیشبینی کنید کدام یک از عنوانهایتان به هم میریزد.
یک نکته را همین ابتدا بگوییم، چون موضع صادقانه همین است: ما از هیچ اندازهگیری منتشرشدهای دربارهٔ نرخ خطای فراداده به خط عربی در هیچ جای این صنعت خبر نداریم. مسئله را همه تجربه کردهاند و هیچکس آن را نسنجیده است. در ادامه هیچ عددی نمیآید، چون عددی برای دادن وجود ندارد.
ترتیب منطقی و ترتیب نمایش دو چیز جدا هستند
یونیکد متن را در ترتیب منطقی ذخیره میکند — همان ترتیبی که آن را میگویید، تایپ میکنید و بلند میخوانید. ترتیب نمایش هنگام ترسیم از روی آن محاسبه میشود، به دست الگوریتم دوجهتهٔ یونیکد که در Unicode Standard Annex #9 (UAX #9) تعریف شده است. خود این پیوست دربارهٔ این جدایی صریح است: "The Unicode Standard prescribes a memory representation order known as logical order" و "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."
همین یک جمله پدیدهای را توضیح میدهد که باعث میشود هنرمندان خط عربی گمان کنند فرادادهٔ آنها جنزده است: رشتهٔ ذخیرهشده میتواند کاملاً درست باشد و نمایش غلط، و میتواند از نظر دیداری درست باشد و بایتهای ذخیرهشده غلط — و روی صفحه، این دو خرابی یکسان به نظر میرسند. این را با نگاه کردن نمیشود بازرسی کرد. کارشناس پشتیبانی توزیعکنندهٔ شما هم نمیتواند.
چرا یک واژهٔ لاتین درون رشتهای راستبهچپ جابهجا میشود
UAX #9 به هر نویسه یک نوع دوجهته میدهد. حروف عربی، فارسی و اردو AL هستند (حروف عربی راستبهچپ). حروف لاتین L هستند. ارقام اَسکی EN (عدد اروپایی) و ارقام عربیـهندی AN (عدد عربی) هستند. فاصلهها و بیشتر نشانههای نگارشی — از جمله پرانتز، کروشه، خط تیره و نقطه — خنثی هستند، یعنی جهتی از خود ندارند و آن را از پیرامون خود میگیرند.
دو گروه از قواعد کار را خراب میکنند.
جهت بند، قواعد P2–P3. الگوریتم به دنبال نخستین نویسهٔ جهتدار قوی میگردد و جهت پایه را از روی آن تعیین میکند. عنوانی که با یک واژهٔ لاتین آغاز شود جهت پایهٔ چپبهراست میگیرد، حتی اگر همهٔ آنچه پس از آن میآید فارسی باشد.
تعیین تکلیف خنثیها، قواعد N1–N2. قاعدهٔ N1: "A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction." قاعدهٔ N2: خنثیهایی که اجماعی بر سرشان نیست جهت بند را میگیرند. سپس قاعدهٔ L2 برای نمایش بازچینش میکند — "reverse any contiguous sequence of characters that are at that level or higher."
اینها را کنار هم بگذارید و میبینید خرابی جبری است، نه تصادفی. یک واژهٔ لاتین — نام ریمیکسر، feat.، Vol. 2، شمارهٔ کاتالوگ، یک سال — در سطح جاسازی متفاوتی از متن عربی پیرامونش مینشیند. خنثیهای روی مرزهای آن (فاصله، پرانتز باز) یک طرفشان عربی است و طرف دیگر لاتین، پس N1 اجماعی نمییابد و N2 جهت بند را به آنها میدهد. پرانتزی که در ویرایشگر متن راستبهچپ شما به یک صورت تعیین تکلیف شده بود، در صفحهٔ چپبهراست فروشگاه به صورت دیگری تعیین تکلیف میشود، و پرانتز جدا میشود و میچرخد.
پس نام آهنگ (Nima Remix) خراب نیست. یک رشته است که در دو بافت متفاوت تعیین تکلیف میشود. جهت پایه بافت است، نه محتوا، و بافت فروشگاه بافت شما نیست.
تنها کاری که هرگز نباید بکنید
نمایش را با تایپ کردن وارونهٔ نویسهها تا وقتی پیشنمایش درست به نظر برسد «درست» نکنید.
نتیجه رشتهای است که در ترتیب منطقی غلط است، در دقیقاً یک بافت نمایشی درست است، و همه جای دیگر خراب — از جمله در جستوجو، مرتبسازی، تطبیق هنرمند و هر فروشگاهی که جهت پایهٔ صفحهاش با ابزاری که در آن «درستش» کردهاید فرق دارد. شما یک مشکل نمایشی را که برگشتپذیر است به یک مشکل دادهای تبدیل کردهاید که برگشتپذیر نیست.
UAX #9 برای مهار صریح این موضوع نویسههایی تعریف میکند: جداسازهای LRI، RLI، FSI و PDI و نشانههای LRM، RLM و ALM. اینها از نظر فنی راهحل درست هستند. همچنین نویسههای قالببندی نامرئی هستند، و بسیاری از خطوط لولهٔ تحویل نویسههای قالببندی نامرئی را بیآنکه به شما بگویند حذف میکنند. در یک فیلد فراداده آنها را نامطمئن بدانید.
راهحل ساختاری: واژهٔ لاتین را از وسط بیرون بیاورید
کاهش خطری که همه جا، در هر موتور ترسیمی و بدون هیچ نویسهٔ نامرئی جواب میدهد، ساختاری است. به ترتیب اولویت:
- هر جا مدل داده فیلد جداگانه میدهد، به جای رشتههای آمیختهٔ دوجهته از فیلدهای جدا استفاده کنید. هنرمند مهمان جایش در سطح نقش هنرمند است، نه در عنوان. راهنمای Music Metadata Style Guide از Music Biz توصیه میکند اعتبار هنرمندان مهمان در سطح نقش هنرمند ثبت شود و این داده به عنوان قطعه یا عنوان انتشار آلبوم افزوده نشود؛ راهنمای عمومی 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." همین دستور "not localized" اینجا کار جدی میکند — «feat.» را در فیلد عنوان به عربی، فارسی یا اردو ترجمه نکنید. این یک نشانهٔ ماشینخوان است، نه یک واژه.
ارقام، و چرا ارقام شما شاید آنهایی نباشند که فکر میکنید
سه مجموعهٔ رقم در میداناند:
| مجموعه | نقطهکدها | کاربرد در | ردهٔ دوجهته |
|---|---|---|---|
| اَسکی | 0–9 | همه جا | EN |
| عربیـهندی | U+0660–U+0669 (٠١٢٣٤٥٦٧٨٩) | عربی | AN |
| عربیـهندی گسترده | U+06F0–U+06F9 (۰۱۲۳۴۵۶۷۸۹) | فارسی، اردو | EN |
اینها گونههای سلیقهای یک چیز نیستند. نقطهکدهای متفاوتی هستند، و بنا بر پایگاه دادهٔ نویسههای یونیکد حتی ردهٔ دوجهتهٔ مشترکی ندارند. قاعدهٔ W2 در UAX #9 یک عدد اروپایی را وقتی نزدیکترین نویسهٔ قوی پیش از آن حرفی عربی باشد به عدد عربی بازنوعگذاری میکند، پس درون متن فارسی این دو ممکن است هنگام نمایش یکسان رفتار کنند — اما هرگز در مرتبسازی، جستوجو یا مقایسهٔ رشته، چون نویسههای متفاوتی هستند. یک "Vol. 2" که با ۲ عربیـهندی گسترده تایپ شده و یک "Vol. 2" که با 2 اَسکی تایپ شده دو رشتهٔ متفاوتاند که تقریباً یکسان دیده میشوند.
برای هر کاتالوگ یک مجموعهٔ رقم انتخاب کنید و هرگز دو مجموعه را درون یک رشته با هم نیامیزید.
چگونه بررسی کنیم واقعاً چه تایپ کردهایم
به نمایش نمیشود اعتماد کرد، پس بایتها را بررسی کنید. سه کار پیش از هر تحویل ارزش انجام دادن دارد:
- رشته را به صورت نقطهکد بخوانید، نه به صورت نگاره. هر ابزاری که مقادیر U+ را نشانتان بدهد بیدرنگ میگوید که آن ی فارسی (U+06CC) است یا ي عربی (U+064A)، ک فارسی (U+06A9) است یا ك عربی (U+0643) — تمایزی که بیشتر قلمها آن را یکدست میکنند و هیچ نمونهخوانی نمیبیندش. همین دربارهٔ کشیدهٔ سرگردان (U+0640) صدق میکند که هیچ صورت هنجارسازی یونیکد آن را برنمیدارد، و دربارهٔ نیمفاصلهای (U+200C) که یک فیلد فرم بیصدا خورده است.
- عنوان را در یک بافت چپبهراست و یک بافت راستبهچپ بچسبانید و مقایسه کنید. اگر نشانههای نگارشی در این دو جای متفاوتی بنشینند، رشتهٔ شما آمیختهٔ دوجهته است و واژهای لاتین دارد که باید در فیلد خودش باشد.
- با انتشار قبلیتان مقایسه کنید، نویسه به نویسه، نه با چشم. کاتالوگهای دوپاره به خط عربی تقریباً همیشه از تفاوتی نامرئی میآیند: یک انتشار روی چیدمان صفحهکلید فارسی تایپ شده و انتشار بعدی روی چیدمان عربی.
ابزارهای Mazufa تماماً در مرورگر شما اجرا میشوند — هیچ صدا و هیچ متنی بارگذاری نمیشود — و وقتی عنوانی راستبهچپ باشد خودکار dir="rtl" میگذارند، تا آنچه هنگام تایپ میبینید با بافتی که رشته برای آن نوشته شده بخواند. در mazufa.com یک بررسیکنندهٔ فرادادهٔ رایگان هم هست که روی دستگاه خودتان اجرا میشود و چند مورد از حالتهای نامرئی را علامت میزند: آمیختن مجموعههای رقم، کشیده، نیمفاصلهٔ زائد یا جاافتاده، یِ و کِ عربی در برابر فارسی، و رشتههای غیر 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/
پیکرهٔ منابع تاریخ نسخه و بازنگری این اسناد را همانگونه که در بالا آمده میدهد و تاریخ قرائت جداگانهای برای آنها ثبت نکرده است.