base64로 인코딩 된 문자열 끝에 왜 = 부호가 있습니까?


321

base64인코딩이 무엇 base64이며 C #에서 인코딩 을 계산 하는 방법을 알고 있지만 문자열을 base64로 변환 할 때 =끝에 가 있음을 여러 번 보았습니다 .

몇 가지 질문이 나왔습니다.

  1. 않습니다 base64항상 함께 문자열 끝 =?
  2. =끝에 끝에 추가되는 이유는 무엇 입니까?

9
이것은 C #과 전혀 관련이 없습니다.
BoltClock

19
실제로 이것은 c #과 관련이 있지만 모든 언어가 =를 포함하는 것은 아닙니다.
Jacob

이것은 일종의 감지가 가능하기 때문에 어떤 경우에는 덜 난독 화 방법을 만드는 것처럼 보입니다.
dgo

6
@ user1167442 Base64는 난독 처리 용이 아닙니다. 이진 데이터 (또는 유니 코드 및 기타 특수 문자가있는 문자열)를 문자열로 전송하기위한 것입니다.
NH.

답변:


269

패딩 역할을 합니다.

더 완전한 대답은 base64로 인코딩 된 문자열이 항상 a로 끝나는 =것이 아니라 =문자열을 적절한 길이로 채워야하는 경우 1-2로 끝나는 것 입니다.


3
"패딩 문자가 필요한 경우는 여러 Base64 인코딩 파일을 연결하는 것입니다."
André Puel

1
@ AndréPuel : 하나의 단일 동기화로 =충분합니다. 경계를 찾으려면 종료자가 항상 있어야합니다 (그리고 여전히 하나의 문자 만 필요합니다). Base64의 전체 패딩 개념은 단지 두뇌 방어 일뿐입니다.
6502

5
그러나이 링크는 base64와는 전혀 관련이 없습니다.
NH.

1
base64그림과 예제 를 효율적으로 패딩하는 방법을 설명하는 관련성 있고 안정적인 링크가 게시되기를 바랍니다 . wikipedia에 대한 현재 링크는 @NH와는 전혀 관련이 없습니다. 말하는.
Fr0zenFyr

1
@ Fr0zenFyr 링크를 원한다면 en.wikipedia.org/wiki/Base64#Output_padding 이 좋습니다. 그러나 Badr답변 은 실제로 더 나은 답변입니다 (아직 투표에 들지 않았습니다).
NH.

312

1- 아니오

2- 짧은 대답으로 : 65 번째 문자 ( "="부호)는 메시지를 인코딩하는 최종 프로세스에서 보완 물로만 사용됩니다.

Base64인코딩에 각각 3 바이트 (8 비트) 가 걸리고 ASCII 표준에서 인쇄 가능한 4 개의 문자 로 표시 되므로 문자열에 3 자의 배수가 있으면 '='기호가 없습니다 .

세부 사항 :

(a) 인코딩하려는 경우

ABCDEFG <=> [ ABC] [ DEF] [G

Base64첫 번째 블록과 두 번째 블록 (완료 됨)을 처리 (4 자 생성)하지만 세 번째 블록은 ==필요한 문자 4 개를 완성하기 위해 출력에 두 배 를 추가합니다 . 따라서 결과는 QUJD REVG Rw == (공간없이)

(b) 인코딩하려는 경우 ...

ABCDEFGH <=> [ ABC] [ DEF] [GH

마찬가지로 =출력 끝에 하나만 추가 하여 4자를 가져옵니다. 결과는 QUJD REVG R0g = (공백없이)입니다.


26
이것은 다른 답변보다 훨씬 완전하고 명확하며 Wikipedia에서도 wikipedia 링크를 가리키는 승인 된 답변보다 더 많은 투표를 받아야합니다. 당신에게 Kudos! 공감!
ANewGuyInTown

2
@ANewGuyIn 허용 된 솔루션의 wikipedia 링크가 올바르지 않습니다. base64의 패딩과 관련이 없습니다. 올바른 페이지아래의 답변
Fr0zenFyr


66

에서 위키 백과 :

마지막 '=='시퀀스는 마지막 그룹에 1 바이트 만 포함되었음을 나타내고 '='는 2 바이트를 포함했음을 나타냅니다.

따라서 이것은 일종의 패딩입니다.


16
  1. 아니.
  2. Base64로 인코딩 된 문자열을 길이가 4 자의 배수로 채워서 올바르게 디코딩 할 수 있습니다.

3
나는 =끝에를 제거하고 이것을 백만 개의 문자열로 테스트했습니다. 디코딩은 항상 일치했습니다.
vivek_23


11

등호 (=)는 특정 형식의 base64 인코딩에서 패딩으로 사용됩니다. base64 의 Wikipedia 기사 에 자세한 내용이 있습니다.


2
"=="가 1 바이트이고 "="가 2 바이트 인 이유에 대한 논리를 설명해 주시겠습니까? 나는 그것을 이해할 수 없다. 입력 방법 : "모든 육체적 인 기쁨" "YW55IGNhcm5hbCBwbGVhc3VyZS4 ="결과를 얻을 수 있지만 "육신적인 즐거움"은 "YW55IGNhcm5hbCBwbGVhc3VyZQ =="결과를 얻을 수 있습니까?
null

14
'=='가 1 바이트이고 '='가 2 바이트 인 경우는 아닙니다. 전체 문자열에 항상 4 바이트의 배수를 가져야하는 경우입니다. 그래서 당신은 그것을 얻을 때까지 '='표시로 채 웁니다. 첫 번째 문자열은 두 번째 문자열보다 하나 더 많은 문자를 가지므로 패딩이 더 적은 '='가 필요합니다.
Sam Holloway

2
이 답변은 주석이어야합니까?
Fr0zenFyr

9

패딩입니다. 에서 http://en.wikipedia.org/wiki/Base64 :

이론적으로, 패딩 문자는 디코딩에 필요하지 않습니다. 누락 된 바이트 수는 Base64 자릿수에서 계산 될 수 있기 때문입니다. 일부 구현들에서, 패딩 문자는 필수적이지만, 다른 것들에서는 사용되지 않는다. 패딩 문자가 필요한 경우는 여러 Base64 인코딩 파일을 연결하는 것입니다.


1
"패딩 문자가 필요한 경우 중 하나는 여러 Base64 인코딩 파일을 연결하는 것입니다." 잘못되었습니다. 예를 들어, 각 파일의 소스 바이트가 3 바이트 인 두 개의 base64 파일을 연결할 때 base64 문자열의 길이는 4 자이며 패딩 바이트는 없습니다. 이 두 개의 base64 문자열을 연결하면 연결된 문자열을 기반으로 한 시작 및 중지 위치를 알 수있는 방법이 없습니다. 따라서 base64 패딩을 사용하면 도움이되지 않습니다. 바이트 길이가 3으로 균등하게 나눌 수있는 모든 파일
Ron C

1
최종 결과가 입력의 연결이어야하는 경우를 의미한다고 생각합니다. 예를 들어 decode(encode(A)+encode(B))=A+B패딩과 함께 작동하지만 그렇지 않으면 작동하지 않습니다.
토마스 레너드

아마도 그러나 그러한 제한된 사용으로 인해 인코딩 된 문자열이 함께 연결될 때 인코딩 된 문자열을 분리하는 일반적인 경우에 패딩 문자를 사용할 수 없습니다. 나는 그것을 그렇게 사용할 수 있다고 생각하는 개발자를 돕기 위해 언급했습니다.
Ron C

1
나는 당신의 반대가 패딩과 구분의 개념의 차이점을 실제로 강조한다고 생각합니다. 연결 결과에는 일반적으로 정보를 되돌릴 수있는 충분한 정보가 포함되어 있지 않습니다. "c3dpenpsZXJz"가 원래 "c3dpenps"+ "ZXJz"또는 "c3dp"+ "enpsZXJz"인지 알 수 없습니다. 그러나 "swizzlers"가 원래 "swi"+ "zzlers"또는 "swizzl"+ "ers"인지 여부도 알 수 없습니다.
GargantuChet

1
관련 Base64 패딩 답변 에서 내 의견을 복사 :> Base64 연결 ( '='패딩 사용)을 사용하면 인코더가 청크 크기를 3의 배수로 정렬 할 필요없이 큰 청크를 병렬로 처리 할 수 ​​있습니다. 마찬가지로 구현 세부 사항으로 3의 배수가 아닌 크기의 내부 데이터 버퍼를 플러시 해야하는 인코더가있을 수 있습니다.
Andre D

7

http://www.hcidata.info/base64.htm

"Mary have"를 Base 64로 인코딩

이 예에서는 간단한 텍스트 문자열 ( "Mary have")을 사용하지만 데이터가 무엇이든 (예 : 그래픽 파일) 원칙이 적용됩니다. 24 비트의 입력 데이터를 32 비트의 출력으로 변환하기 위해 Base 64 인코딩은 24 비트를 6 비트의 4 개 청크로 분할합니다. 첫 번째 문제는 "Mary have"가 3 바이트의 배수가 아니라 8 바이트 길이라는 것입니다. 이 때문에 마지막 비트 그룹은 길이가 4 비트에 불과합니다. 이를 해결하기 위해 '0'의 두 비트를 추가하고 끝에 '='를 넣어서이 사실을 기억하십시오. Base 64로 변환 할 텍스트 문자열의 길이가 7 바이트 인 경우 마지막 그룹은 2 비트입니다. 이 경우, 우리는 '0'의 4 비트를 더 추가하고 마지막에 '=='를 두어이 사실을 기억합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.