Почему 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.

Комментарии:

  1. myr4ik07 опубликовал комментарий 28 Февраль 2013, 20:05 #

    Хм, очень интересно. Намотал, как говорится, на ус.
    У вас, как я понял, стоял тот злополучный режим передачи, это вы его сами поставили?

    | Ответить
    • ITShaman опубликовал комментарий 1 Март 2013, 06:52 #

      Мне кажется виноват в этом был я сам и когда-то его, возможно, случайно установил. Потратив целый вечер на отлавливание этого глюка, я немного прокачал свой скил)

      | Ответить
Имя
e-mail
Сайт
Текст комментария: