2010-12-09 5 views
8

मुझे लगभग 1000 वर्णों की एक स्ट्रिंग को एन्कोड करने की आवश्यकता है जो किसी भी बाइट मान (00-एफएफ) हो सकते हैं। मैं हेक्स का उपयोग नहीं करना चाहता क्योंकि यह पर्याप्त घना नहीं है। बेस 64 के साथ समस्या यह समझ में है कि इसमें +/और = शामिल हैं जो वर्ण हैं जिन्हें मैं अपने आवेदन में बर्दाश्त नहीं कर सकता।बेस 64 एन्कोडिंग जो "+/=" (प्लस या बराबर) वर्णों का उपयोग नहीं करती है?

कोई सुझाव?

+3

असल में, यह बेस 64 के साथ कोई समस्या नहीं है, यह आपके आवेदन के साथ एक समस्या है। – JeremyP

+1

@ जेरेमीपी ने कहा। यदि आपका आवेदन '+' '/' और '=' को बर्दाश्त नहीं कर सकता है तो आपको बहुत चिंतित होना चाहिए। – lenswipe

उत्तर

3

सीरान कहते हैं, बेस 64 को लागू करने में बहुत मुश्किल नहीं है - लेकिन आप मौजूदा पुस्तकालयों की तलाश करना चाहते हैं जो आपको उपयोग करने के लिए वर्णों का एक कस्टम सेट निर्दिष्ट करने की अनुमति देते हैं। मुझे पूरा यकीन है कि वहाँ बहुत सारे हैं, लेकिन आपने यह निर्दिष्ट नहीं किया है कि आपको किस प्लेटफॉर्म की आवश्यकता है।

असल में, आपको केवल 65 ASCII वर्णों की आवश्यकता है जो स्वीकार्य हैं - अधिमानतः लाइन ब्रेक के अतिरिक्त।

+4

यह स्वीकार्य उत्तर कैसा है, यह कोई समाधान नहीं देता है। – xApple

6

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

1

निश्चित रूप से। अपना खुद का बेस 64 एन्कोडर/डिकोडर क्यों न लिखें, लेकिन उन वर्णों को अपने एल्गोरिदम में बदलें। निश्चित रूप से, यह एक सामान्य डिकोडर के साथ डीकोड नहीं किया जा सकता है, लेकिन यदि यह कोई मुद्दा नहीं है, तो इसके बारे में चिंता क्यों करें। लेकिन, आपके पास कम से कम 3 अन्य वर्ण हैं जो आपके ऐप में +/और = के प्रतिनिधित्व करने के लिए उपयोग योग्य हैं ...

+0

मानते हैं कि कोई पैडिंग (सामान्य रूप से =) आवश्यक नहीं है, केवल दो गैर-अल्फान्यूमेरिक वर्णों की आवश्यकता है। –

+0

हाँ, लेकिन मुझे यकीन नहीं है कि यह एक धारणा है जिसे आप बनाना चाहते हैं ... जब तक कि वह सुनिश्चित न हो कि उसकी डेटा लंबाई * हमेशा * वही होगी, और फिर वह भविष्य के अपडेट के लिए इसे ठीक नहीं करेगा एक नया क्षेत्र या कुछ जोड़ता है, और अचानक उसके सभी बी 64 कोड ब्रेक होते हैं, और वह नहीं जानता कि क्यों ... – LarryF

10

अपनी प्रतिस्थापन चुनें। कुछ अन्य प्रकारों पर विचार करें: base64 Variant table from Wikipedia

बेस 64 एनकोडर/डिकोडर तुच्छ, प्रतिस्थापन subsitution एक मौजूदा बेस 64 एन्कोड/डिकोड कार्य (रैपर के अंदर) का एक सरल पूर्व/पोस्ट प्रोसेसिंग चरण में किया जा सकता है कर रहे हैं - फिर से आविष्कार करने के लिए कोई जरूरत नहीं पहिया (पूरी तरह से)। या, बेहतर अभी तक, श्री स्कीट बताते हैं, पर्याप्त लचीलापन वाला मौजूदा लाइब्रेरी ढूंढें।

आप कोई विकल्प नहीं उपयुक्त "अजीब" वर्ण से चुनने के लिए है, तो (शायद सभी अन्य पात्रों से चुनने के लिए केवल 62 अक्षरांकीय अक्षर छोड़ने अमान्य हैं), तो आप हमेशा एक एस्केप वर्ण एक बहुत ही मामूली के लिए उपयोग कर सकते हैं (~ 3/64?) आकार में वृद्धि। उदाहरण के लिए, 0 (ए) को "एए" के रूप में एन्कोड किया जाएगा, 62 (+) को "एबी" के रूप में एन्कोड किया जाएगा और 63 (/) को "एसी" के रूप में एन्कोड किया जाएगा। यदि आप ग्राउंड-अप से अपना स्वयं का एन्कोडर/डिकोडर नहीं लिखना चाहते हैं तो यह भी पूर्व/पोस्ट चरण के रूप में किया जा सकता है। इस दृष्टिकोण के साथ नुकसान यह है कि आउटपुट वर्णों के इनपुट बाइट्स का अनुपात तय नहीं किया गया है।

1

आप इसके बजाय Base32 का उपयोग कर सकते हैं। बेस 64 से कम घना, लेकिन अवांछित पात्रों को पूरी तरह से हटा देता है।

+0

बेस 32 अभी भी उपयोग करता है =, जिसे वह उपयोग नहीं कर सकता ... लेकिन, वह इसे किसी अन्य चार के लिए प्रतिस्थापित कर सकता है, केवल 3 के बजाय, चिंता करने की ज़रूरत है ... – LarryF

+1

@LarryF: यदि लंबाई हो सकती है तो पैडिंग को छोड़ा जा सकता है किसी अन्य तरीके से पता चला, है ना? – sharptooth

7

Base58Check एक विकल्प है। यह क्रिप्टोकुरेंसी पते में एक वास्तविक तथ्य का कुछ बनना शुरू कर रहा है।Base64 से अधिक

बुनियादी सुधार:

  • केवल अक्षरांकीय अक्षर [0-9a-zA-Z]
  • कोई हमशक्ल पात्रों: 0OIl/0OIl
  • कोई विराम चिह्न शब्द रैप या दस्तावेजों में लाइन ब्रेक और ईमेल को गति प्रदान करने
  • विराम चिह्न के कारण एकल मूल्य के साथ संपूर्ण मान भी चुन सकते हैं।

Bitcoin Address Utility एक कार्यान्वयन उदाहरण है; बिटकॉइन के लिए तैयार

नोट: आपकी जरूरतों के लिए एक उपन्यास वास्तविक तथ्य पर्याप्त नहीं हो सकता है। यह स्पष्ट नहीं है कि बेस 58 चेक एन्कोडिंग विधि current protocols पर औपचारिक रूप से लागू होगी।

+0

मैं इस तरह के एक एन्कोडिंग को आधा दशक तक चाहता था, मेरी इच्छा है कि मैं इसे जल्द से जल्द जानता हूं। –

+1

और यहां सी # https://gist.github.com/dotnetchris/8e99ef70a6fcb3bd445ef1f3505f7087 में बेस 58 के कार्यान्वयन के लिए तैयार है –

संबंधित मुद्दे