Контрольная сумма выделения

akkorn · Post by **akkorn** » Sun Feb 17, 2013 3:57 pm

Пришла мысль в голову: А размер командной строки для файла не будет ли системой ограничен?

Узнал. По поводу предыдущей ошибки нужно было установить плагин Scripts (спасибо KDJ).

На счет максимального кол-ва переданных символов: Их не может быть более 32684.

Утилитку подлатал (теперь выводится кол-во преданных ей символов- полезно для анализа). http://webfile.ru/6382309

Будем дальше мучить эту идею. Можно конечно передавать вместо текста ссылку (путь) к файлу, и узнавать его сумму. Но в этом случае вначале нужно сохранять выделенный текст в файле.... Нинаю пока куда копать..

Идеи есть у кого?

akkorn · Post by **akkorn** » Sun Feb 17, 2013 7:43 pm

В общем и целом, встав сегодня утром, я понял, что ни кто за меня не сделает чего хочет моя душа.
Потому сделал я сам

Короче так:
а) Нужен установленный плагин Scripts
б) В папку с плагином (...\AkelFiles\Plugs\Scripts\) копируем файл отседова (распакуйте):
http://webfile.ru/6382600

Из плагина ToolBar запуск такой:

Code: Select all

"Узнать CRC32 выделенного текста" Call("Scripts::Main", 1, "CRC32txt.vbs", "0") Icon(38)

Так оно и мне проще (чо хотел- работает), да и вам всем мозх не выношу.

За сим откланиваюсь. Всем спасибки, все молодцы!

pp.s. Ессно, можно было заморочиться с dll, вызывать у нее ф-цию, передавать параметр, принимать и т.д. и т.д. Да ну ее!!! Здесь все наглядно, вирусов нет, бояться нечего, а значитЪ пользоваться хоть кто-то да буит.

ppp.s. Максимальное количество символов ограничивайте здравым рассудком: чем больше- тем дольше. 100 000 символов обсчитываются все-же не мгновенно (сек 3-4). Так что думать моно и нуно, а так то все работает + сохраняется контр.сумма- для сравнения с предыдущим вариантом.

На сим действительно усе )))

akkorn · Post by **akkorn** » Mon Feb 18, 2013 5:26 am

У меня уже есть небольшие доработочки... В частности у меня там был косячок с форматом новой строки- мануал по Scripts помог.
Так же все же может не закрывать пока тему- мож другие баги выловятся?

Далее. С утра, пока шел на работу, пришла мысль, что большой объем текста может обрабатываться долго. Я могу засечь время для обработки, скажем 100символов (мСек) и пересчитать нужное время (приблизительно) для обработки заданного пользователем текста. И если оно более, скажем 1-2сек, то выводить вопрос, типа "Считать все равно?".
Опять же это усложнение, и надо ли оно в реалиях наших дней??

Вопросов много, и все они требуют вашего участия, друзья

В общем, жду весточек.

p.s. И отпишитесь пожалуйста, работает ли ОНО?

pp.s. Проверить очень просто: создайте текстовый файл, включающий только тестируемые символы. И заархивируйте (WinRar, 7-zip). В этих архиваторах можно посмотреть CRC32- контрольную сумму файла. А в нашем случае, если файл текстовый- то контрольная сумма всего файла будет = контрольной сумме текста в таком файле.

Учачки!

VladSh · Post by **VladSh** » Mon Feb 18, 2013 9:31 am

akkorn
У нас есть тема "Коллекция скриптов", где каждый выкладывает свои скрипты. Если будете обновлять скрипт, то обновите его на странице; смысла разводить тут канитель нету.

akkorn · Post by **akkorn** » Mon Feb 18, 2013 11:08 am

VladSh wrote:akkorn
У нас есть тема "Коллекция скриптов", где каждый выкладывает свои скрипты. Если будете обновлять скрипт, то обновите его на странице; смысла разводить тут канитель нету.

Ок, исправился. Ссылка на пост:
viewtopic.php?p=21273#p21273

Баги поправлены.

FeyFre · Post by **FeyFre** » Mon Feb 18, 2013 3:35 pm

Пришла мысль в голову: А размер командной строки для файла не будет ли системой ограничен?

1. Если уж так захотелось написать самостоятельно, то Вы сделали правильно с точностью до наоборот. Командная строка для передачи блобов не годится(как минимум потому что это текст который будет преобразован раза 2 минимум). Если программе нужно скормить блоб, то это делается так:
а) ложим в файл, и говорим откуда брать(параметром командной стрик);
б) использование IPC:
б1) ложим в память, разделяемую память между процессами, и опять таки говорим как её найти(параметрами командной строки);
б2) создаем IPC-канал(именованный или не именованный пайп), и опять таки говорим как к нему достучаться/найти(параметрами командной строки);
в) запускаем процесс и блоб запихиваем ему в STDIN.

Метод в) очень популярный в юникс-подобных системах(и у нас это делается при помощи плагина Log), б) чаще используется в Windows, например именно так оболочка архиватора 7z 7ZFM передается собственно процессу архивирования все параметры операции. Метод а) - можно считать так: 99% реализаций в) поддерживают и а).(в общем его какраз никто не стесняется)

2. Если для вас важно просто посчитать контрольную сумму, не обязательно CRC32 то можно воспользоваться утилитами md5sum, sha1sum,sha*sum из пакета coreutils GNUWin32. Если нет, то полезно будет посмотреть как они сделаны.

akkorn · Post by **akkorn** » Mon Feb 18, 2013 6:49 pm

FeyFre wrote:
Пришла мысль в голову: А размер командной строки для файла не будет ли системой ограничен?
1. Если уж так захотелось написать самостоятельно, то Вы правильно с точностью до наоборот. Командная строка для передачи блобов не годится(как минимум потому что это текст который будет преобразован раза 2 минимум). Если программе нужно скормить блоб, то это делается так:
а) ложим в файл, и говорим откуда брать(параметром командной стрик);
б) использование IPC:
б1) ложим в память, разделяемую память между процессами, и опять таки говорим как её найти(параметрами командной строки);
б2) создаем IPC-канал(именованный или не именованный пайп), и опять таки говорим как к нему достучаться найти(параметрами командной строки);
в) запускаем процесс и блоб запихиваем ему в STDIN.

Метод в) очень популярный в юникс-подобных системах(и у нас делается при помощи плагина Log), б) чаще используется в Windows, например именно так оболочка архиватора 7z 7ZFM передается собственно процессу архивирования все параметры операции. Метод а) - можно считать так: 99% реализаций в) поддерживают и а).(в общем его какраз никто не стесняется)

2. Если для вас важно просто посчитать контрольную сумму, не обязательно CRC32 то можно воспользоваться утилитами md5sum, sha1sum,sha*sum из пакета coreutils GNUWin32. Если нет, то полезно будет посмотреть как они сделаны.

Пасяпп, полезная инфа. Не все понял, но мне понравилось)))

Fr0sT · Post by **Fr0sT** » Tue Feb 19, 2013 6:34 am

Кстати, в общем случае CRC текста != CRC файла с текстом.

akkorn · Post by **akkorn** » Tue Feb 19, 2013 8:00 am

Fr0sT wrote:Кстати, в общем случае CRC текста != CRC файла с текстом.

Не равно??? Подразумевался файл, тело которого аналогично текстоому файлу (не бинарники..).
Если не трудно, можно примерчик?

DV · Post by DV » Tue Feb 19, 2013 8:29 am

Лёгко. Внутри AkelPad (конкретнее, в элементе управления AkelEdit, который отвечает за хранение и отображение текста) весь текст хранится в формате Юникод UTF-16 LE. А в файле текст может быть в кодировке ANSI/OEM, UTF-8, UTF-16 LE, UTF-16 BE и т.д. Не говоря уже о символах перевода строки, которые в файлах могут быть "\r\n", "\r", "\n" - а внутри AkelEdit хранятся как "\r".

akkorn · Post by **akkorn** » Tue Feb 19, 2013 8:56 am

DV wrote:Лёгко. Внутри AkelPad (конкретнее, в элементе управления AkelEdit, который отвечает за хранение и отображение текста) весь текст хранится в формате Юникод UTF-16 LE. А в файле текст может быть в кодировке ANSI/OEM, UTF-8, UTF-16 LE, UTF-16 BE и т.д. Не говоря уже о символах перевода строки, которые в файлах могут быть "\r\n", "\r", "\n" - а внутри AkelEdit хранятся как "\r".

Здравствуйте.
Походу- будет не легко:
Первое- мы сравниваем текст. В той кодировке, как он в окне редактора AkelPad.
Второе- символы перевода строки (формат Win, Unix, Mac) так же учитываются.

Может, я чего-либо не до-понимаю. Однако, сколько бы я не эксперементировал- результат всего текста всегда у меня равен контрольной сумме файла. Попробуйте.
Пример тут: http://www.image123.net/s5k79y3jv0gipic.html
Пример спецом привел бинарника, а не текстового файла. Все равно все правильно.

Если у Вас получилось другое, то пришлите (выложите) такой файлик (в архиве желательно).

DV · Post by DV » Tue Feb 19, 2013 10:08 am

Создаём новый файл с любым русским текстом - например, со строкой "Жопа метр на метр". Сохраняем как UTF-8. Независимо от того, выбрали мы сохранение с BOM или без него, в обоих случаях мы получим разные контрольные суммы для файла и для текста.

akkorn · Post by **akkorn** » Tue Feb 19, 2013 1:44 pm

DV wrote:Создаём новый файл с любым русским текстом - например, со строкой "Жопа метр на метр". Сохраняем как UTF-8. Независимо от того, выбрали мы сохранение с BOM или без него, в обоих случаях мы получим разные контрольные суммы для файла и для текста.

Да, верно (чешет репу)

Но все же основную задачу выполняет (сравнение двух текстов на идентичность). А CRC считает не всегда корректно- это правда.

Вопрос: Нужно ли рыть землю или и так пойдет?

DV · Post by DV » Tue Feb 19, 2013 2:29 pm

В пределах темы - Контрольная сумма выделения - всё работает. Если бы вопрос ставился как "посчитать контрольную сумму выделенных символов в оригинальной кодировке файла", тогда пришлось бы копать глубже (сначала преобразовать выделенный текст в массив символов в исходной кодировке файла, а потом уже для полученного массива считать контрольную сумму).

akkorn · Post by **akkorn** » Tue Feb 19, 2013 4:55 pm

DV wrote:В пределах темы - Контрольная сумма выделения - всё работает. Если бы вопрос ставился как "посчитать контрольную сумму выделенных символов в оригинальной кодировке файла", тогда пришлось бы копать глубже (сначала преобразовать выделенный текст в массив символов в исходной кодировке файла, а потом уже для полученного массива считать контрольную сумму).

Верно. Сумма CRC32 была выбрана именно из-за небольшого кол-ва символов, "характеризующих" уникальность набора символов. Проще сравнить 8 символов, нежели 25, к примеру.

p.s. Еще раз привожу ссылку на свой посто в разделе "Коллекция скриптов":
viewtopic.php?p=21273#p21273