2010-08-12 44 views
10
"Françoise Lefèvre"@example.com 

Tôi đang đọc RFC 5321 để cố gắng hiểu những gì tạo thành một địa chỉ email hợp lệ - và tôi có thể làm việc này khó khăn hơn rất nhiều - nhưng điều này đã làm tôi khó chịu.Đây có phải là địa chỉ email hợp lệ không?

   i.e., within a quoted string, any 
       ASCII graphic or space is permitted 
       without blackslash-quoting except 
       double-quote and the backslash itself. 

Điều này có nghĩa rằng ASCII extended character sets có giá trị trong dấu ngoặc kép? Hay điều đó ngụ ý chỉ standard ASCII table?

EDIT - Với các câu trả lời, đây là jQuery validator đơn giản có thể hoạt động bổ sung cho xác thực email tích hợp của plugin để kiểm tra ký tự.

jQuery.validator.addMethod("ascii_email", function(value, element) { 
    // In compliance with RFC 5321, this allows all standard printing ASCII characters in quoted text. 
    // Unquoted text must be ASCII-US alphanumeric or one of the following: ! # $ % & ' * + -/= ?^_ ` { | } ~ 
    // @ and . get a free pass, as this is meant to be used together with the email validator 

    var result = this.optional(element) || 
     (
      /^[\u002a\u002b\u003d\u003f\u0040\u0020-\u0027\u002d-u002f\u0030-\u0039\u0041-\u005a\u005e-\u007e]+$/.test(value.replace(/(["])(?:\\\1|.)*?\1/, "")) &&  
      /^[\u0020-\u007e]+$/.test(value.match(/(["])(?:\\\1|.)*?\1/, "")) 
     ); 
    return result; 
}, "Invalid characters"); 

Xác thực được tích hợp sẵn của plugin có vẻ khá tốt, ngoại trừ việc bắt các ký tự không hợp lệ. Trong số các trường hợp thử nghiệm được liệt kê here, nó chỉ không cho phép nhận xét, xếp khoảng trống và địa chỉ thiếu một TDL (ví dụ: @localhost, @ 255.255.255.255) - tất cả đều có thể dễ dàng sống mà không có.

+0

Nói chung, câu trả lời hay nhất cho loại câu hỏi này là địa chỉ hợp lệ nếu bạn có thể nhận được một vài MTA khác nhau để chấp nhận nó. Các tiêu chuẩn IETF không phải lúc nào cũng chỉ rõ mọi thứ rõ ràng như bạn muốn. – msw

+0

Không xác thực các ký tự riêng lẻ. [Thay vì xác thực cú pháp] (http://stackoverflow.com/questions/201323/what-is-the-best-regular-expression-for-validating-email-addresses/1931322#1931322). – BalusC

+0

@BafusC I * do * xác thực cú pháp. Tôi cũng muốn ngăn mọi người khỏi nhồi nhét tiếng Phạn vào một trường chỉ có ASCII. Cả hai không loại trừ lẫn nhau. Tuy nhiên, tôi nhận ra rằng việc xác thực email thực sự với RegEx, là một redditer đặt nó, là "giống như xây dựng một ngôi nhà bằng cách sử dụng gì ngoài một máy khoan điện." Xác thực phía máy khách chỉ ở đó để nói với ai đó "này, cái này không thuộc về" - và tôi tin rằng đây là một cách tốt, đơn giản để làm điều đó. – Greg

Trả lời

3

Theo trang MSDN này, các ký tự ASCII mở rộng không hợp lệ, hiện tại, nhưng có một đặc tả được đề xuất sẽ thay đổi điều này.

http://msdn.microsoft.com/en-us/library/system.net.mail.mailaddress(VS.90).aspx

Phần quan trọng là ở đây:

Thomas Lee là đúng ở chỗ một trích dẫn phần địa phương có giá trị trong một email địa chỉ, địa chỉ email nhất định có thể là không hợp lệ nếu không trong một chuỗi trích dẫn. Tuy nhiên, các ký tự mà những người khác trong số bạn đã đề cập như umlaut và dấu hoa thị không nằm trong bộ ký tự ASCII , chúng được mở rộng ASCII. Trong RFC 2822 (và sau này RFC 5322 và 3696) các dtext đặc điểm kỹ thuật (cho phép trong trích dẫn phần địa phương) chỉ cho phép ASCII nhất đánh giá cao (RFC 2822, phần 3.4.1) mà bao gồm các giá trị trong phạm vi 33-90 và 94-126. RFC 5335 đã được đề xuất cho phép các ký tự không phải ascii trong addr-spec, tuy nhiên vẫn là được gắn nhãn là thử nghiệm và như vậy là không được hỗ trợ trong Thư.

1

Về mặt kỹ thuật có, nhưng đọc trên:

Trong khi định nghĩa trên cho Local phần là tương đối dễ dãi,
cho khả năng tương tác tối đa, một loạt rằng hy vọng sẽ nhận được thư NÊN tránh xác định hộp thư nơi số Phần địa phương yêu cầu (hoặc sử dụng) biểu mẫu được trích dẫn hoặc trong đó Phần địa phương phân biệt chữ hoa chữ thường.

...

Hệ thống KHÔNG PHẢI xác định hộp thư theo số Cách SMTP yêu cầu sử dụng trong SMTP của ký tự không phải ASCII.

4

Trong RFC này, ASCII có nghĩa là US-ASCII, nghĩa là, không được phép cho phép các ký tự có giá trị lớn hơn 127. Như một bằng chứng, đây là một số trích dẫn từ RFC 5321:

Các dữ liệu thư có thể chứa bất kỳ mã ký tự ASCII 128, [...]

[...]

Systems PHẢI KHÔNG định nghĩa hộp thư theo cách yêu cầu sử dụng trong SMTP của các ký tự không phải ASCII (octet có bit thứ tự cao được đặt thành một) hoặc "ký tự điều khiển" ASCII (giá trị thập phân 0-31 và 127). Các ký tự này KHÔNG được sử dụng trong các lệnh MAIL hoặc RCPT hoặc các lệnh khác yêu cầu tên hộp thư.

Những trích dẫn này rõ ràng ngụ ý rằng các ký tự có giá trị lớn hơn 127 được coi là non-ASCII. Vì các ký tự như vậy bị cấm trong các lệnh MAIL TO hoặc RCPT, không thể sử dụng chúng cho các địa chỉ e-mail.

Do đó, "Francoise Lefevre"@example.com là địa chỉ hoàn toàn hợp lệ (theo RFC), trong khi "Françoise Lefèvre"@example.com thì không.

0

HTML5 đặc tả có interesting take on the issue of valid email addresses:

Một địa chỉ e-mail hợp lệ là một chuỗi phù hợp với sản xuất ABNF 1 * (atext/"") "@" LDH-str 1 * (" . "ldh-str) trong đó atext được định nghĩa trong phần RFC 5322 3.2.3, và ldh-str được định nghĩa trong phần RFC 1034 3.5.

Những điều tốt đẹp về vấn đề này, tất nhiên, là bạn có thể có một cái nhìn tại các trình duyệt mã nguồn mở của source code for validating it (tìm IsValidEmailAddress chức năng). Tất nhiên là trong C, nhưng không quá khó để dịch sang JS.

Các vấn đề liên quan