तकनीकी गाइड

1 परिचय

nikpak .nik प्रारूप के लिए एक कमांड-लाइन आर्काइवर है। इसे चार विचारों के इर्द-गिर्द डिज़ाइन किया गया था: स्थापित टूल्स से बेहतर संपीड़न, तेज़ काम, आधुनिक क्रिप्टोग्राफ़ी से डेटा की सुरक्षा, और Windows, macOS तथा Linux पर बिना किसी बदलाव के एक छोटे एग्ज़िक्यूटेबल के रूप में चलना।

1.1 डिज़ाइन लक्ष्य

• छोटा। जो डेटा लोग वास्तव में बड़ी मात्रा में आर्काइव करते हैं, उस पर RAR 7 को मात देना। ऑडियो, छवियाँ और ट्रैकर संगीत सामग्री से पहचाने जाते हैं और विशेष दोषरहित कोडेक से संपीड़ित किए जाते हैं; बाकी सब कुछ एक सुव्यवस्थित, मल्टी-थ्रेडेड Zstandard स्ट्रीम का उपयोग करता है।
• तेज़। संपीड़न और निष्कर्षण डिस्क द्वारा सीमित होने चाहिए, CPU द्वारा नहीं। अपने तेज़ स्तर -m2 पर nikpak एक कोर पर लगभग 200 MB स्रोत फ़ाइलों को एक सेकंड से कम समय में आर्काइव करता है।
• सुरक्षित। मेमोरी-हार्ड कुंजी व्युत्पत्ति फ़ंक्शन के साथ प्रमाणित एन्क्रिप्शन, फ़ाइल नाम हमेशा छिपे रहते हैं, छेड़छाड़ हमेशा पकड़ी जाती है, और एक ऐसा एक्सट्रैक्टर जिसे उसके गंतव्य फ़ोल्डर के बाहर लिखने के लिए धोखा नहीं दिया जा सकता।
• क्वांटम-प्रतिरोधी। केवल 256-बिट सिमेट्रिक क्रिप्टोग्राफ़ी का उपयोग किया जाता है। nikpak में कहीं भी RSA, एलिप्टिक-कर्व या Diffie-Hellman कोड नहीं है, इसलिए Shor के एल्गोरिदम को तोड़ने के लिए कुछ नहीं है।
• पोर्टेबल और स्क्रिप्ट-अनुकूल। एक स्थिर रूप से लिंक किया गया एग्ज़िक्यूटेबल, RAR-संगत कमांड लाइन, पूर्वानुमान योग्य एग्ज़िट कोड, और एक -help जो हर विकल्प का दस्तावेज़ीकरण करता है।

1.2 एक नज़र में परिणाम

मापदंड	परिणाम	तुलना
BMP तस्वीरें	38.8 % छोटा	RAR 7.00 -m5
स्टीरियो संगीत, 44.1 kHz 16-बिट	14.6 % छोटा (FLAC -8 के बराबर)	RAR 7.00 -m5
ProTracker MOD फ़ाइलें	13.3 % छोटा	RAR 7.00 -m5
मोनो ऑडियो, 8-बिट और 16-बिट	12.2 % और 15.3 % छोटा	RAR 7.00 -m5
197 MB स्रोत फ़ाइलें, अधिकतम स्तर	5.5 % छोटा (24.4 MB बनाम 25.9 MB)	RAR 7.00 -m5 -s -md256m
वही डेटा, तेज़ स्तर -m2	0.9 s	RAR 7.00 -m3 सॉलिड: 16.7 s
एन्क्रिप्शन	Argon2id + XChaCha20-Poly1305	RAR5: AES-256-CBC + PBKDF2
सभी 10 परीक्षण सेट, अधिकतम स्तर, 7-Zip की तुलना में	2.4 से 31.7 % छोटा	7-Zip 23.01 -mx9 (अनुभाग 11.7)
ऑफ़िस फ़ाइलें (doc, docx, xls, xlsx, csv, pdf)	31.7 % छोटा	7-Zip 23.01 -mx9 (अनुभाग 11.7)
सभी 10 परीक्षण सेट, अधिकतम स्तर, ZIP की तुलना में	19.9 से 60.4 % छोटा	ZIP -9, Info-ZIP 3.0 (अनुभाग 11.7)
एग्ज़िक्यूटेबल	एक फ़ाइल, कोई निर्भरता नहीं; विंडो के साथ लगभग 9 MB, केवल कमांड-लाइन 2.3 MB	Windows, macOS, Linux

आँकड़े कैसे प्राप्त किए गए सभी माप एक ही मशीन (Linux x86-64 वर्चुअल मशीन, एक CPU कोर) से RAR 7.00 और nikpak 1.1.0 के साथ लिए गए हैं। हर आर्काइव को फिर से निकालकर मूल से बाइट-दर-बाइट मिलाया गया। पूरी विधि, परीक्षण-संग्रह और वे मामले जहाँ RAR तेज़ है, अध्याय 11 में वर्णित हैं।

1.3 यह किसके लिए है?

nikpak उन लोगों के लिए है जो बड़ी मात्रा में मीडिया या स्रोत कोड आर्काइव करते हैं और आकार तथा गति की परवाह करते हैं, उन डेवलपर्स के लिए जो समझदार एग्ज़िट कोड और एक दस्तावेज़ित प्रारूप वाला स्क्रिप्ट-अनुकूल आर्काइवर चाहते हैं, और उन सभी के लिए जिन्हें किसी बंद कार्यान्वयन पर भरोसा किए बिना मज़बूत एन्क्रिप्शन चाहिए। क्योंकि कमांड लाइन RAR की परंपराओं का पालन करती है, Total Commander जैसे फ्रंट-एंड इसे बहुत कम या बिना किसी पुनर्कॉन्फ़िगरेशन के चला सकते हैं।

1.4 यह गाइड कैसे पढ़ें

अध्याय 2 और 3 बताते हैं कि nikpak क्या करता है और इसका उपयोग कैसे करें। अध्याय 4 से 7 आर्किटेक्चर, फ़ाइल प्रारूप, संपीड़न इंजन और मीडिया कोडेक की व्याख्या करते हैं। अध्याय 8 से 10 एन्क्रिप्शन, क्वांटम प्रतिरोध और सख़्ती को कवर करते हैं। अध्याय 11 बेंचमार्क प्रस्तुत करता है, अध्याय 12 nikpak की RAR से ईमानदारी से तुलना करता है, और अध्याय 13 से 15 बिल्ड, परीक्षण और रोडमैप से संबंधित हैं।

1.5 समुदाय और संपर्क

समाचार, प्रश्न, विचार और बग रिपोर्ट: nikpak के लेखक से इन चैनलों पर संपर्क किया जा सकता है:

• Telegramhttps://t.me/cryptonikko
• Xhttps://x.com/cryptonikkoid
• Discordhttps://discord.com/users/1537826350759415811

वही तीन लिंक nikpak विंडो के नीचे, गंतव्य फ़ोल्डर के नीचे (अनुभाग 3.7), गोल, रंगीन बटन के रूप में दिखाए जाते हैं, और nikpak -help के अंत में भी।

2 सुविधा अवलोकन

2.1 क्षमताएँ

क्षेत्र	nikpak क्या प्रदान करता है
संपीड़न	Zstandard (मल्टी-थ्रेडेड, सॉलिड) -m1 से -m4 तक, -m4 पर 128 MiB विंडो और लंबी-दूरी मिलान के साथ। -m5 पर एक मल्टी-इंजन बॉडी: बाइनरी डेटा के लिए LZMA2 और टेक्स्ट के लिए PPMd, जिसे परीक्षण द्वारा चुना जाता है; फ़ाइलें 7-Zip की तरह प्रकार के अनुसार क्रमबद्ध की जाती हैं।
मीडिया बुद्धिमत्ता	WAV, AIFF, ProTracker MOD और BMP की सामग्री-आधारित पहचान; चार फ़िल्टरों (NAC, Shuffle, Shuffle+Delta, MED) के बीच प्रति-फ़ाइल परीक्षण; सादे संपीड़न पर स्वचालित फ़ॉलबैक।
ऑफ़िस, PDF, gzip	Deflate पुनर्संपीड़न (preflate): docx, xlsx, pptx, odt, ods, epub, jar, zip, pdf और gz फ़ाइलों के अंदर मौजूद Deflate स्ट्रीम को डिकोड किया जाता है, कहीं बेहतर संपीड़ित किया जाता है और निष्कर्षण पर बिट-दर-बिट पुनर्निर्मित किया जाता है (-m4, -m5)।
एन्क्रिप्शन	Argon2id (64 MiB) कुंजी व्युत्पत्ति, 64 KiB प्रमाणित चंकों में XChaCha20-Poly1305; नाम, आकार, तिथियाँ और अनुमतियाँ एन्क्रिप्ट की जाती हैं।
पासवर्ड	पुष्टि के साथ इंटरैक्टिव संकेत, एनवायरनमेंट वेरिएबल, stdin, कमांड लाइन; जब कुछ नहीं दिया जाता तो एक मज़बूत यादृच्छिक पासवर्ड का स्वचालित निर्माण।
अखंडता	हर फ़ाइल के मूल बाइट्स का CRC32; एन्क्रिप्टेड आर्काइव के लिए AEAD प्रमाणीकरण; प्रविष्टि गणना के साथ अंत चिह्न; स्व-सत्यापन करने वाला ऑडियो कोडेक।
कमांड लाइन	RAR-शैली कमांड (a x e l v lb t p d), एकल फ़ाइलों, फ़ोल्डरों या वाइल्डकार्ड का निष्कर्षण, और स्विच, zip-शैली उपनाम, वाइल्डकार्ड, @listfiles, बहिष्करण, ओवरराइट नीतियाँ, शांत मोड, स्पष्ट एग्ज़िट कोड।
सुरक्षा	Zip-slip सुरक्षा, सिमलिंक से इनकार, setuid हटाना, सीमित डिकोडर, परमाणु आर्काइव लेखन, Rust मेमोरी सुरक्षा।
पोर्टेबिलिटी	Windows (PowerShell, cmd), macOS, Linux; एकल स्थिर एग्ज़िक्यूटेबल; हर प्लेटफ़ॉर्म पर बाइट-सटीक परिणाम।
ग्राफ़िकल इंटरफ़ेस	बिना आर्गुमेंट के शुरू किया जाए तो nikpak एक न्यूनतम ड्रॉप विंडो खोलता है: सर्वोत्तम संपीड़न से संपीड़ित करने के लिए फ़ाइलें या फ़ोल्डर ड्रॉप करें (या चुनें); प्रगति रिंग, याद रखा गया गंतव्य फ़ोल्डर (अनुभाग 3.7)।
आर्काइव ब्राउज़र	unNik.exe, सभी के लिए निःशुल्क: फ़ोल्डर ब्राउज़ करें, खोजें, टेक्स्ट और बाइनरी फ़ाइलें देखें, चयन निकालें और .nik आर्काइव में फ़ाइलें हटाएँ (अनुभाग 3.9)।
स्किन	55 विंडो स्किन, जिनमें 14 चित्रित दृश्य स्किन शामिल हैं; एक स्किन बॉक्स जो विंडो के बगल में Apply Skin और Cancel के साथ खड़ा रहता है; अपनी Nikkomander .skin.json फ़ाइलें आयात करें (अनुभाग 3.10)।
फ़ाइल-प्रबंधक मेन्यू	Explorer, Dolphin, Nemo, Nautilus और Finder में एक “NikPak” सबमेन्यू: आर्काइव में जोड़ें, यहाँ निकालें, इसके अपने फ़ोल्डर में निकालें, unNik के साथ खोलें; कई आइटमों के चयन के लिए एक आर्काइव (अनुभाग 3.11)।

2.2 nikpak और RAR साथ-साथ

नीचे दी गई तालिका इस परियोजना में मापी गई nikpak 1.1 की RAR 7 से तुलना करती है, और स्पष्ट रूप से बताती है कि RAR कहाँ आगे है। अध्याय 12 अलग-अलग बिंदुओं पर चर्चा करता है।

	nikpak 1.1	RAR 7
मीडिया संपीड़न	प्रति-फ़ाइल परीक्षण द्वारा चुने गए विशेष दोषरहित कोडेक	अंतर्निहित फ़िल्टरों वाला सामान्य एल्गोरिदम
स्रोत कोड, अधिकतम स्तर	24.4 MB (छोटा), 45.6 s	25.9 MB, 26.7 - 36.2 s
तेज़ स्तरों पर गति	0.9 s 197 MB के लिए (-m2)	9.7 - 16.7 s (-m3)
एन्क्रिप्शन	Argon2id + XChaCha20-Poly1305 (प्रमाणित)	AES-256-CBC + PBKDF2-HMAC-SHA256
फ़ाइल नाम हमेशा एन्क्रिप्टेड	हाँ	केवल -hp के साथ
मेमोरी-हार्ड पासवर्ड हैशिंग	हाँ (64 MiB)	नहीं
यादृच्छिक पासवर्ड जनरेटर	अंतर्निहित	अंतर्निहित नहीं
स्रोत कोड, भाषा	पूर्ण स्रोत, Rust (मेमोरी सुरक्षित)	स्वामित्व वाला, C++
रिकवरी रिकॉर्ड, वॉल्यूम, SFX, इन-प्लेस अपडेट	अभी नहीं	हाँ (WinRAR)
ट्रैक रिकॉर्ड	नया, अभी तक ऑडिट नहीं हुआ	दशकों

3 कमांड-लाइन संदर्भ

nikpak उसी सिंटैक्स का पालन करता है जिसे RAR उपयोगकर्ता जानते हैं: nikpak [options] [files...]। विकल्प आर्काइव नाम से पहले या बाद में कहीं भी आ सकते हैं; -- विकल्प पार्सिंग समाप्त कर देता है।

3.1 कमांड

कमांड	अर्थ
a	एक नया आर्काइव बनाएँ। जब नाम में कोई एक्सटेंशन नहीं होता तो .nik जोड़ा जाता है। फ़ोल्डर हमेशा पुनरावर्ती रूप से लिए जाते हैं।
x	पूरे पथों के साथ निकालें: सब कुछ, या केवल आर्काइव नाम के बाद दिए गए नाम, फ़ोल्डर और वाइल्डकार्ड (nikpak x backup.nik Docs/report.pdf एक फ़ाइल निकालता है)। अंत में पथ विभाजक (या -d dir) गंतव्य चुनता है।
e	बिना पथों के निकालें: हर फ़ाइल सीधे गंतव्य फ़ोल्डर में चली जाती है।
l	सामग्री सूचीबद्ध करें (सभी, या केवल मेल खाते नाम): गुण, आकार, तिथि (UTC), नाम, योग।
v	विस्तृत सूची: हर फ़ाइल का CRC32 जोड़ता है।
lb	सादी सूची: प्रति पंक्ति एक नाम, स्क्रिप्ट और GUI फ्रंट-एंड के लिए बनाई गई।
t	परीक्षण: सब कुछ डीकंप्रेस करता है, हर CRC32 जाँचता है और, एन्क्रिप्टेड आर्काइव के लिए, प्रमाणीकरण सत्यापित करता है।
p	फ़ाइलों को मानक आउटपुट पर छापें: सभी, या नामित फ़ाइलें (nikpak p notes.nik todo.txt | more)।
d	किसी आर्काइव से फ़ाइलें या फ़ोल्डर हटाएँ (फ़ोल्डर अपनी सामग्री सहित जाता है)। आर्काइव उनके बिना फिर से लिखा जाता है; एन्क्रिप्टेड आर्काइव अपना पासवर्ड बनाए रखते हैं। नाम आवश्यक हैं।
mt	मीडिया परीक्षण: WAV/AIFF/MOD/BMP फ़ाइलें पहचानता है और दिखाता है कि हर मीडिया फ़िल्टर कितना आकार प्राप्त करता है। कुछ नहीं लिखता।
(none)	बिना किसी आर्गुमेंट के शुरू किया जाए (उदाहरण के लिए nikpak.exe पर डबल-क्लिक करके), nikpak इसके बजाय अपनी विंडो खोलता है (अनुभाग 3.7)।

3.2 विकल्प

RAR शैली	zip शैली	अर्थ
-p	-e	एन्क्रिप्ट / डिक्रिप्ट करें, पासवर्ड माँगें। एक खाली प्रविष्टि यादृच्छिक पासवर्ड बनाकर उसे दिखाती है।
-p	-P	कमांड लाइन पर पासवर्ड (मशीन के अन्य उपयोगकर्ताओं को दिखाई देता है)।
-hp[password]		-p के समान। nikpak में फ़ाइल नाम हमेशा एन्क्रिप्टेड होते हैं।
-m0 .. -m5	-0 .. -9	स्टोर, सबसे तेज़, तेज़, अच्छा, उच्च (Deflate पुनर्संपीड़न जोड़ता है), अधिकतम (1.2.1 से डिफ़ॉल्ट; LZMA2/PPMd, अनुभाग 6.7)। जब गति आकार से अधिक मायने रखे तो -m2 उपयोग करें।
-mt		थ्रेडों की संख्या, 1 से 256 (डिफ़ॉल्ट: सभी कोर)।
-mc- / -mc+		सभी सामग्री फ़िल्टर (मीडिया कोडेक और Deflate पुनर्संपीड़न) बंद / मीडिया फ़िल्टर हमेशा चालू। डिफ़ॉल्ट: स्वचालित प्रति-फ़ाइल परीक्षण।
-r		फ़ोल्डरों में पुनरावर्ती प्रवेश (हमेशा चालू, संगतता के लिए स्वीकृत)।
-ep	-j	हर आर्गुमेंट का केवल अंतिम पथ घटक संग्रहित करें।
-ep1		किसी फ़ोल्डर आर्गुमेंट के आधार फ़ोल्डर का नाम संग्रहित न करें।
-o+	-o	मौजूदा फ़ाइलों को बिना पूछे अधिलेखित करें।
-o-	-n	मौजूदा फ़ाइलों को बिना पूछे छोड़ दें।
-or		पहले से मौजूद निकाली गई फ़ाइलों का नाम बदलें: name (1).ext।
-y		हर प्रश्न का उत्तर हाँ मान लें।
-x	-x	फ़ाइलें बाहर करें; दोहराया जा सकता है।
-d	-d	x और e के लिए गंतव्य फ़ोल्डर।
-inul -idq	-q	शांत: केवल त्रुटियाँ छापी जाती हैं।
@listfile		एक टेक्स्ट फ़ाइल से फ़ाइल नाम पढ़ें, प्रति पंक्ति एक।
-h -help -?		पूर्ण सहायता। -V संस्करण छापता है।

जिन विकल्पों को RAR फ्रंट-एंड अक्सर भेजते हैं लेकिन जिनका यहाँ कोई अर्थ नहीं है (-s, -ma5, -md64m, -ibck, -idp, -rr, -ts*, -w और ऐसे ही) स्वीकार करके अनदेखा कर दिया जाता है, ताकि मौजूदा टूल कॉन्फ़िगरेशन काम करते रहें। बाकी किसी भी चीज़ से एक स्पष्ट त्रुटि संदेश और एग्ज़िट कोड 7 मिलता है।

फ़ाइल-प्रबंधक मेन्यू कुछ लंबे विकल्प जोड़ता है (अनुभाग 3.11): nikpak --add और --add-here दिए गए आइटमों को एक नए आर्काइव में संपीड़ित करते हैं, nikpak --install-menu और --uninstall-menu राइट-क्लिक मेन्यू जोड़ते या हटाते हैं (सभी-उपयोगकर्ता इंस्टॉल के लिए --all-users), और unNik --extract, --extract-here तथा --extract-to मेन्यू से निष्कर्षण चलाते हैं।

3.3 पासवर्ड विस्तार से

जब -p के साथ कोई आर्काइव बनाया जाता है, तो nikpak इसी क्रम में पासवर्ड तय करता है, और केवल इसलिए कभी विफल नहीं होता कि कोई पासवर्ड नहीं दिया गया:

• -p या -P कमांड लाइन पर: जैसा है वैसा उपयोग (न्यूनतम 8 अक्षर)।
• एनवायरनमेंट वेरिएबल NIKPAK_PASSWORD, जो पासवर्ड को प्रोसेस सूची से बाहर रखता है।
• एक इंटरैक्टिव संकेत, पुष्टि के लिए दो बार पूछा जाता है। एक खाली प्रविष्टि यादृच्छिक पासवर्ड बनाती है।
• टर्मिनल के बिना (उदाहरण के लिए GUI के अंदर), stdin पर पाइप किया गया पासवर्ड; अगर कोई नहीं है तो यादृच्छिक पासवर्ड बनाया जाता है।

बनाए गए पासवर्ड में 56 असंदिग्ध चिह्नों (कोई 0/O, 1/l/I नहीं) की वर्णमाला से 24 अक्षर होते हैं, लगभग 139 बिट एन्ट्रॉपी। यह कंसोल पर एक बॉक्स में एक बार छापा जाता है। कोई पुनर्प्राप्ति नहीं है: जिस आर्काइव का पासवर्ड खो जाए, उसे कोई नहीं खोल सकता।

एन्क्रिप्टेड आर्काइव खोलते समय nikpak वही स्रोत उपयोग करता है और फिर एग्ज़िट कोड 11 और एक व्याख्यात्मक संदेश के साथ विफल हो जाता है; यह कभी कुछ नहीं बनाता, क्योंकि बनाया गया पासवर्ड मेल नहीं खा सकता।

3.4 एग्ज़िट कोड

कोड	अर्थ	सामान्य कारण
0	सफलता
1	चेतावनी	कुछ फ़ाइलें छोड़ दी गईं (अपठनीय, असुरक्षित पथ, सिमलिंक)
2	घातक त्रुटि	फ़ाइल बना या पढ़ नहीं सका, आंतरिक त्रुटि
3	दूषित आर्काइव या CRC त्रुटि	क्षतिग्रस्त या काटा गया आर्काइव, चेकसम विफल
7	कमांड-लाइन त्रुटि	अज्ञात विकल्प, आर्काइव नाम गायब
10	कुछ मेल नहीं खाया	कोई फ़ाइल नामों या वाइल्डकार्ड से मेल नहीं खाई
11	गलत या गायब पासवर्ड	गलत पासवर्ड, या छेड़छाड़ किया गया एन्क्रिप्टेड आर्काइव

3.5 उदाहरण

nikpak a backup.nik C:\Docs\*.txt Photos\ # create an archive

nikpak a -m5 -mt8 big.nik Projects\ # maximum, 8 threads

nikpak a -p secret.nik Taxes2026\ # encrypted, prompts

nikpak a -pMyLongPassw0rd s.nik f.pdf # password given

nikpak x backup.nik C:\Restore\ # extract with paths

nikpak e backup.nik *.jpg C:\Pics\ # only *.jpg, flat

nikpak x backup.nik Docs/report.pdf # extract ONE file

nikpak e backup.nik Docs/report.pdf -d C:\Out # one file, no path

nikpak x backup.nik Photos -d C:\Restore # one folder

nikpak l backup.nik *.pdf # list only PDFs

nikpak p backup.nik notes.txt # show a file

nikpak d backup.nik Temp *.bak # delete entries

nikpak l backup.nik # list

nikpak t secret.nik # test (asks password)

nikpak mt song.wav tracker.mod photo.bmp # which filter wins?

3.6 Total Commander और अन्य फ्रंट-एंड के साथ एकीकरण

क्योंकि nikpak RAR का कमांड सिंटैक्स स्वीकार करता है (a, x, e, l, t, @listfile, -p, -ep1, -o+, -y, -m), कोई भी प्रोग्राम जो बाहरी rar.exe चला सकता है, वह nikpak.exe भी चला सकता है। Total Commander में, एक्सटेंशन nik को Configuration, Packer, Additional packer programs के अंतर्गत पंजीकृत करें और पैकर तथा अनपैकर कमांड को nikpak.exe पर इंगित करें। अनअटेंडेड निष्कर्षण के लिए -o+ या -y उपयोग करें, क्योंकि कंसोल के बिना nikpak यह नहीं पूछ सकता कि अधिलेखित करना है या नहीं और इसके बजाय मौजूदा फ़ाइलों को छोड़ देगा। मेन्यू नाम Total Commander के संस्करणों के बीच अलग होते हैं; सटीक फ़ील्ड के लिए इसकी अंतर्निहित सहायता देखें।

Windows पर रिक्त स्थानों वाले फ़ोल्डर एक उद्धृत पथ जो बैकस्लैश पर समाप्त होता है, जैसे "C:\My Folder\", Windows द्वारा गलत पार्स किया जाता है (अंतिम उद्धरण को एस्केप माना जाता है)। रिक्त स्थानों वाले गंतव्यों के लिए इसके बजाय -d "C:\My Folder" उपयोग करें।

3.7 ग्राफ़िकल इंटरफ़ेस

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

• एक फ़ाइल या एक फ़ोल्डर, या एक साथ कई, विंडो पर ड्रॉप करें, या उन्हें डायलॉग में चुनने के लिए वृत्त पर क्लिक करें (या फ़ाइलें चुनें / फ़ोल्डर चुनें लिंक पर); वृत्त पर क्लिक करने से रिंग के अंदर फ़ाइलें चुनें और फ़ोल्डर चुनें दो बटन दिखते हैं। उन्हें सर्वोत्तम संपीड़न (-m5) से एक आर्काइव में संपीड़ित किया जाता है, जिसका नाम फ़ाइल (बिना उसके एक्सटेंशन), फ़ोल्डर, या कई आइटमों के लिए उनके मूल फ़ोल्डर के नाम पर रखा जाता है। मौजूदा आर्काइव कभी अधिलेखित नहीं होता: report.nik बन जाता है report (2).nik।
• प्रगति एक वृत्ताकार मीटर के अंदर बड़े प्रतिशत के रूप में दिखाई जाती है, साथ में चरण (विश्लेषण, संपीड़न, समापन), संसाधित मात्रा और समय। इसके नीचे Cancel बटन (या Esc कुंजी) लंबे संपीड़न को तुरंत रोक देता है और अधूरा आर्काइव हटा देता है; अगले के लिए विंडो खुली रहती है। संपीड़न के दौरान विंडो बंद करने से भी यही होता है।
• पूर्ण: रिंग हरी हो जाती है और आर्काइव का नाम, मूल की तुलना में उसका आकार और समय दिखाती है। फ़ोल्डर में दिखाएँ इसे Explorer, Finder या फ़ाइल प्रबंधक में खोलता है; और संपीड़ित करें (या वृत्त पर एक क्लिक) अगला शुरू करता है।
• इसमें सहेजें: नीचे का गंतव्य फ़ोल्डर टाइप किया जा सकता है या Browse से चुना जा सकता है। यह अगली बार के लिए याद रखा जाता है (Windows: %APPDATA%\nikpak\settings.txt; macOS: ~/Library/Application Support/nikpak; Linux: ~/.config/nikpak)। पहली बार यह डेस्कटॉप होता है।
• समुदाय: नीचे दाईं ओर के तीन गोल बटन nikpak के Telegram, X और Discord पृष्ठ खोलते हैं (अनुभाग 1.5)।
• unNik पर स्विच करें: i बटन के बाईं ओर ऊपर-तीर वाला गोल बटन NikPak बंद करके unNik शुरू करता है (अनुभाग 3.9)। संपीड़न के बाद, यह और पूर्ण स्क्रीन पर unNik में खोलें लिंक नए आर्काइव को तुरंत खोलते हैं। संपीड़न के दौरान बटन अक्षम रहता है।
• गंतव्य फ़ोल्डर खोलें: इसमें सहेजें फ़ील्ड और Browse के बीच का फ़ोल्डर बटन उस फ़ोल्डर को Explorer या Finder में खोलता है; संपीड़न के बाद यह नए आर्काइव को चयनित करके खोलता है।
• ध्वनियाँ: बटन, लिंक और विकल्पों के लिए एक हल्का क्लिक, और हर क्रिया के लिए एक छोटी ध्वनि (काम शुरू होना, सफलता, त्रुटि, रद्द करना, प्रोग्राम बदलना, विंडो पर फ़ाइलें मँडराना)। ये प्रोग्राम स्वयं बनाता है, कोई ध्वनि फ़ाइलें नहीं। शीर्षक पट्टी में स्पीकर बटन इन्हें बंद और चालू करता है; ये डिफ़ॉल्ट रूप से चालू होती हैं, और यह चुनाव unNik के साथ साझा होता है।
• भाषा: नीचे बाईं ओर का बटन, जिसमें एक झंडा और भाषा का अपना नाम है, दुनिया की दस सबसे अधिक बोली जाने वाली भाषाओं का मेन्यू खोलता है (Ethnologue 2025): English, 中文 (Mandarin Chinese), हिन्दी (Hindi), Español, العربية (Arabic), Français, বাংলা (Bengali), Português, Русский (Russian) और Bahasa Indonesia। किसी एक को चुनने पर वह सहेजी जाती है और nikpak उसी भाषा में पुनः आरंभ होता है। पहली बार, nikpak Windows (या सिस्टम) की भाषा का अनुसरण करता है, अन्यथा English। कमांड लाइन English में ही रहती है।
• व्यवस्थापक के रूप में चलाना: Windows किसी व्यवस्थापक के रूप में चल रहे प्रोग्राम पर Explorer से फ़ाइलें खींचने की अनुमति नहीं देता। जब nikpak.exe व्यवस्थापक के रूप में शुरू किया जाता है (उदाहरण के लिए किसी व्यवस्थापक PowerShell से), तो यह Explorer के माध्यम से खुद को एक बार सामान्य उपयोगकर्ता के रूप में पुनः आरंभ करता है ताकि ड्रैग-और-ड्रॉप काम करे। यदि यह संभव नहीं है, तो विंडो एक सूचना दिखाती है; इसके बजाय बटनों से फ़ाइलें चुनें।
• स्थिति और About: ऊपर बाईं ओर EVALUATION COPY · REGISTER (क्लिक करने पर पंजीकरण बॉक्स खुलता है) या REGISTERED TO और लाइसेंस धारक दिखता है। ऊपर दाईं ओर, न्यूनतम और बंद करने के बगल में छोटा i बटन About बॉक्स खोलता है: संस्करण, © 2026 Nicolas Choukroun, Nikkoid LLC द्वारा वितरित, लाइसेंस स्थिति, वेब साइट और लाइसेंस शर्तें (LICENSE.txt)।

विंडो 500 × 560 पॉइंट मापती है (लगभग 9:10), इसलिए पूरी विंडो का स्क्रीनशॉट बिना काट-छाँट के X (Twitter) चित्र पोस्ट में समा जाता है। यह फ़्रेमरहित है: इसे इसके ऊपरी क्षेत्र से खींचें; ऊपर दाईं ओर के बटन About बॉक्स खोलते हैं, न्यूनतम करते हैं और बंद करते हैं। जब nikpak.exe Explorer से शुरू किया जाता है, तो Windows जो कंसोल विंडो इसके लिए खोलता है वह स्वतः बंद हो जाती है; कमांड प्रॉम्प्ट से शुरू करने पर प्रॉम्प्ट अछूता रहता है। ग्राफ़िकल डिस्प्ले के बिना (उदाहरण के लिए SSH पर), nikpak पहले की तरह अपना उपयोग छापता है। इंटरफ़ेस egui/eframe उपयोग करता है और Inter, Noto Sans SC, Noto Sans Devanagari, Noto Sans Bengali तथा Noto Sans Arabic टाइपफ़ेस के उपसमुच्चय एम्बेड करता है (SIL Open Font License, देखें assets/fonts/OFL.txt)। कमांड-लाइन-केवल एग्ज़िक्यूटेबल cargo build --release --no-default-features से बनाया जाता है।

हिंदी, बंगाली और अरबी को शेपिंग की आवश्यकता होती है: अक्षर रूप बदलते और जुड़ते हैं, मात्राएँ अपने व्यंजन के चारों ओर घूमती हैं, और अरबी दाएँ से बाएँ चलती है। egui प्रति अक्षर एक ग्लिफ़ बनाता है, जो इन भाषाओं को गलत छापेगा, इसलिए nikpak ऐसे टेक्स्ट को Unicode द्विदिशात्मक एल्गोरिदम (unicode-bidi) से क्रमबद्ध करता है, उन्हें rustybuzz (HarfBuzz का Rust पोर्ट) से शेप करता है, ab_glyph से रास्टराइज़ करता है और परिणाम को छवि के रूप में रंगता है (textshape.rs)। इनमें मौजूद लैटिन शब्द और संख्याएँ Inter फ़ॉन्ट रखते हैं। लंबे अनुवाद अपने बटनों में समाने के लिए छोटे किए जाते हैं, और बॉक्स अपने टेक्स्ट के साथ बढ़ते हैं। अनुवाद (i18n.rs) मशीन सहायता से लिखे गए थे; देशी वक्ताओं की समीक्षा स्वागत योग्य है।

3.8 लाइसेंस और पंजीकरण (शेयरवेयर)

NikPak शेयरवेयर है, © 2026 Nicolas Choukroun, Nikkoid LLC द्वारा वितरित, और WinRAR की तरह लाइसेंसित: वही पैकेज निःशुल्क मूल्यांकन प्रति है और, एक बार लाइसेंस कुंजी दर्ज करने पर, पंजीकृत संस्करण बन जाता है। मूल्यांकन प्रति में कुछ भी अक्षम नहीं है।

कौन	शर्तें
व्यक्तिगत उपयोगकर्ता	व्यक्तिगत, गैर-व्यावसायिक उपयोग के लिए निःशुल्क, बिना समय सीमा के। एक व्यक्तिगत लाइसेंस ($19) अनुस्मारक हटा देता है; यह धारक द्वारा उपयोग किए जाने वाले सभी कंप्यूटरों को कवर करता है।
कंपनियाँ और संगठन	प्रति सीट एक कंपनी लाइसेंस, निःशुल्क 40-दिन के मूल्यांकन के बाद; सीटें कंप्यूटर या उपयोगकर्ता होती हैं, जो भी अधिक हो। प्रति सीट थोक मूल्य, WinRAR पर आधारित: 1–9 सीटें $19, 10–24 $15, 25–49 $12, 50–99 $9, 100–199 $7, 200–499 $6, 500 और अधिक $5।
वितरण	असंशोधित पैकेज (LICENSE.txt और THIRD-PARTY-NOTICES.txt सहित) किसी भी शेयरवेयर या डाउनलोड साइट पर रखा जा सकता है; कुंजियाँ, कुंजी फ़ाइलें या क्रैक जोड़ना निषिद्ध है। .nik आर्काइव रॉयल्टी-मुक्त हैं।

• अनुस्मारक तब दिखता है जब कोई अपंजीकृत प्रति अपनी विंडो खोलती है। इसमें दो बटन होते हैं, पंजीकृत करें और मुफ़्त में आज़माएँ, जिनका बायाँ/दायाँ क्रम हर बार शुरू होने पर यादृच्छिक रूप से बदलता है। मुफ़्त में आज़माएँ (या Esc) इसे बंद कर देता है; nikpak फिर बिना किसी प्रतिबंध के काम करता है।
• पंजीकरण बॉक्स नाम, ई-मेल पता और लाइसेंस कुंजी माँगता है। तीनों का मेल खाना आवश्यक है: कुंजी नाम और ई-मेल का हस्ताक्षर है। अक्षरों का आकार, अतिरिक्त रिक्त स्थान और मिलते-जुलते अक्षर O/0 तथा I/L/1 मायने नहीं रखते। लाइसेंस खरीदें https://nikpak.nikkoid.com/buy.php खोलता है।
• एक बार पंजीकृत होने पर nikpak उस कंप्यूटर पर उस उपयोगकर्ता के लिए फिर कभी नहीं पूछता। लाइसेंस %APPDATA%\nikpak\license.txt में संग्रहित होता है (macOS: ~/Library/Application Support/nikpak; Linux: ~/.config/nikpak)। कोई कंपनी इसके बजाय nikpak.exe के बगल में एक फ़ाइल nikpak.key रख सकती है, जो उस PC के हर उपयोगकर्ता को पंजीकृत करती है।
• कमांड लाइन: nikpak register "Jane Doe" jane@example.com NPK1-… पंजीकृत करता है; nikpak license स्थिति दिखाता है; nikpak unregister लाइसेंस हटाता है। nikpak -V और nikpak -help भी स्थिति दिखाते हैं। अपंजीकृत प्रतियाँ त्रुटि आउटपुट (stderr) पर एक-पंक्ति मूल्यांकन सूचना छापती हैं, मानक आउटपुट पर कभी नहीं; -q इसे दबा देता है।

कुंजियाँ कैसे काम करती हैं

एक लाइसेंस कुंजी NPK1- के बाद पाँच-पाँच के समूहों में 108 अक्षरों के रूप में पढ़ी जाती है (Crockford base32)। इसमें लाइसेंस प्रकार (व्यक्तिगत या कंपनी), सीटों की संख्या और NIKPAK-LICENSE-1, प्रकार, सीटें, नाम तथा ई-मेल पते का Ed25519 हस्ताक्षर होता है, प्रत्येक सामान्यीकृत (रिक्त स्थान हटाए गए, छोटे अक्षर)। nikpak में केवल 32-बाइट सार्वजनिक कुंजी होती है, src/license_pubkey.rs में, इसलिए प्रोग्राम का अध्ययन करके कोई भी कुंजियाँ नहीं बना सकता।

कुंजियाँ निजी कुंजी से बनाई जाती हैं, जो कभी Nikkoid LLC से बाहर नहीं जाती: या तो निजी टूल nikpak-keygen से (cargo run --release --features keygen --bin nikpak-keygen -- make --name "Jane Doe" --email jane@example.com; कंपनियों के लिए --company --seats 25; newkeys एक नई कुंजी जोड़ी बनाता है) या वेब सर्वर पर server/ में PHP किट (PHP 7.2+, MySQL 5.7) से, जो हर भुगतान पर एक कुंजी जारी करता है और बिल्कुल वही कुंजियाँ बनाता है। server/README.md सेटअप और भुगतान प्रवाह का वर्णन करता है।

3.9 unNik, निःशुल्क आर्काइव ब्राउज़र

unNik (unNik.exe) पैकेज का दूसरा प्रोग्राम है। यह .nik आर्काइव खोलता है, दिखाता है कि अंदर क्या है और जो आप चुनते हैं उसे निकालता है। यह सभी के लिए निःशुल्क है, कंपनियों सहित, बिना पंजीकरण और बिना अनुस्मारक के (LICENSE.txt, अनुभाग 2a)। सेटअप इसे nikpak.exe के बगल में स्थापित करता है, इसे स्टार्ट मेन्यू में जोड़ता है और इसे .nik फ़ाइलों का प्रोग्राम बना देता है, ताकि किसी आर्काइव पर डबल-क्लिक उसे unNik में खोल दे; unNik archive.nik कमांड प्रॉम्प्ट से भी यही करता है।

खाली विंडो बिल्कुल NikPak जैसी दिखती है, रिंग में ऊपर जाते तीर के साथ। इस पर एक .nik आर्काइव ड्रॉप करें, रिंग पर क्लिक करें, या हाल के आर्काइवों में से एक चुनें: विंडो ब्राउज़र में बड़ी हो जाती है (1120 × 720, किनारों से आकार बदलने योग्य, और इसे अधिकतम किया जा सकता है)। एन्क्रिप्टेड आर्काइव पहले अपना पासवर्ड माँगते हैं।

• नेविगेट करें फ़ोल्डर ट्री, ब्रेडक्रम्ब्स, Back, Forward और Up (Alt+Left, Alt+Right, Backspace) तथा डबल-क्लिक से। खोज (Ctrl+F) पूरे आर्काइव में नाम से फ़ाइलें ढूँढती है; हर परिणाम अपना फ़ोल्डर दिखाता है।
• चुनें एक क्लिक, Ctrl+क्लिक, Shift+क्लिक, चेक बॉक्स, Ctrl+A या तीर कुंजियों से। नाम, आकार, प्रकार या तिथि से क्रमबद्ध करने के लिए कॉलम शीर्षक पर क्लिक करें। राइट-क्लिक हर क्रिया वाला मेन्यू खोलता है।
• सभी निकालें, या चयन (Ctrl+E): गंतव्य चुनें (डिफ़ॉल्ट रूप से आर्काइव के नाम पर एक फ़ोल्डर, उसके बगल में), फ़ोल्डर रखें या नहीं, और जब कोई फ़ाइल पहले से मौजूद हो तो क्या करें: उसे बदलें, दोनों रखें (name (1).ext) या उसे छोड़ें। किसी फ़ोल्डर के अंदर से ली गई फ़ाइलें उस फ़ोल्डर के पथ के बिना बनाई जाती हैं, जैसा WinRAR में होता है। पढ़ना अंतिम चुनी गई फ़ाइल के तुरंत बाद रुक जाता है।
• देखें (F3, या टेक्स्ट फ़ाइल पर डबल-क्लिक): पंक्ति संख्याओं वाला टेक्स्ट, हाइलाइटिंग के साथ खोज, पंक्ति लपेटन और कॉपी; बाइनरी फ़ाइलें हेक्साडेसिमल में। पहले 16 MB दिखाए जाते हैं; Notepad में खोलें पूरी फ़ाइल खोलता है। खोलें किसी फ़ाइल को उसके अपने प्रोग्राम से शुरू करता है (पहले उसे एक अस्थायी फ़ोल्डर में निकाला जाता है)।
• हटाएँ (Del) पुष्टि के बाद आर्काइव से फ़ाइलें और फ़ोल्डर हटाता है। आर्काइव सॉलिड है, इसलिए इसे उनके बिना फिर से लिखा जाता है, एक अस्थायी फ़ाइल में जो मूल को तभी बदलती है जब सब कुछ सफल हुआ हो। एन्क्रिप्टेड आर्काइव अपना पासवर्ड बनाए रखते हैं; बाकी प्रविष्टियाँ अपना मीडिया या Deflate फ़िल्टर और अपना -m5 इंजन बनाए रखती हैं।
• परीक्षण पूरे आर्काइव को डीकंप्रेस करता है और हर फ़ाइल जाँचता है। विवरण फलक आकार, तिथि, फ़ोल्डर, CRC32, फ़ाइल कैसे संग्रहित है और उसके गुण दिखाता है; स्वयं आर्काइव के लिए उसका आकार, विधि और एन्क्रिप्शन। ट्री के नीचे का सारांश बचाया गया स्थान दिखाता है।
• वही दस भाषाएँ, भाषा बटन, About बॉक्स (i) और सामुदायिक बटन जैसे NikPak में। किसी भी लिपि के फ़ाइल नाम फ़ॉलबैक के रूप में सिस्टम के फ़ॉन्ट से बनाए जाते हैं।
• NikPak पर स्विच करें: i बटन के बाईं ओर नीचे-तीर वाला गोल बटन unNik बंद करके NikPak शुरू करता है। दोनों प्रोग्राम एक ही फ़ोल्डर में मिलते हैं। वे एक सेटिंग्स फ़ाइल साझा करते हैं, इसलिए एक में चुनी गई भाषा दूसरे में उपयोग होती है, और जो विंडो पहले से खुली है वह दो सेकंड के भीतर बदलाव का अनुसरण करती है।
• गंतव्य फ़ोल्डर खोलें: इजेक्ट बटन के बाईं ओर का बटन अंतिम निष्कर्षण के फ़ोल्डर को Explorer या Finder में खोलता है (किसी भी निष्कर्षण से पहले, आर्काइव का फ़ोल्डर)। unNik NikPak जैसी ही ध्वनियाँ बजाता है, आर्काइव खोलने, निकालने, हटाने और परीक्षण की ध्वनियों के साथ; इसका स्पीकर बटन और NikPak का स्पीकर बटन एक सेटिंग साझा करते हैं।

3.10 स्किन

NikPak और unNik वही 55 विंडो स्किन साझा करते हैं: Nikkomander की 41 स्किन — Nikkoid Blue (डिफ़ॉल्ट) और Nikkoid Bright से लेकर Dracula, Nord, Solarized, Classic Blue, Matrix, Pizza, Christmas और 8-Bit Game तक — साथ ही 14 चित्रित स्किन जिनकी पृष्ठभूमि प्रोग्राम स्वयं बनाता है: Moon, America, Pattaya Neons, Burgers Tokyo, Sushi, Amiga, MSX, Colecovision, ZX Spectrum, Cat Life, Dog Life, Mario Bros, Counter Strike और Chess।

• स्किन बटन (एक पैलेट, दोनों प्रोग्रामों की शीर्षक पट्टी में): स्किन मेन्यू खोलता है, जहाँ हर स्किन अपने रंगों में बनी होती है। किसी स्किन पर इंगित करने से वह पूरी विंडो पर दिखती है; एक क्लिक उसे रख लेता है; Esc या बाहर क्लिक आपको पहले वाली स्किन पर लौटा देता है।
• सूर्य / चंद्रमा बटन उसके बगल में एक क्लिक में Nikkoid Blue (गहरा) और Nikkoid Bright के बीच स्विच करता है।
• स्किन बॉक्स प्रोग्राम के बाहर खड़ा रहता है। जब बॉक्स खुला होता है तो विंडो बॉक्स की चौड़ाई जितनी दाईं ओर चौड़ी हो जाती है: प्रोग्राम अपना 500 × 560 पैनल बनाए रखता है और बॉक्स उसके बगल के अतिरिक्त पारदर्शी स्थान में बैठता है, ताकि आज़माई जा रही स्किन के पीछे पूरा इंटरफ़ेस दिखाई देता रहे। बॉक्स को उसकी शीर्षक पट्टी से वापस प्रोग्राम के ऊपर या विंडो में कहीं और खींचा जा सकता है, और इसमें स्किन लागू करें और रद्द करें बटन हैं। किसी स्किन पर क्लिक उसे पूरी विंडो पर आज़माता है; लागू करें उसे रखता और दोनों प्रोग्रामों के लिए सहेजता है; रद्द करें (या Esc या ×) आपको पहले वाली स्किन पर लौटा देता है। प्रोग्राम पर क्लिक अब बॉक्स बंद नहीं करता। unNik की विंडो चौड़ी नहीं की जाती।
• चुनी गई स्किन सहेजी जाती है (सेटिंग्स फ़ाइल में skin=) और साझा होती है: एक प्रोग्राम में चुनी गई स्किन दूसरे द्वारा दो सेकंड के भीतर ले ली जाती है।
• आपकी अपनी स्किन: मेन्यू के नीचे “Import a skin…” एक Nikkomander .skin.json फ़ाइल (एक नाम और रंगों की सूची) पढ़ता है और उसे सेटिंग्स फ़ाइल के बगल वाले skins फ़ोल्डर में कॉपी करता है; आयातित स्किन की टाइल पर × उसे हटा देता है।
• चित्रित स्किन इंटरफ़ेस के पीछे चली जाती हैं। चित्रित पृष्ठभूमियाँ src/skin_scenes.rs द्वारा बनाई जाती हैं, CSS ग्रेडिएंट से नहीं, इसलिए वे किसी भी विंडो आकार में फैल जाती हैं। 1.6.2 से हर एक discreet() चरण से गुजरती है जो src/skin.rs में है: कला को अपने स्थानीय औसत की ओर खींचा जाता है, हल्का धुंधला किया जाता है और स्किन के पृष्ठभूमि रंग की ओर फीका किया जाता है — सबसे अधिक ड्रॉप रिंग और टेक्स्ट कॉलम के पीछे, लोगो के ऊपर थोड़ा अधिक — ताकि शीर्षक, रिंग और स्थिति टेक्स्ट सभी चौदह पर स्पष्ट रहें।

3.11 फ़ाइल-प्रबंधक मेन्यू

फ़ाइल प्रबंधक के राइट-क्लिक मेन्यू में एक “NikPak” सबमेन्यू, WinRAR की तरह, सेटअप द्वारा स्थापित किया जाता है (Windows: डिफ़ॉल्ट रूप से चेक किया गया विकल्प; Linux: nikpak --install-menu; macOS: Finder Quick Actions)।

• फ़ाइलों और फ़ोल्डरों पर: आर्काइव में जोड़ें… (नाम और फ़ोल्डर माँगता है, फिर NikPak विंडो में संपीड़ित करता है) और यहाँ आर्काइव में जोड़ें (आर्काइव आइटमों के बगल में जाता है, नाम विंडो पर ड्रॉप जैसा रखा जाता है)।
• .nik आर्काइवों पर: unNik के साथ खोलें, फ़ाइलें निकालें…, यहाँ निकालें और इसके अपने फ़ोल्डर में निकालें।
• कई आइटम एक आर्काइव में जाते हैं; कई चयनित आर्काइव एक विंडो में एक के बाद एक निकाले जाते हैं।
• कमांड unNik.exe के माध्यम से चलती हैं, इसलिए कोई कंसोल विंडो चमकती नहीं; लेबल NikPak की भाषा का अनुसरण करते हैं। Windows 10 सबमेन्यू सीधे दिखाता है, Windows 11 अधिक विकल्प दिखाएँ (Shift+F10) के अंतर्गत; Linux KDE Dolphin सर्विस मेन्यू, Nemo क्रियाएँ और Nautilus स्क्रिप्ट जोड़ता है, और macOS Finder Quick Actions जोड़ता है।
• मेन्यू द्वारा उपयोग किए जाने वाले नए कमांड-लाइन विकल्प: nikpak --add और --add-here (दिए गए आइटम संपीड़ित करते हैं), nikpak --install-menu, --uninstall-menu और --all-users; unNik --extract, --extract-here और --extract-to। यहाँ निकालें / इसके अपने फ़ोल्डर में निकालें unNik की छोटी विंडो को प्रगति रिंग के साथ दिखाते हैं (एन्क्रिप्टेड आर्काइवों के लिए पासवर्ड बॉक्स) और सब कुछ निकल जाने पर उसे बंद कर देते हैं; चेतावनियाँ और त्रुटियाँ स्क्रीन पर रहती हैं।
• एक दूसरा सेटअप, unnik--setup.exe, उन लोगों के लिए अकेले unNik (निःशुल्क ब्राउज़र) स्थापित करता है जो केवल .nik आर्काइव प्राप्त करते हैं; जब NikPak पहले से स्थापित है तो यह केवल प्रोग्राम स्थापित करता है, ताकि मेन्यू कभी दोहरे न हों।

4 आर्किटेक्चर

nikpak एक एकल Rust प्रोग्राम है जो लगभग 9,600 पंक्तियों (अपने यूनिट परीक्षणों सहित) का है, सोलह स्रोत फ़ाइलों में, साथ ही निजी लाइसेंस टूल nikpak-keygen। इसका केंद्रीय डिज़ाइन नियम स्ट्रीमिंग है: फ़ाइलें 256 KiB टुकड़ों में पढ़ी जाती हैं, राइटरों की श्रृंखला से गुजारी जाती हैं, और कभी भी पूरी मेमोरी में नहीं रखी जातीं (एकमात्र अपवाद BMP पिक्सेल डेटा हैं, जो 256 MiB तक सीमित हैं, और कोडेक के 64 KiB कार्य बफ़र)।

4.1 आर्काइव बनाते समय डेटा प्रवाह

हर चरण मानक Write ट्रेट का एक कार्यान्वयन है जो अगले के चारों ओर लिपटा होता है, इसलिए वही कोड पथ एक सादे आर्काइव, एक एन्क्रिप्टेड आर्काइव और मीडिया परीक्षण को सेवा देता है।

4.2 स्रोत कोड मानचित्र

फ़ाइल	जिम्मेदारी
main.rs	प्रवेश बिंदु। आर्गुमेंट पार्स करता है, कमांड भेजता है, त्रुटियों को एग्ज़िट कोड में बदलता है। बंद पाइप को शांति से संभालता है (nikpak lb x | head)।
cli.rs	हस्तलिखित RAR/zip-शैली आर्गुमेंट पार्सर, विकल्प तालिकाएँ और पूरा -help टेक्स्ट। Clap-शैली लाइब्रेरियाँ -pSECRET या -m5 जैसे स्विचों को साफ-सुथरा व्यक्त नहीं कर सकतीं।
archive.rs	बनाएँ, सूचीबद्ध करें, परीक्षण करें, निकालें (फ़िल्टर द्वारा या सटीक चयन द्वारा), हटाएँ, छापें और मीडिया परीक्षण; साथ ही unNik द्वारा उपयोग किया जाने वाला सूचकांक और एकल-फ़ाइल पठन। इसमें प्रविष्टि-स्ट्रीम राइटर और रीडर, ओवरराइट नीति और परमाणु अस्थायी-फ़ाइल तर्क शामिल हैं।
media.rs	WAV, AIFF, MOD और BMP के लिए सामग्री पहचान; Shuffle, Delta और MED फ़िल्टर; परीक्षण चयन; CRC और चंक-फ़्रेमिंग सहायक।
nac.rs	NAC दोषरहित ऑडियो कोडेक: स्टीरियो डीकोरिलेशन, प्रेडिक्टर, रेज़िडुअल कोडिंग।
bits.rs	NAC द्वारा उपयोग किया जाने वाला MSB-प्रथम बिट राइटर और रीडर।
crypto.rs	Argon2id कुंजी व्युत्पत्ति और XChaCha20-Poly1305 चंक राइटर तथा रीडर।
format.rs	डिस्क पर प्रारूप के स्थिरांक: मैजिक, संस्करण, रिकॉर्ड प्रकार, KDF सीमाएँ।
util.rs	पासवर्ड संकेत और निर्माण, पथ सफ़ाई, वाइल्डकार्ड मिलान, तिथि और आकार फ़ॉर्मेटिंग।
error.rs	त्रुटि प्रकार, उसके एग्ज़िट कोड, और I/O त्रुटियों का वर्गीकरण (भ्रष्टता बनाम सिस्टम विफलता)।
engine.rs	-m5 की मल्टी-इंजन बॉडी: ब्लॉक राइटर और रीडर, LZMA2 तथा PPMd इंजन, इंजन परीक्षण (अनुभाग 5.6, 6.7)।
recomp.rs	preflate से ZIP कंटेनरों, PDF और gzip का Deflate पुनर्संपीड़न (अनुभाग 7.9)।
gui.rs	ग्राफ़िकल इंटरफ़ेस: ड्रॉप विंडो, प्रगति रिंग, गंतव्य सेटिंग, सामुदायिक लिंक (अनुभाग 3.7)।
unnik.rs	unNik, आर्काइव ब्राउज़र: ट्री, सूची, खोज, व्यूअर, निष्कर्षण और हटाने के बॉक्स (अनुभाग 3.9)।
lib.rs, bin/unnik.rs	nikpak और unNik द्वारा साझा लाइब्रेरी, और unNik.exe का प्रवेश बिंदु (एक विंडो प्रोग्राम, कोई कंसोल नहीं)।
license.rs	शेयरवेयर लाइसेंस: कुंजी प्रारूप, Ed25519 सत्यापन, लाइसेंस संग्रहण, पंजीकरण (अनुभाग 3.8)।
i18n.rs	विंडो का दस सबसे अधिक बोली जाने वाली भाषाओं में अनुवाद; भाषा सेटिंग (अनुभाग 3.7)।
textshape.rs	हिंदी, बंगाली और अरबी के लिए शेप किया गया टेक्स्ट: बाइडी क्रमबद्धता, शेपिंग, रास्टराइज़िंग (अनुभाग 3.7)।

4.3 आर्काइव बनाना, चरण दर चरण

• सत्यापित करें आउटपुट स्थान। मौजूदा आर्काइव केवल -o+ (या इंटरैक्टिव हाँ) से बदला जाता है; अन्यथा nikpak समझाता है कि जोड़ना समर्थित नहीं है।
• एकत्र करें इनपुट: वाइल्डकार्ड विस्तारित किए जाते हैं (PowerShell ऐसा नहीं करता), @listfiles पढ़े जाते हैं, बहिष्करण लागू होते हैं, सिमलिंक और विशेष फ़ाइलें चेतावनी के साथ छोड़ दी जाती हैं, और आर्काइव कभी खुद में नहीं जोड़ा जाता।
• पासवर्ड तय करें यदि एन्क्रिप्शन माँगा गया था (अनुभाग 3.3) और Argon2id से कुंजी व्युत्पन्न करें।
• हेडर लिखें, फिर राइटर श्रृंखला बनाएँ: फ़ाइल, बफ़र्ड राइटर, वैकल्पिक चंक एन्क्रिप्टर, Zstandard एनकोडर।
• हर प्रविष्टि लिखें। मीडिया फ़ाइलें पहचान और परीक्षण से गुजरती हैं (अध्याय 7); बाकी सब कुछ 256 KiB टुकड़ों में कॉपी होता है जबकि CRC32 की गणना की जाती है।
• अंत चिह्न लिखें प्रविष्टि गणना के साथ, Zstandard फ़्रेम पूरा करें, अंतिम एन्क्रिप्टेड चंक सील करें और डिस्क पर फ्लश करें।
• नाम बदलें name.nik.tmp से name.nik। यदि पहले कुछ विफल होता है, तो एक गार्ड ऑब्जेक्ट अस्थायी फ़ाइल हटा देता है, ताकि आधा लिखा आर्काइव कभी अच्छे आर्काइव को न बदले।

4.4 आर्काइव निकालना, चरण दर चरण

• हेडर पढ़ें और सत्यापित करें: मैजिक, संस्करण, फ़्लैग, विधि और, एन्क्रिप्टेड आर्काइव के लिए, Argon2id पैरामीटर, जिन्हें कोई मेमोरी आवंटित होने से पहले सीमा-जाँचा जाता है।
• पासवर्ड प्राप्त करें और कुंजी व्युत्पन्न करें। पहला प्रमाणित चंक फिर पासवर्ड को सिद्ध या असिद्ध करता है।
• प्रविष्टि स्ट्रीम पर चलें। किसी भी फ़ाइल-सिस्टम पहुँच से पहले हर प्रविष्टि नाम साफ़ किया जाता है (अनुभाग 10.1)।
• फ़ाइलें लिखें create_new के साथ, टाइमस्टैम्प और अनुमतियाँ सेट करें, और पुनर्निर्मित बाइट्स का CRC32 सत्यापित करें। जो फ़ाइल अपना CRC विफल करती है उसे रखने के बजाय हटा दिया जाता है।
• अंत सत्यापित करें आर्काइव का: अंत चिह्न के बाद स्ट्रीम वास्तव में समाप्त होनी चाहिए और, यदि एन्क्रिप्टेड है, अंतिम प्रमाणित चंक संसाधित हुआ होना चाहिए। यह कटाव और जोड़े गए डेटा को पकड़ता है।

4.5 मेमोरी और थ्रेडिंग

Zstandard संपीड़न के लिए वर्कर थ्रेड उपयोग करता है (डिफ़ॉल्ट रूप से सभी कोर, सीमित करने के लिए -mt)। डीकंप्रेशन, ऑडियो कोडेक और एन्क्रिप्शन कॉलिंग थ्रेड पर चलते हैं। Argon2id को कुंजी व्युत्पत्ति के लिए 64 MiB चाहिए, और सबसे ऊँचे दो स्तर 128 MiB मिलान विंडो उपयोग करते हैं, इसलिए ऐसे आर्काइवों को डीकंप्रेस करने के लिए उतनी ही मेमोरी चाहिए।

5 .nik कंटेनर प्रारूप

एक .nik फ़ाइल एक छोटा स्थिर हेडर होता है जिसके बाद बॉडी आती है। बॉडी एक सॉलिड स्ट्रीम है: सभी प्रविष्टियाँ जोड़ी जाती हैं, एक साथ संपीड़ित होती हैं, और वैकल्पिक रूप से एन्क्रिप्ट होती हैं। प्रारूप का संस्करण 2 मीडिया रिकॉर्ड जोड़ता है; संस्करण 1 के आर्काइव पठनीय रहते हैं।

5.1 हेडर

ऑफ़सेट	आकार	फ़ील्ड	टिप्पणियाँ
0	8	मैजिक	89 4E 49 4B 0D 0A 1A 0A (PNG विचार: टेक्स्ट-मोड स्थानांतरण क्षति का पता लगाता है)
8	1	संस्करण	3 (1 और 2 अभी भी पठनीय हैं)
9	1	फ़्लैग	बिट 0 = एन्क्रिप्टेड; अन्य बिट 0 होने चाहिए
10	1	विधि	0 = स्टोर, 1 = Zstandard, 2 = मल्टी-इंजन ब्लॉक (5.6)
11	1	आरक्षित	0
12	4	Argon2id मेमोरी (KiB)	केवल एन्क्रिप्टेड आर्काइव, लिटिल एंडियन
16	4	Argon2id पास	केवल एन्क्रिप्टेड
20	4	Argon2id लेन	केवल एन्क्रिप्टेड
24	16	सॉल्ट	प्रति आर्काइव यादृच्छिक, केवल एन्क्रिप्टेड
40	19	स्ट्रीम नॉन्स उपसर्ग	प्रति आर्काइव यादृच्छिक, केवल एन्क्रिप्टेड

पूरा हेडर (12 बाइट, या एन्क्रिप्टेड होने पर 59 बाइट) बाद में हर एन्क्रिप्टेड चंक के एसोसिएटेड डेटा के रूप में प्रमाणित किया जाता है, इसलिए इसे बिना पहचान के बदला नहीं जा सकता।

5.2 प्रविष्टि रिकॉर्ड

(डिक्रिप्टेड, डीकंप्रेस्ड) स्ट्रीम के अंदर हर प्रविष्टि एक रिकॉर्ड है। सभी पूर्णांक लिटिल एंडियन हैं।

प्रकार	लेआउट
0 END	count:u64। अंत को चिह्नित करता है और बताता है कि उससे पहले कितनी प्रविष्टियाँ हैं।
1 FILE	name_len:u16 name mtime:i64 mode:u32 size:u64 data[size] crc32:u32
2 DIR	name_len:u16 name mtime:i64 mode:u32
3 MEDIA	name_len:u16 name mtime:i64 mode:u32 size:u64 filter:u8 method:u8 params_len:u8 params framed_stream crc32:u32

• नाम UTF-8 हैं / विभाजकों के साथ, अधिकतम 4096 बाइट।
• mtime Unix सेकंड है; mode Unix अनुमति शब्द है (Windows फ़ाइलों को 0644 या 0755 मिलता है, केवल-पठन होने पर 0444)।
• CRC32 हमेशा मूल बाइट्स को कवर करता है, जो मीडिया फ़िल्टरों को सत्यापन योग्य बनाता है।
• MEDIA रिकॉर्ड में size मूल आकार है। framed_stream [u32 length][bytes] चंकों की एक श्रृंखला है जो शून्य लंबाई पर समाप्त होती है, इसलिए रीडर हमेशा किसी मीडिया प्रविष्टि को उसके फ़िल्टर को समझे बिना छोड़ सकता है।

मीडिया पैरामीटर

फ़िल्टर	पैरामीटर	सामग्री
1 ऑडियो	19 बाइट	offset:u64 frames:u64 channels:u8 bits:u8 flags:u8 (फ़्लैग बिट 0 = बिग एंडियन, बिट 1 = चिह्नित)
2 छवि	21 बाइट	offset:u64 width:u32 rows:u32 bpp:u8 stride:u32
3 Deflate	0 बाइट	none: the framed stream holds raw segments and recompressed Deflate streams (section 7.9)

offset से पहले की हर चीज़ (हेडर, टैग, पैलेट, MOD पैटर्न) और सैंपल या पिक्सेल क्षेत्र के बाद की हर चीज़ (अनुगामी चंक) फ़िल्टर किए गए डेटा के चारों ओर अपरिवर्तित संग्रहित की जाती है।

5.3 एन्क्रिप्टेड बॉडी फ़्रेमिंग

जब एन्क्रिप्टेड फ़्लैग सेट होता है, तो zstd आउटपुट 64 KiB प्लेनटेक्स्ट के चंकों में काटा जाता है। हर चंक एक 32-बिट बिग-एंडियन लंबाई के रूप में संग्रहित होता है जिसके बाद सिफरटेक्स्ट आता है, जो Poly1305 टैग के कारण 16 बाइट लंबा होता है। एक चंक तभी सील किया जाता है जब कम से कम एक और बाइट बाद में आती है, इसलिए अंतिम चंक कभी खाली नहीं होता और उसे अंतिम के रूप में चिह्नित किया जा सकता है (अनुभाग 8.3)।

5.4 सॉलिड स्ट्रीम क्यों?

सभी फ़ाइलों को एक स्ट्रीम के रूप में संपीड़ित करने से कंप्रेसर फ़ाइलों के बीच दोहराव ढूँढ सकता है, जो स्रोत ट्री और दस्तावेज़ संग्रहों के लिए बहुत मायने रखता है (अध्याय 11 का बेंचमार्क दिखाता है कि RAR का नॉन-सॉलिड आउटपुट 10,949 फ़ाइलों पर उसके सॉलिड आउटपुट से लगभग दोगुना बड़ा है)। कीमत अनुक्रमिक पहुँच है: एक फ़ाइल निकालने के लिए उससे पहले की सामग्री डीकंप्रेस करनी पड़ती है। nikpak मीडिया प्रविष्टियों के लिए इसकी लागत घटाता है, उन्हें डिकोड किए बिना छोड़ कर।

5.5 संस्करण प्रबंधन

संस्करण बाइट की जाँच प्रोग्राम द्वारा समझे जाने वाले उच्चतम संस्करण से की जाती है। नया आर्काइव एक भ्रामक भ्रष्टता त्रुटि के बजाय संदेश Unsupported archive version N; please update nikpak देता है। अज्ञात फ़्लैग, विधियाँ या मीडिया फ़िल्टर उसी तरह अस्वीकार किए जाते हैं।

5.6 मल्टी-इंजन बॉडी (संस्करण 3)

-m5 से बने आर्काइव विधि 2 उपयोग करते हैं। 5.2 में वर्णित आंतरिक रिकॉर्ड स्ट्रीम अपरिवर्तित रहती है, लेकिन इसे, केवल प्रविष्टियों के बीच, ब्लॉकों में काटा जाता है, और हर ब्लॉक अपने इंजन से संपीड़ित होता है। जोड़ने पर, डीकंप्रेस्ड ब्लॉक बिल्कुल एकल-इंजन आर्काइव की रिकॉर्ड स्ट्रीम होते हैं, इसलिए सूचीबद्ध करना, परीक्षण और निष्कर्षण एक जैसे काम करते हैं।

तत्व	लेआउट
body	block* जिसके बाद एक 0 बाइट
block	engine:u8 पैरामीटर, फिर फ़्रेम [u32 length 1 .. 1 MiB][compressed bytes], शून्य लंबाई पर समाप्त
इंजन 1	Zstandard (कोई पैरामीटर नहीं)
इंजन 2	LZMA2 रॉ स्ट्रीम: dictionary size u32, lc u8, lp u8, pb u8
इंजन 3	PPMd variant I (PPMd8): order u8, model size u32, restore method u8 (0 = restart)

फ़्रेमिंग रीडर को हर ब्लॉक का अंत डिकोडर पर भरोसा किए बिना खोजने देती है, और हर पैरामीटर मेमोरी आवंटन से पहले सीमा-जाँचा जाता है (LZMA2 डिक्शनरी अधिकतम 1.5 GiB, PPMd मॉडल अधिकतम 1 GiB, order 2 से 16)। एन्क्रिप्टेड होने पर, बॉडी किसी भी अन्य आर्काइव की तरह वही प्रमाणित चंकों से सुरक्षित होती है (अध्याय 8)।

6 संपीड़न इंजन

6.1 Zstandard क्यों

Zstandard LZ77 मिलान को Huffman कोडिंग और फ़िनाइट-स्टेट एन्ट्रॉपी (FSE) से बने एन्ट्रॉपी चरण के साथ जोड़ता है। ZIP के Deflate एल्गोरिदम की तुलना में यह कहीं बड़ी विंडो में मिलान ढूँढता है, लिटरल और मिलान लंबाइयों को कसी हुई एन्ट्रॉपी कोड से मॉडल करता है, और गीगाबाइट प्रति सेकंड की गति से डिकोड करता है। यह एक खुला, व्यापक रूप से ऑडिट किया गया प्रारूप भी है, जो nikpak के डेटा को स्वतंत्र टूल्स द्वारा पुनर्प्राप्त करने योग्य बनाए रखता है।

6.2 स्तर मैपिंग

nikpak RAR-शैली स्तर (-m0 .. -m5) और zip-शैली स्तर (-0 .. -9) दोनों स्वीकार करता है और उन्हें Zstandard स्तरों पर मैप करता है:

विकल्प	Zstandard स्तर	विशेषता
-m0	none (स्टोर)	कोई संपीड़न नहीं, कोई मीडिया फ़िल्टर नहीं
-m1	1	सबसे तेज़
-m2	3	तेज़; एक कोर पर 197 MB के लिए लगभग 0.9 s (1.2.0 तक डिफ़ॉल्ट)
-m3	9	अच्छा संतुलन
-m4	15	उच्च; 128 MiB विंडो और लंबी-दूरी मिलान; Deflate पुनर्संपीड़न (7.9)
-m5 (default)	LZMA2 / PPMd	अधिकतम, और 1.2.1 से डिफ़ॉल्ट: मल्टी-इंजन बॉडी (6.7) और Deflate पुनर्संपीड़न

zip-शैली स्तर इस प्रकार मैप होते हैं: -0 स्टोर करता है, -1 से -6 Zstandard 1 से 6 उपयोग करते हैं, -7 9 उपयोग करता है, -8 12 उपयोग करता है और -9 -m5 के समान है।

6.3 बड़ी विंडो और लंबी-दूरी मिलान

Zstandard स्तर 15 और उससे ऊपर nikpak 2^27 बाइट (128 MiB) मिलान विंडो और लंबी-दूरी मिलान सक्षम करता है। स्रोत ट्री, दस्तावेज़ सेट और बैकअप में कई लगभग-समान फ़ाइलें होती हैं जो स्ट्रीम में दूर-दूर होती हैं; एक सामान्य 8 MiB विंडो उनके पार नहीं देख सकती। 197 MB परीक्षण सेट पर इसने -m5 पर आउटपुट 26.3 MB से घटाकर 24.4 MB और -m4 पर 29.5 MB से 26.8 MB कर दिया, -m4 के लिए बिना गति-हानि और -m5 के लिए थोड़ी-सी। 2^27 की विंडो Zstandard की डिफ़ॉल्ट डिकोडर सीमा के भीतर है, इसलिए कोई भी मानक डिकोडर डेटा पढ़ सकता है।

6.4 मल्टी-थ्रेडिंग

एनकोडर इनपुट को जॉबों में बाँटता है जो वर्कर थ्रेडों पर चलते हैं (डिफ़ॉल्ट रूप से सभी कोर)। इसलिए संपीड़न गति कोरों की संख्या के साथ बढ़ती है, जबकि प्रारूप एक ही स्ट्रीम रहता है। इस गाइड के सभी आँकड़े एक कोर पर मापे गए थे; एक सामान्य मल्टी-कोर मशीन पर nikpak दिखाए गए से काफ़ी तेज़ है।

6.5 स्ट्रीम के अंदर अखंडता

Zstandard फ़्रेम अपना सामग्री चेकसम रखता है, nikpak प्रति फ़ाइल एक CRC32 और प्रविष्टि गणना वाला एक अंत चिह्न जोड़ता है। इसलिए क्षतिग्रस्त सादा आर्काइव तीन स्तरों पर पकड़ा जाता है: फ़्रेम चेकसम, प्रति-फ़ाइल CRC और अंत चिह्न।

6.6 स्टोर मोड

-m0 प्रविष्टियों को असंपीड़ित लिखता है। यह पहले से संपीड़ित डेटा के लिए उपयोगी है, और यह एकमात्र मोड भी है जिसमें मीडिया फ़िल्टर जानबूझकर छोड़े जाते हैं: जो उपयोगकर्ता स्टोर माँगता है वह डेटा के बदले जाने की अपेक्षा नहीं करता।

6.7 अधिकतम स्तर: LZMA2 और PPMd

Zstandard गति के लिए सही इंजन है, लेकिन अपनी सबसे मज़बूत सेटिंग्स पर यह स्रोत कोड और दस्तावेज़ों पर LZMA2 से अब भी कुछ प्रतिशत पीछे है, और गद्य पर PPMd से काफ़ी पीछे। संस्करण 1.2 से, इसलिए -m5 आर्काइव दो ब्लॉकों से बनाता है (प्रारूप 5.6 में):

• बाइनरी ब्लॉक। फ़ोल्डर, बाइनरी फ़ाइलें, मीडिया प्रविष्टियाँ और Deflate-पुनर्संपीड़ित प्रविष्टियाँ LZMA2 से संपीड़ित होती हैं: preset 9, nice length 273, match-finder depth 32, और डेटा के अनुसार आकार की डिक्शनरी (1 से 128 MiB)।
• टेक्स्ट ब्लॉक। जिन फ़ाइलों के पहले 64 KiB में कोई शून्य बाइट नहीं और लगभग कोई नियंत्रण अक्षर नहीं होते (स्रोत कोड, टेक्स्ट, CSV, HTML, XML ...) वे दूसरे ब्लॉक में जाती हैं। इन फ़ाइलों के चार सन्निहित 1 MiB समूह PPMd variant I (order 8, 192 MiB मॉडल) और टेक्स्ट के लिए ट्यून किए गए LZMA2 (lc 4, pb 0) से परीक्षण-संपीड़ित किए जाते हैं, और छोटा परिणाम जीतता है। गद्य PPMd को पसंद करता है; कई लगभग-समान फ़ाइलों वाले बड़े स्रोत ट्री LZMA2 को पसंद करते हैं, क्योंकि यह फ़ाइलों के बीच लंबे दोहराव कॉपी कर सकता है।
• क्रम। हर ब्लॉक के भीतर, फ़ाइलें एक्सटेंशन से, फिर फ़ाइल नाम से क्रमबद्ध होती हैं, जैसा 7-Zip करता है, ताकि समान या मिलती-जुलती फ़ाइलें पड़ोसी हों। सन्निहित परीक्षण नमूने के साथ, इसने सामान्य डेटा सेट को 7.5 % छोटा किया।

"Extreme" LZMA2 सेटिंग्स मापी गईं और अस्वीकार की गईं: स्प्रेडशीट XML पर वे दस गुना तक धीमी थीं और छोटी नहीं थीं। -m5 एक थ्रेड पर चलता है, -mt की परवाह किए बिना।

7 मीडिया बुद्धिमत्ता

एक सामान्य-उद्देश्य कंप्रेसर बाइट्स देखता है। वह नहीं जानता कि WAV फ़ाइल एक तरंगरूप है जिसका अगला सैंपल पिछले से अनुमानित है, या कि तस्वीर के पड़ोसी पिक्सेल लगभग बराबर हैं। nikpak की मीडिया परत यही ज्ञान देती है: यह ऐसी फ़ाइलें पहचानती है, एक दोषरहित रूपांतरण लागू करती है जो अतिरेक को उजागर करता है, और कंप्रेसर (या समर्पित कोडेक) को उसका लाभ उठाने देती है। यहीं nikpak RAR के मुकाबले सबसे अधिक बढ़त हासिल करता है।

7.1 सामग्री से पहचान

पहचान कम से कम 8 KiB की हर फ़ाइल के पहले बाइट्स देखती है और एक्सटेंशन पर कभी भरोसा नहीं करती, इसलिए .dat नाम बदला गया WAV अब भी मिल जाता है और .wav नाम की टेक्स्ट फ़ाइल नहीं।

प्रकार	इसे कैसे पहचाना जाता है	क्या फ़िल्टर होता है
WAV	RIFF..WAVE, एक fmt चंक जिसमें पूर्णांक PCM (format 1, या PCM उप-प्रारूप वाला WAVE_FORMAT_EXTENSIBLE), 8/16/24/32 बिट, 1 से 8 चैनल, संगत ब्लॉक संरेखण; फिर data चंक	सैंपल क्षेत्र। शून्य, अतिआकार या नकली डेटा लंबाई को फ़ाइल तक सीमित कर दिया जाता है; बचे बाइट और अनुगामी चंक जैसे हैं वैसे रखे जाते हैं।
AIFF / AIFC	FORM..AIFF या AIFC (compression NONE या twos), COMM और SSND चंक, बिग-एंडियन चिह्नित सैंपल	ध्वनि डेटा क्षेत्र।
ProTracker MOD	ऑफ़सेट 1080 पर हस्ताक्षर: M.K., M!K!, FLT4, 4CHN, 6CHN, 8CHN, FLT8, OCTA या CD81	पैटर्न डेटा के बाद का 8-बिट सैंपल क्षेत्र (अनुभाग 7.6)।
BMP	BM, 40 बाइट या अधिक का DIB हेडर, कोई संपीड़न नहीं, 8, 24 या 32 बिट प्रति पिक्सेल, पिक्सेल पंक्तियाँ जो फ़ाइल में समाती हैं, क्षेत्र 4 KiB से 256 MiB के बीच	पिक्सेल पंक्तियाँ (अनुभाग 7.7)।

जो संभाले नहीं जाते, और इसलिए सामान्य संपीड़न से संग्रहित होते हैं: फ़्लोटिंग-पॉइंट WAV, ADPCM और अन्य संपीड़ित ऑडियो, RLE या बिट-फ़ील्ड BMP, और ProTracker MOD के अलावा अन्य ट्रैकर प्रारूप। MP3, JPEG, FLAC, PNG और MP4 जैसा पहले से संपीड़ित मीडिया बिल्कुल पहचाना नहीं जाता और अछूता छोड़ दिया जाता है, क्योंकि उन्हें बदलने से लाभ नहीं होगा।

7.2 परीक्षण: प्रति फ़ाइल सर्वोत्तम फ़िल्टर चुनना

कोई एक रूपांतरण हर फ़ाइल के लिए सर्वोत्तम नहीं है। रिकॉर्ड किए गए संगीत पर पूर्वानुमानित कोडिंग जीतती है; 8-बिट कंपांडेड स्रोत से आए ऑडियो (जहाँ केवल लगभग एक हज़ार अलग 16-बिट मान आते हैं) पर बाइट-प्लेन पृथक्करण जीतता है; मौन और बहुत दोहराव वाले ट्रैकर सैंपल पर सादा संपीड़न जीतता है। इसलिए nikpak अनुमान लगाने के बजाय मापता है।

• एक नमूना लें: पूरा सैंपल क्षेत्र जब वह 3 MiB तक हो, अन्यथा ऑडियो के 5 %, 45 % और 85 % पर 768 KiB की तीन विंडो। छवियों के लिए, लगभग 4 MiB तक की पहली पंक्तियाँ।
• नमूने को सादे Zstandard स्तर 3 (आधार रेखा) से और हर लागू फ़िल्टर से संपीड़ित करें: 16/24/32-बिट ऑडियो के लिए NAC, Shuffle और Shuffle+Delta; 8-बिट ऑडियो के लिए NAC और Shuffle+Delta; छवियों के लिए MED।
• सबसे छोटे अनुमान वाला फ़िल्टर रखें, लेकिन केवल तभी जब वह आधार रेखा को कम से कम 2 % से मात दे। अन्यथा फ़ाइल सामान्य संपीड़न से संग्रहित होती है।
• विजेता के साथ फ़ाइल लिखें। यह सब प्रति फ़ाइल होता है, इसलिए एक आर्काइव में सामान्य फ़ाइलों के बगल में अलग-अलग विधियों से कोडित WAV हो सकते हैं।

nikpak mt वही माप पूरी फ़ाइल पर चलाता है और एक तालिका छापता है, जिससे अध्याय 11 का बेंचमार्क खोजा गया था। विकल्पों में, -mc- फ़िल्टर अक्षम करता है और -mc+ बिना परीक्षण के डिफ़ॉल्ट फ़िल्टर बाध्य करता है।

दोषरहित, सत्यापित, और छोड़ने योग्य हर फ़िल्टर बिल्कुल उत्क्रमणीय है। हर प्रविष्टि के साथ संग्रहित CRC32 मूल बाइट्स पर गणना होता है और निष्कर्षण पर जाँचा जाता है, NAC एनकोडर लिखते समय हर ब्लॉक सत्यापित करता है (अनुभाग 7.4), और -mc- पूरी परत बंद कर देता है।

7.3 NAC ऑडियो कोडेक

NAC (nikpak audio codec) पूर्णांक PCM के लिए एक ब्लॉक-आधारित दोषरहित कोडेक है। यह FLAC के समान परिवार से है: रैखिक पूर्वानुमान के बाद Rice कोडिंग। इसकी अपनी बिट-स्ट्रीम है, इस आर्काइव के लिए डिज़ाइन की गई, और इसका उपयोग WAV, AIFF और MOD फ़ाइलों के सैंपल डेटा के लिए होता है।

ब्लॉक और स्टीरियो डीकोरिलेशन

ऑडियो 4096 सैंपल फ़्रेमों के ब्लॉकों में काटा जाता है, हर ब्लॉक स्वतंत्र रूप से कोडित होता है, जो कोडेक को मज़बूत बनाता है (त्रुटि फैल नहीं सकती) और एनकोडर को बदलती सामग्री के अनुकूल होने देता है। स्टीरियो के लिए, एनकोडर प्रति ब्लॉक चार निरूपणों में से एक चुनता है:

मोड	कोडित चैनल	पुनर्निर्माण
0	Left, Right	direct
1	Left, Side	R = L - S
2	Side, Right	L = R + S
3	Mid, Side	sum = (M << 1) | (S & 1), L = (sum + S) >> 1, R = (sum - S) >> 1

जहाँ Side = L - R और Mid = (L + R) >> 1। साइड चैनल को सामान्य चैनल से एक बिट अधिक चाहिए और इसे bits + 1 से कोडित किया जाता है। मोड सस्ते में चुना जाता है: एनकोडर L, R, M और S के order-2 स्थिर-प्रेडिक्टर रेज़िडुअल के निरपेक्ष मान जोड़ता है और सबसे छोटे योग वाली जोड़ी लेता है। जिन रिकॉर्डिंगों के चैनल दृढ़ता से सहसंबद्ध हैं, वहाँ Mid/Side आम तौर पर कुछ प्रतिशत बचाता है।

सब-फ़्रेम प्रकार

ब्लॉक का हर कोडित चैनल चार सब-फ़्रेमों में से एक के रूप में संग्रहित होता है, जो भी सबसे छोटा हो:

प्रकार	उपयोग	लागत
स्थिर	सभी सैंपल बराबर (डिजिटल मौन)	पूरे ब्लॉक के लिए 2 + सैंपल-चौड़ाई बिट
वर्बेटिम	शोर-जैसी सामग्री, या सुरक्षा फ़ॉलबैक	n x width बिट
स्थिर	order 0 से 4 का बहुपद प्रेडिक्टर	वार्म-अप सैंपल + रेज़िडुअल
LPC	प्रेषित गुणांकों के साथ order 1 से 32 का रैखिक प्रेडिक्टर	गुणांक + वार्म-अप + रेज़िडुअल

व्यर्थ बिट। यदि किसी ब्लॉक के हर सैंपल के निचले बिट हमेशा शून्य हों (16-बिट कंटेनरों में संग्रहित 8-बिट रिकॉर्डिंग, या क्वांटाइज़ किया गया संकेत), तो उन्हें हटा दिया जाता है और उनकी गिनती 5 बिट में संग्रहित होती है।

स्थिर प्रेडिक्टर

order 0: e[i] = x[i]

order 1: e[i] = x[i] - x[i-1]

order 2: e[i] = x[i] - 2*x[i-1] + x[i-2]

order 3: e[i] = x[i] - 3*x[i-1] + 3*x[i-2] - x[i-3]

order 4: e[i] = x[i] - 4*x[i-1] + 6*x[i-2] - 4*x[i-3] + x[i-4]

ब्लॉक के पहले order सैंपल वार्म-अप मानों के रूप में वर्बेटिम संग्रहित होते हैं।

रैखिक पूर्वानुमानित कोडिंग (LPC)

स्वर-प्रधान और हार्मोनिक संगीत के लिए, जिसके गुणांक ब्लॉक पर फ़िट किए गए हों, वह प्रेडिक्टर स्थिर बहुपद से कहीं बेहतर होता है। एनकोडर उन्हें इस प्रकार गणना करता है:

• ब्लॉक पर एक Tukey विंडो लगाएँ (पहले और अंतिम चौथाई पर टेपर), ताकि उसके किनारे सांख्यिकी विकृत न करें।
• विंडो किए गए संकेत की स्वसहसंबंध r[0..32] गणना करें।
• Levinson-Durbin रिकर्सन चलाएँ, जो 1 से 32 तक हर order के लिए इष्टतम गुणांक सेट एक ही पास में देता है: k = (r[i] - sum a[j] r[i-j]) / err, a[i] = k, a[j] = a[j] - k a[i-j], err = err (1 - k^2)।
• वास्तविक गुणांकों को क्वांटाइज़ करें पूर्णांकों में 12, 14 या 15 बिट की परिशुद्धता के साथ (सैंपल चौड़ाई पर निर्भर), दो की घात वाला स्केल चुनते हुए (shift, 0 से 20) ताकि सबसे बड़ा गुणांक ठीक समाए। राउंडिंग त्रुटि फीडबैक उपयोग करती है, ताकि क्वांटाइज़ेशन त्रुटियाँ गुणांकों में जमा न हों।
• कई order का मूल्यांकन करें (सेट प्रयास स्तर पर निर्भर करता है, नीचे), हर एक का रेज़िडुअल गणना करें, और सबसे छोटे अनुमानित कुल आकार वाले को रखें, जिसमें उसके गुणांक भेजने की लागत शामिल है।

प्रेडिक्टर स्वयं शुद्ध पूर्णांक अंकगणित है, जो डिकोडर चलाता है:

pred[i] = (q[0]*x[i-1] + q[1]*x[i-2] + ... + q[n-1]*x[i-n]) >> shift

e[i] = x[i] - pred[i] (n = order; the sum uses 64 bits)

फ़्लोटिंग पॉइंट केवल एनकोडर द्वारा यह तय करने के लिए उपयोग होता है कि कौन से पूर्णांक गुणांक भेजने हैं। डिकोडर कभी फ़्लोटिंग पॉइंट छूता नहीं, इसलिए डिकोडिंग हर प्रोसेसर और हर कंपाइलर पर बिट-सटीक है।

रेज़िडुअल कोडिंग

पूर्वानुमान त्रुटियों को ज़िग-ज़ैग रूपांतरण से अचिह्नित संख्याओं में मैप किया जाता है (u = (e << 1) XOR (e >> 63), ताकि छोटे धनात्मक और ऋणात्मक मान छोटी संख्याएँ बनें) और विभाजित Rice कोड से कोडित होते हैं। ब्लॉक का रेज़िडुअल 2^p विभाजनों में बँटता है (p 0 से 8, एनकोडर द्वारा चुना गया); हर विभाजन को अपना Rice पैरामीटर k (5 बिट) मिलता है। एक मान u >> k यूनरी में लिखा जाता है (उतने शून्य और एक एक) और फिर निचले k बिट। विभाजन का सर्वोत्तम k उसके मानों के योग से निकाला जाता है, इसलिए हर उम्मीदवार प्रेडिक्टर की लागत को एनकोड करने के बजाय चालू योगों से सस्ते में अनुमानित किया जा सकता है।

प्रयास स्तर

आर्काइव का स्तर (-m विकल्प) चुनता है कि प्रति ब्लॉक कितने LPC order आज़माए जाते हैं। अधिक order का अर्थ थोड़ा छोटा परिणाम और धीमा एनकोडर; डिकोडर की गति वही रहती है।

आर्काइव स्तर	NAC प्रयास	आज़माए गए LPC order
-m1	0	8, 16
-m2, -m3	1	4, 8, 12, 16, 24, 32
-m4, -m5	2	2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 24, 28, 32

order 0 से 4 के स्थिर प्रेडिक्टर हमेशा आज़माए जाते हैं। बेंचमार्क में प्रयास स्तर ने स्टीरियो संगीत परिणाम को 0.05 % से कम बदला: बड़ा लाभ पूर्वानुमान का उपयोग करने भर से आता है।

ब्लॉक का बिट लेआउट

block := [stereo mode: 2 bits] sub-frame [sub-frame] (byte-padded)

sub-frame := type:2 ...

CONSTANT : value:width

VERBATIM : wasted:5 samples:(n x (width - wasted))

FIXED : wasted:5 order:3 warm-up residual

LPC : wasted:5 order-1:5 precision-1:4 shift:5

coefficients warm-up residual

residual := partition-order:4 per partition: k:5 Rice-coded values

हर ब्लॉक आर्काइव में सामने 32-बिट लंबाई के साथ संग्रहित होता है, इसलिए डिकोडर हमेशा जानता है कि अगला ब्लॉक कहाँ शुरू होता है।

7.4 स्व-सत्यापन

आर्काइव लिखना एनकोडर बग पकड़ने का एकमात्र मौका है, इसलिए NAC एनकोडर खुद पर भरोसा नहीं करता। हर ब्लॉक एनकोड करने के बाद वह ब्लॉक को फिर से डिकोड करता है और परिणाम की मूल सैंपलों से तुलना करता है। किसी भी अंतर पर वह ब्लॉक को वर्बेटिम (जो विफल नहीं हो सकता) के रूप में फिर से एनकोड करता है और फिर जाँचता है; यदि वह भी विफल हो, तो आर्काइविंग एक स्पष्ट त्रुटि और -mc- उपयोग करने के सुझाव के साथ रुक जाती है। फ़ॉलबैक पथ यूनिट परीक्षणों द्वारा अभ्यासित है, जो बिट गहराई और चैनल गणना के हर संयोजन के लिए वर्बेटिम कोडिंग बाध्य करते हैं, और यह तंत्र संभावित मूक डेटा-हानि बग को एक पहचाने गए, पुनर्प्राप्ति योग्य स्थिति में बदल देता है।

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

7.5 Shuffle और Shuffle+Delta

कुछ ऑडियो पूर्वानुमान पर प्रतिक्रिया नहीं देते। बेंचमार्क में उपयोग की गई गैलरी WAV फ़ाइलें 16-बिट हैं, फिर भी उनमें केवल लगभग एक हज़ार अलग सैंपल मान हैं, क्योंकि वे कंपांडेड 8-बिट स्रोत से बनी थीं। एक प्रेडिक्टर उसका लाभ नहीं उठा सकता, और FLAC उन्हें मूल के 84 % तक संपीड़ित करता है जबकि सादा Zstandard 63 % चाहता है। जो मदद करता है वह है बाइट्स को इस तरह व्यवस्थित करना कि कंप्रेसर को समांगी डेटा दिखे:

• Shuffle सैंपलों के बाइट्स को प्लेनों में अलग करता है: चैनल 0 के सभी न्यूनतम-महत्व बाइट, फिर चैनल 0 के सभी अधिकतम-महत्व बाइट, फिर चैनल 1, और इसी तरह, 32768 फ़्रेमों के ब्लॉकों में। उच्च-बाइट प्लेन चिकना होता है और निम्न-बाइट प्लेन की वर्णमाला बहुत सीमित होती है; Zstandard का एन्ट्रॉपी कोडर हर एक को अंतर्गुंथित मिश्रण से कहीं बेहतर मॉडल करता है।
• Shuffle+Delta पहले हर सैंपल को उसी चैनल के पिछले सैंपल से उसके अंतर से बदल देता है (सैंपल चौड़ाई के मॉड्यूलो, ताकि यह बिल्कुल उत्क्रमणीय हो, ब्लॉकों के बीच स्थिति बनी रहती है) और फिर शफ़ल करता है। यह तब मदद करता है जब संकेत चिकना हो पर NAC के जीतने के लिए पर्याप्त पूर्वानुमान योग्य न हो।

35 गैलरी फ़ाइलों पर प्रति फ़ाइल सर्वोत्तम फ़िल्टर वाला आर्काइव (परीक्षण द्वारा चुना गया) -m2 पर मूल आकार का 51 % और -m5 पर 47 % है, जबकि सादे Zstandard के लिए 63 %।

7.6 ProTracker MOD फ़ाइलें

एक MOD मॉड्यूल एक 1084-बाइट हेडर है (शीर्षक, 31 सैंपल विवरणक, 128 प्रविष्टियों की पैटर्न order तालिका और ऑफ़सेट 1080 पर 4-बाइट हस्ताक्षर), फिर पैटर्न डेटा, फिर सभी उपकरणों के रॉ 8-बिट चिह्नित सैंपल। nikpak गणना करता है कि सैंपल कहाँ शुरू होते हैं और वे कितने लंबे हैं:

patterns = max(order table) + 1

sample_start = 1084 + patterns * 256 * channels (4 ch: 1024 B per pattern)

sample_bytes = sum of (length in words * 2) over the 31 descriptors,

clamped to the end of the file

हेडर और पैटर्न जैसे हैं वैसे संग्रहित होते हैं (कंप्रेसर उन दोहराव वाले नोट इवेंटों को अच्छी तरह संभालता है) और सैंपल क्षेत्र को परीक्षण के लिए एकल मोनो, चिह्नित, 8-बिट स्ट्रीम माना जाता है। प्रति फ़ाइल, NAC, Shuffle+Delta या सादा संपीड़न जीतता है: सैंपल किए गए उपकरण अधिकतर NAC पसंद करते हैं, जबकि कुछ मॉड्यूलों पर (उदाहरण के लिए बहुत छोटे या बहुत दोहराव वाले सैंपलों वाले) सादा संपीड़न जीतता है। काटे गए मॉड्यूल क्षेत्र को वास्तव में मौजूद डेटा तक सीमित करके संभाले जाते हैं।

7.7 BMP छवियाँ

एक असंपीड़ित BMP पिक्सेलों की पंक्तियों को चार बाइट के गुणक में पैड करके संग्रहित करता है। फ़िल्टर चार चरणों में काम करता है:

• विभाजित करें पिक्सेल क्षेत्र को प्रति चैनल एक प्लेन में (32-बिट के लिए B, G, R, और A), प्रति-पंक्ति पैडिंग बाइट अलग से याद रखते हुए।
• रंग डीकोरिलेट करें। नीले और लाल प्लेनों से हरे प्लेन को घटाएँ (मॉड्यूलो 256)। तस्वीरों में तीनों चैनल दृढ़ता से सहसंबद्ध होते हैं, इसलिए अंतर छोटे होते हैं।
• हर पिक्सेल का पूर्वानुमान करें उसके पड़ोसियों से MED (माध्यिका किनारा डिटेक्टर) प्रेडिक्टर से, वही जो LOCO-I छवि कोडर उपयोग करता है: बाएँ a, ऊपर b और ऊपर-बाएँ c के लिए, पूर्वानुमान min(a,b) है यदि c >= max(a,b), max(a,b) यदि c <= min(a,b), और अन्यथा a + b - c। पूर्वानुमान त्रुटि पिक्सेल को बदल देती है (मॉड्यूलो 256)। किनारों पर प्रेडिक्टर किनारे का अनुसरण करता है; चिकने ग्रेडिएंट पर वह ग्रेडिएंट का एक्सट्रापोलेशन करता है।
• जोड़ें रेज़िडुअल प्लेनों और पैडिंग बाइट्स को और Zstandard को उन्हें संपीड़ित करने दें। चिकने क्षेत्र लगभग-शून्य बाइटों की श्रृंखलाएँ बन जाते हैं।

डिकोडर चरणों को बिल्कुल उलट देता है। 8-बिट BMP रंग चरण छोड़ देते हैं; परीक्षण फिर तय करता है कि क्या पूर्वानुमान उस पैलेट के लिए मदद करता है, क्योंकि पैलेट सूचकांकों का पूर्वानुमान केवल ग्रेस्केल या सुचारु रूप से क्रमबद्ध पैलेटों के लिए अर्थ रखता है। 256 MiB से बड़ी BMP फ़ाइलें मेमोरी उपयोग सीमित रखने के लिए फ़िल्टर नहीं की जातीं।

7.8 यह RAR से बेहतर क्यों है

RAR मीडिया को अपने सामान्य match-and-Huffman इंजन और छोटे बाइट-फ़िल्टरों के सेट से संपीड़ित करता है। nikpak इसके बजाय ऑडियो को प्रति-ब्लॉक स्टीरियो डीकोरिलेशन और अनुकूली Rice कोडिंग वाला सच्चा पूर्वानुमानित कोडेक देता है, छवियों को रंग डीकोरिलेशन वाला उचित 2-D प्रेडिक्टर देता है, और मापन द्वारा प्रति फ़ाइल चुनता है। परिणाम बेंचमार्क में दिखता है: हर प्रकार के ऑडियो पर 12 से 15 % छोटा, ट्रैकर संगीत पर 13 % और तस्वीरों पर 39 %, और स्टीरियो ट्रैक के लिए NAC परिणाम समर्पित FLAC एनकोडर के 0.2 % के भीतर है।

7.9 ऑफ़िस दस्तावेज़, PDF और gzip: Deflate पुनर्संपीड़न

आधुनिक ऑफ़िस फ़ाइलें XML के ZIP आर्काइव होती हैं (docx, xlsx, pptx, odt, ods), और PDF फ़ाइलें अपने पृष्ठ Deflate (FlateDecode) स्ट्रीमों में संग्रहित करती हैं। इसलिए उनकी सामग्री पहले से संपीड़ित है, और कोई भी आर्काइवर उसे अधिक नहीं सिकोड़ सकता: 1.1 बेंचमार्क में, 6.6 MB .xlsx फ़ाइलें 7-Zip से केवल 5.6 MB तक गईं। nikpak 1.2 उस बाधा को हटाता है।

• सामग्री से पहचान। फ़ाइल की शुरुआत में ZIP लोकल हेडर (PK\x03\x04), %PDF- या gzip हेडर; एक्सटेंशन कभी उपयोग नहीं होता।
• डिकोडिंग। हर Deflate स्ट्रीम मिलती है (विधि 8 वाली ZIP प्रविष्टियाँ, zlib हेडर वाली PDF स्ट्रीमें, हर gzip सदस्य) और preflate (Microsoft का preflate-rs) से विश्लेषित होती है। preflate सादा डेटा और एक छोटा सुधार-रिकॉर्ड लौटाता है जो बिल्कुल बताता है कि मूल एनकोडर ने अपने चयन कैसे किए, चाहे वह कोई भी एनकोडर रहा हो।
• संग्रहण। फ़ाइल रॉ खंडों और (plain, corrections) जोड़ियों के अनुक्रम के रूप में संग्रहित होती है। सादा XML या पृष्ठ विवरण फिर सॉलिड स्ट्रीम में जाता है, जहाँ LZMA2 उसे उसके Deflate आकार के एक अंश तक संपीड़ित करता है।
• सत्यापन। परिणाम उपयोग करने से पहले, nikpak हर Deflate स्ट्रीम पुनर्निर्मित करता है और पूरी फ़ाइल की लंबाई और CRC32 की मूल से तुलना करता है। यदि कुछ भी भिन्न हो, या preflate किसी विकृत फ़ाइल पर विफल या पैनिक हो, तो फ़ाइल बस सामान्य रूप से संग्रहित कर दी जाती है।
• निष्कर्षण। Deflate स्ट्रीमें बिट-दर-बिट पुनः बनाई जाती हैं, इसलिए निकाली गई .docx या .pdf बाइट-समान होती है, और उसका CRC32 हर प्रविष्टि की तरह जाँचा जाता है।

अनुभाग 11.7 के ऑफ़िस सेट पर यही nikpak को हर दूसरे आर्काइवर से छोटा बनाता है। 6.6 MB .xlsx फ़ाइलों में डिकोड होने पर 71 MB XML होता है, और वह XML Deflate की तुलना में कहीं बेहतर संपीड़ित होता है। कीमत समय है: preflate लगभग 15 MB सादे डेटा प्रति सेकंड विश्लेषित करता है। इसीलिए पुनर्संपीड़न केवल -m4 और -m5 पर उपयोग होता है, जहाँ वह लाभदायक है (मापा गया: -m3 ने छह गुना समय पर 0.5 % लाभ दिया)। सीमाएँ: फ़ाइलें 512 MiB तक, और प्रति स्ट्रीम 512 MiB सादा डेटा और 64 MiB सुधार। -mc- इसे बंद कर देता है।

8 एन्क्रिप्शन

nikpak का एन्क्रिप्शन पूरी तरह मानक, भली-भाँति अध्ययन किए गए घटकों से बना है (Argon2id और XChaCha20-Poly1305 के RustCrypto कार्यान्वयन)। इस परियोजना के लिए कोई प्रिमिटिव आविष्कार नहीं किया गया; काम उन्हें सही ढंग से जोड़ने में है।

8.1 ख़तरा मॉडल

डिज़ाइन एक ऐसे हमलावर को मानता है जो आर्काइव फ़ाइल प्राप्त कर लेता है और उसे आराम से अध्ययन तथा संशोधित कर सकता है, और जो ऑफ़लाइन असीमित पासवर्ड अनुमान आज़मा सकता है। nikpak गारंटी देने का लक्ष्य रखता है:

• फ़ाइल सामग्री और उनके बारे में हर चीज़ की गोपनीयता: नाम, आकार, टाइमस्टैम्प, अनुमतियाँ और फ़ाइलों की संख्या।
• अखंडता और प्रामाणिकता: आर्काइव में कोई भी बदलाव, चाहे डेटा, हेडर, डेटा के क्रम या उसकी लंबाई में हो, गलत डेटा स्वीकार होने से पहले पकड़ा जाता है।
• अनुमान-प्रतिरोध: हर पासवर्ड अनुमान को यथासंभव महँगा बनाया जाता है।

यह नहीं छिपाता कि कोई आर्काइव मौजूद है, न उसका लगभग आकार, और यह उस मशीन के मैलवेयर से रक्षा नहीं कर सकता जो आर्काइव बनाती या खोलती है, न ही कमज़ोर पासवर्ड से।

8.2 पासवर्ड से कुंजी तक: Argon2id

पासवर्ड एक खराब कुंजी है: छोटा, पूर्वानुमान योग्य और मानव द्वारा टाइप किया हुआ। इसे Argon2id से 256-बिट कुंजी में बदला जाता है, जो Password Hashing Competition का विजेता और RFC 9106 में मानकीकृत एल्गोरिदम है। Argon2id जानबूझकर मेमोरी-हार्ड है: एक कुंजी गणना के लिए मेमोरी का बड़ा ब्लॉक चाहिए जो भरा जाता है और फिर डेटा-निर्भर पैटर्न में बार-बार पढ़ा जाता है। nikpak RFC का कम-मेमोरी प्रोफ़ाइल उपयोग करता है:

पैरामीटर	मान	अर्थ
मेमोरी	64 MiB	हर अनुमान को 64 MiB तेज़ मेमोरी चाहिए
पास	3	मेमोरी को तीन बार संसाधित किया जाता है
लेन	4	एक व्युत्पत्ति के अंदर समानांतरता की मात्रा
सॉल्ट	16 यादृच्छिक बाइट	हर आर्काइव के लिए नया: समान पासवर्ड अलग कुंजियाँ देते हैं, और पूर्व-गणना तालिकाएँ बेकार हैं
आउटपुट	32 बाइट	XChaCha20-Poly1305 कुंजी

मेमोरी-हार्डनेस ही Argon2id को पुराने PBKDF2 (RAR5 और ZIP के AES मोड द्वारा उपयोग) से अलग करती है: PBKDF2 को लगभग कोई मेमोरी नहीं चाहिए, इसलिए ग्राफ़िक्स कार्ड या कस्टम चिप समानांतर में बड़ी संख्या में अनुमान आज़मा सकती है। Argon2id के साथ हमलावर के हार्डवेयर को प्रति समानांतर अनुमान 64 MiB देना पड़ता है, जो उस लाभ का अधिकांश हटा देता है। वैध उपयोगकर्ता को लागत एक सेकंड का अंश है, प्रति आर्काइव एक बार।

पैरामीटर हेडर में संग्रहित होते हैं, इसलिए भविष्य के संस्करण पुराने आर्काइव तोड़े बिना उन्हें बढ़ा सकते हैं। पढ़ते समय, पहले उन्हें सीमा-जाँचा जाता है (मेमोरी 8 x लेन 1 GiB तक, पास 1 से 64, लेन 1 से 64) ताकि दुर्भावनापूर्ण आर्काइव पासवर्ड जाँचे जाने से पहले nikpak से बेतुकी मेमोरी आवंटित न करा सके।

8.3 STREAM निर्माण में XChaCha20-Poly1305

थोक डेटा XChaCha20-Poly1305 से सुरक्षित होता है, जो एक प्रमाणित-एन्क्रिप्शन-विद-एसोसिएटेड-डेटा (AEAD) सिफर है: ChaCha20 एक 256-बिट-कुंजी स्ट्रीम सिफर देता है, X संस्करण उसके नॉन्स को 192 बिट तक बढ़ाता है (इतना बड़ा कि बिना दोहराव यादृच्छिक चुना जा सके), और Poly1305 हर सील किए गए संदेश पर 128-बिट प्रमाणीकरण टैग जोड़ता है। ChaCha20 विशेष निर्देशों के बिना हर CPU पर तेज़ है और, तालिका-आधारित AES के विपरीत, स्वाभाविक रूप से कैश-टाइमिंग लीक से मुक्त है।

एक आर्काइव एक संदेश से कहीं बड़ा होता है, इसलिए nikpak STREAM निर्माण उपयोग करता है (वही जो आधुनिक फ़ाइल-एन्क्रिप्शन टूल उपयोग करते हैं): डेटा 64 KiB चंकों में काटा जाता है और चंक संख्या i नॉन्स के अंतर्गत सील होती है

nonce (24 bytes) = random prefix (19 bytes)

| chunk counter (4 bytes, big endian)

| last-chunk flag (1 byte)

यह एक साथ तीन गारंटी देता है। हर चंक का एक अद्वितीय नॉन्स है, जो स्ट्रीम सिफरों के लिए आवश्यक है। क्योंकि काउंटर नॉन्स का हिस्सा है, चंकों को पुनः क्रमबद्ध या डुप्लिकेट करने पर प्रमाणीकरण विफल हो जाता है। क्योंकि अंतिम चंक एक अलग फ़्लैग रखता है, आर्काइव को छोटा काटने पर, ठीक चंक सीमा पर भी, प्रमाणीकरण विफल हो जाता है: नया अंतिम चंक एक गैर-अंतिम चंक के रूप में सील हुआ था। 19-बाइट उपसर्ग प्रति आर्काइव यादृच्छिक है।

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

मद	मान
सिफर	XChaCha20-Poly1305: 256-बिट कुंजी, 192-बिट नॉन्स, 128-बिट टैग
चंक	64 KiB तक प्लेनटेक्स्ट; u32 length + सिफरटेक्स्ट + 16-बाइट टैग के रूप में संग्रहित
आकार ओवरहेड	लगभग 0.03 % (20 बाइट प्रति 64 KiB), 222 MB डेटा सेट पर 0.03 % मापा गया
गति ओवरहेड	मापा गया: 222 MB डेटा सेट पर कुल +0.3 s (0.64 s के बजाय 0.92 s), कुंजी व्युत्पत्ति सहित
गलत पासवर्ड	पहले चंक पर पकड़ा जाता है; कोई प्लेनटेक्स्ट नहीं बनता

8.4 एक प्रेक्षक क्या देख सकता और नहीं देख सकता

पासवर्ड के बिना दृश्यमान	सुरक्षित
मैजिक संख्या, संस्करण, फ़्लैग और संपीड़न विधि	फ़ाइल नाम और फ़ोल्डर संरचना
Argon2id पैरामीटर, सॉल्ट और नॉन्स उपसर्ग	फ़ाइल आकार, टाइमस्टैम्प और अनुमतियाँ
कुल आर्काइव आकार और चंकों की संख्या	फ़ाइलों की संख्या
यह तथ्य कि यह एक nikpak आर्काइव है	सारी सामग्री, जिसमें यह भी कि उसमें मीडिया है या नहीं

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

8.5 पासवर्ड संभालना

• न्यूनतम लंबाई। आर्काइव बनाते समय 8 अक्षर; छोटे पासवर्ड स्पष्टीकरण के साथ अस्वीकार किए जाते हैं।
• पुष्टि। इंटरैक्टिव संकेत दो बार पूछता है, टाइप किए अक्षर प्रदर्शित नहीं करता, और बेमेल अस्वीकार करता है।
• निर्माण। पासवर्ड के बिना, nikpak 56-चिह्न वर्णमाला से 24 अक्षर खींचता है जो मिलते-जुलते (0/O, 1/l/I) छोड़ देती है, ऑपरेटिंग सिस्टम के क्रिप्टोग्राफ़िक रूप से सुरक्षित यादृच्छिक जनरेटर पर अस्वीकृति नमूनाकरण उपयोग करते हुए ताकि कोई चिह्न दूसरे से अधिक संभावित न हो। यह 24 x log2(56), लगभग 139 बिट एन्ट्रॉपी है, और इसे एक बार, स्पष्ट रूप से चिह्नित बॉक्स में दिखाया जाता है।
• मेमोरी स्वच्छता। व्युत्पन्न कुंजी और पासवर्ड स्ट्रिंग जब आवश्यक नहीं रहते तो मेमोरी से मिटा दिए जाते हैं (zeroize crate)।
• चैनल। कमांड लाइन (-p), एनवायरनमेंट वेरिएबल NIKPAK_PASSWORD, इंटरैक्टिव संकेत, या टर्मिनल न होने पर stdin। कमांड-लाइन रूप सुविधाजनक है पर प्रोसेस सूची में दिखता है; अन्य रूप बेहतर हैं।

8.6 हमला परीक्षण

एन्क्रिप्टेड आर्काइवों के निम्नलिखित हेरफेर तैयार प्रोग्राम के विरुद्ध किए गए। सभी किसी गलत डेटा के स्वीकार होने से पहले पकड़े गए:

हेरफेर	परिणाम
सिफरटेक्स्ट के बीच में एक बाइट पलटें	अस्वीकृत: प्रमाणीकरण विफलता (exit 11)
हेडर में सॉल्ट का एक बाइट पलटें	अस्वीकृत (हेडर एसोसिएटेड डेटा है और कुंजी बदल जाती है)
हेडर में विधि बाइट बदलें	अस्वीकृत
फ़ाइल 100 बाइट काटें	क्षतिग्रस्त के रूप में अस्वीकृत (exit 3)
अंतिम चंक ठीक चंक सीमा पर हटाएँ	अस्वीकृत: नए अंतिम चंक में अंतिम फ़्लैग नहीं है
दो चंक अदला-बदली करें	अस्वीकृत: काउंटर बेमेल
गलत पासवर्ड दें	पहले चंक पर अस्वीकृत (exit 11)
एक यादृच्छिक फ़ाइल आर्काइव के रूप में दें	अस्वीकृत: खराब हस्ताक्षर (exit 3)

शेष जोखिम, स्पष्ट रूप से कहे गए एक कमज़ोर पासवर्ड हमेशा अनुमान लगाया जा सकता है; Argon2id इसे महँगा बनाता है पर password123 को बचा नहीं सकता। nikpak का स्वतंत्र ऑडिट नहीं हुआ है। यह कीलॉगर, मैलवेयर या चल रहे प्रोसेस की मेमोरी पढ़ने वाले से रक्षा नहीं कर सकता। जिनके डेटा का उजागर होना गंभीर हानिकारक हो, उन्हें पहले कार्यान्वयन की क्रिप्टोग्राफ़र से समीक्षा करवानी चाहिए।

9 क्वांटम प्रतिरोध

क्वांटम कंप्यूटर कुछ क्रिप्टोग्राफ़ी को बुरी तरह ख़तरे में डालते हैं और अन्य को मुश्किल से छूते हैं। nikpak उसी पक्ष पर डिज़ाइन किया गया था जो मुश्किल से प्रभावित होता है।

9.1 क्वांटम कंप्यूटर क्या बदलते हैं

एल्गोरिदम	प्रभाव	कौन प्रभावित होता है
Shor (1994)	बहुपद समय में पूर्णांकों के गुणनखंड और असतत लघुगणक गणना करता है	RSA, Diffie-Hellman, DSA, एलिप्टिक-कर्व क्रिप्टोग्राफ़ी: एक बड़े क्वांटम कंप्यूटर द्वारा तोड़ी गई
Grover (1996)	N मदों के असंरचित स्थान को लगभग N के वर्गमूल चरणों में खोजता है	सिमेट्रिक कुंजियाँ और हैश फ़ंक्शन: प्रभावी कुंजी लंबाई आधी हो जाती है

Shor का एल्गोरिदम नाटकीय है: यह हर उस सिस्टम को तोड़ देगा जो सार्वजनिक-कुंजी गणित पर निर्भर है, यही कारण है कि सरकारें और मानक निकाय ML-KEM (FIPS 203) जैसे पोस्ट-क्वांटम सार्वजनिक-कुंजी एल्गोरिदम की ओर बढ़ रहे हैं। Grover का एल्गोरिदम हल्का है: एक 256-बिट कुंजी इसके विरुद्ध लगभग 128 बिट सुरक्षा देती है, और Grover की पुनरावृत्तियाँ स्वाभाविक रूप से अनुक्रमिक हैं, इसलिए काम को कई क्वांटम मशीनों में फैलाने से उनकी संख्या का केवल वर्गमूल ही गति-लाभ मिलता है।

9.2 nikpak की स्थिति

घटक	प्रिमिटिव	क्वांटम प्रभाव
एन्क्रिप्शन	XChaCha20, 256-बिट कुंजी	सर्वोत्तम ज्ञात हमला: Grover, लगभग 2^128 संक्रियाएँ। पहुँच से परे।
प्रमाणीकरण	Poly1305, 128-बिट टैग, 256-बिट रहस्य से कुंजीबद्ध	कोई सार्वजनिक-कुंजी गणित शामिल नहीं
पासवर्ड से कुंजी	Argon2id, 64 MiB, 3 पास	Grover अधिकतम पासवर्ड की एन्ट्रॉपी आधी कर सकता है, और हर पुनरावृत्ति को मेमोरी-हार्ड फ़ंक्शन का मूल्यांकन करना होगा
यादृच्छिकता	ऑपरेटिंग-सिस्टम CSPRNG	अप्रभावित
सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी	कोई नहीं	Shor के एल्गोरिदम के हमला करने के लिए कुछ नहीं

एक 256-बिट सिमेट्रिक कुंजी NIST के पोस्ट-क्वांटम मानकीकरण की उच्चतम सुरक्षा श्रेणी (श्रेणी 5) का संदर्भ है: NIST द्वारा मानकीकृत सार्वजनिक-कुंजी एल्गोरिदम इसी से रेट होते हैं कि वे 256-बिट AES कुंजी की संपूर्ण खोज की कठिनाई से कितने मेल खाते हैं। दूसरे शब्दों में, nikpak का डेटा एन्क्रिप्शन पहले से ही उसी ताकत पर बैठा है जिसका लक्ष्य पोस्ट-क्वांटम मानक रखते हैं।

9.3 पासवर्ड के बारे में क्या?

सिफर की कुंजी-स्थान 256 बिट है, पर कुंजी पासवर्ड से व्युत्पन्न होती है, इसलिए वास्तविक ताकत पासवर्ड की एन्ट्रॉपी और 256 बिट में से छोटी है। क्वांटम विरोधी के सामने पासवर्ड की एन्ट्रॉपी, हमलावर के लिए सर्वोत्तम स्थिति में, आधी हो जाती है:

पासवर्ड	एन्ट्रॉपी	शास्त्रीय खोज	Grover खोज (सर्वोत्तम में)
nikpak-निर्मित (24 चिह्न)	लगभग 139 बिट	लगभग 2^139 अनुमान	लगभग 2^70 पुनरावृत्तियाँ, हर एक को संगत 64 MiB Argon2id मूल्यांकन चाहिए
छह यादृच्छिक Diceware शब्द	लगभग 77 बिट	लगभग 2^77 अनुमान	उसी महँगे परिपथ की लगभग 2^39 पुनरावृत्तियाँ
मानव-चुना 10-अक्षर पासवर्ड	आम तौर पर 30 - 45 बिट	संभव	संभव

निष्कर्ष परिचित है, अधिक तीखे ढंग से कहा गया: कमज़ोर बिंदु पासवर्ड है, सिफर नहीं। निर्मित पासवर्ड या लंबा यादृच्छिक पासफ़्रेज़ उपयोग करें और आर्काइव किसी भी दूरदर्शी भविष्य के लिए शास्त्रीय और क्वांटम दोनों हमलावरों का प्रतिरोध करता है। Argon2id दोनों दुनियाओं में मदद करता है, क्योंकि हर अनुमान की लागत में मेमोरी हावी है, जिसे Grover का एल्गोरिदम सस्ता नहीं करता।

9.4 "अभी संचित करें, बाद में डिक्रिप्ट करें"

अक्सर उद्धृत क्वांटम ख़तरा यह है कि विरोधी आज एन्क्रिप्टेड डेटा रिकॉर्ड करता है और क्वांटम कंप्यूटर आने पर उसे डिक्रिप्ट करता है। RSA या एलिप्टिक कर्व से कुंजी अदला-बदली करने वाले सिस्टमों, जैसे TLS कनेक्शन या ई-मेल एन्क्रिप्शन, के लिए यह वास्तविक है। nikpak आर्काइव में कोई कुंजी अदला-बदली नहीं है: इसकी कुंजी एक ऐसे रहस्य से आती है जो उपयोगकर्ता के दिमाग़ या पासवर्ड प्रबंधक से कभी बाहर नहीं जाता। संग्रहित प्रति बाद में केवल उस रहस्य का अनुमान लगाकर खोली जा सकती है, और क्वांटम कंप्यूटर उसे मौलिक रूप से आसान नहीं बनाते।

9.5 ईमानदार सीमाएँ और आगे का रास्ता

• "क्वांटम-प्रतिरोधी" का अर्थ है कि कोई ज्ञात क्वांटम एल्गोरिदम इन प्रिमिटिवों के विरुद्ध सामान्य खोज को नहीं हराता। यह प्रमाण नहीं है; ChaCha20 और Argon2 का क्रिप्टएनालिसिस जारी है, और प्रारूप संस्करणित है ताकि पैरामीटर या एल्गोरिदम बदले जा सकें।
• यदि कभी सार्वजनिक-कुंजी साझा जोड़ा जाए (किसी प्राप्तकर्ता की कुंजी के लिए आर्काइव एन्क्रिप्ट करना), तो यह एक हाइब्रिड योजना उपयोग करेगा, X25519 को ML-KEM के साथ जोड़कर, ताकि यदि कोई भी एक घटक टिके तो सुरक्षित रहे।
• क्वांटम प्रतिरोध कार्यान्वयन त्रुटियों से रक्षा नहीं करता। अनुभाग 8.6 और 10 देखें।

10 सख़्ती और मज़बूती

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

10.1 सुरक्षित निष्कर्षण

• पथ ट्रैवर्सल ("zip slip")। हर प्रविष्टि नाम सामान्यीकृत होता है: बैकस्लैश स्लैश बन जाते हैं, खाली और . घटक हटा दिए जाते हैं, और कोई भी .. घटक प्रविष्टि को चेतावनी के साथ छोड़ने का कारण बनता है। निरपेक्ष नाम अपना रूट खो देते हैं, इसलिए /etc/passwd गंतव्य फ़ोल्डर के अंदर निकाला जाता है।
• Windows नाम। Windows पर चलते समय, < > : " | ? * या नियंत्रण अक्षर रखने वाले, रिक्त स्थान या बिंदु पर समाप्त होने वाले, या आरक्षित डिवाइस नाम (CON, PRN, AUX, NUL, COM1-9, LPT1-9) के बराबर घटक अस्वीकार किए जाते हैं।
• सिम्बॉलिक लिंक। लिखने से पहले, गंतव्य के नीचे लक्ष्य पथ का हर मौजूदा घटक जाँचा जाता है; लिंक का कभी अनुसरण नहीं होता। मौजूदा फ़ाइल पहले हटाई जाती है और नई create_new से बनाई जाती है, जो मौजूदा पथ खोलने से इनकार करता है, इसलिए लेखन को पुनर्निर्देशित करने के लिए लिंक उपयोग नहीं हो सकता।
• विशेषाधिकार बिट। Setuid, setgid और sticky बिट कभी बहाल नहीं होते; अनुमतियाँ सामान्य rwx बिट तक सीमित रहती हैं।
• विफल फ़ाइलें। जिस फ़ाइल का CRC32 नहीं मिलता उसे हटा दिया जाता है, पीछे नहीं छोड़ा जाता।

परीक्षणों में ../../evil.txt, /tmp/evil.txt, ..\..\evil.txt और ok/../../evil.txt वाला हाथ से बना आर्काइव निकाला गया: कुछ भी गंतव्य से बाहर नहीं गया, असुरक्षित प्रविष्टियाँ सूचित और छोड़ी गईं, और गंतव्य में रोपा गया सिमलिंक अस्वीकार किया गया।

10.2 सीमित डिकोडर

• Argon2id पैरामीटर किसी भी आवंटन से पहले सीमा-जाँचे जाते हैं (अनुभाग 8.2)।
• एन्क्रिप्टेड चंकों की लंबाई 16 बाइट और 64 KiB + 16 के बीच होनी चाहिए; नाम अधिकतम 4096 बाइट; ऑडियो ब्लॉकों को एक विश्वसनीय लंबाई घोषित करनी चाहिए; BMP क्षेत्र 256 MiB तक सीमित; यूनरी Rice कोड सीमित हैं।
• यूनिट परीक्षणों में ऑडियो और मीडिया डिकोडरों को हज़ारों यादृच्छिक और बिट-फ़्लिप्ड इनपुट खिलाए गए और उन्हें त्रुटि लौटानी चाहिए, कभी पैनिक या एबॉर्ट नहीं करना चाहिए।
• nikpak के अपने कोड में कोई unsafe ब्लॉक नहीं है, और Rust की सीमा जाँच C में मेमोरी-भ्रष्टता बग होने वाली किसी भी तर्क त्रुटि को एक साफ विफलता में बदल देती है।

nikpak किसी आर्काइव के विस्तार अनुपात को सीमित नहीं करता, इसलिए, हर आर्काइवर की तरह, जानबूझकर बनाया गया "compression bomb" निकालने पर डिस्क भर सकता है। यदि यह मायने रखता है तो अज्ञात आर्काइव पहले t से परखें।

10.3 सुरक्षित निर्माण और ईमानदार त्रुटियाँ

• आर्काइव name.nik.tmp में लिखा जाता है और पूर्ण होने पर ही नाम बदला जाता है; किसी भी विफलता पर गार्ड अस्थायी फ़ाइल हटा देता है, इसलिए बाधित रन कभी आधा लिखा या बदला हुआ आर्काइव नहीं छोड़ता।
• यदि आर्काइव होते समय कोई फ़ाइल छोटी हो जाए, तो nikpak असंगत प्रविष्टि लिखने के बजाय स्पष्ट संदेश के साथ रुक जाता है। अपठनीय फ़ाइलें, सिम्बॉलिक लिंक और विशेष फ़ाइलें चेतावनी के साथ छोड़ दी जाती हैं (एग्ज़िट कोड 1) और आर्काइव कभी खुद में नहीं जोड़ा जाता।
• त्रुटियाँ वर्गीकृत हैं ताकि स्क्रिप्ट प्रतिक्रिया कर सकें: आर्काइव के अंदर चेकसम या फ़्रेम त्रुटि भ्रष्टता है (exit 3), प्रमाणीकरण विफलता गलत पासवर्ड या छेड़छाड़ है (exit 11), अस्वीकृत लेखन घातक त्रुटि है (exit 2)।

11 बेंचमार्क

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

अनुभाग 11.1 से 11.6 nikpak 1.1.0 से मापे गए, जिसका -m5 अब भी Zstandard उपयोग करता था। अनुभाग 11.7 nikpak 1.2.0 की RAR, 7-Zip और ZIP से एक मशीन पर तुलना करता है।

11.1 विधि

मद	विवरण
मशीन	Linux x86-64 वर्चुअल मशीन, एक CPU कोर। सभी समय उस एकल कोर पर वॉल-क्लॉक सेकंड हैं; मल्टी-कोर मशीनें दोनों टूल्स के लिए तेज़ होती हैं।
सॉफ़्टवेयर	RAR 7.00 (26 Feb 2024, Linux ट्रायल बिल्ड, -ma5 प्रारूप); nikpak 1.1.0 रिलीज़ मोड में LTO के साथ बिल्ड; ऑडियो संदर्भ के रूप में FLAC 1.x -8।
RAR सेटिंग्स	-m3 (RAR का डिफ़ॉल्ट) और -m5 (सर्वोत्तम)। सामान्य-डेटा परीक्षण के लिए -s (सॉलिड) और -md256m (256 MB डिक्शनरी) भी, क्योंकि nikpak आर्काइव हमेशा सॉलिड होते हैं और निष्पक्ष तुलना के लिए RAR को वही अनुमति दी जानी चाहिए।
सत्यापन	हर nikpak आर्काइव निकाला गया और मूल से मिलाया गया (मीडिया फ़ाइलों के लिए cmp, सामान्य सेट की सभी 10,949 फ़ाइलों के लिए SHA-256)।

परीक्षण सामग्री

सेट	सामग्री
गैलरी WAV	LibreOffice की गैलरी से 35 ध्वनि फ़ाइलें: मोनो 16-बिट, 23 फ़ाइलें 11,025 Hz पर और 12 फ़ाइलें 22,050 Hz पर। उनमें केवल लगभग एक हज़ार अलग सैंपल मान हैं (कंपांडेड स्रोत) और वे पूर्वानुमानित कोडिंग के लिए जानबूझकर अटपटा मामला हैं।
संगीत	TiMidity++ और Freepats ध्वनि सेट से 44.1 kHz स्टीरियो 16-बिट (17.4 MB) में रेंडर किया गया 100-सेकंड बहु-वाद्य टुकड़ा (पियानो, तार, बास, बाँसुरी, ड्रम)। SoX ने 22.05 kHz मोनो 16-बिट, 22.05 kHz मोनो 8-बिट और 48 kHz स्टीरियो 24-बिट संस्करण निकाले।
MOD	libxmp परीक्षण संग्रह से 16 ProTracker मॉड्यूल।
BMP	6 छवियाँ: scikit-image नमूना सेट से पाँच तस्वीरें (24-बिट, साथ ही एक का 8-बिट ग्रेस्केल रूपांतरण) और TeX Live से एक बनावट।
सामान्य डेटा	10,949 फ़ाइलों में 197.6 MB: Python मानक लाइब्रेरी और पैकेज, परीक्षण मशीन से दस्तावेज़ीकरण और C हेडर, सिम्बॉलिक लिंक हटाए गए।

इस परीक्षण सामग्री की सीमाएँ संगीत कृत्रिम है: इसे MIDI से रेंडर किया गया था और इसमें दोहराए गए अंश हैं, जो NAC के बाद Zstandard चरण सहित हर LZ-आधारित टूल की मदद करते हैं। वास्तविक रिकॉर्डिंगों में कम सटीक दोहराव होते हैं, इसलिए निरपेक्ष आकार भिन्न होंगे। तुलना सभी टूल्स को समान रूप से मानती है, और उसी फ़ाइल पर FLAC का परिणाम पुष्टि करता है कि ऑडियो कोडेक स्वयं प्रतिस्पर्धी है, पर विशिष्ट सामग्री वाले पाठकों को उसे मापना चाहिए: nikpak mt ठीक यही करता है।

11.2 मीडिया फ़ाइलें

सेट	मूल	RAR 7 -m5	nikpak -m2	nikpak -m5	m5 बनाम RAR
6 BMP तस्वीरें	9,183,956	2,862,744	2,035,223	1,750,706	38.8 % छोटा
16 ProTracker MOD फ़ाइलें	2,507,557	1,070,290	966,622	927,973	13.3 % छोटा
35 गैलरी WAV (मोनो 16-बिट)	2,991,820	1,605,879	1,529,219	1,418,532	11.7 % छोटा
संगीत 44.1 kHz स्टीरियो 16-बिट	17,371,848	11,024,411	9,415,519	9,411,898	14.6 % छोटा
संगीत 22.05 kHz मोनो 16-बिट	4,342,996	3,112,135	2,635,819	2,634,669	15.3 % छोटा
संगीत 22.05 kHz मोनो 8-बिट	2,171,520	844,160	742,462	740,751	12.2 % छोटा
संगीत 48 kHz स्टीरियो 24-बिट	28,362,206	21,467,283 (-m3)	18,689,529	18,688,030	12.9 % छोटा

सभी आकार बाइट में हैं। 24-बिट फ़ाइल के लिए RAR केवल -m3 पर मापा गया, इसलिए वह पंक्ति अन्य की तुलना में कमज़ोर तुलना है।

मीडिया फ़िल्टर क्या जोड़ते हैं

मीडिया फ़िल्टरों के बिना वही nikpak (संस्करण 1.0, डिफ़ॉल्ट स्तर पर सादा Zstandard) मीडिया परत के मूल्य का सही मापदंड है:

सेट	nikpak 1.0 (कोई फ़िल्टर नहीं)	nikpak 1.1 -m2	कमी
6 BMP तस्वीरें	3,580,971	2,035,223	43.2 %
16 ProTracker MOD फ़ाइलें	1,260,607	966,622	23.3 %
35 गैलरी WAV (मोनो 16-बिट)	1,876,722	1,529,219	18.5 %
संगीत 44.1 kHz स्टीरियो 16-बिट	15,585,422	9,415,519	39.6 %
संगीत 22.05 kHz मोनो 16-बिट	3,887,183	2,635,819	32.2 %
संगीत 22.05 kHz मोनो 8-बिट	1,078,493	742,462	31.2 %

FLAC से तुलना

44.1 kHz स्टीरियो संगीत के लिए FLAC -8, समर्पित संदर्भ एनकोडर, 9,407,019 बाइट बनाता है। उसी ऑडियो के लिए NAC स्ट्रीम 9,425,305 बाइट है, 0.2 % के भीतर, और तैयार nikpak आर्काइव 9,415,519 बाइट। 22 kHz मोनो और 8-बिट संस्करणों के लिए NAC FLAC से छोटा है (2,635,446 बनाम 2,638,954, और केवल ऑडियो क्षेत्र के लिए 785,890 बनाम 798,810), और 24-बिट के लिए आर्काइव (18.69 MB) FLAC के 19.12 MB से छोटा है। गैलरी फ़ाइलों पर FLAC काफ़ी कमज़ोर है (RAR के 1.61 MB के मुकाबले 2.50 MB), जिसका कारण अनुभाग 7.5 में समझाया गया है; यही वह मामला है जिसमें अन्य फ़िल्टर अपनी जगह अर्जित करते हैं।

11.3 सामान्य डेटा

स्रोत कोड और दस्तावेज़ मीडिया नहीं हैं, इसलिए यह परीक्षण जाँचता है कि क्या nikpak की अन्यत्र बढ़त की सामान्य फ़ाइलों पर कोई कीमत चुकानी पड़ती है।

टूल और स्तर	आकार (बाइट)	समय	निष्कर्षण
nikpak -m5	24,443,483	45.6 s	1.8 s
RAR 7 -m5 -s -md256m	25,862,475	36.2 s
RAR 7 -m5 -s	26,002,812	26.7 s
RAR 7 -m3 -s	26,536,863	16.7 s	1.5 s
nikpak -m4	26,814,023	13.5 s
nikpak -m3	30,329,965	2.0 s
nikpak -m2 (1.1 डिफ़ॉल्ट)	36,266,743	0.9 s	0.8 s
RAR 7 -m5 (डिफ़ॉल्ट, सॉलिड नहीं)	50,851,230	14.8 s
RAR 7 -m3 (डिफ़ॉल्ट, सॉलिड नहीं)	50,974,773	9.7 s	2.3 s

तालिका को ईमानदारी से पढ़ना:

• अधिकतम स्तर: nikpak RAR के सर्वोत्तम से 5.5 % छोटा आर्काइव बनाता है (25.9 के मुकाबले 24.4 MB)। इस स्तर पर RAR तेज़ है (45.6 s के मुकाबले 26.7 से 36.2 s)।
• समान आकार: nikpak -m4 RAR के डिफ़ॉल्ट सॉलिड स्तर के लगभग 1 % के भीतर है, समय के 81 % में (16.7 s के मुकाबले 13.5 s)।
• तेज़ स्तर: -m2 अनुपात की कीमत पर गति देता है: RAR सॉलिड -m3 से 18 गुना तेज़, और 37 % बड़ा। यह बैकअप और पाइपलाइनों के लिए स्तर है जहाँ अंतिम कुछ मेगाबाइट से अधिक समय मायने रखता है।
• सॉलिड नहीं: इस बहुत-छोटी-फ़ाइलों वाले डेटा पर RAR के डिफ़ॉल्ट (नॉन-सॉलिड) आर्काइव उसके सॉलिड आर्काइवों से लगभग दोगुने बड़े हैं। nikpak की RAR से तुलना करने वाले किसी भी व्यक्ति को RAR में -s जोड़ना चाहिए।

11.4 एक बड़ी मीडिया फ़ाइल पर गति

संक्रिया	nikpak	RAR 7	आकार
बनाना, तेज़ / RAR डिफ़ॉल्ट	1.45 s (-m2)	2.54 s (-m3)	9,415,519 बनाम 11,128,595
बनाना, अधिकतम स्तर	3.14 s (-m5)	5.87 s (-m5)	9,411,898 बनाम 11,024,411
निकालना	0.28 s	0.23 s	समान आउटपुट

मीडिया पर nikpak बनाने में छोटा और तेज़ दोनों है। RAR निकालने में थोड़ा तेज़ है; संभावित कारण यह है कि NAC डिकोडिंग हर सैंपल के लिए पूर्णांक पूर्वानुमान करती है, जिसकी लागत सामान्य डिकोडिंग में हावी मिलान कॉपी से कुछ अधिक होती है।

11.5 एन्क्रिप्शन ओवरहेड

222 MB डेटा सेट पर, एक एन्क्रिप्टेड आर्काइव को 0.64 s अनएन्क्रिप्टेड के मुकाबले 0.92 s लगे, और वह 11,087 बाइट (0.03 %) बड़ा था। अंतर में Argon2id व्युत्पत्ति शामिल है, इसलिए लागत में एक सेकंड का स्थिर अंश हावी है।

11.6 परिणाम दोहराना

# media: which filter wins, per file

nikpak mt song.wav tracker.mod photo.bmp

# archive with nikpak and RAR, then compare

nikpak a -q -ep -m2 test.nik *.wav

rar a -ep -m5 -ma5 test.rar *.wav

# fair comparison on many files: give RAR solid mode

rar a -r -s -m5 -ma5 -md256m data.rar data

nikpak a -m5 data.nik data

# verify

nikpak x -o+ test.nik restore\

11.7 दूसरा रन: nikpak, RAR 7, 7-Zip और ZIP

nikpak 1.2.0 के लिए अद्यतन। इस रन के पहले संस्करण में, nikpak 1.1.0 के साथ, 7-Zip -mx9 टेक्स्ट (1.4 % से), ऑफ़िस फ़ाइलों (3.3 %) और स्रोत कोड (8.5 %) पर आगे था। nikpak 1.2.0 Deflate पुनर्संपीड़न (7.9) और LZMA2 तथा PPMd (6.7) पर बना नया अधिकतम स्तर जोड़ता है, और उसी मशीन पर उन्हीं फ़ाइलों के साथ फिर से मापा गया। RAR, 7-Zip और ZIP के आँकड़े पहले रन से आते हैं।

अनुभाग 11.2 से 11.5 केवल nikpak की RAR से तुलना करते हैं। यह दूसरा रन उन दो आर्काइवरों को जोड़ता है जो अधिकांश लोगों के पास पहले से हैं, 7-Zip और क्लासिक ZIP प्रारूप, और दो प्रकार की फ़ाइलें जो हर दिन आर्काइव होती हैं: सादा टेक्स्ट और ऑफ़िस दस्तावेज़ (.doc, .docx, .xls, .xlsx, .csv, .pdf)। चारों टूल एक के बाद एक उसी मशीन और उन्हीं फ़ाइलों पर चलाए गए, और RAR फिर से मापा गया। संग्रह उन्हीं सार्वजनिक स्रोतों से पुनः बनाए गए, इसलिए निरपेक्ष आकार और समय 11.2 से 11.4 वालों से भिन्न हैं। संख्याओं की तुलना इसी अनुभाग के भीतर करें, अनुभागों के आर-पार नहीं।

विधि

मद	विवरण
मशीन	Linux x86-64 वर्चुअल मशीन (Intel Xeon, 2.8 GHz)। हर कमांड taskset से एक CPU कोर पर पिन किया गया और सिंगल-थ्रेडेड चलाया गया (nikpak -mt1, RAR -mt1, 7-Zip -mmt=1; ZIP डिज़ाइन से सिंगल-थ्रेडेड है)।
सॉफ़्टवेयर	nikpak 1.2.0 (रिलीज़ बिल्ड); RAR 7.00 (-ma5, सॉलिड); 7-Zip 23.01 (.7z प्रारूप, LZMA2, डिफ़ॉल्ट रूप से सॉलिड); Info-ZIP Zip 3.0 और UnZip 6.0 (Deflate)।
स्तर	nikpak: तेज़ स्तर -m2 और अधिकतम -m5, जो 1.2.1 से डिफ़ॉल्ट है (और -m4)। अन्य: डिफ़ॉल्ट और अधिकतम, RAR -m3 -s / -m5 -s, 7-Zip -mx5 / -mx9, ZIP -6 / -9। RAR को सॉलिड मोड (-s) दिया गया, क्योंकि अन्य तीन सॉलिड हैं या, ZIP के मामले में, हो नहीं सकते।
समय	वॉल-क्लॉक सेकंड। 50 MB से कम सेट: तीन रनों में सर्वोत्तम। सामान्य सेट: एक रन।
सत्यापन	सभी 92 आर्काइव निकाले गए और diff -r से मूल से मिलाए गए। सभी समान थे।

परीक्षण सामग्री

सेट	फ़ाइलें	आकार (बाइट)	सामग्री
BMP छवियाँ	8	6,987,840	scikit-image नमूना सेट से छह तस्वीरें 24-बिट BMP के रूप में, साथ ही एक 8-बिट ग्रेस्केल तस्वीर और एक 8-बिट कंकड़ बनावट।
ProTracker MOD	16	2,252,604	libxmp परीक्षण संग्रह के 16 सबसे बड़े ProTracker मॉड्यूल।
गैलरी WAV	35	2,991,820	वही 35 LibreOffice गैलरी ध्वनियाँ जैसा 11.1 में।
संगीत, चार प्रारूप	4 × 1	53,417,226	TiMidity++ और Freepats से 44.1 kHz स्टीरियो 16-बिट में रेंडर किया गया नया 100-सेकंड टुकड़ा (पियानो, तार, बास, बाँसुरी, ड्रम), फिर SoX द्वारा 22.05 kHz मोनो 16-बिट और 8-बिट तथा 48 kHz स्टीरियो 24-बिट में परिवर्तित।
सादा टेक्स्ट	18	11,793,318	Project Gutenberg की अठारह पुस्तकें .txt के रूप में (Austen, Melville, Shakespeare, King James Bible और अन्य)।
ऑफ़िस फ़ाइलें	60	39,100,915	.docx, .doc और .pdf के रूप में 12 रिपोर्टें (टेक्स्ट, शीर्षक, तालिकाएँ और कुछ तस्वीरें) और .xlsx, .xls तथा .csv (सूत्रों के साथ) के रूप में 500 से 30,000 पंक्तियों की 8 बिक्री कार्यपुस्तिकाएँ, LibreOffice द्वारा सहेजी गईं।
सामान्य डेटा	11,473	190,454,632	Python 3.12 और 3.13 मानक लाइब्रेरियाँ, Debian Python पैकेज, C हेडर (/usr/include) और /usr/share/doc। सिम्बॉलिक लिंक हटाए गए।

अधिकतम स्तर: आर्काइव आकार

सेट	मूल	nikpak -m5	RAR 7 -m5	7-Zip -mx9	ZIP -9
8 BMP छवियाँ	6,987,840	3,557,350	4,394,310	4,195,043	4,974,680
16 ProTracker MOD फ़ाइलें	2,252,604	1,127,607	1,264,245	1,166,855	1,408,085
35 गैलरी WAV (मोनो 16-बिट)	2,991,820	1,346,484	1,596,971	1,484,879	1,852,279
संगीत 44.1 kHz स्टीरियो 16-बिट	17,760,408	8,731,989	10,460,042	10,666,922	15,225,764
संगीत 22.05 kHz मोनो 16-बिट	4,440,136	2,458,867	2,797,026	2,784,080	3,736,722
संगीत 22.05 kHz मोनो 8-बिट	2,220,090	606,840	725,416	642,341	836,989
संगीत 48 kHz स्टीरियो 24-बिट	28,996,592	18,198,056	21,229,465	25,542,036	26,980,770
18 सादा-टेक्स्ट पुस्तकें (.txt)	11,793,318	2,741,898	3,519,622	3,259,868	4,223,579
60 ऑफ़िस फ़ाइलें	39,100,915	6,887,729	11,186,217	10,085,779	17,399,998
सामान्य डेटा (11,473 फ़ाइलें)	190,454,632	28,175,618	33,606,893	28,879,398	62,198,510

सभी आकार बाइट में हैं। हर पंक्ति में सबसे छोटा आर्काइव बोल्ड में दिखाया गया है।

तेज़ स्तर: आकार और निर्माण समय

सेट	nikpak -m2	RAR 7 -m3	7-Zip -mx5	ZIP -6
8 BMP छवियाँ	54.0 % · 0.39 s	63.0 % · 2.09 s	60.1 % · 3.51 s	71.2 % · 0.35 s
16 ProTracker MOD फ़ाइलें	52.4 % · 0.61 s	56.2 % · 0.43 s	51.9 % · 0.69 s	62.7 % · 0.10 s
35 गैलरी WAV (मोनो 16-बिट)	51.1 % · 0.41 s	53.6 % · 0.71 s	49.6 % · 1.96 s	61.9 % · 0.24 s
संगीत 44.1 kHz स्टीरियो 16-बिट	49.2 % · 1.72 s	59.9 % · 3.60 s	60.1 % · 14.03 s	85.7 % · 0.82 s
संगीत 22.05 kHz मोनो 16-बिट	55.4 % · 0.58 s	64.1 % · 0.95 s	62.7 % · 2.14 s	84.2 % · 0.22 s
संगीत 22.05 kHz मोनो 8-बिट	27.4 % · 0.77 s	33.3 % · 0.52 s	28.9 % · 2.13 s	38.2 % · 0.32 s
संगीत 48 kHz स्टीरियो 24-बिट	62.8 % · 2.06 s	73.6 % · 7.54 s	88.1 % · 13.54 s	93.0 % · 1.19 s
18 सादा-टेक्स्ट पुस्तकें (.txt)	35.2 % · 0.11 s	30.4 % · 5.53 s	27.7 % · 11.76 s	36.0 % · 0.89 s
60 ऑफ़िस फ़ाइलें	38.0 % · 0.22 s	29.5 % · 8.25 s	26.2 % · 21.85 s	44.7 % · 1.83 s
सामान्य डेटा (11,473 फ़ाइलें)	25.3 % · 1.67 s	18.0 % · 48.19 s	17.0 % · 93.71 s	32.9 % · 7.32 s

nikpak -m2 अन्य टूल्स के डिफ़ॉल्ट स्तर के मुकाबले। हर कक्ष मूल के प्रतिशत के रूप में आर्काइव आकार और एक कोर पर निर्माण समय दिखाता है। हर पंक्ति में सबसे छोटा आर्काइव बोल्ड में है।

सामान्य डेटा विस्तार से

टूल और स्तर	आकार (बाइट)	मूल का %	निर्माण	निष्कर्षण
nikpak -m5	28,175,618	14.8 %	154.3 s	5.6 s
7-Zip -mx9	28,879,398	15.2 %	120.9 s	6.0 s
RAR 7 -m5 -s -md256m	32,350,575	17.0 %	73.6 s	7.0 s
7-Zip -mx5	32,375,802	17.0 %	93.7 s	4.5 s
nikpak -m4	33,295,133	17.5 %	37.8 s	3.3 s
RAR 7 -m5 -s	33,606,893	17.6 %	72.4 s	6.7 s
RAR 7 -m3 -s	34,236,198	18.0 %	48.2 s	5.9 s
nikpak -m2	48,229,284	25.3 %	1.7 s	0.9 s
RAR 7 -m3 (सॉलिड नहीं)	56,038,351	29.4 %	20.2 s	6.9 s
ZIP -9	62,198,510	32.7 %	28.2 s	6.9 s
ZIP -6	62,672,415	32.9 %	7.3 s	5.4 s

1.1.0 से 1.2.0 तक

सेट	nikpak 1.1.0 -m5	nikpak 1.2.0 -m5	7-Zip -mx9	1.2.0 बनाम 7-Zip
18 सादा-टेक्स्ट पुस्तकें	3,306,819	2,741,898	3,259,868	15.9 % छोटा
60 ऑफ़िस फ़ाइलें	10,417,750	6,887,729	10,085,779	31.7 % छोटा
सामान्य डेटा	31,322,041	28,175,618	28,879,398	2.4 % छोटा

परिणामों को ईमानदारी से पढ़ना

• nikpak -m5 हर सेट पर सबसे छोटा है। 7-Zip -mx9 के मुकाबले यह 2.4 से 31.7 % छोटा है, RAR 7 -m5 के मुकाबले 10.8 से 38.4 % और ZIP -9 के मुकाबले 19.9 से 60.4 %। रिकॉर्ड किए गए ऑडियो पर NAC वह पूर्वानुमान करता है जो LZ-आधारित कंप्रेसर केवल मिला सकते हैं: 24-बिट संगीत पर 7-Zip 12 % और nikpak 37 % बचाता है।
• ऑफ़िस फ़ाइलें: 7-Zip से 31.7 % छोटी। Deflate पुनर्संपीड़न 6.6 MB .xlsx और 1.9 MB .docx को सादे XML में बदल देता है जिसे LZMA2 Deflate की तुलना में कहीं बेहतर संपीड़ित करता है (10.09 MB के मुकाबले 6.89 MB)। यहाँ तक कि -m4 भी 7-Zip -mx9 से 1.3 % छोटा और तेज़ है (26 s के मुकाबले 16 s)। -m5 पर कीमत समय है: 26 s के मुकाबले 81 s।
• टेक्स्ट: 15.9 % छोटा, आधे समय में। गद्य पर PPMd जीतता है (बनाने में 12.9 s के मुकाबले 6.4 s)। क्योंकि PPMd जितना धीमा एनकोड करता है उतना ही धीमा डिकोड करता है, निष्कर्षण 0.2 s के बजाय 2.7 s लेता है।
• स्रोत कोड: 2.4 % छोटा, थोड़ी-सी बढ़त। 28.9 MB के मुकाबले 28.2 MB, 121 s के मुकाबले 154 s में। फ़ाइल प्रकार से क्रमबद्ध करना और सन्निहित नमूनों पर इंजन चुनना (6.7) अंतर लाया।
• तेज़ स्तर -m2: सबसे तेज़, सबसे छोटा नहीं। nikpak -m2 को सामान्य सेट के लिए 1.7 s लगते हैं, जबकि 7-Zip -mx5 को 93.7 s (56 गुना लंबा), RAR को 48.2 s और ZIP को 7.3 s। यह छवियों और अधिकांश ऑडियो पर 7-Zip -mx5 से छोटा है (MOD फ़ाइलें और गैलरी WAV 1 से 3 % बड़े हैं), पर टेक्स्ट, ऑफ़िस फ़ाइलों और स्रोत कोड पर बड़ा है (सामान्य सेट पर 49.0 %)। इसीलिए, संस्करण 1.2.1 से nikpak डिफ़ॉल्ट रूप से -m5 उपयोग करता है; -m2 माँगना पड़ता है।
• ZIP तेज़ है पर हर जगह सबसे बड़ा। यहाँ तक कि nikpak -m2 हर सेट पर ZIP -9 को मात देता है। ZIP छोटे मीडिया आर्काइव nikpak -m2 से तेज़ बनाता है, क्योंकि Deflate NAC कोडेक से कहीं कम काम करता है, पर यह टेक्स्ट, ऑफ़िस फ़ाइलों और स्रोत कोड पर धीमा है।
• निष्कर्षण। सामान्य सेट 0.9 s (nikpak -m2) या 5.6 s (-m5) में निकलता है, जबकि 7-Zip को 6.0 s, RAR को 6.7 s और ZIP को 6.9 s। पुनर्संपीड़ित Deflate स्ट्रीमों वाले आर्काइव अधिक धीमे निकलते हैं, क्योंकि हर स्ट्रीम पुनर्निर्मित होती है (ऑफ़िस सेट के लिए 0.7 s के मुकाबले 2.1 s)।
• इस मशीन पर RAR। RAR यहाँ 11.3 की तुलना में धीमा था (समान मात्रा के स्रोत कोड पर -m5 -s के लिए 27 s के बजाय 72 s)। मशीन और डेटा भिन्न हैं, इसलिए दोनों अनुभागों को नहीं मिलाना चाहिए। इस रन के भीतर हर टूल को समान परिस्थितियाँ मिलीं।

nikpak के लिए इसका क्या अर्थ है

अधिकतम स्तर पर nikpak 1.2.0 मापे गए हर सेट पर चारों टूल्स में सबसे छोटा आर्काइव बनाता है, 7-Zip -mx9 से 2.4 से 31.7 % छोटा। कीमत गति है: -m5 सिंगल-थ्रेडेड है और ऑफ़िस फ़ाइलों तथा स्रोत कोड पर 7-Zip से धीमा है। इसे तेज़ करना रोडमैप पर है (अनुभाग 15.2)।

12 nikpak और RAR की तुलना

RAR एक उत्कृष्ट और व्यापक रूप से उपयोग किया जाने वाला आर्काइवर है, और यह अध्याय अन्यथा दिखावा नहीं करता। यह बताता है कि माप और डिज़ाइन nikpak के पक्ष में कहाँ हैं, RAR कहाँ आगे है, और किसे क्या चुनना चाहिए।

12.1 nikpak कहाँ आगे है

क्षेत्र	nikpak	प्रमाण
ऑडियो, छवियाँ, ट्रैकर संगीत	मापे गए हर मीडिया सेट पर RAR 7 -m5 से 12 - 39 % छोटा	अनुभाग 11.2
स्रोत कोड, अधिकतम स्तर	RAR की सर्वोत्तम सॉलिड सेटिंग से 5.5 % छोटा	अनुभाग 11.3
तेज़ स्तर -m2 पर गति	197 MB के लिए 9.7 - 16.7 s के मुकाबले 0.9 s; एक WAV के लिए 2.54 s के मुकाबले 1.45 s	अनुभाग 11.3, 11.4
सिफर और मोड	XChaCha20-Poly1305, प्रमाणित; RAR5 CBC मोड में AES-256 उपयोग करता है, जो प्रमाणित नहीं है और अलग चेकसमों पर निर्भर करता है	अध्याय 8
पासवर्ड हैशिंग	Argon2id, मेमोरी-हार्ड (64 MiB); RAR5 PBKDF2-HMAC-SHA256 उपयोग करता है, जो CPU-बद्ध है और GPU पर सस्ते में समानांतर होता है	अनुभाग 8.2
फ़ाइल-नाम गोपनीयता	हमेशा एन्क्रिप्टेड; RAR को -hp स्विच चाहिए	अनुभाग 8.4
पासवर्ड निर्माण	अंतर्निहित: कुछ न दिए जाने पर मज़बूत यादृच्छिक पासवर्ड	अनुभाग 3.3
छेड़छाड़ प्रमाण	पुनः क्रमबद्धता, कटाव और हेडर बदलाव क्रिप्टोग्राफ़िक रूप से पकड़े जाते हैं	अनुभाग 8.6
पारदर्शिता	पूर्ण स्रोत और दस्तावेज़ित प्रारूप; मेमोरी-सुरक्षित Rust में कार्यान्वयन	अध्याय 5, 10
वितरण	एक स्थिर एग्ज़िक्यूटेबल (ड्रॉप विंडो और कमांड लाइन; विंडो के बिना लगभग 2.3 MB), या एक छोटा Windows इंस्टॉलर; शेयरवेयर, व्यक्तिगत उपयोग के लिए निःशुल्क (3.8)	अध्याय 13

12.2 RAR कहाँ आगे है

क्षेत्र	RAR 7	nikpak आज
रिकवरी रिकॉर्ड	क्षतिग्रस्त आर्काइव सुधार सकता है	क्षति पकड़ता है, सुधार नहीं सकता
मल्टी-वॉल्यूम आर्काइव	हाँ	नहीं
स्व-निष्कर्षण आर्काइव	हाँ	नहीं
आर्काइव अद्यतन करना	फ़ाइलें स्थान पर ही जोड़ें, बदलें और हटाएँ	केवल बनाना या अधिलेखित करना
ग्राफ़िकल इंटरफ़ेस	WinRAR, शेल एकीकरण के साथ	संपीड़न के लिए ड्रॉप विंडो (3.7); कोई शेल एकीकरण नहीं, कमांड लाइन से निष्कर्षण
अधिकतम-स्तर गति	सामान्य सेट पर 26.7 - 36.2 s	45.6 s
मीडिया पर निष्कर्षण गति	17 MB WAV के लिए 0.23 s	0.28 s
परिपक्वता और पहुँच	दशकों का फ़ील्ड परीक्षण; लाखों मौजूदा .rar फ़ाइलें	नया; कोई स्वतंत्र ऑडिट नहीं; केवल .nik पढ़ता है

12.3 क्वांटम प्रतिरोध परिप्रेक्ष्य में

nikpak और RAR5 दोनों 256-बिट सिमेट्रिक कुंजी से एन्क्रिप्ट करते हैं, इसलिए दोनों Shor के एल्गोरिदम से अछूते हैं और दोनों Grover के विरुद्ध लगभग 128 बिट सुरक्षा रखते हैं। कोई भी दावा उन्हें अलग नहीं करता। nikpak ऊपर से जो जोड़ता है वह एक मेमोरी-हार्ड पासवर्ड चरण (जो प्रमुख वास्तविक-दुनिया हमले, पासवर्ड अनुमान, को कहीं अधिक महँगा बनाता है) और प्रमाणित एन्क्रिप्शन (जो छेड़छाड़ को पकड़ने योग्य बनाता है) है। इसे शुरू से इसी धारणा पर डिज़ाइन किया गया है कि आर्काइव प्रारूप का हिस्सा कभी कोई सार्वजनिक-कुंजी प्रिमिटिव नहीं होगा, और इसका रोडमैप सार्वजनिक-कुंजी साझा जोड़े जाने पर हाइब्रिड पोस्ट-क्वांटम योजना के लिए प्रतिबद्ध है।

12.4 किसे चुनें

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

12.5 और 7-Zip और ZIP?

अनुभाग 11.7 nikpak 1.2 की 7-Zip 23.01 और Info-ZIP 3.0 से भी तुलना करता है। संक्षेप में:

• सबसे छोटे आर्काइव के लिए nikpak -m5 चुनें। यह मापे गए हर सेट पर 7-Zip -mx9 से 2.4 से 31.7 % छोटा है: ऑफ़िस फ़ाइलों पर 31.7 %, टेक्स्ट पर 15.9 % और स्रोत कोड पर 2.4 %। तेज़ बैकअप के लिए nikpak -m2 चुनें (स्रोत कोड पर 7-Zip के डिफ़ॉल्ट से 56 गुना तेज़)। nikpak का एन्क्रिप्शन भी मज़बूत है: 7-Zip AES-256 को SHA-256 कुंजी व्युत्पत्ति के साथ उपयोग करता है जो मेमोरी-हार्ड नहीं है, और यह फ़ाइल नाम केवल -mhe से छिपाता है।
• 7-Zip चुनें जब अधिकतम स्तर पर समय अधिक मायने रखे (यह बड़े ऑफ़िस और स्रोत-कोड सेटों पर तेज़ है), जब आपको दस्तावेज़ों पर इसका डिफ़ॉल्ट स्तर छोटा चाहिए, या जब आपको 7-Zip द्वारा पढ़े जाने वाले कई प्रारूप खोलने हों।
• ZIP केवल संगतता के लिए चुनें। हर ऑपरेटिंग सिस्टम इसे बिना अतिरिक्त सॉफ़्टवेयर खोलता है, पर nikpak -m5 19.9 से 60.4 % छोटा है, और ZIP का पारंपरिक एन्क्रिप्शन कमज़ोर है।

13 बिल्ड, तैनाती और एकीकरण

13.1 PowerShell के साथ Windows

nikpak Rust में लिखा है और Cargo से बनता है। Windows पर, Rust को एक C/C++ लिंकर चाहिए, जो Visual Studio Build Tools से मिलता है। एक व्यवस्थापक PowerShell में, दोनों एक बार स्थापित करें और फिर PowerShell फिर से खोलें:

winget install Rustlang.Rustup

$o = '--wait --passive --add Microsoft.VisualStudio.Workload.VCTools'

$o += ' --includeRecommended'

winget install Microsoft.VisualStudio.2022.BuildTools --override $o

यदि winget उपलब्ध नहीं है, तो rustup.rs से Rust और Build Tools for Visual Studio को Desktop development with C++ वर्कलोड के साथ स्थापित करें। फिर, स्रोतों वाले फ़ोल्डर में:

.\build.ps1 # builds dist\nikpak.exe and dist\unNik.exe

.\build.ps1 -Test # runs the unit tests first

# if PowerShell refuses to run scripts:

powershell -ExecutionPolicy Bypass -File .\build.ps1

build.ps1 जाँचता है कि Cargo स्थापित है (और नहीं होने पर बताता है कि कैसे स्थापित करें), बिल्ड चलाता है, विफल होने पर सामान्य कारण समझाता है, और एग्ज़िक्यूटेबल को dist\nikpak.exe में कॉपी करता है।

Windows इंस्टॉलर

.\build.ps1 -Installer (या npm run installer) Inno Setup 6.3 या नया से सेटअप प्रोग्राम dist\nikpak--setup.exe भी बनाता है (इसे एक बार winget install JRSoftware.InnoSetup से स्थापित करें)। स्क्रिप्ट installer\nikpak.iss है; संस्करण Cargo.toml से लिया जाता है। यही सेटअप फ़ाइल शेयरवेयर और डाउनलोड साइटों पर अपलोड की जाती है।

• डिफ़ॉल्ट रूप से यह केवल वर्तमान उपयोगकर्ता के लिए स्थापित करता है, बिना व्यवस्थापक अधिकार या UAC संकेत के, %LOCALAPPDATA%\Programs\NikPak में। इसका पहला पृष्ठ "सभी उपयोगकर्ताओं के लिए स्थापित करें" (Program Files, व्यवस्थापक अधिकार चाहिए) प्रस्ताव देता है।
• यह स्वीकृति के लिए LICENSE.txt दिखाता है और nikpak.exe, unNik.exe, आइकन, LICENSE.txt, THIRD-PARTY-NOTICES.txt और CHANGELOG.md स्थापित करता है। यह एक स्टार्ट मेन्यू प्रविष्टि, एक वैकल्पिक डेस्कटॉप आइकन और, अनुरोध पर, कमांड लाइन के लिए फ़ोल्डर को PATH में जोड़ता है। यह Settings > Apps में एक अनइंस्टॉलर पंजीकृत करता है।
• शॉर्टकट: स्टार्ट मेन्यू में NikPak, unNik और लाइसेंस; डेस्कटॉप पर NikPak (हमेशा) और डेस्कटॉप पर unNik विकल्प के रूप में।
• .nik फ़ाइलें हमेशा पंजीकृत होती हैं (1.5.2 से): उन्हें अपना आइकन मिलता है (nikfile.ico, ज़िपर वाला एक पृष्ठ, जैसे .zip फ़ाइलें), प्रकार नाम "NikPak archive", और डबल-क्लिक उन्हें unNik में खोलता है (राइट-क्लिक मेन्यू में "unNik के साथ खोलें")। unNik "इसके साथ खोलें" और Default apps में भी सूचीबद्ध होता है। अनइंस्टॉलर पंजीकरण हटा देता है। यदि .nik फ़ाइलें पहले से किसी अन्य प्रोग्राम से खोलने के लिए सेट हैं, तो Windows वह चुनाव तब तक रखता है जब तक unNik एक बार "इसके साथ खोलें" में नहीं चुना जाता।
• अंतिम "NikPak लॉन्च करें" NikPak को सामान्य उपयोगकर्ता के रूप में शुरू करता है, कभी व्यवस्थापक के रूप में नहीं, ताकि ड्रैग और ड्रॉप काम करे। अपडेट पिछले संस्करण पर स्थापित होते हैं (स्थिर AppId)। %APPDATA%\nikpak में लाइसेंस अपडेट और अनइंस्टॉल पर रखा जाता है। सेटअप में कभी कुंजियाँ या कुंजी फ़ाइलें नहीं होतीं।
• इंस्टॉलर Windows का अनुसरण करते हुए English या French में चलता है। प्रकाशन से पहले, nikpak.exe और सेटअप को कोड-साइनिंग प्रमाणपत्र से हस्ताक्षरित करें, ताकि Windows SmartScreen किसी अज्ञात प्रकाशक के बारे में चेतावनी न दे।

buildall.ps1 एक ही रन में प्रकाशित होने वाली हर चीज़ बनाता है — nikpak.exe, unNik.exe, दोनों सेटअप और SHA256SUMS.txt — उन्हें binaries\ में कॉपी करता है, वेब साइट फिर से बनाता है और FTP से अपलोड करता है (-NoUpload अपलोड छोड़ देता है)। दूसरा सेटअप, unnik--setup.exe (installer\unnik.iss), अकेले unNik, निःशुल्क आर्काइव ब्राउज़र, स्थापित करता है; जब NikPak पहले से स्थापित है तो यह केवल प्रोग्राम स्थापित करता है, ताकि मेन्यू कभी दोहरे न हों।

13.2 npm से बिल्ड करना

Rust परियोजनाएँ npm उपयोग नहीं करतीं, इसलिए npm कभी आवश्यक नहीं है। सुविधा के लिए, परियोजना में एक छोटा package.json है जिसकी स्क्रिप्टें बस Cargo बुलाती हैं, ताकि Node.js वर्कफ़्लो में रहने वाला डेवलपर परिचित कमांड टाइप कर सके:

npm run build # cargo build --release

npm run dist # build.ps1 -> dist\nikpak.exe

npm test # cargo test --release

npm run clean # cargo clean

13.3 एक स्व-निहित एग्ज़िक्यूटेबल

फ़ाइल .cargo/config.toml Windows MSVC लक्ष्यों के लिए C रनटाइम को स्थिर रूप से लिंक करती है। इसलिए परिणामी nikpak.exe (ग्राफ़िकल इंटरफ़ेस के साथ कई MB, बिना उसके लगभग 2.3 MB) की कोई DLL निर्भरता नहीं होती और जिन मशीनों पर चलता है वहाँ Visual C++ Redistributable की आवश्यकता नहीं होती। इसे कहीं भी उपयोग करने के लिए PATH के किसी फ़ोल्डर में कॉपी करें। रिलीज़ प्रोफ़ाइल छोटे, तेज़ बाइनरी के लिए पूर्ण अनुकूलन, लिंक-टाइम अनुकूलन, एकल कोड-जनरेशन इकाई, प्रतीक हटाना और panic = abort सक्षम करती है।

13.4 macOS और Linux

./build.sh # builds and copies the result to dist/nikpak

# or: cargo build --release

sudo cp dist/nikpak /usr/local/bin/

macOS पर पहले कमांड-लाइन टूल स्थापित करें (xcode-select --install); Debian या Ubuntu पर एक C कंपाइलर स्थापित करें (sudo apt install build-essential)। Rust स्वयं curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh से आता है। संपीड़न लाइब्रेरी Cargo द्वारा उसके C स्रोतों से संकलित होती है, इसलिए कोई सिस्टम लाइब्रेरी आवश्यक नहीं।

साइट के macOS और Linux डाउनलोड ./package-unix.sh से बनते हैं, जो nikpak और unNik बनाता है और उन्हें एक install.sh के साथ binaries\nikpak--macos.zip (एक यूनिवर्सल बाइनरी: Intel + Apple silicon) या binaries\nikpak--linux-.tar.gz में पैक करता है। Linux पर ZIG=1 सेट करके cargo-zigbuild से glibc 2.28 के विरुद्ध बिल्ड करें, ताकि प्रोग्राम पुराने वितरणों पर भी चलें।

13.5 निर्भरताएँ

संस्करण 1.2 से nikpak को Rust 1.89 या नया चाहिए। build.ps1 और build.sh स्थापित संस्करण जाँचते हैं और पुराना होने पर rustup update stable चलाते हैं। npm के साथ, npm run build से पहले एक बार rustup update चलाएँ।

nikpak परिपक्व crates के एक छोटे सेट पर निर्भर है। उनके सटीक संस्करण Cargo.lock में स्थिर हैं, जो स्रोत पैकेज का हिस्सा है, इसलिए हर बिल्ड वही कोड उपयोग करता है।

Crate	उद्देश्य
zstd	Zstandard संपीड़न, मल्टी-थ्रेडिंग के साथ
chacha20poly1305	XChaCha20-Poly1305 और STREAM निर्माण (RustCrypto)
argon2	Argon2id कुंजी व्युत्पत्ति (RustCrypto)
rand	ऑपरेटिंग सिस्टम के सुरक्षित यादृच्छिक जनरेटर तक पहुँच
zeroize	मेमोरी से कुंजियाँ और पासवर्ड मिटाना
rpassword	हर प्लेटफ़ॉर्म पर बिना प्रतिध्वनि पासवर्ड पढ़ना
crc32fast	तेज़ CRC32
glob	वाइल्डकार्ड विस्तार (PowerShell मूल प्रोग्रामों के लिए वाइल्डकार्ड विस्तारित नहीं करता)
liblzma	-m5 के लिए LZMA2 इंजन (liblzma, C स्रोतों से स्थिर रूप से संकलित)
ppmd-rust	-m5 पर टेक्स्ट के लिए PPMd variant I इंजन
preflate-rs	बिट-सटीक Deflate पुनर्संपीड़न (Microsoft, Apache-2.0); vendor/preflate-rs में एक वेंडर की गई प्रति जिसका LGPL एन्ट्रॉपी कोडर (cabac) nikpak के अपने रेंज कोडर से बदला गया है, इसलिए nikpak में कोई LGPL कोड नहीं है। Rust 1.89 या नया चाहिए
eframe / egui	ग्राफ़िकल इंटरफ़ेस (वैकल्पिक cargo feature gui, डिफ़ॉल्ट रूप से चालू)
rfd	Browse के लिए मूल फ़ोल्डर डायलॉग
ed25519-dalek	लाइसेंस कुंजी हस्ताक्षरों का सत्यापन (अनुभाग 3.8)
rustybuzz, unicode-bidi	विंडो में हिंदी, बंगाली और अरबी की शेपिंग और दाएँ-से-बाएँ क्रमबद्धता (वैकल्पिक cargo feature gui)

13.6 स्क्रिप्टिंग

पूर्वानुमान योग्य एग्ज़िट कोड और एनवायरनमेंट-वेरिएबल पासवर्ड nikpak को स्क्रिप्ट करना आसान बनाते हैं। एक PowerShell बैकअप जो चेतावनियों को स्वीकार्य और कुछ भी बदतर को विफलता मानता है:

$archive = "D:\Backups\docs-$(Get-Date -Format yyyy-MM-dd).nik"

# the password comes from a file or secret store, not from the script

$env:NIKPAK_PASSWORD = Get-Content "$env:USERPROFILE\.nikpak-secret"

nikpak a -p -m3 -inul $archive "$env:USERPROFILE\Documents"

if ($LASTEXITCODE -gt 1) { throw "nikpak failed: $LASTEXITCODE" }

nikpak t -inul $archive # verify what was written

if ($LASTEXITCODE -ne 0) { throw "archive verification failed" }

शेल स्क्रिप्ट में वही, अन्य टूल्स को खिलाने के लिए सादी सूची कमांड उपयोग करते हुए:

export NIKPAK_PASSWORD="$(cat ~/.nikpak-secret)"

nikpak a -p -m3 -inul "backup-$(date +%F).nik" ~/Documents || [ $? -eq 1 ]

nikpak lb backup-2026-10-16.nik | grep -i '\.wav$'

13.7 Total Commander

अनुभाग 3.6 में वर्णित एकीकरण nikpak द्वारा RAR के सिंटैक्स का पालन करने पर निर्भर है। एक छोटी चेकलिस्ट: एक्सटेंशन nik पंजीकृत करें; पैकिंग के लिए a और अनपैकिंग के लिए x उपयोग करें; लंबी फ़ाइल सूचियों के लिए फ्रंट-एंड को @listfile भेजने दें; अनअटेंडेड निष्कर्षण के लिए -o+ या -y दें; और पासवर्ड -p या NIKPAK_PASSWORD वेरिएबल से दें, क्योंकि ग्राफ़िकल फ्रंट-एंड के पास संकेत देने के लिए कोई कंसोल नहीं होता।

14 परीक्षण और सत्यापन

क्योंकि एक आर्काइवर लोगों का डेटा रखता है, nikpak का चार स्तरों पर परीक्षण किया जाता है।

14.1 यूनिट परीक्षण

चौंतीस स्वचालित परीक्षण cargo test --release से चलते हैं:

क्षेत्र	क्या जाँचा जाता है
एन्क्रिप्शन स्ट्रीम	0, 1, 100, 65,535, 65,536, 65,537, 131,072, 131,077 और 327,803 बाइट पर राउंड ट्रिप (64 KiB चंक सीमाओं के आस-पास); गलत हेडर (एसोसिएटेड डेटा), गलत कुंजी और कटाव सभी को विफल होना चाहिए।
कुंजी-व्युत्पत्ति सीमाएँ	दुर्भावनापूर्ण Argon2id पैरामीटर (विशाल मेमोरी, शून्य पास, शून्य लेन, अत्यधिक पास) अस्वीकार किए जाते हैं।
NAC ऑडियो कोडेक	8/16/24/32-बिट ऑडियो, 1, 2, 3 और 6 चैनलों, नौ संकेत प्रकारों (मौन, शोरयुक्त साइन, श्वेत शोर, पूर्ण-पैमाना वर्ग तरंग, रैम्प, एकल आवेग, स्थिर अधिकतम, व्यर्थ निचले बिट, स्थिर न्यूनतम), 1 से 5000 सैंपलों की आठ ब्लॉक लंबाइयों, तीन प्रयास स्तरों और बाध्य वर्बेटिम कोडिंग के लिए दोषरहित राउंड ट्रिप।
ऑडियो विधियाँ	NAC, Shuffle और Shuffle+Delta सभी बिट गहराइयों, चैनल गणनाओं, बाइट क्रमों और चिह्नितता में, जिसमें वे ब्लॉक भी शामिल हैं जो समान रूप से विभाजित नहीं होते।
पहचान और फ़ाइलें	WAV (मोनो, स्टीरियो, 8/16/24/32-बिट, एक्सटेंसिबल, छह चैनल, अनुगामी चंक, विषम बचे बाइट, शून्य और अतिआकार डेटा लंबाई), AIFF, MOD (काटा हुआ भी) और BMP (8/24/32-बिट, पंक्ति पैडिंग, अनुगामी डेटा); फ़्लोटिंग-पॉइंट WAV, छोटी फ़ाइलें और टेक्स्ट पहचाने नहीं जाने चाहिए; हर फ़ाइल हर लागू फ़िल्टर से राउंड-ट्रिप होती है।
मज़बूती	ऑडियो डिकोडर और मीडिया डिकोडर को खिलाए गए हज़ारों यादृच्छिक और बिट-फ़्लिप्ड ब्लॉक: उन्हें त्रुटियाँ लौटानी चाहिए, कभी पैनिक नहीं करना या मेमोरी ख़त्म नहीं करना चाहिए।
फ़्रेमिंग और सहायक	अनुगामी डेटा के साथ चंक फ़्रेमिंग, पथ सफ़ाई, वाइल्डकार्ड और फ़िल्टर मिलान, तिथि फ़ॉर्मेटिंग, पासवर्ड निर्माण।
Deflate पुनर्संपीड़न	Deflate स्तर 1, 3, 6 और 9 पर ZIP कंटेनर, दो zlib स्ट्रीमों वाला PDF, तीन-सदस्यीय gzip, गैर-कंटेनर; 400 क्षतिग्रस्त या काटी गई पुनर्संपीड़ित स्ट्रीमों को साफ-सुथरा विफल होना चाहिए (preflate पैनिक पकड़े जाते हैं)।
मल्टी-इंजन ब्लॉक	256 KiB फ़्रेम सीमा के आस-पास zstd, LZMA2 और PPMd ब्लॉकों के माध्यम से राउंड ट्रिप; 300 क्षतिग्रस्त या काटी गई बॉडी; दुर्भावनापूर्ण इंजन पैरामीटर; PPMd/LZMA2 परीक्षण।
ग्राफ़िकल इंटरफ़ेस	वर्चुअल डिस्प्ले (Xvfb) पर चलाना: idle, hover, progress और done स्क्रीन दृष्टिगत जाँची गईं; ड्रॉप किया गया फ़ोल्डर आर्काइव और बाइट-दर-बाइट निकाला गया; संपीड़न के दौरान Cancel और बंद करना कोई फ़ाइल पीछे नहीं छोड़ता; कोई डिस्प्ले न होने पर उपयोग टेक्स्ट पर फ़ॉलबैक।
लाइसेंस	nikpak-keygen और PHP किट से बनी कुंजियाँ समान और स्वीकृत होती हैं; बदला गया नाम, ई-मेल, प्रकार या कुंजी, और किसी अन्य कुंजी से हस्ताक्षरित कुंजियाँ अस्वीकार होती हैं। वर्चुअल डिस्प्ले पर: दोनों बटन क्रमों में अनुस्मारक, गलत कुंजी त्रुटि, सफल पंजीकरण, बिना अनुस्मारक पुनः आरंभ; टेक्स्ट बॉक्सों के अंदर रहता है।
भाषाएँ	हर भाषा हर टेक्स्ट का वही प्लेसहोल्डरों के साथ अनुवाद करती है; देवनागरी मात्राएँ और अरबी जुड़ाव शेप किए जाते हैं; वर्चुअल डिस्प्ले पर सभी दस भाषाएँ स्क्रीन-दर-स्क्रीन जाँची गईं (अनुस्मारक, idle, progress, done, About, पंजीकरण, भाषा मेन्यू); भाषा चुनने पर वह सहेजी जाती है और nikpak उसमें पुनः आरंभ होता है।
आर्काइव API	सूचकांक पढ़ना, किसी फ़ोल्डर के अंदर से एक फ़ाइल निकालना (वह फ़ोल्डर के पथ के बिना उतरती है), फ़ोल्डर को उसकी सामग्री सहित हटाना और सब कुछ हटाना, -m5, zstd + एन्क्रिप्शन और स्टोर आर्काइवों के लिए; गलत पासवर्ड वैसा ही सूचित होता है।
आर्काइव ब्राउज़र	निहित फ़ोल्डरों के साथ ट्री निर्माण, टेक्स्ट पहचान और डिकोडिंग (UTF-8, UTF-16, Windows-1252), व्यूअर में पंक्ति लपेटन और खोज। वर्चुअल डिस्प्ले पर: खोलना, पासवर्ड, नेविगेशन, चयन, खोज, व्यूअर, निष्कर्षण, हटाना और परीक्षण, कई भाषाओं में।
स्किन और फ़ाइल-प्रबंधक मेन्यू	Linux मेन्यू फ़ाइलें जनरेट और जाँची जाती हैं; एक चयन के लिए एक आर्काइव तीन प्रोग्रामों के रूप में शुरू हुआ; तीन आइटमों के साथ --add-here और वर्चुअल डिस्प्ले के अंतर्गत --extract-here / --extract-to; एन्क्रिप्टेड आर्काइव अपना पासवर्ड माँगते हैं और समान फ़ाइलें निकालते हैं; हर नया इंटरफ़ेस टेक्स्ट दस भाषाओं में अनुवादित होता है (हर-भाषा-हर-टेक्स्ट-का-अनुवाद करती है अभिकथन)।

14.2 एंड-टू-एंड परीक्षण

• हर बेंचमार्क आर्काइव निकाला गया और उसके स्रोत से बाइट-दर-बाइट मिलाया गया (10,949-फ़ाइल सेट के लिए SHA-256), कई स्तरों पर।
• एक मिश्रित आर्काइव (WAV, MOD, BMP, टेक्स्ट, यादृच्छिक डेटा, उपफ़ोल्डर) बनाया, सूचीबद्ध, परीक्षण और पूरी तरह निकाला गया, और उसके बीच से एक एकल फ़ाइल निकाली गई।
• वही आर्काइव एन्क्रिप्शन के साथ बनाया गया, सही और गलत पासवर्ड से परीक्षण किया गया, और निकाला गया।
• पिछले प्रारूप संस्करण (1.0) द्वारा लिखे आर्काइव 1.1 ने खोले।
• इंटरैक्टिव पासवर्ड प्रविष्टि एक छद्म-टर्मिनल से अभ्यासित की गई: मेल खाते पासवर्ड, बेमेल, खाली प्रविष्टि (निर्माण), खोलने पर सही और गलत पासवर्ड।

14.3 हमला परीक्षण

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

14.4 परीक्षण से मिले दोष

परीक्षण अभियान ही कारण है कि जारी प्रोग्राम में कई दोष मौजूद नहीं हैं। दो उदाहरण: एक Rice-पैरामीटर खोज जो 32-बिट ऑडियो के लिए विफल रही और मल्टी-गीगाबाइट कोड लिख देती (यूनिट परीक्षण मैट्रिक्स से मिली और ठीक हुई), और एक zstd चेकसम विफलता जो 3 के बजाय सामान्य एग्ज़िट कोड 2 से सूचित हुई (छेड़छाड़ परीक्षणों में मिली और ठीक हुई)। तीसरा उदाहरण स्वयं बेंचमार्क पद्धति है: RAR से पहली तुलना में उसका नॉन-सॉलिड डिफ़ॉल्ट उपयोग हुआ, जिसने स्रोत कोड पर nikpak की चापलूसी की; इसे सॉलिड मोड में फिर से किया गया, और अध्याय 11 के परिणाम सुधारे हुए हैं।

15 सीमाएँ और रोडमैप

15.1 वर्तमान सीमाएँ

सीमा	विवरण और उपाय
कोई रिकवरी रिकॉर्ड, वॉल्यूम या SFX नहीं	क्षति पकड़ी जाती है, सुधारी नहीं जाती (महत्वपूर्ण आर्काइवों की दूसरी प्रति रखें); आवश्यकता हो तो बड़े आर्काइव किसी सामान्य टूल से विभाजित करें।
कोई इन-प्लेस अपडेट नहीं	प्रारूप एक सॉलिड स्ट्रीम है। हटाना (nikpak d, या unNik में Delete) आर्काइव फिर से लिखता है; मौजूदा आर्काइव में फ़ाइलें जोड़ना समर्थित नहीं है: नया आर्काइव बनाएँ, या -o+ से अधिलेखित करें।
अनुक्रमिक पहुँच	बहुत बड़े आर्काइव से एक फ़ाइल निकालना उससे पहले की सामग्री पढ़ता है (मीडिया प्रविष्टियाँ बिना डिकोड किए छोड़ दी जाती हैं); unNik अंतिम चुनी गई फ़ाइल के बाद पढ़ना रोक देता है।
मीडिया कवरेज	पूर्णांक PCM WAV और AIFF, ProTracker MOD, असंपीड़ित BMP। फ़्लोट WAV, ADPCM, XM/S3M/IT और संपीड़ित छवियाँ सामान्य संपीड़न से संग्रहित होती हैं।
उच्च स्तरों पर मेमोरी	-m4 और -m5 आर्काइव 128 MiB विंडो उपयोग करते हैं; उन्हें डीकंप्रेस करने के लिए उतनी मेमोरी चाहिए।
अधिकतम स्तर -m5	Single-threaded and the slowest level. Creating needs up to about 1.1 GB of memory, extracting up to about 350 MB.
सिम्बॉलिक लिंक और तिथियाँ	लिंक आर्काइव करते समय छोड़े जाते हैं और निकालते समय अस्वीकार होते हैं; तिथियाँ UTC में सूचीबद्ध होती हैं।
सुरक्षा समीक्षा	स्वतंत्र रूप से ऑडिट नहीं हुआ।
Windows और macOS बिल्ड	Linux पर विकसित, परीक्षण और बेंचमार्क किया गया। Windows- और macOS-विशिष्ट कोड पथों की हाथ से समीक्षा की गई है पर उन्हें उन सिस्टमों पर अभी चलाया नहीं गया है: किसी बिल्ड पर भरोसा करने से पहले वहाँ cargo test --release चलाएँ।

15.2 रोडमैप

मद	उद्देश्य
रिकवरी रिकॉर्ड	Reed-Solomon समता ताकि क्षतिग्रस्त आर्काइव सुधारे जा सकें, वह मुख्य सुविधा जिसकी RAR उपयोगकर्ताओं को कमी खलती है।
मल्टी-वॉल्यूम आर्काइव और अपडेट समर्थन	बड़े आर्काइव विभाजित करना, फ़ाइलें जोड़ना और बदलना।
हाइब्रिड योजना के साथ सार्वजनिक-कुंजी साझा	X25519 को ML-KEM के साथ जोड़कर किसी प्राप्तकर्ता की कुंजी के लिए आर्काइव एन्क्रिप्ट करना, सुरक्षित यदि कोई भी एक घटक टिके।
अधिक मीडिया फ़िल्टर	फ़्लोटिंग-पॉइंट ऑडियो, XM/S3M/IT ट्रैकर, PNG का पुनर्संपीड़न, TGA और असंपीड़ित TIFF के लिए 2-D फ़िल्टर।
ZIP और RAR पढ़ना, शेल एकीकरण	unNik में सामान्य प्रारूप खोलना और unNik से फ़ाइलें बाहर खींचना, ताकि nikpak एकमात्र स्थापित टूल हो सके। (Explorer और Finder संदर्भ मेन्यू 1.5.5 में आए, अनुभाग 3.11।)
तेज़ अधिकतम स्तर	-m5 सिंगल-थ्रेडेड है और ऑफ़िस फ़ाइलों पर 7-Zip -mx9 से तीन गुना तक धीमा है: मल्टी-थ्रेडेड LZMA2 और PPMd ब्लॉक, समान फ़ाइलों का डीडुप्लिकेशन, और एग्ज़िक्यूटेबलों के लिए BCJ फ़िल्टर।
बाहरी सुरक्षा समीक्षा	क्रिप्टोग्राफ़िक कोड और एक्सट्रैक्टर का स्वतंत्र ऑडिट।

लाइसेंस: NikPak बंद-स्रोत शेयरवेयर है, © 2026 Nicolas Choukroun, Nikkoid LLC द्वारा वितरित (LICENSE.txt, अनुभाग 3.8); unNik फ़्रीवेयर है (अनुभाग 3.9)। इसमें मौजूद खुले-स्रोत घटक उनके लाइसेंसों के साथ THIRD-PARTY-NOTICES.txt में सूचीबद्ध हैं, जिसे हर प्रति के साथ भेजना आवश्यक है। निजी लाइसेंस कुंजी (keys/nikpak-private.key) को हर प्रकाशित पैकेज और वेब रूट से बाहर रखें। Cargo.lock को रिपॉज़िटरी में रखें ताकि बिल्ड पुनरुत्पादनीय हों, और अपने समर्थित हर प्लेटफ़ॉर्म के निरंतर-एकीकरण जॉब में cargo test --release चलाएँ।

A परिशिष्ट A: प्रारूप स्थिरांक और सीमाएँ

मद	मान
मैजिक	89 4E 49 4B 0D 0A 1A 0A
प्रारूप संस्करण	3 (रीडर 1, 2 और 3 स्वीकार करते हैं)
हेडर आकार	12 बाइट; एन्क्रिप्टेड होने पर 59 बाइट
रिकॉर्ड प्रकार	0 END, 1 FILE, 2 DIR, 3 MEDIA
आर्काइव विधियाँ	0 स्टोर, 1 Zstandard, 2 मल्टी-इंजन ब्लॉक
ब्लॉक इंजन	1 Zstandard; 2 LZMA2 (डिक्शनरी 128 MiB तक लिखी, 1.5 GiB स्वीकृत); 3 PPMd8 (order 8, 192 MiB लिखा; order 2-16, 1 GiB स्वीकृत)
Deflate पुनर्संपीड़न	ZIP, PDF, gzip; फ़ाइल 512 MiB तक; प्रति स्ट्रीम 512 MiB सादा डेटा और 64 MiB सुधार
अधिकतम नाम लंबाई	4096 बाइट
एन्क्रिप्टेड चंक	64 KiB प्लेनटेक्स्ट + 16-बाइट टैग, सामने u32 बिग-एंडियन लंबाई
Argon2id (लिखा गया)	64 MiB, 3 पास, 4 लेन, 16-बाइट सॉल्ट, 32-बाइट कुंजी
Argon2id (स्वीकृत)	मेमोरी 8 x लेन .. 1 GiB, पास 1 .. 64, लेन 1 .. 64
स्ट्रीम नॉन्स	19-बाइट यादृच्छिक उपसर्ग + 32-बिट काउंटर + 1-बाइट अंतिम फ़्लैग = 24 बाइट
न्यूनतम पासवर्ड लंबाई	8 अक्षर
निर्मित पासवर्ड	24 अक्षर, 56-चिह्न वर्णमाला, लगभग 139 बिट
मीडिया न्यूनतम फ़ाइल आकार	8 KiB (क्षेत्र कम से कम 4 KiB)
NAC ब्लॉक	4096 सैंपल फ़्रेम; Shuffle ब्लॉक 32768 फ़्रेम
परीक्षण	तीन 768 KiB विंडो तक (5 %, 45 %, 85 %); 3 MiB तक होने पर पूरा क्षेत्र; 2 % मार्जिन
BMP क्षेत्र सीमा	256 MiB
Zstandard विंडो	डिफ़ॉल्ट; -m4 और -m5 पर लंबी-दूरी मिलान के साथ 2^27
थ्रेड	1 .. 256 (-mt)

B परिशिष्ट B: शब्दावली

शब्द	अर्थ
AEAD	एसोसिएटेड डेटा के साथ प्रमाणित एन्क्रिप्शन: एन्क्रिप्ट करता है और किसी भी संशोधन का पता लगाता है, जिसमें स्पष्ट भेजे गए डेटा (जैसे हेडर) भी शामिल है।
Argon2id	RFC 9106 में मानकीकृत एक मेमोरी-हार्ड पासवर्ड-हैशिंग फ़ंक्शन; जानबूझकर उच्च मेमोरी लागत पर पासवर्ड को कुंजी में बदलता है।
CRC32	एक 32-बिट चेकसम जो आकस्मिक क्षति पकड़ता है। सुरक्षा सुविधा नहीं।
FSE	फ़िनाइट-स्टेट एन्ट्रॉपी: Zstandard द्वारा उपयोग किया जाने वाला तालिका-चालित एन्ट्रॉपी कोडर।
Grover का एल्गोरिदम	द्विघात गति-वृद्धि वाला एक क्वांटम खोज एल्गोरिदम; सिमेट्रिक कुंजियों की प्रभावी लंबाई आधी करता है।
LPC	रैखिक पूर्वानुमानित कोडिंग: पूर्ववर्ती सैंपलों के भारित योग से एक सैंपल का पूर्वानुमान।
Levinson-Durbin	एक रिकर्सन जो किसी संकेत की स्वसहसंबंध से हर order के इष्टतम प्रेडिक्टर गुणांक गणना करता है।
LZMA2	7-Zip और xz द्वारा उपयोग किया जाने वाला Lempel-Ziv-Markov श्रृंखला एल्गोरिदम: इष्टतम पार्सिंग और बाइनरी रेंज कोडर के साथ LZ77 मिलान।
MED	माध्यिका किनारा डिटेक्टर: LOCO-I / JPEG-LS छवि कोडर से एक पिक्सेल प्रेडिक्टर।
मेमोरी-हार्ड	ऐसा फ़ंक्शन जिसकी लागत में मेमोरी हावी है, जो GPU और कस्टम चिपों से मिलने वाली गति-वृद्धि को सीमित करता है।
NAC	nikpak का दोषरहित ऑडियो कोडेक।
PPMd	Prediction by Partial Matching (variant I): हर बाइट का पूर्ववर्ती 8 बाइट तक से पूर्वानुमान करता है; टेक्स्ट पर बहुत मज़बूत।
preflate	एक विधि (और लाइब्रेरी) जो Deflate स्ट्रीम को उसके सादे डेटा और छोटे सुधारों में बदल देती है, जिनसे समान Deflate स्ट्रीम पुनर्निर्मित की जा सकती है।
Rice कोडिंग	लगभग ज्यामितीय वितरण वाली संख्याओं के लिए एक सरल, तेज़ कोड: एक यूनरी भागफल और निचले बिटों की स्थिर संख्या।
Shor का एल्गोरिदम	एक क्वांटम एल्गोरिदम जो पूर्णांकों के गुणनखंड और असतत लघुगणक गणना करता है, RSA और एलिप्टिक-कर्व क्रिप्टोग्राफ़ी को तोड़ता है।
सॉलिड आर्काइव	एक सतत स्ट्रीम के रूप में संपीड़ित आर्काइव, ताकि फ़ाइलों के बीच अतिरेक का लाभ उठाया जा सके।
STREAM	एक निर्माण जो लंबे संदेश को प्रमाणित चंकों के रूप में एन्क्रिप्ट करता है, नॉन्स में काउंटर और अंतिम-चंक फ़्लैग के साथ।
ज़िग-ज़ैग मैपिंग	चिह्नित पूर्णांकों को अचिह्नित में मैप करना (0, -1, 1, -2 ... से 0, 1, 2, 3 ...), ताकि छोटे परिमाण छोटी संख्याएँ बनें।
Zstandard	एक आधुनिक खुला संपीड़न प्रारूप जो LZ77 मिलान को Huffman और FSE एन्ट्रॉपी कोडिंग के साथ जोड़ता है।

संस्करण 1.6.2 · अक्टूबर 2026 पृष्ठ 19