Как обрабатывать файл полученный пост запросом правильно?

Question

[Константин Теплоухов]

Через форму гружу текстовый файл , нужно обработать его построчно , некоторые строки записать в бд а остальные просто пропустить .
Сейчас вижу только вариант
1. Сохранять файл на сервере
2. Читаем построчно , обрабатываем строки
3. удаляем файл

Но можно ли как-то не сохранять файл на сервере ? В памяти его прочитать или ещё как . Просто пока мне кажется мой метод костылём каким-то

Comments

[Надим]

Если не хотите, чтобы файл записывался в принципе... не отправляйте файл. Отправляйте сразу JSON уже с прочитанными строками из прикрепленного файла. Для чтения файла на стороне браузера существует fileReader

Answer 1

[Надим]

Вероятно вы вообще не изучали тему. Когда на PHP обработчик поступает запрос из браузера в кодировке multipart/form-data, то все полученные файлы автоматически записываются во временную директорию, а ссылки эти файлы добавляются в суперглобальный массив $_FILES.

Чтобы сохранить файл, надо его из временной директории перенести куда-нибудь в другое место, для этого существует специальная функция move_uploaded_file. Если НЕ использовать данную функцию, то после завершения работы PHP обработчика все полученный файлы из временной директории автоматически будут удалены.

Иными словами, вам абсолютно ни что не мешает сразу при получении файла прочесть его содержимое из временной директории при помощи file_get_contents и потом делать с ним что хотите. Можете сохранить, а можете ничего не делать, тогда файл из временной директории автоматом сотрется потом.

P. S. Я хочу сказать, что при получении файла файл сохраняется на сервере автоматом, пусть и во временную директорию. Это ключевой момент, который вы похоже не поняли. Удаляется он потом тоже автоматом.

Answer 2

[Владимир Коротенко]

Когда вы загрузили файл, он уже сохранился.
$tmp = $_FILES['file']['tmp_name'];
Дальше открываете файл .
Сразу же вызываете unlink
В системе его уже нет, но пока дескриптор не освободится вы сможете с ним работать

Comments

[Ипатьев]

unlink-то зачем?

[AUser0]

Ипатьев, может что бы не забыть unlink-кнуть его потом, опосля, при закрытии скрипта (штатно или по какой-нибудь ошибке).

[Владимир Коротенко]

Ипатьев, unlink стандартная практика что бы точно удалить файл если что то пойдет не так и что бы кто то умный не успел его прочитать

[Ипатьев]

AUser0, то есть вы анлинкаете руками каждый загруженный файл, серьёзно?
Это граничит с гениальностью. Потому что кроме вас двоих такая прекрасная идея никому больше в голову не пришла.

[Владимир Коротенко]

Ипатьев, Вот вам официальный баг
https://bugs.php.net/bug.php?id=68535
то есть в последствии эти данные могут быть считаны.

[ProjectSoft]

Владимир Коротенко, баг 2014 года. На php 5.5. Да ещё и в системе Windows... Вы серьёзно???

[Владимир Коротенко]

ProjectSoft, Вполне. PHP по умолчанию складывает все в /tmp надо ли напоминать какие там права доступа?

То есть проведя аналогию из жизни:
Вы забываете ключи от двери в замке, зная что ваша бабушка всегда их вынимает.
Но однажды у бабушки инсульт и она не вынула ключи.
Вы приходите домой, мертвая бабушка и ограбленная квартира.

[ProjectSoft]

Владимир Коротенко, вы может не поняли о чём там речь?
Там речь идёт о версии php 5.5.19 и под системой Windows Server 2012.
Сейчас не рекомендуют использовать версию php ниже 5.6 в целях той же самой безопасности.
Про разницу OS промолчу, т. к. это выбор каждого в частности.
А вот проблема решается в несколько кликов, по сути.
Да и вообще, временная папка никогда и ни при каких обстоятельствах не должна быть доступна извне.
Про бабушку - это вы зря.)))
Задача программиста, а в особенности администратора сервера, никогда, ни в коем случае не оставлять ключей в замке.

[Владимир Коротенко]

ProjectSoft,

Я говорю о концепции.
Процесс создает временные файлы и при своем завершении их удаляет.
Между 2 этими моментами возможен доступ к этим файлам.
А возможно и аварийное завершение этого процесса и тогда 2 действие не сработает.
Итак вы утверждаете что удаленно нельзя вызвать аварийное завершение PHP?
То есть разработчики боги и не допустят ошибки?

И вместо банального действия вы предлагаете уверовать, что все всегда будет штатно?

[ProjectSoft]

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

Итак вы утверждаете что удаленно нельзя вызвать аварийное завершение PHP?

Чем же вас спасёт тогда, в данном случае ваш unlink если будет вызвана ошибка?
Ну и на последок

То есть разработчики боги и не допустят ошибки?

Тогда на черта разрабатывать что-то?
Они никогда не должны допускать ошибки и всегда обрабатывать их. Ловить и принимать нормальное решение по устранению.
Или это ни так?

Answer 3

[alexalexes]

Именно так, как вы описали.
Вообще, если вы используете нативные возможности серверного окружения для приема, передачи, чтения, записи данных по средством файлов, то вы должны морально готовы написать код так, чтобы минимальными ресурсами оперативной памяти (десятки мегабайт) перерабатывать объем данных (сотни мегабайт, гигабайты), расположенный в файлах, кратно превышаемый объем этой оперативной памяти, выделенной для выполнения скрипта.
Поэтому, читать файлы вам в любом случае построчно (еще правильнее - поблочно, с ограничением макс. длины блока), и при обработки блока постоянно вспоминать, а сколько оперативной памяти кушается при получении данных из файла (делать отладку с профилированием памяти), передачи их в функции и методы обработки, до записи результата. Также научитесь вовремя очищать тяжеловесные переменные (внезапно unset окажется не так уж бесполезен).