Чи потрібно для мене мати електронну адресу в нижньому регістрі


11

Я розробляю флаєр, на якому є електронна адреса.

Чи потрібно мені мати електронну адресу в нижньому регістрі?

Або я можу це зробити у верхньому регістрі, щоб зробити більшу увагу?

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

Моєму клієнту, здається, не подобається ідея розміщення його у верхньому регістрі.


13
Якщо вашому клієнту це не подобається .., це має бути достатньою причиною не робити цього. Я б не погодився з таким питанням ні з одним клієнтом. це було б не так важливо для мене.
Скотт

4
Пам’ятайте, що адреси електронної пошти за замовчуванням
залежать

1
@Ferrybig підкреслює важливий момент: Інтернет може залежно від регістру. Незалежно від того, що вирішено, протестуйте адресу електронної пошти, використовуючи вказаний точний випадок, щоб бути впевненим, що вона отримає.
Йорик

4
@ 1171111 Прочитайте офіційну специфікацію smtp : "Локальна частина поштової скриньки ОБОВ'ЯЗКОВО трактуватись як регістр", отже, можна сказати, що адреси електронної пошти (частково) залежно від регістру за замовчуванням. Те, що більшість людей робить їх нечутливими до власного сервера, зовсім інша справа
Феррібіг

6
@Ferrybig: Специфікація вимагає, щоб будь-яка організація, яка переносить повідомлення, повинна доставити їй таку ж комбінацію верхнього та нижнього регістрів, що використовується відправником, що робить такі транспортні агенти чутливими до регістру. Остаточне розпорядження повідомлення залежить від одержувача. Якщо кінцевий хост, який отримує повідомлення, хоче розглядати fredjones, FredJones, FREDJONES і навіть BarneyRubble як ідентифікацію тієї самої поштової скриньки, це було б вільно зробити. Якщо він хоче розглянути це як чотири різні поштові скриньки, це теж буде дозволено.
supercat

Відповіді:


22

Клієнти мають остаточне слово. Навіть якщо ви не згодні з цим.

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

Якщо клієнту це не подобається, не робіть цього.

Якщо ви щось розробляєте, і клієнт просить вас змінити аспект, то, напевно, поясніть, чому ви вважаєте, що так, як у вас є, краще, на вашу думку. Однак якщо клієнт все-таки хоче, щоб речі змінилися, то змінити їх. Клієнт платить вам за послуги, тому у них є остаточне слово.


Справа електронної адреси не має технічного відношення.
Карл

3
@Carl, якщо сервер електронної пошти не відхиляє невідомі електронні листи через чутливість регістру. MYEMAIL@example.com - це не те, що myemail@example.com для деяких поштових серверів. це рідко, так. Але це НЕ неможливо.
Скотт

правда, хоча у протилежному випадку, коли клієнт хотів, щоб адреса електронної пошти була з усіма
великими

2
Немає жодних "поганих" чи "хороших" ідей, коли мова йде про адреси електронної пошти, є в основному лише характеристики, які зазначають, що частина перед символом @ може бути все, що хоче сервер (у тому числі залежно від регістру) і що частина після @ завжди нечутливий до регістру, оскільки це домен.
Пітер В.

13

ВІДПОВІДАЄТЬСЯ електронною поштою в верхніх шапках - це дійсно БАД ІДЕЯ. ВИКОРИСТАННЯ ТОМУ, ЩО "ЕМФАЗА" НЕЩО ВІД ВІД ТИПУВИТЕЛЯ ЕРДИ, де ви не мали інших варіантів.

Вибачте за це.

Як зауважують інші, хоча ім'я користувача в електронній пошті не залежно від регістру, доменне ім'я не відповідає. У деяких крайніх випадках використання YouCouldUseCamelCase використовує великі літери. Вони вживаються на довгих словах. Але вибір довгого слова як першої частини публічного електронного листа також є поганою ідеєю.

Іноді це може знадобитися для доменного імені. FreeDomainNames.Example.com

Правда полягає в тому, що ви повинні кинути цю ідею зараз. Навіть у коментарях у вас ідея зафіксована у вашій свідомості навіть після технічних аргументів

Вибачте, але це стосується флаєра, який я розробляю.

Ні, ви не проектуєте чохол для свого мобільного телефону, де ви можете використовувати єдинороги, якщо хочете.

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

Змінити розмір, змінити шрифт, змінити товщину, змінити вагу, змінити кернінг, покласти контур, покласти кулю, покласти піктограму, поставити вибух, поставити голограму ... у вас є варіанти.

Може бути якийсь аргумент, якби клієнт хотів це зробити. Але це не так.


3
Заява "адреса електронної пошти нечутлива до регістру", як правило, правдиво, але не універсально. Частина доменного імені повинна бути нечутливою до регістру, і багато хостів електронної пошти роблять локальну частину нечутливою до регістру, але вони цього не вимагають.
Monty Harder

Ось чому я вказав "доменне ім'я". Я це відредагую.
Рафаель

@Rafael Я щойно запропонував редагувати відповідне речення, оскільки воно все ще було досить незрозумілим та оманливим.
Jacus Bahs Jacquet

8

більший, сміливіший == помітніший, більш розбірливий.

ALLCAPS == кричати & насправді важче читати.

Я іноді використовую випадок заголовка на шахті, TxxxxxMedia, що робить його легше читати, і мій поштовий сервер не проти цього.

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


Так, але це я дійсно залежний від сервера. Постановка випробування shoiuldnt бути нелегким, хоча.
joojaa

1
"ALLCAPS == кричав" Я не міг більше погодитися, але я побачив шрифти, які в основному є усіма кришками, але якимось чином вдається не натрапляти на крик.
MonkeyZeus

6

Стандарт пошти говорить про те, що те, що знаходиться до @, може бути чутливим до регістру і знаходиться під контролем хост-системи, а те, що є після @, є нечутливим до регістру, як і під контролем системи доставки пошти.

На практиці префікс дуже рідко вважається чутливим до регістру (я ніколи не стикався з будь-якою такою системою), тому ви можете використовувати будь-який корпус, який хочете, і він буде працювати з дуже великою ймовірністю. Моя офіційна адреса щось подібне, john.smith@somedomain.frі я завжди представляю це як John.Smith@somedomain.fr; Я ніколи не мав жодних проблем більше 25 років ...


3
Я стикався із системами, які насправді дбали. Його рідко, але ви можете доглядати. Але ive бачив системи, які не хвилювались тим, що ви ввели пунктирну частину перед своїм ім'ям користувача.
joojaa

Це не дуже переконливо навести лише один приклад адреси електронної пошти, яка працює в нечутливому до регістру способі: немає сумнівів, що вони існують, але це не є доказом того, що навпаки теж не існує :)
psmears

@psmears Звичайно, як це дозволено, але це досить рідко і сильно не рекомендується це робити.
Жан-Батист Юньєс

1
Ваш один сервер ніколи не дбав. Це нічого не говорить про те, чи буде турбуватися чужий сервер чи ні. Однак протестувати досить просто. Надішліть електронний лист на JOHN.SMITH@SOMEDOMAIN.FR і подивіться, чи надійде він. Якщо так, ця адреса прийому працюватиме для всіх.
CJ Dennis

@CJDennis У мене було кілька звернень від багатьох різних постачальників (GAFA і так само, приватні компанії, державні інститути, приватні сервери тощо), я ніколи не експериментував із ситуацією з поштою. Програмне забезпечення поштового сервера не так багато, і майже кожен адміністратор використовує одну з трьох-чотирьох доступних і майже використовує конфігурацію одного типу (що не стосується випадку).
Жан-Батист Юнес

5

Залежить від поштової системи. Багато поштових систем насправді не цікавлять, але їх можна налаштувати на догляд. Деякі системи також дозволяють мати додаткові матеріали у поштових адресах, попросіть у постачальника пошти документацію.


Вибачте, але це стосується флаєра, який я розробляю. Спасибі все одно.
Бьорн Ліза

4
@BjornLiza Якщо ви цього не знаєте, ви не можете змінити.
joojaa

2

Як дизайнер, ви можете показати найкраще дизайнерське рішення, а також те, про що вони просили, щоб він мав найбільший вибір.

Це друкований флаєр? Якщо так, підкресліть електронну адресу найкращим чином, щоб люди могли її легко прочитати та запам'ятати.

Якщо це довга складна адреса, то ви повинні стилювати її, щоб відрізняти слова один від одного.

Усі літери потрібно прокласти разом, не маючи пробілів.

Випадок вирок, з першої літери кожного слова з великої літери, повинен бути найбільш розбірливим.

Я особисто не згоден із додаванням періодів між словами, але це вибір перед символом "@".

".Com" можна знецінити, звести до мінімуму або пропустити, якщо він є таким, як gmail.

Якщо це цифровий флаєр, а посилання електронної пошти повинно працювати і бути доступним для натискання, застосовуються ті самі правила, оскільки html та css дозволяють маскувати посилання як щось інше, ніж повнотекстова версія електронної адреси.

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


На друкованому флаері ніколи не видаляйте жодної частини адреси електронної пошти. Ви не можете просто видалити .com біт адреси Gmail і очікувати, що люди отримають його - вони не стануть. Вони надішлють електронний лист на ваше ім’я @ gmail і будуть засмучені і розлючені, коли воно не надійде. Додавання періодів між словами також очевидно не допоможе створити флаєр із наявною адресою електронної пошти - це варіант при налаштуванні облікового запису електронної пошти, а не під час введення існуючого в дизайні. Справа про вирок, як уже казали інші, потенційно ризикована та руйнівна, а також просто виглядає погано.
Jaus Bahs Jacquet

-1

Не додайте безглуздого шару в щось таке просте. Адреси електронної пошти - це малі регістри, тому що саме так. Не майте людей, які думають, що потрібно робити додаткові зусилля, щоб утримувати додатковий ключ, коли цього не роблять. Використовуйте підхід KISS ("тримайте це просто, дурно"; не спрямовано на вас).

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