Such specifications may instead state, as MIMEĭoes, that characters outside the base encoding alphabet should Implementations MUST reject the encoded data if it containsĬharacters outside the base alphabet when interpreting base-encodedĭata, unless the specification referring to this document explicitly Sent in order to exploit implementation errors leading to, e.g., Non-alphabet characters mayīe exploited as a "covert channel", where non-protocol data can be Non-alphabet characters could exist within base-encoded data,Ĭaused by data corruption or by design. Interpretation of Non-Alphabet Characters in Encoded Dataīase encodings use a specific, reduced alphabet to encode binaryĭata. Sections 4 and 6, but the base16 alphabet does not need it seeģ.3. The base64 and base32 alphabets use padding, as described below in
Implementations MUST include appropriate pad characters at the end ofĮncoded data unless the specification referring to this document The size of transported data cannot be made, padding is required to In the general case, when assumptions about In some circumstances, the use of padding ("=") in base-encoded data RFC 4648 Base-N Encodings October 2006 3.2. The specification referring to this document explicitly directs baseĮncoders to add line feeds after a specific number of characters. Implementations MUST NOT add line feeds to base-encoded data unless The MIME and PEM limits are both due to limits within That it is "virtually identical" however, PEM uses a line length ofĦ4 characters. Inherits the encoding from Privacy Enhanced Mail (PEM), stating Limit on line length of base 64-encoded data to 76 characters. MIME does not define "base 64" per se, but rather a "base 64 Content. MIME is often used as a reference for base 64 encoding. Specific recommended behavior for the future. Implementations in the past and, where appropriate, mandate a Here we discuss the discrepancies between base encoding "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thisĭocument are to be interpreted as described in. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This will hopefully reduce ambiguity in otherĭocuments, leading to better interoperability. Specification is to establish common alphabet and encodingĬonsiderations. Used as a reference for base64 without considering the consequencesįor line-wrapping or non-alphabet characters. Multipurpose Internet Mail Extensions (MIME) is often General, and "base64" in particular, without a precise description or Today, protocol specifications sometimes use base encodings in In the past, different applications have had different requirementsĪnd thus sometimes implemented base encodings in slightly different Makes it possible to manipulate objects with text editors. Base encoding can also be used in newĪpplications that do not have legacy restrictions, simply because it Introductionīase encoding of data is used in many situations to store or transferĭata in environments that, perhaps for legacy reasons, are restricted RFC 4648 Base-N Encodings October 2006 1. Base 32 Encoding with Extended Hex Alphabet.
Base 64 Encoding with URL and Filename Safe Alphabet. Interpretation of Non-Alphabet Characters in Encoded Data. It also discusses the use of line-feeds inĮncoded data, use of padding in encoded data, use of non-alphabetĬharacters in encoded data, use of different encoding alphabets, andġ. This document describes the commonly used base 64, base 32, and baseġ6 encoding schemes. Distribution of this memo is unlimited.Ĭopyright (C) The Internet Society (2006). Official Protocol Standards" (STD 1) for the standardization stateĪnd status of this protocol. Please refer to the current edition of the "Internet
Internet community, and requests discussion and suggestions for This document specifies an Internet standards track protocol for the The Base16, Base32, and Base64 Data Encodings RFC 4648: The Base16, Base32, and Base64 Data Encodings Įrrata Exist Network Working Group S.
0 kommentar(er)
