Автоматическая проверка и исправление орфографии

«Земля - тебе пуховик» произнесла T9 на могиле создателя. Оно точно в таком виде тебе надо?

Ага. Смысл совершенно не важен, там итак полная ахинея. Важна только корректность с точки зрения спеллчекера. Поэтому и ищу автоматизацию. Даже Changeall в спеллчекере ОО/ворда нажимать уйдет очень много времени из-за текста в 100000 слов.

yes 0 | hunspell -c filename.txt

Будет всё исправлять на 1-ый вариант по умолчанию. Но вряд ли результат устроит, т. к. качество может даже ухудшиться.

$ cat test_text.txt
Я преехал из диревни в этот шумный гарадок!
Очинь трудна разабратся где тут запад где васток.
Нибаскрёбы нибаскрёбы а я малинький такой.
То мни страшна то мни грусна то тиряю свой пакой.
$ yes 0 | hunspell -c test_text.txt
$ cat test_text.txt
Я переехал из древни в этот шумный оградок!
Очинить трудна забраться где тут запад где ваток.
Небоскрёбы небоскрёбы а я маленький такой.
То мни страшна то мни грустна то смиряю свой па кой.

Спасибо, это практически что надо. Но как только встречает слово к которому у него нет вариантов, то всё встает и ждет моей команды.

встречает слово к которому у него нет вариантов, то всё встает

Тогда можно попробовать накостылить нечто подобное:

(while [ true ]; do i=0; while [ $i -ne 1000 ]; do echo 0; let i+=1; done; echo ' '; done) | hunspell test_text.txt > /dev/null

где внутренний цикл по $i должен иметь итераций не меньше, чем будет замен (больше - можно, так что границу цикла можно даже определять по размеру входного файла).

Процесс bash из скобок передаёт на вход hunspell очень много 0, а потом пробел, чтоб пропустить слово, и снова нули. Костыль, конечно, но...

границу цикла можно даже определять по размеру входного файла

Но лучше по числу слов в файле, подсчитанных wc -w, а если есть уверенность, что число замен до первого слова без вариантов или до конца файла не превысит некий процент от общего числа слов, то определять границу по этому проценту

expr `wc -w < test_text.txt` '*' 11 '/' 100

Спасибо, очень круто помог. Но это забавно конечно.

15812  hunspell     55.9  03:22.69 2/1   1    29    7408K  0B     0B     15811 14853 running  *0[1]
15811  bash         98.4  05:57.84 1/1   0    8     372K   0B     0B     15811 14853 running  *0[1]

Ещё момент, что когда вариантов больше 10, то hunspell ждем 00, а не 0

00: ts
 01: nets
 02: nits
 03: ants
 04: nuts
 05: its
 06: nos
 07: cts
 08: nus
 09: uts
 10: pts
 11: nth
 12: Ats
 13: Hts

Ещё момент, что когда вариантов больше 10, то hunspell ждем 00, а не 0

Да хоть 00000. Меняем в echo 0 на 00, 000, 0000, ... Или просто используем «echo -n 0», чтоб подавить перевод строки.

А что за слово такое даёт все эти 13 вариантов, если не секрет?

Конечно не секрет. Их много очень в больших текстах.

cally

00: call
 01: ally
 02: calmly
 03: calls
 04: sally
 05: calla
 06: rally
 07: tally
 08: colly
 09: dally
 10: cully
 11: pally
 12: bally
 13: wally

gers

 00: Gers
 01: hers
 02: gees
 03: gets
 04: ger
 05: gears
 06: goers
 07: germs
 08: ergs
 09: gars
 10: gens
 11: gels
 12: germ
 13: gems

powe

00: pow
 01: owe
 02: power
 03: pose
 04: pone
 05: pore
 06: pole
 07: pome
 08: pope
 09: poke
 10: Rowe
 11: Lowe
 12: Howe
 13: p owe

Понял. Интересно, что в русских словарях по подобным русским шаблонам вариантов гораздо меньше. :-)

Всё равно странный выхлоп.

Прогоняю

nickpo$ (while [ true ]; do i=0; while [ $i -ne 14419 ]; do echo 0; let i+=1; done; echo ' '; done) | hunspell /Users/nickpo/Desktop/Blood\ of\ the\ Lords.txt   > /dev/null

Потом делаю

nickpo$ hunspell -c /Users/nickpo/Desktop/Blood\ of\ the\ Lords.txt[/bash]

Сначала всё ок, идут слова без замены, а потом бам

you.involunta

 0: involuntary
 1: involuntarily
 2: voluntarist

Hunspell 1.6.1

Вот подопытный файл http://rgho.st/private/7vYSBsYt2/97ea73e87af2901035e2979d96dda58b

То ли на маке ханспелл криво работает, то ли скрипт.

Попробуй у себя, пожалуйста.

Че т вспомнилось:

http://habrahabr.net/geek/290335/

В июле 2016 года я прочитал статью на GT о том, как мошенники зарабатывают на Amazon Kindle Unlimited. В августе я начал пытаться реализовать по описанному алгоритму, но оказалось, что всё совсем не так радужно, как было описано, да и к тому же изложенные действия в некоторых пунктах были абсолютно не прозрачны (например, пункт про несколько версий книги).

За месяц тестирования, получив блокировку одного аккаунта, на котором я сразу попытался «сгенерировать» ~$10.000, удалось более или менее разобраться. Впоследствии тестирование продолжалось, позволяя мне зарабатывать ~$8.000 в месяц, на тестирование я тратил около 1 часа в день (и далеко не каждый день).

Забавно, чего только не придумают.

Мне же нужно для прохождения американского аналога нашего антиплагиат. Работы, лабораторные, эссе нужно загрузить до 20 июля на сервер, где антиплагиат их проверит. А человек их проверит только в сентябре.

Работы мягко говоря не очень готовы. Поэтому как выход я нашел загрузить туда херню, а потом в сентябре лично разрулить уже тет-а-тет, списав всё на ошибку при загрузке.

Раньше было проще, а теперь их антиплагиат очень поумнел и сейчас все студенты горят.

Такие дела.

Если идти в криминал, то думаю можно и больше зарабатывать. Все кто хотел - уже там.

Но зачем?

Если до 20 июля не загрузить, то работы будут не сданы и уже не спишешь всё на «сбой в программе на вашей стороне».

Вот подопытный файл http://rgho.st/private/7vYSBsYt2/97ea73e87af2901035e2979d96dda58b

Попробуй у себя, пожалуйста.

Попробовал. И автоматически, и вручную. Действительно, некоторые слова он, похоже, предлагает исправить, но не правит. Например, я заметил, что он предлагает заменить слова remembe (0 - remember) и rring (00 - ring). Но при нажатии на 0 и 00 соответственно и выходе с помощью x (как бы с сохранением), время модификации файла меняется, а содержимое - нет.

А другие слова меняет на самом деле.

В общем, как-то непонятно работает.

Hunspell 1.6.1

У меня в Debian oldstable 1.3.3

International Ispell Version 3.2.06 (but really Hunspell 1.3.3)

Работы мягко говоря не очень готовы. Поэтому как выход я нашел загрузить туда херню, а потом в сентябре лично разрулить уже тет-а-тет, списав всё на ошибку при загрузке.

А зачем орфографию проверять? Что, если антиплагиат найдёт ошибку, то не пропустит? А что, если у него другие словари, и он её таки найдёт, даже если у тебя её как бы не будет?

Kosh написал:

http://habrahabr.net/geek/290335/
Впоследствии тестирование продолжалось, позволяя мне зарабатывать ~$8.000 в месяц

Эх, жалко, что после публикации на Хабре, эти методы скорее всего уже не работают!

http://habrahabr.net/geek/290335/
.net

Что это? Я знаю только habrahabr.ru.

.net

Что это? Я знаю только habrahabr.ru.

Да. Не обратил внимания на домен. :-) Ну, раз статья не на хабре, а на каком-то левом малоизвестном сайте, значит есть шанс, что способ ещё работает. Если, конечно, он работал изначально на Амазоне, а не в фантазиях автора. :-)

Попробовал. И автоматически, и вручную. Действительно, некоторые слова он, похоже, предлагает исправить, но не правит. Например, я заметил, что он предлагает заменить слова remembe (0 - remember) и rring (00 - ring). Но при нажатии на 0 и 00 соответственно и выходе с помощью x (как бы с сохранением), время модификации файла меняется, а содержимое - нет.

Кажется, я понял, в чём дело. Ему не нравятся слишком длинные строки. Он начинает путаться. Например, remembe и rring, на которые я обратил внимание, на самом деле являются одним словом rememberring, но hunspell почему-то сначала его разделяет, а потом не записывает.

Соответственно, следующий вариант на данном файле работает:

sed -ri 's/\r/\n/g;s/(([ \t]+[^ \t]+){7,7})/\1\n/g' "Blood of the Lords.txt"

for it in 1 2; do (while [ true ]; do i=0; while [ $i -ne 500 ]; do echo -n 0; let i+=1; done; echo ' '; done) | hunspell -d en_US "Blood of the Lords.txt"; done

После этого остаются только русские слова, для которых в словаре en_US нет вариантов.

Первая строчка запускает sed в режиме расширенных регулярных выражений (опция -r) и замены входного файла (опция -i, только не надо менять порядок опций, т. к. -ir обозначает только -i и прибавляет к выходному файлу суффикс r). Далее идут 2 команды замены: 1-ая заменяет все возвраты кареток, обозначающие на маках конец строки, на нормальные переводы строки, понятные всем нормальным юникс-утилитам. Изначально файл содержит одну длиннющую строку (правда, как на маках, я не знаю, не исключено, что там все свободные утилиты, включая hunspell, правильно распознают \r, но полагаться на это я бы не стал). Но этого мало. Всё равно строки слишком длинные, хоть на них hunspell работает уже лучше. Поэтому 2-ая команда sed

s/(([ \t]+[^ \t]+){7,7})/\1\n/g

разбивает строки длиной более 7 слов (может, можно было бы сделать и подлиннее, - не пробовал).

Во второй строке (собственно, обработка) поначалу у меня внутренний цикл while был до 41, и hunspell не обрабатывал файл с 1-ого раза, поэтому добавил внешний цикл for с 2 итерациями. Но потом, когда вместо 41 я поставил 500, всё отработало с 1-ого раза, и во внешнем цикле нужды больше нет. Но для других файлов я бы его всё-таки на всякий случай оставил: вдруг где-то и 500 не хватит? Напомню, что число итераций в while идентично вводу такого же количества 0 до 1-ого пробела. Если в каком-то файле окажется более 501 замены, и у всех будут варианты, на что заменить, то при while [ $i -ne 500 ] 502-ая замена будет пропущена. Внешний цикл способен это исправить.

Ура! Я всегда знал, что даже у багов должна быть своя логика, и моё предчувствие не обмануло меня!

ИМХО ничего не выйдет, там не дураки сидят. Но можешь попробовать scigen-ом нагенерировать.

http://habrahabr.net/geek/290335/
.net

Что это? Я знаю только habrahabr.ru.

Спасибо большое! Ты крутой!

https://geektimes.ru/post/290335/ 24 тысячи просмотров и куча репостов. Такие схемы сливают только когда они умирают.

Kosh До этого я загружал вообще полную чепуху и подходил к преподавателям и косил, что сбой при загрузке произошел. Прокатывало.

Потом прикрутили антиплагит и стало сложнее, потом прикрутили проверку орфографии и ещё подкрутили антиплагиат. В общем, стало очень сложно, но, думаю, что прокатит и опять.

В любом случае, до 20 все работы сделать я никак не успею. Поэтому мне нужно только грязные методы.

У меня есть практически готовые работы на русском. Я прогнал их переводчиком, он перевел почему-то с ошибками, плюс дофига не переведенных на английский спец терминов.

Антиплагиат принял из 10 работ только 1, которая была без ошибок, но вручную исправлять такой объем очень тяжело и долго, а всё время сжирает работа.

Период корчевателей уже пройден, за них наказывают.

https://geektimes.ru/post/290335/ 24 тысячи просмотров и куча репостов.

А, так значит на хабра.нет была копипаста. Тогда да, шансов воспользоваться нет. Впрочем, может оно и к лучшему, остаться бедным, но свободным. :-)

Такие схемы сливают только когда они умирают.

Тоже верно. Хотя и после слива разные хацкеры зачастую успешно продолжают юзать, пользуясь нерасторопностью админов. Взять хотя бы тот же недавний wannacry. Но это уже другая история.

А может другой переводчик попробовать?

Например?

Так я не знаю, какой ты пробовал.

Промтом переводил.

Есть ли возможность автоматически сделать в нём проверку орфографии и автоматически же откорректировать?

Вот логический итог абсолютной автоматизации: Вы что - и конфеты есть за меня будете?!

В ручную не предлагать

Да, чувак, исправлять тут есть что.

Качество исправления орфографии не столь важно.

Н - НЕНАВИСТЬ.

Полуавтомат (подсветка ошибок в офисных пакетах) уже не катит?

автоматически сделать в нём проверку орфографии и автоматически же откорректировать

Качество исправления орфографии не столь важно

Промтом переводил

Срочно требуется самолёт, боеприпасы и пластинка Вагнера.