वीडियो और उपशीर्षक · उपशीर्षक टूलकिट
ब्राउज़र SRT फ़ाइल को कैसे पार्स करता है: ब्लॉक, इंडेक्स, टाइमकोड और टेक्स्ट
· यह काम किस प्रकार करता है
उपशीर्षक SRT फ़ाइल स्वरूपों
SRT जब तक आपको वास्तविक फ़ाइलें नहीं मिलतीं, तब तक यह तुच्छ लगता है। यह पोस्ट बताती है कि कैसे एक पार्सर ब्लॉक को विभाजित करता है, इंडेक्स और टाइमकोड को पढ़ता है, मल्टी-लाइन टेक्स्ट को संभालता है और वास्तविक दुनिया की फाइलों में मौजूद विकृत ब्लॉक से उबरता है।
फ़ाइल 'ठीक दिखती है' लेकिन आधे संकेत गायब हैं - कैसे एक उदार दिखने वाला प्रारूप सख्त अपेक्षाओं को छुपाता है
SRT में कोई विनिर्देशन निकाय नहीं है, कोई MIME पंजीकरण नहीं है और कोई सत्यापनकर्ता नहीं है जो खिलाड़ियों के साथ भेजा जाता है। इसके बजाय जो मौजूद है वह एक आकृति है जिस पर अधिकांश सॉफ़्टवेयर सहमत हैं: एक संख्या, एक टाइमकोड लाइन, पाठ की एक या अधिक पंक्तियाँ, फिर एक रिक्त रेखा। क्योंकि आकार निर्दिष्ट होने के बजाय पारंपरिक है, दो फ़ाइलें एक टेक्स्ट एडिटर में सही दिख सकती हैं जबकि उनमें से केवल एक ही लोड होता है, और विफलता आमतौर पर चुप रहती है। एक खिलाड़ी जो किसी क्यू को नहीं पढ़ सकता है वह उसे रिपोर्ट करने के बजाय उसे छोड़ देता है, इसलिए टूटे हुए ब्लॉक वाली फ़ाइल त्रुटि के बजाय अंतराल के साथ खेलती है।
इसलिए एक पार्सर के दो कार्य होते हैं जो विपरीत दिशाओं में खींचते हैं। इसे वास्तविक फ़ाइलों में मौजूद विविधताओं को स्वीकार करना होगा, क्योंकि फ़ाइलें प्रतिलेखन सेवाओं, हाथ संपादन और प्रारूप कन्वर्टर्स द्वारा उत्पादित की जाती हैं जो प्रत्येक अलग-अलग धारणाएं बनाती हैं। इसे उन रीडिंग को भी अस्वीकार करना होगा जो गलत समय पर संकेत देगी, क्योंकि चुपचाप गलत टाइमस्टैम्प रिपोर्ट की गई विफलता से भी बदतर है।
ब्लॉकों में विभाजित करना - विभाजक के रूप में रिक्त रेखाएँ और आवारा रिक्त स्थान और CRLF के साथ समस्या
विभाजन रिक्त रेखाओं पर होता है, सूचकांक संख्याओं पर नहीं। पार्सर सबसे पहले लाइन के अंत को सामान्य करता है, CRLF जोड़ी और एक अकेले CR दोनों को एक ही नई लाइन से बदल देता है, क्योंकि विंडोज़ पर लिखी गई और Unix पर संपादित फ़ाइल में दोनों शामिल हो सकते हैं। इसके बाद यह दो या दो से अधिक नई लाइनों में विभाजित हो जाता है, प्रत्येक परिणामी ब्लॉक को ट्रिम कर देता है और खाली ब्लॉक को हटा देता है। वह क्रम मायने रखता है: सामान्यीकरण से पहले विभाजन करने से टाइमकोड लाइन के अंत में एक भटकी हुई गाड़ी वापस आ जाएगी, और फिर टाइमकोड मिलान करने में विफल हो जाएगा।
इनमें से किसी से भी पहले एक बाइट ऑर्डर चिह्न हटा दिया जाता है। किसी फ़ाइल की शुरुआत में एक UTF-8 BOM तीन बाइट्स होते हैं जिन्हें एक अनुभवहीन पार्सर पहले इंडेक्स नंबर के हिस्से के रूप में देखता है, जो पहले क्यू को अपठनीय बनाने के लिए पर्याप्त है जबकि प्रत्येक बाद वाला क्यू पार्स करता है। अन्यथा रिक्त विभाजक रेखा पर अनुगामी रिक्त स्थान को ट्रिम द्वारा नियंत्रित किया जाता है, इसलिए एक फ़ाइल जिसकी रिक्त रेखाओं में एक स्थान होता है वह अभी भी सही ढंग से विभाजित होती है।
सूचकांक रेखा - संख्याएं अक्सर गलत, दोहराई गई या गायब क्यों होती हैं और पार्सर्स को उन पर भरोसा क्यों नहीं करना चाहिए
सूचकांक संख्या को पढ़ा जाता है और फिर अनदेखा कर दिया जाता है। वास्तविक फ़ाइलें संख्या शून्य से संकेत देती हैं, मर्ज के बाद क्रमांकन पुनः आरंभ करती हैं, मैन्युअल संपादन के बाद किसी संख्या को डुप्लिकेट करती हैं, या जब कोई कन्वर्टर फ़ाइल लिखता है तो लाइन को पूरी तरह से छोड़ देता है। उन नंबरों पर भरोसा करने का मतलब है कि उन सभी दोषों को विरासत में लेना, इसलिए पार्सर अब तक सफलतापूर्वक बनाए गए संकेतों की गिनती करते हुए, इसके बजाय अपना स्वयं का अनुक्रमिक नंबर निर्दिष्ट करता है।
यह विकल्प यह भी बताता है कि पार्सर को कभी भी इंडेक्स लाइन की उपस्थिति की आवश्यकता क्यों नहीं होती है। यह टाइमकोड को दूसरी पंक्ति मानने के बजाय, तीर वाली पहली पंक्ति के लिए ब्लॉक खोजकर टाइमकोड लाइन का पता लगाता है। बिना इंडेक्स लाइन वाला ब्लॉक सामान्य रूप से पार्स होता है, और टाइमकोड से पहले दो भटकी हुई लाइनों वाला ब्लॉक अभी भी पार्स होता है, क्योंकि स्थिति वह नहीं है जो टाइमकोड की पहचान करती है।
टाइमकोड लाइन - एचएच: एमएम: एसएस, एमएमएम -> एचएच: एमएम: एसएस, एमएमएम, सहनशील विविधताएं और जो खिलाड़ियों को तोड़ते हैं
टाइमकोड लाइन का मिलान एक नियमित अभिव्यक्ति से किया जाता है, और इसमें सहनशीलता जानबूझकर होती है। घंटे वैकल्पिक हैं, क्योंकि WebVTT दो-फ़ील्ड रीडिंग की अनुमति देता है और कन्वर्टर्स इसे उत्सर्जित करते हैं। या तो अल्पविराम या पूर्ण विराम को मिलीसेकंड विभाजक के रूप में स्वीकार किया जाता है, भले ही फ़ाइल किस प्रारूप में होने का दावा करती है, क्योंकि मिश्रित विभाजक इतने सामान्य हैं कि उन्हें अस्वीकार करने से खराब फ़ाइलों की तुलना में अधिक अच्छी फ़ाइलें विफल हो जाएंगी। आंशिक अंक दाईं ओर गद्देदार होते हैं, इसलिए एक अंक में समाप्त होने वाले संकेत को इकाइयों के बजाय सैकड़ों मिलीसेकंड के रूप में पढ़ा जाता है।
दो रीडिंग से इनकार कर दिया गया है। उनतालीस से ऊपर मिनट या सेकंड फ़ील्ड को ले जाने के बजाय अस्वीकार कर दिया जाता है, क्योंकि नब्बे सेकंड एक घड़ी की रीडिंग नहीं है और आमतौर पर एक भ्रष्ट या गलत रूपांतरित फ़ाइल को इंगित करता है; इसे चुपचाप सामान्य करने से क्यू चालू हो जाएगा। एक पंक्ति जिसका प्रारंभ या अंत पार्स करने में विफल रहता है, आपत्तिजनक पाठ और अपेक्षित आकार का नामकरण करते हुए एक रिकॉर्डेड समस्या उत्पन्न करता है, और अनुमान लगाने के बजाय ब्लॉक को छोड़ दिया जाता है।
पाठ पंक्तियाँ - बहु-पंक्ति संकेत, फ़ॉर्मेटिंग टैग और जहाँ कोई ब्लॉक वास्तव में समाप्त होता है
टाइमकोड लाइन के बाद सब कुछ क्यू टेक्स्ट है, जो नई लाइनों के साथ वापस जुड़ जाता है। इसमें कोई रेखा सीमा नहीं है और पुनः प्रवाहित होने का कोई प्रयास नहीं है, इसलिए तीन-पंक्ति वाला संकेत तीन रेखाओं के रूप में जीवित रहता है। यही कारण है कि रिक्त रेखा लोड-असर वाली होती है: यह एकमात्र चीज है जो पार्सर को बताती है कि पाठ समाप्त हो गया है, यही कारण है कि एक क्यू जिसके स्वयं के पाठ में एक रिक्त रेखा होती है उसे दो ब्लॉक के रूप में पढ़ा जाएगा और दूसरी छमाही को बिना टाइमकोड के रिपोर्ट किया जाएगा।
क्यू सेटिंग्स को अंतिम टाइमस्टैम्प से दो या अधिक स्थानों के क्रम से अलग किया जाता है। WebVTT एक ही लाइन पर अंतिम समय का पालन करने के लिए संरेखण और लाइन प्लेसमेंट जैसे पोजिशनिंग निर्देशों की अनुमति देता है, इसलिए पार्सर टाइमस्टैम्प को पार्स करने से पहले उन्हें अलग कर देता है और उन्हें क्UK साथ रखता है। एक एकल स्थान एक विभाजक नहीं है, जो केवल एक अव्यवस्थित टाइमकोड लाइन को उसके अंतिम समय को खोने से बचाता है।
व्यावहारिक उदाहरण: दो जानबूझकर दोषों के साथ पांच-क्यू फ़ाइल को पार्स करना - एक मजबूत पार्सर क्या पुनर्प्राप्त करता है और यह क्या चिह्नित करता है
एक पांच-ब्लॉक फ़ाइल लें जिसमें ब्लॉक तीन की टाइमकोड लाइन 00:01:75,000 --> 00:01:78,000 पढ़ने के लिए क्षतिग्रस्त हो गई है, और ब्लॉक चार की कॉपी और पेस्ट के दौरान उसकी टाइमकोड लाइन पूरी तरह से खो गई है। पार्सर ब्लॉक एक और दो को सामान्य रूप से पढ़ता है और उन्हें एक और दो नंबर देता है। ब्लॉक तीन एक टाइमकोड के आकार से मेल खाता है लेकिन इसमें पचहत्तर सेकंड का फ़ील्ड होता है, इसलिए इसे अस्वीकार कर दिया जाता है और उस लाइन का नामकरण करते हुए एक खराब टाइमस्टैम्प के रूप में दर्ज किया जाता है जिसे वह पढ़ नहीं सका।
ब्लॉक चार में कोई तीर नहीं है, इसलिए इसे ब्लॉक के पहले चालीस अक्षरों को उद्धृत करते हुए बिना टाइमस्टैम्प के रूप में दर्ज किया गया है, ताकि लाइन को मूल फ़ाइल में पाया जा सके। पाँच पार्स को ब्लॉक करें और क्यू तीन बन जाएँ, न कि क्यू पाँच, क्योंकि क्रमांकन सफल संकेतों को गिनता है। परिणाम तीन उपयोगी संकेत और दो विशिष्ट, स्थित शिकायतें हैं, न कि पहली गलती पर अपवाद और दूसरी के बारे में कोई जानकारी नहीं।
इसमें क्या शामिल नहीं है - ASS/SSA स्टाइलिंग, पोजिशनिंग कोड और गैर-उपशीर्षक टेक्स्ट SRT में डंप किया गया
यह SRT और WebVTT के उन हिस्सों का वर्णन करता है जो इसके क्यू आकार को साझा करते हैं। इसमें ASS और SSA शामिल नहीं हैं, जिनमें एक स्क्रिप्ट हेडर, शैली परिभाषाएँ और प्रति-इवेंट शैली संदर्भ होते हैं, और जिन्हें रिक्त पंक्तियों में विभाजित करके नहीं पढ़ा जा सकता है। कराओके टाइमिंग, ड्राइंग कमांड और उन प्रारूपों में उपयोग किए जाने वाले इनलाइन ओवरराइड टैग क्यू-एंड-टाइमकोड पार्सर मॉडल से बाहर हैं।
यह टेक्स्ट की मरम्मत भी नहीं करता है. बिना टाइमकोड वाली फ़ाइल में चिपकाया गया एक प्रतिलेख उन ब्लॉकों की एक सूची तैयार करता है जिनमें कोई टाइमस्टैम्प नहीं होता है, जिसे सटीक रूप से रिपोर्ट किया जाता है लेकिन समय की जानकारी के बिना उपशीर्षक में नहीं बदला जा सकता है जो मौजूद नहीं है। एन्कोडिंग दोष एक अलग चिंता का विषय है: गलत वर्ण सेट के साथ डीकोड की गई फ़ाइल पूरी तरह से वैध संकेतों में पार्स हो जाती है जिसका पाठ गलत है, और कोई भी संरचनात्मक जांच इसका पता नहीं लगाएगी।
टेकअवे: उदारतापूर्वक पार्स करें, सख्ती से लिखें - उपशीर्षक टूलकिट कैसे गंदे SRT को पढ़ता है और एक साफ लिखता है
कामकाजी नियम यह है कि उदारतापूर्वक विश्लेषण करें और सख्ती से लिखें। रास्ते में, वैकल्पिक घंटों को स्वीकार करें, या तो विभाजक, लापता सूचकांक लाइनें, मिश्रित लाइन अंत और एक अग्रणी बाइट ऑर्डर चिह्न, और प्रत्येक गलती को पहले वाले पर फेंकने के बजाय एक स्थित समस्या के रूप में रिकॉर्ड करें, ताकि एक फ़ाइल को एक ही पास में ठीक किया जा सके। बाहर जाते समय, एक विहित आकृति उत्सर्जित करें।
सबटाइटल टूलकिट परिवर्तित होने पर यही करता है। संकेतों को एक से पुनः क्रमांकित किया जाता है और सन्निहित रखा जाता है, टाइमस्टैम्प को SRT के लिए अल्पविराम और WebVTT के लिए एक पूर्ण विराम के साथ फिर से उत्सर्जित किया जाता है, और जो फ़ाइल वापस आती है वह आकार की खिलाड़ी होती है जिसकी अपेक्षा खिलाड़ी करते हैं, भले ही इनपुट कितना भी अनियमित क्यों न हो। किसी खिलाड़ी द्वारा अस्वीकृत की गई फ़ाइल को कन्वर्टर में चिपकाएँ और पहले रिपोर्ट की गई समस्याओं को पढ़ें; वे संकेत को नाम देते हैं और पंक्ति उद्धृत करते हैं, जो आमतौर पर मूल में दोष ढूंढने के लिए पर्याप्त होता है।