भाषा अज्ञेय कुकी कुकी एन्कोडिंग/डिकोडिंग मानकों

Question

बैकएंड प्लेटफार्मों के बावजूद मुझे एन्कोडिंग/डिकोडिंग कुकी मानों के लिए मानक (या कोई है?) के बारे में पता लगाने में कठिनाई हो रही है।

RFC 2109 के अनुसार:

VALUE उपयोगकर्ता एजेंट को अपारदर्शी है और कुछ भी मूल सर्वर भेजने के लिए, संभवत: यह सर्वर से चयनित प्रिंट योग्य ASCII एन्कोडिंग में चुनता है हो सकता है। "ओपेक" का तात्पर्य है कि सामग्री केवल मूल सर्वर के लिए ब्याज और प्रासंगिकता है। वास्तव में, सामग्री सेट-कुकी हेडर की जांच करने वाले किसी भी व्यक्ति द्वारा पठनीय हो सकती है।

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

मान लें कि हमारे पास मूल्य को एन्कोड करने की आवश्यकता है। रूसी /"печенье (*} значения"/ का अर्थ है "कुकी मूल्य" इसमें कुछ अतिरिक्त गैर अल्फा-न्यूमेरिक वर्ण हैं।

पायथन:

लगभग हर WSGI सर्वर एक ही करता है और पायथन के SimpleCookie वर्ग कि encodes/कई का कहना है कि भले ही octal literals से डीकोड करने के लिए उपयोग करता है ECMA-262, कठोर मोड में octal literals are depreciated। WTF?

तो, हमारे कच्चे कुकी मान "/\"\320\277\320\265\321\207\320\265\320\275\321\214\320\265 (*} \320\267\320\275\320\260\321\207\320\265\320\275\320\270\321\217\"/"

Node.js हो जाता है:

सब पर परीक्षण नहीं किया है, लेकिन मैं सिर्फ अनुमान लगा रहा हूँ एक जावास्क्रिप्ट बैकएंड देशी encodeURIComponent और decodeURIComponent कार्यों के साथ यह करना होगा hexadecimal से बचने/अनदेखा करने का उपयोग करें?

पीएचपी:

पीएचपी कुकी मानों कि encodeURIComponent के लिए इसी तरह बिल्कुल वैसा ही है, लेकिन नहीं पर लागू होता है urlencode।

तो कच्चा मूल्य बन जाता है; %2F%22%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D1%8C%D0%B5+%28%2A%7D+%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D1%8F%22%2F जो डबल कोट्स के साथ भी लपेटा नहीं गया है।

हालांकि; यदि जावास्क्रिप्ट value चर ऊपर पीएचपी इनकोडिंग महत्व है, decodeURIComponent(value) देता /"печенье+(*}+значения"/, .. "+" रिक्त स्थान के बजाय वर्ण देख

जावा, रूबी, पर्ल और .NET में स्थिति क्या है? वांछित व्यवहार के लिए कौन सी भाषा निम्नलिखित (या निकटतम) है। असल में, क्या डब्ल्यू 3 द्वारा परिभाषित इस के लिए कोई मानक है?

Answer 1

मुझे लगता है कि आपके पास चीजें थोड़ा मिश्रित हो गई हैं। सर्वर का एन्कोडिंग क्लाइंट से कोई फर्क नहीं पड़ता, और यह नहीं होना चाहिए। यही वह है जो आरएफसी 210 9 यहां कहने की कोशिश कर रहा है।

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

HTTP में वही बात हो रही है। सर्वर ब्राउज़र के साथ एक कुकी सेट करता है। जब ब्राउज़र सर्वर पर वापस आता है (पढ़ें: अगला HTTP अनुरोध), यह कुकी को सर्वर पर दिखाता है। सर्वर कुकी को पहचानता है, और तदनुसार कार्य करता है। ऐसी कुकी कुछ "WasHereBefore" मार्कर के रूप में सरल हो सकती है। फिर, यह महत्वपूर्ण नहीं है कि ब्राउज़र समझता है कि यह क्या है। यदि आप अपनी कुकी हटाते हैं, तो सर्वर बस कार्य करेगा जैसे कि उसने आपको पहले कभी नहीं देखा है, बस उस क्लब में बाउंसर की तरह ही अगर आप उस स्याही टिकट को धो लेंगे।

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

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

कुकी में डेटा को संग्रहीत करने में कोई मानक नहीं है। मानक केवल इतना कहता है कि एक ब्राउज़र कुकी को वापस भेज देगा जैसा कि इसे प्राप्त हुआ था। उपयोग की जाने वाली एन्कोडिंग योजना जो भी आपकी प्रोग्रामिंग भाषा फिट दिखाई देती है।

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

चूंकि ब्राउज़र व्यवहार मानकीकृत है, तो आप या तो अपने सर्वर पर उपयोग की जाने वाली सभी अन्य भाषाओं में एक भाषा एन्कोडिंग योजना का अनुकरण कर सकते हैं, या बस उपयोग की जा रही सभी भाषाओं में अपनी खुद की मानकीकृत एन्कोडिंग योजना बना सकते हैं। आपको उच्च स्तरीय दिनचर्या के बजाय PHP के header() जैसे निचले स्तर के दिनचर्या का उपयोग करना पड़ सकता है, जैसे start_session() इसे प्राप्त करने के लिए।

बीटीडब्ल्यू: इसी तरह, यह सर्वर साइड प्रोग्रामिंग भाषा है जो सर्वर साइड सत्र डेटा को स्टोर करने का निर्णय लेती है। आप PHP के $_SESSION सरणी का उपयोग कर पर्ल के CGI::Session तक नहीं पहुंच सकते हैं।

Answer 2

क्लाइंट के लिए अपारदर्शी कुकी होने के बावजूद, इसे अभी भी HTTP spec के अनुरूप होना आवश्यक है। rfc2616 निर्दिष्ट करता है कि सभी HTTP शीर्षलेख ASCII (ISO-8859-1) होना चाहिए। rfc5987 विस्तार करता है कि अन्य चरित्र सेटों का समर्थन करने के लिए, लेकिन मुझे नहीं पता कि यह कितना व्यापक रूप से समर्थित है।

Answer 3

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

आपको इसे लपेटते समय भी यूटीएफ 8 में एक स्पष्ट रूपांतरण सुनिश्चित करने की आवश्यकता होगी। अन्य भाषाओं & रनटाइम्स, यूनिकोड का समर्थन करते समय, तारों को आंतरिक रूप से यूटीएफ 8 के रूप में स्टोर नहीं कर सकते हैं ... कई विंडोज एपीआई की तरह। पायथन 2।एक्स, मेरे अनुभव में, शायद ही कभी स्पष्ट रूपांतरण के बिना यूनिकोड तार सही हो जाता है।

एन्कोड: nativeString -> utfEncode() -> base64Encode()

डीकोड: base64Decode() -> utfDecode() -> nativeString

लगभग हर भाषा मैं का पता है, इन दिनों, इस का समर्थन करता है । आप एक सार्वभौमिक एकल-फ़ंक्शन एन्कोड की तलाश कर सकते हैं, लेकिन मैं सावधानी के पक्ष में गलती करता हूं और दो-चरणीय दृष्टिकोण चुनता हूं ... विशेष रूप से विदेशी चरित्र सेट के साथ। अदृश्य स्याही के लिए