डेटा और स्प्रेडशीट · CSV क्लीनर
UTF-8 और Windows-1252 कैसे भ्रमित हो जाते हैं: मोजिबेक की मरम्मत CSV निर्यात
· यह काम किस प्रकार करता है
CAसवी एन्कोडिंग डेटा-सफाई
जब 'जोस' 'जोस' बन जाता है, तो बाइट्स ठीक हैं और व्याख्या गलत है। यह पोस्ट बताती है कि दो सबसे आम एनकोडिंग कैसे टकराती हैं, लक्षणों को कैसे पहचानें और कैसे री-डिकोडिंग उन्हें ठीक करती है।
उच्चारित नाम और घुंघराले उद्धरण प्रतीक सूप में बदल गए - UTF-8 फ़ाइल के बताए गए पैटर्न को Windows-1252 के रूप में पढ़ा जाता है, और इसका उल्टा
एक ग्राहक का नाम जो लोड करने के बाद रिप्लेसमेंट डायमंड बन जाता है, यह इस बात का सबूत नहीं है कि CSV क्लीनर ने गलत लीगेसी कोड पेज का पता लगाया है। कॉन्फ़िगरेशन इसके विपरीत कहता है: केवल UTF-8 को समझा जाता है, और Windows-1252 या Shift-JIS फ़ाइल को UTF-8 के रूप में पढ़ा जाता है। इसलिए अमान्य बाइट अनुक्रमों को CSV पार्सर द्वारा वर्ण देखने से पहले ही बदला जा सकता है।
रूपरेखा जोस जैसे परिचित मोजिबेक पर केंद्रित है, लेकिन ब्राउज़र रीड पथ `File.text()` का उपयोग करता है और कोई एन्कोडिंग चयनकर्ता प्रदान नहीं करता है। यह लेख उस वादे को सही करता है। इस टूल के अंदर कार्रवाई योग्य लक्षण प्रतिस्थापन वर्ण या अन्यथा क्षतिग्रस्त पाठ है, मूल फ़ाइल बाइट्स को अन्यत्र पुनर्प्राप्ति के लिए संरक्षित किया गया है।
एक गैर-UTF-8 फ़ाइल प्रतिस्थापन वर्णों के रूप में इस टूल तक पहुँचती है, सत्यापित मोजिबेक पैटर्न के रूप में नहीं
एक सीमांकित फ़ाइल डिस्क पर बाइट्स होती है, जबकि पार्सर JavaScript स्ट्रिंग पर काम करता है। एक एन्कोडिंग उन परतों के बीच मैपिंग को परिभाषित करती है। CSV वाक्यविन्यास में अल्पविराम, उद्धरण और रिकॉर्ड सीमाएँ होती हैं, लेकिन कोई विश्वसनीय ऑन-डिस्क घोषणा नहीं होती है जो `File.text()` को बताती है कि कौन सी विरासत मैपिंग ने प्रत्येक गैर-ASCII बाइट बनाई है।
एक बार डिकोडिंग से U+FFFD प्रतिस्थापन वर्ण उत्पन्न हो जाते हैं, बाद में CSV ऑपरेशन उन प्लेसहोल्डर्स को सामान्य पाठ के रूप में प्राप्त करते हैं। ट्रिमिंग या निर्यात से यह अनुमान नहीं लगाया जा सकता कि कौन सा मूल बाइट अनुक्रम या चरित्र वहां था। यही कारण है कि अछूता स्रोत क्षतिग्रस्त डिस्प्ले से इकट्ठी की गई खोज-और-प्रतिस्थापन सूची से अधिक मायने रखता है।
दो सामान्य संदिग्ध - UTF-8 के मल्टी-बाइट अनुक्रम और Windows-1252 के एकल बाइट्स, और वे अदला-बदली करने पर अनुमानित कचरा क्यों उत्पन्न करते हैं
UTF-8 मल्टीबाइट अनुक्रमों के साथ गैर-ASCII वर्णों का प्रतिनिधित्व करता है। Windows-1252 व्यक्तिगत बाइट मानों के लिए कई पश्चिमी वर्ण निर्दिष्ट करता है। एक कन्वेंशन को दूसरे के तहत पढ़ना विफल हो सकता है या भ्रामक पाठ बना सकता है, लेकिन यह मार्ग वैकल्पिक डिकोडर्स का परीक्षण नहीं करता है, प्रशंसनीय भाषा का स्कोर नहीं करता है या Windows-1252 चयन की पेशकश नहीं करता है।
एकमात्र एन्कोडिंग-विशिष्ट पार्सर व्यवहार टेक्स्ट डिकोडिंग के बाद अग्रणी U+FEFF UTF-8 बाइट-ऑर्डर मार्क को हटाना है। यह मार्कर को पहले हेडर में शामिल होने से रोकता है। यह सामान्य एन्कोडिंग पहचान नहीं है और कार्यान्वयन में कहीं भी उल्लिखित Shift-JIS, UTF-16 या क्षेत्रीय कोड पेजों के लिए कोई समर्थन प्रदान नहीं करता है।
ToolAcre UTF-8 टेक्स्ट को स्वीकार करता है और Windows-1252 उम्मीदवारों की तुलना नहीं करता है
प्रतिस्थापन वर्ण इंगित करते हैं कि टेक्स्ट डिकोडर अपनी चुनी हुई व्याख्या के तहत कुछ इनपुट बाइट्स को मैप नहीं कर सका। हो सकता है कि पहले किसी हानिपूर्ण निर्यात के कारण प्रश्नचिह्न लगाए गए हों, ऐसी स्थिति में मूल चरित्र पहले से ही अनुपलब्ध हो सकता है। एक पहचानने योग्य Ã अनुक्रम अन्य वर्कफ़्लोज़ में उत्पन्न हो सकता है, लेकिन यह पेज इसके इतिहास का निदान नहीं करता है।
केवल एक उपनाम से स्रोत एन्कोडिंग का निर्णय न लें। निर्यात करने वाले एप्लिकेशन की सेटिंग, फ़ाइल उद्गम और एक बाइट-जागरूक इंस्पेक्टर की जांच करें जो स्रोत को अछूता छोड़ देता है। क्लीनर की पंक्ति चेतावनियाँ उद्धरण बंद होने और कॉलम की चौड़ाई से संबंधित हैं; वे इस बात का प्रमाण नहीं हैं कि वर्ण एन्कोडिंग सही है।
पुन: डिकोडिंग, ढूँढना-और-प्रतिस्थापित करना नहीं - वर्णों को एक-एक करके पैच करने के बजाय सही एन्कोडिंग के साथ बाइट्स को पढ़ना और UTF-8 लिखना क्यों ठीक है
विश्वसनीय मरम्मत मूल बाइट्स पर वापस लौटना और दस्तावेज़ीकृत स्रोत एन्कोडिंग के साथ उन्हें एक बार डीकोड करना है, फिर UTF-8 लिखें। वह कार्रवाई केवल UTF-8-पाठ पथ के माध्यम से खुलने से पहले होनी चाहिए। डिकोडिंग के बाद दृश्यमान कचरा टुकड़ों को बदलने से वैध घटनाएँ दूषित हो सकती हैं और कई मूल वर्णों को अलग नहीं किया जा सकता है जो एक प्लेसहोल्डर पर सिमट गए हैं।
CSV क्लीनर के पास कोई बाइट-स्तरीय री-डिकोडिंग नियंत्रण नहीं है, इसलिए यह रूपरेखा का वादा किया गया रूपांतरण नहीं कर सकता है। एक विश्वसनीय स्रोत-जागरूक रूपांतरण विधि का उपयोग करें, स्रोत प्रणाली के साथ प्रतिनिधि नामों की तुलना करें, और फिर सीमांकक, उद्धरण, व्हाइटस्पेस और डुप्लिकेट कार्य के लिए UTF-8 परिणाम यहां लाएं।
इस टूल के बाहर मूल बाइट्स से पुनर्प्राप्त करें; यहां चरित्र प्रतिस्थापन उन्हें पुनर्स्थापित नहीं कर सकता
एक सुरक्षित प्रदर्शन के लिए, एक छोटी विरासत-एन्कोडेड फ़ाइल बनाएं जिसमें एक उच्चारण नाम हो और एक हेक्साडेसिमल प्रतिलिपि बनाए रखें। इसे टूल में लोड करें और देखें कि प्रतिस्थापन वर्ण दिखाई देते हैं या नहीं। वह अवलोकन UTF-8 सीमा स्थापित करता है; यह मूल कोड पेज केवल इसलिए स्थापित नहीं करता क्योंकि अपेक्षित नाम ज्ञात है।
इसके बाद अछूते बाइट्स को ToolAcre के बाहर एक स्पष्ट रूप से चयनित डिकोडर के साथ परिवर्तित करें, UTF-8 को सहेजें, और उस परिणाम को लोड करें। नाम अब बरकरार रहना चाहिए जबकि CSV पार्सर विभाजकों को सामान्य रूप से संभालता है। इन दोनों रास्तों की तुलना करने से यह दावा किए बिना सही सबक मिलता है कि क्लीनर ने ही रिकवरी की है।
व्यावहारिक उदाहरण: असमर्थित मरम्मत का दावा किए बिना UTF-8 सीमा प्रदर्शित करें
एक डबल-एन्कोडेड फ़ाइल को पहले के परिवर्तन के पुनर्निर्माण की आवश्यकता हो सकती है, और पहले से ही शाब्दिक प्रश्न चिह्नों के साथ सहेजा गया डेटा किसी अन्य स्रोत के बिना अपरिवर्तनीय हो सकता है। यह आलेख एक सार्वभौमिक उत्क्रमण निर्धारित नहीं करता है क्योंकि कार्यान्वयन में कोई एन्कोडिंग इतिहास या बाइट-संरक्षण पुनर्प्राप्ति फ़ंक्शन शामिल नहीं है।
यह UTF-16, पूर्वी एशियाई एनकोडिंग या सामान्यीकरण फॉर्म के लिए समर्थन का दावा करने से भी बचता है। यदि वे मायने रखते हैं, तो एक ऐसा कन्वर्टर चुनें जो उन्हें नाम दे और उनका परीक्षण करे। एक सफल CSV पार्स केवल सीमांकक स्थिति मशीन द्वारा पाई गई पंक्तियों को साबित करता है; यह इस बारे में कुछ नहीं कहता कि उस चरण से पहले चरित्र डिकोडिंग विश्वसनीय थी या नहीं।
व्याख्या को एक बार ठीक करें - कैसे ToolAcre CSV क्लीनर की एन्कोडिंग मरम्मत आपके डिवाइस पर निर्यात को फिर से डिकोड और फिर से एनकोड करती है
ToolAcre अग्रणी UTF-8 BOM को हटा सकता है और परिणामी स्ट्रिंग को ब्राउज़र के डाउनलोड पथ के माध्यम से UTF-8 CSV के रूप में क्रमबद्ध कर सकता है। यह मनमाने लीगेसी बाइट्स को सही यूनिकोड में नहीं बदल सकता क्योंकि वे बाइट्स पहले ही उपयोगकर्ता द्वारा चयनित डिकोडर के बिना ब्राउज़र की निश्चित टेक्स्ट-रीडिंग सीमा को पार कर चुके हैं।
प्रतिस्थापन चिह्नों को स्टॉप सिग्नल के रूप में मानें। स्रोत को सुरक्षित रखें, निर्माता से इसकी एन्कोडिंग की पहचान करें, उचित बाइट-अवेयर टूल के साथ एक बार कन्वर्ट करें, और महत्वपूर्ण नामों को सत्यापित करें। इसके बाद ही संरचनात्मक कार्यों के लिए CSV क्लीनर का उपयोग करें, जिसका कॉन्फ़िगरेशन वास्तव में इसका वादा करता है।