เหตุใด base64 ของสตริงจึงมี“ \ n”

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

Nw==การส่งออกมีการกลับมาก่อน วิธีที่ถูกต้องในการสร้าง base64 ใน Linux คืออะไร?

base64

— Tiina
แหล่งที่มา

คุณแน่ใจหรือว่าผลลัพธ์มีการขึ้นบรรทัดใหม่และไม่ใช่เพียงการห่อหน้าต่างของคุณ? คำสั่งนั้นใช้งานได้ดีสำหรับฉันบน mac คุณใช้ระบบปฏิบัติการอะไร?

— Ian

RFC 2045 ซึ่งกำหนด Base64 ต้องขึ้นบรรทัดใหม่หลังจาก 76 อักขระ (สูงสุด) อะไรทำให้คุณคิดว่าตัวอย่างของคุณไม่ ถูกต้อง

— MSalters

@MSalters RFC 4648แก้ไขปัญหานั้นโดยเฉพาะ การใช้งานต้องไม่เพิ่มตัวดึงข้อมูลบรรทัดลงในข้อมูลที่เข้ารหัสพื้นฐานเว้นแต่ว่าข้อกำหนดที่อ้างถึงเอกสารนี้จะนำผู้เข้ารหัสฐานอย่างชัดเจนไปเพิ่มตัวดึงข้อมูลบรรทัดหลังจากระบุจำนวนอักขระที่เฉพาะเจาะจง => การติดตั้งนี้ไม่ถูกต้องตาม RFC 4648 ตราบใดที่มันอ้างว่าผลิตเอาต์พุตพื้นฐานที่เข้ารหัสแบบ 'ธรรมดา' 64 น่าสนใจยิ่งกว่า GNU base64 (มีคำถาม?) manpages อ้างถึง RFC 3548 โดยเฉพาะซึ่งยังไม่มีการตัดคำโดยค่าเริ่มต้นและ RFC 4648 ที่ล้าสมัย

— Bob

@Bob: RFC มีความเคารพน้อยลงเล็กน้อยสำหรับเสถียรภาพ API เครื่องมือ base64 ไม่สามารถเปลี่ยนรูปแบบผลลัพธ์ได้โดยไม่ทำให้สคริปต์แตก

— MSalters

@MSalters ฉันไม่แน่ใจว่ารุ่นเก่าไม่มีอยู่จริง แต่ GNU base64 ถูกเขียนขึ้นในปี 2004 และ AFAICT มักอ้างว่าทำตาม RFC 3548 เสมอ RFC 3548 มีข้อ "ไม่ต้องเพิ่มตัวดึงข้อมูลบรรทัด" เหมือนกัน ดังนั้นแม้แต่การปฏิบัติดั้งเดิมก็เป็น "ผิด" อย่างน้อยที่สุดการใช้งานนั้นไม่ตรงกับเอกสารประกอบ อย่างไรก็ตามคุณถามว่าทำไมตัวอย่างของ OP จึงถูกต้องและอ้างอิงถึง RFC การตอบสนองของฉันคือ RFC ที่ถูกต้องที่จริงกำหนด base64 ในการแยก หากคำตอบของคุณคือ "ด้วยเหตุผลทางประวัติศาสตร์" ก็เป็นได้ แต่ OP ไม่ผิดที่นี่

— Bob

คำตอบ:

151

ลอง:

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

จากman base64:

-w, --wrap=COLS
ตัดบรรทัดที่เข้ารหัสหลังCOLSอักขระ (ค่าเริ่มต้น76) ใช้0เพื่อปิดการตัดบรรทัด

— Kamil Maciorowski
แหล่งที่มา

trโอ้ฉันเสมอเพียงประปาผ่านทางนี้ เป็นการดีที่จะทราบว่ามี "วิธีการที่เหมาะสม"

— Score_Under

คำอธิบายเกี่ยวกับสาเหตุที่ค่าเริ่มต้นไม่ใช่ศูนย์เป็นสิ่งที่ไม่ดีสำหรับฉัน

— Dherik

@herik ฉันคิดว่ามันเป็นมารยาทต่อเครื่องมือประมวลผลข้อความ base64เข้ารหัสข้อมูลไบนารีโดยพลการเป็นข้อความ เครื่องมือที่คาดหวังมักจะอ่านข้อความบรรทัดเดียวในเวลาและไม่อาจจัดการกับสายยาวได้เป็นอย่างดี หาก-w 0เป็นค่าเริ่มต้นคุณจะได้รับข้อความเริ่มต้นเพียงบรรทัดเดียว เส้นยาวมหาศาลหากอินพุตมีขนาดใหญ่ มันจะดีกว่าที่จะห่อตามค่าเริ่มต้น ผมคิดว่า76ได้รับเลือกเพราะมันน้อยกว่า80ซึ่งเป็นที่จัดเรียงของมาตรฐานพฤตินัยสำหรับขั้ว

— Kamil Maciorowski

@ KamilMaciorowski ขอบคุณสำหรับข้อมูล ทุกครั้งที่ฉันใช้base64คำสั่งที่ฉันต้องการผ่าน-w 0(และเมื่อฉันลืมสิ่งแปลก ๆ สามารถเกิดขึ้นได้ ... ) ดังนั้นพฤติกรรมเริ่มต้นนี้จึงแปลกสำหรับฉัน

— Dherik

นี่จะด้อยกว่าคำตอบของ Kamil ในระบบที่รองรับ-wตัวเลือกbase64แต่สำหรับกรณีที่ไม่สามารถใช้งานได้ (เช่น Alpine Linux, initramfsเบ็ดArch Linux ฯลฯ ) คุณสามารถประมวลผลผลลัพธ์ของ base64 ได้ด้วยตนเอง:

base64 some_file.txt | tr -d \\n

นี่คือวิธีการที่กำลังดุร้าย; แทนที่จะใช้โปรแกรมเพื่อทำงานร่วมกันฉันใช้trในการตัดบรรทัดใหม่ทุกบรรทัดใน stdout

— Score_Under
แหล่งที่มา