Яка оптимальна довжина адреси електронної пошти в базі даних?


95

Ось витягнута частина мого запиту, що відображає EMAIL_ADDRESSтип даних та властивість стовпця:

EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, 

Однак Джон Сондерс використовує VARYING(256).

Це свідчить про те, що я не обов'язково правильно розумів РІЗНИХ.

Я розумію це так, що довжина адреси електронної пошти в моєму випадку становить 20 символів, тоді як 256 для Jodn.

Контекст у коді Джона

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)
  );

Я ніколи не бачив електронних адрес довжиною більше 20 символів, якими користуються звичайні люди.

Яка оптимальна довжина адреси електронної пошти в базі даних?


Що ви маєте на увазі під "оптимальним"? Що ви намагаєтесь «оптимізувати»?
S.Lott,

1
@ S.Lott: Я хочу побудувати безпечну систему. Збільшення вводу користувача збільшує ризик того, що вони можуть запускати коди в базі даних. --- Я вважаю оптимальним найкращий спосіб забезпечити безпечну систему.
Лео Леопольд Герц 준영

1
Ну, хоча існують міркування безпеки, якщо не робити щось необмежене, дотримання стандартів завжди матиме найбільший сенс. Дотримання того, що є "загальним" чи "оптимальним", швидше за все, спричинить проблеми безпеки, а потім зменшить їх.
Кітсон,

1
Це питання на StackOverflow передбачає , що максимальна довжина тепер 254 символів , включаючи символ «@»: stackoverflow.com/questions/386294 / ...
dthrasher

1
Ось родинне повідомлення по довжині електронної пошти від @DominicSayers, з дуже ретельно відповіддю: stackoverflow.com/a/574698/361842
JohnLBevan

Відповіді:


135

Максимальна довжина адреси електронної пошти - 254 символи.

Кожна електронна адреса складається з двох частин. Локальна частина, яка стоїть перед знаком "@", і частина домену, яка йде за нею. У "user@example.com" локальна частина - "user", а частина домену - "example.com".

Локальна частина не повинна перевищувати 64 символів, а частина домену не може перевищувати 255 символів.

Загальна довжина локальних частин домену + @ + електронної адреси не повинна перевищувати 254 символів. Як описано в RFC3696 Errata ID 1690 .

Оригінальну частину цієї інформації я отримав звідси


Здається, найкраще взяти 320 як довжину.
Лео Леопольд Герц 준영

40
Я знаю, що це старий потік, і тут немає проблем із використанням 320, але фактичний максимум - 254, оскільки переважне обмеження від RFC2821, яке накладає додаткові обмеження, крім зазначених для локальної та доменної частин. Якщо простір для зберігання даних є проблемою, люди можуть знати, якщо натраплять на цю тему. Див. Код помилки
HexAndBugs

Як сказав @flightplanner, Вікіпедія узагальнює ці розділи тут : "але максимум ... обмежує всю адресу електронної пошти не більше 254 символів"
RustyTheBoyRobot

2
Особливо, якщо ви хочете, щоб поле електронної пошти мало унікальне обмеження; під INNODB і utf8 varchar (254) досить малий (менше 767 байт), щоб мати унікальне обмеження, а varchar (300) - ні.
Автономія

У виправленні ідентифікатора RFC 3696 ID 1003, як я виявив, сказано, що 256 символів є практичним обмеженням (а максимум 320 символів).
Арнольд Шрейвер

56

від Ask Metafilter :

Мої дані надходять з бази даних 323 адрес. У розподілі є кілька вищих рівнів (позитивні перекоси). Зазвичай він розповсюджується без викидів (я тестував це.)

Хв: 12 1-й квартиль: 19 Середній (без вивільнювачів): 23,04 Середній без випусків): 22,79 3-й квартиль: 26 Макс. (Без вивільнювачів): 47 Макс.

Медіана: 23 Режим: 24 Ст. Розробник (з відхиленнями): 5,20 Розробка (без вибіжків): 4,70

Діапазони на основі даних, включаючи викиди 68,2% даних 17,8 - 28,2 95,4% даних 12,6 - 33,4 99,7% даних 7,4 - 38,6

Діапазони, засновані на викидах даних, виключали 68,2% даних 18,1 - 27,5 95,4% даних 13,4 - 32,2 99,7% даних 8,7 - 36,9

Якщо ви підписалися на http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/ тоді ваша електронна адреса, безумовно, буде невідомим :)

Ось яка максимально безпечна довжина адреси електронної пошти допускається у формі веб-сайту? на Raycon із дещо іншим середнім значенням (N = 50 496, середнє = 23):

Розподіл довжини електронної адреси


@Masi насправді цікаво, що це розподіл Пуассона, а не звичайний розподіл - хтось має ідеї, чому це так? : P
pageman

@pageman: Причина в тому, що кожна подія розподіляється випадковим чином І кожна подія береться з простору нескінченності. - Ви отримаєте подібний розподіл, якщо розрахуєте кількість автомобілів, які їдуть до ЧЕРВОНОГО, таким чином, що у вас є час проти кількості машин, які їдуть до червоного по осях.
Лео Леопольд Герц 준영

Особисто мені більше подобається Закон Бенфорда: en.wikipedia.org/wiki/Benford%27s_law
Кітсон,

2
Я використовував 120 змінних символів протягом багатьох років. Реальна логіка полягає в тому, що навіть якщо хтось готовий заповнити ваше поле 320 варчар ... Б'юся об заклад, у них є альтернативний електронний лист із 40
символами, який

18

Просто використовуйте varchar(50). Більш довгі електронні листи щоразу трапляються.

Просто подивіться, скільки триває 50 символів:

peoplewithanemail @ ddressthislongjustuseashorterone

Якщо ви дозволяєте 255 електронних листів:

  • Показ їх може зіпсувати ваш інтерфейс користувача (у кращому випадку вони будуть відрізані, в гіршому випадку вони штовхають ваші контейнери та поля навколо) і
  • Зловмисні користувачі можуть робити з ними речі, яких ви не можете передбачити (наприклад, ті випадки, коли хакери використовували безкоштовний онлайн-API для зберігання маси даних)

(Статистика показує, що насправді ніхто не вводить більше ніж приблизно 50 символів для законної адреси електронної пошти, див., Наприклад: відповідь pageman https://stackoverflow.com/a/1199245/87861 )


5
Повністю згоден. Хто у здоровому глузді більше не матиме електронної адреси? Звичайно, теоретично правильно, що електронна пошта може мати 320 символів, але в реальному світі? У своїх системах я також використовую varchar (50), і ніколи не скаржився на те, що користувач не може зареєструватися.
Норберт Норбертсон,

2
Було б цікаво дізнатись із величезних наборів даних, яка середня довжина електронної пошти в реальному світі, які відхилення є і наскільки великі.
Норберт Норбертсон,

4
Неправильно. Існує безліч реальних користувачів, котрі містять у своїй електронній пошті більше 50 символів, і, що ще важливіше, вони не можуть змінити це лише для вас. Відмовляти їм у доступі через те, що вони не можуть виправити, несправедливо.
Маркус Даунінг,

2
вони можуть робити нові електронні листи, звичайно, можуть. зробити Google один.
Ніколас Манзіні,

Також не забувайте про позначення плюса. Деякі досвідчені користувачі використовують це для розподілу та упорядкування своїх електронних листів у свою поштову скриньку. По суті, вони матимуть унікальний (додатковий) електронний лист для кожного веб-сайту / послуги / програми. Наприклад, уявімо, що звичайною електронною адресою є моє ім’я та прізвище в назві якоїсь компанії: firstandlastone@superacmecompany.com. Це вже ~ 40 символів. Тепер, якщо я використовував позначення плюс для облікового запису stackoverflow: firstnameandlastone+stackoverflow@superacmecompany.com - це ~ 55 символів. Деякі позначення плюс можуть бути довшими, наприклад, + stackoverflow-personal та * -work.
Waterlink

16

Моя робоча електронна адреса має більше 20 символів!

Прочитайте відповідну специфікацію RFC :

"Локальна частина адреси електронної пошти може містити до 64 символів, а ім’я домену може містити максимум 255 символів"


4

Типи змінних символів у базах даних не займають непотрібного місця. Таким чином, немає причин обмежувати такі поля якомога більше. Залежно від імені особи, схеми імен, яку використовує їх організація, та доменного імені, адреса може легко перевищувати 20 символів.

У RFC-2822 немає обмежень щодо довжини локальної частини та доменного імені . RFC-2181 обмежує доменне ім'я 255 октетами / символами.

Знову ж таки, оскільки varchar використовує лише простір, який фактично використовується рядком, який ви зберігаєте, немає жодних причин для обмеження довжини адреси електронної пошти. Просто поїдьте з 512 і перестаньте хвилюватися. Все інше - це передчасна оптимізація


3

Спочатку максимум становить 320 символів (64 + 1 + 255, як показано в інших відповідях), але, як говориться в Помилці RFC 3696 1003 :

Однак у RFC 2821 є обмеження на довжину адреси в командах MAIL та RCPT у 256 символів. Оскільки адреси, які не поміщаються в цих полях, зазвичай не є корисними, верхньою межею довжин адрес зазвичай слід вважати 256.

А з розділу 4.5.3.1.3 RFC 5321 :

4.5.3.1.3. Шлях

Максимальна загальна довжина зворотного шляху або прямого шляху становить 256 октетів (включаючи розділові знаки та розділювачі елементів)

Це включає відкриваючі та закриваючі дужки, тож ми отримаємо лише 254 октети адреси електронної пошти.

Але майте на увазі, що кількість октетів може не дорівнювати кількості символів (символ може мати 2 і більше октетів). Також розділ 4.5.3.1 RFC повідомляє, що можуть бути поля більше, ніж максимум, і це можливо, але не гарантується серверам для їх правильного лову.

І тоді ви можете / повинні використовувати a VARCHAR(254)для зберігання адреси електронної пошти.

Примітка: Принаймні в MySQL стовпець, оголошений VARCHARні з чим, ні меншим або рівним 255 октетам, буде зберігатися як 1 byte + length(1 - для зберігання довжини), тому простір не забирається, якщо використовується нижня межа.


Ви не можете пояснити, як ви переходите з 256 байт на 254. Я знаю, що це результат відкриття / закриття дужок, але ви повинні пояснити це як частину відповіді.
Гілі

2

Як казали інші, набагато більше 20. 256 + 64 для мене звучить добре і відповідає RFC.

Єдина причина, щоб не мати такого великого значення для вашої бази даних, це якщо ви турбуєтесь про продуктивність чи простір, і якщо ви робите це, то я на 99,99999999999999% впевнений, що це передчасна оптимізація .

Йти великим.


VARCHAR зберігає лише необхідну кількість символів (плюс довжина). Єдиною проблемою, яку я бачу, є те, що ви боретеся за простір в межах 8000 байт на рядок.
Richard Szalay

Я не борюся за космос. Я борюся за баланс між безпекою та зручністю користування.
Лео Леопольд Герц 준영

2

Поле CHAR (20) завжди буде займати 20 символів, незалежно від того, використовуєте ви все це чи ні. (Часто заповнений пробілами в кінці.) Поле VARCHAR (20) займе до 20 символів, але може зайняти менше. Однією з переваг постійної ширини CHAR () є швидкий перехід до рядка в таблиці, оскільки ви можете просто розрахувати індекс, на якому він повинен бути. Недоліком є ​​марнотратство.

Перевага постійних розмірів CHAR (x) втрачається, якщо у вашій таблиці є стовпці VARCHAR (x). Здається, я згадую, що MySQL мовчки перетворював будь-які поля CHAR () у VARCHAR () за лаштунками, якщо деякі стовпці були VARCHAR ().

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.