Почему FTP может портить файлы?
Всю свою сознательную, web-строительную жизнь я пользовался FTP-клиентом Filezilla, но включив его в один солнечный, зимний день я заметил ужасную неточность в его работе: ftp-клиент почему-то все файлы переносил на удаленный сервер не до конца. Это было видно, к примеру, когда копируешь 30 Кб`айтный файл на сервер, а после копирования на сервере лежит 29.9 Кб.
Первым делом начал грешить на хостинг, но мои подозрения не оправдались. Самое обидное в этом было то, что в логах как сервера, так и ftp-клиента, ошибок не было.
Из-за того, что логи были девственно-чисты от каких либо ошибок, мои подозрения пали на провайдера, с которым уже в недалеком прошлом были подобные прецеденты.
Погрузившись с головой в скрупулезный анализ сетевых узлов, которые проходят мои запросы перед тем как попасть к серверу, я сделал вывод что сеть в этот раз работает просто идеально. Идеальнее она может работает только в рекламных буклетах и описаниях менеджеров любого омского провайдера.
Такой поворот событий поставил меня, если честно, в тупик. Я даже не знал куда мне «копать» дальше.
Интернет по этой проблеме почему-то молчал. Складывалось ощущение, что проблема касается только одного меня.
Решение
Для того, чтобы объяснить, как это починить, я немного отступлюсь и немного окунусь в омут ftp`шной теории.
На ftp-сервер мы передаем различный файлы, к которым относятся картинки, файлы стилей, pdf`ники, текстовые файлы и другие нужные нам форматы.
Так как ftp-сервер может быть установлен на операционную систему, которая отличается от нашей, то это и является корнем всех наших проблем. Эти проблемы чаще всего касаются текстовых файлов, так как в них используются переносы строк. Именно эти переносы и мешают передавать файлы на сервер правильно. К примеру, в Linux символ конца строки является \n (еще иногда обозначается LF), в Windows — \r\n (CR+LF), а в MacOS это \r (CR). Если у Вас на рабочей машине стоит Linux, а хостинг, не дай бог, работает на Windows, то текстовый файл не будет правильно отображаться. Всякие там картинки и и PDF-файлы немного «почикаются» и будут, как у меня, весить немного меньше. Прямо мечта каждой женщины.
Разработчики стандарта позаботились о этой проблеме и разделили способы переноса файлов на 2 типа: «режим ASCII» и «режим Binary». Первый, как раз, и призван для автоматической переделки этого безобразия с переносом строки, заменяя на тот способ отображения который используется на сервере.
«Режим Binary» – это передача файлов, грубо говоря, как есть, то есть как раз для картинок и всяких там pdf`ок, этот способ как нельзя лучше подходит.
FTP-клиент Filezilla умеет передавать по обоим этим способам, а самое главное, у него есть «золотая середина» — «режим Auto», который автоматически подбирает режим при каждой передачи файлов. Если его нет, то можете установить «режим Binary» и также забыть о дальнейших проблемах такого рода.
Поэтому, чтобы решить эту проблему нам нужно всего-лишь установить режим передачи файлов в AUTO.
P.S. Если Вы в повседневной работе используете ноутбук Apple MacBook Pro, а удаленный сервер работает на Linux или FreeBSD, то режим передачи файлов у Вас обязательно должен настроен правильно. Если в вашем клиенте нет режима Auto, то стоит позаботиться о том, что текстовые файлы, в обязательном порядке, передавались через режим ASCII, а остальные файлы через режим binary.
Теги: сеть
Хм, очень интересно. Намотал, как говорится, на ус.
У вас, как я понял, стоял тот злополучный режим передачи, это вы его сами поставили?
Мне кажется виноват в этом был я сам и когда-то его, возможно, случайно установил. Потратив целый вечер на отлавливание этого глюка, я немного прокачал свой скил)