Какова оптимальная длина электронного адреса в базе данных?


95

Вот извлеченная часть моего запроса, отражающая EMAIL_ADDRESSтип данных и свойство столбца:

EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, 

Однако Джон Сондерс использует VARYING(256).

Это наводит на мысль, что я не обязательно правильно понял РАЗЛИЧНЫЕ.

Я так понимаю, что длина адреса электронной почты в моем случае составляет 20 символов, а для Jodn - 256.

Контекст в коде Джона

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, которое накладывает дополнительные ограничения сверх тех, которые указаны для локальной и доменной частей. Если место для хранения является проблемой, людям стоит знать, если они наткнутся на эту тему. См. Errata ID 1690 в списке исправлений к RFC3696
HexAndBugs

Как сказал @flightplanner, Википедия суммирует эти разделы здесь : «но максимум ... ограничивает весь адрес электронной почты не более 254 символов»
RustyTheBoyRobot

2
Особенно, если вы хотите, чтобы поле электронной почты имело уникальное ограничение; в INNODB и utf8 varchar (254) достаточно мал (менее 767 байт), чтобы иметь уникальное ограничение, а varchar (300) - нет.
Autonomy

В RFC 3696 с идентификатором ошибки 1003 я обнаружил, что 256 символов - это практический предел (и 320 символов - максимум).
Арнольд Шрайвер,

56

из Ask Metafilter :

Мои данные взяты из базы данных из 323 адресов. Распределение имеет некоторые выбросы в верхней части (с положительным перекосом). Обычно он распространяется без выбросов (я его тестировал).

Мин .: 12 1-й квартиль: 19 Среднее (без выбросов): 23,04 Среднее без выбросов): 22,79 3-й квартиль: 26 Макс. (Без выбросов): 47 Макс. (Без выбросов): 35

Медиана: 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 varchar ... Бьюсь об заклад, у них есть альтернативное электронное письмо с 40
символами, которое

18

Просто используйте varchar(50). Каждый раз длинные электронные письма - это дерьмо.

Вы только посмотрите, как долго это 50 символов:

peoplewithanemail @ ddressthislongjustuseashorterone

Если вы разрешаете 255-символьные электронные письма:

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

(Статистика показывает, что на самом деле никто не вводит более 50 символов для законного адреса электронной почты, см., Например, ответ пейджмена https://stackoverflow.com/a/1199245/87861 )


5
Полностью согласен. У кого в здравом уме больше будет электронный адрес? Конечно, теоретически правильно, что электронное письмо может состоять из 320 символов, но в реальном мире? В своих системах я также использую varchar (50), и у меня никогда не было жалоб на то, что пользователь не может зарегистрироваться.
Норберт Норбертсон

2
Было бы интересно узнать из огромных наборов данных, какова средняя длина электронного письма в реальном мире, каковы выбросы и насколько велики.
Норберт Норбертсон

4
Неправильно. Есть много реальных пользователей, у которых в электронном письме более 50 символов, и, что более важно, они не могут изменить его только для вас. Отказать им в доступе к чему-то, что они не могут исправить, - несправедливо.
Маркус Даунинг

2
они могут создавать новые электронные письма, конечно, могут. сделайте Google один.
Николас Манзини

Также не забывайте об обозначении плюса. Некоторые опытные пользователи используют это, чтобы разделить и упорядочить свои электронные письма в своем почтовом ящике. По сути, у них будет уникальный (под) адрес электронной почты для каждого веб-сайта / услуги / приложения. Например, давайте представим, что моя обычная электронная почта - это мое имя и фамилия в названии какой-либо компании: firstnameandlastone@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 Errata 1003 :

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

И из раздела 4.5.3.1.3 RFC 5321 :

4.5.3.1.3. Путь

Максимальная общая длина обратного или прямого пути составляет 256 октетов (включая знаки препинания и разделители элементов).

Это включает открывающие и закрывающие скобки, поэтому мы можем использовать только 254 октета адреса электронной почты.

Но имейте в виду, что количество октетов может не совпадать с количеством символов (у char может быть 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 байт на строку.
Ричард Салай,

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

2

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

Преимущество CHAR (x) постоянного размера теряется, если в вашей таблице есть столбцы VARCHAR (x). Кажется, я припоминаю, что MySQL незаметно преобразовал любые поля CHAR () в VARCHAR () за кулисами, если некоторые столбцы были VARCHAR () s.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.