बिना BOM के UTF-8 और UTF-8 में क्या अंतर है?

818

बिना BOM के UTF-8 और UTF-8 के बीच क्या अंतर है ? कौनसा अच्छा है?

— सरल
स्रोत

77

यूटीएफ -8 को बीओएम की तुलना में सामग्री द्वारा बेहतर तरीके से ऑटो-डिटेक्ट किया जा सकता है। विधि सरल है: फ़ाइल (या एक स्ट्रिंग) को UTF-8 के रूप में पढ़ने की कोशिश करें और यदि यह सफल होता है, तो मान लें कि डेटा UTF-8 है। अन्यथा मान लें कि यह CP1252 (या कुछ अन्य 8 बिट एन्कोडिंग) है। किसी भी गैर-यूटीएफ -8 आठ बिट एन्कोडिंग में लगभग निश्चित रूप से ऐसे सीक्वेंस होंगे, जिन्हें यूटीएफ -8 द्वारा अनुमति नहीं है। शुद्ध ASCII (7 बिट) को UTF-8 के रूप में व्याख्या की जाती है, लेकिन परिणाम उस तरह से भी सही है।

— ट्रोनिक

39

UTF-8 सामग्री के लिए बड़ी फ़ाइलों को स्कैन करने में समय लगता है। एक BOM इस प्रक्रिया को बहुत तेज़ बनाता है। व्यवहार में आपको अक्सर दोनों करने की आवश्यकता होती है। अपराधी आजकल यह है कि अभी भी बहुत सारी पाठ सामग्री यूनिकोड नहीं है, और मैं अभी भी टूल में टकरा रहा हूं, जो कहते हैं कि वे यूनिकोड करते हैं (उदाहरण के लिए यूटीएफ -8), लेकिन उनकी सामग्री को एक अलग कोडपेज का उत्सर्जन करते हैं।

— जीरोन विर्ट प्लिमर्स

10

@ पुरानी मुझे वास्तव में नहीं लगता कि इस मामले में "बेहतर" फिट बैठता है। यह पर्यावरण पर निर्भर करता है। यदि आप हैं यकीन है कि सभी को UTF-8 फ़ाइलों को एक साथ चिह्नित हैं बीओएम जाँच से बीओएम है "बेहतर" क्योंकि यह तेजी से और अधिक विश्वसनीय है, जिस तरह से।

— mg30rg

32

UTF-8 में BOM नहीं है। जब आप UTF-8 फ़ाइल के प्रारंभ में U + FEFF कोड बिंदु डालते हैं, तो इससे निपटने के लिए विशेष देखभाल की जानी चाहिए। यह सिर्फ उन Microsoft नामकरण झूठों में से एक है, जैसे कि कोई एन्कोडिंग "यूनिकोड" नहीं है जब ऐसी कोई बात नहीं है।

— tchrist

7

"आधुनिक मेनफ्रेम (और एआईएक्स) थोड़ा एंडियन यूटीएफ -8 से अवगत है" यूटीएफ -8 में एक एंडनेस नहीं है ! किसी विशेष सिस्टम के लिए सही "ऑर्डर" में जोड़े या चार के समूहों को रखने के लिए बाइट्स का कोई फेरबदल नहीं है! UTF-8 बाइट अनुक्रम का पता लगाने के लिए यह नोट करना उपयोगी हो सकता है कि मल्टी-बाइट अनुक्रम "कोडपॉइंट" के पहले बाइट (बाइट्स जो "सादा" ASCII वाले नहीं हैं) में MS बिट सेट है और सभी एक से तीन और हैं क्रमिक रूप से कम महत्वपूर्ण बिट एक रीसेट बिट द्वारा पीछा किया। उन सेट बिट्स की कुल संख्या एक कम बाइट्स है जो उस कोडपॉइंट में हैं और वे सभी MSB सेट होंगे ...

— SlySven

773

UTF-8 BOM एक पाठ स्ट्रीम ( ) की शुरुआत में बाइट्स का एक क्रम है 0xEF, 0xBB, 0xBFजो रीडर को UTF-8 में एन्कोड किए जाने के रूप में किसी फ़ाइल का अधिक विश्वसनीय अनुमान लगाने की अनुमति देता है।

आम तौर पर, बीओएम का उपयोग एन्कोडिंग की समाप्ति को इंगित करने के लिए किया जाता है , लेकिन चूंकि एंडियननेस UTF-8 के लिए अप्रासंगिक है, इसलिए बीओएम अनावश्यक है।

यूनिकोड मानक के अनुसार , UTF-8 फ़ाइलों के लिए BOM अनुशंसित नहीं है :

2.6 एन्कोडिंग योजनाएँ

... किसी BOM के उपयोग के लिए UTF-8 की न तो आवश्यकता है और न ही अनुशंसित है, लेकिन ऐसे संदर्भों में सामना किया जा सकता है जहां UTF-8 डेटा को अन्य एन्कोडिंग रूपों से परिवर्तित किया जाता है जो BOM का उपयोग करते हैं या जहां BOM का उपयोग UTF-8 हस्ताक्षर के रूप में किया जाता है । अधिक जानकारी के लिए , खंड 16.8, विशेष में "बाइट ऑर्डर मार्क" उपधारा देखें।

— मार्टिन कोटे
स्रोत

114

इसकी अनुशंसा नहीं की जा सकती है, लेकिन हिब्रू रूपांतरणों में मेरे अनुभव से BOM कभी-कभी एक्सेल में UTF-8 की पहचान के लिए महत्वपूर्ण है, और जिब्रिश और हिब्रू के बीच अंतर कर सकते हैं

— Matanya

26

इसकी अनुशंसा नहीं की जा सकती है, लेकिन "øøå" आउटपुट के लिए प्रयास करते समय मेरी शब्‍दावली लिपि में चमत्कार हुआ

— Marius

63

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

— मार्टिन डे

30

@ bames53: हां, एक आदर्श दुनिया में, फाइल फाइलों की एन्कोडिंग को संग्रहीत करना क्योंकि फाइल सिस्टम मेटाडेटा इसे संरक्षित करने का एक बेहतर तरीका होगा। लेकिन हम में से अधिकांश वास्तविक दुनिया में रहने वाले ओएस (एस) की फ़ाइल प्रणाली को बदल नहीं सकते हैं, हमारे कार्यक्रम चलते हैं - इसलिए यूनिकोड मानक के प्लेटफ़ॉर्म-स्वतंत्र बीओएम हस्ताक्षर का उपयोग करना सबसे अच्छा और सबसे व्यावहारिक वैकल्पिक आईएमएचओ जैसा लगता है।

— मार्टीन्यू

34

@martineau कल ही मैं एक UTF-8 BOM के साथ एक फ़ाइल में भाग गया था जो UTF-8 नहीं था (यह CP936 था)। यह दुर्भाग्यपूर्ण है कि UTF-8 BOM द्वारा दर्द की अपार मात्रा के लिए जिम्मेदार लोग इससे काफी हद तक बेखबर हैं।

— bames53

243

अन्य उत्कृष्ट उत्तर पहले ही उत्तर दे चुके हैं:

UTF-8 और BOM-ed UTF-8 के बीच कोई आधिकारिक अंतर नहीं है
एक बोम-एड UTF-8 स्ट्रिंग तीन निम्नलिखित बाइट्स के साथ शुरू होगा। EF BB BF
वे बाइट्स, यदि मौजूद हैं, तो फ़ाइल / स्ट्रीम से स्ट्रिंग निकालते समय इसे अनदेखा किया जाना चाहिए।

लेकिन, अतिरिक्त जानकारी के रूप में, यूटीएफ -8 के लिए बीओएम "गंध" करने का एक अच्छा तरीका हो सकता है अगर कोई स्ट्रिंग UTF-8 में एन्कोड किया गया था ... या यह किसी अन्य एन्कोडिंग में एक वैध स्ट्रिंग हो सकता है ...

उदाहरण के लिए, डेटा [EF BB BF 41 42 43] या तो हो सकता है:

वैध ISO-8859-1 स्ट्रिंग "¿» ABC "
वैध UTF-8 स्ट्रिंग "ABC"

तो जब यह पहली बाइट्स को देखकर किसी फ़ाइल सामग्री के एन्कोडिंग को पहचानने के लिए शांत हो सकता है, तो आपको इस पर भरोसा नहीं करना चाहिए, जैसा कि ऊपर दिए गए उदाहरण द्वारा दिखाया गया है

एनकोडिंग को जानना चाहिए, विभाजन को नहीं।

— paercebal
स्रोत

60

@ अलकोट: आप सही ढंग से समझ गए। स्ट्रिंग [EF BB BF 41 42 43] केवल बाइट्स का एक गुच्छा है। आपको इसकी व्याख्या करने के लिए बाहरी जानकारी की आवश्यकता है। यदि आपको लगता है कि आईएसओ-8859-1 का उपयोग करके उन बाइट्स को एन्कोड किया गया था, तो स्ट्रिंग "¿» tes एबीसी "है। यदि आपको लगता है कि यूटीएफ -8 का उपयोग करके उन बाइट्स को एन्कोड किया गया था, तो यह "एबीसी" है। यदि आप नहीं जानते हैं, तो आपको यह पता लगाने की कोशिश करनी चाहिए। BOM एक सुराग हो सकता है। UTF-8 के रूप में डिकोड किए जाने पर अमान्य वर्ण की अनुपस्थिति एक और हो सकती है ... अंत में, जब तक आप किसी तरह एन्कोडिंग को याद / खोज नहीं सकते, बाइट्स का एक सरणी बाइट्स का एक सरणी मात्र है।

— पियरसबल

19

@paercebal जबकि "¿» er "वैध लैटिन -1 है, यह बहुत ही संभावना नहीं है कि एक पाठ फ़ाइल उस संयोजन के साथ शुरू होती है। वही ucs2-le / be मार्करों और के लिए रखता है। यह भी आप कभी नहीं जान सकते ।

— user877329

16

@ डिसेज़ शायद यह भाषाई रूप से अमान्य है: पहले which (जो ठीक है), फिर कुछ उद्धरण चिह्न बिना अंतरिक्ष के बीच (ठीक नहीं)। ¿इंगित करता है कि यह स्पैनिश है लेकिन स्पैनिश में इसका उपयोग नहीं किया गया है। निष्कर्ष: यह बिना किसी निश्चितता के ऊपर एक निश्चित कुएं के साथ लैटिन -1 नहीं है।

— user877329

20

@ निश्चित रूप से, यह जरूरी समझ में नहीं आता है। लेकिन अगर आपका सिस्टम अनुमान लगाने पर निर्भर करता है , तो वह अनिश्चितता सामने आती है। कुछ दुर्भावनापूर्ण उपयोगकर्ता उद्देश्य पर इन 3 अक्षरों से शुरू होने वाले पाठ को प्रस्तुत करता है, और आपका सिस्टम अचानक मानता है कि यह UTF-8 को BOM के साथ देख रहा है, पाठ को UTF-8 के साथ मानता है इसमें लैटिन -1 का उपयोग करना चाहिए, और कुछ यूनिकोड इंजेक्शन लगते हैं। बस एक काल्पनिक उदाहरण है, लेकिन निश्चित रूप से संभव है। आप किसी पाठ एन्कोडिंग को उसकी सामग्री, अवधि के अनुसार नहीं आंक सकते हैं।

— deceze

40

"एनकोडिंग को जाना जाना चाहिए, न कि विभाजन को।" समस्या का दिल और आत्मा। +1, अच्छा सर। दूसरे शब्दों में: या तो अपनी सामग्री को मानकीकृत करें और कहें, "हम हमेशा इस एन्कोडिंग का उपयोग कर रहे हैं। अवधि। इसे इस तरह से लिखें। इसे इस तरह पढ़ें।" या एक विस्तारित प्रारूप विकसित करें जो एन्कोडिंग को मेटाडेटा के रूप में संग्रहीत करने की अनुमति देता है। (उत्तरार्द्ध को शायद कुछ "बूटस्ट्रैप मानक एन्कोडिंग" की आवश्यकता है, जैसे कि "यह कहना कि" एन्कोडिंग आपको बताता है कि भाग ASCII है। ")

— jpmc26

135

UTF-8 एन्कोडेड फ़ाइलों में BOM लगाने के साथ कम से कम तीन समस्याएं हैं।

कोई भी पाठ रखने वाली फ़ाइलें अब खाली नहीं हैं क्योंकि उनमें हमेशा BOM सम्‍मिलित है।
वे फाइलें जो टेक्स्ट को पकड़ती हैं जो UTF-8 के ASCII सबसेट के भीतर हैं, अब ASCII खुद नहीं है क्योंकि BOM ASCII नहीं है, जिससे कुछ मौजूदा उपकरण टूट जाते हैं, और उपयोगकर्ताओं के लिए ऐसे विरासत टूल को बदलना असंभव हो सकता है।
कई फ़ाइलों को एक साथ जोड़ना संभव नहीं है, क्योंकि प्रत्येक फ़ाइल में अब शुरुआत में BOM है।

और, जैसा कि दूसरों ने उल्लेख किया है, यह पता लगाने के लिए BOM होना न तो पर्याप्त है और न ही आवश्यक है कि कुछ UTF-8 है:

यह पर्याप्त नहीं है क्योंकि एक मनमाना बाइट अनुक्रम बीओएम का निर्माण करने वाले सटीक अनुक्रम से शुरू हो सकता है।
यह आवश्यक नहीं है क्योंकि आप बस बाइट्स पढ़ सकते हैं जैसे कि वे UTF-8 थे; यदि यह सफल होता है, तो यह परिभाषा के अनुसार, मान्य UTF-8 है।

— जेपी
स्रोत

8

बिंदु 1 "ऐसी फाइलें जो कोई पाठ नहीं रखती हैं, वे अब खाली नहीं हैं क्योंकि उनमें हमेशा BOM होती है", यह (1) व्याख्या किए गए सामग्री स्तर के साथ OS फाइल सिस्टम स्तर को भ्रमित करता है, साथ ही यह (2) गलत तरीके से मानता है कि BOM का उपयोग करना चाहिए। हर अन्यथा खाली फ़ाइल में भी BOM। (1) का व्यावहारिक समाधान (2) नहीं करना है। अनिवार्य रूप से शिकायत "कम करने के लिए संभव है कि यह एक खाली जगह में एक बीओएम डाल करने के लिए संभव है, इस प्रकार तार्किक रूप से खाली फ़ाइल (फ़ाइल आकार की जांच करके) की सबसे आसान पहचान को रोकने"। फिर भी अच्छा सॉफ्टवेयर इससे निपटने में सक्षम होना चाहिए, क्योंकि इसका एक उद्देश्य है।

— चीयर्स एंड हीथ। - अल्फ

7

बिंदु 2, "ASCII पाठ रखने वाली फाइलें अब स्वयं ASCII नहीं हैं", यह UTF-8 के साथ ASCII को मिलाता है। एक UTF-8 फ़ाइल जो ASCII पाठ रखती है वह ASCII नहीं है, यह UTF-8 है। इसी तरह, एक यूटीएफ -16 फ़ाइल जो एएससीआईआई पाठ रखती है वह एएससीआईआई नहीं है, यह यूटीएफ -16 है। और इसी तरह। ASCII एक 7-बिट सिंगल बाइट कोड है। UTF-8 ASCII का 8-बिट चर लंबाई विस्तार है। अगर> 127 मूल्यों के कारण "उपकरण टूट जाते हैं" तो वे केवल 8-बिट दुनिया के लिए फिट नहीं होते हैं। गैर-ASCII बाइट मानों के लिए टूटने वाले टूल के साथ केवल ASCII फ़ाइलों का उपयोग करने के लिए एक सरल व्यावहारिक समाधान है। एक बेहतर उपाय यह है कि उन अनचाहे औजारों को खोदा जाए।

— चीयर्स एंड हीथ। -

8

बिंदु 3, "कई फ़ाइलों को एक साथ जोड़ना संभव नहीं है क्योंकि प्रत्येक फ़ाइल में अब शुरुआत में BOM है" बस गलत है। मुझे BOM के साथ UTF-8 फ़ाइलों को समझने में कोई समस्या नहीं है, इसलिए यह स्पष्ट रूप से संभव है। मुझे लगता है कि शायद आपका मतलब यूनिक्स-भूमि catआपको एक साफ परिणाम नहीं देगा , जिसका परिणाम केवल शुरुआत में बीओएम है। यदि आपका मतलब है, तो ऐसा इसलिए है क्योंकि catबाइट स्तर पर काम करता है, न कि व्याख्या की गई सामग्री के स्तर पर, और इसी तरह catसे तस्वीरों के साथ काम नहीं कर सकता है, कहते हैं। फिर भी यह ज्यादा नुकसान नहीं करता है। ऐसा इसलिए है क्योंकि बीओएम एक शून्य-चौड़ाई वाले गैर-ब्रेकिंग स्पेस को एन्कोड करता है।

— चीयर्स एंड हीथ। -

20

@ चेरसन्ध।-अल्फ यह उत्तर सही है। आप केवल Microsoft बग्स को इंगित कर रहे हैं।

— tchrist

9

@brighty: हालांकि बम को जोड़कर स्थिति में कोई सुधार नहीं हुआ है।

— डिडुप्लिकेटर

84

यहाँ BOM उपयोग के उदाहरण हैं जो वास्तव में वास्तविक समस्याओं का कारण बनते हैं और अभी तक बहुत से लोग इसके बारे में नहीं जानते हैं।

BOM स्क्रिप्ट्स को तोड़ता है

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

#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node

यह उस प्रणाली को बताता है जो ऐसी स्क्रिप्ट को लागू करते समय दुभाषिया को चलाने की आवश्यकता होती है। यदि स्क्रिप्ट UTF-8 में एन्कोडेड है, तो किसी को शुरुआत में BOM शामिल करने का प्रलोभन दिया जा सकता है। लेकिन वास्तव में "#!" वर्ण केवल वर्ण नहीं हैं। वे वास्तव में एक जादू की संख्या है जो दो ASCII वर्णों से बना होता है। यदि आप उन पात्रों के सामने कुछ कहते हैं (एक बीओएम की तरह), तो फाइल ऐसी दिखेगी जैसे उसमें एक अलग मैजिक नंबर था और जिससे समस्याएं हो सकती हैं।

विकिपीडिया, लेख देखें : शबंग, अनुभाग: मैजिक नंबर :

यूटीएफ -8 सहित विस्तारित ASCII एन्कोडिंग में शेबबैंग पात्रों को एक ही दो बाइट्स द्वारा दर्शाया जाता है, जो आमतौर पर वर्तमान यूनिक्स जैसी प्रणालियों पर स्क्रिप्ट और अन्य पाठ फ़ाइलों के लिए उपयोग किया जाता है। हालाँकि, UTF-8 फाइलें वैकल्पिक बाइट ऑर्डर मार्क (BOM) से शुरू हो सकती हैं; यदि "निष्पादित" फ़ंक्शन विशेष रूप से बाइट्स 0x23 और 0x21 का पता लगाता है, तो शेमबंग से पहले BOM (0xEF 0xBB 0xBF) की उपस्थिति स्क्रिप्ट दुभाषिया को निष्पादित होने से रोक देगी।कुछ अधिकारी इस कारण से और व्यापक अंतर और दार्शनिक चिंताओं के लिए POSIX (यूनिक्स जैसी) लिपियों में बाइट ऑर्डर मार्क का उपयोग करने के खिलाफ सलाह देते हैं। इसके अतिरिक्त, यूटीएफ -8 में एक बाइट ऑर्डर मार्क आवश्यक नहीं है, क्योंकि एन्कोडिंग में धीरज के मुद्दे नहीं हैं; यह केवल UTF-8 के रूप में एन्कोडिंग की पहचान करने के लिए कार्य करता है। [महत्व दिया]

JSON में BOM अवैध है

RFC 7159, धारा 8.1 देखें :

कार्यान्वयन एक JSON पाठ की शुरुआत में एक बाइट क्रम चिह्न नहीं जोड़ना चाहिए।

BSON JSON में निरर्थक है

न केवल यह JSON में गैरकानूनी है, वर्ण एन्कोडिंग को निर्धारित करने के लिए भी आवश्यक नहीं है क्योंकि किसी भी JSON स्ट्रीम में उपयोग किए जाने वाले वर्ण एन्कोडिंग और समाप्ति दोनों को निर्धारित करने के लिए अधिक विश्वसनीय तरीके हैं ( विवरण के लिए यह उत्तर देखें)।

BOM ने JSON पार्सर को तोड़ दिया

न केवल यह JSON में अवैध है और इसकी आवश्यकता नहीं है , यह वास्तव में RFC 4627 में प्रस्तुत विधि का उपयोग करके एन्कोडिंग को निर्धारित करने वाले सभी सॉफ़्टवेयर को तोड़ता है :

एनआईएल बाइट के लिए पहले चार बाइट्स की जांच करते हुए, JSON की एन्कोडिंग और समाप्ति का निर्धारण:

00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8

अब, यदि फ़ाइल BOM से शुरू होती है तो यह इस तरह दिखाई देगी:

00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8

ध्यान दें कि:

UTF-32BE तीन NULs से शुरू नहीं होता है, इसलिए इसे पहचाना नहीं जाएगा
UTF-32LE का पहला बाइट तीन NULs द्वारा पीछा नहीं किया जाता है, इसलिए इसे मान्यता नहीं दी जाएगी
UTF-16BE में पहले चार बाइट्स में केवल एक NUL है, इसलिए इसे पहचाना नहीं जाएगा
UTF-16LE के पहले चार बाइट्स में केवल एक NUL है, इसलिए इसे मान्यता नहीं दी जाएगी

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

इसके अतिरिक्त, यदि मान्य JSON के लिए कार्यान्वयन परीक्षण जैसा कि मैं सुझाता हूं, यह उस इनपुट को भी अस्वीकार कर देगा जो वास्तव में UTF-8 के रूप में एन्कोडेड है, क्योंकि यह ASCII वर्ण <128 के साथ शुरू नहीं होता है क्योंकि यह RFC के अनुसार होना चाहिए।

अन्य डेटा प्रारूप

JSON में BOM की आवश्यकता नहीं है, गैरकानूनी है और RFC के अनुसार सही ढंग से काम करने वाले सॉफ़्टवेयर को तोड़ता है। यह केवल तब और अभी तक इसका उपयोग न करने के लिए एक बड़प्पन होना चाहिए, हमेशा ऐसे लोग होते हैं जो BOMs, टिप्पणियों, अलग-अलग उद्धरण नियमों या विभिन्न डेटा प्रकारों का उपयोग करके JSON को तोड़ने पर जोर देते हैं। बेशक किसी को भी BOMs या किसी भी चीज़ का उपयोग करने के लिए स्वतंत्र है यदि आपको इसकी आवश्यकता है - तो बस इसे JSON न कहें।

JSON की तुलना में अन्य डेटा प्रारूपों के लिए, इस पर एक नज़र डालें कि यह वास्तव में कैसा दिखता है। यदि केवल एन्कोडिंग UTF- * हैं और पहले वर्ण में ASCII वर्ण 128 से कम होना चाहिए तो आपके पास पहले से ही आपके डेटा की एन्कोडिंग और समाप्ति दोनों को निर्धारित करने के लिए आवश्यक सभी जानकारी है। वैकल्पिक सुविधा के रूप में भी BOM को जोड़ने से यह और अधिक जटिल और त्रुटि प्रवण हो जाएगा।

BOM के अन्य उपयोग

JSON या स्क्रिप्ट के बाहर उपयोग के लिए, मुझे लगता है कि यहाँ पहले से ही बहुत अच्छे उत्तर हैं। मैं विशेष रूप से स्क्रिप्टिंग और क्रमांकन के बारे में अधिक विस्तृत जानकारी जोड़ना चाहता था, क्योंकि यह BOM पात्रों का एक उदाहरण है जो वास्तविक समस्याओं का कारण बनता है।

— आरएसपी
स्रोत

5

rfc7159 जो rfc4627 को अधिगृहीत करता है वास्तव में सुझाव देता है कि BOM का समर्थन करना इतना बुरा नहीं हो सकता है। मूल रूप से एक बीओएम नहीं होने के कारण सिर्फ एक अस्पष्ट कीचड़ है ताकि पुराने विंडोज और यूनिक्स सॉफ्टवेयर जो यूनिकोड-अवगत नहीं हैं, अभी भी utf-8 प्रक्रिया कर सकते हैं।

— एरिक ग्रेंज

2

JSON जैसी ध्वनियों को इसका समर्थन करने के लिए अद्यतन करने की आवश्यकता है, जैसे पर्ल स्क्रिप्ट, पायथन स्क्रिप्ट, रूबी स्क्रिप्ट, Node.s.s. सिर्फ इसलिए कि इन प्लेटफार्मों ने समर्थन को शामिल नहीं करने का विकल्प चुना, जरूरी नहीं कि यह बीओएम के लिए उपयोग को मार डाले। Apple कुछ सालों से Adobe को मारने की कोशिश कर रहा है, और Adobe अभी भी आसपास है। लेकिन एक ज्ञानवर्धक पोस्ट।

— htm11h

13

@EricGrange, आपको BOM का बहुत समर्थन प्रतीत होता है, लेकिन यह महसूस करने में विफल रहते हैं कि यह सर्व-सर्वव्यापी, सार्वभौमिक रूप से उपयोगी, इष्टतम-न्यूनतम "सादा पाठ" प्रारूप में पूर्व-UTF8 अतीत का अवशेष होगा! किसी भी प्रकार की (इन-बैंड) हेडर को सादा टेक्स्ट स्ट्रीम में जोड़ना , परिभाषा के अनुसार, सबसे सरल टेक्स्ट फ़ाइलों के लिए एक अनिवार्य प्रोटोकॉल लागू करता है, जिससे यह फिर से "सबसे सरल" नहीं होता है! और किस लाभ के लिए? अन्य सभी सीपी का समर्थन करने के लिए , प्राचीन सीपी एनकोडिंग्स में भी हस्ताक्षर नहीं थे, इसलिए आप उन्हें यूटीएफ -8 के साथ गलती कर सकते हैं? (। Btw, ASCII, UTF-8, भी तो, उन लोगों के लिए एक बीओएम भी है;) चलो)।

— Sz।

2

यह उत्तर यही कारण है कि मैं इस सवाल पर आया था! मैं विंडोज में अपनी बैश स्क्रिप्ट बनाता हूं और उन स्क्रिप्ट को लिनक्स में प्रकाशित करते समय बहुत सारी समस्याओं का अनुभव करता हूं! जेसन फ़ाइलों के साथ एक ही बात।

— टोनो नाम

2

काश मैं इस उत्तर को लगभग पचास बार वोट कर पाता। मैं यह भी जोड़ना चाहता हूं कि इस बिंदु पर, यूटीएफ -8 ने मानक युद्ध जीता है, और इंटरनेट पर उत्पादित लगभग सभी पाठ यूटीएफ -8 हैं। सबसे लोकप्रिय प्रोग्रामिंग भाषाओं में से कुछ (जैसे सी # और जावा) यूटीएफ -16 का आंतरिक रूप से उपयोग करते हैं, लेकिन जब प्रोग्रामर उन भाषाओं का उपयोग आउटपुट धाराओं के लिए फाइल लिखते हैं, तो वे लगभग हमेशा उन्हें यूटीएफ -8 के रूप में एनकोड करते हैं। इसलिए, UTF-8 फ़ाइल को चिह्नित करने के लिए BOM का होना कोई मायने नहीं रखता है; UTF-8 को पढ़ने के दौरान आपके द्वारा उपयोग किया जाने वाला डिफ़ॉल्ट होना चाहिए, और यदि UTF-8 डिकोडिंग विफल रहता है तो केवल अन्य एन्कोडिंग का प्रयास करें।

— rmunn

51

बिना BOM के UTF-8 और UTF-8 के बीच क्या अंतर है?

संक्षिप्त उत्तर: UTF-8 में, एक BOM EF BB BFफ़ाइल के आरंभ में बाइट्स के रूप में एन्कोड किया गया है ।

लंबा जवाब:

मूल रूप से, यह उम्मीद की गई थी कि यूनिकोड को UTF-16 / UCS-2 में कूटबद्ध किया जाएगा। BOM को इस एन्कोडिंग फॉर्म के लिए डिज़ाइन किया गया था। जब आपके पास 2-बाइट कोड इकाइयां होती हैं, तो यह इंगित करना आवश्यक है कि उन दो बाइट्स किस क्रम में हैं, और ऐसा करने के लिए एक आम सम्मेलन डेटा की शुरुआत में "बाइट ऑर्डर मार्क" के रूप में चरित्र U + FEFF को शामिल करना है। U + FFFE वर्ण स्थायी रूप से अप्रमाणित है ताकि इसकी उपस्थिति का उपयोग गलत बाइट क्रम का पता लगाने के लिए किया जा सके।

यूटीएफ -8 में प्लेटफ़ॉर्म एंडियननेस की परवाह किए बिना एक ही बाइट ऑर्डर है, इसलिए एक बाइट ऑर्डर मार्क की आवश्यकता नहीं है। हालाँकि, यह हो सकता है EF BB FFकि डेटा में (बाइट अनुक्रम के रूप में ) UTF-8 से UTF-16 में परिवर्तित कर दिया गया हो, या डेटा "UTF-8" इंगित करने के लिए "हस्ताक्षर" के रूप में हो।

कौनसा अच्छा है?

के बिना। जैसा कि मार्टिन कोटे ने उत्तर दिया, यूनिकोड मानक इसकी अनुशंसा नहीं करता है। यह गैर-बीओएम-जागरूक सॉफ्टवेयर के साथ समस्याओं का कारण बनता है।

यह पता लगाने का एक बेहतर तरीका है कि कोई फ़ाइल UTF-8 वैधता जांचने के लिए है या नहीं। यूटीएफ -8 में सख्त नियम हैं कि बाइट अनुक्रम वैध हैं, इसलिए एक झूठे सकारात्मक की संभावना नगण्य है। यदि एक बाइट अनुक्रम UTF-8 की तरह दिखता है, तो यह संभवतः है।

— dan04
स्रोत

8

यह भी एक एकल गलत बाइट के साथ वैध UTF-8 को अमान्य कर देगा, हालांकि: /

— endolith

8

-1 re "यह गैर-बीओएम-जागरूक सॉफ़्टवेयर के साथ समस्याओं का कारण बनता है।", यह मेरे लिए कभी भी एक समस्या नहीं है, लेकिन इसके विपरीत, बीओएम की अनुपस्थिति से बीओएम-जागरूक सॉफ़्टवेयर (विशेष रूप से विज़ुअल सी ++) में समस्या होती है। मुसीबत। तो यह कथन बहुत ही प्लेटफॉर्म-विशिष्ट है , एक संकीर्ण यूनिक्स-भूमि का दृष्टिकोण है, लेकिन भ्रामक रूप से प्रस्तुत किया जाता है जैसे कि यह सामान्य रूप से लागू होता है। जो यह नहीं करता है।

— चीयर्स एंड हीथ। -

6

नहीं, UTF-8 में कोई BOM नहीं है। यह उत्तर गलत है। यूनिकोड मानक देखें।

— tchrist

2

आप यह भी सोच सकते हैं कि आपके पास एक शुद्ध ASCII फ़ाइल है जब बस बाइट्स देख रहे हैं। लेकिन यह एक utf-16 फाइल हो सकती है, जहां आपको शब्दों को देखना होगा और बाइट्स पर नहीं। आधुनिक सोफवेयर को बीओएम के बारे में पता होना चाहिए। अभी भी utf-8 पढ़ना विफल हो सकता है यदि अमान्य अनुक्रमों का पता लगाया जाए, तो कोडपॉइंट्स जो एक छोटे अनुक्रम या कोडपॉइंट्स का उपयोग कर सकते हैं जो कि सरोगेट हैं। Utf-16 पढ़ने के लिए भी विफल हो सकता है जब अनाथ सरोगेट हैं।

— चमकदार

1

@ नहीं, मैं " प्लेटफ़ॉर्म-विशिष्ट , एक संकीर्ण यूनिक्स-भूमि बिंदु " के रूप में एक गैर-बीओएम रवैये की आपकी व्याख्या से असहमत हूं । मेरे लिए, केवल एक ही तरीका है कि संकीर्णता "यूनिक्स भूमि" के साथ झूठ हो सकती है यदि एमएस और विज़ुअल सी ++ * एनआईएक्स से पहले आए, जो उन्होंने नहीं किया। तथ्य यह है कि एमएस (मैं जानबूझकर मान) को UTF-8 के बजाय UTF-16 में एक बीओएम उपयोग शुरू कर दिया मेरे लिए चलता है कि वे तोड़ने को बढ़ावा दिया sh, perl, g++, और कई अन्य स्वतंत्र और शक्तिशाली उपकरण। काम करने के लिए चीजें चाहिए? बस एमएस संस्करण खरीदें । MS ने अपने \ x80- \ x95 रेंज की आपदा की तरह ही प्लेटफ़ॉर्म-विशिष्ट समस्या का निर्माण किया।

— बबल्डेव ०२५

30

BOM के साथ UTF-8 की बेहतर पहचान है। मैं इस नतीजे पर पहुंचा हूं। मैं एक ऐसी परियोजना पर काम कर रहा हूं , जिसमें एक परिणाम CSV फ़ाइल है, जिसमें यूनिकोड वर्ण शामिल हैं।

यदि CSV फ़ाइल को BOM के बिना सहेजा जाता है, तो Excel सोचता है कि यह ANSI है और यह अस्पष्ट दिखाता है। एक बार जब आप सामने से "ईएफ बीबी बीएफ" जोड़ते हैं (उदाहरण के लिए, यूटीएफ -8 के साथ नोटपैड का उपयोग करके इसे फिर से सहेजकर, या यूटीएफ -8 के साथ नोटपैड ++ बीओएम के साथ), एक्सेल इसे ठीक से खोलता है।

यूएमकोड पाठ फ़ाइलों के लिए BOM चरित्र को प्रस्तुत करने की सिफारिश RFC 3629 द्वारा की जाती है: "UTF-8, ISO 10646 का एक रूपांतरण प्रारूप", नवंबर 2003 में http://tools.ietf.org/html/rfc3629 (यह अंतिम जानकारी इस पर मिली: http://www.herongyang.com/Unicode/Notepad-Byte-Oder-Mark-BOM-FEFF-EFBBF.html )

— हेलेन क्रेगमैन
स्रोत

6

इस उत्कृष्ट टिप के लिए धन्यवाद यदि कोई एक्सेल द्वारा उपयोग के लिए UTF-8 फाइल बना रहा है। अन्य परिस्थितियों में, मैं अभी भी अन्य उत्तरों का पालन करूंगा और BOM को छोड़ दूंगा।

— बारफूिन

5

यह उपयोगी भी है यदि आप ऐसी फाइलें बनाते हैं जिनमें केवल ASCII होता है और बाद में इसमें गैर-असिसी जोड़ी जा सकती है। मैं सिर्फ इस तरह के मुद्दे में भाग गया हूं: सॉफ्टवेयर जो utf8 की अपेक्षा करता है, उपयोगकर्ता संपादन के लिए कुछ डेटा के साथ फाइल बनाता है। यदि प्रारंभिक फ़ाइल में केवल ASCII होता है, तो कुछ संपादकों में खोला जाता है और फिर बचाया जाता है, यह लैटिन -1 में समाप्त हो जाता है और सब कुछ टूट जाता है। अगर मैं BOM जोड़ता हूं, तो यह संपादक द्वारा UTF8 के रूप में पता लगाया जाएगा और सब कुछ काम करता है।

— रॉबर्टो अलसीना

1

मुझे प्रोग्रामिंग से संबंधित कई उपकरण मिले हैं, जिन्हें सही ढंग से UTF-8 फ़ाइलों को सही ढंग से पहचानने के लिए BOM की आवश्यकता होती है। विजुअल स्टूडियो, SSMS, सॉरेट्री ....

— kjbartel

5

आप उस RFC में BOM का उपयोग करने के लिए अनुशंसा कहाँ से पढ़ते हैं ? अधिक से अधिक, यह एक कठिन सिफारिश है कि इसे कुछ परिस्थितियों में मना न करें जहां ऐसा करना मुश्किल है।

— Deduplicator

8

एक्सेल सोचता है कि यह एएनएसआई है और यह अस्पष्ट दिखाता है तो समस्या एक्सेल में है।

— इसहाक

17

BOM कहीं न कहीं, बूम (कोई उद्देश्य नहीं (एसआईसी)) को उछाल देता है। और जब यह फूलता है (उदाहरण के लिए, ब्राउज़र, संपादकों, आदि द्वारा पहचाना नहीं जाता है), तो यह ï»¿दस्तावेज़ की शुरुआत में अजीब पात्रों के रूप में दिखाई देता है (उदाहरण के लिए, HTML फ़ाइल, JSON प्रतिक्रिया, RSS , आदि) और ट्विटर पर ओबामा की चर्चा के दौरान हाल ही में एन्कोडिंग मुद्दे की तरह शर्मिंदगी का कारण बनता है ।

यह बहुत कष्टप्रद होता है जब यह डिबग करने के लिए कठिन स्थानों पर दिखाई देता है या जब परीक्षण की उपेक्षा की जाती है। इसलिए इसे टालना सबसे अच्छा है जब तक आप इसका उपयोग न करें।

— हलील ilzgür
स्रोत

हां, बिना बीओएम के बिना UTF-8 के बजाय UTF-8 के रूप में कूटबद्ध की जा रही फ़ाइल के कारण होने वाली समस्या की पहचान करने में केवल घंटों का समय लगता है। (मुद्दा केवल IE7 में दिखाया गया था, जिससे मुझे एक बहुत ही पीछा करना

— पड़ा

भविष्य के पाठक: ध्यान दें कि मैंने ऊपर जिस ट्वीट मुद्दे का उल्लेख किया है, वह BOM से संबंधित नहीं था, लेकिन यदि यह होता है, तो ट्वीट को इसी तरह से दिखाया जाएगा, लेकिन ट्वीट की शुरुआत में।

— हालिल Halzgür

12

@ user984003 नहीं, समस्या यह है कि Microsoft ने आपको भ्रमित किया है। जिसे यूटीएफ -8 कहते हैं, वह यूटीएफ -8 नहीं है। इसे बिना BOM के UTF-8 कहते हैं, जो वास्तव में UTF-8 है।

— tchrist

"सिक" आपके "नो पेन्ट का इरादा" में जोड़ देता है

— जोएलफैन

2

@JoelFan मैं अब और याद नहीं कर सकता, लेकिन मुझे लगता है कि लेखक के दावे के बावजूद सजा का इरादा हो सकता है :)

— हलील 23zgür

17

प्रश्न: बिना BOM के UTF-8 और UTF-8 के बीच क्या अंतर है? कौनसा अच्छा है?

यहाँ बाइट ऑर्डर मार्क (BOM) पर विकिपीडिया लेख के कुछ अंश दिए गए हैं, जो मुझे विश्वास है कि इस प्रश्न का ठोस उत्तर प्रस्तुत करते हैं।

BOM और UTF-8 के अर्थ पर:

यूनिकोड मानक यूटीएफ -8 में बीओएम की अनुमति देता है , लेकिन इसके उपयोग की आवश्यकता या अनुशंसा नहीं करता है। यूटीएफ -8 में बाइट ऑर्डर का कोई मतलब नहीं है, इसलिए यूटीएफ -8 में इसका एकमात्र उपयोग शुरू में संकेत देना है कि टेक्स्ट स्ट्रीम यूटीएफ -8 में एन्कोडेड है।

BOM का उपयोग नहीं करने के लिए तर्क :

BOM का उपयोग नहीं करने के लिए प्राथमिक प्रेरणा सॉफ्टवेयर के साथ बैकवर्ड-संगतता है जो यूनिकोड-अवगत नहीं है ... BOM का उपयोग नहीं करने के लिए एक और प्रेरणा UTF-8 को "डिफ़ॉल्ट" एन्कोडिंग के रूप में प्रोत्साहित करना है।

BOM का उपयोग करने के लिए तर्क :

BOM का उपयोग करने का तर्क यह है कि इसके बिना, यह निर्धारित करने के लिए कि किस फ़ाइल को एन्कोडिंग का उपयोग किया जाता है, हेयुरिस्टिक विश्लेषण की आवश्यकता होती है। ऐतिहासिक रूप से ऐसा विश्लेषण, विभिन्न 8-बिट एन्कोडिंग को भेद करने के लिए, जटिल, त्रुटि-प्रवण और कभी-कभी धीमा होता है। कार्य को आसान बनाने के लिए कई पुस्तकालय उपलब्ध हैं, जैसे कि मोज़िला यूनिवर्सल चार्सेट डिटेक्टर और यूनिकोड के लिए अंतर्राष्ट्रीय घटक।

प्रोग्रामर गलती से यह मान लेते हैं कि UTF-8 का पता लगाना उतना ही मुश्किल है (यह बाइट अनुक्रमों के विशाल बहुमत के कारण अमान्य UTF-8 नहीं है, जबकि इन पुस्तकालयों में एनकोडिंग सभी संभावित बाइट अनुक्रमों को अलग करने की कोशिश कर रहे हैं)। इसलिए सभी यूनिकोड-जागरूक कार्यक्रम इस तरह का विश्लेषण नहीं करते हैं और इसके बजाय बीओएम पर भरोसा करते हैं।

विशेष रूप से, Microsoft कंपाइलर्स और दुभाषिए, और Microsoft Windows पर सॉफ़्टवेयर के कई टुकड़े जैसे कि नोटपैड ने सही ढंग से UTF-8 पाठ नहीं पढ़ा होगा जब तक कि इसमें केवल ASCII वर्ण नहीं है या यह BOM से शुरू होता है, और बचत करते समय प्रारंभ में BOM जोड़ देगा UTF-8 के रूप में पाठ। जब Microsoft Word दस्तावेज़ को एक सादे पाठ फ़ाइल के रूप में डाउनलोड किया जाता है, तो Google डॉक्स एक BOM जोड़ देगा।

जो पर, बेहतर है के साथ या बिना बीओएम:

IETF सिफारिश की है कि UTF-8, या (ख) से संकेत मिलता है क्या एन्कोडिंग का प्रयोग किया जा रहा है किसी और तरीके से, तो यह है कि अगर एक प्रोटोकॉल या तो (क) हमेशा उपयोग करता है "चाहिए एक हस्ताक्षर के रूप में U + FEFF के प्रयोग की मनाही।"

मेरा निष्कर्ष:

BOM का उपयोग केवल तभी करें जब सॉफ़्टवेयर एप्लिकेशन के साथ संगतता बिल्कुल आवश्यक हो।

यह भी ध्यान दें कि जबकि संदर्भित विकिपीडिया लेख इंगित करता है कि कई Microsoft अनुप्रयोग BOM पर सही ढंग से UTF-8 का पता लगाने के लिए भरोसा करते हैं, यह सभी Microsoft अनुप्रयोगों के लिए ऐसा नहीं है । उदाहरण के लिए, द्वारा उठाई बाहर के रूप में @barlop , जब विंडोज कमांड प्रॉम्प्ट का उपयोग कर UTF-8 के साथ ^† , इस तरह के आदेशों typeऔर moreउम्मीद नहीं है बीओएम उपस्थित होना। अगर बीओएम है वर्तमान में, यह समस्या हो सकती है के रूप में यह अन्य अनुप्रयोगों के लिए है।

Without chcpकमांड कोड पृष्ठ 65001 के माध्यम से UTF-8 ( BOM के बिना ) के लिए समर्थन प्रदान करता है ।

— DavidRR
स्रोत

5

मुझे BOM के बिना सख्त होना बेहतर है । मुझे लगता है कि पाया .htaccessऔर gzip compressionUTF-8 बीओएम के साथ संयोजन में एक एन्कोडिंग त्रुटि बदलें किसी सुझाव का बिना बीओएम पालन UTF-8 में एन्कोडिंग के लिए देता है के रूप में समझाया यहां की समस्याओं को हल

— Chetabahana

1

'BOM का उपयोग न करने के लिए एक और प्रेरणा UTF-8 को "डिफ़ॉल्ट" एन्कोडिंग के रूप में प्रोत्साहित करना है।' - जो इतना मजबूत और एक तर्क मान्य है, कि आप वास्तव में वहां जवाब रोक सकते थे! ... -o जब तक आपको सार्वभौमिक पाठ प्रतिनिधित्व के लिए एक बेहतर विचार नहीं मिला, वह है। ;) (मुझे नहीं पता कि आप कितने साल के हैं, आपको कितने साल तक पूर्व-यूटीएफ 8 युग में भुगतना पड़ा था (जब भाषाविदों ने सख्त तौर पर अपने अल्फ़ाज़ बदलने पर भी विचार किया था), लेकिन मैं आपको बता सकता हूं कि हर पल हम राइडिंग के करीब पहुंचते हैं सभी प्राचीन एकल-बाइट-के-साथ-मेटाडेटा एन्कोडिंग्स की गड़बड़ी, "एक ही शुद्ध आनंद है" होने के बजाय

— ।

टेक्स्ट फ़ाइल स्वरूपों के सबसे सरल तरीके से BOM (या कुछ भी!) जोड़ने के बारे में यह टिप्पणी भी देखें , इसका मतलब होगा कि " यूनिवर्सल ", और "सरल" (यानी) "ओवरहेडलेस")! ...

— एसजेड।

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

— एरिक ग्रेंज

9

इस प्रश्न के पहले से ही एक लाख और एक उत्तर हैं और उनमें से कई काफी अच्छे हैं, लेकिन मैं कोशिश करना चाहता था और स्पष्ट करना चाहता हूं कि एक बीओएम का उपयोग किया जाना चाहिए या नहीं।

जैसा कि उल्लेख किया गया है, यह निर्धारित करने के लिए कि क्या एक स्ट्रिंग UTF-8 है या नहीं, यह निर्धारित करने में UTF BOM (बाइट ऑर्डर मार्क) का कोई उपयोग शिक्षित अनुमान नहीं है। यदि उचित मेटाडेटा उपलब्ध है (जैसे charset="utf-8"), तो आप पहले से ही जानते हैं कि आप क्या उपयोग करने वाले हैं, लेकिन अन्यथा आपको कुछ मान्यताओं का परीक्षण करने और बनाने की आवश्यकता होगी। इसमें हेक्साडेसिमल बाइट कोड, ईएफ बीबी बीएफ के साथ शुरू होने वाली फ़ाइल की जाँच करना शामिल है।

यदि यूटीएफ -8 बीओएम के अनुरूप बाइट कोड पाया जाता है, तो संभावना यह है कि यह यूटीएफ -8 है और आप वहां से जा सकते हैं। जब यह अनुमान लगाने के लिए मजबूर किया जाता है, हालांकि, पढ़ने के दौरान अतिरिक्त त्रुटि की जाँच अभी भी एक अच्छा विचार होगा जब कुछ गड़बड़ हो जाएगा। यदि इनपुट निश्चित रूप से इसके स्रोत के आधार पर UTF-8 नहीं होना चाहिए , तो आपको केवल यह मान लेना चाहिए कि BOM UTF-8 (यानी लैटिन -1 या ANSI) नहीं है । अगर कोई बीओएम नहीं है, तो आप बस यह निर्धारित कर सकते हैं कि एन्कोडिंग के खिलाफ सत्यापन करके यह यूटीएफ -8 माना जाता है या नहीं।

BOM की अनुशंसा क्यों नहीं की जाती है?

गैर-यूनिकोड-जागरूक या खराब अनुपालन सॉफ्टवेयर मान सकता है कि यह लैटिन -1 या एएनएसआई है और स्ट्रिंग से बीओएम पट्टी नहीं करेगा, जो स्पष्ट रूप से मुद्दों का कारण बन सकता है।
यह वास्तव में आवश्यक नहीं है (बस जाँच करें कि क्या सामग्री आज्ञाकारी है और हमेशा यूटीएफ -8 का उपयोग इस प्रकार करें कि जब कोई अनुपालन एन्कोडिंग नहीं मिल सके)

आपको बीओएम के साथ कब एनकोड करना चाहिए ?

यदि आप मेटाडेटा को किसी अन्य तरीके से (चारसेट टैग या फ़ाइल सिस्टम मेटा के माध्यम से) रिकॉर्ड करने में असमर्थ हैं, और बीओएम जैसे कार्यक्रमों का उपयोग किया जा रहा है, तो आपको बीओएम के साथ एनकोड करना चाहिए। यह विंडोज पर विशेष रूप से सच है जहां एक बीओएम के बिना कुछ भी आमतौर पर विरासत कोड पृष्ठ का उपयोग करने के लिए माना जाता है। बीओएम कार्यालय जैसे कार्यक्रमों को बताता है कि, हां, इस फाइल का पाठ यूनिकोड है; यहाँ एन्कोडिंग का उपयोग किया गया है।

जब यह इसके नीचे आता है, तो केवल फाइलें जो मुझे वास्तव में सीएसवी के साथ समस्या हैं। कार्यक्रम के आधार पर, यह या तो बीओएम होना चाहिए या नहीं होना चाहिए। उदाहरण के लिए, यदि आप Windows पर Excel 2007+ का उपयोग कर रहे हैं, तो इसे BOM के साथ एन्कोड किया जाना चाहिए यदि आप इसे आसानी से खोलना चाहते हैं और डेटा आयात करने का सहारा नहीं लेना है।

— जेपीसी-ae
स्रोत

2

आपके उत्तर का अंतिम भाग 100% सही है: BOM का उपयोग करने का एकमात्र कारण यह है कि जब आपको बगगी सॉफ़्टवेयर के साथ इंटरॉपर्ट करना है जो अज्ञात फ़ाइलों को पार्स करने के लिए इसके डिफ़ॉल्ट के रूप में UTF-8 का उपयोग नहीं करता है।

— rmunn

8

यह ध्यान दिया जाना चाहिए कि कुछ फ़ाइलों के लिए आप पास विंडोज पर भी बीओएम नहीं होना चाहिए । उदाहरण SQL*plusया VBScriptफाइलें हैं। यदि ऐसी फ़ाइलों में BOM होती है, तो जब आप उन्हें निष्पादित करने का प्रयास करते हैं तो आपको एक त्रुटि मिलती है।

— वर्नफ्रीड डम्सचेत
स्रोत

8

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

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

UTF-8 के लिए BOM से कुछ भी उम्मीद न करें।

— जेम्स वेकफील्ड
स्रोत

7

BOM पर विकिपीडिया पृष्ठ के निचले भाग पर उद्धृत: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"UTM-8 के लिए BOM का उपयोग न तो आवश्यक है और न ही अनुशंसित है, लेकिन ऐसे संदर्भों में सामना किया जा सकता है जहां UTF-8 डेटा को अन्य एन्कोडिंग रूपों से परिवर्तित किया जाता है जो BOM का उपयोग करते हैं या जहां BOM का उपयोग UTF-8 हस्ताक्षर के रूप में किया जाता है"

— PIB
स्रोत

2

क्या आपके पास कोई उदाहरण है जहाँ सॉफ़्टवेयर यह निर्णय लेता है कि क्या UTF-8 का उपयोग BOM के साथ / बिना BOM के साथ किया जा सकता है, इस पर आधारित है कि पिछले एन्कोडिंग से यह एन्कोडिंग है, एक BOM था या नहीं ?! यह एक बेतुके दावे की तरह लगता है

— बार्लोप

7

बिना BOM के UTF-8 में कोई BOM नहीं है, जो इसे किसी भी तरह से UTF-8 से बेहतर नहीं बनाता है, सिवाय इसके कि फ़ाइल के उपभोक्ता को पता होना चाहिए (या जानने से लाभ होगा) कि क्या फ़ाइल UTF-8 है-इनकोडिंग या नहीं।

बीओएम आमतौर पर एन्कोडिंग की समाप्ति को निर्धारित करने के लिए उपयोगी होता है, जो अधिकांश उपयोग के मामलों के लिए आवश्यक नहीं होता है।

इसके अलावा, बीओएम उन उपभोक्ताओं के लिए अनावश्यक शोर / दर्द हो सकता है जो इसके बारे में नहीं जानते या परवाह नहीं करते हैं, और इसके परिणामस्वरूप उपयोगकर्ता भ्रम हो सकता है।

— रोमेन
स्रोत

2

"जिसका यूटीएफ -8 के लिए कोई उपयोग नहीं है क्योंकि यह 8-बिट प्रति ग्लिफ़ है।" एर ... नहीं, केवल ASCII-7 ग्लिफ़ UTF-8 में 8-बिट हैं। इससे आगे कुछ भी 16, 24 या 32 बिट्स होने जा रहा है।

— पॉवरलॉर्ड

3

"BOM आमतौर पर एन्कोडिंग की समाप्ति का निर्धारण करने के लिए उपयोगी है, जो कि अधिकांश उपयोग के मामलों के लिए आवश्यक नहीं है।" ... एंडियननेस यूटीएफ -8 पर लागू नहीं होता है, उपयोग के मामले की परवाह किए बिना

— जोएलफैन

6

मैं इसे अलग नजरिए से देखता हूं। मुझे लगता है कि BOM के साथ UTF-8 बेहतर है क्योंकि यह फ़ाइल के बारे में अधिक जानकारी प्रदान करता है। मैं बिना समस्या के ही BOM के बिना UTF-8 का उपयोग करता हूं।

मैं लंबे समय से अपने पृष्ठों पर कई भाषाओं (यहां तक कि सिरिलिक ) का उपयोग कर रहा हूं और जब फ़ाइलों को बीओएम के बिना सहेजा जाता है और मैं उन्हें संपादक के साथ संपादन के लिए फिर से खोल देता हूं (जैसा कि चेरोविम ने भी उल्लेख किया है), कुछ वर्ण दूषित हैं।

ध्यान दें कि जब आप UTF-8 एन्कोडिंग के साथ एक नई बनाई गई फ़ाइल को सहेजने का प्रयास करते हैं, तो विंडोज का क्लासिक नोटपैड स्वचालित रूप से एक बीओएम के साथ फाइलों को बचाता है।

मैं व्यक्तिगत रूप से सर्वर साइड स्क्रिप्टिंग फ़ाइलों (.asp, .ini, .aspx) को BOM और .html फाइलों को बिना BOM के सहेजता हूं ।

— user1358065
स्रोत

4

उत्कृष्ट क्लासिक नोटपैड के बारे में उत्कृष्ट टिप के लिए धन्यवाद। मैंने पहले से ही कुछ समय बिताया है, जो एक ही बात का पता लगा रहा है। मेरा नतीजा यह था कि विंडोज़ क्लासिक नोटपैड के बजाय हमेशा नोटपैड ++ का उपयोग किया जाता था। :-)

— बारफूिन

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

— चमकदार

@ मुझे लगता है कि आपको BOM के लिए एक की आवश्यकता नहीं है। इससे कोई फर्क नहीं पड़ता, यह एक utf-8 BOM को पहचानने के लिए बहुत ज्यादा नहीं है, यह एफएफबीबीएफ या एफएफई (अगर गलत पढ़ा है तो फीफे का है)। कोई बस उन बाइट्स को हटा सकता है। हालाँकि, बाकी फ़ाइल के लिए मैपिंग करना बुरा नहीं है, लेकिन साथ ही बाइट को हटाने में भी सक्षम है

— बार्लोप

@barlop यदि फ़ाइल की सामग्री utf-8 एन्कोडेड है तो आप utf-8 BOM को क्यों हटाना चाहते हैं? BOM को आधुनिक टेक्स्ट व्यूअर, टेक्स्ट कंट्रोल और साथ ही टेक्स्ट एडिटर्स द्वारा मान्यता प्राप्त है। Utf-8 अनुक्रम के लिए एक से एक दृश्य का कोई मतलब नहीं है, क्योंकि n बाइट्स के परिणामस्वरूप एक वर्ण होता है। बेशक एक पाठ-संपादक या हेक्स-संपादक को किसी भी बाइट को हटाने की अनुमति देनी चाहिए, लेकिन इससे अमान्य utf-8 अनुक्रम हो सकते हैं।

— चमकदार

बम के साथ @brighty utf-8 एक एन्कोडिंग है, और बिना बम के utf-8 एक एन्कोडिंग है। Cmd प्रॉम्प्ट बिना बम के utf8 का उपयोग करता है .. इसलिए यदि आपके पास एक utf8 फ़ाइल है, तो आप chcp 65001utf8 समर्थन के लिए कमांड चलाते हैं , यह बिना बम के utf8 है। यदि आप ऐसा करते हैं तो type myfileयह केवल ठीक से प्रदर्शित होगा यदि कोई बम नहीं है। यदि आप एए फाइल करने के लिए चार्ट का उत्पादन करते हैं echo aaa>a.aया करते हैं echo אאא>a.a, और आपके पास 65001 chcp है, तो यह बिना BOM के आउटपुट देगा।

— बार्लोप

6

जब आप UTF-8 में एन्कोडेड जानकारी प्रदर्शित करना चाहते हैं तो आपको समस्याओं का सामना नहीं करना पड़ सकता है। उदाहरण के लिए HTML दस्तावेज़ को UTF-8 के रूप में घोषित करें और आपके पास आपके ब्राउज़र में वह सब कुछ होगा जो दस्तावेज़ के मुख्य भाग में समाहित है।

लेकिन यह तब नहीं होता जब हमारे पास पाठ, सीएसवी और एक्सएमएल फाइलें हों, या तो विंडोज या लिनक्स पर।

उदाहरण के लिए, विंडोज या लिनक्स में एक पाठ फ़ाइल, सबसे आसान चीजों में से एक, यह कल्पना नहीं है (आमतौर पर) यूटीएफ -8।

इसे XML के रूप में सहेजें और इसे UTF-8 घोषित करें:

<?xml version="1.0" encoding="UTF-8"?>

यह सही ढंग से प्रदर्शित नहीं होगा (यह पढ़ा नहीं जाएगा) भले ही इसे यूटीएफ -8 घोषित किया गया हो।

मेरे पास फ्रांसीसी अक्षरों वाले डेटा की एक स्ट्रिंग थी, जिसे सिंडिकेशन के लिए XML के रूप में सहेजने की आवश्यकता थी। बहुत शुरुआत से एक यूटीएफ -8 फ़ाइल बनाने के बिना (आईडीई और "नई फ़ाइल बनाएं" में विकल्प बदलते हुए) या फ़ाइल की शुरुआत में बीओएम को जोड़ना

$file="\xEF\xBB\xBF".$string;

मैं एक XML फ़ाइल में फ्रेंच अक्षरों को सहेजने में सक्षम नहीं था।

— फ्लोरिन सिमा
स्रोत

1

एफटीएम, एक्सएमएल में, मुझे लगता है कि आपको फ़ाइल को एएससीआईआई के रूप में रखना चाहिए और इसके बजाय संस्थाओं का उपयोग करना चाहिए ।

— एलोइस महदल

4

मुझे पता है कि यह एक पुराना उत्तर है, लेकिन मैं केवल यह उल्लेख करना चाहता हूं कि यह गलत है। लिनक्स पर पाठ फ़ाइलें (अन्य यूनिक्स के लिए बात नहीं कर सकती) आमतौर पर / / यूटीएफ -8 हैं।

— फंक्टिनो

6

एक व्यावहारिक अंतर यह है कि यदि आप Mac OS X के लिए शेल स्क्रिप्ट लिखते हैं और इसे सादे UTF-8 के रूप में सहेजते हैं, तो आपको प्रतिक्रिया मिलेगी:

#!/bin/bash: No such file or directory

शेबंग लाइन के जवाब में निर्दिष्ट करें कि आप किस शेल का उपयोग करना चाहते हैं:

#!/bin/bash

यदि आप UTF-8 के रूप में सहेजते हैं, तो कोई BOM ( BBEdit में नहीं ) सब ठीक हो जाएगा।

— डेविड
स्रोत

8

ऐसा इसलिए है क्योंकि Microsoft मानक क्या कहता है का अर्थ स्वैप किया है। UTF-8 का कोई BOM नहीं है: उन्होंने Microsoft UTF-8 बनाया है जो डेटा स्ट्रीम के सामने एक शानदार BOM सम्मिलित करता है और फिर आपको बताया कि नहीं, यह वास्तव में UTF-8 है। यह नहीं। यह सिर्फ विस्तार और भ्रष्ट है।

— tchrist

4

जैसा कि ऊपर उल्लेख किया गया है, बीओएम के साथ यूटीएफ -8 गैर-बीओएम-जागरूक (या संगत) सॉफ़्टवेयर के साथ समस्याएं पैदा कर सकता है। मैंने एक बार HTML फ़ाइलों को संपादित किया जो UTF-8 + BOM के रूप में मोज़िला-आधारित कोम्पोज़र के साथ एन्कोड किया गया , एक क्लाइंट के रूप में जिसे WYSIWYG प्रोग्राम की आवश्यकता थी ।

बचत करते समय संभवतः लेआउट नष्ट हो जाएगा। इस तरह से मुझे अपना रास्ता बनाने में थोड़ा समय लगा। इन फ़ाइलों ने फिर फ़ायरफ़ॉक्स में अच्छा काम किया, लेकिन इंटरनेट एक्सप्लोरर में लेआउट को नष्ट करने वाले सीएसएस क्विक को फिर से दिखाया। घंटों तक बिना किसी लिंक के सीएसएस फाइलों के साथ काम करने के बाद मुझे पता चला कि इंटरनेट एक्सप्लोरर को BOMfed HTML फ़ाइल पसंद नहीं है। फिर कभी नहीं।

इसके अलावा, मुझे यह विकिपीडिया में मिला:

यूटीएफ -8 सहित विस्तारित ASCII एन्कोडिंग में शेबबैंग पात्रों को एक ही दो बाइट्स द्वारा दर्शाया जाता है, जो आमतौर पर वर्तमान यूनिक्स जैसी प्रणालियों पर स्क्रिप्ट और अन्य पाठ फ़ाइलों के लिए उपयोग किया जाता है। हालाँकि, UTF-8 फाइलें वैकल्पिक बाइट ऑर्डर मार्क (BOM) से शुरू हो सकती हैं; यदि "निष्पादित" फ़ंक्शन विशेष रूप से बाइट्स 0x23 0x21 का पता लगाता है, तो शेमबंग से पहले BOM (0xEF 0xBB 0xBF) की उपस्थिति स्क्रिप्ट दुभाषिया को निष्पादित होने से रोक देगी। कुछ अधिकारी इस कारण और व्यापक अंतर और दार्शनिक चिंताओं के लिए POSIX (यूनिक्स जैसी) लिपियों में बाइट ऑर्डर मार्क का उपयोग करने की सलाह देते हैं।

— मारेक मोहालिंग
स्रोत

4

यूनिकोड बाइट ऑर्डर मार्क (BOM) FAQ एक संक्षिप्त उत्तर प्रदान करता है:

प्रश्न: मुझे BOM से कैसे निपटना चाहिए?

A: यहां कुछ दिशानिर्देशों का पालन किया गया है:

एक विशेष प्रोटोकॉल (जैसे .txt फ़ाइलों के लिए Microsoft कन्वेंशन) को कुछ यूनिकोड डेटा धाराओं जैसे फ़ाइलों पर BOM के उपयोग की आवश्यकता हो सकती है। जब आपको इस तरह के प्रोटोकॉल के अनुरूप होना चाहिए, तो BOM का उपयोग करें।

कुछ प्रोटोकॉल असंगत पाठ के मामले में वैकल्पिक BOMs की अनुमति देते हैं। उन मामलों में,

जहां एक पाठ डेटा स्ट्रीम को सादे पाठ के रूप में जाना जाता है, लेकिन अज्ञात एन्कोडिंग के रूप में, BOM को एक हस्ताक्षर के रूप में इस्तेमाल किया जा सकता है। यदि कोई BOM नहीं है, तो एन्कोडिंग कुछ भी हो सकता है।

जहां एक पाठ डेटा स्ट्रीम को सादे यूनिकोड पाठ (लेकिन जो एंडियन नहीं है) के रूप में जाना जाता है, तो BOM को एक हस्ताक्षर के रूप में उपयोग किया जा सकता है। यदि कोई बीओएम नहीं है, तो पाठ की व्याख्या बड़े-एंडियन के रूप में की जानी चाहिए।

कुछ बाइट ओरिएंटेड प्रोटोकॉल एक फ़ाइल की शुरुआत में ASCII वर्णों की अपेक्षा करते हैं। यदि इन प्रोटोकॉल के साथ UTF-8 का उपयोग किया जाता है, तो BOM का उपयोग एन्कोडिंग फॉर्म हस्ताक्षर के रूप में किया जाना चाहिए।

जहाँ डेटा स्ट्रीम का सटीक प्रकार ज्ञात है (जैसे यूनिकोड बिग-एंडियन या यूनिकोड लिटिल-एंडियन), BOM का उपयोग नहीं किया जाना चाहिए। विशेष रूप से, जब भी कोई डेटा स्ट्रीम UTF-16BE, UTF-16LE, UTF-32BE या UTF-32LE एक BOM का उपयोग नहीं किया जाना चाहिए।

— वर्नफ्रीड डम्सचेत
स्रोत

1

से http://en.wikipedia.org/wiki/Byte-order_mark :

बाइट ऑर्डर मार्क (BOM) एक यूनिकोड वर्ण है जिसका उपयोग टेक्स्ट फाइल या स्ट्रीम के एंडियननेस (बाइट ऑर्डर) को इंगित करने के लिए किया जाता है। इसका कोड बिंदु U + FEFF है। BOM का उपयोग वैकल्पिक है, और, यदि उपयोग किया जाता है, तो पाठ स्ट्रीम की शुरुआत में दिखाई देना चाहिए। बाइट-ऑर्डर इंडिकेटर के रूप में इसके विशिष्ट उपयोग से परे, बीओएम चरित्र यह भी संकेत दे सकता है कि पाठ में कई यूनिकोड निरूपण में से कौन सा इनकोडिंग है।

हमेशा अपनी फ़ाइल में BOM का उपयोग करना सुनिश्चित करेगा कि यह हमेशा एक संपादक में सही ढंग से खुलता है जो UTF-8 और BOM का समर्थन करता है।

BOM की अनुपस्थिति के साथ मेरी वास्तविक समस्या निम्नलिखित है। मान लीजिए कि हमें एक फ़ाइल मिली है जिसमें शामिल हैं:

abc

BOM के बिना यह अधिकांश संपादकों में ANSI के रूप में खुलता है। इसलिए इस फ़ाइल का एक अन्य उपयोगकर्ता इसे खोलता है और उदाहरण के लिए कुछ मूल वर्ण जोड़ता है:

abg-αβγ

उफ़ ... अब फ़ाइल अभी भी ANSI में है और लगता है कि क्या, "α does" 6 बाइट्स पर कब्जा नहीं करता है, लेकिन 3. यह UTF-8 नहीं है और यह बाद में विकास श्रृंखला में अन्य समस्याओं का कारण बनता है।

— cherouvim
स्रोत

9

यह सुनिश्चित करता है कि गैर-बीओएम-जागरुक सॉफ़्टवेयर की शुरुआत में नकली बाइट्स दिखाई दें। वाह।

— रोमेन

1

@Romain Muller: जैसे आप BOM के बाद हेडर भेजने की कोशिश करते हैं, जैसे PHP 5 "असंभव" त्रुटियों को फेंक देगा।

— पिस्कोर ने इमारत को

5

α ascii नहीं है, लेकिन 8bit-ascii-bassed एन्कोडिंग में दिखाई दे सकता है। एक बीओएम का उपयोग utf-8 की एक बेनाफिट को निष्क्रिय कर देता है, एससीआई के साथ इसकी अनुकूलता (लैगसी अनुप्रयोगों के साथ काम करने की क्षमता जहां शुद्ध एस्की का उपयोग किया जाता है)।

— ctrl-alt-delor 13

1

यह गलत उत्तर है। इसके सामने एक BOM के साथ एक स्ट्रिंग पूरी तरह से कुछ और है। यह वहाँ होना चाहिए नहीं है और बस सब कुछ शिकंजा।

— tchrist

BOM के बिना यह अधिकांश संपादकों में ANSI के रूप में खुलता है। मैं बिल्कुल सहमत हूं। यदि ऐसा होता है तो आप भाग्यशाली हैं यदि आप सही कोडपेज से निपटते हैं लेकिन वास्तव में यह सिर्फ एक अनुमान है, क्योंकि कोडपेज फाइल का हिस्सा नहीं है। एक BOM है।

— चमकदार

1

यहाँ विजुअल स्टूडियो, सॉरीकेट्री और बिटबकेट पुल अनुरोधों के साथ मेरा अनुभव है , जो मुझे कुछ समस्याएं दे रहा है:

तो यह पता चला है कि BOM एक हस्ताक्षर के साथ एक लाल डॉट वर्ण शामिल करेगा जब एक पुल अनुरोध की समीक्षा (यह काफी कष्टप्रद हो सकता है)।

यदि आप इस पर मंडराते हैं, तो यह "ufeff" जैसे चरित्र को दिखाएगा, लेकिन यह पता चलता है कि Sourcetree इस प्रकार के बाइटमार्क नहीं दिखाता है, इसलिए यह संभवतः आपके पुल अनुरोधों में समाप्त हो जाएगा, जो ठीक होना चाहिए, यह है कि विज़ुअल स्टूडियो 2017 ने अब नई फ़ाइलों को एन्कोड किया है, इसलिए शायद बिटबकेट को इसे अनदेखा करना चाहिए या इसे दूसरे तरीके से दिखाना चाहिए, यहां अधिक जानकारी:

रेड डॉट मार्कर BitBucket अलग-अलग दृश्य

— सिंह
स्रोत

-4

अगर आप HTML फ़ाइलों में UTF-8 का उपयोग करते हैं और यदि आप उसी पृष्ठ पर सर्बियाई सिरिलिक, सर्बियाई लैटिन, जर्मन, हंगेरियन या कुछ विदेशी भाषा का उपयोग करते हैं तो BOM वाला UTF बेहतर है।

यह मेरी राय है (कंप्यूटिंग और आईटी उद्योग के 30 साल)।

— user2173444
स्रोत

1

मुझे यह सच भी लगता है। यदि आप पहले 255 ASCII सेट के बाहर के वर्णों का उपयोग करते हैं और आप BOM को छोड़ देते हैं, तो ब्राउज़र इसे ISO-8859-1 के रूप में व्याख्या करते हैं और आपको विकृत वर्ण मिलते हैं। ऊपर दिए गए जवाबों को देखते हुए, यह स्पष्ट रूप से ब्राउज़र-विक्रेताओं पर गलत काम कर रहा है जब वे एक बीओएम का पता नहीं लगाते हैं। लेकिन जब तक आप Microsoft Edge / Mozilla / Webkit / Blink में काम नहीं करते, आपके पास इन ऐप्स के दोषों के साथ कोई विकल्प नहीं है।

— asontu

UTF क्या? UTF-8? UTF-16? कुछ और?

— पीटर मोर्टेंसन