Quoted-Printable 인코딩 변환기

ASCII는 그대로 두고 나머지 바이트만 =XX로 적는 이메일 인코딩입니다. RFC 2045 §6.7에 정의되어 있으며, 영문이 많은 본문에서는 Base64보다 사람이 알아보기 쉽습니다. 이메일 원문(.eml)을 열었을 때 =EC=95=88 같은 것이 줄줄이 보인다면 이 방식입니다.

줄바꿈이 아니라 다음 줄로 이어진다는 표시입니다. Quoted-Printable은 한 줄이 =를 포함해 76자를 넘을 수 없어서, 넘치면 그 자리에서 끊고 =를 붙입니다. 디코딩할 때 =와 뒤따르는 줄바꿈을 통째로 지워야 원문이 돌아옵니다. 원문에 실제로 있던 줄바꿈과 구별하지 못하면 문단이 뭉개지거나 없던 줄바꿈이 생깁니다.

한 글자가 UTF-8로 3바이트이고, 바이트마다 =XX 세 글자가 붙어 정확히 세 배가 되기 때문입니다. 안녕하세요 다섯 글자는 15바이트라 =EC=95=88=EB=85=95=ED=95=98=EC=84=B8=EC=9A=94로 45자가 됩니다. Base64는 3바이트를 4글자로 담아 1.33배이므로, 한글이 많은 메일은 Base64를 쓰는 편이 훨씬 짧습니다.

메일 서버가 줄 끝 공백을 조용히 잘라 버리기 때문입니다. 인코딩해 두지 않으면 원문이 소리 없이 바뀝니다. 그래서 공백과 탭은 줄 한가운데서는 그대로 두지만 줄 끝에서는 반드시 =20, =09로 적습니다. RFC가 정한 규칙이며 이 변환기도 그대로 따릅니다.

=가 이스케이프 문자 자신이기 때문입니다. 그대로 두면 뒤따르는 두 글자를 16진수로 읽어 버리므로 예외 없이 =3D로 적어야 합니다. 3D는 =의 ASCII 코드 61을 16진으로 쓴 것입니다.

원문을 여기에 붙여 넣고 디코딩해 보면 인코딩 문제인지 문자셋 문제인지 갈립니다. =XX가 보이는데 글자가 안 나오면 Quoted-Printable 자체는 맞는데 문자셋이 UTF-8이 아닐 수 있고, =XX가 아예 없는데 깨졌다면 다른 원인입니다. 이 변환기는 UTF-8로 읽으며, 잘못된 =XX를 만나면 그 자리를 표시해 줍니다.

전송되지 않습니다. 변환은 모두 브라우저 안에서 이루어지고 넣은 값은 이 기기에만 남습니다.