Как прощение исходные данные формы должно быть?
Я перешел к своему веб-сайту банка на днях и ввел свой номер аккаунта с конечным пробелом. Сообщение об ошибке появилось, который сказал, "Номер аккаунта должен состоять из числовых значений только". Я думал мне, "Серьезно?! Вы, возможно, не просто разделили пространство для меня?". Если я был кем-либо меньше компьютерного фаната, я, возможно, даже думал, "Что? Там существуют только числа!" (не бывший способный видеть пространство).
Калькулятор, который идет с Ubuntu, с другой стороны, весело, принимает пробелы и запятые, но странно не любит запаздывать точки (без любых следующих цифр).
Так, это вызывает вопрос. Точно, как прощение веб-формы должно быть? Я не думаю, обрезая пробел, слишком много для выяснения, но что относительно других целочисленных полей?
- Они должны позволить +/-знаки?
- Сколько пробелов должно быть позволено между знаком и числом?
- Что относительно запятых для тысяч разделителей?
- Что относительно в других частях мира, где использование отмечает точкой вместо этого?
- Что, если они являются промежуточными каждые 4 цифры вместо каждых 3?
- Что относительно шестнадцатеричных и восьмеричных представлений?
- Экспоненциальное представление?
- Что, если я случайно нажал кнопку кавычки, когда я пытаюсь совершить нападки, входит, который должен быть разделен также?
Для меня было бы очень легко разделить все символы нецифры, и это было бы чрезвычайно прощающим, но что, если бы пользователь сделал фактическую ошибку, которая влияет на вход и должна была быть поймана, но теперь я только что разделил его?
Что относительно вещей как номера телефона (которые имеют огромное множество форматов), индексы, почтовые индексы, номера кредитных карт, имена пользователей, электронные письма, URL (я должен принять http? Что относительно .com, в то время как я в нем?)?
Где Вы разграничиваете?
8 ответов
Для чего-то столь же важного, как банковское дело, я не возражаю, чтобы он жаловался на мой вклад, особенно если другой вариант ошибочно переводит кучу денег на чужой счет вместо счета моей жены (потому что отсутствующей или неправильной цифры например).
Классическим примером является один из моих банков, который не принимает денежные значения, если в конце у них нет «.99» (где 9, конечно, может быть любой цифрой). Подавляющее большинство вещей, которые я делаю, рассчитаны на точные суммы в долларах, и это немного раздражает, когда нужно всегда вводить 500,00 вместо 500.
Но я буду счастлив от этого в первый раз, когда я избегу случайно заплатить кому-то 5072 доллара вместо 50,72 доллара только потому, что я забыл десятичную точку. На самом деле, это довольно маловероятно, так как он также требует подтверждения, а я довольно анален в управлении своими деньгами: -)
Сказав это, я стараюсь следовать общему правилу: «будь либерален в том, что ты принимаешь, будь строг в что вы производите ".
Это позволяет другому программному обеспечению, использующему мой вывод, рассчитывать на ограниченный диапазон возможностей (облегчая себе жизнь). Но это делает мое программное обеспечение более полезным, если оно может справляться с простыми ошибками.
Мне кажется, вы немного перегибаете палку. Если в поле есть что-то, чего там не должно быть, удалите это. В противном случае попытайтесь принудительно ввести данные в тот формат, который вы хотите, и если они не подходят, отклоните их.
Это полностью зависит от того, как будут использоваться данные.
Если вводимые данные представляют собой денежную сумму, например, для транзакции, то вводимая переменная должна быть нормализована в соответствии с набором стандартов.
Если это просто номер телефона, то вряд ли сохраненные данные будут использоваться функционально, поэтому можно быть более снисходительным.
Нет ничего плохого в принуждении к правильному формату, чтобы отображение выглядело красивее, но вы должны сбалансировать раздражение пользователей и микровыгоды.
Как только вы начнете собирать данные, вы сможете просканировать их и посмотреть, какие закономерности возникают, и вы сможете автоматически удалять введенный формат.
Где вы проводите черту?
Когда последствия принятия "недействительных" данных перевешивают раздражение от непринятия.
Должны ли они разрешать знаки +/-?
Если отрицательные значения действительны, то, конечно, должны.
Если нет, то не надо просто молча вычеркивать знаки минуса, поскольку это полностью меняет смысл данных. С зачеркиванием плюсов проблем меньше.
Что если [разделители тысяч стоят] между каждыми 4 цифрами вместо каждых 3?
В странах, где используется трехзначная группировка, можно считать, что "1,0000" - это опечатка. Но опечатка ли это для "10 000" или для "1 000"? Я бы не осмелился гадать, так как неправильное предположение может стоить пользователю $9,000.
А как насчет шестнадцатеричного и восьмеричного
Если только вы не используете функцию поиска на сайте unicode.org, я не могу представить, зачем кому-то использовать шестнадцатеричную систему в веб-форме.
А "01234" почти наверняка означает 1234, а не 668.
Что насчет таких вещей, как... номера кредитных карт
Пожалуйста, разрешите пробелы или дефисы в номерах кредитных карт. Это очень раздражает, когда мне приходится набирать 16-значный номер без пробелов.
Я бы сказал "Принимайте все, что угодно, но обрабатывайте только достоверные данные".
Ожидайте, что ваши пользователи будут вести себя как компьютерные профаны. Проверяйте входные данные с помощью регулярных выражений и других валидаторов.
Найдите стандартные регулярные выражения для урлов, электронных писем и прочего.
Добавьте регулярное выражение вроде этого "/(?:([a-zA-Z0-9][\s,]+))([a-zA-Z0-9]+)$/" для значений, разделенных запятыми или пробелами. При небольшой доработке этот exp будет работать для любого количества значений, разделенных запятыми.
Меня как пользователя раздражает номера кредитных карт, обычно они отображаются в виде групп из 4 цифр с пробелами, разделяющими их, но нечетная веб-форма принимает только одну строку цифр без пробелов и нет никаких указаний на то, что это именно тот формат, который он ищет. Подобно телефонным номерам, люди часто используют пробелы для большей ясности, веб-формы иногда принимают пробелы, а иногда нет.
Вы проводите черту в точке, где компьютер догадывается, каким должен быть правильный ввод.
Например, окно ввода лицензионного ключа, которое я однажды написал, принимает пробелы и тире и верхний и нижний регистр, хотя внутри ключи были без пробелов и тире и все в верхнем регистре. Я мог это сделать, поскольку знал, что ни один из ключей на самом деле не содержит пробелов или тире.
Ваш пример с URL-адресами - еще один хороший пример. Я заметил, что современные браузеры (я использую Chrome), когда в адресной строке набирается что-то вроде 'flowers', знают, что должны искать это, поскольку это не действительный URL. Если вместо этого я набираю 'st', он автоматически исправляет (или автоматически предлагает) 'stackoverflow.com', поскольку это закладка.
Хорошо написанная система ввода будет жаловаться, если в противном случае ей пришлось бы гадать, каким должен быть правильный ввод.
Numeric input:
Вычеркивание нецифр кажется мне разумным, но проблема заключается в противоречивых десятичных обозначениях. В некоторых регионах для обозначения десятичного разделителя используется , (запятая), а в других - . (точка). Если входные данные, скорее всего, не будут представлены в других базисах, я бы предпочел использовать только базис 10. Если разумно предположить ввод не в базе 10 (например, в базе 16 для ввода цвета), я бы использовал стандартные соглашения для обозначения баз: ведущий 0 означает базу 8, ведущий 0x означает базу 16.
String input:
Здесь все гораздо сложнее. В основном это зависит от того, что на самом деле должен представлять вводимый текст. Имя пользователя должно исключать символы, которые могут вызвать проблемы, но значение слова "вызвать проблемы" будет зависеть от использования приложения и самой системы. URL-адреса имеют конкретное определение того, что к ним относится, но это определение довольно широкое. К счастью, многие языки поставляются с инструментами для распознавания URL, без необходимости кодировать свой собственный разбор (делает ли язык это идеально или нет - другой вопрос).
В конце концов, это действительно зависит от каждого конкретного случая. Однако мне нравится общее правило paxadiablo: Принимайте столько, сколько можете, выводите только то, что должны.