문제

단순한 예 또는 아니오 의문의 여지가 있습니다. 90%는 그것이 아니라고 확신하지만 ... 확실하지 않습니다.

Base64 문자열에 탭이 포함될 수 있습니까?

도움이 되었습니까?

해결책

그것은 당신이 요구하는 것에 달려 있습니다. 탭이 Base-64 인코딩 될 수 있는지 여부를 묻는 경우 다른 ASCII 문자와 동일하게 취급 될 수 있기 때문에 대답은 "예"입니다.

그러나 Base-64 출력에 탭이 포함될 수 있는지 여부를 묻는 경우 답은 아니오입니다. 다음 링크는 어떤 문자가 유효한 것으로 간주되는지를 포함하여 기본 64를 자세히 설명하는 기사입니다.

http://en.wikipedia.org/wiki/base64

다른 팁

짧은 대답은 아니요. 그러나 Base64에는 캐리지 반환도 포함 할 수 없습니다.

그렇기 때문에 여러 줄의 Base64 라인이있는 경우 캐리지 리턴, 라인 피드 및 Base64 Alphabet에없는 다른 모든 것을 제거합니다.

여기에는 탭이 포함됩니다.

에서 wikipedia.com :

PEM의 현재 버전 (RFC 1421에 지정됨)은 상단 및 소문자 로마 알파벳 문자 (A – Z, A – Z), 숫자 (0-9) 및 "+로 구성된 64 자식 알파벳을 사용합니다. "및"/"기호. "="기호는 특수 접미사 코드로도 사용됩니다. 원래 사양 인 RFC 989는 추가로 "*"기호를 사용하여 출력 스트림 내에서 인코딩되었지만 암호화되지 않은 데이터를 구분했습니다.

보시다시피 탭 문자는 포함되지 않습니다. 그러나 물론 탭 문자를 Base64 문자열로 인코딩 할 수 있습니다.

확신하는. 탭은 ASCII 문자 9이며 다른 정수와 마찬가지로 Base64 표현이 있습니다.

하하, 당신이 응답에서 볼 수 있듯이, 이것은 실제로 간단한 예 아니오 대답이 아닙니다.

결과적으로 변환 후 Base64 문자열은 탭 문자를 포함 할 수 없지만, 당신이 그렇게 요구하지 않는 것 같습니다. Base64에 탭을 포함하는 문자열 (변환 전에)을 나타내는 것 같습니다. 그렇습니다.

나는 당신이해야 할 일이 당신이 당신의 문자열의 인코딩을 보존하기 위해주의를 기울이는 것인지, 즉 올바른 인코딩 (Unicode, UTF-8)이있는 바이트 배열로 변환 한 다음 해당 배열을 변환하는 것입니다. 바이트에서베이스 64.

편집 : 간단한 테스트.

private void button2_Click(object sender, EventArgs e)
{
  StringBuilder sb = new StringBuilder();
  string test = "The rain in spain falls \t mainly on the plain";
  sb.AppendLine(test);
  UTF8Encoding enc = new UTF8Encoding();
  byte[] b = enc.GetBytes(test);
  string cvtd = Convert.ToBase64String(b);
  sb.AppendLine(cvtd);
  byte[] c = Convert.FromBase64String(cvtd);
  string backAgain = enc.GetString(c);
  sb.AppendLine(backAgain);
  MessageBox.Show(sb.ToString());
}

Base64 사양 (RFC 4648) 상태 섹션 3.3 다른 사양에 의해 명시 적으로 허용되지 않는 한, 비 알파벳 문자가 발생하지 않으면 거부해야합니다.

인코딩 된 데이터가 포함 된 경우 구현은 인코딩 된 데이터를 거부해야합니다
베이스 인코딩을 해석 할 때베이스 알파벳 외부의 문자
이 문서를 언급하는 사양이 명시 적으로 명시 적으로 표시되지 않는 한 데이터. 이러한 사양은 대신 MIME과 마찬가지로 기본 인코딩 알파벳 외부의 문자는 데이터를 해석 할 때 단순히 무시되어야한다는 것을 명시 할 수 있습니다 ( "수용 할 수있는 곳에서 자유 롭다"). 이것은 인접한 캐리지 리턴/ 라인 피드 (CRLF) 문자가 "비 알파벳 문자"를 구성하고 무시된다는 것을 의미합니다.

PEM과 같은 사양 (RFC 1421) 및 마임 (RFC 2045) Base64 문자열을 공백으로 분해 할 수 있음을 지정하십시오. 참조 당 RFC 822, 탭 (HTAB)은 공백 문자로 간주됩니다.

따라서 Base64가 MIME 또는 PEM (및 기타 유사한 사양)의 맥락에서 사용될 때, 인코딩 된 컨텐츠를 디코딩하면서 탭을 포함한 공백을 처리 (제거)해야합니다.

Convert.FromBase64String() .NET 프레임 워크에서는 신경 쓰지 않는 것 같습니다. 문자열의 모든 공백은 무시된다고 생각합니다.

string xxx = "ABCD\tDEFG";   //simulated Base64 encoded string w/added tab
Console.WriteLine(xxx);
byte[] xx = Convert.FromBase64String(xxx); // convert string back to binary
Console.WriteLine(BitConverter.ToString(xx));

산출:

ABCD    DEFG
00-10-83-0C-41-46

관련 조항 RFC-2045 (6:8)

인코딩 된 출력 스트림은 각각 76 자 이하의 라인으로 표시되어야합니다. 표 1에서 찾을 수없는 모든 라인 브레이크 또는 기타 문자는 무시해야합니다. 소프트웨어 디코딩으로. Base64 데이터에서 표 1의 문자 이외의 문자 라인 파손 및 기타 공백 아마도 어떤 상황에서는 경고 메시지 나 메시지 거부가 적절할 수있는 전송 오류를 나타낼 수 있습니다.

예!

Base64는 안전한 문자 세트를 사용하여 8 비트 값 (10 진수 0 ~ 255)을 문자열로 인코딩하는 데 사용됩니다. 탭은 10 진수 9입니다.

기본 64는 다음 문자 세트 중 하나를 사용합니다.

Data: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
URLs: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

텍스트의 이진 첨부 파일 (예 : 이메일) 도이 시스템을 사용하여 인코딩됩니다.

여기에는 많은 혼란이있는 것 같습니다. 놀랍게도 대부분의 대답은 "아니오"다양성입니다. 나는 그것이 좋은 표준 대답이라고 생각하지 않습니다. 혼란의 이유는 아마도 Base64가 엄격하게 지정되지 않았다는 사실 일 것입니다. 여러 실질적인 구현 및 해석이 존재합니다. 체크 아웃 할 수 있습니다 링크 텍스트 이것에 대한 자세한 내용은.

그러나 일반적으로 Base64 Codec은 일부 Base64 정의 (76 자 세그먼트, LineFeed 등)에 의해 의무화되어 라인 피드를 이해해야합니다. 이로 인해 대부분의 디코더는 들여 쓰기 공백을 허용하며, 일반적으로 4 자 "트리플렛"(3 바이트를 인코딩하기 때문에 명명) 사이의 모든 공백을 가능하게합니다.

따라서 실제로는 탭 및 기타 공백을 사용할 수 있습니다.

그러나 서비스에 전송 된 Base64 컨텐츠를 생성하는 경우 탭을 직접 추가하지 않을 것입니다. 귀하가 보내는 내용에 대해 보수적으로 보수적으로 보수적으로하십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top