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

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

---

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

---

공식적으로 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의 인용문 (내려가는대로) :

The Internet Engineering Task Force (IETF) has published three crucial documents for the standardisation of email address headers that include symbols outside the ASCII character set. This means that soon you'll be able to use Chinese characters, French accents, and German umlauts in email addresses as well as just in the body of the message. So if your name is Zoë and you work for a company that makes façades, you might be interested in a new email address. But representatives of providers are already moaning. They say there would need to be an "upgrade mania" if the Unicode standard UTF-8 is to replace the American Standard Code for Information Interchange (ASCII) currently used as the general email language.

RFC 5335 specifies the use of UTF-8 in practically all email headers. Changes would have to be made to SMTP clients, SMTP servers, mail user agents (MUAs), software for mailing lists, gateways to other media, and everywhere else where email is processed or passed along. RFC 5336 expands the SMTP email transport protocol. At the level of the protocol, the expansion is labelled UTF8SMTP.

A new header field will be added as a sort of "emergency parachute" to ensure that UTF-8 emails have a soft landing if they are thrown out before reaching the recipient by systems that have not been upgraded. The "OldAddress" is a purely ASCII address. But OldAddress is not to be used as a channel for a second transfer attempt, but rather to make sure that feedback is sent home.

Finally, RFC5337 ensures that correct messages are sent pertaining to the delivery status of non-ASCII emails. The correct address of an unreachable addressee must be sent back, even if further transport has been refused. The email Address Internationalization (EAI) working group is also working on a number of "downgrade mechanisms" for various header fields and the envelope. If possible, original header information is to be "packaged" and preserved.

Germany's DeNIC, the registrar for the ".de" domain, is nonetheless taking this in its stride. "There is really not much we can do", explained DeNIC spokesperson Klaus Herzig. DeNIC is instead paying more attention to the update that the IETF is working on for the standard of international domains – RFC3490, or IDNA2003 as it's sometimes known. "We are not that happy about it because there is no backwards compatibility," Herzig explained. When the update comes, DeNIC says it will be throwing its weight behind the symbol "ß" - also known as estzett - which has been overlooked up to now. The German registrar also says that it may wait a bit before switching in light of the lack of backward compatibility. Once the new standard is running stably and registrars and providers have adopted it, the ß will be added.

In contrast, experts believe that Chinese registrars in China and Taiwan will quickly implement the change for internationalised email. Representatives of CNIC and TWNIC are authors of the standards. Chinese users currently have to write emails in ASCII to the left of the @ and in Chinese characters to the right of it for Chinese domains, which have already been internationalized.

(Monika Ermert)

---

The answer is yes, but they need to be encoded specially.

Look at this. Read the part that refers to email-headers and RFC 2047.

참고URL : https://stackoverflow.com/questions/760150/can-an-email-address-contain-international-non-english-characters