सबटाइटल में BOM जोड़ें
या सबटाइटल टेक्स्ट पेस्ट करें
विकल्प
BOM फ़ाइल के बिल्कुल शुरू में तीन बाइट हैं जो बताते हैं कि फ़ाइल किस एन्कोडिंग में है। हर एडिटर और प्लेयर में वह अदृश्य है, स्क्रीन पर जगह नहीं लेता, और जोड़ने या हटाने से सबटाइटल में कुछ नहीं बदलता। दो तरह के टूल उसकी परवाह करते हैं: सबटाइटल लिखने वाले Windows प्रोग्राम, जो डिफ़ॉल्ट रूप से एक डाल देते हैं, और बिल्ड पाइपलाइन के सख़्त पार्सर, जो उससे शुरू होने वाली फ़ाइल अस्वीकार करते हैं। यह पेज बॉक्स को उसी हालत में खोलता है जो उसका शीर्षक बताता है, ताकि अगर आपकी फ़ाइल दरअसल दूसरी तरह की निकले तो आप उसे पलट सकें। UTF-16 की फ़ाइल हमेशा BOM रखती है, क्योंकि पाठक उसी से जानता है कि दोनों में से कौन-सा बाइट क्रम देख रहा है — वहाँ हटाने को कहने पर भी वह बना रहता है।
टाइमिंग किस फ़्रेम रेट में गिनी गई है। फ़ॉर्मैट पेजों पर यही MicroDVD को चाहिए, क्योंकि वह टाइमिंग फ़्रेम संख्याओं में रखता है। फ़्रेम रेट पेजों पर यह वह रेट है जिसके हिसाब से फ़ाइल की टाइमिंग की गई थी — वह संस्करण जिसके लिए सबटाइटल बने थे — और पेज का दूसरा बॉक्स उस वीडियो का रेट लेता है जिसके साथ आप इन्हें इस्तेमाल करेंगे। 23.976, 24, 25, 29.97, 30, 50, 59.94 और 60 आम हैं। गलत होने पर पूरी टाइमलाइन खिसक जाती है, और फ़्रेम रेट पेजों पर वह एक अनुपात से खिसकती है, तय मात्रा से नहीं।
यह पेज सबटाइटल फ़ाइल के शुरू में एक BOM जोड़ता है — यूनिकोड का वह अदृश्य चिह्न जो पाठक को बताता है कि फ़ाइल UTF-8 में है। वह एक ही बाइट-क्रम जोड़ता है, और फ़ाइल का बाकी सब कुछ वैसा ही रहता है: मौजूदा पंक्ति एंडिंग, टेक्स्ट, टाइमकोड, क्यू का क्रम और फ़ॉर्मैट का ढाँचा।
BOM की ज़रूरत अक्सर उस पुराने सॉफ़्टवेयर पर पड़ती है जो UTF-8 को उसके चिह्न से पहचानता है, और बिना चिह्न वाली फ़ाइल को किसी दूसरे कोडपेज में पढ़ लेता है — नतीजा यह होता है कि उच्चारण-चिह्न और ग़ैर-लैटिन अक्षर कचरा बनकर दिखते हैं। BOM जोड़ना उस सॉफ़्टवेयर से बात करने का सबसे सस्ता तरीका है, भले ही आधुनिक टूल BOM के बिना भी UTF-8 ठीक पढ़ते हों।
दो बातें जानना ज़रूरी है। पहली, यह दौर दोबारा चलाने पर दूसरा BOM नहीं जोड़ता: अगर फ़ाइल में पहले से BOM है तो नतीजा वही रहता है, इसलिए कई बार चलाना सुरक्षित है। दूसरी, वह पंक्ति एंडिंग को नहीं छूता — जिस फ़ाइल में CRLF थे उसमें CRLF ही रहेंगे और जिसमें LF थे उसमें LF — क्योंकि BOM जोड़ना और लाइन एंडिंग बदलना दो अलग माँगें हैं और यह पेज केवल पहली पूरी करता है।
यह साइट के सभी बारह पढ़े जाने वाले फ़ॉर्मैट पर काम करता है, क्योंकि BOM फ़ॉर्मैट का नहीं, बाइट्स का गुण है — SRT हो या ASS, TTML हो या JSON, जोड़ने का काम एक ही है। कुछ अपलोड नहीं होता, और BOM वाली फ़ाइल में BOM दिखता नहीं, इसलिए अगर आप सिर्फ़ खोलकर देखेंगे तो फ़र्क़ नहीं दिखेगा — इसीलिए नतीजा बाइट-स्तर पर जाँचें, न कि पाठक की आँख से।
उदाहरण
UTF-8 फ़ाइल में BOM जोड़ना
इनपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
आउटपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
फ़ाइल के शुरू में तीन बाइट जुड़ते हैं और बाकी सब वैसा ही रहता है; पाठक में खोलने पर पहला अक्षर नहीं बदलता, क्योंकि पाठक BOM को चिह्न की तरह पढ़ता है। टाइमकोड, क्यू की संख्या और पंक्तियाँ सब अपनी जगह हैं, और फ़ाइल का आकार बस तीन बाइट बढ़ता है।
पहले से BOM वाली फ़ाइल
इनपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
आउटपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
कुछ नहीं जुड़ता: पहले से BOM था। छलकर दो BOM जोड़ना कुछ पाठकों को बेचैन करता है, इसलिए पेज पहले जाँचता है और फ़ाइल को जस की तस लौटा देता है। यह दोबारा चलाने पर सुरक्षित होने का ठोस आधार है।
CRLF वाली फ़ाइल में BOM
इनपुट
1
00:00:01,000 --> 00:00:02,000
Already marked.
आउटपुट
1
00:00:01,000 --> 00:00:02,000
Already marked.
BOM जुड़ता है और CRLF वैसे ही रहते हैं। यह जानबूझकर है — बहुत सारे टूल लाइन एंडिंग और एनकोडिंग को एक ही समस्या मान लेते हैं, पर वे दो अलग चीज़ें हैं; BOM जोड़े जाने से CRLF न LF नहीं बनते। जिसे दोनों चाहिए उसे दोनों दौर चलाने होंगे।
अक्सर पूछे जाने वाले सवाल
सबटाइटल फ़ाइल में BOM जोड़ने वाला पेज क्या बदलता है?
केवल फ़ाइल के सबसे शुरू में यूनिकोड बाइट-क्रम चिह्न जोड़ता है, जो UTF-8 में U+FEFF को तीन बाइट में लिखता है। वह टेक्स्ट, टाइमकोड, क्यू का क्रम, पंक्ति एंडिंग और फ़ॉर्मैट का ढाँचा नहीं छूता। अगर फ़ाइल में पहले से BOM है तो कुछ नहीं बदलता, इसलिए इस दौर को कई बार चलाना सुरक्षित है — नतीजा हर बार वही रहता है।
BOM जोड़ने से पाठक में पहला अक्षर बदल जाएगा क्या?
नहीं, अगर पाठक BOM को पहचानता है — और जिन पाठकों के लिए यह जोड़ा जाता है वे पहचानते हैं। BOM चिह्न की तरह पढ़ा जाता है, अक्षर की तरह नहीं। पर ऐसे टूल भी हैं जो BOM को साधारण चिह्न मानकर पहले क्यू के टाइमकोड से पहले एक अदृश्य अक्षर दिखा सकते हैं या उसे पढ़ने में अटक सकते हैं। अगर आपका टूल ऐसा करता है तो BOM न जोड़ें; जिसे जोड़ना ही है उसे दोनों तरह के टूल पर जाँचना चाहिए।
क्या यह पेज लाइन एंडिंग भी बदलता है?
नहीं। BOM जोड़ना और लाइन एंडिंग बदलना दो अलग काम हैं; इस पेज पर केवल पहला होता है। जिस फ़ाइल में CRLF थे उसमें CRLF रहेंगे और LF थे तो LF; मिश्रित एंडिंग भी जस की तस रहती हैं। लाइन एंडिंग बदलने का अपना पेज है जो LF और CRLF चुनने देता है, और वह इन दोनों को एक साथ करने की ज़रूरत पूरी करता है।
BOM जोड़ने पर फ़ाइल का आकार कितना बढ़ता है?
UTF-8 में ठीक तीन बाइट, क्योंकि BOM का कोड बिंदु U+FEFF है और UTF-8 उसे तीन बाइट में लिखता है। अगर फ़ाइल पहले से BOM वाली है तो कुछ नहीं बढ़ता। यह छोटा बदलाव है, पर कुछ जगह फ़ाइल की पहचान बाइट-गिनती से होती है — चेकसम, संलग्नक, किसी तंत्र में दर्ज आकार — और वहाँ तीन बाइट का फ़र्क़ असली फ़र्क़ बन सकता है।
क्या BOM जोड़ने वाला यह पेज हर सबटाइटल फ़ॉर्मैट पर चलता है?
हाँ, साइट के सभी बारह पढ़े जाने वाले फ़ॉर्मैट पर, क्योंकि BOM बाइट्स का गुण है, फ़ॉर्मैट का नहीं। यह फ़ाइल के पाठ को नहीं बदलता, इसलिए यह सवाल ही नहीं उठता कि फ़ॉर्मैट उसे कैसे पढ़ेगा। जो फ़ॉर्मैट पहले से अपना कोई चिह्न रखता है — जैसे LRC का टैग — उसके साथ भी BOM उससे पहले ही जुड़ता है और उसका काम नहीं बिगाड़ता।
अगर मुझे BOM नहीं चाहिए तो क्या करें?
तो यह पेज न चलाएँ, और अगर फ़ाइल में पहले से है तो उसे हटाने वाला पेज चलाएँ। BOM हटाने वाला पेज फ़ाइल के शुरू से चिह्न निकालता है और बाकी सब वैसा ही रखता है; ध्यान रहे कि UTF-16 फ़ाइल में BOM बाइट-क्रम बताने का संरचनात्मक हिस्सा है और उसे हटाना फ़ाइल को बिगाड़ सकता है, इसलिए वहाँ पेज अलग बर्ताव करता है।