Ответ 1
В такие времена официальная спецификация HTTP всегда полезна. Из RFC 2616 7.2.1 (добавлено мной):
Любое сообщение HTTP/1.1, содержащее тело-сущность, ДОЛЖНО включать поле заголовка Content-Type, определяющее тип носителя этого тела. Если и только если тип материала не задан в поле Content-Type, получатель МОЖЕТ попытаться угадать тип носителя путем проверки его содержимого и/или расширений имен URI, используемых для идентификации ресурса. Если тип носителя остается неизвестным, получатель ДОЛЖЕН относиться к нему как к типу "application/octet-stream" .
Причиной вашей проблемы является то, что сервер, принимающий загрузку файла, сам не знает, какой тип файла был загружен. Зачем? Поскольку он использует HTTP-сообщение, которое отправило файл, чтобы указать заголовок Content-Type, чтобы определить точный тип mime. Вероятно, браузер не отправил заголовок Content-Type, а сервер предположил application/octet-stream в соответствии с официальной выпиской по HTTP-спецификации выше. Также возможно, что клиент, загружающий файл, решил не определять тип mime файла, который он загружал, и отправил сам заголовок Content-Type: application/octet-stream.
Теперь, когда мы рассматриваем это в сочетании с руководством PHP в отношении загрузки файлов POST docs, мы видим следующее:
$_FILES['userfile']['type']Тип mime файла, если браузер предоставил эту информацию. Примером может служить "image/gif". Этот тип mime, однако, не проверяется на стороне PHP и поэтому не принимает его значение как должное.
Итак, как вы можете видеть, даже если $_FILES['userfile']['type'] указан, он соответствует только заголовку Content-Type, отправленному клиентом. Эту информацию можно легко подделать, и на нее нельзя положиться. Если вам нужно убедиться, что загруженный файл имеет определенный тип, вам нужно будет убедиться в этом.