लोकेल के अनुसार नाम डेटा वह जगह है जहां एक तटस्थ दिखने वाला फ़ॉर्म डिज़ाइन पकड़ा जाता है कि वह दुनिया के किसी एक हिस्से के लिए लिखा गया था। धारणा लगभग हमेशा वही रहती है — कि व्यक्ति का पहले एक दिया हुआ नाम होता है और बाद में उपनाम, इसी क्रम में, लैटिन लिपि में, बीच में एक स्पेस के साथ — और इस वाक्य का हर हिस्सा कहीं न कहीं गलत साबित होता है।
यह गाइड उन संरचनात्मक अंतरों से गुज़रती है जो तब मायने रखते हैं जब डेटा दिखाया नहीं, सहेजा जाता हो, और बताती है कि नाम फ़ील्ड को अंतरराष्ट्रीय कहने से पहले टेस्ट सूट में क्या-क्या होना चाहिए।
नाम किन चीज़ों से बनता है यह बदलता रहता है
व्यक्तिगत नाम बनाने वाले टुकड़े सार्वभौमिक नहीं हैं, और उनकी संख्या भी नहीं। आम बनावटों में शामिल हैं एक दिया हुआ नाम और एक उपनाम, उपनाम का दिए हुए नाम से पहले लिखा जाना, एक या ज़्यादा दिए हुए नाम बिना किसी उपनाम के, दिए हुए नाम के बाद माता या पिता के नाम से निकला पितृ-नाम, और ऐसे संयुक्त उपनाम जिनके हिस्सों के बीच स्पेस या हाइफ़न लिखा जाता है।
इनमें से कोई किसी नियम का अपवाद नहीं है; ये बस अलग नियम हैं। जो फ़ॉर्म पहले नाम और आख़िरी नाम की सोच पर चलता है वह ऐसी बनावट मान लेता है जिसे दुनिया का बड़ा हिस्सा नहीं मानता, और यह धारणा वहां फेल होती है जहां डेटा इस्तेमाल होता है, न कि वहां जहां वह भरा जाता है — किसी अभिवादन में, शिपिंग लेबल पर, क्रम में लगी सूची में, किसी मिलान वाले एल्गोरिद्म में।
कौन सी भाषाएं उपनाम पहले रखती हैं?
कई रखती हैं, और वे छोटा समूह नहीं हैं। पूर्वी एशिया की नाम परंपराएं आम तौर पर उपनाम पहले और दिया हुआ नाम बाद में रखती हैं, और यूरोप के भीतर हंगेरियन भी यही करती है। जब ऐसा नाम ऐसे सिस्टम में दर्ज होता है जो उल्टा क्रम मानता है, तो दोनों हिस्से बदल जाते हैं, और यह बदलाव दिखता नहीं क्योंकि दोनों हिस्से अपने-अपने ढंग से विश्वसनीय व्यक्तिगत नाम हैं।
यह खामी तब गंभीर हो जाती है जब नाम की तुलना किसी दूसरे रिकॉर्ड से होती है या वह किसी दस्तावेज़ पर छपता है। गलत हिस्से को संबोधित चिट्ठी एक छोटी शर्मिंदगी है; सीमा जांच या पहचान दस्तावेज़ पर उलटा नाम क्रम दिखना बिल्कुल अलग श्रेणी की समस्या है, और मशीन द्वारा पढ़े जाने वाले दस्तावेज़ों के अंतरराष्ट्रीय मानक इसी कारणों में से एक हैं।
व्यावहारिक सबक यह है कि क्रम रिकॉर्ड का गुण है, फ़ील्ड का नहीं। हिस्सों को एक तय तरीक़े से सहेजिए, उस लोकेल को भी सहेजिए जो उनका क्रम तय करती है, और प्रारूपण दिखाने के आख़िरी क्षण पर कीजिए, भरने के समय नहीं।
क्या एक-शब्द वाले नाम वैध हैं?
हाँ, और दो नाम फ़ील्ड मांगने वाला फ़ॉर्म किसी असली व्यक्ति को अस्वीकार कर देगा। कई देशों और संस्कृतियों में एक-शब्द वाले नाम कानूनी नाम के रूप में मौजूद हैं, और जिन लोगों के ऐसे नाम हैं उन्हें यह बार-बार झेलना पड़ता है: फ़ॉर्म उपनाम मांगता ही है, इसलिए वे कुछ भी टाइप कर देते हैं, और अब उनसे मिलाए जाने वाला हर दस्तावेज़ उस रिकॉर्ड से मेल नहीं खाता।
यही ढांचा हल्के रूपों में भी दिखता है। कुछ लोगों के कई दिए हुए नाम होते हैं और उन्हें समेटने लायक कोई बीच का नाम फ़ील्ड होता ही नहीं। कुछ लोगों का उपनाम दो शब्दों का होता है जिसे स्पेस पर तोड़ने वाला पार्सर चीर देगा। कुछ के नाम बस एक अक्षर के होते हैं, जो न्यूनतम लंबाई की उन जांचों में अटक जाता है जो तसल्ली के लिए लिखी गई थीं, किसी कारण से नहीं।
सुधार दिखावटी नहीं, ढांचे का है: दूसरे नाम फ़ील्ड को उन देशों के लिए वैकल्पिक चिह्नित कीजिए जहां वह वैकल्पिक है, या इससे बेहतर, पूरे नाम को एक मान की तरह लेकर उसके साथ वैकल्पिक हिस्सा फ़ील्ड रखिए जो डिफ़ॉल्ट रूप से कभी अनिवार्य न हों। सत्यापन को वह अस्वीकार करना चाहिए जो असंभव है, वह नहीं जो बस अपरिचित है।
किसी और लिपि वाले नाम का क्या होता है?
दो चीज़ें होती हैं, और अक्सर उन्हें आपस में मिला दिया जाता है। पहली है लिप्यंतरण: एक लेखन प्रणाली में लिखे नाम को दूसरी में बदलना, जो ऐसा मानचित्रण है जिसमें असली चुनाव छिपे होते हैं और एक से ज़्यादा स्वीकृत परंपराएं चलती हैं। दूसरी है सामान्यीकरण: यह तय करना कि एक जैसे दिखने वाले दो स्ट्रिंग वाकई एक हैं या नहीं, जो सहेजने और तुलना करने का सवाल है।
बिंदु-चिह्न दोनों में मायने रखते हैं। बिंदु-चिह्न वाला नाम उसी नाम से बिना बिंदु-चिह्न के अलग स्ट्रिंग है, और यह कि दोनों को बराबर माना जाए या नहीं, इस पर निर्भर है कि आप क्या कर रहे हैं। दो रिकॉर्ड मिलाते समय आम तौर पर बिंदु-चिह्नों को नजरअंदाज़ करना चाहिए; दस्तावेज़ छापते समय बिंदु-चिह्न कभी नहीं हटाने चाहिए। क्रम-निर्धारण यानी नाम किस क्रम में लगेंगे, वह भी भाषा-विशेष होता है, इसलिए सर्वर के डिफ़ॉल्ट लोकेल से क्रम में लगी सूची उस क्रम में नहीं होगी जिसकी उस भाषा का पाठक अपेक्षा करता है।
अक्षरों का छोटा-बड़ा रूप जितना दिखता है उससे ज़्यादा बारीक है। किसी नाम को पूरी तरह बड़े अक्षरों में बदलने से कुछ भाषाओं में उसकी लंबाई बदल सकती है, और कुछ अक्षर जोड़े ऐसे हैं जिनके बड़े रूप भाषा के हिसाब से अलग होते हैं। जो नाम फ़ील्ड दिखाने के लिए बड़े अक्षरों में बदलकर नतीजा सहेज लेता है, वह ऐसी जानकारी नष्ट कर देता है जिसे वह दोबारा बना नहीं सकता।
एन्कोडिंग की दिक्कतें बार-बार क्यों उभरती हैं
दो स्ट्रिंग स्क्रीन पर बिल्कुल एक जैसी दिख सकती हैं और फिर भी बराबर नहीं होतीं, क्योंकि बिंदु-चिह्न वाले अक्षर को या तो एक पहले से जुड़े अक्षर के रूप में लिखा जा सकता है या आधार अक्षर के बाद जोड़ने वाले चिह्न के रूप में। दोनों वैध हैं, दोनों एक ही तरह दिखते हैं, और बाइट-दर-बाइट तुलना झूठ लौटाती है।
यही समस्या हर उस मौक़े पर आती है जब टेक्स्ट ऐसे सिस्टमों के बीच जाता है जिनकी यह धारणा अलग हो कि कोई पहचानकर्ता क्या दर्शाता है। टिकाऊ हल यह है कि सीमा पर सामान्यीकरण किया जाए — जब डेटा अंदर आए, जब उसकी तुलना हो, और जब उसे बाहर भेजा जाए — और एक तय रूप इस्तेमाल हो, न कि जो भी रूप आ पहुंचा हो।
इसी वजह से टेस्ट सूट में गैर-लैटिन और बिंदु-चिह्न वाले नाम होना ज़रूरी है। पूरी तरह सादे लैटिन नामों से बना फिक्स्चर हर जांच पास कर लेगा जबकि प्रोडक्शन डेटा चुपचाप उनमें से तीन तोड़ रहा होगा। पहचान और टेस्ट डेटा जनरेटर से बने रिकॉर्ड देश-दर-देश चुने जाते हैं और उस देश की नाम परंपराएं लिए होते हैं, जिससे यह कवरेज करना सुविधाजनक हो जाता है; ये केवल टेस्टिंग के लिए बने काल्पनिक नाम हैं और किसी के नहीं हैं।
नाम फ़ील्ड की बनावट कैसी होनी चाहिए?
शुरुआत इससे कीजिए कि डेटा किस काम आता है और वहां से पीछे चलिए। ज़्यादातर सिस्टमों को नाम दिखाना, नाम क्रम में लगाना और नाम खोजना होता है, और इनमें से किसी काम के लिए ज़रूरी नहीं कि नाम भरने के समय ठीक दो हिस्सों में बंटा हो।
- एक ही दिखाने वाला फ़ील्ड नाम को वैसे रखता है जैसे वह पढ़ा जाना चाहिए, उस क्रम में जो रिकॉर्ड का लोकेल तय करता है।
- अलग हिस्सा फ़ील्ड वैकल्पिक हों और दोनों कभी एक साथ अनिवार्य न हों; जो फ़ॉर्म उपनाम पर ज़ोर देता है वह अंतरराष्ट्रीय नहीं है।
- रिकॉर्ड पर लोकेल या लिपि का चिह्न होने से आगे प्रारूपण और क्रम-निर्धारण सही चुनाव कर पाते हैं।
- लंबाई की सीमाएं उदार रखिए, क्योंकि असली नाम किसी भी विशिष्टि में दिए उदाहरणों से लंबे होते हैं।
- खोज सामान्यीकृत रूप पर चले, जबकि सहेजा गया मान अपने मूल अक्षर बनाए रखे।
इस बनावट की क़ीमत एक अतिरिक्त कॉलम है और इससे खामियों की पूरी श्रेणी हट जाती है। यह नाम को उस परत द्वारा चुपचाप बदले जाने से भी रोकती है जो उसे सबसे पहले छूती है।
डेवलपर्स के लिए: फ़ील्ड, क्रम और तुलना
नाम को एक स्पष्ट मालिक वाली छोटी संरचना की तरह मॉडल कीजिए। जो हिस्से आपको मिले उन्हें सहेजिए, साथ में वह क्रम भी जिसमें वे आते हैं, और दिखाने वाली स्ट्रिंग मांग पर निकालिए। अक्षरों के छोटे-बड़े रूप बदलने या बिंदु-चिह्न हटाने का नतीजा कभी न सहेजिए; मूल सहेजिए और तुलना के लिए उसकी एक प्रतिलिपि सामान्यीकृत कीजिए।
फिक्स्चर के लिए, और साधारण आकार जोड़ने के बजाय वे आकार शामिल कीजिए जो धारणाएं तोड़ते हैं: एक-शब्द वाला नाम, पहले रखा गया उपनाम, हाइफ़न से जुड़ा संयुक्त नाम, जोड़ने वाले चिह्न वाला बिंदु-चिह्न नाम, और एक अक्षर लंबा नाम। ये पांच ऐसी खामियां पकड़ते हैं जो सौ साधारण नाम भी नहीं पकड़ेंगे।
फिर वे दो काम जांचिए जो लोग भूल जाते हैं। क्रम-निर्धारण मशीन के नहीं, रिकॉर्ड के लोकेल के हिसाब से होना चाहिए, और काट-छांट उस सबसे लंबे नाम पर जांची जानी चाहिए जो डेटा में वाकई मौजूद है, क्योंकि जो बनावट विशिष्टि के हर उदाहरण में फ़िट हो जाए, वह इस बात का सबूत नहीं कि वह डेटाबेस में फ़िट होगी। टेस्ट फिक्स्चर में हर नाम सॉफ़्टवेयर टेस्टिंग के लिए गढ़ा गया है, और इस तरह बना कोई रिकॉर्ड किसी असली व्यक्ति की पहचान नहीं है और उसकी जगह नहीं खड़ा होता।
अगले कदम
इस हफ़्ते अपने किसी एक फ़ॉर्म में उपनाम फ़ील्ड वैकल्पिक कीजिए और देखिए कि क्या आगे का कोई हिस्सा उस पर निर्भर है; अगर जवाब हाँ है, तो वह निर्भरता ही खामी है। फिर पहचान जनरेटर में कई लोकेल के नाम बनाइए और उन्हें अपने दिखाने, क्रम लगाने और खोजने वाले रास्तों से गुज़ारिए, यह जांचते हुए कि क्रम-निर्धारण सर्वर के बजाय रिकॉर्ड के लोकेल से बदलता है। फ़ील्ड सुसंगतता वाला लेख उन बाकी जोड़ियों को कवर करता है जिनसे इन नामों को मेल खाना है, और तारीख़ों के आकार जन्म तिथि के सीमा मामले में मिलते हैं।