Độ dài tối đa của một địa chỉ email hợp lệ là bao nhiêu?


988

Độ dài tối đa của một địa chỉ email hợp lệ là bao nhiêu? Được xác định bởi bất kỳ tiêu chuẩn?


Những loại địa chỉ email? Internet, X.400, hay khác?
Toby Speight

Lưu ý rằng giới hạn độ dài mà ứng dụng của bạn nên áp đặt cho các địa chỉ email có thể không giống với mức tối đa theo lý thuyết ( dài hơn toàn bộ nhận xét này ). Các câu trả lời khác thảo luận về câu hỏi đó, ví dụ: stackoverflow.com/questions/1297272
MGOwen

Câu trả lời:


1206

Một địa chỉ email không được vượt quá 254 ký tự.

Điều này đã được IETF chấp nhận sau khi gửi lỗi . Một chẩn đoán đầy đủ của bất kỳ địa chỉ nhất định có sẵn trực tuyến . Phiên bản gốc của RFC 3696 mô tả 320 là độ dài tối đa, nhưng John Klensin sau đó đã chấp nhận một giá trị không chính xác, vì Đường dẫn được định nghĩa là

Path = "<" [ A-d-l ":" ] Mailbox ">"

Vì vậy, phần tử Hộp thư (nghĩa là địa chỉ email) có các dấu ngoặc góc xung quanh nó để tạo thành Đường dẫn, có độ dài tối đa là 254 ký tự để hạn chế độ dài Đường dẫn xuống còn 256 ký tự trở xuống.

Độ dài tối đa được chỉ định trong các trạng thái RFC 5321 :

Tổng chiều dài tối đa của đường dẫn ngược hoặc đường dẫn chuyển tiếp là 256 ký tự.

RFC 3696 đã được sửa chữa ở đây .

Mọi người nên biết về lỗi sai đối với RFC 3696 nói riêng. Ba trong số các ví dụ kinh điển trên thực tế là các địa chỉ không hợp lệ.

Tôi đã đối chiếu vài trăm địa chỉ kiểm tra mà bạn có thể tìm thấy tại http://www.dominicsayers.com/isemail


7
Thế còn tiêu chuẩn RFC mới cho phép Unicode trong địa chỉ email thì sao?
Pacerier

3
Có bao nhiêu ký tự trước @ và bao nhiêu ký tự sau, hoặc nó không quan trọng?
systemovich

5
@Lodewijk RFC 3696 không phải là một tiêu chuẩn, nó chỉ cố gắng giúp mọi người giải thích chính xác các tiêu chuẩn cơ bản. Thật không may, trong nỗ lực làm rõ tình hình, Klensin đã đưa vào một số lỗi thô đã được sửa trong Errata. Nhưng không ai đọc được lỗi, vì vậy RFC 3693 cuối cùng rất vô ích, trớ trêu thay.
Dominic

3
Tôi tin rằng với các địa chỉ e-mail được quốc tế hóa, sẽ đúng hơn nếu xác định giới hạn là 254 octet , không phải ký tự. Nhưng tôi không chắc lắm. RFC 6531 mở rộng đường dẫn ngược và chuyển tiếp RFC 5321 để cho phép các ký tự UTF-8, nhưng RFC 5321 nói cụ thể giới hạn là "256 octet", bao gồm các dấu phân cách (thay đổi có chủ ý từ RFC 2821 có ghi "ký tự"). Tôi tin rằng giới hạn 256 octet (trừ 2 cho 254) không được thay thế và giới hạn ký tự hiệu quả được giảm cho các địa chỉ có ký tự UTF-8 nhiều byte.
Andre D

1
@JohnLBevan vì các tên miền được sử dụng cho các mục đích khác ngoài email và được xác định bởi các RFC khác nhau. Tôi chắc chắn Jon Postel mong muốn anh ta có thể làm cho nó phù hợp hơn nhưng tại thời điểm đó, hầu hết các tên miền đều rất ngắn và việc phá vỡ các địa chỉ phong bì thành hai hoặc nhiều gói chỉ đơn giản là để tính đến tiềm năng cho miền rất dài tên.
Dominic Sayers

38

320

Và các phân đoạn trông như thế này

{64} @ {255}

64 + 1 + 255 = 320

Bạn cũng nên đọc nó nếu bạn đang xác nhận email

http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx


Tuy nhiên, theo thông số kỹ thuật này (đối với dữ liệu cho vay của sinh viên) nchelp.org/el Library / EES / CommonRecord-CommonLineDocumentation / trên trang 20: "Độ dài email thay đổi để phản ánh các tiêu chuẩn ANSI hiện tại. Địa chỉ email là độ dài tối đa gồm 128 ký tự. " Hừm.
Nathan

8
Đây là một bài viết đáng yêu xua tan những huyền thoại khác nhau về email bao gồm "max len == 320". Giới hạn thực sự là 254.
Carl

26
Bài báo đáng yêu ở đâu?
Bob

1
Câu trả lời này đúng. Email này hợp lệ, nhưng hoàn toàn không sử dụng được, vì 2821 hạn chế các lệnh MAIL / RCPT thành 256 với <>dấu ngoặc ...
vp_arth

1
Có bao gồm các email trong định dạng user+inbox@domain?
Aaron Esau

20

người dùng

Tổng chiều dài tối đa của tên người dùng là 64 ký tự.

miền

Tối đa 255 ký tự trong phần tên miền (ký tự sau tên @ @)

Tuy nhiên, có một hạn chế trong cách đọc RFC 2821 :

Tổng chiều dài tối đa của đường dẫn ngược hoặc đường dẫn chuyển tiếp là 256 ký tự, bao gồm dấu chấm câu và dấu tách phần tử. Do các địa chỉ không phù hợp trong các trường đó thường không hữu ích, nên giới hạn trên của độ dài địa chỉ thường được coi là 256, nhưng một đường dẫn được xác định là: Đường dẫn = Hồi <Adl Đường dẫn chuyển tiếp sẽ chứa ít nhất một cặp dấu ngoặc góc ngoài Hộp thư, giới hạn địa chỉ email là 254 ký tự.


7
Thật tuyệt, rfc cổ xưa của năm 1982 ... Có rfc5321 cho SMTP
vp_arth

14

Để giúp những tân binh bối rối như tôi, câu trả lời cho "Độ dài tối đa của một địa chỉ email hợp lệ là bao nhiêu?" là 254 ký tự .

Nếu ứng dụng của bạn sử dụng email, chỉ cần đặt trường của bạn chấp nhận 254 ký tự trở xuống và bạn sẽ ổn.

Bạn có thể chạy một loạt các bài kiểm tra trên một email để xem nó có hợp lệ ở đây không. http://isemail.info/

RFC, hoặc Yêu cầu Nhận xét là một loại ấn phẩm từ Lực lượng đặc nhiệm Kỹ thuật Internet (IETF) xác định 254 ký tự là giới hạn. Nằm ở đây - https://tools.ietf.org/html/rfc5321#section-4.5.3


12

Các câu trả lời khác làm vẩn đục nước một chút. Câu trả lời đơn giản: Tổng số 254 ký tự trong kiểm soát của chúng tôi đối với email 256 là dành cho địa chỉ email ENTIRE, bao gồm "<" ở đầu và ">" ở cuối. Do đó, 254 còn lại để sử dụng của chúng tôi.


4

Theo bài viết dưới đây:

http://tools.ietf.org/html/rfc3696 (Trang 6, Mục 3)

Nó đã đề cập rằng:

"Có giới hạn độ dài đối với địa chỉ email. Giới hạn đó tối đa là 64 ký tự (octet) trong" phần cục bộ "(trước" @ ") và tối đa 255 ký tự (octet) trong phần tên miền (sau phần tên miền) "@") với tổng độ dài 320 ký tự. Các hệ thống xử lý email nên được chuẩn bị để xử lý các địa chỉ dài như vậy, mặc dù chúng hiếm khi gặp phải. "

Vì vậy, tổng độ dài tối đa cho một địa chỉ email là 320 ký tự ("phần cục bộ": 64 + "@": 1 + "phần miền": 255, tổng là 320)


bạn có thể vui lòng cung cấp cho tôi biểu thức chính quy trong javascript để xác thực id email 320 ký tự không? Cảm ơn trước.
Kam Meat

1
Phần này của tiêu chuẩn đã được sửa đổi trong errata để bao gồm tổng giới hạn là 254 ký tự. Xem câu trả lời được chấp nhận để biết chi tiết và các liên kết đến errata.
Matthijs Kooijman
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.