Base64 – Wikipedia tiếng Việt

Group of binary-to-text encoding schemes using 64 symbols ( plus padding )

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ổng thể những lược đồ mã hóa nhị phân thành văn bản, Base64 được phong cách thiết kế để mang tài liệu được tàng trữ ở định dạng nhị phân qua những kênh chỉ tương hỗ nội dung văn bản một cách đáng đáng tin cậy. Base64 đặc biệt quan trọng thông dụng trên World Wide Web [ 1 ] trong đó những tác dụng của nó gồm có năng lực đính những tệp hình ảnh hoặc những nội dung nhị phân khác vào bên trong những 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).

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 AZ, az, và 09 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 những mạng lưới hệ thống chạy cùng một hệ quản lý. Ví dụ : uuencode cho UNIX và BinHex cho TRS-80 ( sau này được kiểm soát và điều chỉnh cho Macintosh ), và do đó hoàn toàn có thể đưa ra nhiều giả định hơn về những ký tự nào bảo đảm 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 mục lục những 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ụ 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 nổi bật vì nó đã hoàn toàn có thể được chuyển một cách bảo đảm an toàn qua tổng thể những mạng lưới hệ thống hoàn toàn có thể giải quyết và xử lý Base64. Việc sử dụng nổi bật hơn là mã hóa tài liệu nhị phân ( ví dụ điển hình như hình ảnh ) ; tài liệu Base64 hiệu quả sẽ chỉ chứa 64 ký tự ASCII khác nhau, toàn bộ đều hoàn toàn có thể được chuyển qua những mạng lưới hệ thống một cách đáng đáng tin cậy hoàn toàn có thể làm hỏng những byte nguồn thô .Đây là một thành ngữ nổi tiếng từ máy tính ” phân tán ” :Many hands make light work. ( Nhiều tay thao tác nhẹ )
Khi trích dẫn được mã hóa thành Base64, nó được màn biểu diễn dưới dạng chuỗi byte gồm những 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 chừng trắng hoàn toàn có thể Open ở bất kể đâu nhưng sẽ bị bỏ lỡ khi giải thuật ) :

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 26 = 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
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
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
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[sửa|sửa mã nguồn]

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
light work . 11

bGlnaHQgd29yay4 =

16 1
light work 10

bGlnaHQgd29yaw = =

16 2
light wor 9

bGlnaHQg

d29y

12 0
light wo 8

bGlnaHQgd28 =

12 1
light w 7

bGlnaHQgdw = =

12 2

Ký tự đệm không thiết yếu để giải thuật, vì số byte bị thiếu hoàn toàn có thể được suy ra từ độ dài của văn bản được mã hóa. Trong một số ít tiến hành, ký tự đệm là bắt buộc, trong khi so với những cách khác, ký tự này không được sử dụng. Một ngoại lệ trong đó những 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[sửa|sửa mã nguồn]

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[sửa|sửa mã nguồn]

Nếu không có phần đệm, sau khi giải thuật thông thường từ bốn ký tự đến ba byte lặp đi lặp lại, hoàn toàn có thể còn lại ít hơn bốn ký tự được mã hóa. Trong trường hợp này, chỉ hoàn toàn 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 hề triển khai được vì một ký tự Base64 chỉ chứa 6 bit và 8 bit được nhu yếu để tạo một byte, vì thế cần có tối thiểu hai ký tự Base64 : Ký tự tiên phong góp phần 6 bit và ký tự thứ hai góp phần 2 bit tiên phong 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ử vẻ vang[sửa|sửa mã nguồn]

Bảng tóm tắt những biến thể[sửa|sửa mã nguồn]

Việc tiến hành hoàn toàn có thể có một số ít ràng buộc so với bảng vần âm được sử dụng để màn biểu diễn một số ít mẫu bit. Điều này đáng quan tâm tương quan đến hai ký tự sau cuối đượ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 ( hoàn toàn có thể là bắt buộc trong 1 số ít giao thức hoặc bị vô hiệu trong những giao thức khác ). Bảng dưới đây tóm tắt những biến thể đã biết này và cung ứng link đến những phần phụ bên dưới .

Thư nâng cao quyền riêng tư[sửa|sửa mã nguồn]

Việc sử dụng mã hóa chuẩn hóa tiên phong được biết đến lúc bấy giờ được gọi là MIME Base64 nằm trong giao thức E-Mail nâng cao quyền riêng tư ( PEM ), được yêu cầu bởi RFC 989 vào năm 1987. PEM định nghĩa một lược đồ ” mã hóa hoàn toàn có thể in ” sử dụng mã hóa Base64 để biến hóa một chuỗi octet tùy ý sang một định dạng hoàn toàn có thể được biểu lộ bằng những dòng ngắn gồm những ký tự 6 bit, theo nhu yếu của những 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 (AZ, az), các chữ số (09), và các ký tự +/. 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 tài 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 giải quyết và xử lý thông thường. Nếu còn lại ít hơn 3 octet ( 24 bit ) để mã hóa, tài liệu nguồn vào sẽ được đệm bên phải với những 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 nhu yếu toàn bộ những dòng được mã hóa gồm có đúng mực 64 ký tự hoàn toàn có thể in được, ngoại trừ dòng ở đầu cuối, hoàn toàn có thể chứa ít ký tự hoàn toàn có thể in hơn. Các dòng được phân làn bằng những ký tự khoảng chừng trắng theo quy ước cục bộ ( dành riêng cho nền tảng ) .
Bài chi tiết cụ thể : 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 và thắt chặt cho những 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 vần âm nào phải được bộ giải thuật tuân thủ bỏ lỡ, mặc dầu hầu hết những tiến hành đều sử dụng cặp dòng mới CR / LF để phân tách những dòng được mã hóa .Do đó, độ dài trong thực tiễn của tài liệu nhị phân được mã hóa Base64 tuân thủ MIME thường bằng khoảng chừng 137 % độ dài tài liệu gốc, mặc dầu so với những tin nhắn rất ngắn, ngân sách hoàn toàn có thể cao hơn nhiều do ngân sách của những tiêu đề. Rất đại khái, size ở đầu cuối của tài liệu nhị phân được mã hóa Base64 bằng 1,37 lần size tài liệu gốc + 814 byte ( so với tiêu đề ). Kích thước của tài liệu được giải thuật hoàn toàn 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, được diễn đạt tiên phong trong RFC 1642, mà sau đó đã được thay thế sửa chữa bởi RFC 2152, đã ra mắt một mạng lưới 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.

Bài cụ thể : 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, hoàn toàn 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 ) nỗ lực thống nhất RFC 1421 và RFC 2045 thông số kỹ thuật kỹ thuật của mã hóa Base64, mã hóa bảng vần âm thay thế sửa chữa và mã hóa Base32 ( hiếm khi được sử dụng ) và Base16 .Trừ khi những tiến hành được viết cho một thông số kỹ thuật kỹ thuật đề cập đến RFC 3548 và đặc biệt quan trọng nhu yếu khác, RFC 3548 cấm việc tiến hành tạo thông tin có chứa những ký tự bên ngoài bảng vần âm mã hóa hoặc không có phần đệm và nó cũng công bố rằng việc tiến hành bộ giải thuật phải phủ nhận tài liệu có chứa những ký tự bên ngoài bảng vần âm mã hóa. [ 6 ]
RFC này bị lỗi thời RFC 3548 và tập trung chuyên sâu 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[sửa|sửa mã nguồn]

Mã hóa Base64 hoàn toàn có thể có ích khi thông tin nhận dạng khá dài được sử dụng trong môi trường tự nhiên HTTP. Ví dụ : một khung bền vững và kiên cố cơ sở tài liệu cho những đối tượng người dùng Java hoàn toàn 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 những 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, gồm có cả trong những 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ự +, /= 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= 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ự +/ của Base64 tiêu chuẩn được thay thế tương ứng bởi -_, để 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.

Các phương thức JavaScript atob()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[sửa|sửa mã nguồn]

Example of an SVG containing embedded JPEG images encoded in Base64[12]

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ư 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 thích hợp với Base64[sửa|sửa mã nguồn]

  • 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, go‘. 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 ./. 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 +- còn hơn là sử dụng ./. 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]
  1. ^ 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 .

Liên kết ngoài[sửa|

sửa mã nguồn]

Base64 – Wikipedia tiếng Việt

Bài viết liên quan
Hotline 24/7: O984.666.352
Alternate Text Gọi ngay