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
[142] RFC 989 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures () https://tools.ietf.org/html/rfc989#section-4.3
[143] RFC 1040 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures () https://tools.ietf.org/html/rfc1040#section-4.3.2.4
[144] RFC 1113 - Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures () https://tools.ietf.org/html/rfc1113#section-4.3.2.4
[149] RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies () https://tools.ietf.org/html/rfc1341#page-17
[150] RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies () https://tools.ietf.org/html/rfc1521#section-5.2
[43] RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies ( 版) https://tools.ietf.org/html/rfc2045#section-6.8
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.
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.
[72] RFC 7950 - The YANG 1.1 Data Modeling Language
()
https://tools.ietf.org/html/rfc7950#section-9.8
[831] please prefer base 64 over base 32 (was: Re: [p2p-hackers] Bitzi (was Various identifier choices)) ( 版) http://zgp.org/pipermail/p2p-hackers/2001-September/000317.html
[832] please prefer base 64 over base 32 (was: Re: [p2p-hackers] Bitzi (was Various identifier choices)) ( 版) http://zgp.org/pipermail/p2p-hackers/2001-September/000316.html
[829] Base64 - Wikipedia, the free encyclopedia ( 版) http://en.wikipedia.org/wiki/Base64#URL_applications
[220] JSON-Base64 (JB64) File Format Specification () https://jb64.org/specification/
[292]
Class Utilities | Apps Script | Google Developers, , https://developers.google.com/apps-script/reference/utilities/utilities
[241]復号の方法は厳密には規定されていません。
[242] RFC 7515RFC 7515 base64url復号 は
「Base64url-decode the encoded representation of (入力データ),
following the restriction that no line breaks, whitespace, or
other additional characters have been used.」
という表現を用いています >>240。
これが満たされないとき検証は失敗することとなり、
緩い復号を用いないことを求めています。
ただし詰めの扱いは明言していません。
[233]RFC 7515 - JSON Web Signature (JWS) () https://tools.ietf.org/html/rfc7515#page-6
[240]RFC 7515 - JSON Web Signature (JWS) () https://tools.ietf.org/html/rfc7515#page-17
[295]RFC 7516
[296]RFC 7516 - JSON Web Encryption (JWE), https://datatracker.ietf.org/doc/html/rfc7516#section-1.1
[264]RFC 7518
[262]RFC 7518 - JSON Web Algorithms (JWA), https://tools.ietf.org/html/rfc7518#section-1.1
[265]RFC 7518 - JSON Web Algorithms (JWA), https://tools.ietf.org/html/rfc7518#section-2
[297]RFC 7517: JSON Web Key (JWK), https://www.rfc-editor.org/rfc/rfc7517.html#section-1.1
[54] RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
( 版)
https://tools.ietf.org/html/rfc7522
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.
[56] RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
( 版)
https://tools.ietf.org/html/rfc7636
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]符号化は、バイト列入力を、次のようにするべきです。
[249]結果を、入力を forgiving-base64 encode
した結果に設定します。
[250]結果中の + を、すべて -
に置き換えます。
[251]結果中の / を、すべて _
に置き換えます。
[252]結果中の = を、すべて削除します。
[253]結果を返します。
[254]復号は、文字列入力を、次のようにするべきです。
[255]入力中の - を、すべて +
に置き換えます。
[256]入力中の _ を、すべて /
に置き換えます。
[257]入力中に
+, /, =,
ASCII英数字のいずれでもない符号位置が含まれる場合、
[258]失敗を返し、ここで停止します。
[259]入力を forgiving-base64 decode した結果を返します。
HTTP Certificate Store Interface の Base64
[300]HTTP Certificate Store Interface
は
Base64
の一種を使っています。
>>299
[299]RFC 4387: Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP, , https://www.rfc-editor.org/rfc/rfc4387.html#section-2.1
[884] RFC 4387 - Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP ( 版) http://tools.ietf.org/html/rfc4387#section-2.1
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
[52]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
[873] Web Applications 1.0 r5814 Specify window.atob() and .btoa(). (ack Aryeh for the reverse-engineering to do this)
( ( 版))
http://html5.org/tools/web-apps-tracker?from=5813&to=5814
[874] [whatwg] Specs for window.atob() and window.btoa()
( ( 版))
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030154.html
[875] Web Applications 1.0 r5867 remove window.atob/btoa from the W3C draft
( ( 版))
http://html5.org/tools/web-apps-tracker?from=5866&to=5867
[876] Web Applications 1.0 r5874 revert 5867, which was apparently based on a miscommunication
( ( 版))
http://html5.org/tools/web-apps-tracker?from=5873&to=5874
[879] [whatwg] Specs for window.atob() and window.btoa()
( ( 版))
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031541.html
[880] Web Applications 1.0 r6874 Change atob() to ignore whitespace. This is a potentially breaking change, but Opera has implemented it for a while and doesn't seem to have had any problems resulting.
( ( 版))
http://html5.org/tools/web-apps-tracker?from=6873&to=6874
[868] [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
( ( 版))
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040364.html
[888] RFC 989 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures
( ( 版))
https://tools.ietf.org/html/rfc989
[38] RFC 989 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures
( 版)
https://tools.ietf.org/html/rfc989#section-4.4
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,
[62] Editorial: put properties shared across globals on mixin · whatwg/html@cdd48e1
( 版)
https://github.com/whatwg/html/commit/cdd48e1f570c817402bf62108847c4a9f4b00b1e
[64] Encoded Polyline Algorithm Format | Google Maps APIs | Google Developers
()
https://developers.google.com/maps/documentation/utilities/polylinealgorithm
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
Web Base64 の標準化
[77] Ambiguities in the "data" URL scheme
()
https://simonsapin.github.io/data-urls/
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
[232] Language Guide (proto3) | Protocol Buffers | Google Developers
()
https://developers.google.com/protocol-buffers/docs/proto3#json
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.
MIME base64 エンコーディングを使用して文字列を Base64 エンコードします。詳細については、RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies の Section 6.8, Base64 Content-Transfer-Encoding を参照してください。
[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