Base64

Trong lập trình, Base64 là nhóm lược đồ mã hóa nhị phân thành văn bản đại diện cho dữ liệu nhị phân (cụ thể hơn là chuỗi byte 8 bit) ở định dạng chuỗi ASCII bằng việc dịch dữ liệu sang biểu diễn cơ số 64. Thuật ngữ Base64 bắt nguồn từ một mã hóa truyền nội dung MIME. Mỗi chữ số Base64 không phải là đại diện cuối cùng cho chính xác 6 bit dữ liệu. Do đó, ba byte 8 bit (24 bit) có thể được biểu diễn bằng bốn chữ số Base64 6 bit.

Thông thường tất cả các lược đồ mã hóa nhị phân thành văn bản, Base64 được thiết kế để mang dữ liệu được lưu trữ ở định dạng nhị phân qua các kênh chỉ hỗ trợ nội dung văn bản một cách đáng tin cậy. Base64 đặc biệt phổ biến trên World Wide Web^[1] trong đó các công dụng của nó bao gồm khả năng đính các tệp hình ảnh hoặc các nội dung nhị phân khác vào bên trong các nội dung văn bản như tệp HTML và CSS.^[2]

Base64 cũng được sử dụng rộng rãi để gửi các tệp đính kèm email. Điều này bắt buộc vì SMTP chỉ được thiết kế để vận chuyển các ký tự ASCII 7-bit. Chi phí phải trả cho mã hóa này là 33–36% (33% bởi chính mã hóa; thêm tối đa 3% do ngắt dòng được chèn).

Thiết kế

Bộ 64 ký tự cụ thể được chọn để đại diện cho các giá trị 64 chữ số cho cơ sở khác nhau giữa các lần triển khai. Chiến lược chung là chọn 64 ký tự phổ biến cho hầu hết các bảng mã và cũng có thể in được. Sự kết hợp này khiến dữ liệu khó có thể bị sửa đổi khi truyền qua các hệ thống thông tin, chẳng hạn như email, theo truyền thống không phải là 8-bit clean.^[3] Ví dụ, triển khai Base64 của MIME, ta sử dụng A-Z, a-z, và 0-9 cho 62 giá trị đầu tiên. Các biến thể khác chia sẻ thuộc tính này nhưng khác nhau về các ký hiệu được chọn cho hai giá trị cuối cùng; một ví dụ là UTF-7.

Các trường hợp sớm nhất của kiểu mã hóa này được tạo ra để liên lạc quay số giữa các hệ thống chạy cùng một hệ điều hành. Ví dụ: uuencode cho UNIX và BinHex cho TRS-80 (sau này được điều chỉnh cho Macintosh), và do đó có thể đưa ra nhiều giả định hơn về những ký tự nào an toàn để sử dụng. Ví dụ: uuencode sử dụng chữ hoa, chữ số và nhiều ký tự dấu câu, nhưng không sử dụng chữ thường.^[3]^[4]^[5]^[6]

Bảng Base64

Bảng mục lục các ký tự của Base64:

STT	Nhị phân	Đầu ra	STT	Nhị phân	Đầu ra	STT	Nhị phân	Đầu ra	STT	Nhị phân	Đầu ra
0	000000	`A`	16	010000	`Q`	32	100000	`g`	48	110000	`w`
1	000001	`B`	17	010001	`R`	33	100001	`h`	49	110001	`x`
2	000010	`C`	18	010010	`S`	34	100010	`i`	50	110010	`y`
3	000011	`D`	19	010011	`T`	35	100011	`j`	51	110011	`z`
4	000100	`E`	20	010100	`U`	36	100100	`k`	52	110100	`0`
5	000101	`F`	21	010101	`V`	37	100101	`l`	53	110101	`1`
6	000110	`G`	22	010110	`W`	38	100110	`m`	54	110110	`2`
7	000111	`H`	23	010111	`X`	39	100111	`n`	55	110111	`3`
8	001000	`I`	24	011000	`Y`	40	101000	`o`	56	111000	`4`
9	001001	`J`	25	011001	`Z`	41	101001	`p`	57	111001	`5`
10	001010	`K`	26	011010	`a`	42	101010	`q`	58	111010	`6`
11	001011	`L`	27	011011	`b`	43	101011	`r`	59	111011	`7`
12	001100	`M`	28	011100	`c`	44	101100	`s`	60	111100	`8`
13	001101	`N`	29	011101	`d`	45	101101	`t`	61	111101	`9`
14	001110	`O`	30	011110	`e`	46	101110	`u`	62	111110	`+`
15	001111	`P`	31	011111	`f`	47	101111	`v`	63	111111	`/`
Đệm		=

Ví dụ

Ví dụ dưới đây sử dụng văn bản ASCII để đơn giản hóa, nhưng đây không phải là trường hợp sử dụng điển hình vì nó đã có thể được chuyển một cách an toàn qua tất cả các hệ thống có thể xử lý Base64. Việc sử dụng điển hình hơn là mã hóa dữ liệu nhị phân (chẳng hạn như hình ảnh); dữ liệu Base64 kết quả sẽ chỉ chứa 64 ký tự ASCII khác nhau, tất cả đều có thể được chuyển qua các hệ thống một cách đáng tin cậy có thể làm hỏng các byte nguồn thô.

Đây là một thành ngữ nổi tiếng từ Điện toán "phân tán":

Many hands make light work. (Nhiều tay làm việc nhẹ)

Khi trích dẫn được mã hóa thành Base64, nó được biểu diễn dưới dạng chuỗi byte gồm các ký tự ASCII có đệm 8 bit được mã hóa trong lược đồ Base64 của MIME như sau (dòng mới và khoảng trắng có thể xuất hiện ở bất kỳ đâu nhưng sẽ bị bỏ qua khi giải mã):

TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu

Trong phần trích dẫn trên, giá trị được mã hóa của Man là TWFu. Được mã hóa bằng ASCII, các ký tự M, a và n được lưu trữ dưới dạng giá trị byte 77, 97, và 110, là giá trị nhị phân 8 bit của 01001101, 01100001,và 01101110. Ba giá trị này được nối với nhau thành một chuỗi 24 bit, tạo ra 010011010110000101101110. Các nhóm gồm 6 bit (6 bit có tối đa 2⁶ = 64 giá trị nhị phân khác nhau) được chuyển đổi thành các số riêng lẻ từ trái sang phải (trong trường hợp này, có bốn số trong một chuỗi 24 bit), sau đó được chuyển đổi thành giá trị ký tự Base64 tương ứng.

Như ví dụ này minh họa, mã hóa Base64 chuyển đổi ba octet thành bốn ký tự được mã hóa.

Nguồn	Văn bản (ASCII)	M								a								n
Nguồn	Octet	77 (0x4d)								97 (0x61)								110 (0x6e)
Bit		0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	1	1	0	1	1	1	0
Base64 được mã hóa	Sextet	19						22						5						46
	Ký tự	T						W						F						u
	Octet	84 (0x54)						87 (0x57)						70 (0x46)						117 (0x75)

= các ký tự đệm có thể được thêm vào để làm cho khối được mã hóa cuối cùng chứa bốn ký tự Base64.

Phép chuyển đổi hệ thập lục phân sang hệ bát phân rất hữu ích để chuyển đổi giữa hệ nhị phân và Base64. Cả đối với máy tính nâng cao và ngôn ngữ lập trình, chuyển đổi như vậy đều có sẵn. Ví dụ: 24 bit ở trên - khi được chuyển đổi sang hệ thập lục phân - là 4D616E. 24 bit đó - khi được chuyển đổi thành bát phân là 23260556. 8 chữ số bát phân đó - khi được chia thành bốn nhóm là 23 26 05 56. Mỗi nhóm 2 chữ số - khi chuyển đổi sang thập phân là 19 22 05 46. Sử dụng bốn số thập phân đó số làm chỉ số cho bảng chỉ mục Base64, các ký tự ASCII tương ứng là TWFu.

Nếu chỉ có hai octet đầu vào quan trọng (ví dụ: 'Ma') hoặc khi nhóm đầu vào cuối cùng chỉ chứa hai octet, tất cả 16 bit sẽ được ghi lại trong ba chữ số Base64 đầu tiên (18 bit); hai bit ít quan trọng nhất của khối 6 bit mang nội dung cuối cùng sẽ trở thành 0 và bị loại bỏ khi giải mã (cùng với = ký tự đệm):

Nguồn	Văn bản (ASCII)	M								a
Nguồn	Octet	77 (0x4d)								97 (0x61)
Bit		0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	0
Base64 được mã hóa	Sextet	19						22						4						Đệm
	Ký tự	T						W						E						=
	Octet	84 (0x54)						87 (0x57)						69 (0x45)						61 (0x3D)

Nếu chỉ có một octet đầu vào có nghĩa (ví dụ: 'M') hoặc trong đó hai chữ số Base64 đầu tiên (12 bit); bốn bit ít quan trọng nhất của khối 6 bit mang nội dung cuối cùng sẽ trở thành 0 và bị loại bỏ khi giải mã (cùng với hai = ký tự đệm):

Nguồn	Văn bản (ASCII)	M
Nguồn	Octet	77 (0x4d)
Bits		0	1	0	0	1	1	0	1	0	0	0	0
Base64 được mã hóa	Sextet	19						16						Đệm	Đệm
	Ký tự	T						Q						=	=
	Octet	84 (0x54)						81 (0x51)						61 (0x3D)	61 (0x3D)

Đệm đầu ra

Bởi vì Base64 là mã hóa sáu bit và vì các giá trị được giải mã được chia thành các bộ tám 8 bit trên máy tính hiện đại, nên cứ bốn ký tự của văn bản được mã hóa Base64 (4 sextet = 4 × 6 = 24 bit) đại diện cho ba bộ tám chưa được mã hóa văn bản hoặc dữ liệu (3 octet = 3 × 8 = 24 bit). Điều này có nghĩa là khi độ dài của đầu vào không được mã hóa không phải là bội số của ba, thì đầu ra được mã hóa phải được thêm phần đệm để chiều dài của nó là bội số của bốn. Ký tự đệm là =, cho biết rằng không cần thêm bit nào để mã hóa đầy đủ đầu vào. (Điều này khác với A, có nghĩa là các bit còn lại đều là số không.) Ví dụ dưới đây minh họa cách cắt bớt đầu vào của câu trích dẫn trên thay đổi phần đệm đầu ra:

Đầu vào		Đầu ra		Đệm
Văn bản	Độ dài	Văn bản	Độ dài	Đệm
light work.	11	bGlnaHQgd29yay4=	16	1
light work	10	bGlnaHQgd29yaw==	16	2
light wor	9	bGlnaHQgd29y	12	0
light wo	8	bGlnaHQgd28=	12	1
light w	7	bGlnaHQgdw==	12	2

Ký tự đệm không cần thiết để giải mã, vì số byte bị thiếu có thể được suy ra từ độ dài của văn bản được mã hóa. Trong một số triển khai, ký tự đệm là bắt buộc, trong khi đối với những cách khác, ký tự này không được sử dụng. Một ngoại lệ trong đó các ký tự đệm là bắt buộc khi nhiều tệp được mã hóa Base64 đã được nối với nhau.

Giải mã Base64 với ký tự đệm

Khi giải mã văn bản Base64, bốn ký tự thường được chuyển đổi trở lại thành ba byte. Các ngoại lệ duy nhất là khi các ký tự đệm tồn tại. Một = chỉ ra rằng bốn ký tự sẽ chỉ giải mã thành hai byte, trong khi == chỉ ra rằng bốn ký tự sẽ chỉ giải mã thành một byte duy nhất. Ví dụ:

Được mã hóa	Đệm	Độ dài	Được giải mã
bGlnaHQgdw==	`==`	1	light w
bGlnaHQgd28=	`=`	2	light wo
bGlnaHQgd29y	None	3	light wor

Giải mã Base64 không có ký tự đệm

Nếu không có phần đệm, sau khi giải mã bình thường từ bốn ký tự đến ba byte lặp đi lặp lại, có thể còn lại ít hơn bốn ký tự được mã hóa. Trong tình huống này, chỉ có thể còn lại hai hoặc ba ký tự. Một ký tự được mã hóa còn lại là không thể thực hiện được vì một ký tự Base64 chỉ chứa 6 bit và 8 bit được yêu cầu để tạo một byte, vì vậy cần có tối thiểu hai ký tự Base64: Ký tự đầu tiên đóng góp 6 bit và ký tự thứ hai đóng góp 2 bit đầu tiên của nó. Ví dụ:

Độ dài	Được mã hóa	Độ dài	Được giải mã
2	bGlnaHQgdw	1	light w
3	bGlnaHQgd28	2	light wo
4	bGlnaHQgd29y	3	light wor

Phát triển và lịch sử

Bảng tóm tắt các biến thể

Việc triển khai có thể có một số ràng buộc đối với bảng chữ cái được sử dụng để biểu diễn một số mẫu bit. Điều này đáng chú ý liên quan đến hai ký tự cuối cùng được sử dụng trong bảng chỉ mục cho chỉ mục 62 và 63 và ký tự được sử dụng để đệm (có thể là bắt buộc trong một số giao thức hoặc bị loại bỏ trong các giao thức khác). Bảng dưới đây tóm tắt các biến thể đã biết này và cung cấp liên kết đến các phần phụ bên dưới.

Mã hóa	Các ký tự mã hóa			Các dòng mã hóa riêng biệt			Giải mã các ký tự không mã hóa
Mã hóa	62nd	63rd	đệm	Dấu phân cách	Độ dài	Checksum	Giải mã các ký tự không mã hóa
RFC 1421: Base64 cho Privacy-Enhanced Mail (không còn dùng nữa)	`+`	`/`	`=` bắt buộc	CR+LF	64, hoặc ít hơn cho dòng cuối cùng	Không	Không
RFC 2045: Base64 chuyển mã hóa cho MIME	`+`	`/`	`=` bắt buộc	CR+LF	nhiều nhất là 76	Không	Bị loại bỏ
RFC 2152: Base64 cho UTF-7	`+`	`/`	Không	Không			Không
RFC 3501: Base64 mã hóa cho tên hộp thư IMAP	`+`	`,`	Không	Không			Không
RFC 4648 §4: base64 (bản tiêu chuẩn)^[a]	`+`	`/`	`=` không bắt buộc	Không			Không
RFC 4648 §5: base64url (URL - và tiêu chuẩn an toàn cho tên tệp)^[a]	`-`	`_`	`=` không bắt buộc	Không			Không
RFC 4880: Radix-64 cho OpenPGP	`+`	`/`	`=` bắt buộc	CR+LF	nhiều nhất là 76	{{Optionalss số 64 được mã hóa 24-bit CRC}}	Không

Thư nâng cao quyền riêng tư

Việc sử dụng mã hóa chuẩn hóa đầu tiên được biết đến hiện nay được gọi là MIME Base64 nằm trong giao thức Thư điện tử nâng cao quyền riêng tư (PEM), được đề xuất bởi RFC 989 vào năm 1987. PEM định nghĩa một lược đồ "mã hóa có thể in" sử dụng mã hóa Base64 để biến đổi một chuỗi octet tùy ý sang một định dạng có thể được thể hiện bằng các dòng ngắn gồm các ký tự 6 bit, theo yêu cầu của các giao thức truyền như SMTP.^[7]

Phiên bản hiện tại của PEM (được chỉ định trong RFC 1421) sử dụng bảng chữ cái 64 ký tự bao gồm các chữ cái La Mã viết hoa và viết thường (A–Z, a–z), các chữ số (0–9), và các ký tự + và / . Ký tự = cũng được sử dụng như một hậu tố đệm.^[4] Đặc điểm kĩ thuật gốc, RFC 989, cũng đã sử dụng ký tự * để phân tách dữ liệu được mã hóa nhưng chưa được mã hóa trong luồng đầu ra.

Để chuyển đổi dữ liệu sang mã hóa có thể in PEM, byte đầu tiên được đặt trong 8 bit quan trọng nhất của bộ đệm 24 bit, byte tiếp theo trong 8 bit ở giữa và byte thứ ba trong tám bit ít quan trọng nhất. Nếu còn lại ít hơn 3 byte để mã hóa (hoặc tổng số), các bit đệm còn lại sẽ bằng không. Sau đó, bộ đệm được sử dụng, 6 bit tại một thời điểm, quan trọng nhất trước tiên, làm chỉ số cho chuỗi: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", và ký tự được chỉ định là đầu ra.

Quá trình được lặp lại trên dữ liệu còn lại cho đến khi còn lại ít hơn 4 octet. Nếu 3 octet vẫn còn, chúng được xử lý bình thường. Nếu còn lại ít hơn 3 octet (24 bit) để mã hóa, dữ liệu đầu vào sẽ được đệm bên phải với các bit 0 để tạo thành bội số tích phân của 6 bit.

Sau khi mã hóa dữ liệu không đệm, nếu 2 octet của bộ đệm 24 bit là số không có đệm, hai ký tự = được thêm vào đầu ra; nếu 1 octet của bộ đệm 24 bit được lấp đầy bởi các số không có đệm, một ký tự = được thêm vào. Điều này báo hiệu cho bộ giải mã rằng các bit 0 được thêm vào do đệm phải được loại trừ khỏi dữ liệu được tái tạo. Điều này cũng đảm bảo rằng độ dài đầu ra được mã hóa là bội số của 4 byte.

PEM yêu cầu tất cả các dòng được mã hóa bao gồm chính xác 64 ký tự có thể in được, ngoại trừ dòng cuối cùng, có thể chứa ít ký tự có thể in hơn. Các dòng được phân cách bằng các ký tự khoảng trắng theo quy ước cục bộ (dành riêng cho nền tảng).

MIME

Đặc điểm kỹ thuật MIME (Tiện ích mở rộng thư Internet đa năng) liệt kê Base64 là một trong hai lược đồ mã hóa nhị phân thành văn bản (lược đồ kia được trích dẫn-in được).^[5] Mã hóa Base64 của MIME dựa trên mã hóa phiên bản RFC 1421 của PEM: nó sử dụng cùng một bảng chữ cái 64 ký tự và cơ chế mã hóa như PEM và sử dụng ký tự =cho phần đệm đầu ra theo cách tương tự, như được mô tả tại RFC 2045.

MIME không chỉ định độ dài cố định cho các dòng được mã hóa Base64, nhưng nó chỉ định độ dài dòng tối đa là 76 ký tự. Ngoài ra, nó chỉ định rằng bất kỳ ký tự ngoài bảng chữ cái nào phải được bộ giải mã tuân thủ bỏ qua, mặc dù hầu hết các triển khai đều sử dụng cặp dòng mới CR/LF để phân tách các dòng được mã hóa.

Do đó, độ dài thực tế của dữ liệu nhị phân được mã hóa Base64 tuân thủ MIME thường bằng khoảng 137% độ dài dữ liệu gốc, mặc dù đối với các tin nhắn rất ngắn, chi phí có thể cao hơn nhiều do chi phí của các tiêu đề. Rất đại khái, kích thước cuối cùng của dữ liệu nhị phân được mã hóa Base64 bằng 1,37 lần kích thước dữ liệu gốc + 814 byte (đối với tiêu đề). Kích thước của dữ liệu được giải mã có thể được tính gần đúng với công thức sau:

bytes = (string_length(encoded_string) - 814) / 1.37

UTF-7

UTF-7, được mô tả đầu tiên trong RFC 1642, mà sau đó đã được thay thế bởi RFC 2152, đã giới thiệu một hệ thống được gọi là Base64 đã được sửa đổi. Lược đồ mã hóa dữ liệu này được sử dụng để mã hóa UTF-16 dưới dạng ký tự ASCII để sử dụng trong truyền tải 7 bit như SMTP. Nó là một biến thể của mã hóa Base64 được sử dụng trong MIME.^[8]^[9]

Bảng chữ cái "Modified Base64" bao gồm bảng chữ cái MIME Base64 nhưng không sử dụng ký tự đệm "=". UTF-7 được thiết kế để sử dụng trong tiêu đề thư (được định nghĩa trong RFC 2047),và ký tự "=" là được dành riêng trong ngữ cảnh đó làm ký tự thoát cho mã hóa "có thể in được trích dẫn". Base64 được sửa đổi chỉ cần bỏ qua phần đệm và kết thúc ngay sau chữ số Base64 cuối cùng chứa các bit hữu ích để lại tối đa ba bit không sử dụng trong chữ số Base64 cuối cùng.

OpenPGP

OpenPGP, được dựa trên RFC 4880, mô tả mã hóa Radix-64, còn được gọi là "ASCII armor". Radix-64 giống với kiểu mã hóa "Base64" được mô tả từ MIME, với việc bổ sung CRC 24 bit tùy chọn. Tổng kiểm tra được tính toán trên dữ liệu đầu vào trước khi mã hóa; sau đó tổng kiểm tra được mã hóa bằng cùng một thuật toán Base64 và tiền tố là ký tự "=" như một dấu phân cách, được nối vào dữ liệu đầu ra được mã hóa.^[10]

RFC 3548

RFC 3548, có thể Mã hóa dữ liệu Base16, Base32 và Base64 là một bản ghi nhớ thông tin (không quy chuẩn) cố gắng thống nhất RFC 1421 và RFC 2045 thông số kỹ thuật của mã hóa Base64, mã hóa bảng chữ cái thay thế và mã hóa Base32 (hiếm khi được sử dụng) và Base16.

Trừ khi các triển khai được viết cho một thông số kỹ thuật đề cập đến RFC 3548 và đặc biệt yêu cầu khác, RFC 3548 cấm việc triển khai tạo thông báo có chứa các ký tự bên ngoài bảng chữ cái mã hóa hoặc không có phần đệm và nó cũng tuyên bố rằng việc triển khai bộ giải mã phải từ chối dữ liệu có chứa các ký tự bên ngoài bảng chữ cái mã hóa.^[6]

RFC 4648

RFC này bị lỗi thời RFC 3548 và tập trung vào Base64/32/16:

Tài liệu này mô tả các lược đồ mã hóa Base64, Base32 và Base16 thường được sử dụng. Nó cũng thảo luận về việc sử dụng nguồn cấp dữ liệu dòng trong dữ liệu được mã hóa, sử dụng khoảng đệm trong dữ liệu được mã hóa, sử dụng các ký tự không phải bảng chữ cái trong dữ liệu được mã hóa, sử dụng các bảng chữ cái mã hóa khác nhau và mã hóa chuẩn.

Các ứng dụng URL

Mã hóa Base64 có thể hữu ích khi thông tin nhận dạng khá dài được sử dụng trong môi trường HTTP. Ví dụ: một khung bền vững cơ sở dữ liệu cho các đối tượng Java có thể sử dụng mã hóa Base64 để mã hóa một id duy nhất tương đối lớn (thường là UUID 128 bit) thành một chuỗi để sử dụng làm tham số HTTP trong các biểu mẫu HTTP hoặc URL HTTP GET. Ngoài ra, nhiều ứng dụng cần mã hóa dữ liệu nhị phân theo cách thuận tiện để đưa vào URL, bao gồm cả trong các trường biểu mẫu web ẩn và Base64 là cách mã hóa thuận tiện để hiển thị chúng một cách nhỏ gọn.

Sử dụng Base64 tiêu chuẩn trong URL yêu cầu mã hóa các ký tự +, / và = thành chuỗi thập lục phân được mã hóa theo phần trăm đặc biệt (+ trở thành %2B, /trở thành %2F và = trở thành %3D), điều này làm cho chuỗi dài hơn một cách không cần thiết.

Vì lý do này, Base64 đã sửa đổi cho các biến thể URL (chẳng hạn như base64url trong RFC 4648), trong đó các ký tự + và / của Base64 tiêu chuẩn được thay thế tương ứng bởi - và _, để việc sử dụng bộ mã hóa/giải mã URL không còn cần thiết và không ảnh hưởng đến độ dài của giá trị được mã hóa, giữ nguyên dạng được mã hóa tương tự để sử dụng trong cơ sở dữ liệu quan hệ, biểu mẫu web và mã định danh đối tượng nói chung. Một số biến thể cho phép hoặc yêu cầu bỏ qua phần đệm = để tránh chúng bị nhầm lẫn với dấu phân cách trường hoặc yêu cầu bất kỳ phần đệm nào như vậy phải được mã hóa theo phần trăm. Một số thư viện ^{[cái gì?]} sã mã hóa = thành ., có khả năng khiến các ứng dụng bị tấn công theo đường dẫn tương đối khi tên thư mục được mã hóa từ dữ liệu người dùng.

HTML

Các phương thức JavaScript atob() và btoa() được xác định trong bản thảo HTML5,^[11] cung cấp chức năng mã hóa và giải mã Base64 cho các trang web. Phương thức btoa() xuất ra các ký tự đệm, nhưng các ký tự này là tùy chọn trong đầu vào của phương thức atob().

Các ứng dụng khác

Base64 có thể được sử dụng trong nhiều ngữ cảnh khác nhau:

Base64 có thể được sử dụng để truyền và lưu trữ văn bản có thể gây ra xung đột dấu phân cách.
Những kẻ gửi thư rác sử dụng Base64 để trốn tránh các công cụ chống gửi thư rác cơ bản, những công cụ này thường không giải mã được Base64 và do đó không thể phát hiện ra các từ khóa trong các thư được mã hóa.
Base64 được sử dụng để mã hóa chuỗi ký tự trong tệp LDIF.
Base64 thường được sử dụng để "nhúng" dữ liệu nhị phân vào tệp XML, sử dụng cú pháp tương tự như <data encoding="base64">…</data> ví dụ. biểu tượng yêu thích trong Firefox xuất ra bookmarks.html.
Base64 được sử dụng để mã hóa các tệp nhị phân chẳng hạn như hình ảnh trong các tập lệnh, để tránh phụ thuộc vào các tệp bên ngoài.
Lược đồ URI dữ liệu có thể sử dụng Base64 để biểu diễn nội dung tệp. Ví dụ: hình nền và phông chữ có thể được chỉ định trong tệp biểu định kiểu CSS dưới dạng URIs data:, thay vì được cung cấp trong các tệp riêng biệt.
Việc triển khai FreeSWAN IPSec đứng trước chuỗi Base64 bằng 0s, vì vậy chúng có thể được phân biệt với chuỗi văn bản hoặc chuỗi thập lục phân. ^{[cần dẫn nguồn]}
Mặc dù không phải là một phần của thông số kỹ thuật chính thức cho SVG, một số người xem có thể hiểu Base64 khi được sử dụng cho các phần tử "nhúng", chẳng hạn như hình ảnh bên trong SVG.^[13]

Các ứng dụng Radix-64 không tương thích với Base64

Uuencoding, tthường được sử dụng trên UNIX, sử dụng ASCII 32 liên tiếp ( (khoảng trống)) đến 95 (_), tạo thành bộ 64 ký tự !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_. Việc tránh sử dụng tất cả các chữ cái viết thường rất hữu ích vì nhiều máy in cũ chỉ in chữ hoa. Sử dụng các ký tự ASCII liên tiếp giúp tiết kiệm sức mạnh tính toán vì chỉ cần thêm 32 ký tự, không phải tra cứu. Việc sử dụng hầu hết các ký tự dấu câu và ký tự khoảng trắng làm hạn chế tính hữu dụng của nó.^{[cần dẫn nguồn]}
BinHex 4 (HQX), vốn được sử dụng trong Mac OS cổ điển, sử dụng một bộ 64 ký tự khác. Nó sử dụng các chữ cái viết hoa và viết thường, các chữ số và các ký tự chấm câu, nhưng không sử dụng một số ký tự dễ gây nhầm lẫn trực quan như 7, O, g và o'. Bộ 64 ký tự của nó là !"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr.
Một số ứng dụng khác sử dụng các bộ cơ số 64 tương tự hơn nhưng theo thứ tự khác với định dạng Base64, bắt đầu bằng hai ký hiệu, sau đó là chữ số, sau đó viết hoa, rồi viết thường:
- Unix lưu trữ các băm mật khẩu được tính bằng crypt trong tệp /etc/passwd sử dụng mã hóa cơ số 64 được gọi là B64. Nó sử dụng một bộ ký tự chủ yếu là chữ và số, có thêm . và /. Bộ 64 ký tự của nó là ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz. Ký tự đệm không được sử dụng.
- GEDCOM 5.5 tiêu chuẩn được dùng để trao đổi dữ liệu phả hệ mã hóa các tệp đa phương tiện ở định dạng tệp phân cấp dòng văn bản bằng cách sử dụng cơ số 64. Bộ 64 ký tự của nó cũng là "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".^[14]
- bcrypt được thiết kế để sử dụng theo cách tương tự như crypt (3) truyền thống và thuật toán sử dụng một bảng chữ cái tương tự nhưng được hoán vị. Bộ 64 ký tự của nó là ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.^[15]
- Xxencoding sử dụng bộ ký tự chủ yếu là chữ và số tương tự như crypt và GEDCOM, nhưng sử dụng + và - còn hơn là sử dụng . và /. Bộ 64 ký tự của nó là +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.
- 6PACK, được sử dụng với một số bộ điều khiển nút đầu cuối, sử dụng một bộ 64 ký tự khác nhau từ 0x00 đến 0x3f.^[16]
- Bash hỗ trợ các ký tự số trong cơ số 2-64, kéo dài đến một bộ ký tự của 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_.^[17]

Ghi chú

^ ^a ^b It is important to note that this variant is intended to provide common features where they are not desired to be specialised by implementations, ensuring robust engineering. This is particularly in light of separate line encodings and restrictions, which have not been considered when previous standards have been co-opted for use elsewhere. Thus, the features indicated here may be over-ridden.

Xem thêm

8BITMIME
Ascii85 (thường được gọi là Base85).
Base16
Base32
Base36
Base62
Binary-to-text encoding để sử dụng cho các thuật toán mã hóa khác nhau.
Binary number
URL

Tham khảo

^ “Base64 encoding and decoding - Web APIs | MDN”.
^ “When to base64 encode images (and when not to)”.
^ ^a ^b The Base16,Base32,and Base64 Data Encodings. IETF. October 2006. RFC 4648. https://tools.ietf.org/html/rfc4648. Truy cập March 18, 2010.
^ ^a ^b Privacy Enhancement for InternetElectronic Mail: Part I: Message Encryption and Authentication Procedures. IETF. February 1993. RFC 1421. https://tools.ietf.org/html/rfc1421. Truy cập March 18, 2010.
^ ^a ^b Multipurpose Internet Mail Extensions: (MIME) Part One: Format of Internet Message Bodies. IETF. November 1996. RFC 2045. https://tools.ietf.org/html/rfc2045. Truy cập March 18, 2010.
^ ^a ^b The Base16, Base32, and Base64 Data Encodings. IETF. July 2003. RFC 3548. https://tools.ietf.org/html/rfc3548. Truy cập March 18, 2010.
^ Privacy Enhancement for Internet Electronic Mail. IETF. February 1987. RFC 989. https://tools.ietf.org/html/rfc989. Truy cập March 18, 2010.
^ UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. July 1994. RFC 1642. https://tools.ietf.org/html/rfc1642. Truy cập March 18, 2010.
^ UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. May 1997. RFC 2152. https://tools.ietf.org/html/rfc2152. Truy cập March 18, 2010.
^ OpenPGP Message Format. IETF. November 2007. RFC 4880. https://tools.ietf.org/html/rfc4880. Truy cập March 18, 2010.
^ “7.3. Base64 utility methods”. HTML 5.2 Editor's Draft. World Wide Web Consortium. Truy cập ngày 2 tháng 1 năm 2018. Introduced by changeset 5814, 2021-02-01.
^ <image xlink:href="data:image/jpeg;base64,JPEG contents encoded in Base64" ... />
^ “Edit fiddle”. jsfiddle.net.
^ “The GEDCOM Standard Release 5.5”. Homepages.rootsweb.ancestry.com. Truy cập ngày 21 tháng 6 năm 2012.
^ Provos, Niels (13 tháng 2 năm 1997). “src/lib/libc/crypt/bcrypt.c r1.1”. Truy cập ngày 18 tháng 5 năm 2018.
^ “6PACK a "real time" PC to TNC protocol”. Bản gốc lưu trữ ngày 24 tháng 2 năm 2012. Truy cập ngày 19 tháng 5 năm 2013.
^ “Shell Arithmetic”. Bash Reference Manual. Truy cập ngày 8 tháng 4 năm 2020. Otherwise, numbers take the form [base#]n, where the optional base is a decimal number between 2 and 64 representing the arithmetic base, and n is a number in that base.

Liên kết ngoài

https://codebeautify.org/base64-encode

[common-7] It is important to note that this variant is intended to provide common features where they are not desired to be specialised by implementations, ensuring robust engineering. This is particularly in light of separate line encodings and restrictions, which have not been considered when previous standards have been co-opted for use elsewhere. Thus, the features indicated here may be over-ridden.

[1] “Base64 encoding and decoding - Web APIs | MDN”.

[2] “When to base64 encode images (and when not to)”.

[autogenerated2006-3] The Base16,Base32,and Base64 Data Encodings. IETF. October 2006. RFC 4648. https://tools.ietf.org/html/rfc4648. Truy cập March 18, 2010.

[rfc_1421-4] Privacy Enhancement for InternetElectronic Mail: Part I: Message Encryption and Authentication Procedures. IETF. February 1993. RFC 1421. https://tools.ietf.org/html/rfc1421. Truy cập March 18, 2010.

[rfc_2045-5] Multipurpose Internet Mail Extensions: (MIME) Part One: Format of Internet Message Bodies. IETF. November 1996. RFC 2045. https://tools.ietf.org/html/rfc2045. Truy cập March 18, 2010.

[rfc_3548-6] The Base16, Base32, and Base64 Data Encodings. IETF. July 2003. RFC 3548. https://tools.ietf.org/html/rfc3548. Truy cập March 18, 2010.

[8] Privacy Enhancement for Internet Electronic Mail. IETF. February 1987. RFC 989. https://tools.ietf.org/html/rfc989. Truy cập March 18, 2010.

[9] UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. July 1994. RFC 1642. https://tools.ietf.org/html/rfc1642. Truy cập March 18, 2010.

[10] UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. May 1997. RFC 2152. https://tools.ietf.org/html/rfc2152. Truy cập March 18, 2010.

[11] OpenPGP Message Format. IETF. November 2007. RFC 4880. https://tools.ietf.org/html/rfc4880. Truy cập March 18, 2010.

[12] “7.3. Base64 utility methods”. HTML 5.2 Editor's Draft. World Wide Web Consortium. Truy cập ngày 2 tháng 1 năm 2018. Introduced by changeset 5814, 2021-02-01.

[13] <image xlink:href="data:image/jpeg;base64,JPEG contents encoded in Base64" ... />

[14] “Edit fiddle”. jsfiddle.net.

[15] “The GEDCOM Standard Release 5.5”. Homepages.rootsweb.ancestry.com. Truy cập ngày 21 tháng 6 năm 2012.

[16] Provos, Niels (13 tháng 2 năm 1997). “src/lib/libc/crypt/bcrypt.c r1.1”. Truy cập ngày 18 tháng 5 năm 2018.

[17] “6PACK a "real time" PC to TNC protocol”. Bản gốc lưu trữ ngày 24 tháng 2 năm 2012. Truy cập ngày 19 tháng 5 năm 2013.

[18] “Shell Arithmetic”. Bash Reference Manual. Truy cập ngày 8 tháng 4 năm 2020. Otherwise, numbers take the form [base#]n, where the optional base is a decimal number between 2 and 64 representing the arithmetic base, and n is a number in that base.

[1]

[2]

[3]

[4]

[5]

[6]

[a]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]