이메일 주소에 다국어 (영어가 아닌) 문자가 포함될 수 있습니까?

가능하다면 사용자의 이메일을 수락해야하며 이러한 주소로 메일을 보낼 때 어떤 문제가 발생할 수 있습니까?

공식적으로 RFC 6532에 따라 - 예 .

빠른 설명 은 주제에 대한 위키피디아 를 확인하십시오 .

2015 업데이트 : RFC 6532 사용

실험 5335은 현재 사용되고 있지 : 6532 및
"분류 : 표준 트랙"이 나중에왔다 세트는
제작 이 표준.

3.2 절 (에 구문 확장 RFC 5322는 ) 대부분의 텍스트 필드를 업데이트했습니다
(적절한) UTF-8을 포함한다.

The following rules extend the ABNF syntax defined in [RFC5322] and
[RFC5234] in order to allow UTF-8 content.

VCHAR   =/  UTF8-non-ascii
ctext   =/  UTF8-non-ascii
atext   =/  UTF8-non-ascii
qtext   =/  UTF8-non-ascii
text    =/  UTF8-non-ascii
             ; note that this upgrades the body to UTF-8
dtext   =/  UTF8-non-ascii

The preceding changes mean that the following constructs now
allow UTF-8:
   1.  Unstructured text, used in header fields like
       "Subject:" or "Content-description:".
   2.  Any construct that uses atoms, including but not limited
       to the local parts of addresses and Message-IDs. This
       includes addresses in the "for" clauses of "Received:"
       header fields.
   3.  Quoted strings.
   4.  Domains.

Note that header field names are not on this list; these are still
restricted to ASCII.

도메인 이 명시 적으로 포함되어 있습니다.
그리고 헤더 이름 의 명시 적 제외 .

NFKC 에 대한 참고 사항 :

The UTF-8 NFKC normalization form SHOULD NOT be used because
it may lose information that is needed to correctly spell
some names in some unusual circumstances.

그리고 제 3 장 시작 :

Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.

문제는 일부 메일 클라이언트 (서버 도구 및 / 또는 데스크톱 도구)가이를 지원하지 않고 예를 들어 움라우트가 포함 된 주소로 메일을 보내려고 할 때 '잘못된 이메일'예외를 던진다는 것입니다.

완전한 지원을 원한다면 이메일 주소 부분을 "퓨니 코드"로 변환하여 트릭을 수행 할 수 있습니다. 이를 통해 사용자는 일반적인 방식으로 주소를 입력 할 수 있지만 지원 수준의 방식으로 저장할 수 있습니다.

예 : müller.com»xn--mller-kva.com

둘 다 같은 것을 가리 킵니다.

많은 최상위 도메인에서 이미 도메인에 대해 비 ASCII 문자를 허용하고 도메인이 이메일 주소의 일부이기 때문에 가능하다고 가정합니다. 이러한 도메인의 예는 www.öko.de입니다.

짧은 대답 : 예

사용자 이름뿐만 아니라 도메인 이름에도 허용됩니다.

아직. IEEE는이를 수행 할 계획입니다. H-Online 기사 : 국제화 된 이메일 주소를 계획하는 IEFT , 여기에 RfC : 국제화 된 이메일 주소를위한 SMTP 확장이 있습니다.

H-Online의 인용문 (내려가는대로) :

IETF (Internet Engineering Task Force)는 ASCII 문자 집합 외부의 기호를 포함하는 전자 메일 주소 헤더의 표준화를위한 세 가지 중요한 문서를 발표했습니다. 즉, 곧 메시지 본문뿐만 아니라 이메일 주소에도 중국어 문자, 프랑스어 악센트 및 독일어 움라우트를 사용할 수 있습니다. 따라서 이름이 Zoë이고 파사드를 만드는 회사에서 일한다면 새 이메일 주소에 관심이있을 수 있습니다. 그러나 공급자의 대표자들은 이미 신음하고 있습니다. 유니 코드 표준 UTF-8이 현재 일반 이메일 언어로 사용되는 미국 표준 정보 교환 코드 (ASCII)를 대체하려면 "업그레이드 매니아"가 필요하다고 말합니다.

RFC 5335는 거의 모든 이메일 헤더에서 UTF-8 사용을 지정합니다. SMTP 클라이언트, SMTP 서버, 메일 사용자 에이전트 (MUA), 메일 링 목록 용 소프트웨어, 다른 미디어에 대한 게이트웨이 및 이메일이 처리되거나 전달되는 모든 곳에서 변경해야합니다. RFC 5336은 SMTP 이메일 전송 프로토콜을 확장합니다. 프로토콜 수준에서 확장은 UTF8SMTP로 레이블이 지정됩니다.

새로운 헤더 필드가 일종의 "비상 낙하산"으로 추가되어 UTF-8 이메일이 업그레이드되지 않은 시스템에 의해 수신자에게 도달하기 전에 폐기되는 경우 소프트 랜딩이되도록합니다. "OldAddress"는 순전히 ASCII 주소입니다. 그러나 OldAddress는 두 번째 전송 시도를위한 채널로 사용되는 것이 아니라 피드백이 홈으로 전송되도록하기위한 것입니다.

마지막으로 RFC5337은 비 ASCII 이메일의 전송 상태와 관련된 올바른 메시지가 전송되도록합니다. 추가 전송이 거부 된 경우에도 연결할 수없는 수취인의 정확한 주소를 다시 보내야합니다. EAI (Email Address Internationalization) 작업 그룹은 다양한 헤더 필드 및 봉투에 대한 여러 "다운 그레이드 메커니즘"도 작업하고 있습니다. 가능하면 원본 헤더 정보는 "패키징"되고 보존됩니다.

그럼에도 불구하고 ".de"도메인의 등록 기관인 독일의 DeNIC는이를 진전시키고 있습니다. DeNIC 대변인 Klaus Herzig는 "우리가 할 수있는 일은별로 없습니다."라고 설명했습니다. 대신 DeNIC는 IETF가 국제 도메인 표준 (RFC3490 또는 IDNA2003)을 위해 작업중인 업데이트에 더 많은주의를 기울이고 있습니다. Herzig는 "하위 호환성이 없기 때문에 그다지 만족스럽지 않습니다."라고 설명했습니다. 업데이트가 올 때, DeNIC는 지금까지 간과되었던 "ß"기호 (estzett라고도 함) 뒤에 무게를 둘 것이라고 말했습니다. 독일 등록 기관은 또한 이전 버전과의 호환성이 부족하다는 점을 감안하여 전환하기 전에 약간 기다릴 수 있다고 말합니다.

반대로 전문가들은 중국과 대만의 중국 등록 기관이 국제화 된 이메일에 대한 변경 사항을 신속하게 구현할 것이라고 믿습니다. CNIC 및 TWNIC의 대표자는 표준의 작성자입니다. 중국 사용자는 현재 이미 국제화 된 중국어 도메인의 경우 @ 왼쪽에 ASCII로 이메일을 작성하고 오른쪽에 중국어 문자로 이메일을 작성해야합니다.

(모니카 에르 메르 트)

대답은 '예'이지만 특별히 인코딩해야합니다.

이것 좀 봐 . 이메일 헤더 및 RFC 2047을 참조하는 부분을 읽으십시오.