base64.h

Base64编码算法, 可以分别对字符串和文件进行编码/解码,带进度条, 内含VC++6.0源码

//
//	   A 33-character subset of US-ASCII is used, enabling 5 bits to be
//	   represented per printable character.  (The extra 33rd character, "=",
//	   is used to signify a special processing function.)
//
//	   The encoding process represents 40-bit groups of input bits as output
//	   strings of 8 encoded characters.  Proceeding from left to right, a
//	   40-bit input group is formed by concatenating 5 8bit input groups.
//	   These 40 bits are then treated as 8 concatenated 5-bit groups, each
//	   of which is translated into a single digit in the base 32 alphabet.
//	   When encoding a bit stream via the base 32 encoding, the bit stream
//	   must be presumed to be ordered with the most-significant-bit first.
//	   That is, the first bit in the stream will be the high-order bit in
//	   the first 8bit byte, and the eighth bit will be the low-order bit in
//	   the first 8bit byte, and so on.
//
//	   Each 5-bit group is used as an index into an array of 32 printable
//	   characters.  The character referenced by the index is placed in the
//	   output string.  These characters, identified in Table 2, below, are
//	   selected from US-ASCII digits and uppercase letters.
//
//					   Table 3: The Base 32 Alphabet
//
//			Value Encoding  Value Encoding  Value Encoding  Value Encoding
//				0 A             9 J            18 S            27 3
//				1 B            10 K            19 T            28 4
//				2 C            11 L            20 U            29 5
//				3 D            12 M            21 V            30 6
//				4 E            13 N            22 W            31 7
//				5 F            14 O            23 X
//				6 G            15 P            24 Y         (pad) =
//				7 H            16 Q            25 Z
//				8 I            17 R            26 2
//
//
//	   Special processing is performed if fewer than 40 bits are available
//	   at the end of the data being encoded.  A full encoding quantum is
//	   always completed at the end of a body.  When fewer than 40 input bits
//	   are available in an input group, zero bits are added (on the right)
//	   to form an integral number of 5-bit groups.  Padding at the end of
//	   the data is performed using the "=" character.  Since all base 32
//	   input is an integral number of octets, only the following cases can
//	   arise:
//
//	   (1) the final quantum of encoding input is an integral multiple of 40
//	   bits; here, the final unit of encoded output will be an integral
//	   multiple of 8 characters with no "=" padding,
//
//
//
//
//
//	Josefsson                    Informational                      [Page 7]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	   (2) the final quantum of encoding input is exactly 8 bits; here, the
//	   final unit of encoded output will be two characters followed by six
//	   "=" padding characters,
//
//	   (3) the final quantum of encoding input is exactly 16 bits; here, the
//	   final unit of encoded output will be four characters followed by four
//	   "=" padding characters,
//
//	   (4) the final quantum of encoding input is exactly 24 bits; here, the
//	   final unit of encoded output will be five characters followed by
//	   three "=" padding characters, or
//
//	   (5) the final quantum of encoding input is exactly 32 bits; here, the
//	   final unit of encoded output will be seven characters followed by one
//	   "=" padding character.
//
//	6.  Base 16 Encoding
//
//	   The following description is original but analogous to previous
//	   descriptions.  Essentially, Base 16 encoding is the standard standard
//	   case insensitive hex encoding, and may be referred to as "base16" or
//	   "hex".
//
//	   A 16-character subset of US-ASCII is used, enabling 4 bits to be
//	   represented per printable character.
//
//	   The encoding process represents 8-bit groups (octets) of input bits
//	   as output strings of 2 encoded characters.  Proceeding from left to
//	   right, a 8-bit input is taken from the input data.  These 8 bits are
//	   then treated as 2 concatenated 4-bit groups, each of which is
//	   translated into a single digit in the base 16 alphabet.
//
//	   Each 4-bit group is used as an index into an array of 16 printable
//	   characters.  The character referenced by the index is placed in the
//	   output string.
//
//					   Table 5: The Base 16 Alphabet
//
//		  Value Encoding  Value Encoding  Value Encoding  Value Encoding
//			  0 0             4 4             8 8            12 C
//			  1 1             5 5             9 9            13 D
//			  2 2             6 6            10 A            14 E
//			  3 3             7 7            11 B            15 F
//
//	   Unlike base 32 and base 64, no special padding is necessary since a
//	   full code word is always available.
//
//
//
//
//
//	Josefsson                    Informational                      [Page 8]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	7.  Illustrations and examples
//
//	   To translate between binary and a base encoding, the input is stored
//	   in a structure and the output is extracted.  The case for base 64 is
//	   displayed in the following figure, borrowed from [4].
//
//			 +--first octet--+-second octet--+--third octet--+
//			 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
//			 +-----------+---+-------+-------+---+-----------+
//			 |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
//			 +--1.index--+--2.index--+--3.index--+--4.index--+
//
//	   The case for base 32 is shown in the following figure, borrowed from
//	   [6].  Each successive character in a base-32 value represents 5
//	   successive bits of the underlying octet sequence.  Thus, each group
//	   of 8 characters represents a sequence of 5 octets (40 bits).
//
//							1          2          3
//			  01234567 89012345 67890123 45678901 23456789
//			 +--------+--------+--------+--------+--------+
//			 |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
//			 +--------+--------+--------+--------+--------+
//													 <===> 8th character
//											   <====> 7th character
//										  <===> 6th character
//									<====> 5th character
//							  <====> 4th character
//						 <===> 3rd character
//				   <====> 2nd character
//			  <===> 1st character
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//	Josefsson                    Informational                      [Page 9]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	   The following example of Base64 data is from [4].
//
//		   Input data:  0x14fb9c03d97e
//		   Hex:     1   4    f   b    9   c     | 0   3    d   9    7   e
//		   8-bit:   00010100 11111011 10011100  | 00000011 11011001
//		   11111110
//		   6-bit:   000101 001111 101110 011100 | 000000 111101 100111
//		   111110
//		   Decimal: 5      15     46     28       0      61     37     62
//		   Output:  F      P      u      c        A      9      l      +
//
//		   Input data:  0x14fb9c03d9
//		   Hex:     1   4    f   b    9   c     | 0   3    d   9
//		   8-bit:   00010100 11111011 10011100  | 00000011 11011001
//														   pad with 00
//		   6-bit:   000101 001111 101110 011100 | 000000 111101 100100
//		   Decimal: 5      15     46     28       0      61     36
//															  pad with =
//		   Output:  F      P      u      c        A      9      k      =
//
//		   Input data:  0x14fb9c03
//		   Hex:     1   4    f   b    9   c     | 0   3
//		   8-bit:   00010100 11111011 10011100  | 00000011
//												  pad with 0000
//		   6-bit:   000101 001111 101110 011100 | 000000 110000
//		   Decimal: 5      15     46     28       0      48
//													   pad with =      =
//		   Output:  F      P      u      c        A      w      =      =
//
//	8.  Security Considerations
//
//	   When implementing Base encoding and decoding, care should be taken
//	   not to introduce vulnerabilities to buffer overflow attacks, or other
//	   attacks on the implementation.  A decoder should not break on invalid
//	   input including, e.g., embedded NUL characters (ASCII 0).
//
//	   If non-alphabet characters are ignored, instead of causing rejection
//	   of the entire encoding (as recommended), a covert channel that can be
//	   used to "leak" information is made possible.  The implications of
//	   this should be understood in applications that do not follow the
//	   recommended practice.  Similarly, when the base 16 and base 32
//	   alphabets are handled case insensitively, alteration of case can be
//	   used to leak information.
//
//	   Base encoding visually hides otherwise easily recognized information,
//	   such as passwords, but does not provide any computational
//	   confidentiality.  This has been known to cause security incidents
//	   when, e.g., a user reports details of a network protocol exchange
//
//
//
//	Josefsson                    Informational                     [Page 10]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	   (perhaps to illustrate some other problem) and accidentally reveals
//	   the password because she is unaware that the base encoding does not
//	   protect the password.
//
//	9.  References
//
//	9.1.  Normative References
//
//	   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
//		   Levels", BCP 14, RFC 2119, March 1997.
//
//	9.2.  Informative References
//
//	   [2] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
//		   Part I: Message Encryption and Authentication Procedures", RFC
//		   1421, February 1993.
//
//	   [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
//		   Extensions (MIME) Part One: Format of Internet Message Bodies",
//		   RFC 2045, November 1996.
//
//	   [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
//		   Message Format", RFC 2440, November 1998.
//
//	   [5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535,
//		   March 1999.
//
//	   [6] Klyne, G. and L. Masinter, "Identifying Composite Media
//		   Features", RFC 2938, September 2000.
//
//	   [7] Myers, J., "SASL GSSAPI mechanisms", Work in Progress.
//
//	   [8] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list", World
//		   Wide Web http://zgp.org/pipermail/p2p-hackers/2001-
//		   September/000315.html, September 2001.
//
//	   [9] Cerf, V., "ASCII format for Network Interchange", RFC 20, October
//		   1969.
//
//	10.  Acknowledgements
//
//	   Several people offered comments and suggestions, including Tony
//	   Hansen, Gordon Mohr, John Myers, Chris Newman, and Andrew Sieber.
//	   Text used in this document is based on earlier RFCs describing
//	   specific uses of various base encodings.  The author acknowledges the
//	   RSA Laboratories for supporting the work that led to this document.
//
//
//
//
//
//	Josefsson                    Informational                     [Page 11]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	11.  Editor's Address
//
//	   Simon Josefsson
//	   EMail: [e-mail]
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//	Josefsson                    Informational                     [Page 12]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	12.  Full Copyright Statement
//
//	   Copyright (C) The Internet Society (2003).  All Rights Reserved.
//
//	   This document and translations of it may be copied and furnished to
//	   others, and derivative works that comment on or otherwise explain it
//	   or assist in its implementation may be prepared, copied, published
//	   and distributed, in whole or in part, without restriction of any
//	   kind, provided that the above copyright notice and this paragraph are
//	   included on all such copies and derivative works.  However, this
//	   document itself may not be modified in any way, such as by removing
//	   the copyright notice or references to the Internet Society or other
//	   Internet organizations, except as needed for the purpose of
//	   developing Internet standards in which case the procedures for
//	   copyrights defined in the Internet Standards process must be
//	   followed, or as required to translate it into languages other than
//	   English.
//
//	   The limited permissions granted above are perpetual and will not be
//	   revoked by the Internet Society or its successors or assignees.
//
//	   This document and the information contained herein is provided on an
//	   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
//	   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
//	   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
//	   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
//	   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
//
//	Acknowledgement
//
//	   Funding for the RFC Editor function is currently provided by the
//	   Internet Society.
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//	Josefsson                    Informational                     [Page 13]
//