openssl base64 -d
nkf -mB -l
-l
がないとJISに変換されてしまう
base64 -d
(Linux系)b64decode
(BSD系)perl -MMIME::Base64 -e 'while(<>){chomp;print(decode_base64($_));}'
普通のBASE64で使われるのは以下の65種の文字(最後の=はパディング用)ですが、
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=記号部分の "+/=" が用途に合わないために、ここだけ交換した方言があります。
RFC3548 にも 記載があります。"/"を避けるエンコード方式です。
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_=
IMAPでは非ASCIIなフォルダ名も使えますが、サーバー上では base64風のエンコードで 格納されます。これも普通のbase64とは違っていて、
&
で始める
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,
-
で締める
&ZbCJjzDVMKkw6zDA-
というMaildirディレクトリに
なります。デコードには専用のデコーダが必要です。
(利用者が深いIMAPフォルダを掘ると MAX_PATH に引っかかってしまう場合も…)
なぜか uconv が
IMAP-mailbox-name
というエンコード名でこれに対応してたりします。
(base64は食えない)
crypt(3)や、Apache の .htpasswd では、以下のエンコードが使われています。
static unsigned char itoa64[] = /* 0 ... 63 => ASCII - 64 */ "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";普通の base64 とは文字群の順も違います。要するにASCIIコード順。
static const char enc_table[64] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_@";
これもポイントは filesystem safe ってところですが 作られたのが RFC3548より前ですしね。
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`
要するに 0x20 だけずらしたもの。
0b000000 にはスペースの代わりに、右にはみ出た `
を使うのが普通です。
行頭の文字が文字列長を表すなど、コンピュータにはやさしいフォーマットです。
$Id: base64.html,v 1.9 2021-05-14 00:08:39+09 kabe Exp $