Comments 35
Слог потрясающий, как и спектр примеров. Чувствуется старая школа. Респект!
Во-первых, IНЖАЛИД ДЕЖИЦЕ, и никак иначе.
Во-вторых, сие никак не связано с кодом RADIX-50 (он использовался, как правильно сказано, в файловой системе, а также внутри некоторых трансляторов, в частности, в ассемблере) и с нечувствительностью к регистру букв: все сообщения в RSX-11 использовали ASCII с большими и малыми английскими буквами, и данное сообщение записывалось Invalid device -- как и положено. На русских же терминалах искажение происходило из-за того, что они вместо американского 7-битного ASCII поддерживали советский КОИ-7, где место малых английских букв заняли большие русские, причём расположены они были не в алфавитном порядке, а, где получалось, по созвучию с английскими, а остальное -- как попало (почему v оказалась заменена на Ж, например). Если советский терминал работал не с КОИ-7, а с КОИ-8, этой проблемы уже не было (но возникали другие).
Ну а в-третьих, использование только больших букв -- куда более ранняя практика, чем Система 360 и, тем более, PDP-11. Скорей всего, связана она была с весьма широким использованием телетайпов и тому подобного оборудования с очень ограниченным набором символов в качестве терминалов.
Во-первых, IНЖАЛИД ДЕЖИЦЕ, и никак иначе.
Недоредактировал. Спасибо, исправил. Вариант с "иНЖАЛИД дЕЖИЦЕ" это потерянное переключение кодом SI на латинскую страницу. Но мне помнится, что они могли и второе слово писать с большой буквы... как минимум в части случаев.
почему v оказалась заменена на Ж, например
Да, меня это тоже удивляет, и, думаю, каждого, кто с этим сталкивается. Вероятно, таблицу составлял кто-то, кто учил немецкий больше английского:))
Ну а в-третьих, использование только больших букв -- куда более ранняя практика, чем Система 360 и, тем более, PDP-11. Скорей всего, связана она была с весьма широким использованием телетайпов и тому подобного оборудования с очень ограниченным набором символов в качестве терминалов.
Уточнение имеет смысл, но не критично. Эти названы как наиболее ходовые и известные.
Да, меня это тоже удивляет, и, думаю, каждого, кто с этим сталкивается. Вероятно, таблицу составлял кто-то, кто учил немецкий больше английского:))
Судя по наличию Й на месте j и В на месте w - именно так оно и было. Хорошо хоть Ц не на z и З не s :) (в результате больше похоже на польский)
Й-J как раз очевидно прямее для славянских языков в принципе (и примыкающих вроде балтийских), как и почти все остальные соответствия. Традиции славянских латиниц были давно, и для русского тоже (не для основного письма, кроме коминтерновских вывертов 1920х). Собственно, только V-Ж существенно выпадает из понятной логики...
Ну на это я могу сказать что традиции славянских латиниц - это очень странный предмет, вроде бы они есть, но на самом деле их нет. К примеру, поляки и чехи [х] передают диграфом ch, а хорваты - одной буквой h, поляки [ч] cz, хорваты с чехами - č, ну [ш] sz - š. Так вот у чехов звук [в] передавался буквой w где-то до середины 19 века, ну и у всяких там хорватов и словенцев передача через w тоже вполне себе встречалась 8)
почему v оказалась заменена на Ж, например
Это соответствие похоже на русскую азбуку Морзе. Там W=В, V=Ж. Но правда там и Q=Щ, а не Я.
Почему v это ж просто.
В связи при приеме азбуки морзе на слух вместо ж писали галочку. Так быстрее написать чем выводить букву из трех закорючек.
Может дело в этом.
Не оспариваю традиций, тем более что сам к радио не имею отношения, но все же спрошу.
Разве нельзя просто написать Х и провести вертикальную черту? Это вроде не дольше, чем написать Н или П
Это заметно дольше. Если пишете на скорости, заметите это. Не зря придумали стенографию, как вариант предельно облегчить написание знаков, хоть и ценой разборчивости и заточки под индивидуальный почерк.
Вообще любой передёрг руки при написании это заметная задержка, сравнимая по времени с двумя завитками. Когда приходилось в школе и университете конспектировать, я обзавёлся некоторыми привычками для этого, в стиле брошюры Штернберга "Скоростное конспектирование" (свободно есть в Сети). Простейшее: Ә вместо Э - как раз на сокращение разрыва и переноса руки. Чуть сложнее (уже не про передёрги): Ђ вместо сочетаний типа жд. Кружочки вокруг букв, как из a делается @, например, f с кружочком - функция. Надстрочные знаки ударения как указание на часть речи при сокращении, типа п̃-но - последовательно. Кванторы, естественно (почти все предметы - математика). И так далее...
Я не знаю, было ли конкретно v вместо ж в конкретной практике телеграфистов. Но именно по описанному - не удивлюсь, если именно так и было.
побайтовое равенство. Согласен, так проще. Но с какого-то момента (массовая юникодизация) этого стало не хватать.
Как раз таки побайтовое консистентно работает независимо от того, что в этих байтах лежит - ASCII, юникод или просто бинарные данные. А вот использовать в системе (тех же именах файлов) CI (и вообще какую то "человеческую" интерпретацию байтов), учитывая что юникод постоянно растёт, байты/символы/кодпойнты - три большие разницы, перевод между регистрами зависит от локали и т.д. - открывать ящик Пандоры.
А все базы данных тяготеют как в метаданных так и в данных к CI collation по умолчанию. И никаких признаков изменения тренда не видится
Ой не все. Туда явно не тяготеют, например, Riak или Mongo :)
Очевидно, что вы имели в виду мир реляционных баз с SQL в качестве основного языка. В этом случае - да, это в заметной мере оговаривается самим SQL. Хотя и тут есть особенности. Например, мне MySQL на Linux (чтобы далеко не ходить) позволил создать одновременно таблицы t1 и T1, но не позволил сделать такое различие в именах колонок несмотря на `` кавычки.
Я не ожидаю тут изменения "тренда" потому, что толковый DBA всё равно в курсе проблемы и настроит, как ему нужно, а бестолкового не допустят к настройкам чего-то серьёзного. При наличии возможности устанавливать CS коллацию простыми настройками - умолчание уже не является проблемой.
фишка в том что я не знаю ниодого ДБА (я и сам в некотором роде ДБА) который устонавливает CS. Ровно наоборот - дефакто все юзают CI
Это исключительно специфика задач и частично приспособленных к ним средств. Например, если хранить только фамилии-имена-отчества, числа, uuidʼы (guidʼы) и т.п., то отклоняться и незачем.
А вот если хранить, например, URLы, то так уже нельзя, CI может стереть важные различия. Соответственно, колонка с ними должна быть CS. (Но при этом, если важно следить за совпадениями, домен и схема должны быть нормализованы, а путь - нет. См. примеры в статье.)
CS сейчас работает как явно задаваемые исключения в субд.
Почему "исключения"? Просто другая политика на колонку.
Вот именно что на колонку.
По умолчанию колейшен существует для всей базы (инстанса). И все колонки наследуют его. Если нужно исключение - то делают другой колейшен на колонку. Но естественно для удобства, колейшен всей базы должен быть таким, чтобы подходит для большинства колонок в базе. И на сегодня это CI. А редкие кейсы с CS, как я говорил работают как исключения, что значит девелоперам надо помнить про них и задавать явно
Но естественно для удобства, колейшен всей базы должен быть таким, чтобы подходит для большинства колонок в базе. И на сегодня это CI.
Вот это и есть инерция мышления. Реально CI не нужен в большинстве случаев, а где нужен, нужны более продвинутые правила, как нормализация юникода.
Но за счёт того, что он в большинстве случаев не мешает, это умолчание остаётся.
Реально CI не нужен в большинстве случаев
это не так. Везде за 20 лет моего опыта работы с данными в субд, в 99% случаев НУЖЕН CI.
Ибо все эти условия вида "where status = 'Enabled" придется обкладывать всякими upper-ами и все равно просочится где-нить то что обязательно упадет в самый неподходящий момент. Так что это реально антипаттерн - иметь CS в субд по умолчанию. Это дает слишком много вариантов как выстрелить себе в ногу
"where status = 'Enabled"
Я правильно понимаю, что речь идёт в вашем случае о текстовом поле, в котором записывается конкретное слово 'Enabled' и вы видите проблему в том, что кто-то может написать туда 'enabled' или 'ENABLED'?
А что, если кто-то запишет туда 'enabld' или 'Еnabled' (первая буква - кириллическая)? Эти случаи вы не отличаете?
В SQL есть понятие домена значений, и во всех "взрослых" СУБД можно налагать это на колонку. Вы не делаете такого наложения, и во всех опечатках, кроме регистра, не обвиняете никого кроме себя, а в регистре - обвиняете возможный CS?
Это дает слишком много вариантов как выстрелить себе в ногу
Главное, чем вы даёте возможность выстрелить себе в ногу - это отсутствие домена значений на колонке.
Вы сами сказали про "20 лет опыта", и не используете домены для избавления от подобных проблем?
в Монго кстати тоже по умолчанию колейшен с опцией
caseLevel : false
что значит CI
Начиная с Windows 95 было введено сохранение регистра имени и CI сравнение. При этом Goodwynn.txt, GOODwynn.TXT - одинаковые имена для поиска, но разные для показа (хотя, если все заглавные, показ в проводнике переводил в форму - одна первая заглавная). Это то, что имеем сейчас.
Ну немного не так. Сохранение регистра - это VFAT, надстройка над файловой системой для хранения длинных имён. А лежащая под ней FAT так и оставалась чисто uppercase. И для каждого файла существовало два элемента каталога - FAT и VFAT, причём последний мог занимать место для нескольких элементов. И уже гораздо потом появилась возможность (опционально) отказаться от 8.3 и использовать только длинные имена.
хотя базисты-DBA наверняка расскажут много ещё интересного
О да! впрочем, всё, что можно рассказать (матерного), просто меркнет перед темой про charset/collation.
Кстати что там в реальном мире?? ФИО сравнивают в пасспортном столе с учетом регистра или без?? Или адреса: Город-улица-дом?? Номера автомобилей с буковками?
ФИО сравнивают в пасспортном столе с учетом регистра или без??
В статье упомянуты проблемы с этим.
Город-улица-дом?? Номера автомобилей с буковками?
В случае номера автомобиля, нужно, чтобы "AA1234BB" и "AA 12 34 BB" воспринимались одинаково, значит, надо устранять пробелы (или вводить, где они критичны). А ещё и учитывать особенности представления символов. В случае Украины, например, начали выдавать номера с латиницей в буквах (Y, Z - чисто электрические, D - через Дию, и так далее), и формально по международным правилам там латиница, а ограничение до набора АВСЕНІКМОРТХ было только в начале выдачи. А большинство операторов будет вводить кириллицей. Значит, "ВІ" должно быть нормализовано до "BI" на любом вводе перед укладкой в базу.
В случае номера дома, нужно единым образом сохранять 101а и 101-А (тем именно, которым оно хранится в базе).
И снова, как видим, тут для корректного сравнения нужна более подробная нормализация, а с ней можно и нужно зафиксировать регистр уже на этапе ввода в базу, чтобы потом не создавать проблем.
Вот такой он, реальный мир-то...
Кстати, ещё про номера домов. В копилку ужасов, так сказать...
Пока вы не разберётесь, как помещать такое в базу - о регистрах и не думайте :))
Я думаю что сам по себе регистр символов, кодируемый отдельными кодами - ошибка на миллиарды долларов. Вот имеются три символа:
С точки зрения инопланетянина, это очевидно три разных символа. Мы знаем что это по смыслу одна и та же буква. Но с точки зрения Юникода, первые два - разные, а третий - лишь курсивный вариант начертания второго в некоторых шрифтах. Регистра не существует для различных иероглифов, индийского и арабского письма. И по большому счету (если бы проектировать Юникод с нуля) регистр должен быть вариантом "декорации", также как bold и italic. А в Юникод (не нынешний, а проектируемый с нуля разумеется) должны быть введены спецкоды (escape-коды) переключения регистра. И заодно, спецкоды переключения тех же bold и italic , всевозможных подчеркиваний и перечеркиваний, поворотов и отражений букв, цвета и многого другого. Некоторые такие модификаторы все равно пролезают в нынешний Юникод, но в каком-то суперкривом виде - известный пример с "цветами кожи" для смайликов, так почему бы не сделать всё системно и универсально?
Ввести форматирование в юникод - идея слишком спорная. При разработке от неё отказались, по крайней мере для основного массива: фактически, они вводят режим, а юникод был максимально рассчитан на независимость символов и отсутствие режима. (Увы, с RTL/LTR у них не получилось уйти, но это, кажется, единственное, где его ввели.) А если каждый символ уточнять отдельно цветом, толщиной, шрифтом и прочим - представляю себе объём результата... кажется, только первые версии FrontPage позволяли себе подобное.
Смайлики тут, конечно, ужас, но ещё есть определённая общность в подходах именно в том, что со всеми такими модификаторами смайлик это целый независимый объект.
"a" и "ɑ" одинаковы в основной письменности, но разные в МФА. Для всех (кажется) славянских реализуют одну и ту же фонему /a/, но заметно по-разному. Для английского - разные фонемы.
То, что юникод изначально проблемен некоторыми решениями - было объявлено ещё в первой версии. Выбор группировки по письменности, а не по языку - с одной стороны, или по форме буквы - с другой. Ничто не мешало объединить все "O" трёх основных европейских письменностей, где даже нет разницы, как менять регистр (a или α?), но этого не сделали. Несколько альтернативных представлений одного символа - одним пунктом или двумя. И прочая и прочая. Всё это было описано, разъяснены причины такого выбора. Увы, совмещение лебедя, рака и щуки в одном механизме - всегда нетривиально. Я думаю, что результат таки в колоссальной мере в плюс, а не в минус.
А вот где корень проблемы - в нашей письменности в целом. Я считаю, что манера использовать заглавные буквы в начале предложения - уже диверсия. (Есть же точки в конце предложения.) А ещё больше - их другие формы. (Поэтому я с пониманием отношусь к тем, кто не использует заглавные в начале предложений, в обычном стиле в Сети.) То использование, которое имеет смысл - как пометка имени собственного - лучше было бы делать каким-то надстрочным знаком над первой буквой. Но это мы не можем быстро поменять. А вот подходы к компьютерному хранению меняются легче.
Ввести форматирование в юникод - идея слишком спорная
А форматирование и не надо вводить. Но я бы подумал о введении разметки. К примеру, верхние и нижние индексы имеются в Юникоде как отдельные символы, но не все - только цифры, некоторые латинские буквы, некоторые спецсимволы. При этом в html и других "богатых" форматах для верхнего и нижнего индекса есть отдельная "декорация" - работающая уже для любых символов. Далее, всякие ударения, умляуты и прочие диакритические знаки - это ведь тоже "декорации"? По идее их можно назначить любому символу. Про цвета уже говорили. Направление письма туда же. Кроме того в Юникоде есть вот такая хрень - это уже в чистом виде escape-разметка как я ее предлагаю, но для очень частного случая аннотирования иероглифов.
Но с моей точки зрения в существующий стандарт вводить ничего такого не нужно. А нужно думать о новом стандарте, в котором будут учтены и исправлены все ошибки предыдущего. Да, здесь может быть картинка про 15 конкурирующих стандартов. Но можно подходить к этому и по другому - иногда действительно лучше переделать что-то с нуля, а не тащить огромный груз кривой обратной совместимости (ситуация такая же как с С++ и новыми языками типа Rust и Carbon).
А форматирование и не надо вводить
Так вроде уже.
Эх, хорошо в иврите! Lowercase нет
Безразличие к регистру — ошибка на миллиарды долларов