BASE64 algorithm and MD5 encryption principle

Base64 is one of the most common encoding methods for transmitting 8Bit bytes of code on the network, and you can view rfc2045~rfc2049, which has a detailed specification of MIME. BASE64 encoding can be used to pass longer identity information in an HTTP environment. For example, in the Java Persistence System hibernate, Base64 is used to encode a long unique identifier (typically 128-bit uuid) as a string that is used as a parameter in an HTTP form and an HTTP GET URL. In other applications, it is often necessary to encode binary data as appropriate in the form of URLs (including hidden form fields). At this time, the adoption of BASE64 encoding is not only short, but also has the non-readability, that is, the encoded data will not be directly visible to the naked eye.

The standard Base64 is not intended to be transmitted directly in the URL because the URL encoder will change the "/" and "+" characters in the standard Base64 into forms such as "%XX", and these "%" numbers need to be converted when they are deposited into the database because ANSI SQL has used the "%" number as a wildcard character. To solve this problem, an improved BASE64 encoding for URLs is used, which does not populate the ' = ' at the end and changes the "+" and "/" in standard Base64 to "*" and "-" respectively, thus eliminating the need for conversion in URL codec and database storage. Avoids the increase in the length of encoded information in this process, and unifies the format of object identifiers in databases, forms, and so on. There is also an improved BASE64 variant for regular expressions that changes "+" and "/" to "!" and "-", because "+", "*" and the "[" and "]" used in the preceding IRCU may have special meanings in regular expressions. There are also variants that change "+/" to "_-" or ". _" (used as an identifier name in a programming language) or ".-" (for NmToken in XML) or even "_:" (for name in XML). Base64 requires that every three bytes of 8Bit be converted to four 6Bit bytes (3*8 = 4*6 = 24), and 6Bit is then added two bits high 0, which makes up four 8Bit bytes, that is, the converted string will theoretically be 1/3 longer than the original one. Rules about this coding rule: ①. 3 characters into 4 characters. ② every 76 characters multibyte a newline character. ③. The final terminator should also be dealt with. Wouldn't it be too abstract to say that? Not afraid, let's look at an example: Convert before Aaaaaabb ccccdddd eeffffff conversion 00aaaaaa 00BBCCCC 00ddddee 00ffffff should be clear? The above three bytes are the original text, the following four bytes are the converted Base64 encoding, the first two bits are 0. After the conversion, we use a code table to get the string we want (that is, the final Base64 encoding), this table is this: (from RFC2045) conversion tables Table 1:the Base64 Alphabet

index	corresponding character	index	corresponding characters	index	corresponding characters	index	corresponding characters
0	A	17	R	34	I	51	Z
1	B	18	S	35	J	52
2	C	19	T	36	k	53
3	D	20	U	37	l	54
4	E	21	V	38	m	55
5	F	22	W	39	N	56
6	G	23	X	40	o	57
7	H	24	Y	41	P	58
8	I	25	Z	42	q	59
9	J	26	A	43	R	60
10	K	27	b	44	s	61
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
15	P	32	G	49	X
16	Q	33	H	50	y

For example, let's look at a practical example to deepen the impression! Pre-conversion 10101101 1011 1010 0111 0110 after conversion 00101011 00011011 00101001 1.1011 million binary 43 27 41 54 The value in the corresponding Code table R B p 2 so the above 24-bit encoding, the encoded BASE64 The value of RBP2 decoding the same, the RBQ2 bits connected to re-recombination to get three 8-bit value, the original code. (decoding is just the inverse of the code, I will not say more, and there is a lot of mime RFC, if you need more information, please find it yourself.) ) The first byte, which is processed according to the first byte of the source byte. Rule: The first byte of the source is shifted right by two bits, the low 2 bits are removed, and the high 2 bits are 0. Both: 00 + high 6 bits, two bytes, combined with the first byte of the source byte and the second byte. The rule is as follows, the first byte high 6 bits remove the left shift four bits, the second byte shifts right four bits namely: source first byte low 2 bits + source 2nd byte High 4 bits three bytes, according to the source byte second byte and the third byte Union processing, the rule second byte removes the high 4 bit and moves left two bits (high 6 bits), The third byte moves 6 bits to the right and removes the high 6 bits (2 bits lower), adds the fourth byte, the rule, the source third byte removes the high 2 bits according to the coding rules of Base64, every 76 characters need a line break//with a closer to programming thinking, the encoding process is this:// The first character gets the Base64 table position of the first target character by moving the 2-bit right, and the corresponding character on the table is taken as the first//target character. The first character is then shifted to the left 4 bits plus the second character aligns 4 bits, that is, the second target character is obtained. Move the second character left 2 bits plus the third word aligns 6 bits to get the third target character. The fourth target character is obtained when the right 6 bits of the third character are finally taken. After each of the above steps, and then the results with the 0x3F operation, you can get the encoded characters. But wait ... Smart you may ask, the original number of bytes should be a multiple of 3 ah, if the condition is not satisfied, then what to do? Our solution is this: the original text of the byte is not enough to complement the full, the conversion of Base64 code with the = number instead. This is why some Base64 encodings end with one or two equals signs, but the equals sign is only two. because: Remainder = original number of bytes MOD 3 so the remainder can only be one of the three 0,1,2 in any case. If the remainder is 0, it means that the original byte count is exactly a multiple of 3 (ideally). If it is 1, in order to let the BASE64 code is a multiple of 3, it is necessary to fill 2 equal signs; Similarly, if it is 2, it willFill 1 equal signs. edit this section of the application BASE64 encoding can be used to pass longer identity information in an HTTP environment. For example, in the Java Persistence System hibernate, Base64 is used to encode a long unique identifier (typically 128-bit uuid) as a string that is used as a parameter in an HTTP form and an HTTP GET URL. In other applications, it is often necessary to encode binary data as appropriate in the form of URLs (including hidden form fields). At this time, the adoption of BASE64 encoding is not only short, but also has the non-readability, that is, the encoded data will not be directly visible to the naked eye. However, the standard Base64 is not suitable for direct transmission in the URL, because the URL encoder will be in the standard Base64 "/" and "+" characters into the form of "%XX", and these "%" number in the database will need to be converted, because ANSI SQL has the "%" Used as a wildcard character. To solve this problem, an improved BASE64 encoding for URLs is used, which does not populate the ' = ' at the end and changes the "+" and "/" in standard Base64 to "*" and "-" respectively, thus eliminating the need for conversion in URL codec and database storage. Avoids the increase in the length of encoded information in this process, and unifies the format of object identifiers in databases, forms, and so on. There is also an improved BASE64 variant for regular expressions that changes "+" and "/" to "!" and "-", because "+", "*" and the "[" and "]" used in the preceding IRCU may have special meanings in regular expressions. There are also variants that change "+/" to "_-" or ". _" (used as an identifier name in a programming language) or ".-" (for NmToken in XML) or even "_:" (for name in XML). Other applications Mozilla Thunderbird and evolution use Base64 to secure email passwords Base64 also often used as a simple "encryption" to protect certain data, and real encryption is often cumbersome. Spammers use Base64 to circumvent anti-spam tools, because those tools don't usually translate Base64 messages. In the LDIF file, Base64 is used as the encoded string.edit this paragraph principle First Take "Thunder download" as an example: many download-type websites are provided "Thunder download" link, its address is usually encrypted thunderbolt dedicated. such as thunder://qufodhrwoi8vd3d3lmjhawr1lmnvbs9pbwcvc3nsbtffbg9nby5nawzawg== in fact, the "private address" is also used BASE64 encryption, its encryption process is as follows: First, Add AA and ZZ respectively before and after the address, such as http://www.baidu.com/img/sslm1_logo.gif into Aahttp://www.baidu.com/img/sslm1_logo.gifzz II, BASE64 encoding of new strings such as Aahttp://www.baidu.com/img/sslm1_ Logo.gifzz with Base64 code to get qufodhrwoi8vd3d3lmjhawr1lmnvbs9pbwcvc3nsbtffbg9nby5nawzawg== another: FlashGet and thunder similar, but in the first step when added "material "Different, FLASHGET in the address before and after adding the" material "is [FLASHGET] and QQ Whirlwind simply do not feed, directly on the address to Base64 codeedit this paragraph implementation [The following code is only implemented in GBK, UTF8 code please put if ($button = = "Thunderbolt address--General address") Echo substr (Base64_decode (Str_ireplace ("thunder://", "", $txt 1) ), 2,-2); This sentence is changed to if ($button = = "Thunderbolt address--General address") Echo substr (Mb_convert_encoding (Base64_decode (Str_ireplace ("thunder://", "", $ TXT1))), 2,-2); and change the charset=gb2312 to Charset=utf-8]<?php$txt1=trim ($_post[' Text1 '); $txt 2=trim ($_post[' text2 ']); $txt 3=trim ($_ post[' Text3 '); $button =$_post[' button '];? ><! DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 transitional//en" >

Base64 algorithm and MD5 encryption principle