कोडिंग साक्षात्कार: आप यूनिकोड सोर्स-कोड स्पूफिंग डायग्नोस्टिक्स को कैसे लागू करेंगे?

प्रॉम्प्ट और संदर्भ

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

साक्षात्कारकर्ता क्या मूल्यांकन करता है

क्या लेक्सिंग, द्विदिश (bidi) रेंडरिंग, और सुरक्षा डायग्नोस्टिक्स अलग-अलग चरण हैं।
क्या आप UTS #55 लेक्सिकल सोर्स-कोड एटम्स और इसके HL4 डिस्प्ले सिमेंटिक्स को समझते हैं।
क्या आप प्रत्येक गैर-ASCII वर्ण को शत्रुतापूर्ण मानने के बजाय UTS #39 कन्फ्यूजेबल और प्रतिबंध नियमों का उपयोग करते हैं।
क्या आप यूनिकोड डेटा वर्ज़न, इंक्रीमेंटल स्कैन, व्याख्या योग्य निष्कर्ष और फॉल्स-पॉजिटिव नीतियों को संभालते हैं।

स्पष्टीकरण के लिए पूछे जाने वाले प्रश्न

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

30-सेकंड का उत्तर

मैं टोकन, आइडेंटिफायर्स, स्ट्रिंग्स और टिप्पणियां प्राप्त करने के लिए लक्षित भाषा लेक्सर का उपयोग करूँगा, फिर प्रत्येक एटम के लिए मूल कोड पॉइंट्स, दिशात्मक कंट्रोल्स और स्क्रिप्ट्स रिकॉर्ड करूँगा। सोर्स डिस्प्ले फ़ाइल को एक साधारण पैराग्राफ मानने के बजाय UTS #55 की लेक्सिकल संरचना का पालन करता है। डायग्नोस्टिक्स UTS #39 प्रतिबंध और कन्फ्यूजेबल डेटा को जोड़ते हैं, जिससे स्थितियों, नियमों, वर्ज़न और रेंडर किए गए अंतरों की रिपोर्ट मिलती है। निष्कर्ष डिफ़ॉल्ट रूप से चेतावनी दे सकते हैं और रिपॉजिटरी नीति द्वारा ब्लॉक कर सकते हैं; मूल टेक्स्ट को बनाए रखा जाता है ताकि वैध RTL टेक्स्ट को गलती से हमला न मान लिया जाए।

चरण-दर-चरण गहन विश्लेषण

1. पहले लेक्सिकल सीमाएं स्थापित करें

वर्ण-दर-वर्ण साधारण पैराग्राफ bidi प्रोसेसिंग लागू न करें। न्यूमेरिक लिटरल्स, आइडेंटिफायर्स, सिंगल-लाइन स्ट्रिंग्स और टिप्पणी सामग्री एटम्स बनाते हैं; नेस्टेड भाषाओं को बाहरी व्याकरण से सीमाओं की आवश्यकता होती है। किसी कंपाइलर या परिपक्व पार्सर के टोकन रेंज का पुन: उपयोग करें, और पार्सिंग विफल होने पर स्पष्ट रूप से रूढ़िवादी डायग्नोस्टिक्स पर डाउनग्रेड करें।

2. bidi कंट्रोल्स और डिफ़ॉल्ट-इग्नोरेबल वर्णों को चिह्नित करें

प्रत्येक एटम के लिए, RLO, LRO, PDF, RLI, LRI, FSI, और PDI जैसे कंट्रोल्स को उनके स्कोप के साथ रिकॉर्ड करें। रिपोर्टों में एस्केप किए गए कोड पॉइंट्स और मूल स्थितियां दिखाई जानी चाहिए, जिससे टर्मिनल या वेब पेज को कंट्रोल्स को दोबारा लागू करने से रोका जा सके। उन्हें आँख मूंदकर न हटाएं क्योंकि वैध लेआउट के लिए दिशात्मक कंट्रोल्स की आवश्यकता हो सकती है।

3. UTS #55 के साथ सोर्स डिस्प्ले को व्यवस्थित करें

UTS #55 लेक्सिकल संरचना पर उच्च-स्तरीय प्रोटोकॉल HL4 लागू करने की अनुशंसा करता है: टोकन क्रम भाषा सिंटैक्स का अनुसरण करता है, जबकि स्ट्रिंग्स, आइडेंटिफायर्स और टिप्पणियां उनके दिशात्मक गुणों के साथ रेंडर किए गए अविभाज्य एटम होते हैं। यह एक ही समय में पठनीय RTL टेक्स्ट और ऑडिट योग्य कोड संरचना को सुरक्षित रखता है।

4. आइडेंटिफायर और कन्फ्यूजेबल नियम लागू करें

आइडेंटिफायर्स पर भाषा की अनुमत नॉर्मलाइज़ेशन, केस और UAX #31 प्रोफ़ाइल लागू करें, फिर मिक्स्ड-स्क्रिप्ट और कन्फ्यूजेबल डायग्नोस्टिक्स के लिए UTS #39 का उपयोग करें। एक स्केलेटन को स्वयं आइडेंटिफायर न बनाएं; यह एक यूनिकोड डेटा वर्ज़न के लिए एक मध्यवर्ती तुलना मान है और संभावित टकरावों को खोजने के लिए उपयोगी है।

5. सबसे छोटा स्कैनिंग पाइपलाइन लिखें

नीचे दिया गया स्यूडोकोड केवल चरण सीमाओं को दिखाता है; प्रोडक्शन कोड को अभी भी लक्षित भाषा लेक्सर और यूनिकोड डेटा फ़ाइलों की आवश्यकता होती है:

typescript

type Atom = { kind: string; start: number; end: number; text: string };
type Finding = { code: string; start: number; end: number; detail: string };

function diagnose(source: string, atoms: Atom[], unicodeVersion: string): Finding[] {
  const findings: Finding[] = [];
  for (const atom of atoms) {
    findings.push(...scanBidiControls(atom));
    if (atom.kind === "identifier") {
      findings.push(...scanIdentifierConfusables(atom, unicodeVersion));
    }
  }
  return findings;
}

scanBidiControls को कंट्रोल कोड पॉइंट्स और स्कोप को संरक्षित करना चाहिए; scanIdentifierConfusables को मिक्स्ड-स्क्रिप्ट, प्रतिबंध-स्तर, या मौजूदा-आइडेंटिफायर टकराव निष्कर्ष वापस करने चाहिए। डायग्नोस्टिक चरण को सोर्स कोड को दोबारा नहीं लिखना चाहिए।

6. वर्ज़न, कैश और इंक्रीमेंटल स्कैन को संभालें

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

7. निष्कर्षों को नीति से अलग करें

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

उच्च गुणवत्ता वाला नमूना उत्तर

मैं कार्यान्वयन को लेक्सर, यूनिकोड विश्लेषण, रेंडर पूर्वावलोकन और नीति रिपोर्टिंग में विभाजित करूँगा। लेक्सर टोकन, आइडेंटिफायर्स, स्ट्रिंग्स और टिप्पणियों के लिए सटीक रेंज लौटाता है; एक अनपार्स करने योग्य क्षेत्र को वर्ण सीमाओं को सौंपने के बजाय अनिश्चित (uncertain) चिह्नित किया जाता है। यूनिकोड विश्लेषण प्रत्येक एटम के लिए Bidi_Control, स्क्रिप्ट सेट, नॉर्मलाइज़ेशन प्रोफ़ाइल और UTS #39 कन्फ्यूजेबल परिणाम रिकॉर्ड करता है। पूर्वावलोकन UTS #55 HL4 दृष्टिकोण का उपयोग करके टोकन सिंटैक्स क्रम बनाए रखता है, प्रत्येक एटम के अंदर bidi नियम लागू करता है, और रेंडरिंग के साथ एस्केप किए गए कोड पॉइंट्स दिखाता है। रिपोर्ट यूनिकोड डेटा वर्ज़न, लेक्सर वर्ज़न, नियम कोड और स्थान ले जाती हैं; नीति फ़ील्ड जोखिम के आधार पर चेतावनी या ब्लॉकिंग चुनती है। समान-वर्ज़न का स्केलेटन आइडेंटिफायर टकराव खोजने में मदद कर सकता है, लेकिन यह कोई उपयोगकर्ता नाम या स्थिर हैश नहीं है। कैश कुंजियों में फ़ाइल सामग्री, भाषा वर्ज़न और यूनिकोड वर्ज़न शामिल हैं, और अपग्रेड एक बैच पुनर्गणना को ट्रिगर करते हैं। परीक्षण RTL टिप्पणियों, स्ट्रिंग्स के अंदर कंट्रोल्स, नेस्टेड भाषाओं, मिक्स्ड-स्क्रिप्ट आइडेंटिफायर्स, पार्स विफलताओं, इंक्रीमेंटल संपादन और टर्मिनल व वेब रेंडरर्स के बीच अंतर को कवर करते हैं।

सामान्य गलतियाँ और विफल दृष्टिकोण

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

अनुवर्ती प्रश्न और उत्तर

प्रत्येक Bidi_Control वर्ण को क्यों न हटाएं?

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

लेक्सिंग विफल होने पर स्कैनर को क्या करना चाहिए?

एक स्पष्ट अनिश्चित रेंज लौटाएं, रूढ़िवादी कंट्रोल और कोड-पॉइंट डायग्नोस्टिक्स चलाएं, और यह दावा न करें कि वह क्षेत्र सुरक्षित है। जब तक कोई पार्सर भाषा का सटीक समर्थन नहीं करता तब तक CI समीक्षा की मांग कर सकता है।

आप कैसे साबित करते हैं कि बहुभाषी कोड को गलत तरीके से फ़्लैग नहीं किया गया है?

सकारात्मक मामलों के रूप में वैध RTL टिप्पणियों, स्ट्रिंग्स और अनुमत आइडेंटिफायर्स का उपयोग करें, और नकारात्मक मामलों के रूप में RLO/LRO, मिक्स्ड-स्क्रिप्ट, और कन्फ्यूजेबल टकरावों का उपयोग करें। कई एडिटर्स, टर्मिनलों और वेब रेंडरर्स में तार्किक क्रम, दृश्य क्रम और रिपोर्ट स्थानों की तुलना करें।