베이스64
Base64베이스64(Base64)는 컴퓨터 프로그래밍에서 4개의 6비트 Base64 숫자로 표현될 수 있는 24비트 시퀀스의 이진 데이터(더 구체적으로는 8비트 바이트 시퀀스)를 나타내는 4진수 바이너리 텍스트 인코딩 방식의 그룹입니다.
모든 바이너리-투-텍스트 인코딩 방식과 마찬가지로, Base64는 바이너리 형식으로 저장된 데이터를 텍스트 콘텐츠만 안정적으로 지원하는 채널을 통해 전송하도록 설계되었습니다. Base64는 특히 월드 와이드 웹에서[1] 널리 사용되고 있는데, 여기서 사용되는 것 중 하나는 HTML 및 CSS 파일과 같은 텍스트 자산 내부에 이미지 파일 또는 기타 이진 자산을 내장할 수 있는 기능입니다.[2]
Base64는 이메일 첨부 파일을 보낼 때도 널리 사용됩니다. 원래 형태의 SMTP는 7비트 ASCII 문자만 전송하도록 설계되었기 때문에 이 작업이 필요합니다. 이 인코딩은 33-37%의 오버헤드를 유발합니다(인코딩 자체에서 33%, 삽입된 줄이 끊어지면 최대 4% 증가).
설계.
기본에 대한 64자리 값을 나타내기 위해 선택된 64자의 특정 집합은 구현마다 다릅니다. 일반적인 전략은 대부분의 인코딩에 공통적이고 인쇄 가능한 64개의 문자를 선택하는 것입니다. 이렇게 결합하면 기존에는 8비트가 깨끗하지 않았던 이메일과 같은 정보 시스템을 통해 전송 중에 데이터가 수정될 가능성이 거의 없습니다.[3] 예를 들어, MIME의 Base64 구현은 A–Z, a–z,그리고. 0–9 처음 62개의 값에 대해. 다른 변형은 이 속성을 공유하지만 마지막 두 값에 대해 선택된 기호가 다릅니다. 예를 들어 UTF-7이 있습니다.
이러한 종류의 인코딩의 초기 예는 UNIX용 uuencode와 TRS-80용 BinHex(이후 매킨토시용으로 채택)와 같이 동일한 OS를 실행하는 시스템 간의 전화 접속 통신을 위해 만들어졌으므로 어떤 문자를 사용하는 것이 안전한지에 대해 더 많은 추측을 할 수 있었습니다. 예를 들어 uencode는 대문자, 숫자 및 많은 구두점 문자를 사용하지만 소문자는 사용하지 않습니다.[4][5][6][3]
RFC 4648의 기본 64 표
이것은 RFC 4648 §4에 정의된 Base64 알파벳입니다. 아래의 변형 요약도 참조하십시오.
| 색인 | 이진법 | 차르 | 색인 | 이진법 | 차르 | 색인 | 이진법 | 차르 | 색인 | 이진법 | 차르 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 | / | |||
| 패딩 | = | |||||||||||||
예
아래 예에서는 단순화를 위해 ASCII 텍스트를 사용하지만, 이는 Base64를 처리할 수 있는 모든 시스템에서 이미 안전하게 전송할 수 있기 때문에 일반적인 사용 사례는 아닙니다. 더 일반적인 용도는 이미지와 같은 이진 데이터를 인코딩하는 것입니다. 결과적으로 생성되는 Base64 데이터는 64개의 서로 다른 ASCII 문자만을 포함하며, 이들 모두는 원시 소스 바이트를 손상시킬 수 있는 시스템을 통해 안정적으로 전송될 수 있습니다.
백지장도 맞들면 낫다.
인용문이 Base64로 인코딩되면 다음과 같이 MIME의 Base64 방식으로 인코딩된 8비트 패딩 ASCII 문자의 바이트 시퀀스로 표시됩니다(새 줄과 공백은 어디에나 존재할 수 있지만 디코딩 시 무시됩니다).
TWFUE SboYW5kcyBtYWtlIGxpZ2h0IHDvcmsu
위 인용문에서 Man의 인코딩된 값은 TWFu입니다. ASCII로 인코딩된 문자 M, a, n은 바이트 값으로 저장됩니다. 77, 97,그리고. 110, 8비트 이진수 값입니다. 01001101, 01100001,그리고. 01101110. 이 세 가지 값은 24비트 문자열로 결합되어 생성됩니다. 010011010110000101101110. 6비트 그룹(6비트는 최대 2=64개의 서로 다른 이진 값을 갖습니다)은 처음부터 끝까지 개별 숫자로 변환됩니다(이 경우 24비트 문자열에 4개의 숫자가 포함됨). 그런 다음 해당 Base64 문자 값으로 변환됩니다.
이 예에서 알 수 있듯이 Base64 인코딩은 3개의 옥텟을 4개의 인코딩된 문자로 변환합니다.
| 원천 | 텍스트(ASCII) | M | a | n | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 옥텟 | 77(0x4d) | 97(0x61) | 110 (0x6e) | ||||||||||||||||||||||
| 비트 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | |
| 베이스64 암호화된 | 육십진 | 19 | 22 | 5 | 46 | ||||||||||||||||||||
| 성격 | T | W | F | u | |||||||||||||||||||||
| 옥텟 | 84(0x54) | 87(0x57) | 70(0x46) | 117(0x75) | |||||||||||||||||||||
= 마지막 인코딩된 블록이 4개의 Base64 문자를 포함하도록 만들기 위해 패딩 문자가 추가될 수 있습니다.
16진수에서 8진수 변환은 이진 및 Base64 간 변환에 유용합니다. 이러한 변환은 고급 계산기와 프로그래밍 언어 모두에서 사용할 수 있습니다. 예를 들어, 위의 24비트의 16진수 표현은 4D616E입니다. 팔분의 표현은 23260556입니다. 그 8개의 팔진수는 쌍으로 나눌 수 있고(230 260 0556), 각 쌍은 소수점으로 변환되어 1922 0 05 46이 됩니다. 이 4개의 10진수를 Base64 알파벳의 인덱스로 사용하면 해당 ASCII 문자가 TWFu가 됩니다.
중요한 입력 옥텟이 2개(예: 'Ma')에 불과하거나 마지막 입력 그룹에 2개의 옥텟만 포함된 경우 16비트가 모두 처음 3개의 Base64 자리(18비트)에서 캡처됩니다. 마지막 내용을 포함하는 6비트 블록의 가장 덜 중요한 2개의 비트는 0으로 판명되고 디코딩 시 폐기됩니다(다음 순서와 함께). = 패딩 문자):
| 원천 | 텍스트(ASCII) | M | a | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 옥텟 | 77(0x4d) | 97(0x61) | |||||||||||||||||||||||
| 비트 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | |||||||
| 베이스64 암호화된 | 육십진 | 19 | 22 | 4 | 패딩 | ||||||||||||||||||||
| 성격 | T | W | E | = | |||||||||||||||||||||
| 옥텟 | 84(0x54) | 87(0x57) | 69(0x45) | 61(0x3D) | |||||||||||||||||||||
중요한 입력 옥텟이 하나(예: 'M')이거나 마지막 입력 그룹에 하나의 옥텟만 포함된 경우, 8비트 모두가 처음 두 Base64 자리(12비트)에서 캡처됩니다. 마지막 내용을 포함하는 6비트 블록의 가장 덜 중요한 4비트는 0으로 판명되고 디코딩 시 폐기됩니다(다음 2비트와 함께). = 패딩 문자):
| 원천 | 텍스트(ASCII) | M | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 옥텟 | 77(0x4d) | ||||||||||||||||||||||||
| 비트 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | |||||||||||||
| 베이스64 암호화된 | 육십진 | 19 | 16 | 패딩 | 패딩 | ||||||||||||||||||||
| 성격 | T | Q | = | = | |||||||||||||||||||||
| 옥텟 | 84(0x54) | 81(0x51) | 61(0x3D) | 61(0x3D) | |||||||||||||||||||||
출력패딩
Base64는 6비트 인코딩이므로 디코딩된 값이 8비트 옥텟으로 나뉘기 때문에 Base64 인코딩된 텍스트의 4개 문자마다 인코딩되지 않은 텍스트 또는 데이터의 3옥텟(3옥텟 = 3 × 8 = 24비트)을 나타냅니다. 즉, 인코딩되지 않은 입력의 길이가 3의 배수가 아닐 때 인코딩된 출력에는 길이가 4의 배수가 되도록 패딩이 추가되어야 합니다. 패딩 캐릭터는. =, 이는 입력을 완전히 인코딩하기 위해 더 이상의 비트가 필요하지 않음을 나타냅니다. (이는 다음과 다릅니다.) A, 나머지 비트는 모두 0임을 의미합니다.) 다음 예제는 위 인용문의 입력을 잘라내면 출력 패딩이 어떻게 변경되는지 보여줍니다.
| 입력 | 산출량 | 패딩 | ||
|---|---|---|---|---|
| 본문 | 길이 | 본문 | 길이 | |
| 가벼운 일 | 11 | bGlnaHQgd29yay4= | 16 | 1 |
| 가벼운 일 | 10 | bGlnaHQgd29yaw== | 16 | 2 |
| 가벼운 말 | 9 | bGlnaHQgd29y | 12 | 0 |
| 엷은 엷은 엷은 wo | 8 | bGlnaHQgd28= | 12 | 1 |
| 엷은 w | 7 | bGlnaHQgdw== | 12 | 2 |
인코딩된 텍스트의 길이로부터 누락된 바이트 수를 유추할 수 있으므로 패딩 문자는 디코딩에 필수적인 것은 아닙니다. 일부 구현예에서는 패딩 문자가 필수인 반면, 다른 구현예에서는 패딩 문자가 사용되지 않습니다. 패딩 문자가 필요한 예외는 여러 Base64 인코딩 파일이 연결된 경우입니다.
패딩을 포함한 기본 64 디코딩
Base64 텍스트를 디코딩할 때 일반적으로 4개의 문자가 다시 3바이트로 변환됩니다. 유일한 예외는 패딩 문자가 존재하는 경우입니다. 싱글 = 4개의 문자가 2바이트만 디코딩할 수 있음을 나타냅니다. == 네 개의 문자가 단일 바이트로만 디코딩됨을 나타냅니다. 예:
| 인코딩된 | 패딩 | 길이 | 디코드 |
|---|---|---|---|
| bGlnaHQgdw== | == | 1 | 엷은 w |
| bGlnaHQgd28= | = | 2 | 엷은 엷은 엷은 wo |
| bGlnaHQgd29y | 없음. | 3 | 가벼운 말 |
패딩 문자를 해석하는 또 다른 방법은 a번마다 비트열에서 2개의 후행 비트를 폐기하라는 명령으로 간주하는 것입니다. = 마주칩니다. 예를 들어, 'bGlnaHQgdw=='가 디코딩되면 각 문자를 변환합니다(후행 발생 제외). =)을 해당 6비트 표현으로 변환한 다음, 첫 번째에 대해 2개의 후행 비트를 폐기합니다. = 그리고 다른 두 개의 추적 비트가 있습니다. =. 이 경우, 우리는 다음으로부터 6비트를 얻을 것입니다. d, 그리고 또 다른 6비트는 w 길이가 12인 비트열에 대해서는 각각 2비트씩 제거하기 때문에 = (총 4비트), dw== 디코딩 시 8비트(1바이트)를 생성하게 됩니다.
패딩 없는 디코딩 베이스64
패딩 없이, 4개의 문자를 3바이트로 반복하여 정상적으로 디코딩한 후, 4개 미만의 인코딩된 문자가 남아있을 수 있습니다. 이런 상황에서 2~3자만 남을 수 있습니다. 단일 Base64 문자는 6비트만 포함하고 바이트를 만드는 데 8비트가 필요하므로 나머지 단일 인코딩 문자는 불가능합니다. 첫 번째 문자는 6비트를 기여하고 두 번째 문자는 첫 번째 2비트를 기여합니다. 예:
| 길이 | 인코딩된 | 길이 | 디코드 |
|---|---|---|---|
| 2 | bGlnaHQgdw | 1 | 엷은 w |
| 3 | bGlnaHQgd28 | 2 | 엷은 엷은 엷은 wo |
| 4 | bGlnaHQgd29y | 3 | 가벼운 말 |
패딩이 없는 디코딩은 디코더들 사이에서 일관성 있게 수행되지 않습니다. 또한, 정의에 따라 패드리스 디코딩을 허용하면 여러 문자열이 동일한 바이트 집합으로 디코딩할 수 있어 보안 위험이 될 수 있습니다.[7]
구현 및 이력
변형 요약 표
구현들은 일부 비트 패턴들을 표현하기 위해 사용되는 알파벳에 대한 일부 제약들을 가질 수 있습니다. 이것은 특히 62번과 63번 위치의 알파벳에 사용된 마지막 두 문자와 패딩에 사용된 문자(일부 프로토콜에서는 필수이거나 다른 프로토콜에서는 제거될 수 있음)에 관한 것입니다. 아래 표는 이러한 알려진 변형을 요약하고 아래 하위 섹션에 대한 링크를 제공합니다.
| 인코딩 | 문자 인코딩 | 선 구분 부호화 | 인코딩되지 않은 문자 디코딩 | ||||
|---|---|---|---|---|---|---|---|
| 62회 | 63회 | 패드를 대다 | 구분자 | 길이 | 체크섬 | ||
| RFC 1421: Privacy-Enhanced Mail을 위한 Base64 (비사용) | + | / | = 의무적인 | CR+LF | 마지막 줄 64 이하 | 아니요. | 아니요. |
| RFC 2045: MIME을 위한 Base64 전송 인코딩 | + | / | = 의무적인 | CR+LF | 많아야 76 | 아니요. | 폐기 |
| RFC 2152: UTF-7의 기본 64 | + | / | 아니요. | 아니요. | 아니요. | ||
| RFC 3501: IMAP 메일함 이름을 위한 Base64 인코딩 | + | , | 아니요. | 아니요. | 아니요. | ||
| RFC 4648 §4: base64 (표준) | + | / | = 선택적. | 아니요. | 아니요. | ||
| RFC 4648 §5: base64url (URL 및 파일명 안전 표준) | - | _ | = 선택적. | 아니요. | 아니요. | ||
| RFC 4880: 오픈PGP용 Radix-64 | + | / | = 의무적인 | CR+LF | 많아야 76 | Radix-64 인코딩된 24비트 CRC | 아니요. |
| 다른 변형들 | RFC 4648 Base64와 호환되지 않는 응용프로그램 참조(아래) | ||||||
개인 정보 보호 기능이 강화된 메일
현재 MIME Base64라고 불리는 인코딩의 최초의 표준화된 사용은 다음에 의해 제안된 개인 정보 보호 강화 전자 메일(PEM) 프로토콜입니다. 1987년 RFC989. PEM은 기본 64 인코딩을 사용하여 임의의 옥텟 시퀀스를 SMTP와 같은 전송 프로토콜에서 요구하는 6비트 문자의 짧은 줄로 표현할 수 있는 형식으로 변환하는 "인쇄 가능한 인코딩" 체계를 정의합니다.[8]
현재 버전의 PEM(RFC1421에 명시됨)은 대문자와 소문자로 구성된 64자 알파벳을 사용합니다.A–Z, a–z), 숫자()0–9), 그리고 + 그리고. / 기호 그 = 기호는 패딩 접미사로도 사용됩니다.[4] 원래 사양인 RFC989는 추가적으로 다음을 사용했습니다. * 출력 스트림 내에서 인코딩되었지만 암호화되지 않은 데이터를 구분하는 기호입니다.
데이터를 PEM 인쇄 가능한 인코딩으로 변환하기 위해 첫 번째 바이트는 24비트 버퍼의 가장 중요한 8비트에, 다음 바이트는 중간 8비트에, 세 번째 바이트는 가장 덜 중요한 8비트에 배치됩니다. 인코딩할 수 있는 바이트가 3바이트 미만(또는 총)이면 나머지 버퍼 비트는 0이 됩니다. 그런 다음 버퍼는 한 번에 6비트씩, 가장 중요한 첫 번째로 문자열에 대한 인덱스로 사용됩니다. "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", 그리고 표시된 문자가 출력됩니다.
나머지 데이터에 대해 4옥텟 미만이 남을 때까지 이 과정을 반복합니다. 3옥텟이 남으면 정상적으로 처리됩니다. 인코딩할 수 있는 옥텟(24비트)이 3개 미만인 경우 입력 데이터를 0비트로 오른쪽 패딩하여 6비트의 정수배를 형성합니다.
추가되지 않은 데이터를 인코딩한 후, 24비트 버퍼의 두 옥텟이 패딩 제로인 경우, 두 개 = 문자가 출력에 추가됩니다. 24비트 버퍼의 한 옥텟이 패딩 제로로 채워지면 한 옥텟이 됩니다. = 문자가 추가되었습니다. 이는 디코더에 패딩으로 인해 추가된 제로 비트를 재구성된 데이터에서 제외해야 함을 알려줍니다. 또한 인코딩된 출력 길이가 4바이트의 배수임을 보장합니다.
PEM에서는 마지막 줄을 제외하고 모든 인코딩된 줄은 정확히 64개의 인쇄 가능한 문자로 구성되어야 합니다. 이 문자에는 인쇄 가능한 문자가 더 적을 수 있습니다. 줄은 로컬(플랫폼별) 규칙에 따라 공백 문자로 구분됩니다.
MIME
MIME(다목적 인터넷 메일 확장) 규격은 Base64를 두 개의 이진 텍스트 인코딩 방식 중 하나로 나열합니다(다른 하나는 인용 인쇄 가능).[5] MIME의 Base64 인코딩은 RFC1421 버전의 PEM 인코딩을 기반으로 합니다: PEM과 동일한 64자 알파벳과 인코딩 메커니즘을 사용하고 다음을 사용합니다. = RFC2045에 설명된 것과 같은 방식으로 출력 패딩을 위한 심볼.
MIME은 Base64 인코딩된 행의 고정 길이를 지정하지 않지만 최대 행 길이를 76자로 지정합니다. 또한 표준 64개 인코딩 문자 집합(예: CRLF 시퀀스) 이외의 모든 문자는 호환 디코더에서 무시해야 함을 명시하지만 대부분의 구현에서는 CR/LF 새 줄 쌍을 사용하여 인코딩된 줄을 구분합니다.
따라서 MIME 호환 Base64 인코딩된 이진 데이터의 실제 길이는 일반적으로 원본 데이터 길이의 약 137%입니다.4 ⁄3×78 ⁄76), 매우 짧은 메시지의 경우 헤더의 오버헤드로 인해 오버헤드가 훨씬 더 높아질 수 있습니다. 기본 64로 인코딩된 이진 데이터의 최종 크기는 원래 데이터 크기의 1.37배 + 814바이트(헤더의 경우)와 같습니다. 디코딩된 데이터의 크기는 다음 공식으로 근사할 수 있습니다.
바이트 = (string_length(encoded_string)) - 814) / 1.37
UTF-7
RFC 1642에서 처음 기술된 UTF-7은 나중에 RFC 2152로 대체된 수정된 Base64라는 시스템을 도입했습니다. 이 데이터 인코딩 방식은 SMTP와 같은 7비트 전송에서 사용하기 위해 UTF-16을 ASCII 문자로 인코딩하는 데 사용됩니다. 이것은 MIME에 사용되는 Base64 인코딩의 변형입니다.[9][10]
"Modified Base64" 알파벳은 MIME Base64 알파벳으로 구성되어 있지만 "를 사용하지 않습니다.= " 패딩 캐릭터 UTF-7은 메일 헤더(RFC2047에 정의됨)에 사용하기 위한 것입니다.=" 문자는 해당 컨텍스트에서 "quoted 인쇄 가능" 인코딩을 위해 이스케이프 문자로 예약됩니다. 수정된 베이스64는 단순히 패딩을 생략하고 마지막 베이스64 자리에 사용되지 않은 최대 3개의 비트를 남기는 유용한 비트를 포함하는 마지막 베이스64 자리 바로 뒤에 종료됩니다.
오픈PGP
RFC4880에 설명된 OpenPGP는 "ASCII armor"라고도 알려진 Radix-64 인코딩을 설명합니다. Radix-64는 MIME에서 설명한 "Base64" 인코딩과 동일하며, 옵션인 24비트 CRC가 추가됩니다. 체크섬은 인코딩하기 전에 입력 데이터에 대해 계산됩니다. 그리고 체크섬은 동일한 Base64 알고리즘으로 인코딩되고 "에 의해 접두사가 붙습니다.=" 부호화된 출력 데이터에 추가되는 구분 기호입니다.[11]
RFC 3548
RFC 3548(The Base16, Base32, Base64 Data Encodings)은 Base64 인코딩, 대체 알파벳 인코딩, Base32 및 Base16 인코딩의 RFC 1421 및 RFC 2045 사양을 통합하려는 정보(비규범적) 메모입니다.
구현예들이 RFC 3548을 참조하고 특별히 달리 요구하는 사양에 기입되지 않는 한, RFC 3548은 구현예들이 인코딩 알파벳 외부의 문자들을 포함하는 메시지들 또는 패딩들을 포함하지 않는 메시지들을 생성하는 것을 금지하고, 그리고 디코더 구현은 인코딩 알파벳 외부의 문자를 포함하는 데이터를 거부해야 한다고 선언합니다.[6]
RFC 4648
이 RFC는 RFC 3548을 폐지하고 Base64/32/16에 초점을 맞추고 있습니다.
- 이 문서에서는 일반적으로 사용되는 Base64, Base32 및 Base16 인코딩 방식에 대해 설명합니다. 또한 인코딩된 데이터에서 라인 피드의 사용, 인코딩된 데이터에서 패딩의 사용, 인코딩된 데이터에서 비알파벳 문자의 사용, 다양한 인코딩 알파벳의 사용 및 표준 인코딩에 대해 논의합니다.
URL 응용프로그램
기본 64 인코딩은 HTTP 환경에서 상당히 긴 식별 정보가 사용될 때 유용할 수 있습니다. 예를 들어 Java 개체에 대한 데이터베이스 지속 프레임워크는 Base64 인코딩을 사용하여 비교적 큰 고유 ID(일반적으로 128비트 UUID)를 문자열로 인코딩하여 HTTP 형식 또는 HTTP GET URL에서 HTTP 매개 변수로 사용할 수 있습니다. 또한 숨겨진 웹 폼 필드를 포함하여 URL에 포함하기에 편리한 방식으로 이진 데이터를 인코딩해야 하는 많은 애플리케이션이 필요하며, Base64는 콤팩트한 방식으로 렌더링하기에 편리한 인코딩입니다.
URL에서 표준 Base64를 사용하려면 '의 인코딩이 필요합니다.+', '/' 그리고 '=' 특수 백분율 encoded 16진수 시퀀스(')의 문자+' '가 됩니다.%2B', '/' '가 됩니다.%2F' 그리고 '=' '가 됩니다.%3D'), 문자열이 불필요하게 길어집니다.
이러한 이유로 URL 변형에 대한 수정된 Base64가 존재합니다(예: RFC4648의 base64url).+' 그리고 '/' 표준 Base64의 문자는 각각 '로 대체됩니다.-' 그리고 '_', URL 인코더/디코더를 사용하는 것이 더 이상 필요하지 않고 인코딩된 값의 길이에 영향을 미치지 않기 때문에 일반적으로 관계형 데이터베이스, 웹 양식 및 객체 식별자에서 사용하기 위해 동일한 인코딩된 형태를 그대로 유지합니다. 이를 활용하기에 인기 있는 사이트는 유튜브입니다.[12] 일부 변형은 패딩을 허용하거나 생략해야 합니다.=' 필드 구분자와 혼동되지 않도록 표시하거나 해당 패딩이 퍼센트 encoded이어야 합니다. 일부 라이브러리는[which?] '을(를) 인코딩합니다.=' '에게.', 사용자 데이터에서 폴더 이름을 인코딩할 때 응용 프로그램을 상대 경로 공격에 노출시킬 가능성이 있습니다.[citation needed]
HTML
그 atob() 그리고. btoa() HTML5 초안 규격에 정의된 자바스크립트 메소드는 [13]웹 페이지에 Base64 인코딩 및 디코딩 기능을 제공합니다. 그 btoa() 메서드는 패딩 문자를 출력하지만, 이러한 문자는 입력에서 선택 사항입니다. atob() 방법.
기타 응용프로그램
Base64는 다양한 맥락에서 사용할 수 있습니다.
- Base64를 사용하여 구분 기호 충돌을 일으킬 수 있는 텍스트를 전송하고 저장할 수 있습니다.
- Base64는 LDAP Data Interchange Format 파일의 문자열을 인코딩하는 데 사용됩니다.
- Base64는 종종 XML 파일에 이진 데이터를 내장하는 데 사용되며, 다음과 유사한 구문을 사용합니다.
<data encoding="base64">…</data>예: Firefox에서 내보낸 faviconsbookmarks.html. - Base64는 외부 파일에 의존하지 않도록 스크립트 내에서 이미지와 같은 이진 파일을 인코딩하는 데 사용됩니다.
- 데이터 URI 체계는 파일 내용을 표현하기 위해 Base64를 사용할 수 있습니다. 예를 들어, 배경 이미지 및 글꼴은 CSS 스타일시트 파일에서 다음과 같이 지정할 수 있습니다.
data:별도의 파일로 제공되는 대신 URI. - SVG의 공식 사양에는 포함되지 않지만 일부 뷰어는 SVG 내부의 이미지와 같은 내장 요소에 사용할 때 Base64를 해석할 수 있습니다.[15]
- Base64는 컴퓨터의 텍스트 클립보드 기능을 통해 비교적 적은 양의 이진 데이터를 저장/전송하는 데 사용할 수 있습니다. 특히 정보가 영구적으로 저장될 필요가 없거나 다양하고 잠재적으로 호환되지 않는 프로그램 간에 정보를 신속하게 전송해야 하는 경우에 사용할 수 있습니다. 암호화폐 수신자의 공개 키를 Base64 인코딩된 텍스트 문자열로 표현하는 것이 그 예이며, 이는 사용자의 지갑 소프트웨어에 쉽게 복사 및 붙여넣을 수 있습니다.
- 파일 체크섬이나 키 지문과 같이 안전 메커니즘으로 사람이 신속하게 확인해야 하는 이진 데이터는 쉽게 확인할 수 있도록 Base64에 표시되는 경우가 많으며, 때로는 PGP 키 지문의 표현에서 4개의 문자로 구성된 각 그룹을 공백으로 분리하는 등 추가 포맷과 함께 표시됩니다.
- 이진 데이터가 포함된 QR 코드는 모든 QR 코드 판독기가 정확하게 텍스트를 디코딩할 것이라는 더 강력한 보장이 있을 뿐만 아니라 일부 장치가 잠재적으로 악성 이진 데이터보다 QR 코드에서 텍스트를 더 쉽게 저장할 것이기 때문에 원시 이진 데이터를 단순히 저장하는 것이 아니라 Base64로 인코딩된 데이터를 저장하는 경우도 있습니다.
RFC 4648 Base64와 호환되지 않는 응용 프로그램
일부 응용 프로그램은 가장 일반적인 Base64 변형에 사용되는 알파벳과 크게 다른 Base64 알파벳을 사용합니다(위의 변형 요약 표 참조).
- Uu 인코딩 알파벳은 소문자를 포함하지 않으며 대신 ASCII 코드 32(")를 사용합니다.
_"), 연속적으로. Uu 인코딩은 알파벳 ""!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_을 사용합니다. 많은 오래된 프린터가 대문자만 인쇄했기 때문에 소문자를 모두 피하는 것이 도움이 되었습니다. 연속된 ASCII 문자를 사용하면 룩업 테이블 없이 32만 더하면 되므로 컴퓨팅 파워를 절약할 수 있었습니다. 대부분의 구두점 문자와 공백 문자를 사용하면 이러한 문자를 구문으로 사용하는 응용 프로그램과 같은 일부 응용 프로그램에서 유용성이 제한될 수 있습니다.[citation needed] - 클래식 맥 OS에 사용되었던 BinHex 4 (HQX)는 '와 같이 시각적으로 혼동하기 쉬운 일부 문자를 제외합니다.
7', 'O', 'g' 그리고 'o'. 알파벳에는 추가 구두점 문자가 포함되어 있습니다. 알파벳 "를 사용합니다.!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr - UTF-8 환경에서는 동기화되지 않은 계속 바이트를 기본 64로 사용할 수 있습니다.
0b10xxxxxx. UTF-8#Self-synchronization을 참조하십시오. - 다른 몇몇 응용 프로그램들은 일반적인 변형과 유사하지만 다른 순서로 알파벳을 사용합니다.
- 유닉스는 crypt로 계산된 암호 해시를 B64라는 인코딩을 사용하여 파일에 저장합니다. crypt의 알파벳은 구두점을 입력합니다.
.그리고./영숫자 앞에 입력합니다. crypt는 알파벳 "을 사용합니다../0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz". 패딩은 사용하지 않습니다. - 계도 데이터 교환을 위한 GEDCOM 5.5 표준은 텍스트 라인 계층 파일 형식으로 멀티미디어 파일을 인코딩합니다. GEDCOM은 crypt와 동일한 알파벳을 사용하는데, 이는 ""
./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz[16]입니다. - bcrypt 해시는 전통적인 crypt(3) 해시와 같은 방식으로 사용되도록 설계되었지만 bcrypt의 알파벳은 crypt의 알파벳과 다른 순서로 되어 있습니다. bcrypt는 알파벳 ""을 사용합니다.
./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789[17] - Xx 인코딩은 대부분 영숫자 집합을 crypt와 유사하게 사용하지만,
+그리고.-보다는.그리고./. Xx 인코딩은 알파벳 ""+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz을 사용합니다. - 일부 터미널 노드 컨트롤러와 함께 사용되는 6PACK은 0x00에서 0x3f 사이의 알파벳을 사용합니다.[18]
- Bash는 Base64에서 숫자 리터럴을 지원합니다. Bash는 알파벳 ""
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_[19]을 사용합니다.
- 유닉스는 crypt로 계산된 암호 해시를 B64라는 인코딩을 사용하여 파일에 저장합니다. crypt의 알파벳은 구두점을 입력합니다.
RFC 4648 알파벳의 한 가지 문제는 정렬된 ASCII 인코딩 문자열 목록이 Base64 변환되고 다시 정렬되면 요소의 순서가 변경된다는 것입니다. 패딩 문자와 대체 알파벳의 문자는 ASCII 문자 값으로 정렬되지 않기 때문입니다(다음 샘플 표의 정렬 버튼을 사용하여 확인할 수 있습니다). (추가되지 않은) B64와 같은 알파벳이 이를 해결합니다.
| 아스키 | 베이스64 | 베이스64,패딩없음 | B64 |
|---|---|---|---|
| 엷은 w | bGlnaHQgdw== | bGlnaHQgdw | P4ZbO5EURk |
| 엷은 엷은 엷은 wo | bGlnaHQgd28= | bGlnaHQgd28 | P4ZbO5EURqw |
| 가벼운 말 | bGlnaHQgd29y | bGlnaHQgd29y | P4ZbO5EURqxm |
참고 항목
참고문헌
- ^ "Base64 encoding and decoding – Web APIs". MDN Web Docs.
- ^ "When to base64 encode images (and when not to)". 28 August 2011.
- ^ a b The Base16, Base32, and Base64 Data Encodings. IETF. October 2006. doi:10.17487/RFC4648. RFC 4648. Retrieved March 18, 2010.
- ^ a b Privacy Enhancement for InternetElectronic Mail: Part I: Message Encryption and Authentication Procedures. IETF. February 1993. doi:10.17487/RFC1421. RFC 1421. Retrieved March 18, 2010.
- ^ a b Multipurpose Internet Mail Extensions: (MIME) Part One: Format of Internet Message Bodies. IETF. November 1996. doi:10.17487/RFC2045. RFC 2045. Retrieved March 18, 2010.
- ^ a b The Base16, Base32, and Base64 Data Encodings. IETF. July 2003. doi:10.17487/RFC3548. RFC 3548. Retrieved March 18, 2010.
- ^ Chalkias, Konstantinos; Chatzigiannis, Panagiotis (30 May 2022). Base64 Malleability in Practice (PDF). ASIA CCS '22: 2022 ACM on Asia Conference on Computer and Communications Security. pp. 1219–1221. doi:10.1145/3488932.3527284.
- ^ Privacy Enhancement for Internet Electronic Mail. IETF. February 1987. doi:10.17487/RFC0989. RFC 989. Retrieved March 18, 2010.
- ^ UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. July 1994. doi:10.17487/RFC1642. RFC 1642. Retrieved March 18, 2010.
- ^ UTF-7 A Mail-Safe Transformation Format of Unicode. IETF. May 1997. doi:10.17487/RFC2152. RFC 2152. Retrieved March 18, 2010.
- ^ OpenPGP Message Format. IETF. November 2007. doi:10.17487/RFC4880. RFC 4880. Retrieved March 18, 2010.
- ^ "Here's Why YouTube Will Practically Never Run Out of Unique Video IDs". www.mentalfloss.com. 23 March 2016. Retrieved 27 December 2021.
- ^ "7.3. Base64 utility methods". HTML 5.2 Editor's Draft. World Wide Web Consortium. Retrieved 2 January 2018. 변경 세트 5814, 2021-02-01에 의해 소개되었습니다.
- ^ <image xlink:href="데이터:image/jpeg;base64,
JPEG contents encoded in Base64" ... /> - ^ "Edit fiddle". jsfiddle.net.
- ^ "The GEDCOM Standard Release 5.5". Homepages.rootsweb.ancestry.com. Retrieved 2012-06-21.
- ^ Provos, Niels (1997-02-13). "src/lib/libc/crypt/bcrypt.c r1.1". Retrieved 2018-05-18.
- ^ "6PACK a "real time" PC to TNC protocol". Archived from the original on 2012-02-24. Retrieved 2013-05-19.
- ^ "Shell Arithmetic". Bash Reference Manual. Retrieved 8 April 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.
