Data format validation (email, number, string, mobile number, name)

Format validation चेक करता है कि भरा हुआ data सही shape का है: एक email में एक @ और उसके बाद एक dot हो, एक Indian mobile 10 digits का हो जो 6 से 9 के बीच शुरू हो, एक नाम सिर्फ़ letters का हो, और एक number field सच में numeric हो, आमतौर पर ^ और $ से anchored एक regular expression से test किया जाता है।

10 min read · 9 cards · 2 checks

Read in: English · हिन्दी · ગુજરાતી


Theory

भरा हुआ है, पर बकवास है

FestConnect अब खाली fields reject करता है। पर sheet फिर भी junk से भरती है: email hello, mobile 12, नाम asdf123। हर field भरी है, तो basic validation pass हो गया, फिर भी कोई भी काम का नहीं है।

अगली layer है format validation: सिर्फ़ 'क्या कुछ है?' नहीं बल्कि 'क्या यह सही shape है?'। एक email को email जैसा दिखना चाहिए; एक mobile दस digits का होना चाहिए; एक नाम letters का होना चाहिए। Shape-checking का सबसे तेज़ tool है regular expression।

Theory

एक stencil जिसमें answer फिट होना चाहिए

एक regular expression valid input की shape में काटा गया एक stencil है। आप user का text इसके ऊपर रखते हैं: अगर यह cut-out में exactly फिट होता है, pass होता है; अगर बाहर निकला कोई भी हिस्सा match नहीं करता, fail होता है। \d{9} exactly नौ digits के लिए एक stencil slot है; ^ और $ stencil के edges हैं, पूरे answer को फिट करने पर मजबूर करते हुए, सिर्फ़ एक कोने को नहीं।

At a glance

Common validation patterns

FieldRulePattern
Mobile (IN)10 digits, 6-9 से शुरू/^[6-9]\d{9}$/
Nameसिर्फ़ letters और spaces/^[A-Za-z ]+$/
Digits onlyएक या ज़्यादा digits/^\d+$/
Email (simple)text @ text . text/^\S+@\S+\.\S+$/

Practical

FestConnect format checks

// pattern.test(value) returns true/false
function checkFormats(name, email, mobile) {
  let namePat   = /^[A-Za-z ]+$/;       // letters + spaces
  let emailPat  = /^\S+@\S+\.\S+$/;     // x@y.z
  let mobilePat = /^[6-9]\d{9}$/;        // 10 digits, 6-9 first

  if (!namePat.test(name))   { alert("Name: letters only"); return false; }
  if (!emailPat.test(email)) { alert("Email looks invalid"); return false; }
  if (!mobilePat.test(mobile)){ alert("Mobile: 10 digits");  return false; }
  return true;
}

console.log(checkFormats("Aditi Shah", "aditi@x.com", "9876543210")); // true
console.log(checkFormats("asdf123",    "hello",       "12"));         // false

// a number field: reject non-numeric
let age = "20";
console.log(!isNaN(Number(age)));   // true

This example runs in Gri-Learn on the web, where you can edit it and see the output.

Think first

^ और $ क्यों?

Mobile pattern /^[6-9]\d{9}$/ है। अगर आप ^ और $ हटा दें, सिर्फ़ /[6-9]\d{9}/ इस्तेमाल करें, input call me 9876543210 today पर क्या ग़लत होगा?

Show the answer

बिना anchors के, pattern तब match करता है जब वे दस digits string में कहीं भी दिखें, तो call me 9876543210 today एक valid mobile की तरह pass हो जाएगा, सारे extra text के साथ भी। ^ match को शुरुआत पर और $ को आख़िर पर pin करता है, पूरी value को exactly एक 10-digit number बनाने पर मजबूर करते हुए, कुछ और नहीं। Anchors 'contains a match' को 'is exactly this shape' में बदल देते हैं, जो validation को चाहिए।

Quiz

कौन सा input Indian mobile pattern /^[6-9]\d{9}$/ को सही तरीक़े से pass करता है?

  1. 9876543210
  2. 1234567890 (1 से शुरू)
  3. 98765 43210 (एक space के साथ)
  4. 98765432 (सिर्फ़ 8 digits)
Show the answer

9876543210

9876543210 exactly 10 digits का है और 9 से शुरू होता है, [6-9] फिर नौ और digits से match करते हुए, शुरू से आख़िर तक anchored (A)। 1234567890 1 से शुरू होता है, जो [6-9] में fail होता है (B)। Space वाला version continuous 10-digit run और $ anchor दोनों तोड़ता है (C)। आठ digits पहले के बाद \d{9} के लिए बहुत कम हैं (D)। Pattern तीनों rules एक साथ लागू करता है: leading digit, exact count, कुछ भी extra नहीं।

Watch out

Format validation traps

1. Anchors missing: ^ और $ के बिना, एक pattern एक substring match करता है, तो junk एक valid chunk के आस-पास sneak कर जाता है।

2. नामों को over-restrict करना: असली नामों में spaces होती हैं (और कभी-कभी dots या hyphens)। सिर्फ़ letters वाला pattern जो spaces रोकता है 'Aditi Shah' reject कर देगा।

3. Client पर भरोसा करना (फिर से): format checks UX बेहतर करते हैं पर एक determined user इन्हें bypass कर देता है, तो server को फिर validate करना ज़रूरी है। यह पूरी unit से चला आ रहा वही rule है।

Formula

FestConnect पूरा हुआ

Journey देखिए: Unit 1 ने HTML+CSS में form और page बनाया, Unit 2 ने Bootstrap से इसे responsive बनाया, Unit 3 ने JavaScript logic और events जोड़े, Unit 4 ने objects और DOM से page को पढ़ा और बदला, और Unit 5 ने register() को हर field validate करने के लिए wire किया, पहले basic फिर format, success पर redirect करने से पहले। वह पूरा round trip, structure से style से behaviour से validation तक, वेब डिज़ाइनिंग है। एक exam में, इसे end to end walk through कर पाना किसी भी अकेली class name से ज़्यादा worth है।

Summary

Key takeaways

  • Format validation भरे हुए data की SHAPE चेक करता है, सिर्फ़ इसकी मौजूदगी नहीं।
  • pattern.test(value) इस्तेमाल कीजिए: email /^\S+@\S+\.\S+$/, name /^[A-Za-z ]+$/, mobile /^[6-9]\d{9}$/, digits /^\d+$/।
  • ^ और $ pattern को पूरी string से anchor करते हैं, 'contains' को 'is exactly' में बदलते हुए।
  • Indian mobile = 10 digits जो 6-9 से शुरू हों; नामों को over-restrict मत कीजिए (spaces allow कीजिए)।
  • Numbers: !isNaN(Number(value)) test कीजिए। Client checks UX के लिए हैं; server को फिर validate करना ज़रूरी है।
  • Memory hook: एक regex एक stencil है जिसमें पूरा answer फिट होना चाहिए।

Study this properly

This page is the lesson to read. In Gri-Learn the same topic is a graded deck: the self-checks are scored and your weak topics are tracked. Free to start.

Start this topic

Already have an account? Sign in

More from JavaScript Functions

Gri-Learn · syllabus-mapped B.C.A. lessons in English, Hindi and Gujarati

Data format validation (email, number, string, mobile number, name) · Web Designing-1 (option A) · Gri-Learn