Địa chỉ email có thể chứa các ký tự quốc tế (không phải tiếng Anh) không?

Question

Nếu có thể, tôi có nên chấp nhận các email như vậy từ người dùng hay không và những vấn đề gì sẽ xảy ra khi tôi gửi thư đến các địa chỉ như vậy?

Answer 1

Chính thức, mỗi RFC 6532 - Có.

Để được giải thích nhanh, hãy xem wikipedia về chủ đề.

Answer 2

Chưa. IEEE lên kế hoạch để làm điều này: H-Online article: IEFT planning internationalised email addresses, đây là Trích RfC: SMTP Extension for Internationalized Email Addresses

từ H-Online (như nó đã đi xuống):

Internet Engineering Task Force (IETF) đã xuất bản ba tài liệu rất quan trọng cho tiêu chuẩn hóa tiêu đề địa chỉ email bao gồm các biểu tượng bên ngoài bộ ký tự ASCII. Điều này có nghĩa là bạn sẽ sớm có thể sử dụng ký tự Trung Quốc, dấu tiếng Pháp và dấu âm tiếng Đức trong địa chỉ email cũng như chỉ trong phần nội dung của thư . Vì vậy, nếu tên của bạn là Zoë và bạn làm việc cho một công ty tạo ra các mặt tiền , bạn có thể quan tâm đến một địa chỉ email mới. Nhưng đại diện của các nhà cung cấp đã rên rỉ. Họ nói rằng sẽ có cần phải là "nâng cấp mania" nếu tiêu chuẩn Unicode UTF-8 là thay thế Mã tiêu chuẩn của Mỹ cho trao đổi thông tin (ASCII) hiện được sử dụng làm ngôn ngữ email chung.

RFC 5335 chỉ định việc sử dụng UTF-8 trong thực tế tất cả các tiêu đề email. Thay đổi sẽ phải được thực hiện cho máy khách SMTP, máy chủ SMTP, người dùng thư đại lý (MUA), phần mềm cho danh sách gửi thư, cổng tới phương tiện khác, và mọi nơi khác nơi email được xử lý hoặc chuyển. RFC 5336 mở rộng giao thức truyền tải email SMTP. Ở cấp độ của giao thức , mở rộng được gắn nhãn UTF8SMTP.

Trường tiêu đề mới sẽ được thêm dưới dạng "loại nhảy khẩn cấp" thành đảm bảo rằng email UTF-8 có đích hạ cánh nếu chúng được ném ra trước khi tiếp cận với người nhận bằng hệ thống chưa được nâng cấp. "OldAddress" là địa chỉ thuần túy ASCII. Nhưng OldAddress không phải là được sử dụng làm kênh cho nỗ lực chuyển lần thứ hai, mà là để thực hiện chắc chắn rằng phản hồi được gửi về nhà.

Cuối cùng, RFC5337 đảm bảo rằng thư chính xác được gửi liên quan đến trạng thái gửi của email không phải ASCII. Địa chỉ chính xác của một người nhận không thể truy cập phải được gửi lại, ngay cả khi việc vận chuyển tiếp theo đã bị từ chối . Nhóm Địa chỉ email Quốc tế hóa (EAI) đang hoạt động cũng đang làm việc trên một số "cơ chế hạ cấp" cho các trường tiêu đề khác nhau và phong bì. Nếu có thể, thông tin tiêu đề gốc sẽ được "đóng gói" và được lưu giữ.

DeNIC của Đức, công ty đăng ký tên miền ".de", tuy nhiên, thực hiện việc này trong bước tiến của nó. "Chúng tôi không thể làm được gì nhiều", phát ngôn viên của DeNIC, Klaus Herzig giải thích.Thay vào đó, DeNIC thanh toán thêm sự chú ý nhiều hơn cho bản cập nhật mà IETF đang làm việc theo tiêu chuẩn của các tên miền quốc tế - RFC3490 hoặc IDNA2003 vì nó là đôi khi được biết. "Chúng tôi không vui vì nó không có khả năng tương thích ngược" ", Herzig giải thích. Khi cập nhật đến, DeNIC nói rằng nó sẽ ném trọng lượng của nó sau biểu tượng "ß" - cũng được gọi là estzett - đã bị bỏ qua cho đến bây giờ. Nhà đăng ký của Đức cũng nói rằng nó có thể chờ một chút trước khi chuyển sang ánh sáng do thiếu khả năng tương thích ngược. Khi tiêu chuẩn mới là chạy ổn định và nhà đăng ký và nhà cung cấp đã chấp nhận nó, thì ß sẽ được thêm vào.

Ngược lại, các chuyên gia tin rằng nhà đăng ký Trung Quốc ở Trung Quốc và Đài Loan sẽ nhanh chóng thực hiện thay đổi đối với email được quốc tế hóa. Đại diện của CNIC và TWNIC là tác giả của các tiêu chuẩn. Người dùng Trung Quốc hiện phải viết email bằng ASCII ở bên trái của ký tự @ và bằng tiếng Trung ở bên phải đối với tên miền Trung Quốc đã được quốc tế hóa.

(Monika Ermert)

Answer 3

Tôi sẽ giả có kể từ khi một số lĩnh cấp cao nhất đã cho phép phi ascii ký tự cho tên miền và kể từ khi tên miền là một phần của một địa chỉ thư điện tử, đó là hoàn toàn có thể. Một ví dụ cho một tên miền như vậy sẽ được www.öko.de

Answer 4

trả lời ngắn gọn: yes

không chỉ ở tên người dùng mà còn trong tên miền được cho phép.

Answer 5

Vấn đề là một số ứng dụng thư (máy chủ công cụ và/hoặc công cụ máy tính để bàn) không hỗ trợ và ném ngoại lệ 'email không hợp lệ' khi bạn cố gắng gửi thư đến địa chỉ có chứa ngôn ngữ ví dụ.

Nếu bạn muốn hỗ trợ đầy đủ, bạn có thể thực hiện thủ thuật bằng cách chuyển đổi các phần địa chỉ email thành "punycode". Điều này cho phép người dùng nhập địa chỉ của họ theo cách thông thường nhưng bạn lưu nó theo cách được hỗ trợ.

Ví dụ: müller.com »xn--mller-kva.com

Cả hai điểm giống nhau.

Answer 6

Câu trả lời là có, nhưng chúng cần phải được mã hóa đặc biệt.

Look at this. Đọc phần đó đề cập đến email-header và RFC 2047.

Answer 7

Cập nhật 2015: Sử dụng RFC 6532

Các thực nghiệm 5335 đã lỗi thời bởi: 6532 và
này sau đã được thiết lập để "Thể loại: Tiêu chuẩn Track" ,
làm cho nó tiêu chuẩn.

Section 3.2 (Tiện ích cú pháp thành RFC 5322) đã cập nhật hầu hết các trường văn bản thành
bao gồm (đúng) 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. 

Xin lưu ý rõ ràng bao gồm các tên miền.
Và loại trừ rõ ràng của tiêu đề tên.

Cũng Lưu ý về 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. 

Và Section 3 bắt đầu:

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