अधिकांश (सभी?) वेबसाइटें केवल ASCII में उपयोगकर्ता नामों का समर्थन क्यों करती हैं? क्या कोई व्यवस्थापक यूनिकोड उपयोगकर्ता नाम स्वीकार करना शुरू करने का निर्णय लेता है तो क्या कोई सुरक्षा विचार है?क्या उपयोगकर्ता नामों में यूनिकोड की अनुमति होनी चाहिए?
मैं कहूंगा कि अधिकांश PHP इंस्टॉलेशन में यूनिकोड के लिए समर्थन की कमी का एक बड़ा कारण है। इसके साथ काम करना आसान नहीं है, तो क्यों इसकी अनुमति दें जब ASCII में संभावनाएं आपके पूरे उपयोगकर्ता आधार को कवर करने के लिए पर्याप्त हों?
प्रश्न PHP के बारे में नहीं है, इसलिए उस भाषा की दुर्बलता तर्क नहीं होनी चाहिए। – Crozin
@ क्रोज़िन: PHP में कई वेब एप्लिकेशन लिखे गए हैं, इसलिए यह उन लोगों के लिए तर्क हो सकता है। उस विशेष भाषा में केवल लाटेक्स के बगल में यूनिकोड के लिए सबसे कठिन समर्थन का एक लंबा, दुखद इतिहास है। – Joey
@Scott_M।@ Johannes_Rössel: इस तर्क के बाद, वेब केवल लैटिन वर्णों के साथ आबादी होनी चाहिए? आपके उत्तरों पर फॉलो-अप करने के लिए, भले ही आप कहते हैं कि PHP में यूनिकोड का समर्थन नहीं है, आपको यूनिकोड सामग्री के साथ कई वेबसाइटें मिलती हैं, ** ** को छोड़कर जब वे अपने उपयोगकर्ताओं को एएससीआई उपयोगकर्ता नाम और पासवर्ड चुनने के लिए मजबूर करते हैं। – banx
सादा ASCII दुर्लभ है, मैं कहूंगा। अक्सर यह है कि पश्चिमी यूरोप लैटिन 1 में और अमेरिका के लिए भी कोई भी इसके बारे में सोचता नहीं है। कुछ डेटाबेस विरासत चरित्र सेट और यूनिकोड (varchar बनाम nvarchar) में टेक्स्ट के बीच भेद बनाते हैं या अन्य डेटाबेस के लिए एक विशेष चरित्र सेट सेट करना होगा।
खासकर अमेरिका में कई लोग कभी भी ध्यान नहीं देते कि एएससीआईआई पर्याप्त नहीं होगा। कुछ लोगों के साथ बहाने का प्रयास करें »उपयोगकर्ताओं को इसे दर्ज करना होगा« या इसी तरह जो अधिकतर फर्जी हैं, हालांकि।
अपने प्रश्न का उत्तर देने के लिए, मुझे संदेह है कि अलग-अलग स्क्रिप्ट का उपयोग करके अन्य लोगों के नामों को धोखा देने के लिए सुरक्षा विचार हैं, एक और एक समान दिखता है, लेकिन एक लैटिन है, एक सिरिलिक है - यह पहले यूआरएल के साथ किया गया है) । आम तौर पर मैं इसे डेवलपर्स द्वारा एक निरीक्षण के रूप में देखता हूं जो शायद बेहतर जानना चाहिए।
होमोग्लिफ़ हमले। उपयोगकर्ता 'बिल्ली' और 'сat' अलग यूनिकोड तार हैं हालांकि वे वही दिखते हैं। दूसरे 'कोट' में पहला अक्षर रूसी 'एस' - "साइरिलिक लघु पत्र ईएस" सटीक होना है। सिस्टम आसानी से यह नहीं बता सकता कि आप किसी अन्य उपयोगकर्ता के नाम को धोखा दे रहे हैं - कंप्यूटर पर निक्स अलग हैं।
संपादित करें: मिश्रित स्क्रिप्ट को रोकने से समस्या हल नहीं होती है। उदाहरण के लिए 'сосо' शुद्ध साइरीलिक है और इसे एसीआई 'कोको' को धोखा देने के लिए उपयोग किया जा सकता है।
इसके अलावा, बाएं से दाएं ओवरराइड (और दोस्तों।) उन्हें असुरक्षित छोड़ दें और वे आपके पूरे पृष्ठ को गड़बड़ कर देंगे।
ठीक है, यह * आसानी से बता सकता है कि क्या आप स्क्रिप्ट मिश्रण कर रहे हैं और उनको अस्वीकार कर सकते हैं। वेब ब्राउज़र पन्योड डिस्प्ले पर आईडीएन को वापस करने के लिए एक समान नियम का पालन करते हैं। – Joey
आपको * स्क्रिप्ट को * मिश्रण करने की हमेशा आवश्यकता नहीं है। कुछ ऑल-एसीआई शब्द केवल सिरिलिक का उपयोग करके पुनर्निर्मित किए जा सकते हैं, उदाहरण के लिए 'कोको'। तो आपको उससे भी निपटने की ज़रूरत है। –
एएससीआईआई में भी Homoglyph हमले संभव हैं; "0" और "ओ" कई फोंट में अलग-अलग हैं, जैसे "|", "मैं", "एल", और "1"; दूसरों के बीच ".com", ".corn"। –
HTTP प्रमाणीकरण? मौजूदा प्रोटोकॉल पर यूनिकोड उपयोगकर्ता नाम (और/या पासवर्ड) भेजने में कुछ समस्याएं हो सकती हैं। एक मामला जिसे मैंने पहले में चलाया है मूल प्रमाणीकरण के साथ है। मूल ऑथ हेडर में इन यूनिकोड उपयोगकर्ता नाम/पासवर्ड भेजने को संभालने के लिए कोई अच्छी तरह से परिभाषित तरीका नहीं है।
[यूटीएफ -7] (http://en.wikipedia.org/wiki/UTF-7) आपको यूनिकोड कोड-पॉइंट ASCII के रूप में प्रेषित करने की अनुमति देता है। – dreamlax
लेकिन यूटीएफ -7, या किसी अन्य एन्कोडिंग के साथ, आपको यह सुनिश्चित करने के लिए क्लाइंट और सर्वर कोड का स्वामित्व होना चाहिए कि वे डेटा को सही तरीके से डीकोड करेंगे। – Mike
यह मेरे लिए पृष्ठ पर सबसे अच्छा जवाब था क्योंकि मैं एक ऐसे कारण की तलाश कर रहा था जो अभी भी लागू होता है भले ही कोई व्यवस्थापक सभी उपयोगकर्ता नामों को नियंत्रित फैशन में आवंटित करता हो। हम वास्तव में अभी भी बेसिक ऑथ का उपयोग कर रहे हैं ... मुझे लगता है कि यह हमें भविष्य में इसे छोड़ने का कारण बताता है। – Trejkaz
जबकि आप आगे बढ़ सकते हैं और यूनिकोड की अनुमति दे सकते हैं, समझें कि कुछ उपयोगकर्ता नाम एक ही पात्रों के लिए विभिन्न नियमों को लागू करने वाली विभिन्न संस्कृतियों के लिए अपेक्षित धन्यवाद के रूप में काम नहीं करेंगे।
मामले sensivitity को तोड़ने के लिए बुनियादी मामले पर विचार करें: तुर्की में, उपयोगकर्ता नाम "ID1" और "ID1" हैं अलग (तुर्की में दो अलग-अलग, एक बिंदु के साथ एक और बिना एक है, 2 पूंजी में जिसके परिणामस्वरूप देखते हैं और 2 छोटे अक्षरों जो अंग्रेजी के समान कैप्चरलाइजेशन नियमों से मेल नहीं खाते हैं)। इसलिए जब कोई भी तुर्की व्यक्ति अपनी भाषा में अपना नाम दर्ज कर सकता है, तो कार्यक्रम उनके नाम का इलाज नहीं करेगा जैसा कि वे उम्मीद करते हैं - इसके बजाय यह उत्परिवर्ती अंग्रेजी में एक अजीब परिवर्तन से गुज़र जाएगा।
यूरोपीय भाषाओं में विशेष लैटिन वर्णों में समान ओवरलैप होते हैं, जिससे यह यादृच्छिक रूप से यादृच्छिक होता है कि उन्हें किस भाषा में प्रवेश किया जा रहा है। दुनिया के अन्य क्षेत्रों में समान साझा वर्ण हैं जहां उपयोग के नियम अलग-अलग हैं - कुछ मामलों में राष्ट्रीय और सांस्कृतिक नफरत के परिणामस्वरूप बहुत गुस्सा लोग हो सकते हैं जब उनके उपयोगकर्ता नाम बनाने वाले पात्रों को इस तरह माना जाता है कि यह उनके घृणित दुश्मन की भाषा में लिखा गया था (क्योंकि उन विदेशी पात्रों के लिए ऑपरेटिंग सिस्टम डिफ़ॉल्ट सेटिंग है)।
तो, हमें पीएसपी (राजनीति संवेदनशील प्रोग्रामिंग) की आवश्यकता है। हमारे लिए बाहर निकलने के लिए यूनिकोड कंसोर्टियम पर शर्म आती है। ☺ –
आपका अवलोकन हमेशा सत्य नहीं है।और, ASCII की पसंद तकनीकी या सुरक्षा मुद्दों के बजाय काफी हद तक मानव कारक है।
अधिकांश मामलों में, यह केवल प्रोग्रामिंग की आसानी के लिए है। एक प्रोग्रामर कभी नहीं जानता कि वेबसाइट में सभी सॉफ्टवेयर, पुस्तकालय, उपयोगिताएं कुछ पात्रों के साथ टूट जाएंगी या नहीं। एएससीआईआईआई अच्छी तरह से काम करते समय वेबसाइट विकास का जोखिम क्यों उठाता है? इसके अलावा, कुछ पैक किए गए वेब सॉफ़्टवेयर उपयोगकर्ता नाम में यूनिकोड के उपयोग में बाधा डालते हैं। यह इस मुद्दे को योगदान देता है कि कई वेबसाइटें केवल ASCII में उपयोगकर्ता नामों का समर्थन करती हैं।
सैद्धांतिक रूप से, सभी मौजूदा सॉफ्टवेयर 8-बिट डेटा को अच्छी तरह से संभाल सकते हैं। आजकल भंडारण या संचरण में कोई समस्या नहीं है। यहां तक कि अगर कुछ प्रोटोकॉल नहीं हैं, तो वे यूटीएफ -7 में या अन्य परिवर्तन योजनाओं के साथ अनुवाद कर सकते हैं।
यूनिकोड के साथ कुछ समस्याएं हैं। यह डेटा प्रोसेसिंग के पक्ष में अधिक है। यह गैर-बीएमपी पात्रों, संयोजन, तुलना, इनपुट विधियों, लेखन दिशाओं के लिए सॉफ्टवेयर, सॉफ्टवेयर और सॉफ्टवेयर पुस्तकालयों की डिस्प्ले, फोंट, तैयारी हो सकती है। व्यवस्थापक उन्हें संभालने के लिए पर्याप्त जानकारी नहीं दे सकते हैं। वेबसाइट की प्रकृति के आधार पर, यह एक समस्या हो सकती है, लेकिन ज्यादातर नहीं।
व्यवस्थापक उद्देश्य के लिए, कुछ विदेशी पात्रों को टाइप करना आसान नहीं है। यह उपयोगकर्ताओं को खोजने के लिए व्यवस्थापक को कड़ी मेहनत करता है। एक व्यवस्थापक के लिए वेबसाइट से विदेशी भाषाओं में आपत्तिजनक उपयोगकर्ता नाम रखने के लिए भी मुश्किल है।
हालांकि, यह असामान्य नहीं है कि चीनी उपयोगकर्ता नाम चीनी वेबसाइट का उपयोग किया जाता है। यह हमेशा ASCII में नहीं हो सकता है। तो अन्य संस्कृतियों और भाषाओं को करो। कुछ वैश्विक परियोजनाएं सभी प्रकार के यूनिकोड वर्णों को निकटता से स्वीकार करती हैं। विकिपीडिया एक उदाहरण है।
या, हम उपयोगकर्ता नाम की तरह दिखने के बारे में एक बकवास देना बंद कर सकते हैं, और क्या हम इसे उच्चारण/याद कर सकते हैं। यह यूएसर्स चिंता होना चाहिए। अगर कोई आपको याद नहीं करता है, तो यह तुम्हारा नुकसान है। और, नाम स्पूफिंग के लिए, यह किसी भी मामले में लगभग अपरिहार्य है। और फिर भी, शायद ही कभी आप उपयोगकर्ता नाम स्पूफ के बारे में सुनते हैं।
एक फोरम की कल्पना करें, किसी ऐसे खाते के साथ किसी पोस्ट की कल्पना करें जो आपके जैसा दिखता है। आपको परेशानी हो रही है, कहें कि आपने ऐसा नहीं किया है, अपने इतिहास के लिए एक लिंक पोस्ट करें, देखें कि पोस्ट वहां नहीं है। उस व्यक्ति की प्रोफ़ाइल पर क्लिक करें जिसने इसे वास्तव में पोस्ट किया है, और बाम, आपके पास उसकी प्रोफ़ाइल है। वह अब बैनबल है।
एक ही नाम होने का मतलब यह नहीं है कि आपके पास एक ही उपयोगकर्ता डेटा है। कोई भी एप्लिकेशन जो आपके लिए दो समान उपयोगकर्ताओं को अंतर करने में आसान बनाता है, वैसे भी खराब है और उसे फिर से लिखना होगा।
यह प्रश्न का उत्तर नहीं देता है। यह अन्य उत्तरों में से एक के तहत एक टिप्पणी के रूप में बेहतर होगा। –
हालांकि यह बिल्कुल संदिग्ध है कि उपयोगकर्ता की पहचान करने के लिए कभी भी उपयोगकर्ता नाम क्यों नहीं होना चाहिए, मुझे लगता है कि यूनिकोड उपयोगकर्ता नामों को अस्वीकार करने का कोई कारण नहीं है।
क्या अधिक महत्वपूर्ण है, यह पासवर्ड लैंगुगेज-अज्ञेयवादी के रूप में सत्यापित किया जाना चाहिए: इसे उपयोगकर्ता की कीबोर्ड सेटिंग के बावजूद कीस्टोक का इलाज करना चाहिए। इसका मतलब है, "שלום" और "अकुओ" एक ही पासवर्ड होगा। यह महत्वपूर्ण है, क्योंकि उपयोगकर्ता अक्सर टाइप करने वाले पासवर्ड वर्ण नहीं देखता है, और यदि कैप्लॉक चालू है तो वे गंभीर रूप से पेश हो रहे हैं।
यह बहुत बढ़िया लगता है लेकिन मैं एक ऐसी प्रणाली देखना चाहता हूं जो विश्वसनीय रूप से ऐसा कर सके ... कहें कि आपका आईएमई एक ऐसा है जो चीजों को एक गैर-परिवर्तनीय फैशन में परिवर्तित कर सकता है। उदाहरण के लिए, 缶 用 で シ プ ェ आर て ぃ एस? – Trejkaz
मैं वोट देता हूं यह समुदाय विकी होना चाहिए। लगता है जैसे कुछ अच्छी चर्चा शुरू हो रही है। – jtbandes
यदि आप अपने कोड की सुरक्षा की परवाह करते हैं, तो आपको कहीं भी यूनिकोड की अनुमति नहीं देनी चाहिए (जब तक कि आप एक मासोचिस्ट ** और ** एक यूनिकोड विशेषज्ञ ** नहीं हैं ** और ** आप अकेले हैं जिन्हें कभी भी बनाए रखना होगा कोड) –
@ L̳o̳̳n̳̳g̳̳p̳o̳̳k̳̳e̳̳, वास्तव में अंतिम बिंदु "** और ** रखरखाव भी योग्य होना चाहिए (1) और (2)।" – Pacerier