| The character referenced by the index shall be placed in the output | | | | | | |
|
| string. | | | | | | |
|
| The output stream (encoded bytes) shall be represented in lines of no |
|
| found in the table shall be ignored by decoding software (see | |
|
| available at the end of a message or encapsulated part of a message. A |
| full encoding quantum shall always be completed at the end of a |
| message. When fewer than 24 input bits are available in an input group, |
| zero bits shall be added (on the right) to form an integral number of |
| 6-bit groups. Output character positions that are not required to |
| represent actual input data shall be set to the character |
| Since all Base64 input is an integral number of octets, only the |
| following cases can arise: | |
|
| here, the final unit of encoded output shall be an integral multiple of | |
| 4 characters with no |
| padding. |
| The final quantum of encoding input is exactly 16 bits; here, the final |
| unit of encoded output shall be three characters followed by one |
| padding character. |
| The final quantum of encoding input is exactly 8 bits; here, the final |
| unit of encoded output shall be two characters followed by two |
| padding characters. |
| A terminating |
| evaluates to nothing and denotes the end of the encoded data. |
| The standard output shall be a text file (encoded in the character set |
| of the current locale) that begins with the line: |
|
| "begin %s %s\n" <mode>, <decode_pathname> |
| and ends with the line: |
|
| "end\n" |
| In both cases, the lines shall have no preceding or trailing |
| <blank> |
| characters. |
| The algorithm that shall be used for lines in between |
| and |
| takes three octets as input and writes four characters of output by |
| splitting the input at six-bit intervals into four octets, containing |
| data in the lower six bits only. These octets shall be converted to |
| characters by adding a value of 0x20 to each octet, so that each octet |
| is in the range [0x20,0x5f], and then it shall be assumed to represent |
| a printable character in the ISO/IEC 646:1991 standard encoded character set. It then |
| shall be translated into the corresponding character codes for the |
| codeset in use in the current locale. (For example, the octet 0x41, |
| representing |
| would be translated to |
| in the current codeset, such as 0xc1 if it were EBCDIC.) |
| Where the bits of two octets are combined, the least significant bits |
| of the first octet shall be shifted left and combined with the most |
| significant bits of the second octet shifted right. Thus the three |
| octets |
| shall be converted into the four octets: |
|
| 0x20 + (( A >> 2 ) & 0x3F) |
| 0x20 + (((A << 4) | ((B >> 4) & 0xF)) & 0x3F) |
| 0x20 + (((B << 2) | ((C >> 6) & 0x3)) & 0x3F) |
| 0x20 + (( C ) & 0x3F) |
| These octets then shall be translated into the local character set. |
| Each encoded line contains a length character, equal to the number of |
| characters to be decoded plus 0x20 translated to the local character |
| set as described above, followed by the encoded characters. The |
| maximum number of octets to be encoded on each line shall be 45. |
| The standard error shall be used only for diagnostic messages. |
| None. |
| None. |
| The following exit values shall be returned: |
| Successful completion. |
| An error occurred. |
| Default. |
| The file is expanded by 35 percent (each three octets become four, plus |
| control information) causing it to take longer to transmit. |
| Since this utility is intended to create files to be used for data |
| interchange between systems with possibly different codesets, and to |
| represent binary data as a text file, the ISO/IEC 646:1991 standard was chosen for a |
| midpoint in the algorithm as a known reference point. The output from |
| is a text file on the local system. If the output were in the ISO/IEC 646:1991 standard |
| codeset, it might not be a text file (at least because the |
| <newline> |
| characters might not match), and the goal of creating a text file would |
| be defeated. If this text file was then carried to another machine with |
| the same codeset, it would be perfectly compatible with that system's |
| If it was transmitted over a mail system or sent to a machine with a |
| different codeset, it is assumed that, as for every other text file, |
| some translation mechanism would convert it (by the time it reached a |
| user on the other system) into an appropriate codeset. This |
| translation only makes sense from the local codeset, not if the file |
| has been put into a ISO/IEC 646:1991 standard representation first. Similarly, files |
| processed by |
| can be placed in |
| archives, intermixed with other text files in the same codeset. |
| None. |
| A new algorithm was added at the request of the international community |
| to parallel work in RFC 2045 (MIME). As with the historical |
| format, the Base64 Content-Transfer-Encoding is designed to represent |
| arbitrary sequences of octets in a form that is not humanly readable. A |
| 65-character subset of the ISO/IEC 646:1991 standard is used, enabling 6 bits to be |
| represented per printable character. (The extra 65th character, |
| is used to signify a special processing function.) |
| This subset has the important property that it is represented |
| identically in all versions of the ISO/IEC 646:1991 standard, including US ASCII, and all |
| characters in the subset are also represented identically in all |
| versions of EBCDIC. The historical |
| algorithm does not share this property, which is the reason that a |
| second algorithm was added to the ISO POSIX-2 standard. |
| The string |
| was used for the termination instead of the end used in the original |
| format because the latter is a string that could be valid encoded |
| input. |
| In an early draft, the |
| option was named |
| (for Base64), but it was renamed to reflect its relationship to the |
| RFC 2045. A |
| was also present to invoke the default algorithm, but since this was |
| not historical practice, it was omitted as being unnecessary. |
| See the RATIONALE section in |
| for the derivation of the |
| symbol. |
| None. |
| The Base Definitions volume of POSIX.1-2008, |
| Portions of this text are reprinted and reproduced in electronic form |
| from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology |
| -- Portable Operating System Interface (POSIX), The Open Group Base |
| Specifications Issue 7, Copyright (C) 2013 by the Institute of |
| Electrical and Electronics Engineers, Inc and The Open Group. |
| (This is POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the |
| event of any discrepancy between this version and the original IEEE and |
| The Open Group Standard, the original IEEE and The Open Group Standard |
| is the referee document. The original Standard can be obtained online at |
| http://www.unix.org/online.html . |
|
| Any typographical or formatting errors that appear |
| in this page are most likely |
| to have been introduced during the conversion of the source files to |
| man page format. To report such errors, see |
| https://www.kernel.org/doc/man-pages/reporting_bugs.html . |
|
|
|
|
|
- Running on 
-
:
: 