LINUX.ORG.RU

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

 


0

2

У меня есть документ .txt, .rtf с текстом на английском языке. Есть ли возможность автоматически сделать в нём проверку орфографии и автоматически же откорректировать?

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


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

Majestio
()
Ответ на: комментарий от Majestio

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

nickpo
() автор топика
yes 0 | hunspell -c filename.txt

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

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

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

nickpo
() автор топика
Ответ на: комментарий от nickpo

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

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

(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, а потом пробел, чтоб пропустить слово, и снова нули. Костыль, конечно, но...

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

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

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

expr `wc -w < test_text.txt` '*' 11 '/' 100
для варианта 10% с отбрасыванием дробной части. Иначе очень долго может работать на большом количестве больших файлов с большим числом слов без вариантов замены.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

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

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]

nickpo
() автор топика
Ответ на: комментарий от aureliano15

Ещё момент, что когда вариантов больше 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
nickpo
() автор топика
Ответ на: комментарий от nickpo

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

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

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

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

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

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
() автор топика
Ответ на: комментарий от aureliano15

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

Прогоняю

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

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

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

nickpo
() автор топика

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

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

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

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

Kosh
()
Ответ на: комментарий от Kosh

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

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

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

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

Такие дела.

nickpo
() автор топика
Ответ на: комментарий от Kosh

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

nickpo
() автор топика
Ответ на: комментарий от te111011010

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

nickpo
() автор топика
Ответ на: комментарий от nickpo

Вот подопытный файл 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 в месяц

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

aureliano15 ★★
()
Ответ на: комментарий от tm4

.net

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

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

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

Попробовал. И автоматически, и вручную. Действительно, некоторые слова он, похоже, предлагает исправить, но не правит. Например, я заметил, что он предлагает заменить слова 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-ая замена будет пропущена. Внешний цикл способен это исправить.

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

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

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

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

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

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

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

nickpo
() автор топика
Ответ на: комментарий от te111011010

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

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

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

nickpo
() автор топика
Ответ на: комментарий от nickpo

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

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

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

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

aureliano15 ★★
()

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

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

anonymous
()

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

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

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

anonymous
()

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.