Как сделать нечеткий поиск строки без тяжелой базы данных?
В вашем скрипте есть пара ошибок.
- Браузер анализирует ваш HTML-код сверху вниз. Это означает, что он обрабатывает раздел
<head>до<body>.
Часть JavaScript расположена внутри секции <head> и помещена между открывающим тегом <script type="text/javascript"> и закрывающим тегом </script>. Если вы внимательно посмотрите на свой код JavaScript, то обнаружите, что эти два утверждения:
document.getElementById("totalTip").style.display = "none";
document.getElementById("each").style.display = "none";
Они не входят в сферу применения функции calculateTip () {} и обработчик .onclick = function () {} , поэтому браузер пытается выполнить его. К сожалению это не может! Два элемента, которыми он пытается манипулировать - totalTip & amp; каждый - пока недоступен, так как браузер еще не дошел до раздела <body>, где он фактически определен. Итак, у вас есть два варианта.
A
Переместить весь блок JavaScript, включая <script type="text/javascript"> и </script> и все, что между ними, в раздел body, чуть выше закрывающего тега </body>, почти на конец файла.
B
Возможно, эти два оператора принадлежат обработчику .onclick = function () {} . Переместите его туда как:
document.getElementById("calculate").onclick = function() {
document.getElementById("totalTip").style.display = "none";
document.getElementById("each").style.display = "none";
calculateTip();
};
- Измените эту строку
if billAmt( === "" || serviceQual == 0) {
на эту
if (billAMT == "" || serviceQual == 0) { [ 1129]
- Javascript чувствителен к регистру - это означает, что счет Amt и счет AMT не совпадают. Измените все ссылки на billAmt или billAMT
- , здесь есть небольшая опечатка:
var billAMT = document.getElementBy Id ("billamount"). Value;
5 ответов
Nucular имеет полнотекстовый поиск, но не поддерживает совпадения с ошибками из коробки. Вы можете попробовать добавить дополнительное поле к каждой записи который индексирует SOUNDEX перевод терминов, а затем поиск с использованием перевода soundex пользовательского ввода. Я действительно не знаю, насколько хорошо это будет работать ...
Взгляните на advas http://advas.sourceforge.net/news.php , в котором есть хорошая демонстрация, сравнивающая различные soundex- похожие методы:
advas/examples Aaron$ python phonetic_algorithms.py
soundex metaphone nyiis caverphone
====================================================================================================
schmidt : S253 sxmtt sssnad SKMT111111
schmid : S253 sxmt sssnad SKMT111111
schmitt : S253 sxmt sssnatt SKMT111111
smith : S530 sm0h snatt SMT1111111
smythe : S530 smy0h snatt SMT1111111
schmied : S253 sxmt sssnaad SKMT111111
mayer : M600 myr naaar MA11111111
meier : M600 mr naaar MA11111111
....
Я не знаю, подходит ли какой-нибудь из них для вашего неназванного языка ...
С реализацией SOUNDEX вы получите слишком много ложных срабатываний. Существует только 26 000 (максимум) возможных кодов SOUNDEX.
Хотя алгоритм Metaphone был разработан для английских фамилий, он довольно хорошо работает для орфографических ошибок; Я использовал это однажды в локаторе веток, и это было довольно успешно.
Добавьте поле с переводом «Метафон» и сопоставьте его, если точное совпадение не найдено. Вы по-прежнему будете получать ложные срабатывания, но меньше, чем с другими алгоритмами.
Обычный способ вычисления расстояния редактирования между двумя строками - довольно дорогой алгоритм (если я правильно помню, его сложность по времени является квадратичной). Возможно, если бы вы использовали другую метрику сходства строк, ваша проблема исчезла бы.
Один из моих любимых методов нечеткого сопоставления строк - это сопоставление триграмм . Сравнение двух строк с использованием этого метода имеет линейную сложность по времени, которая намного лучше, чем упомянутое расстояние редактирования. Вы можете найти мою реализацию Python на Github . Для этого есть также модуль contrib для PostgreSQL . Не должно быть слишком сложно адаптировать его для работы с SQLite3.
Sybase SQL Anywhere имеет бесплатную веб-версию / версию для разработчиков и поставляется с полнотекстовая индексация / поиск и оператор FUZZY (и некоторые ограничения реализации).
Цитата из документации:
Specifying 'FUZZY "500 main street"' is equivalent to
'500 OR mai OR ain OR str OR tre OR ree OR eet'.
Другим подходом было бы использование оценки при полнотекстовом поиске.
По-видимому, единственный способ быстро проводить нечеткие сравнения - это делать их меньше;)
Вместо того, чтобы писать еще один поиск по n-граммам или улучшать поиск в Whoosh, мы теперь сохраняем индекс слов , получить все записи, содержащие хотя бы одно (правильно написанное) слово, общее с запросом, и использовать diffflib для их ранжирования. В этом случае работает достаточно хорошо.