Base64 형식을 다루어야 하나요? 그러면 여러분에게 이 웹사이트가 딱 맞네요! 저희 웹사이트의 아주 편리한 온라인 도구를 사용하여 데이터를 인코딩하거나 디코딩해보세요.

Perl에서의 Base64 인코딩: 완전한 가이드

당신에게는, 그것을 싫어하는 채널을 살아남아야 하는 데이터가 있습니다. JSON 필드에 자리를 잡아야 하는 바이너리 덩어리. HTML 태그 안에 살아야 하는 이미지. 설정 파일에 속하는 인증서. URL, 헤더, 쿼리 스트링을 지나가야 하는 토큰. 이것이 바로 Base64 인코딩의 일상입니다. 모든 원시 데이터 3바이트를 64글자 알파벳의 4문자로 다시 쓰며, = 기호 하나 또는 둘로 꼬리를 마무리하니, 결과는 무엇이든 나를 수 있는 평문 텍스트가 됩니다. 당신이 시작한 것보다 보통 33퍼센트쯤 더 길어지는 형태로요. 이 사이트의 홈 페이지는 포맷을 끝까지 상세히 설명해 주므로, 이 글은 Perl이 당신에게 무엇을 주는지, 그것이 당신을 대신해 조용히 무엇을 결정하는지, 그리고 함정이 어디 있는지에 집중합니다.

좋은 소식부터: encode_base64는 2002년부터 Perl 코어에 살아 있고, C로 구현되어 있으며, 확실히 빠릅니다. 흥미로운 부분은, 이 함수는 주장이 있다는 점입니다. 출력을 76자에서 줄바꿈하고, 끝에서 줄바꿈을 덧붙이며, 먼저 바이트로 변환하지 않은 Unicode 문자는 인코딩해 주지 않습니다. Latin-1 범위를 넘으면 아예 죽고, 그 아래선 Latin-1 바이트라는 가정으로 조용히 굴러갑니다. 이 가이드는 Perl 개발자가 실제로 만들어 내는 Base64의 모든 맛을 지나갑니다. 원라이너, MIME 래핑된 이메일 본문, PEM 래핑된 키, URL-safe 토큰, 그리고 메모리에 담기 너무 큰 파일을 위한 스트리밍 버전까지.

함수 하나, 숨겨진 줄바꿈

전체 API, 현대 문서가 제시하는 대로 그대로:

encode_base64( $bytes )
encode_base64( $bytes, $eol )

한 번 더 읽어 보세요. 인자 두 개, 그중 하나는 선택적, 반환값 하나, 플래그 없음. 선택인 두 번째 인자는 줄바꿈 시퀀스이고, 기본값은 그냥 줄바꿈입니다. 이것은 Perl에서 가장 무해해 보이는 호출이, 줄바꿈되고 줄바꿈으로 끝나는 출력을 만들어 낸다는 뜻입니다:

use MIME::Base64 qw(encode_base64);
my $wrapped = encode_base64("Aladdin:open sesame");
print length($wrapped), "\n";  # 29: 28자 + 줄바꿈 하나
my $single = encode_base64("Aladdin:open sesame", "");
print length($single), "\n";   # 28: 래핑이 없도록 빈 문자열을 전달

출력 크기는 호출 전에 예측할 수 있는 고정 패턴을 따릅니다:

입력 바이트 출력 문자 패딩
0 0 없음
1 4 = 둘
2 4 = 하나
3 4 없음
100,000 133,336 없음, 한 줄에
3,000,000 4,000,000 없음

패턴은, 온전한 3바이트 그룹마다 4문자, 그리고 마지막 부분 그룹을 = 기호 하나 또는 둘로 채우는 것입니다. 알아 둘 가치가 있는 한 가지 결과: 1바이트든 3바이트든 4문자가 나오므로, 인코딩된 길이는 정확한 입력 크기를 숨깁니다. 그리고 일을 하지 않고 크기가 필요하다면, 이 모듈은 2010년 3.10부터 길이 함수를 가지고 있습니다. 다만 기본적으로 내보내지 않으므로, 패키지 이름을 통해 호출합니다:

use MIME::Base64 ();
my $with_wrap   = MIME::Base64::encoded_base64_length($bytes);        # 76자 줄, 기본 eol
my $single_line = MIME::Base64::encoded_base64_length($bytes, "");    # 래핑 없음
my $mime_body   = MIME::Base64::encoded_base64_length($bytes, "\r\n");

외워야 할 규칙이 하나 더 있습니다. 인코더가 소리쳐 경고하는 유일한 방식이니까요: 건네는 문자열에 코드 255를 넘는 문자가 있으면, encode_base64는 서브루틴 진입 시 와이드 문자와 함께 죽습니다. 그 아래선 실패가 더 조용합니다. 255 이하의 문자는 Latin-1 바이트로 조용히 격하되므로, 변환을 건너뛴 발음 기호 문자열은 UTF-8 대신 Latin-1로 인코딩되고, 아무도 당신에게 말하지 않습니다. Base64 인코딩은 단일바이트 문자에 대해서만 정의되어 있고, Perl 5.8 이상은 문자열에 확장 문자를 허용하므로, 변환은 Encode를 써서 당신이 의도적으로 내리는 결정입니다. 바로 다음 섹션에서요.

텍스트인가 바이트인가? 함수가 대신 해 줄 수 없는 단계

Perl의 문자열은 그것이 문자를 담고 있는지 바이트를 담고 있는지를 말하는 조용한 플래그를 품고 있으며, Base64는 그 경계의 바이트 쪽에 살아 있습니다. 당신의 텍스트가 문자열이라면 - JSON 파서, 템플릿, UTF-8 소스 파일에서 온 발음 기호가 있는 리터럴에서 나온 순간이 바로 그렇습니다 - 인코더는 Latin-1 범위를 넘는 문자에 대해 당신이 어떤 바이트를 의도했는지를 추측하기를 거부하고, 그것을 알려 줍니다. 그 범위 아래에서는 Latin-1이라는 추측을 조용히 합니다. 수선은 두 경우 모두 같고, Encode 모듈의 코어 함수 하나입니다:

use MIME::Base64 qw(encode_base64);
use Encode qw(encode);
my $chars = "H\x{eb}llo W\x{f6}rld";  # 문자열
my $utf8  = encode("UTF-8", $chars);  # 이제: 바이트
my $b64   = encode_base64($utf8, "");
print $b64, "\n";  # SMOrbGxvIFfDtnJsZA==

그 encode 호출이 바로 춤 전체입니다. 바이트 표현을 고르고(현대적인 것은 전부 UTF-8), 문자를 그 바이트로 변환하고, 그때서야 바이트를 인코더에 건네는 것. Windows 1252로 도착한 레거시 서양 텍스트의 경우, 변환은 이름만 다른 같은 함수, encode("Windows-1252", $legacy)로, 원래의 단일바이트 형태를 돌려 줍니다. Encode 모듈은 코어이므로, 이 모든 것이 공짜입니다.

이제 함정입니다. 당신이 가진 바이트가 이미 UTF-8인데, 그것을 UTF-8으로 만들어 주는 것이라고 생각하며 encode("UTF-8", ...)에 한 번 더 통과시켜 보면, 복본을 얻는 것이 아니라 이중 인코딩을 얻게 됩니다. 발음 기호가 붙은 글자마다 제법 두 개 글자로 부풀어 오르는 형태죠. 고전적인 증상은 Hëllo로 읽히던 텍스트가 이제 Hëllo로 읽히는 것인데, 인터넷의 모든 디코더가 그것을 당신을 위해 충실히 디코딩해 줄 겁니다:

use Encode qw(encode decode);
my $right = encode("UTF-8", "H\x{eb}llo");
my $wrong = encode("UTF-8", $right);  # 바이트를 문자로 다시 인코딩
print decode("UTF-8", $right), "\n";  # Hëllo
print decode("UTF-8", $wrong), "\n";  # Hëllo

이를 막아 주는 경험 법칙: 바이트는 정확히 한 번만 인코딩된다. 그리고 utf8::is_utf8()가 문자열이 경계의 어느 쪽에 있는지 보여 줍니다. 플래그가 세워져 있으면 당신은 문자를 가지고 있는 것이니 encode() 호출이 옳은 수이고, 세워져 있지 않으면 바이트를 가지고 있는 것이니 Base64를 향해 준비된 것입니다.

줄바꿈: 세 가지 변형, 하나의 규칙

기본 출력이 래핑되고 줄바꿈으로 끝나므로, 모든 인코딩 작업의 첫 번째 결정은 목적지 문제입니다. 이 문자열은 어디에 살게 될 것인가. 모든 것을 하나로 묶어 주는 사실은, 디코더가 줄바꿈을 아예 무시한다는 것입니다. RFC 2045는 디코딩 소프트웨어에 모든 줄바꿈과 알파벳 밖의 문자를 무시하라고 말하므로, 래핑은 줄 기반 도구와 사람을 위한 예의이지, 의미의 차이가 아닙니다. 실무에서의 세 가지 답:

줄바꿈 없음. 래핑을 끄고 만든 함수의 출력, 정확히 한 줄. URL, JSON 페이로드, 헤더, 데이터베이스 값, 그리고 줄바꿈이 버그가 되는 모든 곳에서 이것이 바로 당신이 원하는 것입니다. 'Base64만'이라고 묻는 대부분의 사람이 뜻하는 것도 이거죠:

my $single = encode_base64($bytes, "");

MIME: 76자에 CRLF. RFC 2045의 이메일 관례: 인코딩된 줄은 76자를 넘을 수 없으며, MIME 세계는 CRLF로 말합니다. 이것은 이 모듈 자신의 일이며, 두 번째 인자로 해 줍니다:

my $mime_body = encode_base64($bytes, "\r\n");

PEM: 64자에 LF. 키와 인증서는 더 짧은 64자 줄의 오래된 관례를 쓰며, 이 모듈은 스스로 그 폭을 만들 수 없으므로, 4줄짜리 헬퍼가 그 간극을 메웁니다:

sub wrap_lines {
  my ($text, $width) = @_;
  return join "\n", $text =~ /(.{1,$width})/g;
}
my $pem = "-----BEGIN CERTIFICATE-----\n"
        . wrap_lines(encode_base64($der, ""), 64) . "\n"
        . "-----END CERTIFICATE-----\n";

같은 헬퍼가 다른 64자 변형들에도 쓰입니다. RFC 7468의 PKIX 텍스트 인코딩과 OpenPGP 아머, 데이터 줄이 64자 폭이고 꼬리의 CRC24 체크섬 줄은 당신이 아니라 GnuPG가 덧붙이는 변형들이죠. 하나, 모든 것에 적용되는 함정: encode_base64는 마지막 줄이 정확히 폭을 채웠을 때도, 결과의 맨 끝에서 줄바꿈을 덧붙입니다. 하류 소비자가 그 꼬리 빈 줄에 걸려 삐걱거리면, 결과에 rtrim 호출 하나가 그것을 고칩니다.

URL-safe Base64: - 와 _ 알파벳

표준 알파벳에는 +와 /가 들어 있고, 둘 다 텍스트 파일 밖에서는 문제입니다. 폼 인코딩된 쿼리 스트링의 +는 당신의 애플리케이션이 보기 전에 이미 공백이 되고, /는 URL에서 경로 구분자입니다. 파일명과 토큰은 자기 나름의 불만이 있죠. RFC 4648의 5절은 URL- 및 파일명-safe 알파벳으로 이것을 해결합니다. 여기서 +는 -가 되고, /는 _가 되며, 꼬리의 = 패딩은 보통 빠집니다. RFC는 이것이 base64 인코딩과 같은 것으로 간주해서는 안 된다고 강조하므로, 대개 base64url이라고 불리는 별개의 포맷으로 취급하세요. Perl은 2010년 3.11 버전부터 이를 한 호출로 만들어 왔습니다:

use MIME::Base64 qw(encode_base64url);
my $seg = encode_base64url("sunset-42");
print $seg, "\n";  # c3Vuc2V0LTQy: 패딩 없음, 줄바꿈 없음

그 한 호출이 세 가지 변경을 전부 해 줍니다. 알파벳 교체, 패딩 없음, 줄바꿈 없음. 이미 표준 Base64를 가지고 있고 목적지가 URL-safe 변형을 원한다면, 문자열 조작 두 번이 제자리에서 변환합니다:

sub to_urlsafe {
  my ($b64) = @_;
  $b64 =~ tr{+/}{-_};
  return $b64 =~ s/=+\z//r;
}
my $seg = to_urlsafe(encode_base64($bytes, ""));

언제 쓸 것인가: JSON Web Token의 파트, OAuth의 state와 nonce 파라미터, URL 경로에 넣는 API ID, 주소 창이나 파일명을 견뎌야 하는 불투명한 키. CPAN에는 정확히 이를 위한 Data::UUID::Base64URLSafe가 있습니다. 언제 쓰지 말아야 하는가: 이메일 본문, PEM 아머, 그리고 반대편에 표준 알파벳 소비자가 있는 모든 곳. -와 _는 그쪽 어휘에 없으니까요. 그리고 두 알파벳을 조용히 섞지 마세요. URL-safe로 인코딩한 값은 어디서나, 영원히, URL-safe로 디코딩되어야 합니다. 3.11 이전의 Perl에는, Python의 urlsafe 코덱을 이식한 2006년의 독립 모듈 MIME::Base64::URLSafe가 urlsafe_b64encode를 제공합니다. 현대적인 어떤 Perl이든, 내장 함수가 옳은 도구입니다.

JWT 만들기: 모든 파트를 손으로

JSON Web Token은 현대 API에서 Base64의 선두 소비자이며, 앞 섹션의 URL-safe, 패딩 없는 변형을 씁니다. RFC 7515에 따라, 컴팩트 JWT는 점으로 나누어진 base64url 파트 3개입니다. 보호된 헤더, 페이로드, 서명. 손으로 하나 만들어 보는 것은 모든 움직이는 부품을 살펴보는 즐거운 방법입니다:

use MIME::Base64 qw(encode_base64url);
use JSON::PP qw(encode_json);
use Digest::SHA qw(hmac_sha256);
my $secret  = "correct-horse-battery-staple";
my $head    = encode_base64url(encode_json({ alg => "HS256", typ => "JWT" }));
my $claims  = encode_base64url(encode_json({ sub => "homer", role => "admin" }));
my $sig     = encode_base64url(hmac_sha256("$head.$claims", $secret));
my $jwt     = "$head.$claims.$sig";
print $jwt, "\n";  # 컴팩트 HS256 토큰. 각 JSON 파트 안의 키 순서는 실행마다 달라질 수 있다

살펴볼 가치가 있는 디테일이 3개 있습니다. 첫째, 코어 JSON::PP 모듈의 encode_json는 공백 없는 컴팩트 UTF-8 바이트를 내보내는데, 이것이 바로 JOSE 규격이 토큰 안에 원하는 것입니다. 둘째, 페이로드는 누구나 읽을 수 있으며, 이것은 설계 그대로입니다. JWT는 서명된 티켓이지 비밀이 아니므로, 기밀 값을 클레임에 넣지 마세요. 셋째, 서명은 원시 HMAC 바이트의 base64url 인코딩이므로, hmac_sha256는 어떤 16진수 포맷팅도 없이 그대로 인코더로 들어갑니다.

프로덕션에서는 서명을 손으로 만들지 않습니다. CryptX를 바탕으로 하는 CPAN 모듈 Crypt::JWT가 알고리즘 전체 세트로 JWS와 JWE를 구현합니다:

use Crypt::JWT qw(encode_jwt);
my $jwt = encode_jwt(
  payload => { sub => "homer", role => "admin" },
  alg     => "HS256",
  key     => $secret,
);

그리고 수신 측에서는, 공격자가 토큰을 더 약한 변형으로 뒤바꾸지 못하게 accepted_alg로 알고리즘을 고정하세요. decode_jwt(token => $jwt, key => $secret, accepted_alg => "HS256")는 서명을 검증하고, 실패하면 죽음을 선언합니다. 손으로 만드는 것은 이해를 위해 충분하고, 라이브러리는 돈을 위해 충분합니다.

HTTP: 인증 헤더, Data URI, WebSocket 핸드셰이크

Authorization: Basic 헤더는 가장 오래된 현역 사용 사례입니다. 콜론으로 이어 붙인 사용자 이름과 비밀번호를 한 줄로 인코딩하고, 스킴 단어를 앞에 붙이는 것. 빈 문자열인 두 번째 인자는 여기서 하중을 지고 있습니다. 헤더 필드 안의 꼬리 줄바꿈은 버그니까요:

use MIME::Base64 qw(encode_base64);
my $user = "alice";
my $pass = "s3cr3t";
my $header = "Basic " . encode_base64("$user:$pass", "");
print $header, "\n";  # Basic YWxpY2U6czNjcjN0

RFC 2397의 Data URI는 이미지를 위한 같은 아이디어입니다. 페이로드가 URL 안에 직접 앉아서, 그것을 가져오기 위한 두 번째 요청이 필요 없습니다. 바이너리 미디어는 ;base64 플래그를 쓰므로, 페이로드는 정확히 래핑을 끈 encode_base64의 출력입니다:

my $uri = "data:" . $mime_type . ";base64," . encode_base64($bytes, "");

다만, 트레이드오프는 실재합니다. 인코딩된 페이로드는 파일보다 33퍼센트쯤 커서, HTML 문서 자체가 커집니다. 브라우저는 파일 URL처럼 data URI를 캐시하지 않습니다. 캐시할 별개의 가져오기가 없으니, 모든 페이지 뷰마다 바이트가 문서의 일부로 다시 나가는 셈이고, RFC 자체도 data URI는 짧은 값에만 유용하다고 말합니다. 아바타, 아이콘, 작은 인라인 그래픽에는 쓰세요. 나머지는 전부 진짜 파일을 쓰세요. Base64를 조용히 사용하는 HTTP 구석이 또 하나 있습니다. RFC 6455의 WebSocket 핸드셰이크, 클라이언트가 무작위 16바이트의 Base64인 Sec-WebSocket-Key 헤더를 보내는 곳. Mojolicious 같은 프레임워크가 당신을 위해 해 주지만, 어느 날 와이어에서 그것을 보면, 이제 그것이 무엇인지 아시겠죠:

use MIME::Base64 qw(encode_base64);
my $key = encode_base64(pack("C16", map { int(rand 256) } 1 .. 16), "");
print length($key), "\n";  # 24: 무작위 16바이트, 4문자 그룹에 패딩

파일: 통째로 읽기, 57바이트 청크, 그리고 CLI

가장 단순한 인코딩 작업: 파일이 텍스트가 됩니다. Perl의 문자열은 바이트이므로, 찾아다녀야 할 바이너리 모드가 없습니다. :raw 레이어가 전부입니다. 원시로 열고, 읽고, 인코딩하고, 쓰세요:

use MIME::Base64 qw(encode_base64);
open my $in, "<:raw", $ARGV[0] or die $!;
local $/;
my $bytes = <$in>;
close $in;
open my $out, ">:raw", $ARGV[1] or die $!;
print {$out} encode_base64($bytes);
close $out;

:raw 레이어는 중요합니다. 없으면 Perl은 들어오고 나가는 길에서 바이트를 플랫폼 텍스트로 해석하려 하고, 기본 인코딩이 다른 시스템에서는, 바로 그 파일이 어딘가에서 열릴 때까지 보이지 않는 손상입니다. 저장소를 계획할 때 크기의 청구서를 기억하세요. 500KB 이미지는 670KB 텍스트 파일이 되고, 1GB 비디오는 1.33GB가 됩니다.

메모리에 담기 너무 큰 파일에는, 모듈 자신의 문서가 규칙을 줍니다. 57바이트의 배수 청크로 인코딩하라는 것. 57바이트의 데이터가 정확히 76자 줄 하나를 채우기 때문이고, 76은 57 곱하기 4를 3으로 나눈 값입니다. 그 경계에서 청킹하면, 스트림 한가운데 패딩을 절대 만나지 않습니다:

use MIME::Base64 qw(encode_base64);
open my $in, "<:raw", $ARGV[0] or die $!;
while (read($in, my $buf, 57 * 10)) {
  print encode_base64($buf);
}
close $in;

각 청크가 정확히 줄 경계에 착륙하고, 마지막, 어쩌면 짧은, 청크가 최종 패딩을 담당하며, 결과는 파일 전체를 통째로 읽고 한 번에 인코딩한 것과 바이트 단위 동일합니다. 다만 메모리 사용이 일정하죠. 그리고 아예 스크립트가 필요 없다면, 원라이너가 커버합니다. -0777가 입력을 통째로 읽고, 빈 문자열 인자가 출력을 한 줄에 유지합니다:

perl -MMIME::Base64 -0777 -ne 'print encode_base64($_, "")' < file > file.b64

이메일: MIME 본문과 첨부 파일

이메일은 Base64가 이름을 번 곳입니다. MIME 표준은 원시 텍스트로 안전하게 탈 수 없는 데이터는 Content-Transfer-Encoding: base64로, 76자를 넘지 않는 줄로 보내야 한다고 말합니다. MIME::Lite로 메일을 만들면, 전체가 인자 하나이며, 모듈이 인코딩도, 래핑도, 헤더도 당신을 위해 해 줍니다:

use MIME::Lite;
my $mime = MIME::Lite->new(
  From    => 'me@example.com',
  To      => 'you@example.com',
  Subject => 'A file',
  Type    => 'text/plain',
  Data    => 'The body text.',
);
$mime->attach(
  Type     => 'application/octet-stream',
  Data     => $bytes,
  Encoding => 'base64',
  Filename => 'hello.txt',
);

Encoding 인자가 바로 그 트리거입니다. MIME::Lite가 첨부 파일을 76자 줄로 Base64 인코딩합니다(모듈의 기본값인 맨 줄바꿈으로. 그것들을 CRLF로 바꾸는 것은 메일 전송 측이죠) 그리고 해당 파트에 맞는 Content-Transfer-Encoding 헤더를 찍어 줍니다. Email::MIME도 같은 입장을 가지고, 당신이 건네는 모든 첨부 파일을 원시 데이터 문자열로 Base64 인코딩합니다(그 문서의 말: '이 방식으로 만들어진 모든 파트는, 안전을 기하기 위해 base64로 인코딩됩니다'). 손으로 원시 MIME 메시지를 조립한다면, 동등한 것은 래핑 섹션의 두 줄, encode_base64($bytes, "\r\n")에 헤더 줄을 더한 것인데, 그것이 프로토콜 쪽 이야기 전체입니다.

데이터베이스, 설정과 환경 변수

데이터베이스: 컬럼이 임의의 바이트를 건드리지 않고 통과시키겠다는 보장을 할 수 없기 때문에, 바이너리 데이터가 Base64를 타고 TEXT 컬럼에 실려 다니는 일이 많습니다. 한 줄 형태를 저장하세요. 래핑된 형태는 절대. 그렇지 않으면 다음 SELECT가 값 한가운데 줄바꿈이 있는 문자열을 돌려 줄 테니:

use MIME::Base64 qw(encode_base64);
# $dbh는 이미 연결된 DBI 핸들
my $stmt = $dbh->prepare(q{UPDATE photos SET data = ? WHERE id = ?});
$stmt->execute(encode_base64($bytes, ""), 42);

설정 파일은 같은 모양입니다. 바이너리나 기밀 필드가 한 줄 Base64 문자열인 JSON 문서. 이것이 바로 두 번째 인자가 존재하는 이유입니다:

use JSON::PP qw(encode_json);
my $config = {
  api_key  => encode_base64($key_bytes, ""),
  logo_png => encode_base64($png_bytes, ""),
};
open my $fh, ">:raw", "app.json" or die $!;
print {$fh} encode_json($config);
close $fh;

환경 변수는 경고 한마디를 받을 가치가 있습니다. 환경 안의 작은 토큰에는 Base64가 충분하지만, 인코딩된 형태는 원래보다 33퍼센트 크고, 운영 체제는 각 인자에 상한을 둡니다. Linux에서는 한 문자열당 128KB, execve가 시행하며, 환경 변수의 큰 덩어리는 예의 바르게 실패하지 않습니다. 자식 프로세스는 태어나는 순간 난해한 에러와 함께 죽죠. 작은 값은 환경 변수에, 큰 값은 파일이나 데이터베이스에.

성능: 일을 하는 것은 Perl이 아니라 C

코어 모듈은 C로 구현되어 있고, 그 C는 1991년에 metamail을 위해 쓰인 코드로 거슬러 올라갑니다. 당신이 그 함의를 눈치채기 전까지는 재미있는 사실. 인코더는 30년간의 튜닝을 받아 온 것입니다. 현대적인 기계에서는 초당 기가바이트 속도로 데이터를 처리하는데, 이것은 보통 그것이 공급하는 디스크나 네트워크보다 빠릅니다. 그래서 Base64 자체는 거의 한 번도 병목이 되지 않습니다. 병목은 I/O가죠.

C 컴파일러가 없는 드문 시스템에는, CPAN의 순수 Perl 쌍둥이 MIME::Base64::Perl이 같은 기본 인터페이스를 제공합니다. 몇 배는 느리지만, 일상적인 워크로드에는 여전히 충분하죠. 그리고 두 가지 습관이 큰 작업을 예측 가능하게 지켜 줍니다. 통째로 읽기 대신 57바이트 청크로 스트림하고, 할당 전에 버퍼 크기를 encoded_base64_length로 잡는 것. 그러면 추측도, 재할당도 모두 피할 수 있습니다.

함정, 오후 피해 규모 순으로

함정들, 대략 물리는 순서대로:

함정 무슨 일이 일어나나 해결책
두 번째 인자를 잊는 것 출력은 76자 래핑에 꼬리 줄바꿈을 단 채 도착하고, 당신의 URL, JSON 필드, 헤더는 값 한가운데에서 부서진다 한 줄 출력을 위해 ""를 넘기고, 래핑을 기대하는 목적지에는 래핑을 유지
틀린 폭으로 래핑하는 것 PEM 소비자는 64자 줄을 기대하고 76자를 받거나, MIME 본문이 76자 한계를 넘는다 폭을 변형에 맞춰라: 없으면 "", MIME이면 "\r\n", PEM에는 헬퍼
와이드 문자의 죽음 선언 코드 255를 넘는 문자열은 요청 도중 서브루틴 진입 시 와이드 문자와 함께 죽는다 encode_base64 호출 전에, 문자를 먼저 Encode에 통과시켜라. 이름을 의도적으로 붙여
이중 인코딩 이미 UTF-8인 바이트를 encode("UTF-8", ...)로 다시 인코딩하면 Hëllo가 Hëllo가 된다 바이트는 정확히 한 번만 인코딩. 의심스러우면 utf8::is_utf8()를 확인
알파벳을 조용히 섞는 것 -와 _로 인코딩한 값이 표준 알파벳 디코더에 부딪히면 쓰레기로 돌아온다 값당 변형은 하나, 끝에서 끝까지. 경계에서 base64url 또는 표준을 골라
꼬리 줄바꿈 encode_base64는 마지막 줄이 정확히 차 있어도 eol을 덧붙이고, 엄격한 소비자는 빈 줄을 본다 소비자가 까다로우면 결과에 chomp 또는 rtrim
데이터베이스의 래핑된 값 줄바꿈이 TEXT 컬럼 안에 떨어지고, 다음 SELECT가 부서진 토큰을 돌려 준다 한 줄 형태를 저장. 래핑은 목적지에서만
큰 덩어리를 가진 환경 변수 33퍼센트 팽창에 OS의 인자당 한계가 더해져, 자식 프로세스가 태어나는 순간 난해한 에러와 함께 죽는다 작은 값은 환경 변수에, 큰 값은 파일이나 데이터베이스에
Base64가 보호라고 가정하는 것 이 포맷은 아무것도 숨기지 않으며, 공개 기록에는 사용자가 IMAP 교환을 붙여 넣었다가 우연히 비밀번호를 노출한 실제 사건들이 문서화되어 있다 출력은 만들어지는 순간부터 기밀로 취급하고, 로그에서 멀리 두어라
크기의 청구서 없이 계획하는 것 500KB 이미지는 670KB 텍스트가 되고, 확인하지 않은 저장소나 페이로드 한계가 물린다 확정하기 전에 원래 크기의 4/3을 예산에 잡아라

인코더가 말해주는 역사

Perl의 Base64 인코더는 1분을 할 만한 경력을 가지고 있으며, 그것은 최초의 웹 툴킷에서 시작됩니다:

  • libwww perl에서 태어났다. 인코더는 LWP::Base64로 생을 시작했습니다. Martijn Koster와 Joerg Reichelt가 썼고, Gisle Aas가 libwww perl에 MIME::Base64로 흡수했죠. 1997년 4월에는 자신의 CPAN 배포판으로 독립했는데, 버전 2.00, 변경 기록 항목은 그저 libwww perl 5.08 기반이라고만 적혀 있습니다.
  • 속도의 시대. 1998년 버전 2.07은 더 빠르고 더 똑똑한 디코더의 C 구현을 실었습니다. 당시로선 현대적인 Linux 기계에서 약 25퍼센트 빠랐고, 튜닝은 10년간 계속되었습니다.
  • Unicode의 시대. 2002년 Perl 5.8이 코드 255를 넘는 문자를 범상한 문자열에 들여왔고, 모듈은 단계적으로 답했습니다. 2001년 2.12는 인코딩 전에 UTF-8 문자열을 격하했고, 현대적인 서브루틴 진입 시 와이드 문자 죽음 선언은 인코더가 그 약속을 지킬 방식입니다. 같은 해 코어와 동기화한 2.13은 EBCDIC 지원을 함께 가져왔는데, Perl의 Base64가 아직 메인프레임에서 돌아간다는 일깨움입니다.
  • 명령줄의 시대. 2003년 2.14부터 2004년 3.05까지의 릴리스는 진짜 encode-base64 명령을 번들했습니다. 디코딩과 quoted-printable 쌍둥이와 함께. 2005년 3.06은 그 스크립트들을 별도의 MIME Base64 Scripts 배포판으로 옮겼습니다.
  • URL-safe의 도착. RFC 4648이 2006년 URL-safe 알파벳을 표준화했고, 같은 해 독립 MIME::Base64::URLSafe 모듈이 나타났으며, 코어 모듈은 2010년 3.11에서 encode_base64url 한 호출로 뒤를 이었습니다.
  • 현대 라인. 2020년 버전 3.16은 패키징을 다시 세우고 하한을 Perl 5.6으로 끌어올렸습니다. 현행 코어 Perl은 3.16 시리즈를 싣고 있고, 모듈은 코어 배포판 안에서 유지 관리되는데, 코어 모듈이 가질 수 있는 집 중 그만큼 안전한 집입니다.

재미 있는 사실, 특히 Perl

이 이야기를 좋은 이야기로 만들어 주는 흥미로운 사실들:

  • POD의 예시는 마법의 문구다. 1997년부터, 모듈 자신의 문서가 Aladdin:open sesame를 인코딩해 왔으므로, 문자열 QWxhZGRpbjpvcGVuIHNlc2FtZQ==는 거의 30년간 그 모듈의 명함이었죠.
  • 기본 줄바꿈은 당신이 예상하지 못한 그거다. MIME이 말하는 CRLF가 아니라, 그냥 \n입니다. RFC 자신의 관례는 두 번째 인자를 필요로 하고, 모듈은 프로그래머의 기본값을 싣고 다니지, 프로토콜의 기본값은 싣고 다니지 않죠.
  • 빈 문자열에는 특별한 규칙이 있다. 아무것도 인코딩하면 아무것도 돌아오고, 줄바꿈은 붙지 않습니다. 꼬리 eol 규칙의 유일한 문서화된 예외이며, 빈 파일이 깨끗하게 라운드 트립하는 이유입니다.
  • IMAP 사촌에게는 쉼표가 있다. RFC 3501의 메일박스 이름 변형은 알파벳에서 /를 쉼표로 바꾸므로, IMAP 서버에서 온 Base64 문자열에는 표준 디코더가 잡음으로 취급하는 글자가 들어 있을 수 있습니다.
  • 1991년 혈통은 진짜다. C 구현은 Bellcore의 1991년 메일 프로그램 metamail로 거슬러 올라가며, Perl 5가 태어나기 3년 전입니다. 그래서 모든 encode_base64 호출은 일부가 90년대 코드입니다.
  • 순수 Perl 쌍둥이에는 자기만의 이야기가 있다. 2004년 버전 3.00이 코어 모듈에서 순수 Perl 구현을 떨어뜨렸을 때, 변경 기록은 그것들을 XS 구현의 진짜 문제를 숨기는 부풀어 오름이라 부르고 MIME::Base64::Perl으로 재발행했는데, 거기서 아직 살아 있습니다.

그러니 다음에 원시 바이트가 텍스트만인 세계를 지나가야 한다면, 당신은 전체 이야기를 알고 있습니다. 함수 호출 하나가 일을 하고, 숨겨진 줄바꿈은 두 번째 인자로 내리는 결정이고, 와이드 문자의 죽음 선언은 인코더가 당신의 Unicode를 정직하게 지켜 주는 방식이며, URL-safe 변형은 2010년부터 한 호출이고, 파일은 57바이트 청크로 스트림되고, 33퍼센트의 청구서가 입장료입니다. 그리고 어느 날 반대 방향으로 여행을 해야 한다면, 글자의 문자열을 받아 원래 바이트를 되돌려 받아야 한다면, 아래에서 링크된 Perl에서의 Base64 디코딩 관련 글이 그 의례를 같은 깊이로 다룹니다.

마지막 업데이트: 2026-09-08

관련 문서: Perl에서의 Base64 디코딩: 완전한 가이드