Суть проблемы кодировок (интересующимся могу рекомендовать приносившуюся мной достаточно давно обзорную статью) — натуральный (вспоминаем традиционное определение денег) налог на использование «неправильного» алфавита.
Свежий пример (декабрь 2024): ищу книгу по заголовку в каталоге РГБ. Где?!? Ещё вчера же была тут!..
Захожу с ревизией критериев поиска: вот она! Так вот в чём дело…
Причина в особенностях поддержки кириллицы (33 буквы современного алфавита ещё совсем недавно прямо-таки провоцировали соблазны упрощения). В смысле задействования 32 кодов номерной ёмкости. В результате чего буква «ё» «поддерживается» разнообразными костылями. С учётом определяющего достоинства современного стандарта UTF8 — досейчас.
Но интереснее было, когда я попробовал проверить гипотезу на примере памфлета Дениса Соколова («Чёрные буйволы бизнеса»). Он ищется в обоих вариантах. Подозреваю, благодаря занесению в каталог двух карточек.
Оттуда же растут корни у перевода с русского на русский в цифровом каталоге (прозрачный намёк на реформу правописания, которой дали ход из политических соображений в 18-м году). С гаданиями о переводе.
ЗЫ: Но с «і»/«и» описанный финт с «е»/«ё» уже не прокатывает… Не говоря о прочих ятях/ерах с примкнувшими ижицами.
Комментарии
Нет, с "Ё" проблема в том, что одни люди её пишут, а другие - нет. И только во вторую очередь виноваты кодеры, которые пишут велосипеды для поиска, вместо того, чтобы взять готовый инструмент, где такие (и многие другие) нюансы уже учтены.
Вы говорите об одной стороне проблемы (практика применения), я о другой (алгоритмы обработки и их реализация).
И то, о чём вы говорите («пишут велосипеды для поиска») является следствием особо качественной поддержки в коробке (НЕТ РЕШЕНИЯ, которое можно было бы просто взять и оно бы работало ПРАВИЛЬНО, везде необходимо разбираться с нюансами, и собственный велосипед часто/обычно оказывается дешевле).
Сам алгоритм поиска на сайте РГБ - вещь загадочная и небанальная, с разными результатами (!!) на разных устройствах. Случайные находки нужно фиксировать сразу - не факт, что они "всплывут" в дальнейшем. Про всякие "труды" - Труды Томского университета или Института Крови, например - и говорить не приходиться.
Например, поиск случайно "отмеченной" книги про историю псевдонимов в газете "Известия" до ВОВ - предпринимались три раза, занял суммарно около 8-ми часов и... Книга (первоначально случайно вывалившаяся в поиске самих Известий) так и не была найдена.
Самый крайний случай - русско-немецкий медицинский журнал, издающийся в Берлине, под редакцией Н. Семашко. В НЭБе есть запись (!), в Ленинке я не могу найти никаких кодов и следов. Да ещё каталоги недоступны, в связи с ремонтом...
Вы уверены, что данная тенденция свойственна только сайту РГБ?
Применительно к примеру виѳлиотеки могу добавить вполне независимую от проблемы кодировок составляющую сопровождения больших баз данных. С отягчающим обстоятельством культуры обработки обратной связи.
И тут цифровизаторы ИВНР порылись. В том смысле, что культура работы с бумажным каталогом — НЕОБХОДИМАЯ предпосылка формирования правильного навыка работы с каталогом электронным.
Сейчас же, с специалистами профессионалами, не знакомыми с базовыми технологиями, очень скоро может получиться… Ну вы же знаете примеры ситуаций, когда воссоздание базы с аналогового прототипа оказывалось в лучшем случае дешевле корректировки структуры прогрессивного цифрового решения.
интересно, как Вам навык работы с бумажным каталогом, в котором вполне себе нормально использование неформатных комментариев на карточках, отсутствие возможности нормального поиска по регуляркам и куча всякого разного хардварного ограничения заложена байдезигн? Там главная часть навыка- это умение быстро перебирать пальцами карточки в ящике.
Для Вас, вероятно, является непостижимым Дао факт потерь информации в процессе формализации.
Да и с рег.вырами ситуация весьма интересна (в смысле описания и наличия утилит для визуализации алгоритма обработки). Хотя конечно не настолько, как с POSIX shell…
ну, теряется часть информации при формализации. и что в этом такого? зато после формализации резко поднимается доступность оставшейся информации! Вас же не пугает факт того, что при варке курицы она уваривается и часть полезных вещей теряется? потому что после варки курица становится сильно более усвояемой, нежели до. Так и с информацией похожая ситуация.
А с регэкспами ситуация интересна не из-за наличия или отсутствия утилит, а из-за запредельно высокого уровня абстракции самих регэкспов, недоступной нормальному гражданину.
и главное- Вы не ответили на вопрос, каким образом навык работы с бумажными каталогами поможет разрабам электронных? я просто умею работать и с теми, и с теми, и мне реально интересно- чего такого я не заметил, что я там в навыке работы с бумажными каталогами ценного прозевал?
Синтаксис там дурацкий, вот и все. Чтобы написать хотя бы простенькую регулярку, человеку со стороны надо поначалу очень долго разбираться, у большинства просто мотивации не хватает, а не мозгов.
Но я сомневаюсь, что регулярки - это хорошее решение для полнотекстового поиска. Стеммер существенно его упрощает, а в регекспах придется каждый раз все прописывать вручную, с неизбежными ошибками.
Дедовщина (входной барьер) встречается очень много где (и вообще по мне является скорее правилом), не только в рег-вырах (кстати, глобы Вы куда и почто потеряли?).
Ну и как обычно: критерии «хорошести» некоторого технического решения, тесты… Иде?
Так проведите опрос: кто знает, что такое регулярки, и кто готов их выучить. А стеммер, даже простейший snowball, все нормализует и приводит к основам слов безо всяких напрягов со стороны пользователя, а результат его работы еще и хорошо индексируется.
Ну да.
Постулируем аксиому о несущественности потерь… и «ничего»!
Доступность измеряем как и в чём?
И где обоснование вульгарного кармадрочерства на «рост»? Без постановки вопроса о критериях оптимума.
ЗЫ: Касаемо уровней абстракции лично мне сразу вспоминается пример как раз к обсуждаемой теме: и почему это при разработке баз данных обычно ограничивается третьей нормальной формой?..
Но этого же история цифровизации Ленинки.
Когда был "оцифрован" тематический каталог и потом был торжественно уничтожен (смеясь). А вот потом... уже плача... основной каталог теперь хранится без допуска читателей ;) что не помешало мне в нем несколько раз побывать... (речь не про общедоступные каталоги периодических изданий).
Ну это как обычно…
Причём не только в цифре.
Сначала *перелётный* минет.жымент сдвигает в сторону сокращения и без того нереальные сроки. Потом под такие вводные городят по факту *демонстрационный* прототип. Ну и наконец минет.жымент улетает, а при разгребании последствий его деятельности выясняется необходимость и незаменимость «устаревшей» и «замещённой» подсистемы… Впрочем, морские свины тоже этому в немалой степени способствуют.
Строго по руководству господина Фокса.
потому что ищет не по метрике Левенштейна, а самописным велосипедом каким-то.
Скажите пожалуйста: «метрика Левенштейна» — это имя *библиотечки*?
Или некоторого стандарта, по сути аналогичного POSIX shell?..
это название метрики, используемой для сравнения строк на степень похожести. Как "метрика L2" или Евклидова метрика для точек, только для строк. Поиск строк, наиболее близких к заданной строке в какой-либо метрике позволяет находить не только точные совпадения побуквенные, но и близкие строки, при поиске слова "елка" в наборе "Елка, ёлка, Ёлка и Илка" побуквенно вы не найдете ничего, а по метрике Левенштейна- сначала найдете Елку, потом ёлку, потом Ёлку и потом- Илку. это не библиотечка, это именно числовая метрика для сравнения строк, придуманная, кстати, советским математиком Левенштейном Владимиром Иосифовичем. Берем две строки, вычисляем для них метрику, и если метрика равна нулю- то это абсолютно одинаковые строки. А если отлична от нуля- то строки разные, и чем сильнее отлична от нуля метрика- тем более разные эти строки.
То есть как и предполагалось: речь идёт не о готовом к практическому применению решении, а о некоторой *идеальной* (!) *модели* (!!!) алгоритма.
В процессе реализации которой может всплыть немало интересного.
Это годный алгоритм для автокомплита. А для поиска совершенно не нужно, там опечатки и грамматические ошибки - это зона ответственности пользователя: а вдруг он именно это и ищет?
Тут крайне показательным примером является попытка поиска по фамилии «Высотский».
Стоит показывать все варианты, и похожие, и полностью совпадающие, но полное совпадение ранжировать выше.
Ну, в идеале. Еще можно похожие варианты предлагать автокомплитом.