какие символы запрещается использовать в именах полей
Ограничения на имена полей и объектов
При задании имен полей таблиц, а также объектов базы данных и других элементов управления необходимо учесть действующие в MS Access ограничения на имена полей и объектов:
· имя должно содержать не более 64 знаков;
· имя может включать любую комбинацию букв, цифр, пробелов и специальных знаков за исключением точки (.), восклицательного знака (!), надстрочного знака (`) и квадратных скобок ([ ]);
· не должно начинаться с знака пробела;
· не должно включать управляющие знаки (с кодами ASCII от 0 до 31);
· не должно включать прямые кавычки («) в именах таблиц, представлений и сохраненных процедур в проекте Microsoft Access.
Хотя пробелы внутри имен полей, элементов управления и объектов являются допустимыми, в большинстве примеров в документации Microsoft Access имена полей записываются без пробелов. Пробелы в именах могут, при некоторых обстоятельствах, вызывать конфликты в программах Microsoft Visual Basic для приложений.
Тип данных и свойства поля
После определения имени поля необходимо выбрать для него тип данных. Тип данных определяет значения, которые можно сохранять в этом поле.
Тип данных для конкретного поля выбирается в зависимости от того, какая информация там будет располагаться. Допустимы следующие значения свойства Тип данных.
| ТИП ДАННЫХ | ХРАНИМЫЕ ДАННЫЕ | ОГРАНИЧЕНИЯ |
| Текстовый | Алфавитно-цифровые данные (текст и числа) | Может храниться до 255 знаков. |
| Поле МЕМО | Алфавитно-цифровые данные (текст и числа) | Может храниться до 2 ГБ данных (предельный размер для всех баз данных Access) при программном заполнении полей. |
| Числовой | Числовые данные | В полях с типом данных «Числовой» используется параметр Список полей, управляющий размером значения, которое может содержать поле. |
| Дата/время | Значения даты и времени | Приложение Access хранит все значения даты и времени в виде 8-байтовых целых чисел с двойной точностью. |
| Денежный | Денежные данные | Данные хранятся в виде 8-байтовых чисел с точностью до четырех знаков после запятой. Этот тип данных используется для хранения финансовых данных и в тех случаях, когда значения не должны округляться. |
| Счетчик | Уникальные значения, создаваемые приложением Access при введении новой записи | Данные хранятся в виде 4-байтовых значений; обычно используются в первичных ключах. |
| Логический | Логические данные («истина» или «ложь») | Используется 1 для всех значений «Да» и 0 для всех значений «Нет». |
| Поле объекта OLE | Изображения, документы, диаграммы и другие объекты из приложений Office и других программ Windows. | Может храниться до 2 ГБ данных (предельный размер для всех баз данных Access). Поля с типом данных «Поле объекта OLE» создают растровые изображения исходных документов или других объектов, а затем отображают их в полях таблиц и элементах управления форм или отчетов в базе данных. |
| Гиперссылка | Веб-адреса | Может храниться до 1 гигабайта данных. |
| Вложение | Файлы любого поддерживаемого типа | В записи базы данных можно вкладывать изображения, файлы электронных таблиц, документы, диаграммы и другие файлы поддерживаемых типов точно так же, как в сообщения электронной почты. |
При выборе типа данных конкретного поля таблицы необходимо учесть следующее:
· какие именно значения должны храниться в поле (например, нельзя хранить текст в поле, имеющем числовой тип данных);
· сколько места необходимо для хранения значений в поле, т.е. определить размер этого поля;
· будут ли над значениями в поле производиться вычисления (например, нельзя суммировать значения в текстовых и MEMO полях);
· нужно ли создавать индекс по этому полю для ускорения операций поиска и сортировки (невозможно индексирование полей со следующими типами данных: поле MEMO, гиперссылка, поле объектаOLE);
· нужно ли производить сортировку значений в поле (например, числа в текстовых полях сортируются как строки цифр (1, 10, 100, 2, 20, 200 и т.д.), а не как числовые значения; для корректной сортировки значений дат в разных форматах необходимо использовать тип данных дата/время).
После выбора типа данных можно определить дополнительные свойства для поля таблицы. Задаваемые для поля дополнительные свойствапозволяют настроить способ хранения, обработки и отображения данных этого поля. Набор свойств меняется в зависимости от выбранного типа данных, причем некоторые из этих свойств устанавливаются по умолчанию.
| СВОЙСТВО ПОЛЯ | ТИП ДАННЫХ | ПРИМЕНЕНИЕ СВОЙСТВА |
| Размер поля | Текстовый Числовой Счетчик | Задание максимального размера для данных, хранящихся в поле с типом данных «Текстовый», «Числовой» или «Счетчик». |
| Формат поля | Текстовый Поле МЕМО Числовой Дата/время Денежный Счетчик Логический Гиперссылка | Настройка отображения поля по умолчанию на экране и при печати. |
| Число десятичных знаков | Числовой Денежный | Задание числа десятичных знаков, используемых при отображении чисел. |
| Новые значения | Счетчик | Указывает, какие значения (последовательные или случайные) присваиваются полю «Счетчик» при добавлении новой записи. |
| Маска ввода | Текстовый Числовой Дата/время Денежный | Символы редактирования, определяющие способы ввода данных. |
| Подпись | Все типы данных | Текст, отображаемый по умолчанию в качестве подписи в формах, отчетах и запросах. |
| Значение по умолчанию | Текстовый Поле МЕМО Числовой Дата/время Денежный Логический Гиперссылка | Значение, автоматически назначаемое полю при добавлении новой записи. |
| Условие на значение | Текстовый Поле МЕМО Числовой Дата/время Денежный Логический Гиперссылка | Выражение, значение которого должно быть истинно при добавлении или изменении значения поля. |
| Текст для проверки | Текстовый Поле МЕМО Числовой Дата/время Денежный Логический Гиперссылка | Текст, появляющийся при вводе значения, при котором нарушается условие, указанное в поле Условие на значение. |
| Обязательное поле | Все типы данных, кроме «Счетчик» | Указывает, должно ли это поле содержать значение в каждой записи. |
| Пустые строки | Текстовый Поле МЕМО Гиперссылка | Разрешает (установкой значения Да) ввод строки нулевой длины («») в текстовое поле и в поле МЕМО. |
| Индексация | Текстовый Поле МЕМО Числовой Дата/время Денежный Счетчик Логический Гиперссылка | Посредством создания и использования индекса ускоряет доступ к этому полю для чтения. |
| Сжатие Юникод | Текстовый Поле МЕМО Гиперссылка | Выполняется сжатие данных, содержащихся в этом поле, если в нем менее 4096 символов |
| Режим IME | Текстовый Поле МЕМО Дата/время Гиперссылка | Управление преобразованием символов в восточноазиатских версиях Windows. |
| Режим предложений IME | Текстовый Поле МЕМО Дата/время Гиперссылка | Управление преобразованием предложений в восточноазиатских версиях Windows. |
| Смарт-теги | Текстовый Поле МЕМО Числовой Дата/время Денежный Счетчик Гиперссылка | Позволяет выбрать смарт-теги, применяемые к полю. |
| Только добавление | Поле МЕМО Гиперссылка | Когда для свойства задано значение Да, ведется журнал значения поля. |
| Формат текста | Поле МЕМО | Для хранения данных в виде HTML-кода и использования RTF-форматирования следует выбрать значение Формат RTF. Чтобы хранить только текст без форматирования, следует выбрать значение Обычный текст. |
| Выравнивание текста | Все типы данных, кроме «Вложение» | Выравнивание текста по умолчанию в элементе управления. |
| Отображать элемент выбора даты | Дата/время | Указывает, должен ли в приложении Access отображаться элемент выбора даты (элемент управления «Календарь»), когда пользователь изменяет значение поля. |
Маска ввода
Свойством формат определяется формат представления данных при выводе на экран или печать, а свойством маска ввода – определяется образец для всех данных, которые вводятся в это поле, что позволяет контролировать правильность данных при вводе. Однако формат поля влияет только на отображение введенного значения и применяется только после сохранения введенных данных. Если же вводом данных в поле необходимо управлять, в дополнение к формату поля (или же вместо него) следует использовать маску ввода.
Маска ввода позволяет управлять вводом данных в поле. Например, ее можно использовать для преобразования вводимых символов к нужному регистру или же для автоматического добавления скобок и дефиса к номерам телефонов. Чаще всего маски ввода используются для текстовых полей, полей даты/времени, а также для числовых и денежных полей.
Маска ввода отображается в поле таблицы в виде символов шаблона(или знаков заполнителя) и текстовых символов. Символ шаблонаиспользуется для отображения пустых позиций в маске ввода, в которые помещаются вводимые пользователем символы.
Сообщение об ошибке при использовании специальных символов в базах данных Access
В этой статье перечислены специальные символы, которые следует избегать использования при работе с именами объектов базы данных или именами полей во всех версиях Access.
Office 365 ProPlus переименован в Майкрософт 365 корпоративные приложения. Для получения дополнительной информации об этом изменении прочитайте этот блог.
Исходный номер КБ: 826763
Эта статья применяется либо к файлу базы данных Microsoft Access (.mdb), либо к файлу базы данных Microsoft Access (.accdb), а также к файлу проекта Microsoft Access (.adp).
Симптомы
При использовании специальных символов в Access вы испытываете одну из следующих проблем.
Проблема 1
В имени настольного поля используется один из следующих специальных символов:
В этом случае вы получите следующее сообщение об ошибке:
Имя поля не допустимо.
Убедитесь, что имя не содержит периода (.), восклицательный знак (!), кронштейна ([]), ведущего пространства или непечатного символа, например возврата вагона. Если вы вклеили имя из другого приложения, попробуйте нажать кнопку ESC и введите имя еще раз.
Если вы используете эти специальные символы в имени таблицы, вы получите следующее сообщение об ошибке:
Имя объекта ‘TableName’, в которое вы ввели, не следует Microsoft Office правил именования объектов Access.
Проблема 2
Вы создаете выражение запроса. Выражение запроса включает поля, которые содержат специальные символы. В зависимости от конкретных специальных символов вы получаете одно из следующих сообщений об ошибке:
Если имя поля содержит символ пространства, знак вопроса (?) или знак на знаке (@), вы получите следующее сообщение об ошибке:
Введенное выражение содержит недопустимый синтаксис.
Возможно, вы ввели операнд без оператора
Если имя поля содержит кавычка() или апостроф(‘), вы получите следующее сообщение об ошибке:
Введенное выражение имеет недействительные строки.
Строка может быть длиной до 2048 символов, включая открытие и закрытие кавычков.
Если имя поля содержит знак номера (#), вы получите следующее сообщение об ошибке:
Введенное выражение имеет недействительное значение даты.
Если имя поля содержит знак процента (%), tilde (
), полуколон (;) или кронштейн ([]), вы получите следующее сообщение об ошибке:
Введенное выражение содержит недопустимый синтаксис.
Вы опущены операнд или оператор, вы ввели недействительный символ или запятую или ввели текст, не окружав его кавычками.
Если имя поля содержит скобку <> (), вы получите следующее сообщение об ошибке:
Malformed GUID в выражении запроса ‘ObjectName‘
Если имя поля содержит скобку ([]) или скобку (()), вы получите следующее сообщение об ошибке:
В выражении, в который вы ввели, отсутствует закрываемая скобка, скобка (]) или вертикальная планка (|).
Проблема 3
У вас есть запрос, содержащий выражения запросов. Выражения запросов включают поля, содержащие специальные символы. При запуске запроса вам будет назначено ввести значение параметра. Как правило, эта проблема возникает при использовании следующих специальных символов:
Дополнительные сведения
Microsoft Access не ограничивает использование специальных символов, таких как знак номеров (#), период (.) или кавычка () в именах объектов базы данных или в именах полей баз данных. Однако при использовании специальных символов могут возникнуть непредвиденные ошибки. Поэтому Корпорация Майкрософт рекомендует не использовать специальные символы в именах объектов базы данных в базе данных Access или в проекте базы данных. В этой статье обсуждаются специальные символы, которых необходимо избегать из-за известных проблем с этими специальными символами.
При работе с Access или с каким-либо другим приложением, например Visual Basic Microsoft или приложением ASP (ASP), следует избегать следующих специальных символов:
Мир цифровой информации
Если вам кажется, что нет ничего проще, чем придумать имя для файла или папки, то скорее всего вы ошибаетесь. Существуют правила из-за которых нельзя назвать файл любым именем как обычный физический предмет. Для начала проясним, что такое имя файла, и как оно используется.
Понятия «путь» и «имя файла»
Очень часто в компьютерной литературе используются термины «путь» и «имя файла» под разными значениями. Обычно под словом «путь» понимают адрес или расположение файла, т. е. диск, папка и подпапки в которых расположен файл. Однако Microsoft и другие считают, что в путь к файлу входит не только его расположение но и само имя файла. А некоторые подразумевают под словом «путь» только имена файла и папок, в которых он расположен, без указания диска. Некоторые пользователи полагают, что «имя файла» не включает расширение. В данной статье расширение всегда является частью имени файла. На примере ниже синим цветом выделен путь к файлу, а красным имя файла.
X:\папка\подпапка\ файл.расширение
Зарезервированные символы и имена
Ограничения на длины имен файлов и путей
Существуют ограничения на длину имени файла и на длину пути. Абсолютное ограничение длины имени файла вместе включая путь к нему равно 260 символам. Этот предел называют термином MAX_PATH. На самом же деле на практике пределы для имен еще меньше из-за ряда других ограничений. Например, каждая строка на конце должна содержать так называемый нулевой символ, который обозначает конец строки. Несмотря на то, что маркер конца строки не отображается, он учитывается как отдельный символ при подсчете длины, а значит остается 259 символов доступных для имени файла и пути к нему. Первые три символа в пути используются для обозначения диска (например, C:\). Это уменьшает предел для имен папок, подпапок и файла до 256 символов.
На имя объекта (папки или файла) наложено ограничение длины 255 символов. Этот предел действителен только, если объект не расположен внутри папки. Так как при расположении объекта внутри папки, сумма длин всех папок в которых он расположен, разделителей и имени объекта ограничена 256 символами, то предел длины самого имени объекта меньше 255 символов.
Какие символы запрещены в именах каталогов Windows и Linux?
мне нужно полное руководство, однако, и тот, который учитывает двухбайтовые символы. Связь с внешними ресурсами меня устраивает.
мне нужно сначала создать каталог в файловой системе, используя имя что может содержат запрещенные символы, поэтому я планирую заменить эти символы подчеркивает. Затем мне нужно записать этот каталог и его содержимое в zip-файл (используя Java), поэтому любые дополнительные советы относительно имен zip-каталогов буду признателен.
12 ответов
давайте держать его простым и ответить на вопрос, в первую очередь.
запрещено печатаемые символы ASCII являются:
непечатаемые символы
если ваши данные поступают из источника, который разрешил бы непечатаемые символы, то есть больше, чтобы проверить для.
Примечание: хотя в файловых системах Linux/Unix разрешено создавать файлы с управляющими символами в имени файла,это может быть кошмаром для пользователей, чтобы иметь дело с такими файлами.
зарезервированные имена файлов
следующие имена зарезервировано:
другие правила
имена файлов не могут заканчиваться пробелом или точкой.
другие люди покрыли правила Windows.
обратите внимание, что MacOS X имеет файловую систему без учета регистра.
1 это был Керниган и Пайк в практика программирования кто сказал это в главе 6, тестирование, §6.5 стресс Тесты:
когда Стив Борн писал свою оболочку Unix (которая стала известна как оболочка Борна), он сделал каталог из 254 файлов с односимвольными именами, по одному для каждого значения байта, кроме ‘ ‘ и Слэш, два символа, которые не могут отображаться в именах файлов Unix. Он использовал эту директорию для всевозможных тестов на соответствие шаблону и токенизацию. (Конечно, тестовый каталог был создан программой.) В течение многих лет после этого этот каталог был проклятием файл-дерево-Ходячие программы; он тестировал их до разрушения.
вместо создания черного списка символов вы можете использовать белый. Учитывая все обстоятельства, диапазон символов, которые имеют смысл в контексте имени файла или каталога, довольно короткий, и если у вас нет определенных требований к именованию, ваши пользователи не будут удерживать его против вашего приложения, если они не могут использовать всю таблицу ASCII.
это не решает проблему зарезервированных имен в целевой файловой системе, но с белым списком проще снижение рисков у источника.
в этом духе, это набор символов, которые можно считать безопасным:
и любые дополнительные безопасные символы, которые вы хотите разрешить. Помимо этого, вы просто должны применять некоторые дополнительные правила, касающиеся пробелов и точек. Этого обычно достаточно:
это уже позволяет довольно сложные и бессмысленные имена. Например, эти имена были бы возможны с этими правилами и были бы допустимыми именами файлов в Windows / Linux:
по сути, даже с таким небольшим количеством белых символов вы все равно должны решить, что на самом деле имеет смысл, и проверить/настроить имя соответственно. В одном из моих приложений я использовал те же правила, что и выше, но удалил все дубликаты точек и пробелов.
Ну, если только для исследовательских целей, то вам лучше всего посмотреть эта запись Википедии о именах файлов.
Если вы хотите написать портативную функцию для проверки ввода пользователя и создания имен файлов на основе этого, короткий ответ не. Взгляните на портативный модуль, такой как Perl File:: Spec чтобы увидеть все прыжки, необходимые для выполнения такой «простой» задачи.
простой способ заставить Windows сообщить вам ответ-попытаться переименовать файл через Проводник и ввести / для нового имени. Windows появится окно сообщения, сообщающее вам список незаконных символов.
для Windows вы можете проверить его с помощью PowerShell
для отображения UTF-8 кодов вы можете конвертировать
пример кода VBA:(будут добавлены позже)
например, хотя это может быть законным именем файла 1>&2 или 2>&1 в Unix такие имена файлов могут быть неправильно истолкованы при использовании в командной строке.
при создании ярлыков интернета в Windows, чтобы создать имя файла, он пропускает незаконные символы, за исключением косой черты, которая преобразуется в минус.
У меня была такая же потребность, и я искал рекомендации или стандартные ссылки и наткнулся на эту тему. Мой текущий черный список символов, которых следует избегать в именах файлов и каталогов:
Какие символы допускаются в адресе электронной почты?
Я не спрашиваю о полной проверке электронной почты.
Я просто хочу знать, какие символы разрешены в user-name и server части адреса электронной почты. Это может быть упрощено, возможно, адреса электронной почты могут принимать другие формы, но мне все равно. Я спрашиваю только об этой простой форме: user-name@server (например wild.wezyr@best-server-ever.com) и разрешенные символы в обеих частях.
18 ответов
RFC 822 также охватывает адреса электронной почты, но имеет дело в основном с его структурой:
и, как обычно, Википедия имеет приличный статья об адресах электронной почты:
локальная часть адреса электронной почты может использовать любой из этих символов ASCII:
Берегись! В этом потоке есть куча знаний (вещи, которые раньше были правдой, а теперь нет).
чтобы избежать ложноположительных отклонений фактических адресов электронной почты в текущем и будущем мире и из любой точки мира, вам нужно знать, по крайней мере, концепцию высокого уровня RFC 3490, » интернационализация доменных имен в приложениях (IDNA)». Я знаю, что люди в нас и часто не в курсе этого, но это уже в широко распространенный и быстро увеличение использования по всему миру (в основном на английском преобладают детали).
Я сам мало знал об этом развитии, пока не вернулся в Японию и не начал видеть адреса электронной почты, такие как hei@やる.ca и Amazon URLs, как это:
Я знаю, что вам не нужны ссылки на спецификации, но если вы полагаетесь исключительно на устаревшие знания хакеров Интернет-форумы, ваш email validator в конечном итоге отклоняет адреса электронной почты, которые не-Enlish пользователи все чаще ожидают работать. Для этих пользователей такая проверка будет такой же раздражающей, как обычная мертвая форма мозга, которую мы все ненавидим, та, которая не может обрабатывать + или трехчастное доменное имя или что-то еще.
после этого вы можете следовать (большинству) советов выше.
формате e-mail адрес: local-part@domain-part (макс. 64@255 символов, не более 256 в общей сложности).
на local-part и domain-part может иметь другой набор разрешенных символов, но это еще не все, так как есть больше правил.
в общем, локальная часть может иметь следующие символы ASCII:
эти адреса электронной почты действительны:
и эти примеры некорректны:
полное регулярное выражение для адресов RFC2822 было всего лишь 3.7 k.
официальное определения адресов электронной почты находятся в:
локальная часть адреса электронной почты может использовать любой из следующих символов ASCII:
кроме того, строки с кавычками (т. е. «John Doe» @example.com) разрешены, таким образом, разрешены символы, которые в противном случае были бы запрещены, однако они не появляются в обычной практике. RFC 5321 также предупреждает, что»хост, который ожидает получать почту, должен избегать определения почтовых ящиков, где локальная часть требует (или использует) форму с кавычками».
Google делает интересную вещь со своими gmail.com адреса. gmail.com адреса разрешают только буквы (a-z), цифры и точки(которые игнорируются).
например, pikachu@gmail.com это то же самое, что pi.kachu@gmail.com, и оба адреса электронной почты будут отправлены в один и тот же почтовый ящик. PIKACHU@gmail.com также доставляется в тот же почтовый ящик.
поэтому, чтобы ответить на вопрос, иногда это зависит от исполнителя от того, сколько стандартов RFC они хотят следовать. Гугла gmail.com стиль адреса совместим со стандартами. Они делают это таким образом, чтобы избежать путаницы, когда разные люди будут принимать аналогичные адреса электронной почты, например
ссылка Википедии является хорошей ссылкой на то, что адреса электронной почты обычно позволяют. http://en.wikipedia.org/wiki/Email_address
короткий ответ заключается в том, что есть 2 ответа. Существует один стандарт того, что вы должны делать. т. е. поведение, которое является мудрым и будет держать вас от неприятностей. Существует еще один (гораздо более широкий) стандарт поведения, который вы должны принять, не создавая проблем. Эта двойственность работает для отправки и приема электронной почты, но имеет широкое применение в жизни.
для хорошего руководства по адресам, которые вы создаете; см.: http://www.remote.org/jochen/mail/info/chars.html
чтобы фильтровать действительные письма, просто передайте что-нибудь достаточно понятное, чтобы увидеть следующий шаг. Или начните читать кучу RFCs, осторожно, здесь будут драконы.
принятый ответ относится к статье Википедии при обсуждении действительной локальной части адреса электронной почты, но Википедия не является авторитетом в этом.
IETF RFC 3696 авторитет по этому вопросу, и следует обращаться в раздел 3. Ограничения на адреса электронной почты на странице 5:
современные адреса электронной почты состоят из «локальной части» отделился от «доменная часть» (полностью квалифицированная доменное имя) по знаку at («@»). Синтаксис доменной части соответствует синтаксису предыдущей части раздел. Проблемы, выявленные в этом разделе относительно фильтрации и списки имен применяются к доменным именам, используемым в контексте электронной почты как что ж. Доменное имя также может быть заменено IP-адресом в квадратные скобки, но эта форма сильно не рекомендуется, за исключением тестирование и устранение неполадок.
локальная часть может отображаться с использованием соглашений о цитировании описанный под. Цитируемые формы редко используются на практике, но необходимы для некоторых законных целей. Следовательно, они не должны быть отвергнуты в процедуры фильтрации, но, вместо этого, должны быть переданы в систему электронной почты для оценки хостом назначения.
точное правило заключается в том, что любой символ ASCII, включая элемент управления символы, могут отображаться в кавычках или в строке с кавычками. Когда цитирование необходимо, символ обратной косой черты используется для выражения следующих характер. Например
является действительным адресом электронной почты. Также могут появляться пробелы, как в
символ обратной косой черты также может использоваться для цитирования себя, например,
в дополнение к цитированию с использованием символа обратной косой черты, обычный символы двойной кавычки могут использоваться для окружения строк. Например
являются альтернативными формами первых двух примеров выше. Эти процитировал формы редко рекомендуются, и являются необычными на практике, но, как рассмотренные выше, должны поддерживаться приложениями, которые обрабатываются адрес электронной почты. В частности, цитируемые формы часто появляются в контекст адресов, связанных с переходами из других систем и контексты; эти переходные требования все еще возникают и, поскольку система, принимающая предоставленный пользователем адрес электронной почты, не может «знать», связан ли этот адрес с устаревшей системой, адрес формы должны быть приняты и переданы в среду электронной почты.
без кавычек, local-parts может состоять из любой комбинации
алфавитные символы, цифры или любой из специальных символов
точка («.») может также появиться, но не может использоваться для начала или конца локальная часть, а также не может появляться два или более последовательных периода. Указано иначе, любой графический (печатный) символ ASCII, кроме знак at ( » @ » ), обратная косая черта, двойной кавычка, запятая, или квадратные скобки может появиться без цитирования. Если какой-либо из этого списка исключен символы должны появиться, они должны быть процитированы. Такие формы, как
действительны и видны довольно регулярно, но любой из символов перечисленные выше разрешены.
как и другие, я отправляю регулярное выражение, которое работает как для PHP, так и для JavaScript для проверки адресов электронной почты: