=?ISO-2022-JP?B?…?= 같은 MIME 인코딩 해독하기
=?ISO-2022-JP?B?GyRC…?= 같은 모습으로 도착한 일본어 제목은 깨진 것이 아니라 전송용 인코딩을 입고 있을 뿐입니다. 이 도구는 그것을 벗겨내고, 반대로 인코딩이 필요할 때는 다시 입혀줍니다.
- 브라우저 안에서 전부 처리됩니다
- 오프라인에서도 작동합니다
- 업로드 없음
- 가입 없음
- 워터마크 없음
도구를 불러오는 중…
작동 방식
- 헤더나 본문 부분, 또는 =?…?= 형태의 단어 하나를 붙여넣으세요.
- “Decode”(디코딩)를 누르세요. 인코딩된 단어마다 문자셋과 함께 나열됩니다.
- 반대로 인코딩하려면 아래 인코딩 상자에 텍스트를 입력하세요.
왜 아무것도 업로드되지 않는가
이 페이지가 하는 모든 작업은 브라우저 탭 안에서 도는 코드가 처리합니다. 웹 페이지를 그리는 그 엔진을 그대로 씁니다. 파일은 디스크에서 탭의 메모리로 읽어 들여 거기서 변환한 뒤 다시 다운로드 파일로 내보냅니다. 어디로도 전송되지 않습니다. 우리에게도, 제3자에게도.
직접 확인해 보세요
- 브라우저 개발자 도구(F12)를 열고 네트워크(Network) 탭을 선택합니다.
- 파일을 올리고 도구를 실행합니다.
- 보이는 요청은 도구 자체의 코드를 받아 오는 것뿐입니다. 무거운 몇몇 도구는 공개 CDN에서 오픈소스 엔진을 함께 받아 옵니다. 여기에 loreatec.jp로 가는 작은 방문 집계 신호 하나(페이지 주소와 제목, 그 이상은 없습니다)가 더해집니다. 어느 것도 당신의 파일을 실어 나르지 않습니다.
자주 묻는 질문
인코딩된 단어란 무엇인가요?
원래 표준상 메일 헤더는 ASCII 문자만 쓸 수 있습니다. RFC 2047은 이 제약을 피해가기 위해 ASCII가 아닌 텍스트를 =?문자셋?인코딩?텍스트?= 형태로 감쌉니다. 인코딩 부분은 B(base64)나 Q(quoted-printable의 변형) 중 하나입니다. 모든 메일 프로그램이 화면에 표시할 때 이것을 알아서 디코딩해 주기 때문에, 원본 헤더를 직접 보게 되는 상황이 아니라면 평소에는 볼 일이 없습니다.
ISO-2022-JP를 지금도 써야 하나요?
일본 이동통신사나 정말로 오래된 시스템으로 가는 헤더라면 여전히 가장 안전한 선택입니다. 하지만 ①, ㈱, ～처럼 Word에서 흔히 붙여넣는 기호의 절반, 그리고 이모지는 전혀 표현하지 못합니다. 이런 문자는 물음표로 바뀌거나 아예 사라집니다. UTF-8은 모든 것을 담을 수 있고 오늘날 세 통신사를 포함한 모든 최신 수신 시스템에서 받아들여집니다.
인코더는 왜 UTF-8만 지원하나요?
브라우저는 ISO-2022-JP, Shift_JIS, EUC-JP를 디코딩할 수는 있지만 그 형식으로 인코딩할 수는 없기 때문입니다. TextEncoder는 오직 UTF-8만 만들어냅니다. 그런 선택지를 보여주고는 몰래 UTF-8을 돌려주는 것이야말로 이 도구가 드러내려는 바로 그런 종류의 조용한 오류일 것입니다. 디코딩은 이 모든 형식을 지원합니다.
B와 Q, 어느 쪽을 써야 하나요?
일본어라면 B입니다. Q 방식으로는 거의 모든 바이트를 이스케이프해야 해서 base64 쪽이 더 짧아집니다. 악센트가 조금 섞인 로마자 위주의 텍스트라면 Q가 헤더를 읽기 쉽게 유지해 주므로, 원본 소스를 직접 읽을 때 도움이 됩니다.