Объем файла порядка 700 метров и более.
Задача:
1. Разрезать на заданные(произвольного объёма, например пополам или в определённой точке) фрагменты.
2. Редактировать "как есть".

Не хочется сползать к прогам типа "мультиэдит". Да и не уверен, что она переварит такой файл.

ValkII
1.Total Commander - "разбить файл".
2. Как есть редактирует Far, вернее текстовый редактор в нем. Любого размера вроде.

spliner

Любого размера вроде.
вот именно "вроде".

А "Тотал" не бьёт на заданные фрагменты......

ValkII. Ага - у всех бьет, а у вас не бьет.
Там надо ручками прописать нужный размер кусков, а не выбирать из списка.
С Far-ом советую попробовать. Чтоб "не вроде" было.

ValkII
только что попробовал из фара открыть 1.7Гб файл на редактирование. Открыть-то он его открыл, но медленно, поэтому лучше разбить.

ValkII
Как это не бьет? Только что проверил на ТС версии 5.51 - настрогал в килобайтную лапшу файл. Чудненько порезало, красота!

Там просто нюанс - размер надо указывать в байтах :) И все получится. Задаешь 1000 - оно и крошит файлики в 1000 байт аккуратно...

spliner
у всех бьет, а у вас не бьет
Бьёт как у всех - по размеру по другому Wcmd не умеет, к сожалению, а нужно в определённой точке - на заданной строке.

за идею с ФАР - спасибо

Отдельно спасибо speedboy за эксперимент.

не приходилось раньше пользоваться ФАРовским-редактором
правда у меня ФАР читает файл больше минуты да и интерфейс там далёк от совершенства....
пожалуй использую в случае безъисходки...

John Z ещё не настолько в тупике, чтоб пересчитывать заданную позицию в файле - в байты....

PS^ по ходу пьессы сообразил, есть такая замечательная штука - WinHex.

Всем спасибо.

В заданной строке значит ... :

А самому мелкую прогу для данной конкретной задачи разве так трудно написать - ведь не более 100 строк кода займет :)

unknown000
WinHex - вполне достаточно....
Просто сначала тормознул чем "это" колбасить.....

.....ведь не более 100 строк кода займет
Стоит-ли по любому поводу хвататься за Борланд и т.д.?
Из пушки по воробьям..... ©
100 строк кода - некоторое время... плюс возможно отладка....
Не столь трудно - сколь бессмысленно.

Было совершенно ясно, что существует масса готового софта для решения вопроса....

To All

Кстати(проверил ради интереса): Не советую пользоваться для подобных манипуляций ФАР-редактором.... ну если только совсем времени не жалко.....

В итоге, наиболее эффективной оказалась связка: Tcmd(нарезка "заготовок")+WinHex(правка, независимо от размера и быстро).

Удачи всем!

Я в таких случаях пользуюсь WORD'ом, а в особо тяжёлых - WORD 5.0 for DOS.

А разве нельзя открыть файл в Ворде, выделять нужные части текста, вырезать их в буфер обмена, и сохранять как новый файл? Или Ворд такую махину не откроет?

DimaL
valera13
Даже и не знаю.....
Может это?
Это от Word2000

ValkII , извини, хотелось помочь, но это было бы слишком просто, конечно ты пробовал так. Если бы у меня был такой здоровенный файл я бы таких "советов" не давал. Надеюсь найдешь решение.

Не знаю как 700 метров, но метров по 10-15 работает нормально TextEd 1.85a. Есть и более свежие, но мне именно этот нравится.
Ну, и Word пока ещё никто не отменял!

ValkII

Я в 1994 году такую проблему решал "Лексиконом"

Только там надо было не только порезать файл (слив из БД), но и поделить его на страницы в соответствии с содержанием, а потом распечатать на матричном принтере, разрезать на карточки и рассортировать... Файл был около 100 мб. Мы справились месяца за четыре круглосуточной работы. Умерли три принтера...

Alex Puff


Бедные... принтеры!

Alex Puff
Я в 1994 году такую проблему решал "Лексиконом"
Тогда ещё "гиговые" проблемы не маячили....

А нам пришлось в 98-м распечатать 6000 ценников.... по 24 на страницу, тоже на матрицах и многие не по одному разу.....

А че это за текстовый файл на 700 метров? Война и Мир по моему 3 метра занимает...

А чем WinRAR не подходит?

andrey
а WInRAR тут каким боком?
и как после него файлы редактировать?

andrey
А чем WinRAR не подходит?

Эээ... Ну скажем: Назначением, функциями.....
А каким боком к такой задаче архиватор?

ValkII
1. Разрезать на заданные(произвольного объёма, например пополам или в определённой точке) фрагменты.
С произвольным объемом понятно - TCMD и прочие.
С заданной точкой ака номер строки - только прогу ваять... длины строк разные, понимаешь... впрочем прога плевая, и даже отлаживать не придется... вот скажем на VBA шинковка на куски по 10 тыс. строк

2. Редактировать "как есть".
а вот тут непонятка - bin-редактирование (запросто) или txt-редактирование (тяжело)?

Текстовых редакторов для работы с такими монстрами не припоминаю...

To All
Вопроса уже нет! Есть только "некоторые рассуждения на тему"......
Проблема решена(в моём случае) ещё до сообщения №6..............

Akina
Рад видеть людей, которым не надо объяснять: Откуда такие файлы?

С заданной точкой ака номер строки - только прогу ваять... длины строк разные, понимаешь... впрочем прога плевая, и даже отлаживать не придется... вот скажем на VBA шинковка на куски по 10 тыс. строк
Спасибо за шаблон кстати, многим может пригодиться....
Нашинковать - не проблема..... Если исходить из конкретики(VBA и данной задачи в моём случае) - придется вводить туда "Файнд" или другие операторы и соответственно использовать другой алгоритм...
Идея с VBA - особенно актуальна в связи с дальнейшим импортом в "Аксесс"... Просто файл исходный немного "поправить" надо было.....

bin-редактирование (запросто) или txt-редактирование (тяжело)?
В WinHex эти грани весьма "размыты".

To All
Наблюдения:
(среда - 98SE, оперативка - 512)
1. Фар-редактор - тормозит безбожно. Границу "тормозов" не проверял(извините, интерфейс удручает).....
2. SkimEdit - не смотря на заявленные на сайте 2 гига - не смог вывести на экран результат..... (ожидание около 10 мин)
При работе с файлами около 100 метров - глючит.....
3. TextEdit - Почти полный аналог(интерфейс покрассимше) №2.....
4. Bred - Весьма проворно выдаёт "ошибка в среде". При работе с файлами до 100 метров(реальную границу не искал) - работает без вопросов.
5. AkelPad - выдает на экран результат, при попытке редактировать - отваливается(чёта там невозможно)... При работе до 100 метров - аналог "Bred".

6. Вне конкурса - WinHex:
Реального текстового режима нет(нельзя рассматривать как "текстовый редактор"). НО!
Вскрывает файл вне зависимости от размера, позволяет редактировать "всё и вся", при реальных операциях с файлом - задержка пропорциональна размеру файла(весьма небольшая).

Всем успехов!

ValkII
Я понимаю, что вопрос уже решен, но может это будет получше:
Есть еще редактор Vega. Работает с большими файлами, написано - до 2 Гб. Занимает жалких 8Кб в архиве. Интерфейс получше notepad'а.
http://maxtkhor.narod.ru/Soft/vega.zip

ValkII
В WinHex эти грани весьма "размыты".
нет. bin-редактирование - чистый overwrite (как diskedit или hiew), а txt-редактирование предполагает вставку-удаление байтов.

Добавление от 08.04.2005 09:07:

ValkII
Идея с VBA - особенно актуальна в связи с дальнейшим импортом в "Аксесс"... Просто файл исходный немного "поправить" надо было.....
я бы после импорта правил (собсно) так всегда и делаю.

не надо объяснять: Откуда такие файлы?
именно так - импорт в Аксесс - смотрю и анализирую логи. и 700 метров мне неудивительны...

DemonFromJupiter
В принципе SkimEdit и Vega в некотором роде "родственники" http://skimsoft.com/?l=ru.
Подозревал, что "движок" у них общий, потому и не проверял...
Не всё так просто оказалось!
Vega - действительно вскрывает и полноценно правит такие файлы, по крайней мере размером до 1 гига...
При этом весьма умеренно свопится, в отличии от SkimEdit и других....

Akina

чистый overwrite - всего лишь вопрос прямого доступа к диску.....

И каким редактором будем тогда считать WinHex ?

WinHex заточен под бинарную правку. И такой например косвенный признак как дата изменения - стандартная опция....
Но это не мешает вставить или удалить байтик-другой....

я бы после импорта правил (собсно) так всегда и делаю.
Аксесс весьма чувствителен к организации данных при импорте, не любит отклонений. Часть информации при этом можно получить в виде Егог-тэйбл. Оно нам надо?


именно так - импорт в Аксесс - смотрю и анализирую логи. и 700 метров мне неудивительны...
без комментариев....

ValkII
Но это не мешает вставить или удалить байтик-другой....
Если редактирование сопровождается (или может) сдвижкой - это ТХТ-редактирование. Т.е. удалив или вставив байт в начале, вынужден переписывать весь файл. А BIN-редактирование - это изменение блока безотносительно к другим (сектора, кластера) - хаписываем только измененный блок.

Добавление от 08.04.2005 17:43:

ValkII
Аксесс весьма чувствителен к организации данных при импорте, не любит отклонений.
Импорт начинается просто - каждая строка в одно поле типа стринг, а далее парсим программно.

Akina
Насчёт BIN:
Не буду спорить. Это скорее вопрос восприятия....
Есть прямая правка на диске без существенной привязки к неким объектам, есть работа с некоторой организованной структурой в виде файла.....
На мой взляд граница здесь, а лингво-юридическое толкование терминов второстепенно....

Импорт начинается просто - каждая строка в одно поле типа стринг, а далее парсим программно.
Это вариант для серьёзных неоднородностей. Согласен, не плохой.

Когда сбой серийный и легко устранимый (возникает например с лишними/двойными пробелами) проще локализовать заранее и втянуть готовую таблицу, "малой кровью" тэсэзэть....
1. Тянем "как есть".
2. Оцениваем навскидку характер ошибок.
3. Принимаем решение.... (в данном случае предкоррекция)

Ну не нраицца мне под каждую ситуацию плагин лепить. Это имеет смысл только при рутине или невозможности обойтись готовыми средствами.

разбить, как было предложенно выше, ФАРом на приемлимые куски. А потом любым текстовым редактором из кусков слепить требуемые фрагменты.

ValkII
Это вариант для серьёзных неоднородностей. Согласен, не плохой.
Иногда - единственно возможный. Скажем логи IP-трафика - для разных типов пакетов (допустим TCP и ICMP) структура строк лога (после даты-времени) радикально различается.

Удобно тем, что обработка "сырого импорта" пишется для каждого типа файла ОДИН РАЗ. Потом просто отслеживаются исключения и, буде встретятся, корректируется парсинг... но на стандартизрванных структурах вроде логов это практически невозможно...

Akina
Иногда - единственно возможный. Скажем логи IP-трафика - для разных типов пакетов (допустим TCP и ICMP) структура строк лога (после даты-времени) радикально различается.
...достаточно ясна разница в формате ТСР и ICMP
В данном случае обрабатывался протокол уровня приложений...
Кстати, в отдельных случаях, можно "втянуть" ТСР и ICMP по разным правилам и... дальше понятно.


Удобно тем, что обработка "сырого импорта" пишется для каждого типа файла ОДИН РАЗ. Потом просто отслеживаются исключения и, буде встретятся, корректируется парсинг... но на стандартизрванных структурах вроде логов это практически невозможно...
А когда логи "пришлые"? Зачем это для "непредсказуемых" логов?
Да в общем и... "Сам себе ответил"

В сабжевой ситуации всё свелось к "сводной таблице" в Аксессе/Экселе. Поразительно легко отделался... А заодно и текстовые редакторы изучил.

Akina, спасибо!
Выручили в очень подходящий момент!
Мегапрограммка, внукам буду показывать, настолько просто и изящно вопрос помогли решить

Исправлено: moderator-Bio, 16.11.2011 14:47