क्या फ़ाइल नामकरण में बड़े अक्षरों का उपयोग नहीं करना सबसे अच्छा अभ्यास माना जाता है?

Question

लोग कहते हैं कि आपको यूनिक्स फ़ाइल नामकरण में रिक्त स्थान का उपयोग नहीं करना चाहिए। क्या फ़ाइल नामों (अर्थात, File_Name.txtबनाम file_name.txt) में बड़े अक्षरों का उपयोग नहीं करने के अच्छे कारण हैं ? या यह सिर्फ व्यक्तिगत पसंद का मामला है?

Comments

आप कैप का उपयोग कर सकते हैं लेकिन मानक के रूप में इसका उपयोग नहीं करते हैं। बस छोटे अक्षरों का उपयोग करें और _ इसलिए file_name.txt अच्छा है।

— शाबिर ए।

कुछ Unixy चीजें हैं जो बड़े अक्षरों के साथ फ़ाइल नाम का उपयोग करती हैं ... कुछ उदाहरणों में Makefile, INSTALL, CHANGELOG और निश्चित रूप से आदरणीय README शामिल हैं।

— थॉमस

PSR-2 - PHP की दुनिया का वास्तविक नामकरण मानक, जो लिनक्स पर बहुमत से चलता है, camelCase php-fig.org/psr/psr-2

— jdog

Answer 1

लोग कहते हैं कि आपको यूनिक्स फ़ाइल नामकरण में स्थान नहीं चाहिए।

लोग बहुत सी बातें कहते हैं। कुछ उपकरण हैं जो खराब हो सकते हैं, लेकिन उम्मीद है कि वे इस समय इस संख्या में कम हैं, क्योंकि रिक्त स्थान विशाल उपभोक्ता स्वामित्व वाले ओएस कॉर्पोरेशन्स द्वारा फैलाया गया वायरस है और अब बचना असंभव है।

रिक्त स्थान कमांड लाइन पर फ़ाइल नाम निर्दिष्ट करते हैं, आदि, अजीब। यह इसके बारे में। * Nix सिस्टम पर केवल स्पष्ट रूप से निषिद्ध वर्ण NUL हैं (चिंता न करें, यह आपके कीबोर्ड, या किसी और के पर नहीं है) और /, क्योंकि यह पथ विभाजक है। ¹ इसके अलावा कुछ भी हो जाता है। व्यक्तिगत पथ तत्व (फ़ाइल नाम) 255 बाइट्स तक सीमित हैं (एक संभावित जटिलता यदि आप विस्तारित चरित्र सेट का उपयोग कर रहे हैं) और 4 kB को पूर्ण पथ।

या यह सिर्फ व्यक्तिगत पसंद का मामला है

मैं कहूंगा कि यह है। अधिकांश डे के दशक में अपने पूंजीकृत निर्देशिका के एक धसान बनाने के लिए लग रहे हैं $HOME( Downloads, Desktop, Documents- D, बहुत लोकप्रिय है) तो इसके बारे में कुछ भी नहीं विचित्र नहीं है। उनमें राजधानियों के साथ बहुत आम पारंपरिक फाइलें भी हैं, जैसे .Xclientsऔर .Xauthority।

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

मैं ऊँट के मामले का एक प्रशंसक हूँ (उर्फ। कैमलकेस) और इसका उपयोग फ़ाइल नाम के साथ करता हूँ, उदाहरण के लिए, /home/goldilocks/blueSuedeShoes- कोई बात नहीं कि वहाँ क्या है। निश्चित रूप से व्यक्तिगत पसंद की बात है लेकिन इसने मुझे दु: ख पहुंचाना अभी बाकी है।

जावा वर्ग की फाइलें प्रकृति द्वारा राजधानियों को समाहित करती हैं, क्योंकि जावा वर्ग के नाम हैं। और हां, हम भूल नहीं सकते NetworkManager, भले ही हम में से कुछ पसंद करेंगे।

---

^{1. एक बहुत अधिक सीमांकित है, जो POSIX द्वारा सुझाया गया है "पोर्टेबल फ़ाइलनाम चरित्र सेट" जिसमें स्थान शामिल नहीं है - लेकिन इसमें ऊपरी मामला शामिल है! POSIX एक ही दस्तावेज़ में कहीं और "स्लैश चरित्र और अशक्त बाइट" के बारे में अधिक सामान्य प्रतिबंध को निर्दिष्ट करता है । यह लंबे समय से चली आ रही पारंपरिक प्रथाओं को दर्शाता है, या परिलक्षित होता है ।}

Comments

मिया: "क्या यह एक तथ्य है?" विन्सेन्ट: "नहीं यह नहीं है, यह वही है जो मैंने सुना है।" मिया: "यह आपको किसने बताया?" विंसेंट: "वे।" Mia: "वे बहुत बात करते हैं न?" विन्सेन्ट: "वे निश्चित रूप से करते हैं।"

— corsiKa

" मूल्य शुरुआत में कुछ बड़े अक्षरों में की है कि जब कोषगत सूचीबद्ध [...], वे सब कुछ पहले आया हूँ है।" - बेशक, यह तभी काम करता है सबसे फ़ाइल नामों की लोअरकेस कर रहे हैं, आप के लिए एक कारण दे आरक्षित टोपियां ( कम से कम प्रमुख टोपियां) आपके लिए READMEऔर Makefileएस और इतने पर।

— ब्लैकलाइट शाइनिंग

कई कीबोर्ड पर, ctrl-space या ctrl- @ या alt-0 एक NUL टाइप करेगा।

— डबियसजिम

@dodgethesteamroller मुझे विश्वास है कि आप फ़्लैट-आउट गलती से फ़ॉरवर्ड स्लैश (या अधिक सटीक, बाइट 0x2F के साथ) के बारे में गलत हैं । वास्तव में, मुझे विश्वास नहीं है कि यह फाइलसिस्टम को भी मिलेगा; VFS परत बैकिंग स्टोर की परवाह किए बिना इसे अस्वीकार कर देगी।

— zwol

सिर्फ फ़ाइल नाम और निर्देशिका नामों में रिक्त स्थान का उपयोग न करें। यहां तक ​​कि अगर आपका सिस्टम तकनीकी रूप से इसकी अनुमति देता है, तो यह केवल आपके दुःख का कारण होगा। इसके बजाय अंडरस्कोर वर्ण "_" का उपयोग करें।

— स्नेकडोक

Answer 2

फाइलनाम में कैप से बचने का एक कारण यह है कि यूनिक्स में सॉर्टिंग ऑर्डर संवेदनशील है, इसलिए कैपिटल लेटर से शुरू होने वाली फाइलें ऑर्डर से बाहर हो जाएंगी। यही कारण है कि Makefileआम तौर पर एक पूंजी का उपयोग करके नाम दिया जाता है M- यह उन फ़ाइलों में से एक है जिसे आप पहले देखना चाहते हैं, बिना गर्त नीचे स्क्रॉलिंग / स्किपिंग के a-l।

इसने कहा, आप फ़ाइल नामों के मामले में बहुत बुरा कर सकते हैं:

• रिक्त स्थान का उपयोग करने से कुछ बुरी तरह से लिखे गए प्रोग्राम और स्क्रिप्ट टूट जाएंगे जो फ़ाइल नामों को ठीक से उद्धृत नहीं करते हैं
• फ़ाइल नाम शुरू करने से -समस्याएँ हो सकती हैं क्योंकि कई प्रोग्राम इसे फ़ाइल नाम के बजाय कमांड-लाइन विकल्प के रूप में देखेंगे (जैसे नाम वाली फ़ाइल rm -rको नहीं हटाएगा -r)।
• .वसीयत के साथ एक फ़ाइल नाम शुरू करना कई उपयोगिताओं और शेल ग्लोबिंग से छिपाएगा (जैसे rm *फाइलें नहीं निकालेगा .config)
• तकनीकी वर्णों जैसे |<>*?और यहां तक ​​कि गैर-मुद्रण योग्य वर्णों का उपयोग newlineकरना तकनीकी रूप से संभव है, लेकिन अंतरिक्ष वर्ण के समान स्क्रिप्ट / कार्यक्रमों को तोड़ सकता है। अंतर यह है कि अंतरिक्ष चरित्र का उपयोग अक्सर किया जाता है, इसलिए प्रोग्रामर इसके खिलाफ अपने कार्यक्रमों का परीक्षण करते हैं, जबकि कम लोकप्रिय चरित्र अक्सर अप्रयुक्त रहते हैं।

Comments

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

— स्टीफन चेज़लस

क्या आपके कहने का मतलब है: rm *फाइलों को नहीं हटाया जाएगा .config?

— वाइल्डकार्ड 15

@Wildcard वास्तव में नहीं है, लेकिन शायद आपका उदाहरण मेरी तुलना में अधिक यथार्थवादी है। मेरा कहना यह था कि एक डॉट के साथ शुरू होने वाले फ़ाइलनाम ग्लोबिंग के लिए प्रतिरक्षा हैं, भले ही उपयोगकर्ता उस डॉट को स्पष्ट रूप से निर्दिष्ट करता हो।

— दिमित्री ग्रिगोरीव

@DmitryGrigoryev, नहीं, वे नहीं हैं। Ls -ald कोशिश करें। * * किसी भी डायरेक्टरी में जिसमें डॉट फाइलें हों।

— बिल बर्थ

मेरा मानना ​​है कि यह कहना अधिक उपयुक्त होगा "यदि आप फ़ाइल नामों में बड़े अक्षरों का उपयोग करना चाहते हैं, तो आपको इस तथ्य को ध्यान में रखना चाहिए कि यूनिक्स में क्रमबद्धता (कभी-कभी) मामला संवेदनशील है।" उपयोगकर्ता इस व्यवहार को चाह सकता है, Makefileऔर READMEइसके आदर्श उदाहरण हैं। यह भी ध्यान दें कि यदि नाम में पहला अक्षर नहीं है, तो यह प्रभाव नगण्य है, इसलिए यदि आप कैमकोर्डर का उपयोग करते हैं तो यह कोई बड़ी बात नहीं है। निश्चित रूप से, आपको anOctagonपहले देखकर आश्चर्य हो सकता है angle, लेकिन कम से कम वे लिस्टिंग में एक साथ होंगे।

— जी-मैन का कहना है कि 'मोनिका'

Answer 3

यदि आप Windows वातावरण के साथ इंटरफ़ेस करने जा रहे हैं, तो आपको राजधानियों से बचना चाहिए क्योंकि Windows सब कुछ कम कर देगा। यह अक्सर दूसरी तरह से जाने वाली समस्या है; विंडोज में Page_2.htmlखोजने के लिए एक लिंक page_2.html, लेकिन यूनिक्स में विफल हो जाएगा।

Comments

यह सच नहीं है। NTFS, VFAT, और exFAT सभी केस-असंवेदनशील लेकिन केस-संरक्षण हैं, जिसका अर्थ है कि वे लुकअप के उद्देश्यों के लिए मामले को अनदेखा करते हैं, लेकिन फिर भी केस को स्टोर करते हैं । OSX पर डिफ़ॉल्ट फ़ाइल सिस्टम HFS + पर भी यही लागू होता है। NTFS के पास भी एक POSIX नाम स्थान है, जो अन्य सभी यूनियनों की तरह ही काम करता है , यानी बिना व्याख्या वाले ऑक्टेट के बहुत लंबे फ़ाइलनाम, केवल NULऔर /निषिद्ध के साथ।

— जोर्ग डब्ल्यू मित्तग

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

— dodgethesteamroller

@ JörgWMittag जब तक मैं गलत नहीं हूँ, NTFS केस-असंवेदनशील नहीं है, यह सिर्फ इतना है कि विंडोज़ रहस्यमय तरीके से काम करती है।

— Cthulhu

@Cthulhu: AFAIK, NTFS में चार अलग-अलग नामस्थान हैं जिनमें आप फ़ाइलों के लिए नाम बना सकते हैं। (मुझे नहीं पता कि किसी एकल फ़ाइल में एक से अधिक नामस्थानों में कोई नाम हो सकता है।) एक "DOS" नाम स्थान (8.3, केस-असंवेदनशील), एक "लंबा" नाम स्थान (केस-असंवेदनशील, केस-प्रोटेक्टिंग)। UTF-16), "शॉर्ट लॉन्ग" नामों के लिए एक विशेष नामस्थान, अर्थात ऐसे नाम जिनके मामले को संरक्षित किया जाना चाहिए, लेकिन यह 8.3 में फिट होता है, और एक POSIX नाम स्थान (ऑक्टेट्स की एक धारा \0और /, केस-संवेदी)। कम से कम यह है कि मुझे यह कैसे याद है। लेकिन मैं मानता हूं कि यह एक गड़बड़ है। आगे भी प्रतिबंध हैं ...

— Jörg W Mittag

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

— जोर्ग डब्ल्यू मित्तग

Answer 4

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

Comments

echo set completion-ignore-case On >> ~/.inputrcथोड़ी मदद कर सकते हैं, कम से कम अपने सिस्टम पर।

— wchargin

मैं स्पष्ट नहीं हूं कि इस उत्तर का क्या मतलब है - जब तक कि यह नहीं है कि आप यह भूल सकते हैं कि आपने एक फ़ाइल नाम "वर्तनी" कैसे रखा है। उदाहरण के लिए, यदि आप नाम Fooऔर बाद में टाइप cat f(टैब) फ़ाइल बनाते हैं, तो यह विफल हो जाएगा। लेकिन अगर आप टाइप करते हैं तो वही बात होती है cat foo, cat Foobarया cat Fu- यह तथ्य कि आपको एक ऐसी फाइल तक पहुंचने में परेशानी होगी, जिसका नाम आपको ठीक से याद नहीं है, इसका वास्तव में स्वत: पूर्णता से कोई लेना-देना नहीं है।

— जी-मैन का कहना है कि 'मोनिका' को

@ जी-मैन टच। फिर भी, सभी-निचले फ़ाइल नाम का उपयोग करने का मतलब है कि आपके पास उनके बारे में याद रखने के लिए एक कम चीज है।

— ब्लैकलाइट शाइनिंग

Answer 5

चूंकि NL_Derek ने कीड़े के इस डिब्बे को खोला, लेकिन इसे ठीक से व्यक्त नहीं किया, इसलिए मैं यह कहूंगा:

बड़े अक्षरों का उपयोग करना ठीक है, लेकिन आपको फ़ाइलें (उसी निर्देशिका में) बनाने से बचना चाहिए जो केवल मामले से भिन्न हों , उदाहरण के लिए, File_Name.txt और file_name.txt ,

• यदि आप किसी तरह निर्देशिका को विंडोज सिस्टम के लिए उपलब्ध कराते हैं, तो यह दोनों फाइलों को एक्सेस नहीं कर पाएगा। यह संभवतः केवल उसी को एक्सेस करने में सक्षम होगा जो पहले निर्देशिका में दिखाई देता है, चाहे आप किस नाम का उपयोग करें। (सिवाय इसके: यह आपको उनके रूप में पहुँच प्रदान कर सकता है FILENA~1.TXTऔर FILENA~2.TXT - dir /xयह देखने के लिए कि संक्षिप्त नाम (यदि कोई हो) किस लंबे नाम के साथ जाता है।)
• यदि फ़ाइल सिस्टम वास्तव में एक विंडोज फाइल सिस्टम है (उदाहरण के लिए, विंडोज चलाने वाले एनएफएस सर्वर से एक्सफैट या एनटीएफएस फाइल सिस्टम से माउंट किया गया है), तो दो नामों को (शायद) सह-अस्तित्व की अनुमति नहीं दी जाएगी। उदाहरण के लिए, यदि आप करते हैं और , आप एक फ़ाइल के साथ समाप्त कर सकते हैं, जिसमें से आउटपुट है ।cmd1 > foocmd2 > Foocmd2
• इसी तरह, यदि आप कभी भी एक विंडोज सिस्टम में फाइल ट्रांसफर करते हैं, तो दो नामों को (शायद) सह-अस्तित्व के लिए अनुमति नहीं दी जाएगी। उदाहरण के लिए, यदि आपने दो फ़ाइलों से युक्त एक संग्रह (जैसे, ज़िप) बनाया है, और इसे विंडोज सिस्टम पर निकाला है, तो दूसरी फाइल संभवतः पहले वाले को अधिलेखित कर देगी। एक ही बात अगर आप उन्हें एफ़टीपी या कुछ इसी तरह एक विंडोज बॉक्स में स्थानांतरित कर दिया।

Comments

न केवल विंडोज, बल्कि कई अन्य ओएस (वीएमएस, मुझे लगता है, सीपी / एम निश्चित रूप से, अन्य ...)

— टोबी स्पाइट

Answer 6

तकनीकी कारणों के अलावा, मेरे पास इसका एक व्यावहारिक पहलू है। अक्षरों को नीचे करने से यह सुनिश्चित होगा कि खोज तब तक आसान है जब तक कि कोई grep -i या find -i का उपयोग करने का शौकीन न हो। कभी-कभी, कैमकलेस भी भ्रामक हो सकता है यदि किसी को स्टोरेज वाईएनसीडीसीरीरी की तरह केस-केस शब्दों का उपयोग करना है। इसलिए, मुझे स्टोरेज_एनसी_डेक_प्रिमरी की तरह पठनीयता के लिए अंडरस्कोर या हाइफ़न से चिपके रहना और उन्हें पेस्ट करना सबसे अच्छा लगता है।

Comments

snake_case आँखों पर आसान है - storageNycDcPrimaryऔर StorageNycDcPrimaryदोनों पढ़ने के लिए अजीब हैं।

— go2null

Answer 7

मैं मानता हूं कि फ़ाइल नाम में राजधानियों और स्थानों का उपयोग करने से बचना सबसे अच्छा अभ्यास है ।

कुछ कहेंगे कि वे सहमत नहीं हैं, लेकिन यह एक मामला है या जिसे मैं धार्मिक विश्वास कहता हूं : चर्चा करना और सहमत होना मुश्किल है। सहमत नहीं होने वालों का कहना है कि अधिकांश उपकरण अब राजधानियों और स्थानों के अनुकूल होने के लिए तय किए गए हैं: वे सही हैं लेकिन यह सवाल नहीं है।

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

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

और एक आखिरी बात, यदि आप सभी समस्याओं से बचना चाहते हैं , तो फ़ाइल नाम में कोई विशेष वर्ण नहीं है (केवल निचले मामले के अक्षर, अंक, अंडरस्कोर और मिनस [1])। इस अनचाही चरित्र सूची में सभी गैर अस्सी के अक्षर भी शामिल हैं (हाँ, फ्रेंच और अन्य गैर अंग्रेजी लोग - और मैं उनमें से एक हूं - इनमें से कोई नहीं: à, â, ä, ç, é, ..., ö, includes, includes) , ...)। यह लॉगिन और पासवर्ड सहित कई अन्य चीजों तक भी फैला हुआ है । मैं आपको अनुमान लगाता हूं कि जब आप एक बोली या दोहरी बोली ( 'या ") एक लॉगिन या पासवर्ड में डालते हैं तो क्या होता है जो किसी पुष्ट स्क्रिप्ट द्वारा लिखित नहीं है।

[1]: शायद हम विस्तार कर सकता है कि करने के लिए ~, @, #और कुछ अन्य, लेकिन इस मुसीबत की तलाश में है (और हाँ मैं Emacs फ़ाइलों के बारे में पता है ...)।

Comments

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

— ब्लैकलाइट शाइनिंग

ठीक है, पासवर्ड में वर्णों को सीमित करना बहस का विषय है: li1, oO0, ... शौकीन के आधार पर, संवाद करने में मुश्किल। कुछ कहते हैं कि पासवर्ड का संचार नहीं किया जाना चाहिए, लेकिन एक वाईफाई कुंजी एक प्रकार का पासवर्ड है जो मैं अपने दोस्तों से संवाद करता हूं जब वे मेरी जगह पर होते हैं ...

— jfg956

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

— ब्लैकलाइट उदय