FTP и глюки аплоада

igortik

Новичок
Не могу понять чем вызвана следующая неприятность:

- Иногда при загрузке файлов по фтп по факту аплоада на сервер содержимое файла меняется (между каждой строкой появляется межстрочный интервал, т.е. еще одна дополнительная пустая строка, перевод каретки), при этом кодировка загружаемого файла windows-1251.
- что интересно, то что это наблюдается не во всех файлах из той же директории, при том что их кодировки идентичны

глюк фтп?
 

igortik

Новичок
пока что по ходу дела почитал, но в winscp, кторым пользуюсь для работы также не только по фтп но и ssh вообще нет вариантов выбора между бинарным режимом передачи и ASCII...
 

vovanium

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

глюк также может быть из-за того, если какие-то файлы правятся браузером из винды, так как в таком случае отправляются данные в с \r\n, которые потом при скачивания из linux на винду по FTP преобразовываются в \r\n \r\n (или \r\r\n) и получаются лишние строки.
 

igortik

Новичок
Так а какое решение в данном случае?
А то сейчас приходится все прогонять в линуксе с помощью sed для удаления этих LF...

Проблема не только у меня встречалась, и зендом код писали и дримвувером и периодически они на сервер уже поступают в таком раздолбанном виде ))) ... самое интересное, что они туда отправляются в нормальном виде, а по факту аплоада искажаются, т.е. это происходит именно на стадии загрузки на сервер.
 

vovanium

Новичок
смотреть настройки своих софтин, юзаю FlashFXP и WinSCP обе нормально все автоматом заливают, разве что зазенденные файлы нужно вручную переключать в binary режим.
как вариант напиши скриптик который показывает спец. символы, и проверь файлы перед отправкой и после уже на хостинге, выясняй где именно косяк происходит.
 

igortik

Новичок
Все равно не могу понять зачем тогда переключаться при передачи в режим ASCII, если интерпретатор без проблем работает с файлами, у которых переводы строк представлены как CR, LF, CR/LF (в любых вариациях).. не проще ли тогда просто в бинарном виде отдавать контент таким какой он есть.. или я что-то пропустил на этот счет?

Я реально подустал от этих конвертаций:

for i in `find ./ -type f -name \*.php`; do
cat $i | sed 's/?>//g' > buffer.cat;
cat buffer.cat | sed 's/.$//' > $i;
echo "" > buffer.cat;
done

и то это не решает ряд проблем ...

объясните дураку.. к чему это авто определение ASCII?

Привожу разумный ман на этот счет:

ASCII vs. Binary Mode

One of the least-understood aspects of FTP transfers is the difference between ASCII and Binary mode data transfers. ASCII stands for American Standard Code for Information Interchange, and is a type of character encoding based on the English language used on devices that handle information stored in text. It includes 33 non-printed control characters and 94 printed characters such as letters and punctuation.

When files are transferred in ASCII mode, the transferred data is considered to contain only ASCII formatted text. The party that is receiving the transferred data is responsible for translating the format of the received text to one that is compatible with their operating system. The most common example of how this is applied pertains to the way Windows and UNIX handle newlines. On a Windows computer, pressing the "enter" key inserts two characters in an ASCII text document - a carriage return (which places the cursor at the beginning of the line) and a line feed (which places the cursor on the line below the current one). On UNIX systems, only a line feed is used. ASCII text formatted for use on UNIX systems does not display properly when viewed on a Windows system and vice versa.

Binary mode refers to transferring files as a binary stream of data. Where ASCII mode may use special control characters to format data, binary mode transmits the raw bytes of the file being transferred. In this way, the file is transferred in its exact original form.

Which Mode Is Best?

In the vast majority of cases, the user does not need to worry about manually configuring the proper mode when transferring files. FTP clients, such as FTP Voyager, usually employ a method of automatically determining the proper transfer mode based upon the contents of the file or the file's extension. FTP Voyager calls this Auto-ASCII.

When using FTP Voyager, Auto-ASCII is the preferred (and default) transfer mode. It uses a customizable list of file extensions defined in the View | Options | Auto-ASCII Extensions menu to automatically determine whether a file should be transferred in ASCII or binary mode. The list of Auto-ASCII file extensions can be modified to include proprietary file extensions that indicates to FTP Voyager that the content of the file is ASCII formatted text.

For times when the transfer mode must be manually selected, ASCII should be used when transferring text files. While ASCII mode isn't technically necessary when transferring data between compatible file systems, as a practical matter determining the compatibility of the file systems in use by the client and server is not possible. Some of the most common file types that should be transferred in ASCII mode includes:
* txt - Plain text files.
* htm, html, css - Files containing HTML or CSS mark-up.
* asp, vbs, js - Files containing scripting delivered through HTTP.

If a file containing binary data is sent using ASCII mode, it will most likely end up being corrupted. If you're having problems with corrupted file transfers, try using binary mode when transferring the file. Some common file formats that are sometimes mistakenly transferred in ASCII mode includes:
* pdf - PDF files can contain embedded binary data such as images.
* doc - Microsoft Word documents are a binary formatted file.
* In general, all audio, video, and image file formats are binary.

Вопрос еще раз ...

Опять же - нахрен нужен тогда режим ASCII, если он может создать проблемы при переносе с одной ОС на другую в то время, как в бинарном виде файл зальется без изменений и корректно обработается интерпретатором PHP ...
 

vovanium

Новичок
Можешь вполне юзать unix'овые переводы строк на винде и заливать всё в бинарке, проблемы будут разве что в Блокноте, нормальные редакторы и IDE работают с любыми переносами строк.
 

igortik

Новичок
Можешь вполне юзать unix'овые переводы строк на винде и заливать всё в бинарке, проблемы будут разве что в Блокноте, нормальные редакторы и IDE работают с любыми переносами строк.
выходит - перегнать все CR в LF и не париться :)
 

igortik

Новичок
Можно и так, в принципе обычно в IDE можно настраивать кодировку и переносы для проекта.
в рамках того, сколько их у меня, я боюсь с дуру что-то напутать а потом разбираться...
я под убунту юзаю Komodo в качестве среды разработки (бесплатный), под виндой дримвувер... много проектов на cp1251, винда ставит свои CR/LF, linux - LF соответственно.. все это счастье дополняется неожиданными дополнительными переводами строк в файлах после аплоада и я пляшу от счастья :D

Вот пытаюсь для себя понять идеальный, хотя бы частично идеальный подход в данном случае ...

Скоро со страху буду через консоль загружать :)))
смех и слезы...
 

vovanium

Новичок
Так вроде ни что не мешает юзать Komodo и на винде, и настроить их одинаково, а переводы не винда вставляет, а сами редакторы. Если открываешь на винде файл с unix переводами, то он таким остается и после редактирования. Просто по умолчанию для новых файлов выставлены переводы такие как приняты в ОС.
 

igortik

Новичок
Так вроде ни что не мешает юзать Komodo и на винде, и настроить их одинаково, а переводы не винда вставляет, а сами редакторы. Если открываешь на винде файл с unix переводами, то он таким остается и после редактирования. Просто по умолчанию для новых файлов выставлены переводы такие как приняты в ОС.
угу... думаю так и буду делать.
сейчас остается вопрос борьбы с лишними переводами... в одних файлах по 2 LF, в других 2 CR последовательно ...
а я сижу втыкаю в монитор и жду, когда проблема решится сама собой :)
 
Сверху