openssl base64 -dnkf -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 $