वीडियो और उपशीर्षक · उपशीर्षक टूलकिट
उपशीर्षक में é é क्यों बन जाता है: टेक्स्ट एन्कोडिंग और ब्राउज़र उन्हें कैसे डिकोड करते हैं
· यह काम किस प्रकार करता है
उपशीर्षक चरित्र-एन्कोडिंग ब्राउज़र-प्रसंस्करण
उपशीर्षक में मोजिबेक लगभग हमेशा एक एन्कोडिंग बेमेल है। यह पोस्ट बताती है कि बाइट्स कैसे अक्षर बन जाते हैं, क्यों UTF-8 और लीगेसी विंडोज कोड पेज असहमत हैं और कैसे एक ब्राउज़र-आधारित टूल किसी फ़ाइल को कहीं भी भेजे बिना डीकोड करता है।
लहजे बेकार हैं लेकिन समय एकदम सही है - एन्कोडिंग समस्याएं कैसे स्वयं को प्रस्तुत करती हैं
बताया जा रहा है कि किरदारों को छोड़कर सब कुछ ठीक है। समय सटीक है, क्यू क्रम सही है, फ़ाइल लोड होती है, और केवल उच्चारण वाले अक्षर गलत हैं। यह संयोजन किसी संरचनात्मक दोष से इंकार करता है, क्योंकि एक पार्सर जो फ़ाइल को नहीं पढ़ सका, उसने सही समय का उत्पादन नहीं किया होगा। जो गलत हुआ वह पार्सिंग से पहले हुआ, जब बाइट्स का एक क्रम वर्णों के अनुक्रम में बदल गया।
इससे यह भी पता चलता है कि गलती अक्सर स्रोत के बजाय वर्कफ़्लो के बीच में क्यों दिखाई देती है। जो फ़ाइल एक एडिटर में सही दिख रही थी, वह अगले एडिटर में गलत दिख सकती है, बिना किसी बदलाव के। इसमें कुछ भी संशोधन नहीं किया गया; दूसरे प्रोग्राम ने बाइट्स के अर्थ के बारे में एक अलग धारणा बनाई।
बाइट्स बनाम अक्षर - डिकोडर के आधार पर समान बाइट्स को 'é' या 'é' के रूप में क्यों पढ़ा जा सकता है
डिस्क पर एक फ़ाइल बाइट्स है। वर्ण तभी अस्तित्व में आते हैं जब कोई एन्कोडिंग लागू करता है, जो वर्णों के लिए बाइट अनुक्रमों को मैप करने वाली एक तालिका है। UTF-8 दो बाइट्स के रूप में ई-एक्यूट जैसे एक उच्चारण लैटिन अक्षर का प्रतिनिधित्व करता है। Windows-1252 एक ही अक्षर को एक बाइट के रूप में दर्शाता है, और दो UTF-8 बाइट्स को पूरी तरह से अलग अर्थ देता है: पहला टिल्ड के साथ एक बड़ा A है और दूसरा एक कॉपीराइट चिह्न है।
तो परिचित विकृत जोड़ी भ्रष्टाचार नहीं है. यह गलत तालिका के अंतर्गत सही बाइट्स का एक विश्वसनीय, दोषरहित वाचन है। हर बाइट बच गया; केवल व्याख्या बदल गई। यही कारण है कि क्षति आमतौर पर प्रतिवर्ती होती है, और दृश्यमान पात्रों को हाथ से संपादित करने के बजाय यह पहचानना उचित है कि बेमेल किस दिशा में गया।
UTF-8, Windows-1252 और मित्र - एन्कोडिंग उपशीर्षक फ़ाइलें वास्तव में सामने आती हैं
उपशीर्षक फ़ाइलें कम संख्या में एन्कोडिंग में सामने आती हैं। UTF-8 आधुनिक डिफ़ॉल्ट है और एकमात्र WebVTT परमिट है। Windows-1252 पुराने पश्चिमी यूरोपीय टूलींग द्वारा निर्मित फ़ाइलों में आम है, और इसके करीबी रिश्तेदार ISO-8859-1 समान आधार को कवर करते हैं। मध्य यूरोपीय, सिरिलिक या ग्रीक स्रोतों की फ़ाइलें संबंधित विंडोज़ कोड पेजों में दिखाई देती हैं, और पूर्वी एशियाई सामग्री कई और जोड़ती है।
इनमें से कोई भी एन्कोडिंग फ़ाइल के अंदर अपनी पहचान दर्ज नहीं करता है। SRT फ़ाइल में इसे लिखने के लिए उपयोग की गई एन्कोडिंग की कोई घोषणा नहीं है, जो पूरी समस्या की जड़ है: पाठक को निर्णय लेना है, और पढ़ने के लिए कुछ भी आधिकारिक नहीं है।
बाइट-ऑर्डर चिह्न - कुछ खिलाड़ियों के लिए एक उपयोगी संकेत और दूसरों में एक दृश्य गड़बड़ी
बाइट ऑर्डर चिह्न एक आंशिक अपवाद है। यह फ़ाइल की शुरुआत में एक विशिष्ट वर्ण है, जो मौजूद होने पर एन्कोडिंग का संकेत देता है। यह कुछ खिलाड़ियों की मदद करता है और पहले उपशीर्षक सूचकांक से पहले दूसरों में एक भटके हुए चरित्र के रूप में दिखाई देता है, यही कारण है कि एक को ले जाने वाली फ़ाइलें बिल्कुल एक प्रोग्राम में विफल हो सकती हैं और हर जगह काम कर सकती हैं।
पार्सर कुछ और करने से पहले इसे हटा देता है, क्योंकि जगह पर छोड़ा गया निशान पहले इंडेक्स नंबर से जुड़ जाता है और पहले क्यू की लागत आती है। प्रारूप का पता लगाना भी इसे सहन करने के लिए लिखा गया है, इसलिए एक WebVTT फ़ाइल जो अपने हेडर से पहले एक निशान से शुरू होती है, उसे अभी भी SRT के रूप में माने जाने के बजाय WebVTT के रूप में पहचाना जाता है।
ब्राउज़र किसी फ़ाइल को स्थानीय रूप से कैसे डिकोड करता है - टेक्स्टडिकोडर API, और जब कोई एन्कोडिंग घोषित नहीं की जाती है तो पता लगाना एक अनुमान क्यों है
जब टूल किसी फ़ाइल को लोड करता है तो यह फ़ाइल API टेक्स्ट विधि को कॉल करता है, और उस विधि को UTF-8 के रूप में डिकोड करने के लिए निर्दिष्ट किया जाता है। कोई एन्कोडिंग पैरामीटर नहीं है और कोई बातचीत नहीं है। एक फ़ाइल जो वास्तव में UTF-8 है, सही ढंग से पढ़ी जाती है; एकल-बाइट उच्चारण अक्षर वाली Windows-1252 फ़ाइल एक बाइट प्रस्तुत करती है जो वैध UTF-8 अनुक्रम शुरू नहीं कर सकती है, और डिकोडर अनुमान लगाने के बजाय एक प्रतिस्थापन वर्ण को प्रतिस्थापित करता है।
यह जानने लायक है क्योंकि इससे लक्षण बदल जाता है। एक विरासत तालिका के साथ UTF-8 फ़ाइल को पढ़ने से परिचित दो-अक्षर वाला गार्बल उत्पन्न होता है। किसी लीगेसी फ़ाइल को UTF-8 के रूप में पढ़ने से उसके स्थान पर प्रतिस्थापन वर्ण, काले हीरे या खाली बक्से उत्पन्न होते हैं। UTF-8 के अलावा किसी अन्य चीज़ के रूप में डिकोड करने के लिए ब्राउज़र डिकोडर API के माध्यम से एन्कोडिंग को स्पष्ट रूप से नामित करने की आवश्यकता होती है, और इसे नाम देना कठिन हिस्सा है: फ़ाइल में कोई घोषणा नहीं होने से, कोई भी स्वचालित विकल्प बाइट पैटर्न से अनुमान लगाया जाता है, जो एक अनुमान है जो आमतौर पर सही होता है और कभी-कभी आत्मविश्वास से गलत होता है।
कारगर उदाहरण: Windows-1252 फ़ाइल को बचाना - स्रोत एन्कोडिंग की पहचान करना और रूपांतरण से पहले इसे UTF-8 के रूप में पुनः सहेजना
किसी लीगेसी फ़ाइल को बचाने के लिए, रूपांतरण बाद में करने के बजाय उपशीर्षक कार्य से पहले करें। इसे एक एडिटर में खोलें जो आपको दोनों तरफ एन्कोडिंग बताने देता है, इसे फ़ाइल को Windows-1252 के रूप में फिर से खोलने के लिए कहता है, और पुष्टि करता है कि उच्चारण वर्ण सही ढंग से दिखाई देते हैं। यदि वे ऐसा करते हैं, तो अनुमान सही था। फिर फ़ाइल को स्पष्ट रूप से UTF-8 के रूप में सहेजें।
संपूर्ण फ़ाइल के बजाय उस पंक्ति पर सत्यापित करें जिसका आप अनुमान लगा सकते हैं। एक ऐसा संकेत चुनें जिसमें एक उच्चारण हो जिसे आप जानते हों कि वहां होना चाहिए और परिवर्तित आउटपुट में इसकी जांच करें। पहले ऐसा करने का मतलब है कि उपशीर्षक टूल को एक फ़ाइल प्राप्त होती है जिसके बाइट्स पहले से ही उस एन्कोडिंग से मेल खाते हैं जो वह मानने जा रहा है, और रूपांतरण चरण में गलत होने के लिए कुछ भी नहीं बचा है।
इसमें क्या शामिल नहीं है - गलत रूपांतरण के दो दौरों से क्षतिग्रस्त फ़ाइलें, जहां मूल बाइट्स पहले ही खो चुके हैं
एक फ़ाइल जो दो गलत रूपांतरणों से गुज़री है वह एक अलग समस्या है। यदि किसी फ़ाइल को गलत पढ़ा गया था और फिर उस गलत पढ़ी गई स्थिति में सहेजा गया था, तो गलत वर्ण वास्तविक वर्ण के रूप में लिखे गए थे, और मूल बाइट्स अब इसमें कहीं भी मौजूद नहीं हैं। उस समय पुनर्व्याख्या करने के लिए कुछ भी नहीं है, क्योंकि फ़ाइल में अब वास्तव में विकृत पाठ शामिल है।
उन मामलों को कभी-कभी गलत एन्कोडिंग के सटीक अनुक्रम को उलट कर पुनर्प्राप्त किया जा सकता है, लेकिन केवल तब जब हर चरण ज्ञात हो और कोई भी चरण जानकारी खो न जाए। एक बाइट जो एक प्रतिस्थापन चरित्र बन गया है वह स्थायी रूप से चला गया है: प्रतिस्थापन एक एकल चरित्र है जो एक बाइट के लिए खड़ा है जिसे डिकोडर उपयोग नहीं कर सकता है, और यह रिकॉर्ड नहीं करता है कि बाइट क्या था। विश्वसनीय समाधान मूल फ़ाइल पर वापस लौटना है।
टेकवे: कन्वर्ट करने से पहले UTF-8 पर मानकीकरण करें - उपशीर्षक टूलकिट ब्राउज़र में आपकी फ़ाइल पर कैसे काम करता है और परिभाषा के अनुसार WebVTT आउटपुट UTF-8 क्यों है
कुछ भी परिवर्तित करने से पहले UTF-8 पर मानकीकरण करें। फ़ाइल में एन्कोडिंग का कोई विवरण नहीं है, इसलिए इसे खोलने वाला प्रत्येक प्रोग्राम एक धारणा बना रहा है, और असहमत धारणाओं को रोकने का तरीका उन सभी को सही बनाना है। WebVTT परिभाषा के अनुसार अस्पष्टता को दूर करता है, क्योंकि प्रारूप के लिए UTF-8 की आवश्यकता होती है, जो वेब डिलीवरी के लिए SRT को WebVTT में परिवर्तित करने का एक व्यावहारिक कारण है।
रूपांतरण ब्राउज़र टैब में फ़ाइल पर चलता है। किसी भी गलत दिखने वाली चीज़ को स्कैन करने के बजाय उस लाइन पर परिणाम की जांच करें जिसके उच्चारण का आप अनुमान लगा सकते हैं, क्योंकि नौ सौ संकेतों में मुट्ठी भर उच्चारण शब्दों वाली फ़ाइल पर उस भाग की जांच किए बिना हस्ताक्षर करना आसान है जो विफल हो जाएगा।