base64.h

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

/*
	Copyright 2006 - 2008
	ZhangLuduo <[e-mail]>
	All Rights Reserved.
							
	Base64 编码及解码

	作者	- 张鲁夺(zhangluduo)
	MSN		- [e-mail]
	QQ群	- 34064264

	为所有爱我的人和我爱的人努力!
*/

#ifndef _BASE64_H
#define _BASE64_H

#pragma warning(disable:4786) 
#include <string>
using namespace std;

class Base64
{
public:
	Base64();
	virtual ~Base64();

private:

	//编码表
	char*	m_EncodeTable;
	char	m_DecodeTable[256];

	//char GetDecodeChar(char ch);

	void EncodeInput1(/* in */const unsigned char pData[1], /* out */char EncodeBuf[4]);
	void EncodeInput2(/* in */const unsigned char pData[2], /* out */char EncodeBuf[4]);
	void EncodeInput3(/* in */const unsigned char pData[3], /* out */char EncodeBuf[4]);

public:

	string	Encode(unsigned char* pData, int DataLen);
	string	Decode(unsigned char* pData, int DataLen, int* nByte = 0);

};

#endif

//	rfc3548.txt
//
//
//
//
//
//
//
//	Network Working Group                                  S. Josefsson, Ed.
//	Request for Comments: 3548                                     July 2003
//	Category: Informational
//
//
//				 The Base16, Base32, and Base64 Data Encodings
//
//	Status of this Memo
//
//	   This memo provides information for the Internet community.  It does
//	   not specify an Internet standard of any kind.  Distribution of this
//	   memo is unlimited.
//
//	Copyright Notice
//
//	   Copyright (C) The Internet Society (2003).  All Rights Reserved.
//
//	Abstract
//
//	   This document describes the commonly used base 64, base 32, and base
//	   16 encoding schemes.  It also discusses the use of line-feeds in
//	   encoded data, use of padding in encoded data, use of non-alphabet
//	   characters in encoded data, and use of different encoding alphabets.
//
//	Table of Contents
//
//	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
//	   2.  Implementation discrepancies . . . . . . . . . . . . . . . . .  2
//		   2.1.  Line feeds in encoded data . . . . . . . . . . . . . . .  2
//		   2.2.  Padding of encoded data  . . . . . . . . . . . . . . . .  3
//		   2.3.  Interpretation of non-alphabet characters in encoded
//				 data . . . . . . . . . . . . . . . . . . . . . . . . . .  3
//		   2.4.  Choosing the alphabet  . . . . . . . . . . . . . . . . .  3
//	   3.  Base 64 Encoding . . . . . . . . . . . . . . . . . . . . . . .  4
//	   4.  Base 64 Encoding with URL and Filename Safe Alphabet . . . . .  6
//	   5.  Base 32 Encoding . . . . . . . . . . . . . . . . . . . . . . .  6
//	   6.  Base 16 Encoding . . . . . . . . . . . . . . . . . . . . . . .  8
//	   7.  Illustrations and examples . . . . . . . . . . . . . . . . . .  9
//	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
//	   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
//		   9.1.  Normative References . . . . . . . . . . . . . . . . . . 11
//		   9.2.  Informative References . . . . . . . . . . . . . . . . . 11
//	   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
//	   11. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 12
//	   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
//
//
//
//
//
//
//	Josefsson                    Informational                      [Page 1]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	1.  Introduction
//
//	   Base encoding of data is used in many situations to store or transfer
//	   data in environments that, perhaps for legacy reasons, are restricted
//	   to only US-ASCII [9] data.  Base encoding can also be used in new
//	   applications that do not have legacy restrictions, simply because it
//	   makes it possible to manipulate objects with text editors.
//
//	   In the past, different applications have had different requirements
//	   and thus sometimes implemented base encodings in slightly different
//	   ways.  Today, protocol specifications sometimes use base encodings in
//	   general, and "base64" in particular, without a precise description or
//	   reference.  MIME [3] is often used as a reference for base64 without
//	   considering the consequences for line-wrapping or non-alphabet
//	   characters.  The purpose of this specification is to establish common
//	   alphabet and encoding considerations.  This will hopefully reduce
//	   ambiguity in other documents, leading to better interoperability.
//
//	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
//	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
//	   document are to be interpreted as described in RFC 2119 [1].
//
//	2.  Implementation discrepancies
//
//	   Here we discuss the discrepancies between base encoding
//	   implementations in the past, and where appropriate, mandate a
//	   specific recommended behavior for the future.
//
//	2.1.  Line feeds in encoded data
//
//	   MIME [3] is often used as a reference for base 64 encoding.  However,
//	   MIME does not define "base 64" per se, but rather a "base 64
//	   Content-Transfer-Encoding" for use within MIME.  As such, MIME
//	   enforces a limit on line length of base 64 encoded data to 76
//	   characters.  MIME inherits the encoding from PEM [2] stating it is
//	   "virtually identical", however PEM uses a line length of 64
//	   characters.  The MIME and PEM limits are both due to limits within
//	   SMTP.
//
//	   Implementations MUST NOT not add line feeds to base encoded data
//	   unless the specification referring to this document explicitly
//	   directs base encoders to add line feeds after a specific number of
//	   characters.
//
//
//
//
//
//
//
//
//	Josefsson                    Informational                      [Page 2]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	2.2.  Padding of encoded data
//
//	   In some circumstances, the use of padding ("=") in base encoded data
//	   is not required nor used.  In the general case, when assumptions on
//	   size of transported data cannot be made, padding is required to yield
//	   correct decoded data.
//
//	   Implementations MUST include appropriate pad characters at the end of
//	   encoded data unless the specification referring to this document
//	   explicitly states otherwise.
//
//	2.3.  Interpretation of non-alphabet characters in encoded data
//
//	   Base encodings use a specific, reduced, alphabet to encode binary
//	   data.  Non alphabet characters could exist within base encoded data,
//	   caused by data corruption or by design.  Non alphabet characters may
//	   be exploited as a "covert channel", where non-protocol data can be
//	   sent for nefarious purposes.  Non alphabet characters might also be
//	   sent in order to exploit implementation errors leading to, e.g.,
//	   buffer overflow attacks.
//
//	   Implementations MUST reject the encoding if it contains characters
//	   outside the base alphabet when interpreting base encoded data, unless
//	   the specification referring to this document explicitly states
//	   otherwise.  Such specifications may, as MIME does, instead state that
//	   characters outside the base encoding alphabet should simply be
//	   ignored when interpreting data ("be liberal in what you accept").
//	   Note that this means that any CRLF constitute "non alphabet
//	   characters" and are ignored.  Furthermore, such specifications may
//	   consider the pad character, "=", as not part of the base alphabet
//	   until the end of the string.  If more than the allowed number of pad
//	   characters are found at the end of the string, e.g., a base 64 string
//	   terminated with "===", the excess pad characters could be ignored.
//
//	2.4.  Choosing the alphabet
//
//	   Different applications have different requirements on the characters
//	   in the alphabet.  Here are a few requirements that determine which
//	   alphabet should be used:
//
//	   o   Handled by humans.  Characters "0", "O" are easily interchanged,
//		   as well "1", "l" and "I".  In the base32 alphabet below, where 0
//		   (zero) and 1 (one) is not present, a decoder may interpret 0 as
//		   O, and 1 as I or L depending on case.  (However, by default it
//		   should not, see previous section.)
//
//
//
//
//
//
//	Josefsson                    Informational                      [Page 3]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	   o   Encoded into structures that place other requirements.  For base
//		   16 and base 32, this determines the use of upper- or lowercase
//		   alphabets.  For base 64, the non-alphanumeric characters (in
//		   particular "/") may be problematic in file names and URLs.
//
//	   o   Used as identifiers.  Certain characters, notably "+" and "/" in
//		   the base 64 alphabet, are treated as word-breaks by legacy text
//		   search/index tools.
//
//	   There is no universally accepted alphabet that fulfills all the
//	   requirements.  In this document, we document and name some currently
//	   used alphabets.
//
//	3.  Base 64 Encoding
//
//	   The following description of base 64 is due to [2], [3], [4] and [5].
//
//	   The Base 64 encoding is designed to represent arbitrary sequences of
//	   octets in a form that requires case sensitivity but need not be
//	   humanly readable.
//
//	   A 65-character subset of US-ASCII is used, enabling 6 bits to be
//	   represented per printable character.  (The extra 65th character, "=",
//	   is used to signify a special processing function.)
//
//	   The encoding process represents 24-bit groups of input bits as output
//	   strings of 4 encoded characters.  Proceeding from left to right, a
//	   24-bit input group is formed by concatenating 3 8-bit input groups.
//	   These 24 bits are then treated as 4 concatenated 6-bit groups, each
//	   of which is translated into a single digit in the base 64 alphabet.
//
//	   Each 6-bit group is used as an index into an array of 64 printable
//	   characters.  The character referenced by the index is placed in the
//	   output string.
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//	Josefsson                    Informational                      [Page 4]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//					   Table 1: The Base 64 Alphabet
//
//		  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
//
//	   Special processing is performed if fewer than 24 bits are available
//	   at the end of the data being encoded.  A full encoding quantum is
//	   always completed at the end of a quantity.  When fewer than 24 input
//	   bits are available in an input group, zero bits are added (on the
//	   right) to form an integral number of 6-bit groups.  Padding at the
//	   end of the data is performed using the '=' character.  Since all base
//	   64 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 24
//	   bits; here, the final unit of encoded output will be an integral
//	   multiple of 4 characters with no "=" padding,
//
//	   (2) the final quantum of encoding input is exactly 8 bits; here, the
//	   final unit of encoded output will be two characters followed by two
//	   "=" padding characters, or
//
//	   (3) the final quantum of encoding input is exactly 16 bits; here, the
//	   final unit of encoded output will be three characters followed by one
//	   "=" padding character.
//
//
//
//
//
//
//
//
//
//
//	Josefsson                    Informational                      [Page 5]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//
//
//	4.  Base 64 Encoding with URL and Filename Safe Alphabet
//
//	   The Base 64 encoding with an URL and filename safe alphabet has been
//	   used in [8].
//
//	   An alternative alphabet has been suggested that used "~" as the 63rd
//	   character.  Since the "~" character has special meaning in some file
//	   system environments, the encoding described in this section is
//	   recommended instead.
//
//	   This encoding should not be regarded as the same as the "base64"
//	   encoding, and should not be referred to as only "base64".  Unless
//	   made clear, "base64" refer to the base 64 in the previous section.
//
//	   This encoding is technically identical to the previous one, except
//	   for the 62:nd and 63:rd alphabet character, as indicated in table 2.
//
//			 Table 2: The "URL and Filename safe" Base 64 Alphabet
//
//		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 - (minus)
//		  12 M            29 d            46 u            63 _ (understrike)
//		  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
//
//	5.  Base 32 Encoding
//
//	   The following description of base 32 is due to [7] (with
//	   corrections).
//
//	   The Base 32 encoding is designed to represent arbitrary sequences of
//	   octets in a form that needs to be case insensitive but need not be
//	   humanly readable.
//
//
//
//
//
//	Josefsson                    Informational                      [Page 6]
//	
//	RFC 3548     The Base16, Base32, and Base64 Data Encodings     July 2003
//