위키 백과 는 말합니다

Base64 인코딩 체계는 텍스트 데이터를 처리하도록 설계된 미디어를 통해 저장 및 전송해야하는 이진 데이터를 인코딩해야 할 때 일반적으로 사용됩니다. 이는 전송 중에 데이터를 수정하지 않고 그대로 유지하기위한 것입니다.

그러나 데이터가 항상 바이너리로 저장 / 전송되는 것은 아닙니다. 머신에 바이너리가 저장되어 있고 해석 방법에 따라 달라지기 때문입니다. 따라서 비트 패턴 010011010110000101101110을 ManASCII 또는 TWFuBase64 와 같이 인코딩하더라도 결국 동일한 비트 패턴을 저장하게됩니다.

궁극적 인 인코딩이 0과 1의 관점에서 모든 머신과 미디어가이를 처리 할 수 ​​있다면 데이터가 ASCII 또는 Base64로 표시되면 어떻게 중요합니까?

"텍스트 데이터를 처리하도록 설계된 미디어"는 무엇을 의미합니까? 그들은 바이너리를 다룰 수 있습니다 => 그들은 무엇이든 다룰 수 있습니다.

고마워요, 이제 이해합니다.

데이터를 전송할 때 데이터가 의도 한 것과 동일한 형식으로 해석되는지 확신 할 수 없습니다. 따라서 양 당사자가 이해하는 Base64와 같은 형식으로 코딩 된 데이터를 전송합니다. 이렇게하면 발신자와 수신자가 동일한 내용을 다르게 해석하더라도 코딩 된 형식에 동의하기 때문에 데이터가 잘못 해석되지 않습니다.

에서 마크 바이어스 예

보내려면

Hello
world!

한 가지 방법은 ASCII와 같이 ASCII로 보내는 것입니다.

72 101 108 108 111 10 119 111 114 108 100 33

그러나 바이트 10은 다른 쪽 끝에서 줄 바꿈으로 올바르게 해석되지 않을 수 있습니다. 따라서 ASCII의 하위 집합을 사용하여 다음과 같이 인코딩합니다.

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

동일한 양의 정보에 대해 더 많은 데이터가 전송되는 대신, 수신자가 나머지 문자 세트에 대해 다른 해석을 수행하더라도 수신자가 의도 된 방식으로 데이터를 디코딩 할 수 있습니다.

첫 번째 실수는 ASCII 인코딩과 Base64 인코딩이 상호 교환 가능하다는 생각입니다. 그들은 아닙니다. 그것들은 다른 목적으로 사용됩니다.

• 텍스트를 ASCII로 인코딩하면 텍스트 문자열로 시작하여 일련의 바이트로 변환합니다.
• Base64로 데이터를 인코딩 할 때 일련의 바이트로 시작하여 텍스트 문자열로 변환합니다.

Base64가 처음 필요한 이유를 이해하려면 약간의 컴퓨팅 역사가 필요합니다.

컴퓨터는 이진수 (0과 1)로 통신하지만 사람들은 일반적으로 텍스트 나 이미지와 같은보다 풍부한 형식의 데이터와 통신하기를 원합니다. 컴퓨터간에이 데이터를 전송하려면 먼저 0과 1로 인코딩 한 다음 전송 한 다음 다시 디코딩해야합니다. 텍스트를 예로 들어이 인코딩을 수행하는 방법에는 여러 가지가 있습니다. 단일 인코딩에 모두 동의 할 수 있다면 훨씬 간단하지만 슬프게도 그렇지 않습니다.

원래 ASCII가 문자 당 7 비트의 표준이 될 때까지 문자 당 다른 비트 수를 사용 하는 많은 다른 인코딩 (예 : Baudot 코드 ) 이 만들어졌습니다 . 그러나 대부분의 컴퓨터는 이진 데이터를 각각 8 비트로 구성된 바이트로 저장하므로 ASCII 는 이러한 유형의 데이터를 전송하는 데 적합하지 않습니다. 일부 시스템은 가장 중요한 비트를 지울 수도 있습니다. 또한 시스템 간 줄 끝 인코딩의 차이점은 ASCII 문자 10 및 13도 때때로 수정되었음을 의미합니다.

이러한 문제를 해결하기 위해 Base64 인코딩이 도입되었습니다. 이를 통해 임의의 바이트를 손상없이 전송하기에 안전한 바이트 (ASCII 영숫자 문자 및 두 개의 기호)로 인코딩 할 수 있습니다. 단점은 Base64를 사용하여 메시지를 인코딩하면 길이가 증가한다는 것입니다. 데이터의 3 바이트마다 4 개의 ASCII 문자로 인코딩됩니다.

텍스트를 보내려면 확실하게 당신이 할 수있는 첫번째 다음 (예를 들어, UTF-8) 선택의 텍스트 인코딩하여 바이트 인코딩 후 Base64로 ASCII로 인코딩 전송하는 것이 안전 텍스트 문자열로 생성 된 바이너리 데이터를 인코딩합니다. 수신자는 원본 메시지를 복구하기 위해이 과정을 반대로해야합니다. 물론 수신자는 어떤 인코딩이 사용되었는지 알고 있어야하며,이 정보는 종종 별도로 전송해야합니다.

지금까지는 전자 메일 서버가 줄 끝을 수정할 수있는 전자 메일 메시지에서 이진 데이터를 인코딩하는 데 사용되었습니다. 보다 현대적인 예는 Base64 인코딩을 사용하여 이미지 소스를 HTML 소스 코드에 직접 포함시키는 것 입니다. 여기서 '<'및 '>'와 같은 문자가 태그로 해석되지 않도록 데이터를 인코딩해야합니다.

다음은 실제 예입니다.

두 줄로 문자 메시지를 보내려고합니다.

여보세요
세계!

ASCII (또는 UTF-8)로 보내면 다음과 같습니다.

72 101 108 108 111 10 119 111 114 108 100 33

바이트 10은 일부 시스템에서 손상되어 64 바이트를 Base64 문자열로 기본 인코딩 할 수 있습니다.

SGVsbG8sCndvcmxkIQ ==

ASCII를 사용하여 인코딩하면 다음과 같습니다.

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

여기의 모든 바이트는 안전한 바이트로 알려져 있으므로 시스템이이 메시지를 손상시킬 가능성은 거의 없습니다. 원본 메시지 대신 이것을 보내면 수신자가 원래 메시지를 복구하는 프로세스를 되돌릴 수 있습니다.

이진 데이터를 XML로 인코딩

XML 문서 내에 몇 개의 이미지를 포함 시키려고한다고 가정하십시오. 이미지는 이진 데이터이고 XML 문서는 텍스트입니다. 그러나 XML은 포함 된 이진 데이터를 처리 할 수 ​​없습니다. 어떻게합니까?

한 가지 옵션은 base64에서 이미지를 인코딩하여 이진 데이터를 XML이 처리 할 수있는 텍스트로 변환하는 것입니다.

대신에:

<images>
  <image name="Sally">{binary gibberish that breaks XML parsers}</image>
  <image name="Bobby">{binary gibberish that breaks XML parsers}</image>
</images>

당신은 :

<images>
  <image name="Sally" encoding="base64">j23894uaiAJSD3234kljasjkSD...</image>
  <image name="Bobby" encoding="base64">Ja3k23JKasil3452AsdfjlksKsasKD...</image>
</images>

그리고 XML 파서는 XML 문서를 올바르게 구문 분석하고 이미지 데이터를 추출 할 수 있습니다.

현재 Base64를 정의하는 RFC를 보지 않겠습니까?

데이터의 기본 인코딩은 여러 상황에서
레거시 이유로 인해 US-ASCII [1] 데이터로 제한되는 환경에서 데이터 를 저장하거나 전송 하는 데 사용되며 레거시 제한이없는 새로운 응용 프로그램에서도 사용할 수 있습니다. 텍스트 편집기로 개체를 조작 할 수 있기 때문입니다.

과거에는 응용 프로그램마다 요구 사항이 다르기 때문에 때때로 약간 다른 방식으로 기본 인코딩을 구현했습니다. 오늘날 프로토콜 사양은 일반적으로 정확한 설명이나 참조없이 일반적으로 기본 인코딩, 특히 "base64"를 사용합니다. MIME (Multipurpose Internet Mail Extensions) [4]는 줄 바꿈 또는 알파벳이 아닌 문자의 결과를 고려하지 않고 base64에 대한 참조로 자주 사용됩니다. 이 사양의 목적은 일반적인 알파벳 및 인코딩 고려 사항을 설정하는 것입니다. 이로 인해 다른 문서의 모호성이 줄어들어 상호 운용성이 향상 될 것입니다.

Base64는 원래 이진 데이터를 다목적 인터넷 메일 확장의 일부로 전자 메일에 첨부 할 수 있도록 고안되었습니다.

텍스트 데이터 용으로 설계된 미디어는 물론 이진 파일이지만 텍스트 미디어는 종종 제어 문자에 특정 이진 값을 사용합니다. 또한 텍스트 미디어는 특정 이진 값을 텍스트가 아닌 것으로 거부 할 수 있습니다.

Base64 인코딩은 이진 데이터를 텍스트 미디어의 텍스트로만 해석 할 수있는 값으로 인코딩하며 특수 문자 및 / 또는 제어 문자가 없으므로 데이터가 텍스트 미디어에서도 보존됩니다.

미디어 가 문자열 인코딩의 유효성을 검사 하는 것이 더 많으므로 처리 응용 프로그램에서 데이터를 수용 할 수 있도록하려고합니다 (예 : EOL을 나타내는 이진 시퀀스가 ​​포함되어 있지 않음)

UTF-8 인코딩을 사용하여 전자 메일로 이진 데이터를 보내려고한다고 가정합니다. 1과 0의 스트림이 UTF-8 인코딩의 유효한 유니 코드가 아닌 시퀀스 를 만드는 경우 전자 메일이 올바르게 표시되지 않을 수 있습니다 .

URL 자체에서 URL에 유효하지 않은 문자를 인코딩하려는 경우 URL에서 동일한 유형의 일이 발생합니다.

http://www.foo.com/hello 내 친구-> http://www.foo.com/hello%20my%20friend

공간이 냄새가 나는 것으로 생각되는 시스템을 통해 공간을 보내려고하기 때문입니다.

우리가하고있는 일은 알려진 양호하고 수용 가능하며 비 영향적인 비트 시퀀스와 다른 리터럴 비트 시퀀스간에 일대일 매핑이 있고 처리 응용 프로그램 이 인코딩을 구별하지 않는 것 입니다.

귀하의 예 man에서 첫 번째 형식의 유효한 ASCII 일 수 있습니다. 그러나 종종 임의의 이진 값을 전송하고 싶을 수도 있습니다 (예 : 이메일로 이미지 전송).

MIME 버전 : 1.0
내용 설명 : "a.gif의 Base64 인코딩"
내용 유형 : image / gif; name = "a.gif"
콘텐츠 전송 인코딩 : Base64
콘텐츠 처리 : attachment; filename = "a.gif"

여기서 GIF 이미지는 base64에서 이메일 덩어리로 인코딩됩니다. 이메일 클라이언트는 헤더를 읽고 디코딩합니다. 인코딩으로 인해 GIF에 프로토콜로 해석 될 수있는 내용이 포함되어 있지 않으며 SMTP 또는 POP에서 중요한 데이터를 삽입하지 않도록 할 수 있습니다.

특수 문자를 이스케이프 처리하는 대신 Base64

매우 다르지만 실제 예를 들어 보겠습니다. 브라우저에서 실행할 자바 스크립트 코드를 작성합니다. HTML 태그에는 ID 값이 있지만 ID에서 어떤 문자가 유효한 지에 대한 제약이 있습니다.

그러나 내 ID가 파일 시스템의 파일을 손실없이 참조하기를 원합니다. 실제로 파일은 느낌표, 악센트 부호가있는 문자, 물결표, 심지어 이모티콘에서 모든 종류의 이상하고 멋진 문자를 포함 할 수 있습니다! 나는 이것을 할 수 없다 :

<div id="/path/to/my_strangely_named_file!@().jpg">
    <img src="http://myserver.com/path/to/my_strangely_named_file!@().jpg">
    Here's a pic I took in Moscow.
</div>

다음과 같은 코드를 실행하고 싶다고 가정 해보십시오.

# ERROR
document.getElementById("/path/to/my_strangely_named_file!@().jpg");

이 코드는 실행될 때 실패한다고 생각합니다.

Base64를 사용하면 어떤 언어가 어떤 특수 문자를 허용하고 어떤 문자를 이스케이프해야하는지 걱정할 필요없이 복잡한 것을 참조 할 수 있습니다.

document.getElementById("18GerPD8fY4iTbNpC9hHNXNHyrDMampPLA");

MD5 또는 다른 해싱 함수를 사용하는 것과 달리, 인코딩을 반대로하여 데이터가 실제로 유용한 것이 무엇인지 알아낼 수 있습니다.

Base64 년 전에 알고 있었으면 좋겠습니다. 나는 ' encodeURIComponent'로 머리를 찢어 버리지 않았을 것입니다.str.replace(‘\n’,’\\n’)

텍스트의 SSH 전송 :

ssh를 통해 복잡한 데이터를 전달하려는 경우 (예 : 도트 파일을 사용하여 셸 개인화를 얻을 수 있음) Base 64없이 수행하는 것이 좋습니다. Base 64로 수행하는 방법입니다 (SCP를 사용할 수 있음, 그러나 그것은 여러 명령을 취할 것입니다-서버에 sshing하기위한 키 바인딩을 복잡하게 만듭니다) :

• https://superuser.com/a/1376076/114723

내가 편리하다고 생각했을 때의 예는 XML에 이진 데이터 를 포함 하려고 할 때였습니다 . 이진 데이터 중 일부는 SAX 파서에 의해 잘못 해석되었습니다. 해당 데이터는 문자 그대로 XML 특수 문자를 포함하여 모든 것이 될 수 있기 때문입니다. 송신단에서 데이터를 인코딩하고 수신단에서 디코딩하는 Base64는 그 문제를 해결했다.

대부분의 컴퓨터는 8 비트 이진 형식으로 데이터를 저장하지만 반드시 그럴 필요는 없습니다. 일부 기계 및 전송 매체는 한 번에 7 비트 만 처리 할 수 ​​있습니다. 이러한 매체는 스트림을 7 비트의 배수로 해석하므로 8 비트 데이터를 보내면 다른 쪽에서 예상 한 것을받지 못합니다. Base-64는이 문제를 해결하는 한 가지 방법입니다. 입력을 6 비트 형식으로 인코딩하고 매체를 통해 전송 한 다음 수신 측에서 8 비트 형식으로 다시 디코딩합니다.

7 비트 ASCII 만 지원하는 기존 시스템을 무시하더라도 다른 (약간의 긴) 답변 외에도 텍스트 모드에서 이진 데이터를 제공 할 때의 기본 문제는 다음과 같습니다.

• 개행은 일반적으로 텍스트 모드에서 변환됩니다.
• NUL 바이트를 텍스트 문자열의 끝으로 취급하지 않도록주의해야합니다. 이는 C 계보가있는 모든 프로그램에서 수행하기가 너무 쉽습니다.

"텍스트 데이터를 처리하도록 설계된 미디어"는 무엇을 의미합니까?

이러한 프로토콜은 바이너리 데이터 (.png 및 .jpg 이미지) 대신 텍스트 (종종 영어 텍스트 만)를 처리하도록 설계되었습니다 .

그들은 바이너리를 다룰 수 있습니다 => 그들은 무엇이든 다룰 수 있습니다.

그러나 그 반대는 사실이 아닙니다. 텍스트를 나타내도록 설계된 프로토콜은 다음을 포함하는 이진 데이터를 부적절하게 취급 할 수 있습니다.

• 바이트 단위 0x0A 및 0x0D는 라인 엔딩에 사용되며 플랫폼마다 다릅니다.
• 0x00 (NULL = C 문자열 종결 자), 0x03 (텍스트 끝), 0x04 (전송 끝) 또는 0x1A (DOS 파일 끝)와 같은 다른 제어 문자는 데이터의 끝을 조기에 알릴 수 있습니다.
• 0x7F보다 높은 바이트 (ASCII 용으로 설계된 프로토콜 인 경우)
• 유효하지 않은 UTF-8 바이트 시퀀스.

따라서 텍스트 기반 프로토콜을 통해 이진 데이터를 보낼 수는 없습니다. 공백이 아닌 비 제어 ASCII 문자를 나타내는 바이트로 제한되며 그 중 94가 있습니다. Base 64가 선택된 이유는 2의 거듭 제곱으로 작업하는 것이 더 빠르기 때문에 64가 가장 큰 것입니다. .

하나의 질문입니다. 시스템이 여전히 일반적인 UTF-8과 같은 일반적인 인코딩 기술에 어떻게 동의하지 않습니까?

웹상에서 그들은 적어도 대부분 가지고 있습니다. 대부분의 사이트에서 UTF-8을 사용합니다 합니다.

서구의 문제는 1 바이트 = 1 문자이며 UTF-8에서 작동 할 수없는 오래된 소프트웨어가 많이 있다는 것입니다.

동방의 문제는 GB2312 및 Shift_JIS와 같은 인코딩에 대한 첨부 파일입니다.

그리고 Microsoft가 여전히 잘못된 UTF 인코딩을 선택하지 않은 것 같습니다. Windows API 또는 Microsoft C 런타임 라이브러리를 사용하려는 경우 UTF-16 또는 로케일의 "ANSI"인코딩으로 제한됩니다. 이것은 항상 변환해야하기 때문에 UTF-8을 사용하는 것이 고통 스럽습니다.

왜 / 우리는 Base64 인코딩을 어떻게 사용합니까?

Base64는 75 % 효율을 갖는 이진-텍스트 인코딩 체계 중 하나입니다. 이미지와 같은 일반적인 이진 데이터가 레거시 "8 비트 클린이 아닌"채널을 통해 안전하게 전송 될 수 있도록 사용됩니다. 초기 이메일 네트워크 (1990 년대 초까지)에서 대부분의 이메일 메시지는 7 비트 US-ASCII 문자 세트의 일반 텍스트였습니다. 많은 초기 통신 프로토콜 표준은 "8 비트 클린이 아닌" "7 비트"통신 링크에서 작동하도록 설계되었습니다. 체계 효율은 입력의 비트 수와 인코딩 된 출력의 비트 수 사이의 비율입니다. 16 진법 (Base16)은 50 % 효율의 이진-텍스트 인코딩 체계 중 하나입니다.

Base64 인코딩 단계 (간체) :

1. 이진 데이터는 각각 24 비트 (3 바이트)의 연속 청크로 배열됩니다.
2. 각 24 비트 청크는 각각 6 비트의 네 부분으로 그룹화됩니다.
3. 각 6 비트 그룹은 해당 Base64 문자 값으로 변환됩니다. 즉, Base64 인코딩은 3 개의 옥텟을 4 개의 인코딩 된 문자로 변환합니다. 출력 바이트와 입력 바이트의 비율은 4 : 3 (33 % 오버 헤드)입니다.
4. 흥미롭게도, 동일한 문자는 4 개의 문자를 생성하도록 인코딩 된 3 옥텟 그룹 내의 위치에 따라 다르게 인코딩 될 것이다.
5. 수신자는 원본 메시지를 복구하기 위해이 과정을 반대로해야합니다.

"텍스트 데이터를 처리하도록 설계된 미디어"는 무엇을 의미합니까?

ASCII가 비 ASCII 값을 다루는 세계를 지배하던 시절에는 골치 아픈 일이었습니다. 사람들은 정보를 잃지 않고 전선을 통해 전송되도록 모든 종류의 농구대를 뛰어 넘었습니다.