Base64 क्या है? एन्कोडिंग समझें

डिकोड की गई values। JVBERi0xLjcK डिकोड होकर %PDF-1.7 और उसके बाद एक line break देता है: यही header PDF फ़ाइल की शुरुआत में होता है, यानी content में सच में फ़ाइल के बाइट्स हैं। YWdlbmN5MDc6VmlzYSNUZXN0MjY= डिकोड होकर agency07:Visa#Test26 देता है, यानी partner का username और password। 2LPYp9ix2Kk= के बाइट्स D8 B3 D8 A7 D8 B1 D8 A9 को UTF-8 में पढ़ें तो अरबी नाम سارة (सारा) मिलता है, और यही बाइट्स Latin-1 में पढ़ें तो ठीक سارة। दोनों receipt references डिकोड होकर 12-12 random bytes देते हैं; उनमें पढ़ने लायक़ कुछ होने की उम्मीद नहीं है।

O1: gateway configuration में defect। Base64 हर 3 बाइट को 4 कैरेक्टर में बदलता है और आख़िरी group को ऊपर round करता है। सबसे बड़ी allowed फ़ाइल, 5,000,000 bytes, 1,666,667 groups है, इसलिए content 6,666,668 कैरेक्टर का है (एक "=" padding के साथ) और body 6,666,668 + 72 = 6,666,740 bytes, जो gateway की 6,000,000 की सीमा से ऊपर है। Gateway से निकलने वाली सबसे बड़ी फ़ाइल: content के लिए 6,000,000 − 72 = 5,999,928 कैरेक्टर बचते हैं; 5,999,928 ÷ 4 = 1,499,982 पूरे groups; 1,499,982 × 3 = 4,499,946 bytes। इसलिए sample की तरह JSON के 72 bytes के साथ 4,499,947 से 5,000,000 bytes तक की हर valid फ़ाइल reject होती है (4,800,000 bytes की family-book.pdf को 6,400,072 bytes की body चाहिए, जबकि 4,200,000 bytes की birth-certificate.pdf 5,600,000 कैरेक्टर में encode होती है और निकल जाती है), और आवेदक को काम का error नहीं, gateway का HTML page मिलता है। सीमा से बड़ी फ़ाइलों को भी गलत जवाब मिलता है: partner का system, जिसके आगे app वाली जाँच नहीं है, 5,000,001 bytes की फ़ाइल भेजे तो वह service तक पहुँचती ही नहीं, इसलिए DOC-4 का माँगा हुआ FILE_TOO_LARGE error कभी नहीं लौटता।

ISTQB की भाषा में failure है valid फ़ाइल पर 413; defect है request body की ऐसी सीमा जो encoded request के बजाय raw फ़ाइल के साइज़ के हिसाब से तय की गई। इसे gateway configuration के ख़िलाफ़ report करें, DOC-4 को test basis बनाकर। Fix का फ़ैसला team का है: सीमा को सबसे बड़ी encoded body से ऊपर ले जाना, लंबे file names की गुंजाइश के साथ, या फ़ाइलों को JSON में Base64 के बजाय binary रूप में upload करना (जैसे multipart/form-data), जिससे एक-तिहाई का overhead भी ख़त्म हो जाता है। Developers के लिए एक note जोड़ें: 5,000,000 और 5,000,001 bytes दोनों 6,666,668 कैरेक्टर में encode होते हैं, इसलिए साइज़ का नियम डिकोड किए गए बाइट्स पर जाँचना चाहिए, Base64 स्ट्रिंग की लंबाई पर कभी नहीं।

O2: Android app में defect। हर 76 कैरेक्टर पर line break MIME-style wrapping है। RFC 4648 §3.1 कहता है कि encoders line breaks न जोड़ें, जब तक Base64 इस्तेमाल करने वाला specification ऐसा न माँगे, और contract नहीं माँगता; §3.3 कहता है कि डिकोडर alphabet से बाहर के कैरेक्टर reject करे, जब तक specification कुछ और न कहे। इसलिए service का 400 INVALID_BASE64 सही है, और iOS दिखाता है कि फ़ाइलें ख़ुद ठीक हैं। दोनों तरह के डिकोडर आप साथ-साथ देख सकते हैं: Base64 encoder में "पंक्ति रैप" को "76 कैरेक्टर (MIME)" पर रखकर कोई छोटी फ़ाइल encode करें और नतीजा Base64 decoder में paste करें, जो tolerant है: वह line breaks को नज़रअंदाज़ करता है और बताता है कि कितने whitespace कैरेक्टर छोड़े। Documents service strict है, जैसा RFC default रूप से माँगता है। Fix: Android encoder value को एक ही line में बनाए। API owner से कहें कि contract में साफ़ लिखे: "एक line, कोई whitespace नहीं"।

O3: receipt link बनाने के तरीके में defect। दूसरे reference में "+" है। Link standard Base64 को बिना percent-encoding के query string में रखता है, और service query string को form-encoding के नियमों से पढ़ती है, जिनमें "+" का मतलब space है; उसे k7Qd2 fA9w1Z0LsE मिलता है और वह उसे reject कर देती है। URL decoder इसे दोहराता है: "+ को स्पेस के रूप में डिकोड करें" चालू हो तो k7Qd2+fA9w1Z0LsE बदलकर k7Qd2 fA9w1Z0LsE बनता है। पहला reference सिर्फ़ इसलिए चलता है कि उसमें "+" नहीं है; उसका "/" query string में मान्य है, लेकिन अगर reference कभी path में गया तो route तोड़ देगा। References random bytes हैं, इसलिए कौन-सा link fail होगा यह भी random लगता है, और इसी वजह से ऐसे defects अक्सर intermittent कहकर report होते हैं। Fix: reference के लिए Base64URL (RFC 4648 §5), ताकि k7Qd2-fA9w1Z0LsE और Lm0x8Qp_Vt2aKc3Q को कोई escaping न चाहिए; या value को percent-encode करना ताकि "+" बने %2B (URL encoder यह दिखाता है), हालाँकि इसे भूल जाना आसान है। ईमेल से पहले भेजे जा चुके links fix के बाद भी चलने चाहिए: पूछें कि पुराने references कैसे स्वीकार होंगे।

O4: security defect, और छहों में सबसे गंभीर, क्योंकि यह credentials उजागर करता है। Header कुछ सेकंड में डिकोड होकर agency07:Visa#Test26 देता है: gateway log partner का password पढ़ने लायक़ रूप में रखता है, logs पढ़ सकने वाले हर व्यक्ति के लिए, और production भी इसी तरह log करता है। Developer का comment गलत है: Base64 बिना key की एन्कोडिंग है, एन्क्रिप्शन नहीं, और HTTPS Basic credentials को सिर्फ़ रास्ते में बचाता है, log में लिखे जाने के बाद नहीं। इसे high severity के साथ report करें, और report में username लिखें पर password छिपा दें। अपेक्षित fix: gateway log में, और headers दर्ज करने वाले हर दूसरे log या monitoring tool में, Authorization header को mask करना या हटाना, और उजागर हुए credential को बदलना। Confirmation test: partner की call दोहराएँ और जाँचें कि log में कोई credential नहीं दिखता; regression tests में secrets ले जाने वाले दूसरे headers भी जाँचें, जैसे API keys और Bearer tokens।

O5: back office में defect। Apps सही हैं: 2LPYp9ix2Kk= नाम سارة का UTF-8 encoding है (4 कैरेक्टर, 8 बाइट)। Back office डिकोड किए गए बाइट्स को Latin-1 से टेक्स्ट बनाता है, हर बाइट का एक कैरेक्टर, तो D8 बनता है Ø और B3 बनता है ³, और नतीजा سارة; Base64 decoder में "टेक्स्ट को इस रूप में डिकोड करें" को "Latin-1 / बाइनरी स्ट्रिंग" पर रखने से यही ठीक-ठीक दोहराया जा सकता है। Ø या Ù की कतार, जिसमें हर एक के बाद कोई और symbol हो, Latin-1 में पढ़े गए अरबी UTF-8 का आम निशान है। Fix: डिकोड किए गए बाइट्स को UTF-8 में पढ़ना। Confirmation test और regression suite के लिए test data: एक अरबी नाम, देवनागरी में एक हिंदी नाम (UTF-8 में हर कैरेक्टर 3 बाइट), accent वाला Latin नाम जैसे José (é 2 बाइट), field अनुमति दे तो emoji वाला नाम (4 बाइट), और सिर्फ़ ASCII वाला नाम, जो बिना बदले रहना चाहिए।

O6: defect नहीं। Padding फ़ाइल के साइज़ से तय होती है, क्योंकि Base64 तीन-तीन बाइट के groups में काम करता है: 48,211 को 3 से भाग देने पर शेष 1 बचता है, इसलिए value "==" पर ख़त्म होती है; 120,005 पर शेष 2, इसलिए "="; 96,300 पर शेष 0, इसलिए कोई padding नहीं। (जल्दी जाँचने का तरीका: किसी संख्या को 3 से भाग देने पर वही शेष बचता है जो उसके अंकों के जोड़ को 3 से भाग देने पर।) लंबाई होती है 4 × (साइज़ ÷ 3, ऊपर round करके): 16,071 × 4 = 64,284, 40,002 × 4 = 160,008 और 32,100 × 4 = 128,400, यानी हर फ़ाइल से लगभग एक-तिहाई ज़्यादा, जैसा होना चाहिए। Note को इस हिसाब के साथ "defect नहीं" कहकर बंद करें, और तीनों फ़ाइलें रख लें: साथ मिलकर वे padding के तीनों cases cover करती हैं।

फ़ाइल साइज़ की test values (2-value BVA)। Requirement की boundary: 5,000,000 bytes, 201 के साथ accept, और 5,000,001 bytes, 413 और FILE_TOO_LARGE के साथ reject; दोनों को सिर्फ़ app से नहीं, सीधे API पर भी भेजें, जैसे partner का system भेजता है। Sample file name के लिए gateway की boundary, जो एक technical boundary है और requirement में नहीं लिखी: 4,499,946 bytes (body ठीक 6,000,000, accept) और 4,499,947 bytes (body 6,000,004, आज gateway reject करता है, defect fix होने के बाद accept)। Padding cases: तीन साइज़ जिन्हें 3 से भाग देने पर शेष 0, 1 और 2 बचे, जैसे O6 की फ़ाइलें। Gateway boundary को सबसे लंबे allowed file name के साथ भी चलाएँ, क्योंकि JSON का हर extra बाइट gateway से निकलने वाली सबसे बड़ी फ़ाइल को घटाता है, और पूछें कि खाली फ़ाइल के लिए DOC-4 क्या अपेक्षा करता है। Fix के बाद 4,499,947 और 5,000,000 को regression suite में रखें।

मौजूदा contract के हिसाब से content के negative tests, हर एक में अपेक्षित 400 INVALID_BASE64 और कुछ भी store नहीं: value के अंदर line breaks या spaces; Base64URL के कैरेक्टर "-" या "_"; alphabet से बाहर का कोई कैरेक्टर, जैसे "*"; ऐसी लंबाई जो 4 का गुणज न हो (padding हटाकर); और value के बीच में "="। दो बार encode की गई फ़ाइल वैध Base64 है जिसके डिकोड किए गए बाइट्स ख़ुद Base64 टेक्स्ट हैं (यह JVBERi0 की जगह SlZCRVJp से शुरू होती है): अगर service फ़ाइल के content को mimeType से मिलाती है तो इसे PDF न होने के कारण reject होना चाहिए, इसलिए पूछें कि वह मिलाती है या नहीं। Receipt reference के लिए: "+" और "/" वाले references, और अगर references की लंबाई बदल सकती है तो "=" वाले भी; space वाला reference; percent-encoded reference (%2B); और सही format का पर अनजान reference, जिस पर client error आना चाहिए, 500 कभी नहीं (अंश में नहीं लिखा कि कौन-सा, इसलिए पूछें)।

API owner के लिए सवाल: service गायब padding और whitespace को स्वीकार करे या reject, और क्या contract यह साफ़ लिख सकता है? सबसे लंबा allowed file name कितना है, क्योंकि वह gateway boundary को खिसकाता है? क्या service जाँचती है कि डिकोड किए गए बाइट्स mimeType से मेल खाते हैं? क्या receipt references Base64URL पर जाएँगे, और पहले भेजे गए links कैसे चलते रहेंगे? और 5 MB तक की फ़ाइलों के लिए, एक-तिहाई के overhead के साथ, क्या JSON के अंदर Base64 सही channel है भी?

अगर आपके numbers अलग हैं, तो जाँचें कि encoded लंबाई निकालते समय आपने groups की गिनती ऊपर round की और gateway से निकलने वाली सबसे बड़ी फ़ाइल निकालते समय नीचे, और JSON के 72 bytes जोड़े।