मूल टेक्स्ट खोए बिना SRT सबटाइटल एन्कोडिंग ठीक करें

यदि आपके SRT सबटाइटल café के स्थान पर caféदिखाते हैं, तो फ़ाइल को तुरंत UTF-8 के रूप में सहेजने की भूल न करें। सबसे पहले इसके बाइट्स की एक अछूती कॉपी सुरक्षित रखें, ऐसी डिकोडिंग की पहचान करें जिससे सही शब्द प्राप्त हों, और फिर सत्यापित टेक्स्ट को एक अलग फ़ाइल में लिखें। गलत अक्षरों को नई एन्कोडिंग में सहेजने से वे गलत अक्षर ही स्थायी रूप से सुरक्षित रह जाते हैं।

यहाँ सबसे महत्वपूर्ण अंतर वैध एन्कोडिंग बनाम सही टेक्स्टका है। नीचे दिए गए मूल दो-क्यू (cue) प्रयोग में, एक खराब फ़ाइल सख्त UTF-8 जांच पास कर लेती है और उसमें कोई रिप्लेसमेंट वर्ण नहीं है। फिर भी उसका फ्रेंच टेक्स्ट गलत है। दूसरी फ़ाइल छह मूल वर्णों को �.

यह गाइड एक लोकल Python जांच और रूपांतरण टूल, डाउनलोड करने योग्य स्रोत फ़ाइलें और एक पुनः प्रस्तुत करने योग्य परीक्षण प्रदान करती है। यह फ़ाइल-स्तरीय निदान और स्पष्ट रूपांतरण संभालती है—न कि स्वचालित एन्कोडिंग पहचान, वीडियो सिंक्रोनाइज़ेशन, या खोए हुए अक्षरों को पुनः प्राप्त करने का कोई वादा।

सबसे पहले पहचानें कि वास्तव में क्या खराब है

एक .srt एक्सटेंशन सबटाइटल प्रारूप की पहचान करता है, किसी निश्चित एन्कोडिंग की गारंटी नहीं देता। SRT में क्यू नंबर, टाइमस्टैम्प, टेक्स्ट और विभाजक होते हैं; लाइब्रेरी ऑफ़ कांग्रेस का SRT प्रारूप रिकॉर्ड इसे किसी एक वर्ण-एन्कोडिंग मानक के बिना केवल सादे टेक्स्ट के रूप में वर्णित करता है।

दिखने वाले लक्षण को जांच का कारण मानें, अपने आप में पूरा निदान नहीं:

वर्ण और उनकी प्रदर्शित आकृतियाँ अलग-अलग चीजें हैं। Python का Unicode स्पष्टीकरण कोड बिंदुओं को फ़ॉन्ट-रेंडर किए गए ग्लिफ़ से अलग करता है। किसी संपादक में सही टेक्स्ट होना प्लेयर की ओर से समस्या होने की संभावना को पुख्ता करता है; यह यह साबित नहीं करता कि कोई विशेष फ़ॉन्ट इंस्टॉल करने से यह ठीक हो जाएगा। इस लेख के लिए किसी भी फ़ॉन्ट या प्लेयर का परीक्षण नहीं किया गया था।

बाइट्स का बैकअप लें, फिर डीकोडिंग का निरीक्षण करें

डाउनलोड करें subtitle_encoding.py और इसे उस SRT के साथ रखें जिसकी आप जाँच करना चाहते हैं। इन कमांड्स के लिए पहले से मौजूद Python 3 इंस्टॉलेशन की आवश्यकता होती है और किसी अतिरिक्त पैकेज की नहीं। यहाँ स्थानीय जाँचों में macOS पर Python 3.14.3 का उपयोग किया गया। यदि आपका Windows इंस्टॉलेशन Python लॉन्चर का उपयोग करता है, तो py -3 के स्थान पर python3का उपयोग करें; उस परिवेश का यहाँ परीक्षण नहीं किया गया था।

उस फ़ोल्डर में टर्मिनल खोलें। इन उदाहरणों में, input.srt को अपने वास्तविक फ़ाइल नाम से बदलें। रिक्त स्थान वाले पथों के चारों ओर कोटेशन चिह्न बनाए रखें।

एक अछूती प्रतिलिपि बनाएँ

python3 subtitle_encoding.py backup "input.srt" "original-bytes.srt"

गंतव्य फ़ाइल पहले से मौजूद नहीं होनी चाहिए। यह टूल बाइट्स को डीकोड किए बिना कॉपी करता है, कॉपी को वापस पढ़ता है, और इसके SHA-256 हैश की रिपोर्ट करता है। यह गंतव्य के रूप में स्रोत पथ को भी अस्वीकार कर देता है। उपयोग योग्य सबटाइटल बनाने के बाद भी इस बैकअप को रखें।

बिना कुछ सहेजे UTF-8 की जाँच करें

python3 subtitle_encoding.py inspect "original-bytes.srt"

रिपोर्ट में strict_utf8, utf8_bom, चयनित डीकोडिंग, और—यदि वह डीकोडिंग सफल होती है—तो एक टेक्स्ट पूर्वावलोकन और replacement_characters गिनती। इसका डिफ़ॉल्ट टेक्स्ट व्यू utf-8-sigका उपयोग करता है, जो शुरुआती UTF-8 सिग्नेचर को संभालता है।

• strict_utf8: false का अर्थ है कि बाइट्स UTF-8 जाँच में विफल हो गए हैं। यह नहीं बताता कि कौन सी अन्य एन्कोडिंग सही है।
• strict_utf8: true का अर्थ है कि उन्हें UTF-8 के रूप में डिकोड किया जा सकता है। इसका मतलब यह नहीं है कि शब्द सही हैं।
• शून्य से अधिक रिप्लेसमेंट काउंट का अर्थ है कि चुनी गई डिकोडिंग ने U+FFFD वर्ण उत्पन्न किए हैं। नई फ़ाइल बनाने से पहले उनकी जाँच करें।

निरीक्षण ASCII-सुरक्षित JSON प्रिंट करता है ताकि टर्मिनल फ़ॉन्ट वर्ण की पहचान को छिपा न सके: \u00e9 का अर्थ है é, और \ufffd का अर्थ है प्रतिस्थापन वर्ण। किसी संदिग्ध पंक्ति की विस्तार से जाँच करने के लिए, उसकी फ़िज़िकल पंक्ति संख्या का अनुरोध करें—उसके क्यू नंबर का नहीं:

python3 subtitle_encoding.py inspect "original-bytes.srt" --encoding cp1252 --line 3

यह Windows-1252, Python के cp1252 कोडेक का केवल-पढ़ने के लिए परीक्षण है। इसका उपयोग तब करें जब निर्यात सेटिंग्स या स्रोत इतिहास उस विकल्प का समर्थन करते हों, केवल इसलिए नहीं कि इस उदाहरण में फ़्रेंच का उपयोग हुआ था। लाइन रिपोर्ट प्रत्येक वर्ण का नाम बताती है और उसका कोड बिंदु दिखाती है; U+20AC यूरो का चिह्न है।

सबूतों के आधार पर एन्कोडिंग चुनें, न कि पहले सफल प्रीव्यू के आधार पर

फ़ाइल के निर्माता से वास्तविक निर्यात एन्कोडिंग के बारे में पूछें, निर्यात करने वाले एप्लिकेशन की सेटिंग्स जाँचें, या किसी विश्वसनीय मूल ट्रांसक्रिप्ट से तुलना करें। पूरी फ़ाइल में एक्सेंटेड नाम, विराम चिह्न, मुद्रा चिह्न और प्रतिनिधि पंक्तियों की समीक्षा करें। यदि आप वह भाषा नहीं पढ़ सकते हैं, तो एक सफल डिकोडर आपके लिए वह समीक्षा नहीं कर सकता है।

स्रोत कोडेक का चयन करने के लिए "ANSI" पर्याप्त सटीक नहीं है। न ही Windows-1252 और Latin-1 एक दूसरे के स्थान पर उपयोग किए जा सकते हैं। दिए गए प्रयोग में, एकल बाइट 80 को € के अंतर्गत cp1252में डिकोड किया जाता है, लेकिन नियंत्रण वर्ण U+0080 के तहत latin-1। दोनों प्रक्रियाएं सफल हो जाती हैं। केवल ज्ञात स्रोत ही हमें बताता है कि वास्तव में क्या अभिप्रेत है।

अन्य भाषाएं विभिन्न पुरानी एन्कोडिंग का उपयोग कर सकती हैं, लेकिन केवल भाषा का नाम ही इसे निर्धारित नहीं करता है। यदि स्रोत का इतिहास अज्ञात है और संभावित विकल्प आपस में मेल नहीं खाते हैं, तो रूपांतरण से पहले रुकें और बेहतर स्रोत साक्ष्य प्राप्त करें।

स्रोत टेक्स्ट के पठनीय होने के बाद ही कनवर्ट करें

Windows-1252 के रूप में पुष्ट किए गए स्रोत के लिए, एक अलग UTF-8 फ़ाइल बनाएं:

python3 subtitle_encoding.py convert "original-bytes.srt" "repaired-utf8.srt" --from-encoding cp1252
python3 subtitle_encoding.py inspect "repaired-utf8.srt"

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

यह जानबूझकर निम्नलिखित से इनकार करता है:

• मौजूदा गंतव्य को अधिलेखित (ओवरराइट) करना;
• सख्त डिकोडिंग त्रुटि होने पर आगे बढ़ना; या
• U+FFFD युक्त टेक्स्ट लिखना, भले ही वह वर्ण जानबूझकर जोड़ा गया हो।

अंतिम प्रतिबंध सतर्कता बरतने के लिए है: यह टूल यह तय नहीं कर सकता कि प्रतिस्थापन वर्ण का क्या अर्थ था। कमांड को सफल बनाने के लिए इसे हटाना साक्ष्य को मिटा देगा, टेक्स्ट को पुनर्स्थापित नहीं करेगा। पायथन का त्रुटि-हैंडलर दस्तावेज़ बताता है कि क्यों replace और ignore सख्त डिकोडिंग से भिन्न हैं: वे समस्याग्रस्त डेटा को बदल देते हैं या छोड़ देते हैं। इनमें से कोई भी इस रूपांतरण चरण के लिए उपयुक्त नहीं है।

यदि कोई I/O त्रुटि होती है, तो असफल आउटपुट का उपयोग न करें। एक अधूरी नई फ़ाइल रह सकती है; मूल फ़ाइल को सुरक्षित रखें और बाद के प्रयास के लिए एक नए गंतव्य नाम का उपयोग करें। टूल का पूरा व्यवहार और उपयोग डाउनलोड करने योग्य README.

BOM वाले UTF-8 के बारे में क्या?

UTF-8 BOM शुरुआती बाइट अनुक्रम EF BB BFहै। पायथन का utf-8-sig कोडेक डिकोड करते समय उस सिग्नेचर का उपभोग करता है और एन्कोड करते समय इसे जोड़ता है।

BOM वाले किसी पुष्ट UTF-8 स्रोत के लिए, --from-encoding utf-8-sigका उपयोग करें। यह टूल आम तौर पर बिना BOM के UTF-8 लिखता है; --with-bom केवल तभी जोड़ें जब प्राप्त करने वाले एप्लिकेशन की आवश्यकताएं इसकी मांग करें। BOM बदलने से café , caféमें नहीं बदल सकता। यह प्रयोग किसी विशेष प्लेयर, एडिटर या अपलोड प्लेटफॉर्म के साथ अनुकूलता स्थापित नहीं करता है।

पांच छोटी फाइलें दिखाती हैं कि UTF-8 की वैधता ही पर्याप्त क्यों नहीं है

यह प्रयोग पूरी तरह से स्वयं लिखे गए दो फ्रेंच सबटाइटल संकेतों का उपयोग करता है। इन्हें किसी फिल्म, ग्राहक या अनुवाद उत्पाद से नहीं लिया गया है:

1
00:00:01,000 --> 00:00:04,000
Émile dit : « Le prix est de 12,50 €. »

2
00:00:05,000 --> 00:00:08,000
Le café est fermé.

13 सितंबर, 2026 को, Python 3.14.3 स्टैंडर्ड-लाइब्रेरी स्क्रिप्ट ने पांच बाइट निरूपण (representations) तैयार किए और उस ज्ञात स्रोत के साथ प्रत्येक की तुलना की। ये नियतात्मक (deterministic) बाइट और स्ट्रिंग जांच हैं, अनुवाद-गुणवत्ता का बेंचमार्क नहीं। लिंक की गई फाइलों को उनके ब्राउज़र पूर्वावलोकन से कॉपी करने के बजाय डिस्क पर सहेजें: अलग-अलग बाइट ही इस प्रयोग का मुख्य उद्देश्य हैं।

प्रत्येक प्रतिलिपि में वही दो टाइमस्टैम्प स्ट्रिंग्स बरकरार रहती हैं। सही ढंग से रूपांतरित फ़ाइल मूल UTF-8 के बाइट-दर-बाइट समान है। दो क्षतिग्रस्त UTF-8 फ़ाइलें एक सीमित लेकिन उपयोगी बात साबित करती हैं: न तो वैध एन्कोडिंग और न ही अपरिवर्तित टाइमस्टैम्प यह सिद्ध करते हैं कि सबटाइटल टेक्स्ट सही है। टाइमस्टैम्प का मेल खाना यह भी नहीं बताता कि यह कल्पित ट्रैक किसी वास्तविक वीडियो के अनुकूल है या नहीं।

पाँचों फ़ाइलों को स्वयं पुनः उत्पन्न करने के लिए, reproduce.py डाउनलोड करें और इसे ऐसे डायरेक्टरी नाम के साथ चलाएँ जो मौजूद न हो:

python3 reproduce.py encoding-experiment

स्क्रिप्ट फ़िक्स्चर और एक results.json लिखती है जिसमें पूरा टेक्स्ट, रूपांतरण, हैश, रनटाइम संस्करण और असर्शन शामिल होते हैं। इसकी तुलना रिकॉर्ड किए गए प्रयोग परिणामोंसे करें; निर्माण का टाइमस्टैम्प अलग होगा। स्क्रिप्ट और मूल शिक्षण फ़ाइलों में MIT लाइसेंस.

शामिल है। स्थानीय कनवर्टर जाँचों ने मौजूदा-आउटपुट अस्वीकृति, स्रोत-पाथ अस्वीकृति, गलत-कोडेक विफलता, U+FFFD अस्वीकृति, CRLF संरक्षण और स्पष्ट BOM आउटपुट का भी परीक्षण किया। वे जाँचें इस टूल के फ़ाइल व्यवहार को सत्यापित करती हैं। वे प्लेयर रेंडरिंग, वास्तविक-मीडिया टाइमिंग या BookTranslator अनुवाद का परीक्षण नहीं करती हैं।

यदि बिगड़े हुए वर्ण पहले ही सहेजे जा चुके हों

सहेजा गया मोजिबेक: सटीक इतिहास की जाँच करें

हमारी मोजिबेक प्रतिलिपि एक ज्ञात शृंखला के तहत बनी थी: मूल UTF-8 बाइट्स को Windows-1252 के रूप में डिकोड किया गया था, फिर उन गलत वर्णों को UTF-8 के रूप में सहेजा गया था। इसके परिणामस्वरूप café और बिगड़ा हुआ यूरो अनुक्रम €.

शामिल हो जाता है। क्योंकि इस विशिष्ट रूपांतरण में कोई बाइट नष्ट नहीं हुई थी, इसलिए पुनरुत्पादन स्क्रिप्ट इसे उलट सकती है: गलत टेक्स्ट को फिर से cp1252के माध्यम से एन्कोड करें, फिर प्राप्त बाइट्स को UTF-8 के रूप में डिकोड करें। यह पुनर्प्राप्त टेक्स्ट को मूल टेक्स्ट के विरुद्ध सत्यापित करता है।

यह इस ज्ञात शृंखलाका प्रमाण है, न कि प्रत्येक SRT पर एक व्यापक "मोजिबेक ठीक करें" प्रक्रिया लागू करने का निर्देश। किसी फ़ाइल में वैध वर्ण, मिश्रित इतिहास, या पिछली मरम्मत द्वारा पहले से बदला गया टेक्स्ट हो सकता है। अछूते स्रोत और सामान्य रूपांतरण मार्ग को प्राथमिकता दें। यदि केवल सहेजा गया मोजिबेक ही बचता है, तो उसे सुरक्षित रखें और किसी अन्य प्रतिलिपि पर विपरीत रूपांतरण का प्रयास करने से पहले यह पता लगाएँ कि वह कैसे उत्पन्न हुआ था।

सेव किए गए रिप्लेसमेंट कैरेक्टर: छूटा हुआ अक्षर वहाँ एनकोड नहीं है

डेटा लॉस का उदाहरण Windows-1252 बाइट्स को रिप्लेसमेंट सक्षम करके UTF-8 के रूप में डिकोड करने, और फिर परिणाम को सेव करने से बना था। अलग-अलग मूल कैरेक्टर एक ही � मार्कर बन गए। सेव किया गया मार्कर यह पहचानने के लिए पर्याप्त जानकारी नहीं रखता कि उस स्थान पर कौन सा मूल कैरेक्टर मौजूद था।

इसे किसी ऐप में केवल दिखने � के साथ भ्रमित न करें। यदि मूल बाइट्स में कोई बदलाव नहीं हुआ है, तो सही डिकोडिंग से टेक्स्ट अभी भी रिकवर हो सकता है—जैसा कि हमारे Windows-1252 स्रोत के लिए होता है। डेटा हानि घोषित करने से पहले उस स्रोत की जाँच करें।

यदि एकमात्र बची हुई कॉपी में छूटे हुए टेक्स्ट की जगह वास्तव में U+FFFD या प्रश्नवाचक चिह्न आ गए हैं, तो एक साफ स्रोत को दोबारा एक्सपोर्ट या प्राप्त करें, या विश्वसनीय सामग्री के साथ मैन्युअल ट्रांसक्रिप्शन का मिलान करें। एक साधारण प्रश्नवाचक चिह्न वैध विराम चिह्न भी हो सकता है; केवल इसकी उपस्थिति कुछ साबित नहीं करती। किसी मॉडल का संभावित रिप्लेसमेंट एक अनुमान होता है, रिकवर किया गया फ़ाइल डेटा नहीं।

केवल एक सफल कमांड पर नहीं—एक पठनीय स्रोत पर काम पूरा करें

सुधारी गई फ़ाइल को स्वीकार करने से पहले, प्रतिनिधि शब्दों और प्रतीकों की तुलना विश्वसनीय स्रोत से करें, पुष्टि करें कि क्यू और टाइमस्टैम्प लाइनें नहीं बदली हैं, और उस एप्लिकेशन में नई फ़ाइल खोलें जो इसका उपयोग करेगा। यह स्क्रिप्ट डिकोड किए गए टेक्स्ट को सुरक्षित रखती है; यह कोई SRT सिंटैक्स वैलिडेटर या प्लेबैक स्वीकृति परीक्षण नहीं है।

यदि अब आप सबटाइटल पढ़ सकते हैं और किसी अन्य भाषा की आवश्यकता नहीं है, तो काम पूरा हो गया है। यदि आपको वीडियो की सीधी समीक्षा या आगे संपादन की आवश्यकता है, तो सबटाइटल सॉफ़्टवेयर तुलना विभिन्न टूल्स की भूमिकाओं को समझाती है।

केवल तभी जब स्रोत टेक्स्ट विश्वसनीय हो जाए—और आपको वास्तव में किसी अन्य भाषा की आवश्यकता हो— BookTranslator के Subtitle Translator और AI सबटाइटल अनुवाद वर्कफ़्लोकी ओर बढ़ें। एन्कोडिंग सुधार, अनुवाद और अंतिम ट्रैक देखने को अलग-अलग कार्यों के रूप में मानें। इनमें से कोई भी इस बात का प्रमाण नहीं है कि अन्य कार्य भी सफल रहे हैं।