상위 질문
타임라인
채팅
관점
유니코드와 전자우편
위키백과, 무료 백과사전
Remove ads
많은 이메일 클라이언트는 이제 유니코드에 대한 일부 지원을 제공한다. 일부 클라이언트는 메일 내용에 따라 레거시 인코딩과 유니코드 중에서 자동으로 선택하거나, 자동으로[1] 또는 사용자가 요청할 때 선택한다.[2]
비-ASCII 문자를 포함하는 메시지를 이메일로 보내기 위한 기술적 요구사항은 다음과 같다:
- 특정 헤더 필드(제목, 발신자 및 수신자 이름, 발신자 조직 및 회신 이름) 인코딩, 그리고 선택적으로 내용-전송 인코딩으로 본문 인코딩
- 유니코드 변환 중 하나로 비-ASCII 문자 인코딩
- 이메일 주소 및 회신 코드(SMTPUTF8)에서 UTF-8 인코딩 사용 협상
- 내용-전송 인코딩 및 사용된 유니코드 변환에 대한 정보 전송하여 수신자가 메시지를 올바르게 표시할 수 있도록 함
발신자 또는 수신자의 이메일 주소에 비-ASCII 문자가 포함된 경우, 메시지를 보내려면 이러한 문자를 메일 서버가 이해할 수 있는 형식으로 인코딩해야 한다.
Remove ads
프로토콜 지원
RFC 6531은 SMTP[3] 및 LMTP 프로토콜에서 UTF-8로 인코딩된 비-ASCII 이메일 주소를 허용하는 메커니즘을 제공한다.
메시지 헤더
제목 줄, 발신자 및 수신자 이름과 같은 특정 이메일 헤더 필드에서 유니코드를 사용하려면 유니코드 텍스트를 문자 집합으로 유니코드 인코딩을 사용하여 MIME "인코딩된 단어"로 인코딩해야 한다. 이메일 주소의 도메인 부분에서 유니코드를 사용하려면 전통적으로 IDNA 인코딩을 사용해야 한다. 또는 SMTPUTF8[3]은 이메일 주소(로컬 부분 및 도메인 이름 모두)와 메일 헤더 섹션에서 UTF-8 인코딩 사용을 허용한다. 원래 ASCII 전용 이메일 프로토콜에 비-ASCII 데이터 처리를 추가하기 위해 다양한 표준이 만들어졌다:
Remove ads
메시지 본문
US-ASCII를 제외한 모든 인코딩과 마찬가지로 이메일에서 유니코드 텍스트를 사용할 때는 텍스트에 유니코드 변환 형식이 사용되고 있음을 지정하기 위해 MIME을 사용해야 한다.
구식 인코딩인 UTF-7은 구식의 비-8비트 클린 네트워크에서 유니코드 인코딩보다 이점이 있었다. 이는 레거시 인터넷 메일 서버의 7비트 한계 내에 맞추기 위해 전송 인코딩이 필요하지 않기 때문이다. 반면에 UTF-16은 SMTP 데이터 형식에 맞추기 위해 전송 인코딩되어야 한다. 엄격하게 요구되지는 않지만, UTF-8도 7비트 메일 서버에서 문제를 피하기 위해 일반적으로 전송 인코딩된다. UTF-8의 MIME 전송 인코딩은 이를 일반 텍스트로 읽을 수 없게 만들거나(베이스64의 경우), 일부 언어 및 텍스트 유형의 경우 크기 비효율적으로 만든다.
HTML, 포스트스크립트 및 서식 있는 텍스트 포맷과 같은 일부 문서 형식은 비-ASCII 문자에 대한 자체 7비트 인코딩 체계를 가지고 있으므로 특별한 이메일 인코딩을 사용하지 않고도 보낼 수 있다. HTML 이메일은 이메일의 HTML 원본 텍스트가 레거시 인코딩(예: 7비트 ASCII)일지라도 HTML 엔티티를 사용하여 유니코드의 어느 곳에서나 문자를 사용할 수 있다.
같이 보기
- 이메일 클라이언트 비교
- 이메일 주소 국제화
- 국제 이메일
- 유니코드와 HTML
각주
외부 링크
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads