Работая с текстовым файлом

← →
ИМХО © (2004-11-21 16:42) [0]

Как узнать текущую позицию?

Ситуация такова: читается текстовый файл от начала и до самого конца (с помощью ReadLn).

Нужно "запоминать" определенные места (начало и конец блока), чтобы затем быстро обращаться к ним.

Как это осуществить?

← →
Anatoly Podgoretsky © (2004-11-21 16:48) [1]

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

← →
ИМХО © (2004-11-21 16:54) [2]

я считаю байты:

Sum := Sum + Length(Str) + 2;

чтобы затем обратиться так

MyStream := TFileStream.Create(FName, fmOpenRead or
fmShareDenyNone);
try
MyStream.Position := Start_Index;
SetLength(MessageStr, Finish_Index);
MyStream.Read(MessageStr[1], Finish_Index);
finally
MyStream.Free;
end;

ДЛЯ НЕКОТОРЫХ ФАЙЛОВ ЭТОТ МЕТОД НЕ КАТИТ!

← →
ИМХО © (2004-11-21 16:56) [3]

для некоторых файлов по какой-то неведомой причине счетчик накручивает больше байтов, чем есть, поэтому MessageStr получается не тот, что надо

← →
ИМХО © (2004-11-21 16:58) [4]

"Что делать?" (с) Чернышевский

← →
ИМХО © (2004-11-21 17:01) [5]

допустим, стою я на 100-й строке.
Как определить смещение первого символа этой строки относительно начала файла???

← →
Anatoly Podgoretsky © (2004-11-21 17:01) [6]

ИМХО © (21.11.04 16:54) [2]
Это уже не текстовые файлы, а VCL обвязка над низкоуровневым АПИ работы с двоичными данными, для работы как с текстовыми файлам тебе придется поверх ее реализовать всю функциональность ReadLn

← →
ИМХО © (2004-11-21 17:08) [7]

но почему по формуле

Sum := Sum + Length(Str) + 2

кол-во байтов считается неверно???

← →
ИМХО © (2004-11-21 17:10) [8]

ставим так вопрос:
как при последовательном чтении текстового файла с использованием ReadLn ПРАВИЛЬНО подсчитать количество байтов?

← →
Anatoly Podgoretsky © (2004-11-21 17:15) [9]

ИМХО © (21.11.04 17:08) [7]
А почему по этой формуле должно считаться верно?

ИМХО © (21.11.04 17:10) [8]
Сумма длин строк + неопределенный разделитель строк, если файл верный ,то +1 или 2 в зависимости от системы, только для строковых файлов это не верно, у них единица информации строка, а не байт.

← →
ИМХО © (2004-11-21 17:20) [10]

> ИМХО © (21.11.04 17:08) [7]
> А почему по этой формуле должно считаться верно?

мне ее Панов давал как-то...

> Сумма длин строк + неопределенный разделитель строк, если
> файл верный

что значит верный?

> зависимости от системы

ось - всегда Винды

← →
ИМХО © (2004-11-21 17:23) [11]

то есть предлагается запоминать номер строки начала блока, номер строки конца блока, затем КАЖДЫЙ раз открывать файл и читать ReadLn ДО ПОБЕДНОГО?

Жутко неэффективно.

← →
KilkennyCat © (2004-11-21 17:23) [12]

синхронизировав TstringList со свои текстовым файлом ты получишь желаемое удобство и скорость (в зависимости от частоты синхронизации)

← →
ИМХО © (2004-11-21 17:28) [13]

> KilkennyCat © (21.11.04 17:23) [12]

можно подробнее о синхронизации?

← →
Anatoly Podgoretsky © (2004-11-21 17:36) [14]

ИМХО © (21.11.04 17:20) [10]
Во первых если тебе нужна скорость и позионируемость, то загрузи файл в список.

Верный это когда разделитель соответствует системе, а не дика смесь из разных разделителей, например #13#10#10

← →
KilkennyCat © (2004-11-21 17:38) [15]

TstringList.LoadFromFile - в общем случае, каждый раз, когда изменится файл. Но можно продумать и более удобный вариант, когда меняться будет только измененное...

← →
Anatoly Podgoretsky © (2004-11-21 17:42) [16]

ИМХО © (21.11.04 17:23) [11]
Ну если уж быть совсем строгим, то вообще только один раз в одном направлении, поскольку это может быть последовательный коммуникационный файл, например COM порт, что ты там будешь открывать заново? А это и есть именно определение чистого текстового файла - последовательный, со строками заранее неизвестной длины, разграниченные разделителем, и кончом файла является специальный символ конец файла. В случае файла расположеного на диске просто действует небольшое отклонение от нормы, конец можно определить по размеру, но это чисто частный случай.

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

← →
ИМХО © (2004-11-21 17:50) [17]

> Anatoly Podgoretsky © (21.11.04 17:42) [16]
> Вся твоя проблема, что ты выбираешь не те средства и алгоритмы
> для выполнения какой то работы. Список наиболее подходящий
> алгоритм.

то есть предлагаешь использовать все-таки TStringList?
файл какого размера он может удержать в памяти? (берем слабенькую машину)

← →
KilkennyCat © (2004-11-21 17:52) [18]

> ИМХО © (21.11.04 17:50) [17]

зависит от типа ОС, объема памяти-винчестера, фата...

← →
Anatoly Podgoretsky © (2004-11-21 17:52) [19]

Не предлагаю, а показываю как один из вариантов, на основании твоего разъяснения, которое далеко не полное. Все определяется задачей, но уверен, что это решит проблему скорости, добавления, удаление строк практически на 100%, только при больших размерах стоит задуматься, но это действительно при больших размерах, скажем свыше 10/100 мб на файл.

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

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

> Anatoly Podgoretsky © (21.11.04 17:15) [9]
> Сумма длин строк + неопределенный разделитель строк, если
> файл верный ,то +1 или 2 в зависимости от системы, только
> для строковых файлов это не верно, у них единица информации
> строка, а не байт.

ВОТ!!!

Выяснилось, что некоторые строки в этих [skipped] файлах заканчивались только на #13, а не на #13#10, а я ко всем приплюсовываю 2!

Но как это узнать программно (без лазания по всему файлу шестнадцатиричном редактором)?

ReadLn не может сказать, чем заканчивается текстовый файл: #13 или #13#10 ???

нет.

кто может это сказать?

ИМХО © (21.11.04 18:15) [22]
Никак, вот если бы это был Д5 тогда было бы одназначно, а начиная с Д6 борланд поше на поводу у некоторыех, теперь абсолютно неясно как и ксолько.

KilkennyCat © (21.11.04 19:04) [26]
Через ReadLn, а именно о нем вопрос, никак. А другие методы это уже не из текстовых файлов.

TTextRec type

Работая с текстовым файлом Найти похожие ветки