📧 — Символ E-mail эмоджи (U+1F4E7)
Начертание символа «Символ E-mail» в разных шрифтах
📧Ваш браузер
Описание символа
Символ E-mail. Различные символы и пиктограммы.
Связанные символы
Кодировка
| Кодировка | hex | dec (bytes) | dec | binary |
|---|---|---|---|---|
| UTF-8 | F0 9F 93 A7 | 240 159 147 167 | 4036989863 | |
| UTF-16BE | D8 3D DC E7 | 216 61 220 231 | 3627932903 | 11011000 00111101 11011100 11100111 |
| UTF-16LE | 3D D8 E7 DC | 61 216 231 220 | 1037625308 | 00111101 11011000 11100111 11011100 |
| UTF-32BE | 00 01 F4 E7 | 0 1 244 231 | 128231 | 00000000 00000001 11110100 11100111 |
| UTF-32LE | E7 F4 01 00 | 231 244 1 0 | 3891527936 | 11100111 11110100 00000001 00000000 |
unicode-table.com
Никогда не проверяйте e-mail адреса по стандартам RFC / Habr
Множество сайтов требуют от пользователя ввода адреса электронной почты, и мы, как крутые и щепетильные разработчики, всегда стремимся проверять формат введенных адресов строго по стандартам RFC. Благодаря этому наши приложения и сайты проверяют формат e-mail корректно и не имеют проблем с юзабилити, а мы сладко спим, потому что уверены, что все работает как надо.Приведенные выше аргументы звучат круто и железобетонно, но проблема здесь заключается в том, что в адресе почты могут находиться совершенно бессмысленные вещи, и, на деле, проверка адресов по стандартам RFC может, наоборот, все жутко запутать.
Почему так? Существует множество способов сформировать адрес почты, который будет одновременно и корректным и бредовым. Отчасти это происходит из-за того, что некоторые почтовые службы в целях обратной совместимости позволяют представлять адреса в форматах, которые давно устарели. Например это электронная почта существовавшая до появления DNS и до появления современного формата [email protected]: тогда использовались UUCP ”bang path” — адреса, которые представляли собой список всех узлов по маршруту ответственных за доставку.
Внутренности адреса почты
mailbox@hostname
Тут mailbox может быть локальным аккаунтом пользователя, аккаунтом роли или маршрутизатором автоматизированной системы такой, например, как список рассылки, а в качестве hostname может быть использован любой узел, если о нем известно DNS-серверу, к которому обращается почтовик при доставке.
Кроме того, некоторые системы позволяют добавлять теги к адресу. Обычно это происходит в формате:
mailbox+tag@hostname
где тег и разделитель (обычно это «+», но qmail использует «-» по-умолчанию, хотя может быть сконфигурирован и иначе) игнорируются при доставке. Обычно это используется для фильтрации почты по папкам и автоматизации, но может быть использовано и для разделения введенных адресов по получателям и выявления злоупотреблений персональными данными.
Итак, в адресе в формате «mailbox@hostname», «mailbox» является пользовательским аккаунтом, приложением или аккаунтом системной роли, но может содержать и такие экстравагантные вещи, как информацию для дальнейшей маршрутизации или идентификаторы используемые для сортировки, автоматизации или отслеживания, а «hostname» — обычно доменное имя, но может являться и субдоменом, сервером, сервисом, ip-адресом или просто именем хоста.
Корректные имена ящика с точки зрения RFC
Ящик может содержать пробелы. Насколько я помню, доинтернетовский AOL разрешал пробелы в «Imya Polzovatelya», которые использовались еще и как почтовые ящики с вырезанными оттуда пробелами: «[email protected]», однако ж согласно RFC вы можете использовать двойные кавычки вокруг ящиков содержащих пробелы:
"Alan Turing"@example.com <== Это корректно, но поддерживать не стоит
Кстати говоря, по этой логике, ящик содержащий всего лишь пробел корректен:
" "@example.com <== Это корректно, но смотри выше
А вот еще один корректный адрес, он создан из допустимых для адреса символов:
!#$%&'*+-/=?^_`{}|[email protected] <== Корректный адрес вряд ли достойный поддержки
Кстати, проверяйте апострофы, апострофы должны поддерживаться:
Miles.O'[email protected] <== Стоит поддерживать
Апострофы не должны закавычиваться или эскейпиться, но когда вы сохраняете такие адреса в базу или передаете еще куда-то, убедитесь, что всё чики-пуки.
В Википедии есть еще куча примеров.
Нужна ли полная совместимость с RFC? Вам выбирать, но я не советую — пробелы и нестандартные символы в адресе довольно необычная штука и чаще всего являются просто опечаткой. Крупные e-mail провайдеры не разрешают использовать это примерно по тем же причинам; таким образом обычно достаточно дозволять буквы, цифры, точки, подчеркивания, дефисы, апострофы и плюсы.
Регистрозависимые адреса
Согласно RFC уникальность адреса определяется его регистрозависимой уникальностью, однако 99,9% провайдеров считают иначе и не позволяют регистрировать [email protected], если [email protected] уже зарегистрирован. Считайте, что имя почтового ящика регистронезависимо:
[email protected]
[email protected]
[email protected]Небольшая кучка систем использует полную проверку регистра, позволяя лишь адрес [email protected] и отбрасывая входящую корреспондецию всех остальных АлЛеНоВ, однако это не работает на практике, поскольку пользователь не привык различать регистр в адресах почты.
Должны ли вы тут сохранять совместимость с RFC? Конвертируя адреса в нижний регистр перед сохранением вы можете доставить проблем небольшому количеству пользователей (вы не сможете посылать им письма), но отослав миллионы e-mail я столкнулся с этим всего несколько раз.
Конвертация в адреса в нижний регистр является неплохой идеей в плане нормализации данных, так как домен всегда регистронезависим и должен быть в нижнем регистре. Если же вы решите сохранять адрес так, как он введен, добавьте поле, в котором будет хранить каноническую версию.
Нестандартные символы
Gmail тут отличился: в то время как стандарт включает в себя точку как стандартный символ, Gmail не делает различий между адресами ящиков с точками и без. Эти адреса указывают на один и тот же почтовый ящик:
[email protected]
[email protected]
[email protected]Обратите внимание, что Google Apps позволяет использовать Gmail на любом домене.
Основная проблема здесь заключается в поиске адреса в базе в том виде, в котором он был изначально введен, что может доставить немало геморроя как пользователю, так и службе поддержки, а также и программистам с тестировщиками. Тут то вам и пригодится вторая, канонiческая форма адреса, но об этом позже.
Расширенная форма названия ящиков с использованием тегов.
Как было сказано выше, большинство систем доставки электронной почты (MTA), включая sendmail, Postfix, qmail, Yahoo Plus и Gmail поддерживают расширенное название ящика. Это позволяет пользователю, добавляя тег, сортировать письма. Это может позволить мне насоздавать кучу аккаунтов на одном сайте или в приложении:
[email protected]
[email protected]
Но нужно ли вычищать теги из адреса ящика?
НЕТ! Будьте дружелюбны к своим пользователям, и пользователи проникнутся верой, что вы не осуществите хищение и сбыт их персональных данных с целью наживы. Даже если вы пытаетесь запретить регистрацию дополнительных аккаунтов с существующим ящиком, представьте себе, насколько просто в наше время тупо зарегистрировать еще один ящик чтобы снова зарегистрироваться у вас — не сложнее создания алиаса или папки(но об алиасах, папках и тегах, наоборот, мало кто знает).
Итак, еще раз. Создание второй, канонической, формы сохранения адреса в базе может неплохо прикрыть
Юникод и интернационализированные имена ящиков
Имена ящиков не поддерживают расширенные символы ASCII (8-bit) и символы Юникода. Это ограничение уходит своими корнями в спецификацию SMTP, во времена появления которого всего этого попросту не существовало; однако 8-битные значения, определенные локально, например из кодировок семейства ISO-8859-x, все-таки могут использоваться, но вы все равно никогда не узнаете, что же это за кодировка. Фактически, я видел 8-битные ящики только у спамеров.
В конце концов, вы ведь храните ваши данные в UTF-8, так? Значит вы в любом случае не сможете перевести их обратно в ту локаль, которая была использована, если вы ее не знаете.
Доменные имена
У почтовых доменов те же самые ограничения как и в HTTP: они регистронезависимые, так что их следует нормализовывать в нижний регистр.
Поддомены
Некоторые адреса содержат ненужные поддомены: например, «email.msn.com» и «msn.com» являются одним и тем же почтовым доменом, кроме того, такие истории часто случаются в корпоративной среде (и это еще один хороший кандидат для каноникализации).
Интернационализированные домены (IDN)
IDN были созданы для того чтобы использовать местные символы Юникода в названиях доменов, кроме того, возможно создать домен и со специальными символами:
postmaster@→→→→→→→.ws
этот классно описывает круговорот воды в природе.
Как и HTTP, SMTP поддерживает лишь 7-битную кодировку, и для того чтобы справиться с этим несчастьем IDN конвертируются в Punycode, что позволяет имени домена конвертироваться в представление Юникод и обратно:
[email protected]
Очень жаль, но существует возможность фишинга при использовании IDN. Юникод содержит несколько разных экземпляров некоторых символов ASCII. Это позволяет злоумышленнику создать сайт, название которого выглядит точно также как и оригинал из-за того, что некоторые символы в названии совпадают внешне, но не внутренне.
Это порождает несколько вопросов на которые следует ответить:
Должны ли мы дозволять IDN-адреса? Можем ли мы обеспечить саппорт пользователей службой поддержки (откуда у саппорта, например, клавиатуры с китайскими иероглифами?) Должны ли мы сохранять их в Юникоде или Punycode? Если мы сохраняем каноничные адреса, то в какой кодировке это делать? Поддерживает ли вообще наш почтовик (MTA) IDN, и в какой форме он ждет адреса при отправке писем?
IP Address syntax
Использование IP-адресов допустимо:
allen@[127.0.0.1]
allen@[IPv6:0:0:1]
Однако такие адреса выглядят подозрительно, и вряд ли им стоит доверять.
Временные почтовые адреса
Существует множество сервисов, которые предоставляют пользователям временные почтовые адреса. Обычно это используется для анонимности или для того чтобы регистрироваться на недоверенных сайтах.
Даже такие сервисы как Hotmail и Yahoo предоставляют алиасы, которые могут быть использованы примерно тем же способом, то есть уничтожены через некоторое время. Не существует единой техники выявления таких адресов — в конце концов именно для этого они и предназначены. Они используют большущий набор доменных имен с постоянной ротацией для того чтобы быть на шаг впереди тех, кто пытается пресечь их деятельность.
Белый список используемых возможностей
Адреса электронной почты могут быть чудовищно сложными, но, навскидку, 99,99% (а может, и больше) придерживаются простых принципов, а остальные слишком утомительно поддерживать.
Итак, вам вероятно следует воздержаться от поддержки адреса, если он содержит:
- Зависимость от регистра
- Пробелы
- Кавычки или Эскейп-символы
- Специальные символы кроме
'._+- - Айпишники в поле домена
- IDN
Конечно, это может создать проблемы некоторым пользователям, но и в этом случае они скорее всего попытаются использовать какой-нибудь другой адрес, который подойдет. Кроме того, это позволит вашему саппорту более качественно оказывать поддержку вне зависимости от пользовательской локали.
Если это необходимо, вы можете создать еще одно поле в базе с каноническим адресом, даже если считаете, что всю эту RFC-шную совместимость стоит поддерживать. Адрес в таком поле может быть:
- Приведен в нижний регистр
- Быть без тегов
- Транскодирован из Юникода в ASCII
- Без дублирующихся поддоменов
Несмотря на то, что этот совет может показаться слишком радикальным, это все равно лучше, чем слепо подчиняться стандартам. Как знать, может когда-нибудь такая упрощенная нотация станет новым стандартом?
📨 — Входящая почта эмоджи (U+1F4E8)
Начертание символа «Входящая почта» в разных шрифтах
📨Ваш браузер
Описание символа
Входящая почта. Различные символы и пиктограммы.
Связанные символы
Кодировка
| Кодировка | hex | dec (bytes) | dec | binary |
|---|---|---|---|---|
| UTF-8 | F0 9F 93 A8 | 240 159 147 168 | 4036989864 | 11110000 10011111 10010011 10101000 |
| UTF-16BE | D8 3D DC E8 | 216 61 220 232 | 3627932904 | 11011000 00111101 11011100 11101000 |
| UTF-16LE | 3D D8 E8 DC | 61 216 232 220 | 1037625564 | 00111101 11011000 11101000 11011100 |
| UTF-32BE | 00 01 F4 E8 | 0 1 244 232 | 128232 | 00000000 00000001 11110100 11101000 |
| UTF-32LE | E8 F4 01 00 | 232 244 1 0 | 3908305152 | 11101000 11110100 00000001 00000000 |
| Вид | HTML-код | CSS-код | Описание |
|---|---|---|---|
| | \00A0 | Неразрывный пробел | |
| ­ | \00AD | Место возможного переноса | |
| < | < | \003C | Знак «меньше чем» (начало тега) |
| > | > | \003E | Знак «больше чем» (конец тега) |
| « | « | \00AB | Левая двойная угловая скобка |
| » | » | \00BB | Правая двойная угловая скобка |
| ‹ | ‹ | \2039 | Левая угловая одиночная кавычка |
| › | › | \203A | Правая угловая одиночная кавычка |
| « | " | \0022 | Двойная кавычка |
| ′ | ′ | \2032 | Одиночный штрих |
| ″ | ″ | \2033 | Двойной штрих |
| ‘ | ‘ | \2018 | Левая одиночная кавычка |
| ’ | ’ | \2019 | Правая одиночная кавычка |
| ‚ | ‚ | \201A | Нижняя одиночная кавычка |
| “ | “ | \201C | Левая двойная кавычка |
| ” | ” | \201D | Правая двойная кавычка |
| „ | „ | \201E | Нижняя двойная кавычка |
| ❜ | ❜ | \275C | Жирная одинарная верхняя запятая |
| ❛ | ❛ | \275B | Жирная одинарная повёрнутая верхняя запятая |
| & | & | \0026 | Амперсанд |
| ‘ | ' | \0027 | Апостроф (одинарная кавычка) |
| § | § | \00A7 | Параграф |
| © | © | \00A9 | Знак copyright |
| ¬ | ¬ | \00AC | Знак отрицания |
| ® | ® | \00AE | Знак зарегистрированной торговой марки |
| ¯ | ¯ | \00AF | Знак долготы над гласным |
| ° | ° | \00B0 | Градус |
| ± | ± | \00B1 | Плюс-минус |
| ¹ | ¹ | \00B9 | Верхний индекс «1» |
| ² | ² | \00B2 | Верхний индекс «2» |
| ³ | ³ | \00B3 | Верхний индекс «3» |
| ¼ | ¼ | \00BC | Одна четверть |
| ½ | ½ | \00BD | Одна вторая |
| ¾ | ¾ | \00BE | Три четверти |
| ´ | ´ | \00B4 | Знак ударения |
| µ | µ | \00B5 | Микро |
| ¶ | ¶ | \00B6 | Знак абзаца |
| · | · | \00B7 | Знак умножения |
| ¿ | ¿ | \00BF | Перевернутый вопросительный знак |
| ƒ | ƒ | \0192 | Знак флорина |
| ™ | ™ | \2122 | Знак торговой марки |
| • | • | \2022 | Маркер списка |
| … | … | \2026 | Многоточие |
| ‾ | ‾ | \203E | Надчеркивание |
| – | – | \2013 | Среднее тире |
| — | — | \2014 | Длинное тире |
| ‰ | ‰ | \2030 | Промилле |
| } | } | \007D | Правая фигурная скобка |
| { | { | \007B | Левая фигурная скобка |
| = | = | \003D | Знак равенства |
| ≠ | ≠ | \2260 | Знак неравенства |
| ≅ | ≅ | \2245 | Конгруэнтность (геометрическое равенство) |
| ≈ | ≈ | \2248 | Почти равно |
| ≤ | ≤ | \2264 | Меньше чем или равно |
| ≥ | ≥ | \2265 | Больше чем или равно |
| ∠ | ∠ | \2220 | Угол |
| ⊥ | ⊥ | \22A5 | Перпендикулярно (кнопка вверх) |
| √ | √ | \221A | Квадратный корень |
| ∑ | ∑ | \2211 | N-ичное суммирование |
| ∫ | ∫ | \222B | Интеграл |
| ※ | ※ | \203B | Знак сноски |
| ÷ | ÷ | \00F7 | Знак деления |
| ∞ | ∞ | \221E | Знак бесконечности |
| @ | @ | \0040 | Символ собака |
| [ | [ | \005B | Левая квадратная скобка |
| ] | ] | \005D | Правая квадратная скобка |
my-mails.ru
Символ электронной почты | biz-incom.ru
Символ @ в настоящее время приобрел известность как символ электронной почты, однако он был широко распространен за долго до появления компьютеров. Самые ранние упоминания этого символа относятся к средневековью. Символ @ использовался в древних рукописях, написанных на латыни. В рукописях на латыни употреблялся предлог «ad», что на современном английском произносится как «at» – (русск. «на», «в»). В латинском предлоге «ad» символ «d» имел начертание с «хвостом» вверху, что делало похожим его на цифру 6, перевернутую зеркально. Со временем предлог «ad» начали изображать в рукописях как @.
В 15 веке символ @ в Испании и Италии использовался для обозначения меры веса. @ — «arroba» – означал меру веса примерно в 11, 5 килограмм. В различных эпохах символ @ имел разное назначение. Им обозначали цены, символ имел хождение в различной бухгалтерской документации.
В наше время, символ @ известен по всему миру. В Испании и Португалии мера веса «arroba» используется по прежнему. Во Франции появилось языковое заимствование слово arobas — «аробаз». В Англии и в Америке знак @ называют at sign — «знак эт». В немецком языке название знака @ звучит как at-Zeichen. В японском языке знак @ произносится как atto maak./span>
Различные народы мира не имея истории практического применения символа @, как например в Испании, дали название символу исходя из метафорических образов, связанных с формой знака, и особенностей его восприятия.
В Африке символ @ сравнивают с обезьяньим хвостом. Корейцы называют символ @ улиткой. В Дании символ @ называют хоботом слона. В Китае прижилось название @ — мыш. Фины сравнивают символ @ с спящей кошкой.
В России символ @ известен как «собака». Происхождение такого названия так же имеет несколько версий. Возможно, из за того, что звучание английского «at» напоминает собачий лай, либо напоминает по форме спящую собаку. Еще одна версия связана с первыми компьютерными играми, героем одной из которых был пес. Поскольку игра была не графической с изображениями людей, а самой простой, в связи с невысокими возможностями техники того времени, герои игры были условно изображены различными текстовыми символами. Пес был изображен символом @.
Значение символа собака @ у многих народов ассоциируется с едой. Например в Испании этот знак иногда называют конфетой, исходя из формы конфет, которые производятся там же и имеют выгнутую в спираль форму.
Благодаря раннему хождению знака @ в бухгалтерских отчетах, ему нашлось место на клавиатуре первых печатных машинок. В современном языке коммерции символ @ называется «коммерческое «at». В ранних бухгалтерских документах символ обозначал предлоги « В», «ПО». Знак использовался, например в документах на закупки. Запись о закупке товара в количестве 10 штук ценой по 5 долларов за штуку, имела вид – 10 widgets @ $5 each. К моменту создания первых ЭВМ, символ утратил коммерческое назначение, и хождение в бухгалтерских документах прекращено.
В связи с былой распространенностью, символ @ не был забыт. С появлением первых компьютеров знак @ нанесли и на клавиатуру ЭВМ. Впервые на компьютерной клавиатуре символ @ появился в 1971 году.
Символ @ в настоящее время превратился в символ электронной почты. С началом развития компьютерной техники возникла необходимость передачи файлов с одного компьютера на другой. В конце 60 – х годов по заказу министерства обороны США был организован проект ARPANet, предполагающий соединение компьютеров, существовавших в то время в единую сеть. Этот проект стал прообразом современного интернета. Одной из участников проекта была компания BBN Technology, в которой работал исследователь Рэй Томлинсона (Ray Tomlinson).
К моменту запуска проекта, уже существовали программы для передачи файлов от одного пользователя к другому. Необходимо было усовершенствовать процесс передачи сообщений. Томлинсон разработал виртуальный почтовый ящик – специальный файл, в который можно было добавлять файл сообщения, но корректировать его было невозможно. Первые сообщения, переданные с использованием почтовой программы, были переданы спустя полгода после начала экспериментов с почтовыми файлами. Все работы были строго засекречены.
С созданием электронного почтового файла сразу возникла проблема определения адреса абонента, для которого предназначалось сообщение. Для определения адреса получателя, был разработан универсальный алгоритм построения электронного адреса – «Имя получателя – Знак разделения – Место, где находится хост получателя».
Если с именем пользователя и названием места расположения хоста получателя проблем не возникало, то с знаком машинного распознавания для отделения имени пользователя от названия хоста возникли трудности. Синтаксис адреса электронной почты должен был включать в себя знак разделения, который бы присутствовал на клавиатуре и в то же время был уникальным, единственным в своем роде и не использовавшийся в написании любых имен, в том числе и иностранных. Томлинсон выбрал символ @. Благодаря использованию, символ электронной почты @ стал самым известным и употребляемым символом в мире.
biz-incom.ru
Адрес электронной почты — Википедия
Материал из Википедии — свободной энциклопедии
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 16 октября 2019; проверки требует 1 правка. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 16 октября 2019; проверки требует 1 правка.Адрес электронной почты — запись, установленная по RFC 5322, однозначно идентифицирующая почтовый ящик, в который следует доставить сообщение электронной почты.
Адрес состоит из двух частей, разделённых символом «@». Левая часть указывает имя почтового ящика, часто оно совпадает с логином пользователя. Правая часть адреса указывает доменное имя того сервера, на котором расположен почтовый ящик.
Существуют и иные (более сложные или устаревшие) формы адреса электронной почты, но они используются редко.
При доставке сообщения почтовый сервер отправителя выделяет правую часть адреса и разрешает при помощи DNS соответствующее доменное имя. При этом запрашивается запись типа MX (англ. mail exchange). Обычно у почтовых доменов несколько MX-записей, каждая из которых имеет определённый приоритет, обозначенный целым числом. Чем меньше это число, тем выше приоритет.
Ниже приведён пример, показывающий, куда должно быть отослано письмо, имеющее адрес назначения [email protected]. Запрос в DNS возвращает MX-запись для соответствующего домена:
$>host -t mx wikipedia.org wikipedia.org mail is handled by 50 pascal.knams.wikimedia.org. wikipedia.org mail is handled by 10 mail.wikimedia.org. $>
В этом примере указаны два сервера электронной почты, обслуживающие домен wikipedia.org. Они имеют приоритет 50 и 10 соответственно. Это значит, что для любого адреса электронной почты, содержащего в правой части wikipedia.org, почта должна передаваться на хост mail.wikimedia.org (первичный сервер), а если он недоступен, то на хост pascal.knams.wikimedia.org (вторичный сервер).
Почтовый сервер отправителя соединяется по протоколу SMTP с почтовым сервером, указанным в MX-записи, и передаёт ему сообщение.
ru.wikipedia.org
Почему значок @ в адресе электронного письма называется «собака»?
На украинском языке этот символ носит название «равлик» (улитка), на болгарском, польском, немецком — Affe (обезьянка), на казахском — айқұлақ (букв. «ухо луны»). Не правда ли странно? Как же называется этот «странный» символ?
Согласно правилам написания адреса письма для электронной почты, этот значок разделяет имя пользователя и наименование почтовой службы, где искомое имя зарегистрировано. Впервые использовать этот символ предложил программист Рэй Томлинсон в ноябре 1971 года, отправляя первое в мире подобное электронное письмо. Электронная почта как таковая существовала и до Томлинсона, но он первый предложил использовать именно этот значок @ для разделения имени и домена.
Почему был выбран в итоге именно этот значок, а не что-то иное, мы расскажем отдельно, а сейчас – как же правильно его называть? Совершенно очевидно, что в каждом языке его называют по-своему. Как же правильно его называть по-русски?
Похожие на @ знаки встречаются в русских книгах еще XVI—XVII веков. В частности, как пишет Википедя, на заглавном листе Судебника Ивана Грозного (1550 г.) уже присутствовал такой значок. Это была украшенная завитком буква «аз», обозначающая в кириллической системе счисления единицу. В случае с Судебником этот значок обозначал «первый пункт».
В СССР этот знак не применялся до появления персональных компьютеров.
Одна из версий происхождения названия «собака» гласит следующее:
Цитата:На алфавитно-цифровых мониторах персональных компьютеров серии ДВК (1980-е годы) «хвостик» рисуемого на экране изображения этого символа был очень коротким, что придавало ему сходство со схематически нарисованной собачкой. Символ @ отображался при каждом включении компьютера ДВК, после чего пользователю необходимо было выбрать начальный загрузчик.
По другой версии происхождение, как рассказывает Википедия, названия «собака» связано с компьютерной игрой Adventure, в которой игрока сопровождал пес, которого можно было посылать с разведывательными миссиями и который обозначался символом @.
Этот символ также видели первые пользователи компьютерных сетей на эмблеме Фидонета: он изображал собаку, где знак @ располагается в центре морды и выполняет роль носа.
И когда этот значок стали использовать в адресах электронной почты, то первыми освоили новый инструмент именно программисты. Они по привычке или для шика воспользовались тем названием, к которому привыкли.
Но почему в других странах этот значок называется «обезьянка»? Неужели там не играли в те же игры, что советские разработчики?
Как пишет Википедия, в среде пользователей и поклонников компьютеров серии zx-spectrum ходило название «обезьяна». Некоторые модели были оснащены «волшебной» кнопкой, с помощью которой можно было сделать образ программы для использования на дисковых накопителях (адаптировать с ленты на диск). Значком на этой кнопке был знак @.
Почему его назвали именно «обезьянкой»?
Потому что очень часто этот подход портил программу. Поэтому данная кнопка получила название «обезьяньей» или просто «обезьяной».
blogs.pcmag.ru