2009-08-19 26 views
67

Tôi nhận ra rằng địa chỉ email về cơ bản có thể dài vô thời hạn nên bất kỳ kích thước nào tôi áp đặt vào trường địa chỉ email varchar của tôi sẽ tùy ý. Tuy nhiên, tôi đã tự hỏi "chuẩn" là gì? Các bạn làm được bao lâu? (Cùng một câu hỏi cho trường Name ...)Các trường email SQL nên dài bao lâu?

update: Rõ ràng độ dài tối đa cho một địa chỉ email là 320 (< = 64 tên phần, < = 255 tên miền). Bạn có sử dụng cái này không?

+1

RFC gì bạn đang sử dụng cho những giá trị đó? – IDisposable

+7

http: // stackoverflow.com/questions/386294/tối đa-length-of-a-hợp lệ-email-id – Mala

Trả lời

128

Giới hạn lý thuyết thực sự dài nhưng bạn có thực sự cần phải lo lắng về những địa chỉ email dài này không? Nếu ai đó không thể đăng nhập bằng Email 100-char, bạn có thực sự quan tâm không? Chúng tôi thực sự thích họ không thể.

Một số dữ liệu thống kê có thể làm sáng tỏ một số vấn đề. Chúng tôi đã phân tích một cơ sở dữ liệu với hơn 10 triệu địa chỉ email. Các địa chỉ này không được xác nhận để có địa chỉ không hợp lệ. Dưới đây là một số sự kiện thú vị,

  1. Một giá trị dài nhất là 89.
  2. Có những người hàng trăm còn lên đến giới hạn của cột của chúng tôi (255) nhưng họ rõ ràng là giả qua sự kiểm tra thị giác.
  3. Đỉnh của độ dài phân phối là 19.
  4. Không có đuôi dài. Mọi thứ đều giảm mạnh sau 38.

Chúng tôi đã dọn sạch DB bằng cách vứt bỏ bất kỳ thứ gì dài hơn 40. Tin tốt là không ai phàn nàn nhưng tin xấu không có nhiều hồ sơ được dọn sạch.

+23

Thank tốt đẹp đối với một số cảm giác thông thường?. Mọi người đều nói "làm cho nó 320!" xin vui lòng, * xin vui lòng * gõ ra một địa chỉ email 320 ký tự, có một cái nhìn dài khó khăn vào nó, và tự hỏi mình cho dù bất cứ ai trên trái đất sẽ bao giờ sử dụng một địa chỉ như vậy trong ứng dụng của bạn. – MGOwen

+8

40? Đoán bạn là sau đó trong một câu lạc bộ của nhà phát triển người chính thức ghét Facebook Proxy email (a.k.a - [email protected]ymail.facebook.com). Tôi thực sự rao giảng kích thước của 90 ... thú vị đủ, nó cũng đi với # 1 trên danh sách của bạn. – kape123

+1

Phụ thuộc vào email được sử dụng. Nếu nó dành cho người dùng, tôi đồng ý, 40, có thể 50 là đủ. Tôi chỉ làm một thử nghiệm và thấy đa số là từ 17 đến 25. Rất hiếm khi trên 40. –

15

Tôi đã làm trong quá khứ chỉ cần thực hiện 255 vì đó là tiêu chuẩn quá hạn của đầu vào ngắn nhưng không quá ngắn. Điều đó, và tôi là một sinh vật của thói quen.

Tuy nhiên, vì CPC tối đa là 319, tôi muốn làm nvarchar(320) trên cột. Phải nhớ số @!

nvarchar sẽ không sử dụng dung lượng bạn không cần, vì vậy nếu bạn chỉ có một địa chỉ email 20 ký tự, nó sẽ chỉ chiếm 20 byte. Điều này trái ngược với nchar sẽ luôn luôn chiếm tối đa của nó (nó phải đệm giá trị bằng dấu cách).

Tôi cũng sẽ sử dụng nvarchar thay cho varchar vì đó là Unicode. Với sự biến động của địa chỉ email, điều này chắc chắn là con đường để đi.

+2

255 + 64 = 319, 320 đang đếm @ – Havenard

+0

Tôi đang sử dụng phpMyAdmin để thiết lập cơ sở dữ liệu và tôi không thấy nvarchar bất cứ nơi nào ... tôi cần phải thiết lập đó bằng tay với một câu lệnh SQL, hoặc tôi chỉ thiếu nó ở đâu đó? – Mala

+5

thisemailaddressisonly160charslong-[email protected]butuserswithnoemailaddressunder100charswillNEVERbeanissue.com – MGOwen

4

Nếu bạn thực sự là mặt nạ về nó, hãy tạo một tên người dùng varchar (60), tên miền varchar (255). Sau đó, bạn có thể làm số liệu thống kê vô lý về việc sử dụng tên miền nhanh hơn một chút so với thực hiện nó như một trường đơn lẻ. Nếu bạn cảm thấy thực sự về việc tối ưu hóa điều đó, điều đó cũng sẽ làm cho máy chủ SMTP của bạn có thể gửi email với ít kết nối hơn.

+0

s/súng-ho/gung-ho/ – jameshfisher

+4

s/gung -ho? (: \ S * về)/dành riêng cho/ –

0

Đối với email, bất kể thông số kỹ thuật, tôi hầu như luôn đi với 512 (nvarchar). Tên và họ tương tự nhau.

Thực sự, bạn cần xem xét mức độ quan tâm của bạn về việc có thêm một ít dữ liệu. Đối với tôi, chủ yếu, nó không phải là một lo lắng, vì vậy tôi sẽ sai về mặt bảo thủ. Nhưng nếu bạn đã quyết định, thông qua phương tiện hợp lý và chính xác, bạn sẽ cần phải tiết kiệm không gian, sau đó làm như vậy. Nhưng nói chung, hãy bảo thủ với kích thước của trường, và cuộc sống sẽ tốt.

Lưu ý rằng có lẽ không phải tất cả các ứng dụng email đều hỗ trợ RFC, vì vậy bất kể những gì nó nói, bạn có thể gặp phải những thứ khác nhau trong tự nhiên.

5

Địa chỉ email sau đây chỉ là 94 ký tự:

[email protected]ngCompanyNameOfSomeKind.com.au

sẽ bạn thực sự sử dụng địa chỉ email như thế? có ai không? Tất nhiên là không. Quá lâu để nhập và quá khó nhớ.

Nếu không gian đĩa trong DB của bạn là vấn đề và bạn không ngại nếu một người dùng trong một triệu sử dụng địa chỉ email phụ để sử dụng trang web của bạn, hãy truy cập 50 ký tự: [email protected] com

(Sau đó, phần lớn thời gian, không gian đĩa không còn là vấn đề nữa, phải không?)

3

RFC 5321 (SMTP đặc tả hiện tại, obsoletes RFC2821) khẳng định:

4.5.3.1.1. Local-part

Tổng chiều dài tối đa của một người dùng tên hoặc một phần địa phương khác là 64
octet.

4.5.3.1.2. Tên miền

Tổng chiều dài tối đa là tên miền hoặc số là 255 octet.

Điều này liên quan đến miền localpart @, với tổng số 320 ký tự ASCII (7 bit).

Nếu bạn có kế hoạch để chuẩn hóa dữ liệu của bạn, có lẽ bằng cách tách localpart và miền vào các lĩnh vực riêng biệt, điều bổ sung cần ghi nhớ:

  • Một kỹ thuật được gọi là VERP có thể dẫn đến localparts full-length cho tự động thư được tạo (có thể không liên quan đến trường hợp sử dụng của bạn)
  • các miền không phân biệt chữ hoa chữ thường; khuyên bạn nên giảm phần miền
  • các vùng nội bộ có phân biệt chữ hoa chữ thường; [email protected][email protected] là các địa chỉ kỹ thuật khác nhau theo thông số kỹ thuật, mặc dù chính sách tại domain.com có thể là để xử lý hai địa chỉ là tương đương. Tốt nhất là hạn chế trường hợp nội bộ gấp thành các miền được biết là làm điều này.
1

tôi sử dụng varchar (64) tôi không nghĩ rằng bất cứ ai có thể có email còn

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