array[0..5] of byte = (1,2,3,4,5,6);
begin
fs:=TFileStream.Create('test.txt',fmCreate);
cs:=TZCompressionStream.Create(clfastest, fs);
fs.Write(s[0], Length(s));
cs.Free;
fs.Free;
end.
test.txt:
78 01 03 00 00 00 00 01
💁♂️🤷♂️🤔
Подозреваю, что это нормально(такой вывод в файле)....
А как сделать чтобы я мог и сырые данные писать и сжатые в один стрим? (каждый раз создавать-разрушать CompressionStream?)
А куда, кстати, ушли сырые байты? Их что CompressionStream перехватил?
Это Delphi, если что
Чет у тебя не сжалось вообще, а наоборот)
ну я и пишу в стрим, который без сжатия.... а вот этот выхлоп (сам для себя решил, без лазанья в код), что это заголовки какие-то
в общем... на FPC я до этого так делал: 1. Пишу данные(заголовок) сырых данных, в обычный FileStream 2. Потом пишу в CompressionStream основные данные для сжатия Когда нужно - расжимал всё обратно и сверял с заголовком И это - работало. Теперь решил данные после сжатого стрима хранить... и вот чёто тут не пошло, ни в FPC ни в Delphi Смотря на HEX вывода два вопроса возникает: 1. CompressionStream - он что перехватывает вывод в связанный FileStream, даже если я пишу в сам FileStream? 2. CompressionStream - формирует какой-то заголовок(эпилог?) в конце стрима?
Отвечаю на свои вопросы сам: 1. В Delphi TCompressionStream игнорит смещение, пишет с начала (может это как-то можно зарегулировать, но с ходу не нашёл) 2. При освобождении объекта TCompressionStream - пишет ещё какие-то данные(заголовок(эпилог?)) - можно ли это отключить? Не знаю, может контрольная сумма или что это... или служебные данные...
классы разные, даже названия. совсем не факт что они должны и будут одинаково работать
да, согласен, де юре не подкопаться
Обсуждают сегодня