टेस्ट फ़ाइल जनरेटर

यह कैसे काम करता है

हर फॉर्मैट को उसके स्पेसिफिकेशन के हिसाब से बाइट-बाइट करके बनाया जाता है, और पैडिंग उन जगहों पर छिपाई जाती है जहाँ पार्सर्स को छोड़ना ही होता है। PDF एक असली पाँच-ऑब्जेक्ट डॉक्यूमेंट है जिसकी क्रॉस-रेफरेंस टेबल हर ऑब्जेक्ट का सटीक बाइट ऑफ़सेट बताती है, और पैडिंग एक बड़ी कमेंट लाइन के ज़रिए की जाती है; ZIP एक असली आर्काइव है जिसमें एक ज़ीरो-भरी एंट्री के चारों ओर लोकल हेडर, सेंट्रल डायरेक्टरी और एंड रिकॉर्ड होता है, जिसमें पेलोड पर कैलकुलेट किया गया एक असली CRC-32 चेकसम भी शामिल है—यह इसलिए मायने रखता है क्योंकि अनज़िप टूल्स उस चेकसम को वेरिफाई करते हैं और नकली फाइलों को रिजेक्ट कर देते हैं।

इमेज को भी वही ट्रीटमेंट मिलता है: GIF को 255 बाइट तक के कमेंट एक्सटेंशन सब-ब्लॉक्स से बड़ा किया जाता है, JPEG को हर एक 64 KB तक सीमित COM सेगमेंट्स से, और PNG को IEND से पहले जोड़े गए एक कस्टम एंसिलरी चंक से, जिसका अपना CRC-32 होता है और जिसके टाइप में पहला अक्षर लोअरकेस होता है ताकि डिकोडर्स को पता चले कि इसे नज़रअंदाज़ करना सुरक्षित है। यह स्ट्रक्चरल ईमानदारी ही मुख्य बात है: ये फाइलें मैजिक-नंबर चेक्स पास करती हैं, असली व्यूअर्स में डिकोड होती हैं, और चेकसम वेरिफिकेशन से बच जाती हैं, इसलिए ये उन अपलोड पाइपलाइनों को असल में टेस्ट करती हैं जो कंटेंट की जाँच करती हैं।

खासतौर पर इमेज अपलोड टेस्ट करते समय एक चेतावनी: अगर पाइपलाइन इमेज को दोबारा एन्कोड करती है (जैसा ज़्यादातर अवतार और फोटो अपलोडर करते हैं), तो पैडिंग रीएन्कोडिंग के दौरान हट जाती है और आपकी 5 MB की JPG दूसरी तरफ बहुत छोटी होकर आती है। रीएन्कोडिंग होने से पहले वाले पॉइंट पर साइज़ लिमिट टेस्ट करें, या ZIP या PDF इस्तेमाल करें, जिन्हें पाइपलाइन शायद ही कभी दोबारा लिखती हैं। कोई भी फाइल कहीं से फ़ेच नहीं होती: बाइट्स मेमोरी में असेंबल होते हैं और आपके ब्राउज़र को एक blob के रूप में सौंपे जाते हैं, इसलिए सैकड़ों मेगाबाइट पर भी जनरेशन तुरंत होता है।