[5] Base64 は、オクテット列を64種類の英数字などに転写する符号化方式の一種です。
[196] 元々インターネットメールでバイナリーデータを転送するための仕組みとして考案されました。 文字コードの異なる様々なシステム間で転送される電子メールでは、 任意のバイナリーデータを転送することができなかったため、 限られたASCII文字で符号化する手段が必要でした。 その後徐々に適用範囲が拡大され多種多様な目的で使われるようになりました。
[58] いくつかのバリエーションがあり、どれを使うべきなのか注意が必要です。
[27] オクテット値3つ (8ビット×3 = 24ビット) を4文字 (6ビット×4) で表現します。ですからデータ量は3分の4倍、33%増加になります。
64文字 (と、特殊用途に使われる =) は、
ISO/IEC 646の版で全て共通に存在し、しかも EBCDIC
の全ての版で使える文字から選ばれたそうです。
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y[28]
Base64 は6ビット単位になりますが、オクテット列の長さと必ずしも
一致する (6と8の公倍数の長さになる) とは限らないので、
= で埋めて調節します。この結果、 Base64 data は必ず
4の整数倍の長さになります。
[136] Base64 による符号化は、 任意のバイト列を Base64 の ASCII文字列へと変換する処理です。
[89] forgiving-base64 encode は、バイト列データを次のようにします >>86。
[117] RFC 4648 第4章 Base64 は、 バイト列データを次のようにします。
[123] 次の文脈で用いられます。
[137] Base64 による復号は、 Base64 の ASCII文字列をその表すバイト列へと変換する処理です。
[91] forgiving-base64 decode は、文字列データを次のようにします >>86。
[125] 次の文脈で用いられます。
[225] 仕様書上 forgiving-base64 decode は入力が文字列として定義されています。
data: URL処理器では入力がバイト列となるため、
同型復号を通しています。
[138] 「Base64」と呼ばれているものは、 注意して観察すると色々なバリエーションがあることがわかります。 Base64 は有用で様々な用途に活用されてきたのですが、 その過程で仕様書の規定の部分をコピペしたり、 用途依存の細かい改変を加えたりされたため、 単一の定義と言えるものが存在しなくなってしまいました。
[23] どの仕様書の定義を参照するかという政治的な問題の他に、 技術的に様々な違いがありますが、 主として次のような観点で比較できます。
[145] Base64 は最初に PEM で導入されました。 PEM は特別な名前を与えず、単に「printable encoding」 (印字可能符号化) と呼んでいました。 >>142, >>143, >>144
[146] 字母や詰めについては既に後の時代と同じ規定となっていました。 符号化後の最終行以外の各行は、64文字としなければならないとされていました。 誤り処理の明確な規定はありませんでした。
[147] 字母は、当時使われていた ASCII や EBCDIC を文字コードとするシステムで問題なく扱えるものが選ばれていました。 行長制限は、SMTP の制約に由来するものでした。
[148] PEM の Base64 は、あくまで PEM のプロトコルの一部を構成するもので、
汎用的な利用を想定したものではありませんでした。 Base64 の字母に加え、 PEM
での利用上特別な意味を持った区切りの文字 *
も字母の1つとして挙げられていました。
[166] 符号化の方法は規定されていましたが、復号の方法は明確には定められていませんでした。
[25] MIME は、 PEM から派生して独自の Base64 を規定しました >>149, >>150, >>43。 Base64 という名称はここで与えられました。
[151] 基本的には PEM と同内容ですが、いくつかの違いがありました。
[152] MIME では特別な意味を持たない * は字母に含まれませんでした。
[154] 字母以外は無視するべきことと定められ、 字母、改行、空白以外は誤りと考えられるため警告を出したり、 場合によっては拒絶するのもよいとされました。
[155] RFC 1521 は ==== のようなあり得ない詰めを無視することを定めていましたが、
改訂版の RFC 2045 ではなぜか削除されました。
[156] このように PEM とは違って誤り処理が定められたことは注目に値しますが、 起こり得るすべての誤りケースをカバーできてはいませんでした。
Base64 転送符号化x-gzip64 転送符号化Content-MD5: ヘッダーFace: ヘッダーencoded-word B 符号化instance-digest
(digest-algorithm が
SHA または MD5 の時)mode=base64 (→ RFC 2045)HMAC-SHA1 (→ RFC 2045)RSA-SHA1 (→ RFC 2045)[170] Content-MD5: を定める RFC 1864 は「base64」としか言っておらず、
どこで規定される何を指すのかは曖昧ですが、 MIME の追加機能ですから、
MIME の定義と解釈するのが自然でしょう。
ヘッダー値として使うため改行を自由には挿入できないはずですが、
符号化される値は十分短いため、実際には問題とはなりません。
[281] RFC 2065 は RFC 1521 から Base64 部分をコピペして組み込んでいました。 >>280
[827] 基本認証の credentials では MIME の RFC 1521 や RFC 2045 の Base64 から行長制限を撤廃したものと規定されていました >>826, >>183, >>828。 厳密に読めば制限が撤廃されたのは良いとして、改行が認められるのかは不明でした。 この点は後の改訂で明確化されました (>>185)。
[171] data: を定める RFC 2397 は「base64」としか言っておらず、
どこで規定される何を指すのかは曖昧ですが、参考文献として示された
MIME の RFC 2045 だけが文脈から推測できる候補でした。
しかし行長制限の扱いと URL としての構文の矛盾など、
著者の意図を断言するのは難しい状態でした。
(出版から20年後にようやく Fetch Standard により明確化されることになります。)
[224] OAuth 1.0 の HMAC-SHA1 や RSA-SHA1
は RFC 2045 の Base64 を採用していました。
符号化される値は十分短いため、
行長制限に達することはありません。
The encoding of the binary key or lock is performed in accordance with the Base64 Transfer Encoding defined in [RFC-2045].
[282] rfc2060, https://datatracker.ietf.org/doc/html/rfc2060#page-66
ABNF 構文定義のみ
[74] PGPメッセージ交換形式もまた、独自に Base64 を規定しており、 Radix-64 と呼んでいます >>159, >>160, >>161。
[163] RFC 2440 や RFC 4880 は、 MIME の RFC 2045 と同内容の Base64 を規定しています。歴史的経緯によるものか、 MIME の Base64 への言及は一切ありません。 しかし明らかに同じテキストを流用しています。 ですが全く同じではなく、解釈次第ではこちらの定義の方が厳密ともいえます。
[274] RFC 2801 - Internet Open Trading Protocol - IOTP Version 1.0, , https://tools.ietf.org/html/rfc2801#page-52
[276] RFC 3252 - Binary Lexical Octet Ad-hoc Transport, , https://tools.ietf.org/html/rfc3252#section-2.1
This RFC REQUIRES the contents of the payload to be encoded in the base-64 encoding of RFC 2045 [RFC2045], but removes the requirement that the encoded output MUST be wrapped on 76-character lines.
[283] rfc3885, https://datatracker.ietf.org/doc/html/rfc3885#section-1
字母の ABNF 定義のみ。
[15] IETF はその後 Base64 (と Base32 と Base16) のみを定める RFC を発行しました >>6, >>24。
[30] MIME 式の base64 と、 base64url (>>833) との2種類が定義されています。 両者は字母のみが異なっています。
[164] MIME 式のものは、 MIME や OpenPGP に由来するものですが、 いくつか異なる点もあります。
[165] 詰めは、原則として必須ですが、応用は省略可能と定めることができます。 しかし詰めが省略された場合にどう処理しなければならないかは規定されていません。
[167] RFC 3548 にはありませんでしたが、 RFC 4648 は、 詰めの前の字母の選択時に余ったビットは 0 としなければならないとしています。 そうでない場合、復号時に拒絶しても構わないとされています。
[168] 復号時に字母以外が含まれる場合、 原則として拒絶しなければならず、 応用はそれ以外の処理方法を定めても良い、とされています。 電子メールのように行長制限が必要な場合には改行を挿入することを選べますが、 基本的には改行は含めないことになっているのが MIME との最大の違いです。 同様に復号時に不正な詰めも無視すると定めても良いことになっています。
[169] これらの RFC でも、完全な復号の方法は定められていません。
CRLF / CR 挿入可) >>60.pem (>>197)x5cのJSON配列Sec-WebSocket-Key: 旧 RFC、旧 Fetch Standard[36]
RFC 4287 の Atom 1.0 における atom:content では、
RFC 3548 の MIME 式 Base64 が使われています >>177。
ただし、前後に空白があっても良いこと、
改行は U+000A とすることが定められています >>177。
この改行の定めが何を意味するかは不明瞭です。
RFC 3548 によれば応用が明確に認めない限り改行の挿入は認められませんが、
RFC 4287 が明確に認めているとは言えず、
しかしそうだとすると RFC 4287 の記述は理解不能となります。
[197] RFC 7468 は、 .pem ファイルの Base64
を RFC 4648 の MIME 式 Base64 としています。
ただし、生成時には最終行以外を64文字丁度とすることと定めています
(これは PEM に由来する制約です)。
解釈時には空白を含む字母以外を無視することを認めています。
ABNF 構文上は詰めの省略が認められているようですが、
本文には明確な規定がなく、意図は不明です。
(ABNF 構文は通常、緩め、厳密の3種類が用意されています。)
3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in Base64 (see Section 4 of [RFC4648]). To avoid long lines, <CRLF> or <LF> line breaks MAY be inserted into the Base64-encoded string.
Base64: An encoding mechanism defined in Section 4 of [RFC4648] that converts an octet string input to a textual output string that can be easily displayed to a human. The use of base64 in SCRAM is restricted to the canonical form with no whitespace.
[287] rfc3977, https://datatracker.ietf.org/doc/html/rfc3977#section-3.2.1
[288] rfc3977, https://datatracker.ietf.org/doc/html/rfc3977#page-98
xs:base64Binary[63] XML Schemaデータ型 xs:base64Binary
は、 MIME の RFC 2045 の定義を参照しつつ、
独自の構文を規定しています >>172。
[173] US-ASCII ベースの RFC 2045 と違って、 XML Schema は Unicode ベースとなっています。 (文字レベルで見れば実質的な違いはありません。)
[174] 本来の字母の他に XMLの空白が任意の位置に認められることになっています。
ただし XML Schema の正規化を経た字句形の構文上は途中に U+0020
各1つのみの挿入が認められることになっています。
MIME とは違って行長制限はありません。
[87] Web では、 エラー処理を含め正確なアルゴリズムとして符号化 (>>89) と復号 (>>91) を定義した forgiving base64 >>86 を用いています。
[88] 正常な入力のみに限ったとき、 RFC 4648 第4章の Base64 と等価です。
[112] 詰めは、必ず生成されますが、省略されても復号には成功します。 詰めの直前の字母の余分なビットは、無視されます。
[113] 空白は生成されませんが、無視されます。 字母と空白以外が含まれる場合や、 不正な詰めが含まれる場合は、復号に失敗します。
[114] Infra Standard の forgiving base64 が Base64 の歴史上最も厳密な定義となっており、特に事情がない場合、これを採用するのが望ましいと思われます。
[2] UTF-7 は、修正Base64と称する変種を定義していました >>44, >>47。
[178] MIME の RFC 1521 や RFC 2045 を参照しつつ、
詰めの = は使わないこととしていました。
復号時には、16ビット単位の列として解釈した時に余ったビットは捨てることとされていました。
余ったビットが 0 でないものは ill-formed であるとされていましたが、
それをどう処理するべきかは明記されていませんでした。
[179] UTF-7 では字母でない文字を修正Base64部分の終わりとみなすことになっていました。 従って改行の挿入は認められていませんでしたし、字母以外の混入時の復号の処理も明確でした。 ただし改行を挿入しないため行長制限を超えてしまうデータが認められると明記はしていませんでした。
[7] IMAP の修正UTF-7 は、 UTF-7 の修正Base64を更に改変し、
字母 / の代わりに , を使うとしています
>>182, >>181。
[833] modified Base64 for URL >>829 あるいは base64url と呼ばれる変種は、 URL で利用しやすくした Base64 の一種です。 Web 関係の分野でよく用いられるようになってきました。
[277] Base64 のバリエーションの中では、 MIME 式に次いで2番目に普及していると思われます。
[834] MIME 式の Base64 と base64url との違いは、 次の通りです。
[838] 出典としてはしばしば Wikipedia >>829 が参照されます。 そんなあやふやなものを参照して技術基盤として大丈夫なんだろうか、 と不安になりますが、案外よく参照されています。
[839] 公的な文書としては RFC (>>30) があり、ファイル名や URL
で安全なものとして紹介されています。ただし RFC は原則として詰め =
は省略できないとしており、一般的な実装とは異なっています。
[840] RFC は既存の利用例としてメーリング・リストの記事を参照していますが、 URL が変わってしまったのか、関係ない記事になっています。本来指すべきだったと思われる >>831、>>832 によると、元々は Freenet で使われていたのを採用したようです。
[293]
Google Apps Script
の標準ライブラリーの
base64EncodeWebSafe,
base64DecodeWebSafe
は
base-64 web-safe encoded string
なるものに対応しています。
>>292
これは詰め = ありの base64url のようです。
[229] I-JSON は、 RFC 4648 base64url を使うべきとしています。 (JSON で通常の Base64 では不都合な理由はなく、敢えて base64url を選択した理由は不明です。)
[221]
JSON-Base64 は、 RFC 4648 の URL安全Base64 を参照しつつも、
独自に定義しています。 Base64 の字母を置き換え、
= を削除したものとなっています >>220。
RFC を参照しているものの、 RFC が改変する前の本来の
URL安全Base64 ということになります。
[234] RFC 7515, RFC 7522, RFC 7636 Base64url Encoding >>233, >>54, >>56 は、 RFC 4648 base64url の詰めを禁止し、 空白その他の挿入も明示的に禁止しています。 また RFC 7515 は符号化と復号の、 RFC 7636 は符号化の実装例も掲載しています。 (>>242 も参照)
[236] 結局 IETF のプロトコルでも詰めのない base64url が主流にみえます。 敢えて世間一般と違うものを定義した RFC の意義は何だったのでしょうか。そして利用実態に反したまま改訂せずに放置している IETF の意図は何なのでしょうか。
[242] RFC 7515 は 「Base64url-decode the encoded representation of (入力データ), following the restriction that no line breaks, whitespace, or other additional characters have been used.」 という表現を用いています >>240。 これが満たされないとき検証は失敗することとなり、 緩い復号を用いないことを求めています。 ただし詰めの扱いは明言していません。
[243] RFC 7515 の復号のサンプルコード >>233 は、次のような挙動を示します。 ただ、あくまで実装例に過ぎず、復号方法の規定とは到底言えません。
+ や / は - や _ とそれぞれ同義とみなされる= はあってもなくても同義とみなされる[278] 仕様書がこんな状態なので、実装は混乱していることが予想されます。 base64url データの送信者は、壊れたデータを送信しないよう、 慎重に実装することが望まれます。 base64url データを受信する実装を作る開発者は、 既成のライブラリーを流用するなら、 そのライブラリーの挙動を慎重に調査し、 不正な入力が与えられても適切に動作するよう、 注意が必要です。
[75] 他の Base64 の変種同様、字母を置き換えるだけなので簡単に実装できます。 両対応のライブラリーも珍しくありません。
[842] Perl の標準モジュールである MIME::Base64 >>841
に実装されています。 Perl では今後はこちらが標準的な実装となっていくと思われます。
Wikipedia >>829 が出典とされています。
[844] >>843 は >>841 が実装される前によく用いられていました。 Python の実装に倣った >>843, >>845 としつつ、 Wikipedia >>829 も引用しています。
[849] Python の実装というのは >>848 でしょうが、こちらは >>841、>>843
とは違って = を省略しません。 >>839 に従っている実装です。
[279] MIME 式と一部の字母が違うだけなので、 字母を置き換えてから MIME 式で復号するような実装が蔓延っています。 簡単に実装できるのは結構ですが、 この方式だと MIME 式 Base64 の入力や、 MIME 式 Base64 と base64url の両方の字母が混在している入力まで復号できてしまいます。 そんな実装が混在している (かもしれない) という現状は、 相互運用性やセキュリティーの問題の温床です。
[263] BASE64URL(OCTETS)
のような仕様書上の表記法が使われています >>262, >>296, >>297。
[235] いくつかの RFC は、バイナリーデータを RFC として記述するための便宜上の方法として base64url を使っています。 RFC 4648 を引用しつつ、 RFC の制約上空白を挿入することとしています。 明記はされていませんが、詰めも省略されています。
[266] Base64urlUInt は、 正整数または 0 の値について、 符号無し大エンディアン表現をオクテット列としたとき、 これを base64url 符号化したものです。 このときオクテット列は、 当該整数値を表現するために必要な最低数のオクテットのみ用いなければなりません。 >>265
The SAML Assertion XML data MUST be encoded using base64url, where the encoding adheres to the definition in Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to zero. To avoid the need for subsequent encoding steps (by "application/x-www-form- urlencoded" [W3C.REC-html401-19991224], for example), the base64url- encoded data MUST NOT be line wrapped and pad characters ("=") MUST NOT be included.
Base64 encoding using the URL- and filename-safe character set defined in Section 5 of [RFC4648], with all trailing '=' characters omitted (as permitted by Section 3.2 of [RFC4648]) and without the inclusion of any line breaks, whitespace, or other additional characters. (See Appendix A for notes on implementing base64url encoding without padding.)
[248] 符号化は、バイト列入力を、次のようにするべきです。
[300] HTTP Certificate Store Interface は Base64 の一種を使っています。 >>299
[301] 仕様書では 「Base64」, 「Base64 encoding」, 「base64 encoding」, 「base64-encoded」 といった表現が使われています。 >>299
[302]
末尾の = は省略しなければならないとされています。
>>299
[303]
実装は ASCII英数字、 +、 / 以外が含まれるとき、
拒絶しなければならないとされています。
>>299
[304] このように IETF にしてはしっかりエラー処理が規定されているにも関わらず、 なぜか 「Base64」 とは何かという最も重要な部分が規定されていません。
[305]
>>303 から、 MIME や PEM の Base64 から空白や
=
を禁止したものだと推測はできますが...
[306]
BUCS と共に使う外字のグリフ記述用の Base64 案は
ASCII英数字と . と /
を使っていました。
[9] urn:urn-5 URN 名前空間で使っている Base64
変種は、 / の代わりに -
を使います。 (URN では / が使えないため。)
また、詰め文字は使いません。
(Namespace ID: urn-5 http://www.iana.org/assignments/urn-informal/urn-5)
[16] RFC 3548 曰く、 MIME Base64 ではファイル名や URI
で安全ではないので、 / の代わりに ~
を使う提案があったそうです。しかし ~ もやはりファイル・システムや
URI で安全とは言えません。
[18] M$XML は / の代わりに *
を使っていたそうです。最近の版では両方認識するそうです。
[20] OpenToken >>19 はクッキーで使うためとして、 RFC 4648
の Base64 の詰め文字を = ではなく *
に変えたものを採用しています >>19。
採用アプリ 変換方式 Hibernate +/ → *- IMAP4 +/ → +, IRCu +/ → [] Python +/ → -_ 正規表現フリー注2 +/ → !-
[29]
Norton AntiSpam は encoded-word の最後の
= を省くそうです。 mew-dist 25264
もちろんこの実装は MIME 違反です。
[39]
機械的に電子メイルを生成する類のプログラムで、
末尾に4つも = を付けるとんでもない符号化するものがあるそうです。
(しかも改善するように要求したら使っている MUA が悪いのだろうと言われたとか。。。)
(名無しさん [sage] 2005-12-10 07:32:30 +00:00)
[45]
RFC 4387 では固定長のオクテット列を符号化するため、常に最後が = になってしまうので、
= は省略することになっています >>884。
[55]
Perl の Digest::MD5 や
Digest::SHA1 が出力する Base64
化文字列は、詰めが省略されています >>853 。
[189] IMAP4 の AUTHENTICATE 命令は、 base64
で符号化するとされていますが、その定義は示されていません
>>186, >>187, >>188。
[190] インターネットメールのプロトコルであるから MIME の Base64 ではないかと推測したいところですが、 ABNF 構文が示されており、そこでは改行が認められていません。 本文中も単数の a line となっており、複数行は認められないようです。 しかし符号化されるデータが MIME 式 Base64 で1行に収まる保証はありません。
[191] 構文は、 MIME 式の字母と詰めを認めており、 それ以外の文字は一切認めていません。詰めが含まれる数は、正しくなければなりません。 詰めの前の字母の制約は構文上は現れていません。
[273] 普通 Base64 は他の誰かが復号することを期待して用いられるものですが、 それを期待しない、あるいは自分自身しか復号しないので相互運用性が不要なところでも用いられる場合があります。 それなら任意のデータで構わないのですが、 プロトコルの文脈的な制約からまったく任意のバイト列を認めるわけにもいかず、 一定の制約は設けておきたい、 というようなノリで、 Base64 のようだけどそうとも言い切らない構文が使われることがあります。
[269]
RFC 6750
は
Bearer
の
credentials
として
b64token
と称する構文を規定しています。
これは
MIME の Base64
とは矛盾しないという程度の構文上の制約で、若干の拡張も施されています。
構文の定義としてそうなっているだけで、
Base64
によるデータであることは求めていません。
(「b64」という名前で暗示しているだけで、 Base64
に言及すらしていません。)
[268] RFC 8030 Topic: HTTPヘッダーは、
構文の制約を RFC 4648 base64url
により定めています。字母の定義として参照しているだけで、
それが実際に base64url で符号化されたデータであることは要求していません。
[3] MIME 以外の場面でファイルを貼り付けるのに、 uuencode みたいな書き方をすることがあるみたい。
例1:
begin-base64 644 base64ed.data ... base64 stream ... ====
[26] 例2:
begin-base64 644 code.tgz ... base64 stream ... =
[193] Base64 の実装の選択時には、利用したいのがどのバリエーションで、 実装が対応しているのがどのバリエーションであるのかを慎重に検討する必要があります。
[8] uuencode も64進数であることを利用して、 uuencode
で符号化した後に tr を使うという方法が使われることもあります。
[4] Perl なら、 MIME::Base64 を使うのが気楽かと。
Perl 5.7.3 以降では標準で入っています。
base64 コマンド[68] 一般的な Linux 環境では、 base64 コマンドが用意されています。
ASSUME CS:CODE,DS:CODE CODE SEGMENT ORG 100H START: MOV BX,0 START1: MOV DI,0 LOOP1: PUSH BX PUSH DI MOV AH,06H MOV DL,0FFH INT 21H POP DI POP BX JNZ JUMP1 CMP DI,0 JZ END1 CMP DI,1 JZ END2 CMP DI,2 JZ END3 JUMP1: MOV BUFFER[DI],AL INC DI CMP DI,3 JNZ LOOP1 SHORI2: MOV CH,4 LOOP3: MOV CL,6 MOV SI,0 LOOP2: SAL BUFFER+2,1 RCL BUFFER+1,1 RCL BUFFER+0,1 RCL SI,1 DEC CL JNZ LOOP2 PUSH BX PUSH DI PUSH SI PUSH CX MOV DL,BASE64[SI] MOV AH,06H INT 21H POP CX POP SI POP DI POP BX DEC CH JNZ LOOP3 ADD BX,DI CMP BX,57 JNZ START1 PUSH BX PUSH CX PUSH DI PUSH SI MOV DL,0AH MOV AH,06H INT 21H MOV DL,0DH MOV AH,06H INT 21H POP SI POP DI POP CX POP BX JMP START END2: MOV CH,2 JMP LOOP5 END3: MOV CH,3 LOOP5: MOV CL,6 MOV SI,0 LOOP4: SAL BUFFER+2,1 RCL BUFFER+1,1 RCL BUFFER+0,1 RCL SI,1 DEC CL JNZ LOOP4 PUSH CX PUSH DI PUSH SI MOV DL,BASE64[SI] MOV AH,06H INT 21H POP SI POP DI POP CX DEC CH JNZ LOOP5 CMP DI,2 JZ JUMP2 MOV DL,'=' MOV AH,06H INT 21H JUMP2: MOV DL,'=' MOV AH,06H INT 21H ;処理終了 END1: MOV AH,4CH MOV AL,00H INT 21H ;base64 moji hyoji MOV AH,09H MOV DX,OFFSET BASE64 INT 21H BASE64 DB 'ABCDEFGHIJKLMNOP' DB 'QRSTUVWXYZabcdef' DB 'ghijklmnopqrstuv' DB 'wxyz0123456789+/' BUFFER DB '000','$' CODE ENDS END START
BASE64.ASM
名無しさん [223] tests-web/base64 at master · wakaba/tests-web () https://github.com/wakaba/tests-web/tree/master/base64
[40] RFC 4648 - The Base16, Base32, and Base64 Data Encodings () https://tools.ietf.org/html/rfc4648#section-10
[130] web-platform-tests/base64.json at master · w3c/web-platform-tests () https://github.com/w3c/web-platform-tests/blob/master/fetch/data-urls/resources/base64.json
[131] mime-base64/base64.t at master · gisle/mime-base64 () https://github.com/gisle/mime-base64/blob/master/t/base64.t
[132] mime-base64/base64url.t at master · gisle/mime-base64 () https://github.com/gisle/mime-base64/blob/master/t/base64url.t
[133] base64url/tests.txt at master · ptarjan/base64url () https://github.com/ptarjan/base64url/blob/master/tests.txt
[121] rust-base64/tests at master · alicemaz/rust-base64 () https://github.com/alicemaz/rust-base64/tree/master/tests
[218] tests/base64.c · master · gnutls / GnuTLS · GitLab () https://gitlab.com/gnutls/gnutls/blob/master/tests/base64.c
[219] org.bouncycastle.util.encoders: Base64Test.java () http://www.docjar.org/html/api/org/bouncycastle/util/encoders/Base64Test.java.html
[222] base64_url/base64_url_spec.rb at master · infopark/base64_url () https://github.com/infopark/base64_url/blob/master/base64_url_spec.rb
[34] 秘密情報送信のための使用: HTTP の認証や SASL などでは、合言葉などの繊細な情報を送信するために Base64 を使うことがあります。 Base64 は転送符号化であって暗号化ではありませんが、 第3者 (例えばシステムの管理者) が繊細な情報を含むメッセージを見てしまったとしても読むことができません (流石に脳内で Base64 を復号できる猛者はいないでしょう)。 もちろん、悪意のある人は計算機を使って復号してしまうでしょうから、 それに対する効果はありません。
[35] バッファ溢れ攻撃: 不正な (字母に含まれない)
文字や末尾以外にある詰めの =
への対処がいい加減だと、バッファ溢れ攻撃に使われることがあり得ます。
RFC 3920 14.9 など
[65] Base64 が普及する前は、同じく64進数でもある uuencode がよく使われていました。
[194] PEM や MIME が当時一般的だった uuencode ではなく Base64 を採用したのは、 EBCDIC やISO/IEC 646の版を採用するメールシステムでも問題が起こらないという要件があったためのようです。
[195] しかし当時マイナーだった Base64 を選択したことは、 MIME の普及の足を引っ張ることになりました。 インターネットメールや Usenet のファイル転送にはその後も uuencode が使われ続け、2000年を過ぎても MUA によっては添付ファイルを MIME 形式と uuencode 形式のどちらで送信するか選択するオプションが付いていたくらいです。 受信は両方に対応する必要がありました。 MIME 未対応の MUA でも対応済みの MUA でも適切に処理できるよう、 uuencode を非公式に MIME の CTE として実装した MUA もありました。
[14]
MIME の application/octet-stream
では、オクテット (8ビット) 単位でないビット列も扱うことが出来ます。
そのような場合には全体長が8の倍数になるようにビット 0 を詰め、
詰めた数を引数でメモっておきます。
[12] インターネットでのオクテット列の文字列転写法のデ・ファクト標準です。
[10] XML でバイナリを扱う時には Base64 を使うのが推奨されている (誰に?)
そうです。 (XML は人間可読である
のじゃなかったのか? って気もするが。)
[11] >>10 実際のところ、 ISO/IEC 6479 の制御シーケンスとかが混じったデータを使いたいという要求はある。 (それは XML の思想に反するという反発は強く、 XML 1.1 でも結局駄目になったけど。)
[21] >>11 XML 1.1 では結局文字参照なら OK
(U+0000 以外。) になりましたね。
[13] >>11 でも、せめて FF
くらい使いたい気はする。 (実質 Un*x
でしか使えない環境依存だから入れたくないのかもしれんが。)
[37]
XML デジタル署名系仕様では
Base64 を使うことを識別するために
http://www.w3.org/2000/09/xmldsig#base64
という URI参照を使っています。
(名無しさん [sage])
[41] たっぴ (パソコン質問掲示板) - Question and Answers - http://pcq.furu.org/thread.php?thread=81003
BASE64への変換(エンコード)やBASE64からの逆変換(デコード)はこちらで確認することができるようです。 http://suika.fam.cx/~wakaba/-temp/wiki/wiki?Base64
ちょwwwwwwwwwwwwwwwwwwwwwwwwwww そんな話聞いたことないってwww (名無しさん 2006-05-28 11:09:01 +00:00)
[51]
MTOM は、往復変換を保障するため、 XML Schema
の base64Binary の正準形のみを最適化対象としています。
(名無しさん)
[42] Base64 - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Base64 (名無しさん )
Base64
[825] RFC 6120 - Extensible Messaging and Presence Protocol (XMPP): Core ( ( 版)) http://tools.ietf.org/html/rfc6120#section-13.9.1
[852] W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes ( ( 版)) http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#base64Binary
[854] Jakarta Commons Codec による Base64符号の末尾に改行が付加される件について - keigoiの日記 ( ( 版)) http://d.hatena.ne.jp/keigoi/20090820/1250760023
[855] Base 64 エンコーディングと改行 (line feed) の話 - ひだまりソケットは壊れない ( ( 版)) http://vividcode.hatenablog.com/entry/2012/05/12/051058#comment-11696248318757556925
[856] RFC 6591 - Authentication Failure Reporting Using the Abuse Reporting Format ( ( 版)) http://tools.ietf.org/html/rfc6591#section-2.3
[881] XPath and XQuery Functions and Operators 3.0 ( ( 版)) http://www.w3.org/TR/xpath-functions-3/#binary-functions
[882] Native base64 utility methods ( ( 版)) http://esdiscuss.org/topic/native-base64-utility-methods
[883] IRC logs: freenode / #whatwg / 20140505 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140505#l-183
[885] Bug 22731 – Should atob() trim spaces, or not? ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=22731
[886] IRC logs: freenode / #whatwg / 20140929 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140929#l-683
[887] IRC logs: freenode / #whatwg / 20140929 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140929#l-683
[888] RFC 989 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures ( ( 版)) https://tools.ietf.org/html/rfc989
A specific point regarding the integration of privacy-enhanced mail
facilities with the message encapsulation mechanism is worthy of
note. The subset of IA5 selected for transmission encoding
intentionally excludes the character "-", so encapsulated text can be
distinguished unambiguously from a message's closing encapsulation
boundary (Post-EB) without recourse to character stuffing.
[48] RFC 2440 - OpenPGP Message Format ( 版) https://tools.ietf.org/html/rfc2440#section-6.3
[49] RFC 4880 - OpenPGP Message Format ( 版) https://tools.ietf.org/html/rfc4880#section-6
[50] RFC 1113 - Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures ( 版) http://tools.ietf.org/html/rfc1113#section-4.3
The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455 section 4.1, is wrong. It was processed by a base 64 encoder that was "improperly implemented" as mentioned in RFC 4648 section 3.5. Pad bits were not set to zero, which is a "MUST" requirement in RFC 4648,
[57] Base 64 エンコーディングと改行 (line feed) の話 - ひだまりソケットは壊れない ( 版) http://vividcode.hatenablog.com/entry/2012/05/12/051058
[59] Base64 って結構カオス? - DELPHIER@はてな ( 版) http://d.hatena.ne.jp/izariuo440/20110127/1296138201
[62] Editorial: put properties shared across globals on mixin · whatwg/html@cdd48e1 ( 版) https://github.com/whatwg/html/commit/cdd48e1f570c817402bf62108847c4a9f4b00b1e
The encoding process converts a binary value into a series of character codes for ASCII characters using the familiar base64 encoding scheme
[76] XPath and XQuery Functions and Operators 3.1 () https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#func-base64Binary-equal
[77] Ambiguities in the "data" URL scheme () https://simonsapin.github.io/data-urls/
[78] Define forgiving base64 (annevk著, ) https://github.com/whatwg/infra/commit/6c69d4505476eb6adf08f3c17f682cff7f58ccb2
[79] base64: move code point check back down (annevk著, ) https://github.com/whatwg/infra/commit/6509cfbbf0c47020f8bcd0ce9786eea0b4f4bb74
[80] Define forgiving-base64 by annevk · Pull Request #145 · whatwg/infra () https://github.com/whatwg/infra/pull/145
[81] base64: move code point check back down by annevk · Pull Request #147 · whatwg/infra () https://github.com/whatwg/infra/pull/147
[82] base64: move code point check back down (annevk著, ) https://github.com/whatwg/infra/commit/6509cfbbf0c47020f8bcd0ce9786eea0b4f4bb74
[83] Move base64 algorithms to Infra by annevk · Pull Request #2920 · whatwg/html () https://github.com/whatwg/html/pull/2920
[84] Where should the web platform's base64 algorithm go? · Issue #2912 · whatwg/html () https://github.com/whatwg/html/issues/2912
[85] Move base64 algorithms to Infra (annevk著, ) https://github.com/whatwg/html/commit/9008ac9439aa7e4a30bd34ace8f7a2f1e63c153c
[127] Define data: URLs by annevk · Pull Request #579 · whatwg/fetch () https://github.com/whatwg/fetch/pull/579
[128] web-platform-tests/html/webappapis/atob at master · w3c/web-platform-tests () https://github.com/w3c/web-platform-tests/tree/master/html/webappapis/atob
[129] data: URL processing and generalized forgiving-base64 decode tests (annevk著, ) https://github.com/w3c/web-platform-tests/commit/7eec2bf5e522d28d99ced501b0f49477c3b105d5
Some simple samples of doing base64 url decoding.
Base64-encoding of
the concatenated
Cookie Value Fields
bits described below
The binary bits should be padded at the
end with zeroes to the nearest multiple of
8 bits, packed into a string of bytes, and
have websafe-base64 encoding
performed.
Above fields are multiples of 6 bits to fit
into base64-encoded bytes.
Tags 33 and 34 are for base64url- and base64-encoded text strings, as defined in [RFC4648];
[230] Correct variable name in base64 algorithm (annevk著, ) https://github.com/whatwg/infra/commit/fcacad00d2b34fbc7ae1d023e81e9661f46e4b0d
[231] Correct variable name in base64 algorithm by annevk · Pull Request #195 · whatwg/infra () https://github.com/whatwg/infra/pull/195
JSON value will be the data encoded as a string using standard base64 encoding with paddings. Either standard or URL-safe base64 encoding with/without paddings are accepted.
By default the encoded file has a line break every 64 characters. To suppress this you can use in addition to -base64 the -A flag. This will produce a file with no line breaks at all.
Base64 itself does not impose a line split, but openssl uses it in PEM context hence enforce that base64 content is splitted by lines with a maximum of 80 characters.
[271] Decentralized Identifiers (DIDs) v1.0 (, ) https://w3c.github.io/did-core/#cbor-extensibility
[272] draft-multiformats-multibase-02 - The Multibase Data Format, , https://tools.ietf.org/html/draft-multiformats-multibase-02
MIME base64 エンコーディングを使用して文字列を Base64 エンコードします。詳細については、RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies の Section 6.8, Base64 Content-Transfer-Encoding を参照してください。
URL クエリ文字列内の無効な文字を有効な文字で置き換えます。次の表に無効な文字と有効な文字を示します。
無効な文字 (置換元) 有効な文字 (置換先)
+
- (ハイフン)
=
_ (下線)
/
~ (チルダ)
[289] base64 dialect · Issue #539 · httpwg/http-extensions () https://github.com/httpwg/http-extensions/issues/539
[291] d3x0r/JSOX: JavaScript Object eXchange format; extended JSON/JSON6 () https://github.com/d3x0r/JSOX#base64-character-set
[298] How does the base64 chosen here compare to atob/btoa? · Issue #5 · tc39/proposal-arraybuffer-base64 · GitHub, https://github.com/tc39/proposal-arraybuffer-base64/issues/5
=は URL では query などで特別な意味を持つことがあるので、 あまり安全ではありません。 RFC は原則を貫こうとするあまり、 一般的な実装が意図的に加えた改変を無視しているのです。