HTTP हेडर में UTF-8 का उपयोग करना

जैसा कि आप जानते हैं, HTTP 1.1 एक टेक्स्ट-आधारित डेटा ट्रांसफर प्रोटोकॉल है। HTTP संदेशों को ISO-8859-1 (जिसे सशर्त रूप से umlauts, diacritics युक्त ASCII का एक विस्तारित संस्करण माना जा सकता है, और पश्चिमी यूरोपीय भाषाओं में उपयोग किए जाने वाले अन्य वर्ण) का उपयोग करके एन्कोड किया गया है। उसी समय, संदेश निकाय में एक और एन्कोडिंग का उपयोग किया जा सकता है, जिसे "सामग्री-प्रकार" हेडर में इंगित किया जाना चाहिए। लेकिन क्या होगा अगर हमें संदेश बॉडी में नहीं बल्कि स्वयं हेडर में गैर-एएससीआईआई वर्णों को निर्दिष्ट करने की आवश्यकता है? संभवतः सबसे आम मामला "सामग्री-विवाद" शीर्षक में एक फ़ाइल नाम है। यह एक काफी सामान्य कार्य प्रतीत होगा, लेकिन इसका कार्यान्वयन इतना स्पष्ट नहीं है।

TL; DR: “सामग्री-विवाद” के लिए RFC 6266 में वर्णित एन्कोडिंग का उपयोग करें और पाठ को अन्य मामलों में लैटिन (लिप्यंतरण) में परिवर्तित करें।

एन्कोडिंग के लिए एक छोटा सा परिचय

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

ASCII एक साधारण एन्कोडिंग है जिसमें 128 वर्ण हैं और पूरे अंग्रेजी वर्णमाला, संख्या, विराम चिह्न और सेवा वर्ण शामिल हैं।



7 बिट्स किसी भी ASCII चरित्र का प्रतिनिधित्व करने के लिए पर्याप्त हैं। शब्द "परीक्षण" को हेक्स प्रतिनिधित्व में 0x74 0x65 0x73 0x74 के रूप में दर्शाया जाएगा। सभी वर्णों के लिए पहला बिट हमेशा 0 होता है, क्योंकि वर्ण 128 एनकोडेड होते हैं, और बाइट 2 ^ 8 = 256 विकल्प प्रदान करता है।

ISO-8859-1 पश्चिमी यूरोपीय भाषाओं के लिए एन्कोडिंग है। इसमें फ्रेंच डायक्टिरिटिक्स, जर्मन ऑमलेट्स आदि शामिल हैं।



एन्कोडिंग में 256 वर्ण होते हैं और इस प्रकार, एक बाइट द्वारा दर्शाया जा सकता है। पहला हाफ (128 अक्षर) ASCII जैसा ही है। इस प्रकार, यदि पहला बिट = 0 है, तो यह एक नियमित ASCII वर्ण है। यदि 1 है, तो यह ISO-8859-1 के लिए विशिष्ट वर्ण है।

UTF-8 ASCII के साथ सबसे प्रसिद्ध एन्कोडिंग में से एक है। 1.112.064 वर्णों को एनकोड करने में सक्षम। प्रत्येक वर्ण का आकार 1 से 4 बाइट्स से भिन्न होता है ( पहले 6 बाइट तक की अनुमति थी)।



इस एन्कोडिंग के साथ काम करने वाला कार्यक्रम पहले बिट्स द्वारा निर्धारित करता है कि चरित्र में कितने बाइट्स शामिल हैं। यदि ओकटेट 0 से शुरू होता है, तो चरित्र को एक बाइट द्वारा दर्शाया जाता है। 110 - दो बाइट्स, 1110 - तीन बाइट्स, 11110 - 4 बाइट्स।

ISO-8859-1 के साथ, पहले 128 अक्षर पूरी तरह से ASCII के अनुरूप हैं। इसलिए, केवल ASCII वर्णों का उपयोग करने वाले ग्रंथ बाइनरी प्रतिनिधित्व में बिल्कुल समान होंगे, भले ही US-ASCII, ISO-8859-1 या UTF-8 का उपयोग एन्कोडिंग के लिए किया गया हो।

संदेश के शरीर में UTF-8 का उपयोग करना

हेडर पर जाने से पहले, आइए संदेशों के शरीर में UTF-8 का उपयोग करने के तरीके पर एक नज़र डालें। ऐसा करने के लिए, हेडर "सामग्री-प्रकार" का उपयोग करें ।



यदि "सामग्री-प्रकार" निर्दिष्ट नहीं है, तो ब्राउज़र को संदेशों को संसाधित करना चाहिए जैसे कि उन्हें ISO-8859-1 में लिखा गया था। ब्राउज़र को एन्कोडिंग का अनुमान लगाने की कोशिश नहीं करनी चाहिए और, इसके अलावा, "सामग्री-प्रकार" को अनदेखा करें। लेकिन वास्तव में ऐसी स्थिति में क्या प्रकट होता है जहां "सामग्री-प्रकार" प्रेषित नहीं होता है, यह ब्राउज़र के कार्यान्वयन पर निर्भर करता है। उदाहरण के लिए, फ़ायरफ़ॉक्स विनिर्देश के अनुसार करेगा और संदेश को पढ़ेगा जैसे कि इसे ISO-8859-1 में एन्कोड किया गया था। Google Chrome, इसके विपरीत, ऑपरेटिंग सिस्टम के एन्कोडिंग का उपयोग करेगा, जो कई रूसी उपयोगकर्ताओं के लिए विंडोज -1251 के बराबर है। किसी भी स्थिति में, यदि संदेश UTF-8 में था, तो इसे सही ढंग से प्रदर्शित नहीं किया जाएगा।

हमने UTF-8 संदेश को हेडर मान में रखा है

संदेश शरीर के साथ, सब कुछ काफी सरल है। संदेश का मुख्य भाग हमेशा हेडर का अनुसरण करता है, इसलिए कोई तकनीकी समस्या नहीं है। लेकिन सुर्खियों का क्या? विनिर्देश स्पष्ट रूप से बताता है कि संदेश में शीर्षलेखों का क्रम मायने नहीं रखता है। यानी एक हेडर में दूसरे हेडर के माध्यम से एन्कोडिंग निर्दिष्ट करना संभव नहीं है।

क्या होता है अगर आप सिर्फ हेडर मूल्य के लिए UTF-8 मान लेते हैं और लिखते हैं? हमने देखा है कि संदेश निकाय के साथ इस तरह की चाल के परिणामस्वरूप मूल्य केवल आईएसओ-8859-1 में पढ़ा जाएगा। यह मान लेना तर्कसंगत होगा कि हेडलाइन के साथ भी यही होगा। लेकिन ऐसा है नहीं। वास्तव में, कई में, यदि अधिकांश नहीं, मामलों में, यह समाधान काम करेगा। इसमें पुराने iPhones, IE11, Firefox, Google Chrome शामिल हैं। मेरी उंगलियों पर एकमात्र ब्राउज़र जब मैंने यह लेख लिखा था जो उस शीर्षक के साथ काम नहीं करना चाहता था तो वह था एज।



यह व्यवहार विशिष्टताओं में दर्ज नहीं है। शायद ब्राउज़र डेवलपर्स ने डेवलपर्स के लिए जीवन को आसान बनाने का फैसला किया और स्वचालित रूप से पता लगाया कि संदेश हेडर UTF-8 में एन्कोड किए गए थे। सामान्य तौर पर, यह इतना मुश्किल काम नहीं है। हम पहले बिट को देखते हैं: यदि 0, तो एएससीआईआई, यदि 1 - तो, ​​संभवतः, यूटीएफ -8।

क्या इस मामले में ISO-8859-1 के साथ कोई अंतरंगता है? वास्तव में, लगभग कोई भी नहीं। उदाहरण के लिए UTF-8 को 2 ऑक्टेट वर्ण (रूसी अक्षर दो ऑक्टेट द्वारा दर्शाया गया है) लें। प्रस्तुत बाइनरी में प्रतीक इस तरह दिखाई देगा: 110xxxxx 10xxxxxx । हेक्स प्रतिनिधित्व में: [0xC0-0x6F] [0x80-0xBF] । ISO-8859-1 में, ये पात्र शायद ही किसी चीज़ को सांकेतिक रूप से लोड कर सकते हैं। इसलिए, ब्राउज़र द्वारा गलत तरीके से संदेश को डिक्रिप्ट करने का जोखिम बहुत कम है।

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

लेकिन, इस बात की परवाह किए बिना कि आपका फ्रेमवर्क या सर्वर आपको हेडर के लिए UTF-8 संदेश लिखने की अनुमति देता है या नहीं, मैं ऐसा करने की सलाह नहीं देता। यह एक प्रलेखित समाधान नहीं है जो किसी भी समय ब्राउज़र में काम करना बंद कर सकता है।

लिप्यंतरण

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

RFC 2047

जैसा कि मैंने पहले ही उल्लेख किया है, टॉमकैट ने मुझे संदेश शीर्षक में UTF-8 डालने की अनुमति नहीं दी। क्या यह व्यवहार सुविधा सर्वलेट्स के लिए जावा डॉक्स में परिलक्षित होती है? हाँ, परिलक्षित:



आरएफसी 2047 का उल्लेख किया। मैंने इस प्रारूप का उपयोग करके संदेशों को एनकोड करने की कोशिश की - ब्राउज़र ने मुझे नहीं समझा। यह एन्कोडिंग विधि HTTP में काम नहीं करती है। हालांकि उन्होंने पहले काम किया था। उदाहरण के लिए, फ़ायरफ़ॉक्स से इस एन्कोडिंग के लिए समर्थन निकालने के लिए एक टिकट ।

RFC 6266

टिकट में, जो लिंक पिछले अनुभाग में है, वहाँ संदर्भ हैं कि RFC 2047 के लिए समर्थन की समाप्ति के बाद भी, अभी भी डाउनलोड की गई फ़ाइलों के नाम पर UTF-8 मान स्थानांतरित करने का एक तरीका है: RFC 6266 । मेरी राय में, यह अब तक का सबसे सही निर्णय है। कई लोकप्रिय ऑनलाइन संसाधन इसका उपयोग करते हैं। हम CUBA प्लेटफ़ॉर्म पर "सामग्री-विवाद" उत्पन्न करने के लिए इस विशेष RFC का उपयोग करते हैं।

RFC 6266 "सामग्री-विवाद" शीर्षक के उपयोग का वर्णन करने वाला एक विनिर्देश है। एन्कोडिंग विधि स्वयं एक और विनिर्देश, RFC 8187 में विस्तार से वर्णित है।



"फ़ाइल नाम" पैरामीटर में ASCII, "फ़ाइल नाम *" - किसी भी आवश्यक एन्कोडिंग में फ़ाइल नाम शामिल है। दोनों विशेषताओं के साथ, "फ़ाइल नाम" सभी आधुनिक ब्राउज़रों (IE11 और सफारी के पुराने संस्करणों सहित) में अनदेखा किया गया है। अधिकांश पुराने ब्राउज़र, इसके विपरीत, "फ़ाइल नाम *" को अनदेखा करते हैं।

इस एन्कोडिंग विधि का उपयोग करते समय, पैरामीटर पहले एन्कोडिंग को इंगित करता है, उसके बाद एन्कोडेड मान। ASCII एन्कोडिंग के दृश्यमान वर्णों की आवश्यकता नहीं है। शेष वर्ण केवल हेक्स प्रतिनिधित्व में लिखे गए हैं, प्रत्येक ओकटेट से पहले "%" के साथ।

अन्य हेडर के साथ क्या करना है?

RFC 8187 में वर्णित एन्कोडिंग सार्वभौमिक नहीं है। हां, आप हेडर में * प्रीफिक्स के साथ एक पैरामीटर डाल सकते हैं, और यह कुछ ब्राउज़रों के लिए भी काम कर सकता है, लेकिन विनिर्देश आपको बताता है कि नहीं।

प्रत्येक मामले में जहां UTF-8 हेडर में समर्थित है, वर्तमान में संबंधित RFC में इसका स्पष्ट उल्लेख है। सामग्री-निपटान के अलावा, इस एन्कोडिंग का उपयोग किया जाता है, उदाहरण के लिए, वेब लिंकिंग और डाइजेस्ट एक्सेस ऑथेंटिकेशन में ।

यह ध्यान दिया जाना चाहिए कि इस क्षेत्र में मानक लगातार बदल रहे हैं। HTTP में ऊपर वर्णित एन्कोडिंग का उपयोग केवल 2010 में प्रस्तावित किया गया था। "सामग्री-विवाद" में इस एन्कोडिंग का उपयोग 2011 में मानक में तय किया गया था। इस तथ्य के बावजूद कि ये मानक केवल "प्रस्तावित मानक" चरण में हैं , वे हर जगह समर्थित हैं। विकल्प है कि भविष्य में हम नए मानकों की उम्मीद करते हैं जो हेडर में अलग-अलग एन्कोडिंग के साथ अधिक समान काम करने की अनुमति देंगे, इससे इनकार नहीं किया जाता है। इसलिए, यह केवल HTTP मानकों की दुनिया में समाचार और ब्राउज़रों के पक्ष में उनके समर्थन के स्तर का पालन करने के लिए बना हुआ है।