Infocatcher
Взяло(только сделайте там что-бы скрипты сервер выдавал с Content-Disposition: attachment и Content-Type: application/octet-stream раз уже сервер не желает выдавать BOM (материлось ну русские буквы пока не сохранил с кодировкой utf8)
Сделано хорошо, но попахивает велосипедом.(В Windows они все уже реализованы. Нужно только вызвать парочку API функций). Позже потестирую.
Posted: Wed Dec 15, 2010 6:42 pm
by Infocatcher
FeyFre
Боюсь, что настраиваться бесплатный хостинг не очень-то желает.
И где там BOM? Там же все скрипты в windows-1251 и отдаются сервером как «application/javascript» без указания кодировки. И никаких проблем не наблюдается – только IE спрашивает, запустить или сохранить, а не открывает.
Сделано хорошо, но попахивает велосипедом.(В Windows они все уже реализованы. Нужно только вызвать парочку API функций).
Велосипедная часть нагуглилась и накопировалась минут за десять, не больше. И ее всегда можно заменить другой реализацией.
Posted: Wed Dec 15, 2010 7:16 pm
by Deim0s
Infocatcher,
Мне интереснее понять, что должно быть на входе, и как оно должно обрабатываться.
Могу только дилетантское предположение , если такое реализуемо:
Привязать к плагину HexSel, через него получать hex-значения выделенных символов и подсчитывать. По идее, если нет каких-нибудь нюансов: или должно всё работать без привязки к кодировке символов, или я что то неправильно понимаю . Посмотрите как это работает в WinHex.
FeyFre,
Под руками есть TotalCommander? В нем есть функция вычисления хеша файла.
Ну, всего файла не интересно, вот выделенных символов, да ещё бы без привязки к кодировке - это да.
Posted: Wed Dec 15, 2010 9:08 pm
by FeyFre
Ну, всего файла не интересно, вот выделенных символов, да ещё бы без привязки к кодировке - это да.
Deim0s
WinHex, как и прочие работают не с символами а с байтами, т.е. представлением текста в данной системе. То что Вы называете символ в Вашем понятии это просто глиф - что-то нарисовано(на бумаге, на экране, у подруги на ягодице, ...). У Юникод, как у стандарта, задача вести учет всех глифов. Прямо говоря - пересчитать(грубо говоря оцифровать). Т.е. Юникод это набор индексов образов письменных знаков + некий набор правил который определяет как идентифицировать сложные символы(например гласная буква с ударением)+символы форматирования(порядка 200 штук, в том числе порядка 10 переносов строк, и столько же разновидностей "пробелов"). Например заглавная буква А имеет код(codepoint) 1040, а прописная "ё" может быть отображена в Юникоде двояко: один код 1105(CYRILLIC SMALL LETTER IO) либо два кода 1077(CYRILLIC SMALL LETTER IE)+776(COMBINING DIAERESIS) (буква "е"+"̈"). Таких кодов состоянием на сегодня насчитывается не мало не много 1114111 штук(сюда входят все дальневосточные иероглифы, егоипетские пиктограммы, шумерское письмо и пр. + туда пытаются принять знаки искусственных языков таких как Эльфийские(Толкиена), Клингонский(Звездные войны)). Это касалось чисто человеческого восприятия письменности.
Что касается машинного(компьютерного, цифрового):
Так сложилось исторически(а сейчас для компактности) текстовую информацию стараются сохранять так, что-бы она занимали минимум места и удобно обрабатывалась. Правила соответствия представления символа в системе коду в Юникод и есть кодировками. Кодировка определяет какими байтами хранить тот или иной символ или знак. Так что Ваше "да ещё бы без привязки к кодировке" это значит в коды символов из Юникод(а это три байта) и аж потом натравить на них хеш-функцию. Только я уже приводил пример, как символ можно представить двояко(а есть и 4 способами). Да и эти три байта в памяти можно положить двумя способами. Вот и получится, что символ один, а в зависимости от представления хеш будет разный. Потому следует говорить не о хеше текста, а о хеше последовательности байт, которая представляет текст в системе по какому-то закону(кодировке).
Posted: Wed Dec 15, 2010 10:44 pm
by Deim0s
FeyFre,
Много букв...
Извиняюсь, но не понял к чему?
Хотелка, сообственно и состоит в том, чтобы получать хеш выделенного по hex-значению, вне зависимости от отображаемых символов (будь то даже не печатаемые символы и т.п.).
Deim0s писал:
...через него получать hex-значения выделенных символов и подсчитывать.
В cp1251:
Hex-последовательность: A8 EB EA E8 20 EF E0 EB EA E8 2C 20 EB E5 F1 20 E3 F3 F1 F2 EE E9 21
Хеш SHA1: 9D3A0FDFACFFB5BCD7CA4A7F55C5048D344D3274
В cp866:
Hex-последовательность: F0 AB AA A8 20 AF A0 AB AA A8 2C 20 AB A5 E1 20 A3 E3 E1 E2 AE A9 21
Хеш SHA1: 4364736A76ECD5AD08A52A77C101BB81A9C59682
В UTF-8:
Hex-последовательность: D0 81 D0 BB D0 BA D0 B8 20 D0 BF D0 B0 D0 BB D0 BA D0 B8 2C 20 D0 BB D0 B5 D1 81 20 D0 B3 D1 83 D1 81 D1 82 D0 BE D0 B9 21
Хеш SHA1: 40A9391AB31730EF936DD10082BA0D41C3E7FFFC
И так далее, вопрос был: можно ли это организовать средствами скрипт + AkelPad.
Posted: Wed Dec 15, 2010 11:00 pm
by FeyFre
получать hex-значения выделенных символов и подсчитывать.
hex-значения будут в указанной в настройках плагина кодировке. Другая кодировка - другие hex-значения другой хеш, но символы те же.
Posted: Thu Dec 16, 2010 12:54 am
by Deim0s
FeyFre,
hex-значения будут в указанной в настройках плагина кодировке. Другая кодировка - другие hex-значения другой хеш, но символы те же.
В сохранённом документе, hex-значения неизменны - что естественно, не зависимо в какой кодировке его открывать. Меняться, как раз, в зависимости от кодировки, будут только отображаемые символы. В не сохранённом документе, hex-значения будут как раз принадлежать текущей кодировке символов, в которой открыт документ. Или мы не поняли друг друга, но задумка как раз отображать реальный (исходный) хэш выделенного в документе, а не то что отображается в символах.
Posted: Thu Dec 16, 2010 1:10 am
by Infocatcher
openFileIn.js
Добавлен запуск программ, для которых указано выполнение от имени администратора (Windows Vista/7).
Ранее в этом случае выдавалась ошибка:
Ошибка: Запрошенная операция требует повышения.
Источник: WshShell.Exec
Posted: Thu Dec 16, 2010 8:58 am
by FeyFre
реальный (исходный) хэш выделенного в документе
В редакторе весь текст хранится в UCS2(2-4 байта на символ), НЕ ЗАВИСИМО ОТ ТОГО в какой кодировке текст лежал в файле. И хеш, вычисленный по нему, не будет обязательно совпадать с хешем, который Вы посчитаете бинарным редактором.(Для тех, кто не хочет понять: в файле лежат числа 0xE9 0xF6 0xF3 0xEA 0xE5 0xED а в памяти лежат 0x04 0x39 0x04 0x46 0x04 0x43 0x04 0x3A 0x04 0x35 0x04 0x3D - одни и те же буквы, один и тот же текст, хеш - разный.)
Posted: Thu Dec 16, 2010 1:00 pm
by Fr0sT
Infocatcher wrote:нужен конвертер из UTF-16
Да, см. у меня в Base64, вроде бы нормально работает.
Posted: Thu Dec 16, 2010 1:39 pm
by Deim0s
FeyFre,
Вы второй раз пишите прописные истины, но не ответ на сам вопрос:
Можно ли, брать выдаваемую плагином HexSel реальную последовательность байт выделенных в документе символов и по ней высчитывать контрольные суммы? Если нет - так нет, бог с ним.
Posted: Thu Dec 16, 2010 3:26 pm
by FeyFre
Deim0s
Я Вам ответил "hex-значения будут в указанной в настройках плагина кодировке." Я же Вам повторяю "прописные истины" потому что Вы их не поняли судя по Вашему "Меняться, как раз, в зависимости от кодировки, будут только отображаемые символы.". А когда Вы что-то просите понимая это по своему, а мы понимаем по своему, то так мы не договоримся ни к чему хорошему.
Posted: Thu Dec 16, 2010 5:01 pm
by Fr0sT
Deim0s
"реальная последовательность байт" перестает существовать для Акеля сразу после загрузки и перегонки текста в другую кодировку.
Posted: Thu Dec 16, 2010 5:05 pm
by Deim0s
FeyFre,
Я Вам ответил "hex-значения будут в указанной в настройках плагина кодировке."
Есть же флаг "Автоматически" - работает исправно.
Fr0sT,
Разговор: если брать "реальную последовательность байт" из HexSel.
Posted: Thu Dec 16, 2010 5:55 pm
by Infocatcher
Deim0s wrote:реальную последовательность байт выделенных в документе символов
Вроде бы, в любом случае придется приводить текст к кодировке файла.
goToLongestLine.js
Добавлен диалог (для перехода можно использовать клавиши PageUp/PageDown) и дополнительные параметры запуска, улучшено определение выхода на границу файла, добавлено временно́е ограничение для больших файлов.
, если такое реализуемо: