मैं एडवर्ड की तरह एक ही समस्या का अनुभव किया है। मैं डस्टिन से सहमत हूं, आमतौर पर टेक्स्टफाइल में शून्य-वर्णों का उपयोग नहीं करेगा।
हालांकि मैं यह है कि सभी यूनिकोड वर्ण हैं एक फ़ाइल बनाया है। मैंने पहले यूटीएफ -32 एन्कोडिंग, फिर एक यूटीएफ -32 ए एन्कोडिंग, एक यूटीएफ -16 एल और एक यूटीएफ -16 ए एन्कोडिंग के साथ-साथ एक यूटीएफ -8 एन्कोडिंग का उपयोग किया है।
utf-8 के लिए फ़ाइलों को फिर से सांकेतिक शब्दों में बदलना करने की कोशिश कर रहे हैं, मैं पहले से ही विद्यमान utf-8 फ़ाइल के लिए परिणाम की तुलना करना चाहते थे। चूंकि बीओएम के बाद मेरी फाइलों में पहला अक्षर शून्य-चरित्र है, मैं यूटीएफ -16 बीओएम के साथ फाइल को सफलतापूर्वक पहचान नहीं पाया, यह यूटीएफ -32 एल बीओएम के रूप में दिखाई दिया, क्योंकि बाइट्स बिल्कुल एडवर्ड के वर्णन के समान दिखाई दिए। बीओएम एफएफएफई के बाद पहला चरित्र 0000 है, लेकिन बीओएम डिटेक्शन को बीओएम एफएफएफई 0000 मिला और इसलिए, यूटीएफ -16 के बजाय यूटीएफ -32ले का पता चला, जिससे मेरा पहला 0000-चरित्र चोरी हो गया और बीओएम के हिस्से के रूप में लिया गया।
तो किसी को कभी भी utf-16 छोटे एंडियन के साथ एन्कोड किए गए फ़ाइल के पहले अक्षर के रूप में शून्य-वर्ण का उपयोग नहीं करना चाहिए, क्योंकि यह utf-16le और utf-32le BOM अस्पष्ट बना देगा।
मेरी समस्या का समाधान करने के लिए, मैं पहले और दूसरे चरित्र स्वैप जाएगा। :-)
अशक्त चरित्र अच्छी तरह से एक उच्च क्रम पाठ में इनकोडिंग प्रोटोकॉल का हिस्सा हो सकता है। यूनिकोड वास्तव में इस बात की परवाह नहीं करता है कि पाठ में कौन से कोड बिंदुओं का उपयोग किया जाता है और यू +0000 यू +0041 के रूप में मान्य है। – Joey
एक उच्च-आदेश प्रोटोकॉल पढ़ना, यह सिद्धांत प्रश्न सेटिंग के साथ संघर्ष करता है जहां एन्कोडिंग का आकलन किया जाना चाहिए। यदि आप प्रोटोकॉल पढ़ रहे हैं, तो आप एन्कोडिंग का अनुमान नहीं लगाते हैं। – u0b34a0f6ae
इसे एक और तरीके से रखने के लिए, फ़ाइल की शुरुआत में U + 0000 होना असंभव * नहीं है, लेकिन यह * बेहद दुर्लभ * है। यदि यह आपके द्वारा पढ़े जा रहे डेटा की संभावना है तो आपको प्रारूप पहचान के लिए बीओएम पर भरोसा नहीं करना चाहिए। –