स्ट्रिंग के बेस 64 में "\ n" क्यों होता है?

Question

$ echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64
YXBmanhraWMtb215dW9id2QzMzk4MDVhazo2MGEwNmNkMmRkZmFkNjEwYjk0OTBkMzU5ZDYwNTQw
Nw==

आउटपुट से पहले का रिटर्न है Nw==। लिनक्स में बेस 64 उत्पन्न करने का सही तरीका क्या है?

Comments

क्या आप निश्चित हैं कि आउटपुट में एक नई रेखा होती है, और यह केवल आपकी विंडो रैपिंग नहीं है? उस आदेश ने मेरे लिए मैक पर ठीक काम किया। आप कौन सा ओएस उपयोग कर रहे हैं?

— इयान

RFC 2045, जिसने बेस 64 को परिभाषित किया, 76 वर्णों (अधिकतम) के बाद एक नई रूपरेखा को बताता है। आपको क्या लगता है अपने उदाहरण है नहीं सही तरीका?

— MSalters

@MSalters RFC 4648 विशेष रूप से उस मुद्दे को संबोधित करता है। कार्यान्वयन आवश्यक रूप से आधार-एन्कोडेड डेटा में लाइन फीड नहीं जोड़ते हैं जब तक कि इस दस्तावेज़ का उल्लेख करने वाले विनिर्देश स्पष्ट रूप से आधार एनकोडर को वर्णों की एक विशिष्ट संख्या के बाद लाइन फीड जोड़ने के लिए निर्देशित नहीं करते हैं। => यह कार्यान्वयन RFC 4648 के अनुसार गलत है, जब तक कि यह 'प्लेन' बेस 64-एनकोडेड आउटपुट का दावा करता है। अधिक दिलचस्प बात यह है कि, GNU बेस 64 (प्रश्न में?) मैनपाज विशेष रूप से RFC 3548 को संदर्भित करता है, जो डिफ़ॉल्ट रूप से कोई रैपिंग भी निर्दिष्ट करता है, और जो RFC 4648 ऑबसेट्स।

— बॉब

@ याकूब: एपीआई स्थिरता के लिए आरएफसी का थोड़ा कम सम्मान है; एक बेस 64 टूल स्क्रिप्ट्स को तोड़े बिना इसका आउटपुट फॉर्मेट नहीं बदल सकता है।

— एमएसलटर्स

@MSalters मैं निश्चित नहीं हो सकता कि एक पुराना संस्करण मौजूद नहीं है, लेकिन GNU बेस 64 2004 में लिखा गया था और AFAICT ने हमेशा RFC 3548 का पालन करने का दावा किया। RFC 3548 में समान "MUST NOT add line feeds" क्लॉज है। यहां तक ​​कि मूल कार्यान्वयन "गलत" था। बहुत कम से कम, इसका कार्यान्वयन इसके प्रलेखन से मेल नहीं खाता है। वैसे भी, आपने ओपी का उदाहरण सही है और एक आरएफसी का संदर्भ दिया है; मेरी प्रतिक्रिया सही RFC है जो वास्तव में अलगाव में बेस 64 को परिभाषित करता है। यदि आपका जवाब "ऐतिहासिक कारणों से" है, तो ऐसा ही हो, लेकिन यहाँ ओपी गलत नहीं है।

— बॉब

Answer 1

प्रयत्न, कोशिश:

echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64 -w 0

से man base64:

-w, वर्ण (डिफ़ॉल्ट ) के --wrap=COLS
बाद एन्कोडेड लाइनें लपेटें । लाइन रैपिंग को अक्षम करने के लिए उपयोग करें ।COLS760

Comments

अरे यार, मैं हमेशा के माध्यम से बस यह पाइप tr। यह जानने के लिए अच्छा है कि "उचित तरीका" है।

— स्कोर_उंडर

डिफ़ॉल्ट मान शून्य क्यों नहीं है, इसके बारे में स्पष्टीकरण मेरे लिए एक अजीब बात है।

— ढेरिक

@Dherik मुझे लगता है कि यह टेक्स्ट प्रोसेसिंग टूल के प्रति शिष्टाचार है। base64पाठ के रूप में मनमाना द्विआधारी डेटा एन्कोड करता है। पाठ की अपेक्षा करने वाले उपकरण आमतौर पर एक समय में एक पंक्ति पढ़ते हैं और बहुत लंबी लाइनों के साथ अच्छी तरह से व्यवहार नहीं कर सकते हैं । यदि -w 0डिफ़ॉल्ट था, तो आप डिफ़ॉल्ट रूप से पाठ की केवल एक पंक्ति प्राप्त करेंगे; यदि इनपुट बड़ा था, तो एक लंबी लाइन। डिफ़ॉल्ट रूप से लपेटना बेहतर है। मुझे लगता है 76कि चुना गया क्योंकि यह उससे कम है 80जो टर्मिनलों के लिए एक प्रकार का वास्तविक मानक है ।

— कामिल मैकियोरोस्की

@KamilMaciorowski जानकारी के लिए धन्यवाद। हर बार जब मैंने base64कमांड का उपयोग किया था, तो -w 0(और जब मैं भूल गया, तो अजीब चीजें हो सकती हैं ...), इसलिए यह डिफ़ॉल्ट व्यवहार मेरे लिए बहुत अजीब था।

— ढेरिक

Answer 2

यह उन प्रणालियों पर कामिल के उत्तर से हीन है जो -wविकल्प का समर्थन करते हैं base64, लेकिन ऐसे मामलों के लिए जब यह उपलब्ध नहीं है (जैसे अल्पाइन लिनक्स, एक आर्क लिनक्स initramfsहुक, आदि), तो आप मैन्युअल रूप से बेस 64 के आउटपुट की प्रक्रिया कर सकते हैं:

base64 some_file.txt | tr -d \\n

यह जानवर-बल दृष्टिकोण है; सह-संचालन करने के लिए कार्यक्रम को प्राप्त करने के बजाय, मैं trहर नए कदम को स्टडआउट पर अंधाधुंध रूप से पट्टी करने के लिए उपयोग कर रहा हूं ।