Bir dizgenin base64'ü neden “\ n” içeriyor?


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

Çıktının önce bir geri dönüşü var Nw==. Linux'ta base64 üretmenin doğru yolu nedir?

terminal ekran görüntüsü


5
Çıktının yeni bir satır içerdiğinden emin misiniz ve sadece pencere sarma bölümünüz değil mi? Bu komut benim için mac'ta iyi çalıştı. Hangi işletim sistemini kullanıyorsunuz?
Ian,

47
Base64'ü tanımlayan RFC 2045, 76 karakterden sonra (maksimum) yeni bir satır GEREKTİRİR. Örneğinizin doğru yol olmadığını düşündüren nedir ?
MSalters

24
@ MSalters RFC 4648 özellikle bu sorunu giderir. Uygulamalar, bu belgeye atıfta bulunan şartname, belirli sayıda karakterden sonra satır yayınları eklemek için açıkça baz kodlayıcıları yönlendirmediği sürece, temel kodlanmış verilere satır beslemeleri EKMEMELİDİR. => bu uygulama, 'düz' base64 kodlu çıktı ürettiğini iddia ettiği sürece RFC 4648'e göre yanlış. Daha ilginç olarak, GNU base64 (söz konusu olan?) Manpages, özellikle varsayılan olarak sargılamadığını ve hangi RFC 4648'in eski olduğunu belirten RFC 3548'i belirtir.
Bob,

4
@Bob: RFC'ler API kararlılığına biraz daha az saygı gösterir; Bir base64 aracı, komut dosyalarını bozmadan çıktı biçimini değiştiremez.
MSalters

2
@ MSalters Eski bir sürümün bulunmadığından emin olamıyorum, ancak GNU base64 2004'te yazıldı ve AFAICT her zaman RFC 3548'i takip ettiğini iddia etti. Yani orijinal uygulama bile "yanıldı". En azından, uygulaması belgeleriyle uyuşmuyor. Neyse, neden OP'nin örneğinin doğru olduğunu ve bir RFC'ye başvurduğunu sordunuz; Benim cevabım, aslında taban64'ü yalıtımda tanımlayan doğru RFC'dir. Cevabınız "tarihsel nedenlerden dolayı" ise, öyle olsun, ancak OP burada yanlış değil.
Bob,

Yanıtlar:


151

Deneyin:

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

Kimden man base64:

-w, Karakterden --wrap=COLS
sonra kodlanmış satırları kaydır COLS(varsayılan 76). 0Satır kaydırmayı devre dışı bırakmak için kullanın .


17
Oh dostum, hep bunu hep aktardım tr. "Uygun bir yol" olduğunu bilmek güzel.
Score_Under

Varsayılan değerin neden sıfır olmadığı hakkında açıklama benim için bir misteridir.
Dherik

1
@Dherik sanırım metin işleme araçlarına karşı nezaket. base64isteğe bağlı ikili verileri metin olarak kodlar. Metin bekleyen araçlar genellikle aynı anda bir satır okunur ve çok uzun satırlarla iyi başa çıkamazlar . Eğer -w 0varsayılan olsaydı, varsayılan olarak sadece bir satırlık metin elde edersiniz; giriş büyükse, son derece uzun bir çizgi. Varsayılan olarak kaydırmak daha iyidir. Bence 76o biraz daha az olduğu için seçildi 80olan terminaller için fiili standart bir çeşit .
Kamil Maciorowski

@KamilMaciorowski bilgi için teşekkür ederiz. Her ne zaman base64komutunu kullanmam gerekiyordu -w 0(ve unuttuğumda, garip şeyler olabilirdi ...), bu varsayılan davranış benim için çok garipti.
Dherik

54

Bu, Kamil'in bu -wseçeneği destekleyen sistemler konusundaki cevabından daha düşüktür base64, ancak bu mümkün olmadığında (örneğin, Alpine Linux, bir Arch Linux initramfskancası, vb.), Base64 çıkışını manuel olarak işleyebilirsiniz:

base64 some_file.txt | tr -d \\n

Bu kaba kuvvet yaklaşımıdır; Programın işbirliği yapması yerine, trstdout'taki tüm yeni satırları ayırt etmeden soymak için kullanıyorum .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.