Độ dài tối ưu cho địa chỉ email trong cơ sở dữ liệu là bao nhiêu?


95

Đây là một phần được trích xuất của truy vấn của tôi, phản ánh EMAIL_ADDRESSloại dữ liệu cột và thuộc tính:

EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, 

Tuy nhiên, John Saunders sử dụng VARYING(256).

Điều này gợi ý cho tôi rằng tôi chưa chắc đã hiểu VARYING một cách chính xác.

Tôi hiểu rằng độ dài của một địa chỉ email là 20 ký tự trong trường hợp của tôi, trong khi 256 đối với Jodn.

Bối cảnh trong mã của John

CREATE TABLE so."User"
  (
    USER_ID SERIAL NOT NULL,
    USER_NAME CHARACTER VARYING(50) NOT NULL,
    EMAIL_ADDRESS CHARACTER VARYING(256) NOT NULL, // Here
    HASHED_PASSWORD so.HashedPassword NOT NULL,
    OPEN_ID CHARACTER VARYING(512),                                                         
    A_MODERATOR BOOLEAN,
    LOGGED_IN BOOLEAN,
    HAS_BEEN_SENT_A_MODERATOR_MESSAGE BOOLEAN,
    CONSTRAINT User_PK PRIMARY KEY(USER_ID)
  );

Tôi chưa bao giờ thấy địa chỉ email dài hơn 20 ký tự, được sử dụng bởi những người bình thường.

Độ dài tối ưu cho địa chỉ email trong cơ sở dữ liệu là bao nhiêu?


Bạn có nghĩa là gì bởi "tối ưu"? Bạn đang cố gắng "tối ưu hóa" điều gì?
S.Lott

1
@ S.Lott: Tôi muốn xây dựng một hệ thống an toàn. Sự gia tăng đầu vào của người dùng làm tăng nguy cơ họ có thể chạy mã trong cơ sở dữ liệu. --- Tôi thấy tối ưu là cách tốt nhất để có một hệ thống an toàn.
Léo Léopold Hertz 준영

1
Vâng, mặc dù có những cân nhắc về bảo mật trong việc không tạo ra thứ gì đó không bị ràng buộc, nhưng việc tuân theo các tiêu chuẩn sẽ luôn có ý nghĩa nhất. Làm theo những gì là "phổ biến" hoặc "tối ưu" có thể sẽ gây ra các vấn đề bảo mật sau đó giảm bớt chúng.
Kitson

1
Câu hỏi này trên StackOverflow gợi ý rằng độ dài tối đa hiện là 254 ký tự bao gồm cả dấu "@": stackoverflow.com/questions/386294/…
dthrasher

1
Đây là một bài đăng liên quan về độ dài email từ @DominicSayers, với câu trả lời thực sự thấu đáo: stackoverflow.com/a/574698/361842
JohnLBevan

Câu trả lời:


135

Độ dài tối đa của một địa chỉ email là 254 ký tự.

Mỗi địa chỉ email bao gồm hai phần. Phần cục bộ đứng trước dấu '@' và phần miền đứng sau nó. Trong "user@example.com", phần cục bộ là "người dùng" và phần miền là "example.com".

Phần cục bộ không được vượt quá 64 ký tự và phần miền không được dài hơn 255 ký tự.

Độ dài kết hợp của các phần miền + @ + cục bộ của địa chỉ email không được vượt quá 254 ký tự. Như được mô tả trong RFC3696 Errata ID 1690 .

Tôi nhận được phần gốc của thông tin này từ đây


Có vẻ như tốt nhất nên lấy 320 làm chiều dài.
Léo Léopold Hertz 준영

40
Tôi biết đây là một chuỗi cũ và không có vấn đề gì khi sử dụng 320, nhưng tối đa thực tế là 254 vì hạn chế ghi đè từ RFC2821 áp đặt các ràng buộc bổ sung lên và cao hơn những ràng buộc được trích dẫn cho phần cục bộ và miền. Nếu không gian lưu trữ là một vấn đề, điều này có thể đáng để mọi người biết nếu họ vấp phải chuỗi này. Xem Errata ID 1690 trong errata thành RFC3696
HexAndBugs

Như @flightplanner nói, Wikipedia tóm tắt những phần ở đây : "nhưng tối đa ... hạn chế toàn bộ địa chỉ email để không quá 254 ký tự"
RustyTheBoyRobot

2
Đặc biệt nếu bạn muốn trường email có một ràng buộc duy nhất; trong INNODB và utf8 varchar (254) đủ nhỏ (dưới 767byte) để có một ràng buộc duy nhất và varchar (300) thì không.
Autonomy

Trong RFC 3696 errata ID 1003, tôi thấy rằng 256 ký tự là giới hạn thực tế (và tối đa 320 ký tự).
Arnold Schrijver

56

từ Hỏi Metafilter :

Dữ liệu của tôi đến từ cơ sở dữ liệu gồm 323 địa chỉ. Sự phân phối có một số giá trị ngoại lai (lệch dương). Nó được phân phối bình thường mà không có các ngoại lệ (tôi đã thử nghiệm nó.)

Tối thiểu: 12 Phần tư thứ nhất: 19 Trung bình (có / ngoại lệ): 23.04 Giá trị ngoại lệ trung bình): 22.79 Phần tư thứ ba: 26 Tối đa (có / ngoại lệ): 47 Tối đa (ngoại lệ có / không): 35

Trung bình: 23 Chế độ: 24 Std. Dev (w / ngoại lệ): 5,20 Std. Dev (w / o ngoại lệ): 4,70

Phạm vi dựa trên dữ liệu bao gồm ngoại lệ 68,2% dữ liệu 17,8 - 28,2 95,4% dữ liệu 12,6 - 33,4 99,7% dữ liệu 7,4 - 38,6

Phạm vi dựa trên ngoại lệ dữ liệu đã loại trừ 68,2% dữ liệu 18,1 - 27,5 95,4% dữ liệu 13,4 - 32,2 99,7% dữ liệu 8,7 - 36,9

Nếu bạn đăng ký http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/ thì địa chỉ email của bạn chắc chắn sẽ là một địa chỉ khác :)

Đây là Độ dài an toàn tối đa của địa chỉ email cho phép trong một biểu mẫu trang web là gì? trên Raycon với giá trị trung bình hơi khác (N = 50,496, trung bình = 23):

Phân phối độ dài địa chỉ email


@Masi thực sự điều gây tò mò là đó là một phân phối Poisson chứ không phải là một phân phối bình thường - có ai biết tại sao nó lại như vậy không? : P
pageman

@pageman: Lý do là mỗi sự kiện được phân phối ngẫu nhiên VÀ mỗi sự kiện được lấy từ không gian vô cực. - Bạn sẽ nhận được một phân phối tương tự nếu bạn tính toán số lượng ô tô chuyển sang màu ĐỎ để bạn có thời gian so với số ô tô chuyển sang màu đỏ trong các trục.
Léo Léopold Hertz 준영

Cá nhân tôi như Luật Benford tốt hơn: en.wikipedia.org/wiki/Benford%27s_law
Kitson

2
Tôi đã sử dụng 120 ký tự biến trong nhiều năm. Logic thế giới thực là ngay cả nếu ai đó đã sẵn sàng để điền vào lĩnh vực varchar 320 của bạn ... Tôi đặt cược họ có một 40 char thay thế email chỉ đứng
Chukky NZE

18

Chỉ dùng varchar(50) . Các email dài hơn là tào lao, mọi lúc.

Chỉ cần xem 50 ký tự dài bao nhiêu:

peoplewithanemail @ ddressthislongjustuseashorterone

Nếu bạn cho phép email 255 ký tự:

  • Hiển thị chúng có thể làm rối giao diện người dùng của bạn (tốt nhất là chúng sẽ bị cắt bỏ, tệ nhất là chúng đẩy vùng chứa và lề của bạn xung quanh) và
  • Người dùng độc hại có thể làm những điều mà bạn không thể lường trước được (chẳng hạn như những trường hợp tin tặc sử dụng API trực tuyến miễn phí để lưu trữ một loạt dữ liệu)

(Thống kê cho thấy không ai thực sự nhập hơn 50 ký tự cho một địa chỉ email hợp pháp, hãy xem ví dụ: câu trả lời của người trang https://stackoverflow.com/a/1199245/87861 )


5
Hoàn toàn đồng ý. Ai trong tâm trí họ sẽ có một địa chỉ email nữa? Chắc chắn, về mặt lý thuyết, một email có thể có 320 ký tự nhưng trong thế giới thực thì đúng? Trong hệ thống của tôi, tôi cũng sử dụng varchar (50) và tôi chưa bao giờ có khiếu nại rằng người dùng không thể đăng ký.
Norbert Norbertson

2
Sẽ rất thú vị khi biết từ bộ dữ liệu khổng lồ độ dài trung bình của email trong thế giới thực là gì và các giá trị ngoại lai là gì và lớn như thế nào.
Norbert Norbertson

4
Sai lầm. Có rất nhiều người dùng trong thế giới thực có hơn 50 ký tự trong email của họ và quan trọng hơn là họ không thể thay đổi nó chỉ vì bạn. Từ chối họ truy cập cho một cái gì đó mà họ không thể sửa chữa là không công bằng.
Marcus Downing

2
tất nhiên họ có thể tạo email mới. làm cho google một.
Nicolas Manzini

Ngoài ra, đừng quên về ký hiệu cộng. Một số người dùng thành thạo đang sử dụng điều này để tách biệt và sắp xếp các email của họ trong hộp thư đến của họ. Về cơ bản, họ sẽ có một email (phụ) duy nhất trên mỗi trang web / dịch vụ / ứng dụng. Ví dụ: hãy tưởng tượng rằng email bình thường của tôi là tên và họ của tôi tại một số tên công ty: firstnameandlastone@superacmecompany.com. Đó là ~ 40 ký tự. Bây giờ, nếu tôi sử dụng ký hiệu cộng cho tài khoản stackoverflow: firstnameandlastone+stackoverflow@superacmecompany.com— thì ~ 55 ký tự. Một số ký hiệu cộng có thể dài hơn, ví dụ: + stackoverflow-personal và * -work.
Waterlink

16

Địa chỉ email công việc của tôi dài hơn 20 ký tự!

Đọc thông số kỹ thuật RFC thích hợp :

"Phần cục bộ của địa chỉ e-mail có thể dài tối đa 64 ký tự và tên miền có thể có tối đa 255 ký tự"


4

Các kiểu ký tự biến đổi trong cơ sở dữ liệu không chiếm không gian không cần thiết. Vì vậy, không có lý do gì để hạn chế các trường đó càng nhiều càng tốt. Tùy thuộc vào tên của một người, cách đặt tên mà tổ chức của họ sử dụng và tên miền của họ, một địa chỉ có thể dễ dàng vượt quá 20 ký tự.

Không có giới hạn về độ dài của phần cục bộ và tên miền trong RFC-2822 . RFC-2181Mặc dù vậy, giới hạn tên miền ở 255 octet / ký tự.

Một lần nữa, vì varchar chỉ sử dụng không gian thực sự được sử dụng bởi chuỗi bạn lưu trữ, không có lý do gì để có giới hạn nhỏ cho độ dài địa chỉ email. Chỉ cần đi với 512 và đừng lo lắng. Mọi thứ khác là tối ưu hóa quá sớm


3

Ban đầu, tối đa là 320 ký tự (64 + 1 + 255, như hiển thị trong các câu trả lời khác) nhưng như RFC 3696 Errata 1003 đã nói:

Tuy nhiên, có một hạn chế trong RFC 2821 về độ dài của một địa chỉ trong lệnh MAIL và RCPT là 256 ký tự. Vì các địa chỉ không phù hợp với các trường đó thường không hữu ích, giới hạn trên về độ dài địa chỉ thường được coi là 256.

Và từ RFC 5321 phần 4.5.3.1.3 :

4.5.3.1.3. Con đường

Tổng độ dài tối đa của một đường dẫn ngược hoặc đường dẫn chuyển tiếp là 256 octet (bao gồm dấu câu và dấu phân tách phần tử)

Điều này bao gồm các dấu ngoặc mở và đóng nên nó chỉ cho chúng ta 254 octet địa chỉ email.

Nhưng hãy nhớ rằng số octet có thể không bằng số ký tự (một char có thể có 2 hoặc nhiều octet). Ngoài ra, phần RFC 4.5.3.1 cho biết rằng có thể có nhiều trường hơn là tối đa và điều này là có thể nhưng không được đảm bảo cho máy chủ để bắt chúng một cách chính xác.

Và sau đó bạn có thể / phải sử dụng VARCHAR(254) để lưu trữ địa chỉ email.

Lưu ý: Ít nhất trong MySQL, một cột được khai báo là VARCHARnhỏ hơn hoặc bằng 255 octet sẽ được lưu trữ dưới dạng 1 byte + length(số 1 là lưu trữ độ dài) vì vậy không có khoảng trống nào được sử dụng nếu sử dụng giới hạn thấp hơn.


Bạn không giải thích được cách bạn đi từ 256 byte đến 254. Tôi biết đây là kết quả của dấu ngoặc mở / đóng, nhưng bạn nên giải thích điều này như một phần của câu trả lời.
Gili

2

Như những người khác đã nói, cách lớn hơn 20. 256 + 64 nghe có vẻ tốt đối với tôi và tuân thủ RFC.

Lý do duy nhất để không có giá trị lớn như vậy cho cơ sở dữ liệu của bạn là nếu bạn đang lo lắng về hiệu suất hoặc dung lượng và nếu bạn đang làm điều đó thì tôi 99,99999999999999% chắc chắn rằng đó là tối ưu hóa quá sớm .

Đi lớn.


VARCHAR chỉ lưu trữ số ký tự cần thiết (cộng với độ dài). Vấn đề duy nhất tôi thấy là nếu bạn đang đấu tranh cho không gian trong giới hạn 8000 byte mỗi hàng.
Richard Szalay, 29/07/09

Tôi không đấu tranh cho không gian. Tôi đang đấu tranh cho sự cân bằng giữa bảo mật và khả năng sử dụng.
Léo Léopold Hertz 준영

2

Trường CHAR (20) sẽ luôn chiếm 20 ký tự, cho dù bạn có sử dụng tất cả hay không. (Thường được đệm bằng khoảng trắng ở cuối.) Trường VARCHAR (20) sẽ chiếm tối đa 20 ký tự nhưng có thể chiếm ít hơn. Một lợi ích của độ rộng không đổi CHAR () là nhảy nhanh đến một hàng trong bảng, bởi vì bạn chỉ có thể tính chỉ số mà nó phải có. Hạn chế là lãng phí không gian.

Lợi ích của CHAR (x) có kích thước không đổi sẽ bị mất nếu bạn có bất kỳ cột VARCHAR (x) nào trong bảng của mình. Tôi dường như nhớ lại rằng MySQL đã âm thầm chuyển đổi bất kỳ trường CHAR () nào thành VARCHAR () ở hậu trường nếu một số cột là VARCHAR () s.

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.