आपका अरबी शीर्षक ख़राब नहीं हुआ है — स्टोर उसे दूसरी दिशा में पढ़ रहा है

8 मिनट का पाठहर आँकड़ा स्रोत-सहित

जब कोई अरबी, फ़ारसी या उर्दू शीर्षक किसी स्टोर पर ब्रैकेट ग़लत तरफ़ लिए हुए पहुँचता है, या "feat." का क्रेडिट दूर सिरे पर धकेल दिया जाता है, या कोई कैटलॉग नंबर वहाँ तैरता दिखता है जहाँ उसे नहीं होना चाहिए — तो कुछ भी ख़राब नहीं हुआ है। आपने जो बाइट टाइप किए थे, लगभग हमेशा वही बाइट पहुँचे हैं। जो बदला है वह उस डिब्बे की आधार दिशा है जिसमें टेक्स्ट खींचा जा रहा है, और वह स्टोर का पेज तय करता है, आपका शीर्षक नहीं। यह लेख उस तंत्र को इतनी सटीकता से समझाता है कि आप डिलीवर करने से पहले ही अंदाज़ा लगा सकें कि आपके कौन-से शीर्षक बिगड़ेंगे।

शुरू में ही एक बात कहनी है, क्योंकि ईमानदार स्थिति यही है: हमें उद्योग में कहीं भी अरबी-लिपि मेटाडेटा की त्रुटि-दरों का कोई प्रकाशित मापन नहीं मिला। यह समस्या सब भोगते हैं और इसे किसी ने नापा नहीं है। नीचे कोई आँकड़ा नहीं आता, क्योंकि देने को कोई आँकड़ा है ही नहीं।

तार्किक क्रम और प्रदर्शन क्रम दो अलग चीज़ें हैं

Unicode टेक्स्ट को तार्किक क्रम में रखता है — यानी उसी क्रम में जिसमें आप उसे बोलते, टाइप करते और पढ़ते हैं। प्रदर्शन क्रम उससे रेंडर के समय निकाला जाता है, उस Unicode Bidirectional Algorithm से जो 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."

यही एक वाक्य उस परिघटना को समझा देता है जिसकी वजह से अरबी-लिपि के आर्टिस्ट मानने लगते हैं कि उनके मेटाडेटा पर कोई साया है: संग्रहीत स्ट्रिंग बिलकुल सही हो सकती है जबकि प्रदर्शन ग़लत हो, और वह दिखने में सही हो सकती है जबकि संग्रहीत बाइट ग़लत हों — और स्क्रीन पर दोनों गड़बड़ियाँ एक जैसी दिखती हैं। आप इसे देखकर जाँच नहीं सकते। आपके डिस्ट्रिब्यूटर का सपोर्ट एजेंट भी नहीं।

RTL स्ट्रिंग के भीतर लैटिन टोकन क्यों खिसकता है

UAX #9 हर वर्ण को एक द्विदिश (bidirectional) प्रकार देता है। अरबी, फ़ारसी और उर्दू अक्षर AL हैं (दाएँ-से-बाएँ अरबी अक्षर)। लैटिन अक्षर L हैं। ASCII अंक 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 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." उस "not localized" निर्देश का यहाँ असली काम है — शीर्षक फ़ील्ड में "feat." का अरबी, फ़ारसी या उर्दू अनुवाद मत कीजिए। यह मशीन से पढ़ा जाने वाला टोकन है, कोई शब्द नहीं।

अंक, और आपके अंक शायद वे न हों जो आप समझते हैं

तीन अंक-समूह खेल में हैं:

समूहकोड पॉइंटकहाँ इस्तेमालBidi वर्ग
ASCII0–9हर जगहEN
अरबी-हिंदसाU+0660–U+0669 (٠١٢٣٤٥٦٧٨٩)अरबीAN
विस्तारित अरबी-हिंदसाU+06F0–U+06F9 (۰۱۲۳۴۵۶۷۸۹)फ़ारसी, उर्दूEN

ये शैली के भेद नहीं हैं। ये अलग कोड पॉइंट हैं, और Unicode Character Database के अनुसार इनका द्विदिश वर्ग तक साझा नहीं है। UAX #9 का नियम W2 किसी यूरोपीय संख्या को अरबी संख्या में फिर से वर्गीकृत कर देता है जब निकटतम पूर्ववर्ती प्रबल वर्ण कोई अरबी अक्षर हो, इसलिए फ़ारसी टेक्स्ट के भीतर दोनों प्रदर्शन के समय एक जैसा बर्ताव कर सकते हैं — पर सॉर्टिंग, सर्च या स्ट्रिंग तुलना में कभी नहीं, क्योंकि ये अलग वर्ण हैं। विस्तारित अरबी-हिंदसा ۲ से टाइप किया गया "Vol. 2" और ASCII 2 से टाइप किया गया "Vol. 2" दो अलग स्ट्रिंग हैं जो देखने में लगभग एक जैसी हैं।

अपने कैटलॉग के लिए एक अंक-समूह चुनिए और एक ही स्ट्रिंग के भीतर समूह कभी मत मिलाइए।

आपने असल में जो टाइप किया, उसे कैसे जाँचें

प्रदर्शन पर भरोसा नहीं किया जा सकता, इसलिए बाइट जाँचिए। हर डिलीवरी से पहले तीन काम करने लायक हैं:

  1. स्ट्रिंग को ग्लिफ़ के बजाय कोड पॉइंट के रूप में पढ़िए। कोई भी टूल जो आपको U+ मान दिखाता है, तुरंत बता देगा कि वह फ़ारसी ی (U+06CC) है या अरबी ي (U+064A), फ़ारसी ک (U+06A9) है या अरबी ك (U+0643) — ऐसा भेद जिसे ज़्यादातर फ़ॉन्ट चपटा कर देते हैं और कोई प्रूफ़रीडर देख नहीं सकता। यही बात किसी भटके हुए तत्वील (U+0640) पर लागू होती है, जिसे कोई Unicode नॉर्मलाइज़ेशन रूप नहीं हटाता, और उस ज़ीरो-विड्थ नॉन-जॉइनर (U+200C) पर भी जिसे किसी फ़ॉर्म फ़ील्ड ने चुपचाप निगल लिया हो।
  2. शीर्षक को एक बाएँ-से-दाएँ संदर्भ में और एक दाएँ-से-बाएँ संदर्भ में चिपकाकर तुलना कीजिए। अगर दोनों में विरामचिह्न अलग-अलग जगह गिरते हैं, तो आपके पास मिश्रित-दिशा वाली स्ट्रिंग है और एक ऐसा लैटिन टोकन है जिसे अपने फ़ील्ड में होना चाहिए।
  3. अपनी पिछली रिलीज़ से तुलना कीजिए, वर्ण-दर-वर्ण, आँख से नहीं। अरबी लिपि में बँटे हुए कैटलॉग लगभग हमेशा किसी ऐसे अंतर से बनते हैं जो दिखता नहीं: एक रिलीज़ फ़ारसी कीबोर्ड लेआउट पर टाइप हुई, अगली अरबी पर।

मज़ुफ़ा के टूल पूरी तरह आपके ब्राउज़र में चलते हैं — न कोई ऑडियो अपलोड होता है, न कोई टेक्स्ट — और जब शीर्षक दाएँ-से-बाएँ होता है तो वे अपने आप 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/

संग्रह इन दस्तावेज़ों के लिए संस्करण और संशोधन तिथियाँ देता है, जैसा ऊपर सूचीबद्ध है, और इनके लिए कोई अलग पढ़ने की तारीख़ दर्ज नहीं करता।

मुफ़्त टूल

मज़ुफ़ा जो भी टूल बनाता है वह आपके ब्राउज़र में ही चलता है, उसका कोई शुल्क नहीं है और उसके लिए अकाउंट की ज़रूरत नहीं।

टूलकिट खोलें ⇥