Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 212
Какая-то очень плохая база данных, в которой Null == "Null"
Навряд ли этот глюк происходит на уровне SQL — все строковые литералы должны быть в кавычках, а NULL соотв должен быть без кавычек.
Скорее всего где-то уже в коде происходит текстовое сравнение c "NULL", хотя тоже непонятно — ведь NULL пишется весь большими буквами или весь маленькими.
Скорее всего просто байка для программистов.
Скорее всего где-то уже в коде происходит текстовое сравнение c "NULL", хотя тоже непонятно — ведь NULL пишется весь большими буквами или весь маленькими.
Скорее всего просто байка для программистов.
InvariantCultureIgnoreCase?
Возможно, поля формы на сервер передаются как-то так: example.com?name=null — и парсер на той стороне сходит с ума понимает это не как строку "null", а как javascript-значение null, т.е. поле не заполнено.
Даже если фамилия Нуль и байка, такие случаи, увы, случаются: я довольно давно зарегистрировал домен в зоне .name — и многие сайты, на которых я хотел потратить деньги, отказывались принимать почтовый адрес в этом домене.
Даже если фамилия Нуль и байка, такие случаи, увы, случаются: я довольно давно зарегистрировал домен в зоне .name — и многие сайты, на которых я хотел потратить деньги, отказывались принимать почтовый адрес в этом домене.
С большой долей вероятности подобные системы пишут криворукие индусы, которые кроме как приведением к строковым значениям сравнивать не умеют. Я долгое время считал шуткой вариант "a.toString()=="false" пока не увидел аналогичную конструкцию в творении индийского гения.
Читая недавние новости про npm, наткнулся на пакет isarray, который проверяет, является ли массивом объект на входе:
Правда, как выяснилось, instanceof даст сбой, если объект был создан в другой глобальной области видимости — так что тут иных вариантов, кроме приведения к строке, не предвидится. Вот такие дела. Получается, не только индусы этим страдают :)
module.exports = Array.isArray || function (arr) {
return toString.call(arr) == '[object Array]';
};Правда, как выяснилось, instanceof даст сбой, если объект был создан в другой глобальной области видимости — так что тут иных вариантов, кроме приведения к строке, не предвидится. Вот такие дела. Получается, не только индусы этим страдают :)
ждем webassembly?
Это кривой хак а не решение проблемы использования объектов из другой области видимости. Сталкивался давно с такой проблемой в IE при передаче данных из одного окна в другое. После закрытия окна, в котором данные создавались все переданные объекты, созданные в закрытом окне теряли информацию о прототипах. Решалось глубоким копированием объектов в момент передачи данных, далее как обычно — instanceof и проч работают как надо.
Джаваскрипт же. null == «null».
School: Hi, this is your son's school. We're having some computer trouble.
Mom: Oh, dear — Did he break something?
School: In a way. Did you really name your son Robert'); DROP TABLE Students;--?
Mom: Oh. Yes. Little Bobby Tables we call him.
School: Well, we've lost this year's student records. I hope you're happy.
Mom: And I hope you've learned to sanitize your database inputs
Mom: Oh, dear — Did he break something?
School: In a way. Did you really name your son Robert'); DROP TABLE Students;--?
Mom: Oh. Yes. Little Bobby Tables we call him.
School: Well, we've lost this year's student records. I hope you're happy.
Mom: And I hope you've learned to sanitize your database inputs
School: Hi, this is your son's school. We're having some computer trouble.
Mom: Oh, dear — Did he break something?
School: In a way. Did you really name your son Robert'); DROP TABLE Students;--?
Mom: Oh. Yes. Little Bobby Tables we call him.
School: Well, we've lost this year's student records. I hope you're happy.
Mom: And I hope you've learned to sanitize your database inputs.
Mom: Oh, dear — Did he break something?
School: In a way. Did you really name your son Robert'); DROP TABLE Students;--?
Mom: Oh. Yes. Little Bobby Tables we call him.
School: Well, we've lost this year's student records. I hope you're happy.
Mom: And I hope you've learned to sanitize your database inputs.
Не, просто это PHP, а индус сравнил используя == вместо ===
Интересна причина этого безумия. Я пока придумать не могу.
Предложу 2 варианта: 1) слишком длинная («20 символов хватит всем»); 2) тире («В фамилии могут быть только русские буквы»).
прошу прощения, но во втором варианте это все все-таки предпочтительно называть дефисом; тире в фамилии — это следующий уровень сложности (дефис хотя бы есть в спецсимволах)
Как-то на сайте госуслуг не принимался email длиной более 20 символов. Помогло исправление атрибута maxlength в соответствующем html теге.
Плохо объяснимые ограничения часто встречаются… Казалось бы, какая gmail'у разница, но почта, начинающаяся с цифры — недопустима. А тот же mail.ru позволяет создать ящик, начинающийся с цифры и даже состоящий из одних только цифр — живу на таком уже много лет. Изредка возникают проблемы некорректного e-mail при регистрации на сторонних ресурсах.
Интересно, если вообще есть официальные ограничения по символам в e-mail адресе, кто их нарушает, мэйл или гугл?
Интересно, если вообще есть официальные ограничения по символам в e-mail адресе, кто их нарушает, мэйл или гугл?
>> Казалось бы, какая gmail'у разница, но почта, начинающаяся с цифры — недопустима.
Да щас. У меня почта на gmail полностью из цифр состоит.
Да щас. У меня почта на gmail полностью из цифр состоит.
А сейчас проверю еще разок… Все равно не получается…
Цитата: "Sorry, usernames of 8 or more characters must include at least one alphabetical character (a-z)"
Возможно, кстати, что ограничение смягчилось за прошедшее время — помню, без подробностей, что мне никак не удавалось создать адрес, начинающийся с цифр — по логике, я был вполне согласен дописать буквы в конец, но их все равно пришлось дописывать в начало.
Цитата: "Sorry, usernames of 8 or more characters must include at least one alphabetical character (a-z)"
Возможно, кстати, что ограничение смягчилось за прошедшее время — помню, без подробностей, что мне никак не удавалось создать адрес, начинающийся с цифр — по логике, я был вполне согласен дописать буквы в конец, но их все равно пришлось дописывать в начало.
> кто их нарушает, мэйл или гугл?
Ни тот, ни другой. Читайте тут:
https://habrahabr.ru/post/274985/
> у 2.3.10 RFC 2821, который определяет SMTP, часть перед знаком "@" называется локальной частью (часть после знака — это домен получателя) и предназначена для интерпретации ***исключительно сервером получателя***.
> «Следовательно — и благодаря длинной череде проблем, вызванных промежуточными хостами, пытавшимися оптимизировать передачу путём изменения их [адресов — перев.], локальная часть ДОЛЖНА быть интерпретирована (и ей должен быть назначен семантический смысл) ***исключительно сервером, указанным в доменной части адреса***.»
Ни тот, ни другой. Читайте тут:
https://habrahabr.ru/post/274985/
> у 2.3.10 RFC 2821, который определяет SMTP, часть перед знаком "@" называется локальной частью (часть после знака — это домен получателя) и предназначена для интерпретации ***исключительно сервером получателя***.
> «Следовательно — и благодаря длинной череде проблем, вызванных промежуточными хостами, пытавшимися оптимизировать передачу путём изменения их [адресов — перев.], локальная часть ДОЛЖНА быть интерпретирована (и ей должен быть назначен семантический смысл) ***исключительно сервером, указанным в доменной части адреса***.»
Плохо объяснимые ограничения часто встречаются…
Угу. Например, ограничения на максимальную длину пароля. Вот уж никогда не понимал...
Но не 12-20 же символами же...
// и это… плохая практика ограничивать длину вместо того, чтобы не заниматься всякой фигнёй типа обработки того, что обрабатывать не надо (оно же там падало не при аутентификации, а после того, как к-во символов в поле становилось довольно большим. И тут вопрос в том, почему систему вообще волновало к-во символов в поле ДО отправки пароля валидатору).
// и это… плохая практика ограничивать длину вместо того, чтобы не заниматься всякой фигнёй типа обработки того, что обрабатывать не надо (оно же там падало не при аутентификации, а после того, как к-во символов в поле становилось довольно большим. И тут вопрос в том, почему систему вообще волновало к-во символов в поле ДО отправки пароля валидатору).
Ха! Интересно, во многих ли веб-приложениях проверка введенных данных реализована только или частично на клиенте.
Просто привычка такова, что во всем, что довелось мне разрабатывать — ту проверку, что происходит на клиенте, я рассматривал не более чем заглушку от лишних запросов на сервер, перепроверяя все присланные на сервер данные.
Просто привычка такова, что во всем, что довелось мне разрабатывать — ту проверку, что происходит на клиенте, я рассматривал не более чем заглушку от лишних запросов на сервер, перепроверяя все присланные на сервер данные.
Пару лет назад в системе Webmoney у белорусов были проблемы с вводом номера телефона… Поле было ограничено 11 цифрами (4 цифры код и 7 цифр номера). А в Беларуси код из 5 цифр. Приходилось писать 11 последних цифр номера, потом выделять автоматически подставляемый в поле знак плюс, и нажимать клавишу первой цифры номера. И вот так оно работало…
Азербайджанские отчества типа ...-оглы и ...-кызы тоже наверняка отрабатываются не очень.
А у меня по паспорту вообще отчества нет.
А недавно было судебное решение — в России человеку разрешили жить без фамилии. Многие ли программы готовы к такому повороту?
Государственные органы, транспорт и сбербанк вроде бы готовы. С частниками вроде систем переводов, сотовых операторов и прочих, проблемы есть. Не смотря на то, что без отчества больше двадцати лет как можно обходиться. Думаю, те же проблемы сохранятся и после признания фамилии необязательной.
истец получил военный билет в 1976 году, в 2003 получил общегражданский паспорт, женился в 2005, а в 2014 получил заграничный паспорт, но во всех документах его фамилии указано не было
Мне в этой истории больше всего удивительно вот это.
А что тут удивительного? Руками такой паспорт выдать можно (в свидетельстве о рождении фамилии нет, а выдаваемый паспорт должен соответствовать, если выдаётся не по замене установочных данных). В компьютерных системах это тоже стандартный случай (технический признак отсутствия данных просто ставится).
На них были отдельные правила в системах, где об этом подумали (типа проверки соответствия отчества полу). Бывают ограничения, тянущиеся из лохматых годов (типа по 30 символов на каждое поле, формат введён приказом и менять только через министерство) в связанных системах и это доставляло множество дополнительных приятных минут. Отсутствия же фамилий или отчеств (или даты рождения) — вполне стандартный случай (опять же — если об этом подумали).
Да… Ноооо… Как же тестирование или продакшен все стерпит?
Пантелеймон Христарождественский же.
На самом деле просто надо предусмотреть такую длину поля, чтобы точно хватило, а потом умножить на полтора.
На самом деле просто надо предусмотреть такую длину поля, чтобы точно хватило, а потом умножить на полтора.
Размер СМС — да, согласен. Хотя я сходу не могу придумать, где бы мне нужно было писать или читать свои полные ФИО в СМС.
Остальное — забота дизайнера. Это как с визитками: начинающий дизайнер бодро вбивает рыбу в виде Ивана Ивановича Пупкина, а опытный уже знает про Константинопольского. Если речь о железном устройстве, так и тут можно придумать много чего.
Сколько я видел поломанных длинными фамилиями дизайнов — не перечесть.
Остальное — забота дизайнера. Это как с визитками: начинающий дизайнер бодро вбивает рыбу в виде Ивана Ивановича Пупкина, а опытный уже знает про Константинопольского. Если речь о железном устройстве, так и тут можно придумать много чего.
Сколько я видел поломанных длинными фамилиями дизайнов — не перечесть.
Некоторые банки почему-то еще меньшее ограничение принимают. Недавно на работе всем офисом получаем карточки, у всех эмбоссировано имя фамилия, у меня же mr A фамилия. Вместе с пробелом имя+фамилия всего 19 символов латиницей.
И тут появляется / срывает рубашку / человек-банковский-сотрудник / вспоминает что уже год как внештатный сотрудник, и застегивает рубашку /
В основном, весь софт, что видит "девочка-кассир" писался не рядовыми банковскими сотрудниками, а всевозможными "тру-вендорами".
Да процесс неторопливый, но через некоторое время (если конечно с вендором к тому времени не разругались) все это исправляется, просто случай для 2016 года, ну очень удивительный.
Вообще фильтровать ФИО — гиблое дело; единственное, что стоит сделать это заэкранировать входные данные и выпилить CHR(13) и CHR(10)
В основном, весь софт, что видит "девочка-кассир" писался не рядовыми банковскими сотрудниками, а всевозможными "тру-вендорами".
Да процесс неторопливый, но через некоторое время (если конечно с вендором к тому времени не разругались) все это исправляется, просто случай для 2016 года, ну очень удивительный.
Вообще фильтровать ФИО — гиблое дело; единственное, что стоит сделать это заэкранировать входные данные и выпилить CHR(13) и CHR(10)
Есть подозрение, что все исправление заключалась в сообщении сотрудникам фронт-офиса, что теперь надо вместо дефиса ставить пробел. А проблему с пробелом они уже побороли, когда столкнулись с Кызы/Оглы.
Вообще скорость исправления зависит от степени "залета". Пример из жизни: в некотором банке, где я работал в отделе КХД, ночью останавилась сборка из, за того одного депозита не смог к нам попасть, так как у нашего поля INTEREST_RATE была размерность (вроде) DECIMAL(6,4), то мы получили ошибку вида Parameter value '10000000.00' is out of range.
После непродолжительного исследования, оказалось что сотрудник фронт-офиса по ошибке внес в величину депозита процентную ставку, а в процентную ставку внес величину депозита. Далее распечатал договор и клиент не смотря подписал его. А уже ночью процентная ставка не смогла попасть в ХД.
Конечно после этого у нескольких отделов началось то, что можно охарактеризовать как "Усе пропало, шеф!". С клиентом связались, пригласили переподписать договор ну и оперативно вендером были внесены изменения. Happy End?
Вообще скорость исправления зависит от степени "залета". Пример из жизни: в некотором банке, где я работал в отделе КХД, ночью останавилась сборка из, за того одного депозита не смог к нам попасть, так как у нашего поля INTEREST_RATE была размерность (вроде) DECIMAL(6,4), то мы получили ошибку вида Parameter value '10000000.00' is out of range.
После непродолжительного исследования, оказалось что сотрудник фронт-офиса по ошибке внес в величину депозита процентную ставку, а в процентную ставку внес величину депозита. Далее распечатал договор и клиент не смотря подписал его. А уже ночью процентная ставка не смогла попасть в ХД.
Конечно после этого у нескольких отделов началось то, что можно охарактеризовать как "Усе пропало, шеф!". С клиентом связались, пригласили переподписать договор ну и оперативно вендером были внесены изменения. Happy End?
Мог, хотя наши юристы говорили, что "все хорошо", но мне кажется, что так же говорили и про случай (который вы описали) с ТКС
Многие считают, что телефонный код Украины +38. Это бы объяснило почему не влезает один символ. Про второй пока идей нет.
Операторы добавляют путаницу. Если код страны +38, тогда префикс оператора — 012 (допустим), а полностью номер +38 012 345 67 89, если же код страны все-таки +380 — тогда префикс оператора всего лишь 12, а номер полностью — +380 12 345 67 89. Но второе написание практически не встречается, хотя по сути он правильный, везде и всюду пишут именно как в первом варианте. Сам одно время долго удивлялся, чего ж это всякие амазоны и пейпалы имеют "кривую" форму для номера телефона, а потом выяснил, что к чему…
Раньше все еще запущеннее было — обязательная восьмерка в телефонном номере, и код страны превращался в +3, а весь номер в черти-что вида +3 8 012 345 67 89…
Раньше все еще запущеннее было — обязательная восьмерка в телефонном номере, и код страны превращался в +3, а весь номер в черти-что вида +3 8 012 345 67 89…
Довольно странно, учитывая, что например в Китае Apple сейчас более чем популярен, и номера телефонов там выглядят как +86 12345678900 — под них-то точно должны были подогнать.
(С содроганием представил себе пра-пра-правнучку кого-нибудь, чья семья по традиции берёт в замужестве двойную фамилиию. Наталью Иванову-Петрову-Сидорову-Пушкину-Лермонтову-Сухово-Кобылину.)
Последним в последнем томе регулярного издания, вышедшем в прошлом году, числился Франсиско-Каэтано-Августин-Лусия-и-Мануэль-и-Хосефа-и-Мигель-Лука-Карлос-Педро Тринидад. («Род. 16 июля 1491 г. н. э., ум. 17 июля 1491 г. н. э. Родители: Педро-Карлос-Лука-Мигель-и-Хосефа-и-Мануэль-и-Лусия-Августин-Каэтано-Франсиско Тринидад и Мария Тринидад (см.). Португалец. Анацефал. Кавалер Ордена Святого Духа, полковник гвардии».)
"Семейный кодекс Российской Федерации" от 29.12.1995 N 223-ФЗ (ред. от 30.12.2015)
СК РФ, Статья 32. Право выбора супругами фамилии
- Супруги по своему желанию выбирают при заключении брака фамилию одного из них в качестве общей фамилии, либо каждый из супругов сохраняет свою добрачную фамилию, либо, если иное не предусмотрено законами субъектов Российской Федерации, присоединяет к своей фамилии фамилию другого супруга.
Соединение фамилий не допускается, если добрачная фамилия хотя бы одного из супругов является двойной.
Может быть исключение, если добрачная "на самом деле двойная" фамилия кого-то из супругов признана судом по какой-то причине не двойной. Ну вот много поколений в семье по мужской линии идёт фамилия типа Штерн-Переконский. Тогда может быть юридически двойная фамилия, а по факту тройная (с двумя дефисами): Штерн-Переконский-Петров. Несколько таких случаев имеют место быть, вот только недавно где-то читал про это дело.
Хм. Моя фамилия на одну букву длиннее "Сапожниковой" — но латиницей еще немного длиннее. Не любой банк может указать ее на карте вместе с именем.
А имя короткое, намного короче Александра.
А имя короткое, намного короче Александра.
Ну, не знаю. Живу с двойной фамилией (не в первом поколении уже, кстати, и даже детям передал). Проблемы с неправильной фамилией возикают очень редко (я бы даже сказал, что за последнее время — только в самописной веб-панели какого-то наколеночного доменного недорегистратора.
Зато, вот, люди — хронически её искажают. Только паре человек на моей памяти удалось с первого раза правильно её воспроизвести :)
// А уж сколько я натерпелся за щкольные годы...
Зато, вот, люди — хронически её искажают. Только паре человек на моей памяти удалось с первого раза правильно её воспроизвести :)
// А уж сколько я натерпелся за щкольные годы...
Вспомнился анекдот:
Здравствуйте, я за зарплатой, моя фамилия Итого.
Здравствуйте, я за зарплатой, моя фамилия Итого.
В компьютерной терминологии такие случаи называют пограничными — неожиданные и проблемные ситуации, на которые не рассчитана система.
Пограничный случай — это всё-таки случай, когда программе на вход подаётся граничная точка области допустимых значений входных данных, а не "неожиданная ситуация". И длинная фамилия в некотором роде является пограничным случаем только тогда, когда её длина равна максимальной для данной системы.
Появление NaN в Perl — это весьма интересная история, ведь в Perl строки и числа являются одним и тем же типом — scalar.
Разработчики языка ввели поддержку NaN и Inf без возможности ее отключить. И ввели качественно:
В кратчайшие сроки оказались уязвимыми многие биллинговые и торговые системы. И хотя прошло около десяти лет, но до сих пор кое-где можно ввести NaN в поле "количество" или "сумма" и обеспечить кучу проблем.
А знаете, зачем разработчики языка это сделали? Ради ухода от ошибки "division by zero". Такого бессмысленного и беспощадного издевательства сообщество не простило и в том же году популярность Perl начала резко снижаться, хотя до этого понемногу росла.
Разработчики языка ввели поддержку NaN и Inf без возможности ее отключить. И ввели качественно:
- NaN пролезал через такие стандартные методы экранирования как int, sprintf
- NaN просачивался через защитные условия — операция сравнения с ним всегда возвращала false:
return ERROR_NO_MONEY if ($money < $account_balance); # в случае NaN не сработает. - NaN расползался как вирус, потому как любая операция с NaN возвращала NaN
В кратчайшие сроки оказались уязвимыми многие биллинговые и торговые системы. И хотя прошло около десяти лет, но до сих пор кое-где можно ввести NaN в поле "количество" или "сумма" и обеспечить кучу проблем.
А знаете, зачем разработчики языка это сделали? Ради ухода от ошибки "division by zero". Такого бессмысленного и беспощадного издевательства сообщество не простило и в том же году популярность Perl начала резко снижаться, хотя до этого понемногу росла.
Если в поле "количество" можно ввести NaN и оно пойдет дальше по коду, то это проблема с программистом, который поленился фильтровать ввод, а не с языком.
Так же написал про стандартные методы: чтобы фильтровать ввод для численных данных используется int для целых чисел, арифметическая операция типа $val+=0 или sprintf() если нужно округление ($val = sprintf('%.2f', $val). И все три метода отлично работали. До NaN.
$val += 0 это считай что и не фильтровали вообще — все равно скаляр, что приводится к числу, этим числом и заменится при арифметических операциях.
Стандартом при фильтровании в первую очередь должно быть правильное RE, а int() и sprintf() это скорее костыль — чтобы код отработал любой ввод вместо соответствующего вывода об ошибке.
P.S. Согласен, что имплементация inf и nan заслуживала более уважительного к себе отношения, нежели проверка первых трех символов:
Стандартом при фильтровании в первую очередь должно быть правильное RE, а int() и sprintf() это скорее костыль — чтобы код отработал любой ввод вместо соответствующего вывода об ошибке.
P.S. Согласен, что имплементация inf и nan заслуживала более уважительного к себе отношения, нежели проверка первых трех символов:
% perl -le «print 1 + 'info'»
inf
% perl -le «print 1 + 'nano'»
nan
все равно скаляр, что приводится к числу, этим числом и заменится при арифметических операциях.
Приводить к числу полезно для записей в логах, для передачи параметра обратно в JS или в БД. Тут наложился еще и тот фактор, что операции сравнения c NaN выдавали всегда false. Я уважаю принципы защитного программирования, но кто же мог предположить, что сломается сразу два механизма, которые использовались много лет? Понятно, что в итоге все кончилось RE. И я очень надеюсь, что не появится какой-нибудь аналог NaN в рамках RE, пролезающий под \d.
Это неправильный способ фильтровать ввод в perl. Правильный — только регэксп.
NaN вообще придумал какой-то больной на голову человек непонятно, зачем.
Например, в JS typeof NaN == 'number'
Например, в JS typeof NaN == 'number'
Проблема в артикле. NaN это не «не-число». NaN это «не-определённое-число» — Not-A-Number.
"a" = "one", "Not one number", "не число".
И почему же "Не одно (какое-то) число" === "не число"? Число же, просто не одно какое-то конкретное.
«Не одно конкретное» — Not the number
Not a number — не представитель класса объектов Number. Not a problem — не проблема. Not a number — не число.
Not a number — не представитель класса объектов Number. Not a problem — не проблема. Not a number — не число.
Уточню: «не (одно какое-то конкретное)» = «одно какое-то не-конкретное». Что и является референтом неопределённого артикля.
"Not a number" всё-таки переводится как "не число". Как раз потому, что "a" — неопределенный артикль. Если штука не является любым неопределенным числом, она не является всеми числами. Значит, она вообще не принадлежит к числам.
"We're looking for number 42. That's not the number we're looking for." — пример с не каким-то одним числом
"We're looking for number 42. That's not a number [at all]! That's a crocodile" — пример с не-числом
"We're looking for number 42. That's not the number we're looking for." — пример с не каким-то одним числом
"We're looking for number 42. That's not a number [at all]! That's a crocodile" — пример с не-числом
Если штука не является любым неопределенным числом
Простите, но тут либо "любым", либо «неопределённым». Артикль у нас один. «Не-любое-число» всё-таки не «Любое не-число», а «не-определённое-число» это то, о чём я и пишу.
Простите, но тут либо "любым", либо «неопределённым». Артикль у нас один. «Не-любое-число» всё-таки не «Любое не-число», а «не-определённое-число» это то, о чём я и пишу.
"Не-любое-число" это "не-число", и только так.
Но any в выражении отсутствует.
В русском вообще есть прекрасное слово "некоторый". "Некоторое число".
Если из бесконечности вычесть бесконечность, получим некоторое число, но какое именно: мы не знаем.
В русском вообще есть прекрасное слово "некоторый". "Некоторое число".
Если из бесконечности вычесть бесконечность, получим некоторое число, но какое именно: мы не знаем.
Я понял, где корень проблемы. Вы читаете фразу как "не любое число", а я — как "не любое число". Если мы вернемся к первоначальному варианту "not a number", будет понятно, что второй вариант перевода верный, потому что неопределенный артикль относится к слову "number".
Давайте вернемся к природе неопределенного артикля.
a number — неопределенное число. Можете рассматривать это как некий шаблон, класс объектов number. 2 is a number. 15 is a number. Какое число сюда ни подставь, всё будет "a number".
not a number — всё, что не является той странной фигнёй, которую мы получили на прошлом шаге. Отпадает 2, отпадает 15, отпадает ещё бесконечность чисел, что остаётся? Не числа.
Вы не можете взять NaN и сказать, что NaN является не каким-то определенным числом. Потому что "какого-то определенного числа" не существует в контексте появления NaN. Это определение бессмысленно. Возьмем "5", 5 != NaN. Всё, мы нашли то конкретное число? Все остальные числа равны NaN? Нет, конечно.
any в выражении отсутствует.
Давайте вернемся к природе неопределенного артикля.
a number — неопределенное число. Можете рассматривать это как некий шаблон, класс объектов number. 2 is a number. 15 is a number. Какое число сюда ни подставь, всё будет "a number".
not a number — всё, что не является той странной фигнёй, которую мы получили на прошлом шаге. Отпадает 2, отпадает 15, отпадает ещё бесконечность чисел, что остаётся? Не числа.
Вы не можете взять NaN и сказать, что NaN является не каким-то определенным числом. Потому что "какого-то определенного числа" не существует в контексте появления NaN. Это определение бессмысленно. Возьмем "5", 5 != NaN. Всё, мы нашли то конкретное число? Все остальные числа равны NaN? Нет, конечно.
Поэтому я и стараюсь использовать лисповые скобки.
Второй вариант перевода не верный, поскольку "2 is a number" это бессмыслица. "2 is the number". Оно определено самим собой.
А "Infinity is a number", "-Infinity is a number" и "NaN is a number" взаимодополняются как "Самое большое по модулю положительное неопределённое число", "Самое большое по модулю отрицательное неопределённое число" и "Неопределённое число в промежутке между двумя предыдущими". Quartum non datur.
Второй вариант перевода не верный, поскольку "2 is a number" это бессмыслица. "2 is the number". Оно определено самим собой.
А "Infinity is a number", "-Infinity is a number" и "NaN is a number" взаимодополняются как "Самое большое по модулю положительное неопределённое число", "Самое большое по модулю отрицательное неопределённое число" и "Неопределённое число в промежутке между двумя предыдущими". Quartum non datur.
«2 is a number» это бессмыслица
Простите, но перед лицом подобных высказываний у меня вдруг куда-то делись все аргументы. Могу разве что посоветовать на досуге прочитать что-нибудь про артикли и разницу предложений вроде "he is a man"/"he is the man" — уверен, про это немало написано.
Провёл гуглоисследование и выяснил, что "2 is number" встречается чуть чаще "2 is a number". Правда, примеры с дробями и неотфильтрованными неалфавитными знаками сильно мешают.
Впрочем, глядя на спеки, понимаю, что их составители тоже не вполне понимали разницу, потому и засунули в генераторы NaN как случаи
так и случаи
Для второго куда больше подошло бы значение undefined, но оно уже используется для другого.
Есть ли языки с нативным TypeUndefined для таких случаев?
Впрочем, глядя на спеки, понимаю, что их составители тоже не вполне понимали разницу, потому и засунули в генераторы NaN как случаи
Infinity - Infinity; // Неопределённое число в математическом смыслетак и случаи
parseInt('zzz'); // Неопределённое значение для типа Number / IntДля второго куда больше подошло бы значение undefined, но оно уже используется для другого.
Есть ли языки с нативным TypeUndefined для таких случаев?
Так можно же использовать второй пункт и вычислить ($val == $val), что true всегда, когда $val ≠ NaN.
Пример
my $val=NaN;
print ($val == $val);
Результат пустой.
my $val=NaN;
print ($val == $val);
Результат пустой.
Нетрудно защититься от NaN в новом проекте: $val=~s/[^\d.]+//g; — и уже не важно был ли там NaN или нет.
Но представьте себе старый проект, в котором полмиллиона строк кода и десятки, а то и сотни мест, где могут быть введены числовые данные. И тут как снег на голову сваливается вот такой "подарочек". А если еще и разработка проекта была завершена несколько лет назад сторонней командой...
Но представьте себе старый проект, в котором полмиллиона строк кода и десятки, а то и сотни мест, где могут быть введены числовые данные. И тут как снег на голову сваливается вот такой "подарочек". А если еще и разработка проекта была завершена несколько лет назад сторонней командой...
А скоро прогрессивные японцы начнут давать детям имена содержащие эмодзи и прочую лабуду…
Ваш ник потрясающе подходит вашему комментарию
Но ведь есть же юникод. Да и вообще, прогаммисты умные и взрослые дяди, придуали бы универсальный стандарт чтобы можно было всё.
Извините, оффтоп, но как прочитал ваш комментарий, так в мозгу сюрреалистическая картинка возникла — вместо паспорта таскать за собой винчестер, в котором было бы записано имя-фамилия-отчество. Как раз 3 Тб выходит… А хочешь родителем стать, чтоб детей вписать — будь добр, меняй на увеличенного объема… :)
Прочитав ваш комментарий, вспомнил xkcd про 14 конкурирующих стандартов.
Вы так говорите, как будто это что-то плохое!
Ну, как мне кажется, так далеко (в Японию) ходить не надо, наши тоже на многое способны: назвать сына БОЧРВФ260602
www.woman.ru/kids/medley5/article/51059
www.woman.ru/kids/medley5/article/51059
Ух ты, оно ещё продолжается. Так ведь и до паспорта дойти может, а там отписки что «нельзя цифры в имени» не будет.
«У сына правильное имя. Не Петя или Вася, а человек!»
Zapp: What's your name?
Hugh Man: Hugh Man, sir.
Zapp: Now that's a name I can trust.
«У сына правильное имя. Не Петя или Вася, а человек!»
Zapp: What's your name?
Hugh Man: Hugh Man, sir.
Zapp: Now that's a name I can trust.
Ясно что «Нуль»- недоработка разработчиков программы, а вот с Кейханаикукауакахихулихе'экахаунаеле я бы наоборот, попросил её сменить фамилию на более короткий и удобочитаемый вариант.
Прогрессивное сообщество скажет, что это расизм и притеснение культуры меньшинств.
Когда уже жалкие человеки поймут что легче идентифицировать себя по номеру))
И да и нет. Мне кажется вы переоцениваете возможности идентификации по номеру. В Польше, например, у каждого человека есть номер. И его просят указывать почти во всех гос формах и во многих не гос. Это и правда удобно. Но имя и фамилию никто из форм убирать и не думает. Потому что если вы ошибетесь в одной цифре своего номера вы станете совсем другим человеком, а если в одной букве своего имени-фамилии, то это будет всего-лишь опечаткой. К тому же имя и фамилия являются своего рода контрольной суммой к номеру — они должны соответствовать друг другу.
Умерла уже аська, на смену ей пришёл jabber с запоминающимися именами. Да и в соцсетях уже давно можно вместо цифр буквы использовать. Так удобнее и проще запоминать.
А по-моему, это просто какие-то обезьяньи вопли. Не в обиду госпоже Кейха.
Всё-таки фамилии гавайцев — это достаточно новое введение (в 1860 году Камехамеха IV обязал их получить фамилии — до этого были только имена), так что не думаю что введение ограничений на них можно считать ущемлением их традиционной культуры.
Базы данных не при чем.
Это горе-программисты, незнакомые с техникой использования bind variables, пишут такой код от которого потом проблемы людям со странными фамилиями. Зато лафа хакерам умеюшим делать SQL injections. На картинке про «Роберта — брось стол» именно такая иньекция. :) Но бороться с ней экранированием символов бесполезно. Только bind variables.
Это горе-программисты, незнакомые с техникой использования bind variables, пишут такой код от которого потом проблемы людям со странными фамилиями. Зато лафа хакерам умеюшим делать SQL injections. На картинке про «Роберта — брось стол» именно такая иньекция. :) Но бороться с ней экранированием символов бесполезно. Только bind variables.
Почему бесполезно? Вполне полезно.
Ну-ну. Блажен, кто верует.
До первого залета.
До первого залета.
SQL injection на картинке про роберта сквозь экранирование не пролезет.
Так что в данном случае — полезно.
Так что в данном случае — полезно.
В _данном_ случае, возможно спасет. В общем случае — нет.
При экранировании апострофа двойным, длина строки увеличивается.
Например можно забить апострофами имя до предела длины строки, так что последний апостроф будет нечетным. В лучшем случае INSERT упадет. А если это UPDATE? Есть шанс, что остальные предикаты могут быть вытолкнуты из запроса, и он пройдет не по одной строке, а по многим.
Или в запросе INSERT INTO Students(FirstName, MidName, LastName, Age, ...) потенциально можно подобрать значения так, что значение для FirstName будет иметь нечетное количество ', затем нечто подобное сделатьс с остальными, чтобы программа сконкатенировала иньекцию.
Или, если MySQL заэскейпить \'.
Или ввести юникодный гомоглиф, который программа пропустит, а база превратит в апостроф.
Хакеры изобретательный народ.
Писать хитрые процедуры экранирования будет дороже, чем просто сделать запрос параметризированным (bind vars).
При экранировании апострофа двойным, длина строки увеличивается.
Например можно забить апострофами имя до предела длины строки, так что последний апостроф будет нечетным. В лучшем случае INSERT упадет. А если это UPDATE? Есть шанс, что остальные предикаты могут быть вытолкнуты из запроса, и он пройдет не по одной строке, а по многим.
Или в запросе INSERT INTO Students(FirstName, MidName, LastName, Age, ...) потенциально можно подобрать значения так, что значение для FirstName будет иметь нечетное количество ', затем нечто подобное сделатьс с остальными, чтобы программа сконкатенировала иньекцию.
Или, если MySQL заэскейпить \'.
Или ввести юникодный гомоглиф, который программа пропустит, а база превратит в апостроф.
Хакеры изобретательный народ.
Писать хитрые процедуры экранирования будет дороже, чем просто сделать запрос параметризированным (bind vars).
Да я ж не спорю, что бинд лучше, надёжнее и т.п.
Но утверждение, что экранирование бесполезно — неумный экстремизм. Лучше уж с ним, чем вообще без.
От случайных ошибок и странных имён убережёт, и то хлеб. От большинства типовых проблем. И это хорошо.
А хакеры такие твари, ничего от них не поможет, даже бинд. Только им ваш сайт нафиг не упёрся в большинстве случаев.
Но утверждение, что экранирование бесполезно — неумный экстремизм. Лучше уж с ним, чем вообще без.
От случайных ошибок и странных имён убережёт, и то хлеб. От большинства типовых проблем. И это хорошо.
А хакеры такие твари, ничего от них не поможет, даже бинд. Только им ваш сайт нафиг не упёрся в большинстве случаев.
> странных имён убережёт.
Ну да, а потом проблемы у всяких Янов, Д'Артаньянов, корейцев с фамилией Ю, и тп.
>Лучше уж с ним, чем вообще без.
Лучше уж без. С байндами и надежно, и не надо бесполезную логику навинчивать, которая усложняет, т.е. в итоге удорожает.
>Только им ваш сайт нафиг не упёрся в большинстве случаев.
Заблуждаетесь. Чего они тогда на мой домашний SSH ломятся?
Да и на работе, помню, в безобидном ASP приложении (не про деньги, нафиг не упёрлось), хакеры инекцией добавили в столб Note во всех строках таблицы JavaScript код, который был не видим, т.к. они поставили 0 символ в конце легитимного текста, а свой код за ним. И в браузере всех юзеров он тоже был не видим, но исполнялся, че-то куда-то сливал, или счетчики где-то накручивал.
Когда я указал (я ДБА), откуда ноги растут, посчитали во сколько обойдется переделать все сконкатенированные SQL-запросы в аппе на параметризированные, то просто… закрыли глаза. Не было столько в бджете. Я, конечно, сделал процедурку, которая чистит таблицы по расписанию, на всякий случай. Но damage was done.
Ну да, а потом проблемы у всяких Янов, Д'Артаньянов, корейцев с фамилией Ю, и тп.
>Лучше уж с ним, чем вообще без.
Лучше уж без. С байндами и надежно, и не надо бесполезную логику навинчивать, которая усложняет, т.е. в итоге удорожает.
>Только им ваш сайт нафиг не упёрся в большинстве случаев.
Заблуждаетесь. Чего они тогда на мой домашний SSH ломятся?
Да и на работе, помню, в безобидном ASP приложении (не про деньги, нафиг не упёрлось), хакеры инекцией добавили в столб Note во всех строках таблицы JavaScript код, который был не видим, т.к. они поставили 0 символ в конце легитимного текста, а свой код за ним. И в браузере всех юзеров он тоже был не видим, но исполнялся, че-то куда-то сливал, или счетчики где-то накручивал.
Когда я указал (я ДБА), откуда ноги растут, посчитали во сколько обойдется переделать все сконкатенированные SQL-запросы в аппе на параметризированные, то просто… закрыли глаза. Не было столько в бджете. Я, конечно, сделал процедурку, которая чистит таблицы по расписанию, на всякий случай. Но damage was done.
Как-то вы странно экранируете, что проблемы у Янов, Д'Артаньянов и Ю. Я ещё могу себе представить супермегахакера с тремя миллионами кавычек, хотя от переполнения нужно защищаться отдельно, но чем Д'Артаньян-то не угодил? И, тем более, Ю?
Любой разумный ввод от пользователя экранирование позволит обработать правильно. Хоть Null, хоть Д'''''Артаньян. И это хорошо.
Хакеры инъекцию нуля в экранированный код провели? Правда-правда? Сильны.
Любой разумный ввод от пользователя экранирование позволит обработать правильно. Хоть Null, хоть Д'''''Артаньян. И это хорошо.
Хакеры инъекцию нуля в экранированный код провели? Правда-правда? Сильны.
Да это не я экранирую. Я как раз против этого (для баз). Про проблемы Янов почитайте ниже.
Д'Артаньян не угодил переполнением. Если вы задали переменную в программе не в 2 раза длиннее чем поле в форме, то жди переполнения.
Я за экранирование, которое проверяет на предмет зловредного HTML/JavaScript кода в полях типа Notes. Но к базам это не имеет никакого отношения.
Понятие «разумный ввод от пользователя» отличается не только от приложения к приложению, от формы к форме, от поля к полю, но и от записи к записи.
Будете для каждого случая писать скринеры?
Часто бизнес аналитики, не знакомы с техниками хакерских атак, и не могут составить спеки с учетом _всех_ необходимых ограничений, либо перестраховываются и вводят чрезмерные ограничения. Их понятие «разумного ввода» может не работать в каких-то странных случаях.
Например кто нибудь «грамотный» скажет — надо блаклистить SQL слова!
Ага. А потом появляются возмущенные люди с фамилиями Null, Case, Begin, End, If… Девушки с именем Else…
Некоторые программисты, особенно веб-программисты, привыкли все конкатенировать.
Большинство веб-программистов, что я встречал, вообще _не знали_, что такое байнды, и что могут быть атаки-иньекции.
>Хакеры инъекцию нуля в экранированный код провели? Правда-правда? Сильны.
Нет. В том случае, веб-«программист» был настолько безграмотен и ленив, что даже этого не сделал.
Результат — разгневанные клиенты, интернет ржет, репутации компании нанесен урон.
Д'Артаньян не угодил переполнением. Если вы задали переменную в программе не в 2 раза длиннее чем поле в форме, то жди переполнения.
Я за экранирование, которое проверяет на предмет зловредного HTML/JavaScript кода в полях типа Notes. Но к базам это не имеет никакого отношения.
Понятие «разумный ввод от пользователя» отличается не только от приложения к приложению, от формы к форме, от поля к полю, но и от записи к записи.
Будете для каждого случая писать скринеры?
Часто бизнес аналитики, не знакомы с техниками хакерских атак, и не могут составить спеки с учетом _всех_ необходимых ограничений, либо перестраховываются и вводят чрезмерные ограничения. Их понятие «разумного ввода» может не работать в каких-то странных случаях.
Например кто нибудь «грамотный» скажет — надо блаклистить SQL слова!
Ага. А потом появляются возмущенные люди с фамилиями Null, Case, Begin, End, If… Девушки с именем Else…
Некоторые программисты, особенно веб-программисты, привыкли все конкатенировать.
Большинство веб-программистов, что я встречал, вообще _не знали_, что такое байнды, и что могут быть атаки-иньекции.
>Хакеры инъекцию нуля в экранированный код провели? Правда-правда? Сильны.
Нет. В том случае, веб-«программист» был настолько безграмотен и ленив, что даже этого не сделал.
Результат — разгневанные клиенты, интернет ржет, репутации компании нанесен урон.
Вы, вероятно, встречали веб-программистов очень давно. Bind-ы повсюду. Для ленивых есть даже библиотеки, позволяющие биндить не заморачиваясь:
А еще более ленивые используют дополнительный слой абстракции для работы с учетом разных СУБД:
my ($sql, @bind) = sql_interp
'SELECT * FROM table WHERE x = ', \$s, 'AND y IN', \@v;
# RESULT:
# $sql = 'SELECT * FROM mytable WHERE x = ? AND y IN (?, ?)'
# @bind = ($s, @v);А еще более ленивые используют дополнительный слой абстракции для работы с учетом разных СУБД:
use SQL::Abstract;
my $sql = SQL::Abstract->new;
my %where = (
requestor => 'inna',
worker => ['nwiger', 'rcwe', 'sfz'],
status => { '!=', 'completed' }
);
my($stmt, @bind) = $sql->select('tickets', '*', \%where);
# Эквивалент:
# $stmt = "SELECT * FROM tickets WHERE
# ( requestor = ? ) AND ( status != ? )
# AND ( worker = ? OR worker = ? OR worker = ? )";
# @bind = ('inna', 'completed', 'nwiger', 'rcwe', 'sfz');
Зато лафа хакерам умеюшим делать SQL injections. На картинке про «Роберта — брось стол» именно такая иньекция. :)Ну спасибо, что просветили.
Это хотя бы более или менее очевидные проблемные фамилии, и примерно понятны причины их возникновения.
Я как то раз словил непонятную ошибку у одного из пользователей нашей системы. После долгих выяснений оказалось, что учетная запись пользователя в домене, соответствовавшая фамилии пользователя — Струева, на английском, соответственно — strueva, в некоторых местах программы определялась как s1va. При сравнении разных вариантов учетной записи система не находила соответствия и не выдавала права пользователю.
К сожалению, в код, который генерировал подобную багу, мне заглянуть не довелось, проблему решили, переименовав учетку.
Я как то раз словил непонятную ошибку у одного из пользователей нашей системы. После долгих выяснений оказалось, что учетная запись пользователя в домене, соответствовавшая фамилии пользователя — Струева, на английском, соответственно — strueva, в некоторых местах программы определялась как s1va. При сравнении разных вариантов учетной записи система не находила соответствия и не выдавала права пользователю.
К сожалению, в код, который генерировал подобную багу, мне заглянуть не довелось, проблему решили, переименовав учетку.
Подтверждаю такое. DocsVision меняет true на 1 в логине Struev и пользователь становится S1v с соответствующими проблемами в системе. Вендор ничего по этому инциденту не решил. Аналогично переименовали человеку учетку.
Совершенно прелестный баг. Разработчиков, которые по собственной прихоти вычленяют булево значение из строки надо бить.
Скорее всего они ручками формируют SQL-запрос из этих параметров, а для этого с ними делают .ToString(), в том числе для логического типа, что даёт строки "true" и "false", но в SQL надо 1 и 0, поэтому, после того, как сформировали запрос, они в нём делают .Replace("true", "1").Replace("false", "0"), или даже сразу делают .ToString.Replace.Replace. Но зачем они так делают? Интересно посмотреть на какого-нибудь Фалсева.
Вспоминается фильм где главного героя в итоге начали называть «Sure, Not»
А я вспомнил историю, как товарищ с именем Ян не смог купить билеты у РЖД, потому что система ответила "имя должно содержать не менее 3 букв".
База ОМС полгода не давала вбивать отчества, не заканчивающиеся на -ович и -овна. Разработчики не слышали про Оглы и Кызы.
А как же Ильич?
Именно. Процентов 5 прикреплённого населения в базе пометилось как неправильно вбитое, а новых Ильичей и Илья Оглы вбить из программы было нельзя.
:)
А вот dbf редактором на ура. Забивали с программы как Ильичович или ИльяОглыович, потом ручками конвертил поиском перед ежемесячной сдачей базы. Так эти полгода и крутился.
Мой знакомый "китаец" (родился в Китае, но с пяти лет жил сначала в России, потом в Туркменистане, потом и в Украину перебрался, так что я даже не знаю, какой он национальности :) ) постоянно мучается. Ли Ши Го, в три слога. Говорит, подумывает переименоваться в Лешу, ибо практически любая процедура, связанная с внесением его имени-фамилии в компьютер обычно заканчивается огромным геморроем… Причем независимо от уровня конторы — начиная от местечкового провайдера и заканчивая госучереждениями вроде МРЭО…
Мой знакомый Ян логинился как Яян или даже Яяяян.
Обладая только именем и фамилией (строго говоря — именем и отчеством) в документах, жена испытывает определенные проблемы в общении с операторами в различных учреждениях. Просим ввести в поля отчества и фамилии одинаковые значения — некоторые отказываются, приходится скандалить. Такая морока, знаете ли.
Ух ты, интересно! Она исландка?
А я бы скандалил, если бы как раз предлагали именно это. Ну нет у меня отчества, и фамилия им не является. Делайте что хотите.
У наших студентов-монголов были только имена. В программах дублировали его во все три поля.
Не удержался от бояна…
Русский, французский и китайский лингвисты решили написать имена друг-друга каждый на своем языке.
— Моя фамилия Ге — сказал француз китайцу.
— В китайском языке два иероглифа Ге, но, к сожалению, не один из них не подходит для фамилии.
— Почему?
— Потому что один имеет значение «колесо», а другой передает звук, с которым лопается мочевой пузырь осла.
— А что плохого в колесе?
— Мужское имя не может быть круглым, все будут считать тебя педиком. Для твоего имени мы возьмем иероглиф Шэ, означающий «клавиатура», «корнеплод», «страница» а также прилагательное «бесснежный» и дополним его иероглифом Нгу, означающим мужской род. В конце я пишу иероглиф Мо — «девственный».
— Но… это, мягко говоря, не совем так…
— Никто не будет считать тебя девственником, просто без иероглифа Мо иероглифы Ше-Нгу означают «сбривающий мамины усы»
— Хорошо, теперь я напишу твое имя.
— Моя фамилия Го.
— Отлично, я начну твою фамилию с буквы G.
— Что означает буква G?
— У нас, европейцев, сами по себе буквы ни хрена не значат, но чтобы проявить к тебе уважение я поставлю перед G букву H — во французском она все равно не читается.
— Отлично! Дальше O?
— Нет, чтобы показать, что G — произносится как Г, а не как Х, надо после G поставить букву U, а также H — чтобы показать, что U не читается сама по себе, а только показывает, как правильно читать G, и буквы EY, показывающую, что слово не длинное и скоро кончится.
— Hguhey… дальше O?
— Нет, О во французском произносится как А или Ё, в зависимости от стоящих по соседству букв, ударения и времени года. Твое чистое О записывается как AUGHT, но слово не может кончаться на T, поэтому я добавлю нечитаемое окончание NGER. Вуаля!
Русский лингвист поставил бокал на стол, взял бумажку и написал «Го» и «Ге».
— И всё?
— Да.
Француз с китайцем почесали в затылке.
— Хорошо, как твоя фамилия, брат?
— Щекочихин-Крестовоздвиженский.
— А давайте просто бухать? — первым нашелся китаец.
Русский кивнул и француз с облегчением поднял тост за шипящие дифтонги.
Русский, французский и китайский лингвисты решили написать имена друг-друга каждый на своем языке.
— Моя фамилия Ге — сказал француз китайцу.
— В китайском языке два иероглифа Ге, но, к сожалению, не один из них не подходит для фамилии.
— Почему?
— Потому что один имеет значение «колесо», а другой передает звук, с которым лопается мочевой пузырь осла.
— А что плохого в колесе?
— Мужское имя не может быть круглым, все будут считать тебя педиком. Для твоего имени мы возьмем иероглиф Шэ, означающий «клавиатура», «корнеплод», «страница» а также прилагательное «бесснежный» и дополним его иероглифом Нгу, означающим мужской род. В конце я пишу иероглиф Мо — «девственный».
— Но… это, мягко говоря, не совем так…
— Никто не будет считать тебя девственником, просто без иероглифа Мо иероглифы Ше-Нгу означают «сбривающий мамины усы»
— Хорошо, теперь я напишу твое имя.
— Моя фамилия Го.
— Отлично, я начну твою фамилию с буквы G.
— Что означает буква G?
— У нас, европейцев, сами по себе буквы ни хрена не значат, но чтобы проявить к тебе уважение я поставлю перед G букву H — во французском она все равно не читается.
— Отлично! Дальше O?
— Нет, чтобы показать, что G — произносится как Г, а не как Х, надо после G поставить букву U, а также H — чтобы показать, что U не читается сама по себе, а только показывает, как правильно читать G, и буквы EY, показывающую, что слово не длинное и скоро кончится.
— Hguhey… дальше O?
— Нет, О во французском произносится как А или Ё, в зависимости от стоящих по соседству букв, ударения и времени года. Твое чистое О записывается как AUGHT, но слово не может кончаться на T, поэтому я добавлю нечитаемое окончание NGER. Вуаля!
Русский лингвист поставил бокал на стол, взял бумажку и написал «Го» и «Ге».
— И всё?
— Да.
Француз с китайцем почесали в затылке.
— Хорошо, как твоя фамилия, брат?
— Щекочихин-Крестовоздвиженский.
— А давайте просто бухать? — первым нашелся китаец.
Русский кивнул и француз с облегчением поднял тост за шипящие дифтонги.
Предположу чисто гипотетический случай, когда все поля формы пропускаются через фильтр мата. Тогда фамилия, скажем, Аблямитов фильтр не пройдёт.
Ну в каких-то случаях это может давать преимущество. Например, невидимость такого человека для налоговой системы или базы должников по кредитам.
В статье перечислили несколько сайтов, на которых есть потенциальная дыра в защите.
[sarcasm]А можно весь список сайтов, которые не учитывают тип «Null»?[/sarcasm]
[sarcasm]А можно весь список сайтов, которые не учитывают тип «Null»?[/sarcasm]
Да что там Null или Кейханаикукауакахихулихе'экахаунаеле...
В России, чтобы иметь нескончаемые проблемы с именем, достаточно иметь в нём букву "ё".
В России, чтобы иметь нескончаемые проблемы с именем, достаточно иметь в нём букву "ё".
Всё же фамилия этой женщины звучит как Нал, а не Нуль.
Напомнило
"SQL инъекция при помощи рег. номера для камеры слежения за траффиком."
Ха! Вы попробуйте на половине рунетных сайтов зарегистрироваться с номером сотового, начинающемся не на +7
а это тут при чем? «половина рунетных сайтов» вполне может не уметь отправлять смс на номера с другими префиксами.
Там несколько другой механизм — все эти смс-ки платные (деньгами или партнерками, уже непринципиально, главное то, что гешефт оператор все равно получить должен). И естественно, подключить "тарифный план" только на смс-ки по России для владельца сайта гораздо выгоднее, чем ради 5-10% пользователей терять приличные суммы, чтобы были и международные рассылки.
Я не смог верифицировать свои данные на одном польском сайте (платежная система), потому что форма сразу при вводе говорит, что у меня "имя неправильное".
Т.е. они видимо берут список Расово Верных польских имен, а все остальные — не пропускают как неправильные.
Т.е. они видимо берут список Расово Верных польских имен, а все остальные — не пропускают как неправильные.
Ну, например, ЕСПЧ недавно отказал родителям в праве назвать ребёнка Мирон.
http://www.rubaltic.ru/news/15032016-imya-russkomu-bez-s/
http://www.rubaltic.ru/news/15032016-imya-russkomu-bez-s/
Помню, коллега с фамилией Троян имела стабильные проблемы с почтой и антивирусом.
На StackOverflow было что-то похожее http://stackoverflow.com/questions/4456438/how-do-i-correctly-pass-the-string-null-an-employees-proper-surname-to-a-so
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дженнифер Нуль и другие неудачные фамилии