Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
unc в имплементациях FTP. 02.06.06 06:39
Автор: void <Grebnev Valery> Статус: Elderman
|
Столкнулся второй раз с "юникс стилем" программ использующих сетевой обмен данными...
Когда посылаешь файл в каталог на FTP (ftp.xxx.com/directory/filename), то такой формат имени удалённого файла, directory/filename, одинаково хорошо работает для MS Windows и Unix based FTPs.
Когда же используешь нотацию directory\filename, то MS надо это и посылать. Для юниксов же надо посылать directory\\filename в сеть!
Т.е, LPCTSTR для MS remoteFileName= "directory\\filename" (что ясно и понятно), а для юникс remoteFileName= "directory\\\\filename" (что ясно и смешно).
Такая нежная восприимчивость юникса к эскейп последовательнотям всего лишь в имени файла, передаваемого по сети (передаваемого по сетиимени немного удивляет и настараживает неискушённого программиста, вроде меня.
Казалось бы используй / вместо \\. Но не ту-то было. Первый раз столкнулся в с тем, как приложения первоначально написанные для юникс, интерпретируют строки, передаваемые по сети - для MySQL. Легко проверить, что если в базе данных мы захотим хранить path \\host\directory\filename, то придётся использовать нечто вроде LPCTSTR fname = "\\\\\\\\host\\\\direcory\\\\fiename";
Ничего такого для Microsoft нет. Пишем обычную строку:
LPCTSTR fname = "\\\\host\\direcory\\fiename"
Поинт, в том, что негоже по сети передовать строки так, как принято в том или другом языке программирования. Если надо по сети передать строку "\\aaa\bbb", то ровно это, ровно эти байты и должны проезжать по сетке, а не эскейп последовательности.
Поправьте, если я не прав.
Спасибо.
ПС. RFC ftp умалчивает спецификацию последовательности байт представляющих имя ресурса ftp.
|
|
тут всё не просто 02.06.06 11:59
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> Столкнулся второй раз с "юникс стилем" программ
> использующих сетевой обмен данными...
>
> Когда посылаешь файл в каталог на FTP
> (ftp.xxx.com/directory/filename), то такой формат имени
> удалённого файла, directory/filename, одинаково хорошо
> работает для MS Windows и Unix based FTPs.
> Когда же используешь нотацию directory\filename, то MS надо
> это и посылать. Для юниксов же надо посылать
> directory\\filename в сеть!
Это как раз понятно. RFC0959 упоминает о том что контрольный канал у фтп работает на 7-битном ASCII. Отсюда, естесственно нужда в escape-последовательностях. Плюс необходимость эскапировать служебные символы FTP.
> Т.е, LPCTSTR для MS remoteFileName= "directory\\filename"
> (что ясно и понятно), а для юникс remoteFileName=
> "directory\\\\filename" (что ясно и смешно).
> Такая нежная восприимчивость юникса к эскейп
> последовательнотям всего лишь в имени файла, передаваемого
> по сети (передаваемого по сетиимени немного удивляет и
> настараживает неискушённого программиста, вроде меня.
>
Добро пожаловать в мир Cи! А кто это у вас с собой? Pathnames из MSDOS? Хм. Ну что ж - вольному воля :)
> Казалось бы используй / вместо \\. Но не ту-то было.
А в чём проблема?
> Первый
> раз столкнулся в с тем, как приложения первоначально
> написанные для юникс, интерпретируют строки, передаваемые
> по сети - для MySQL. Легко проверить, что если в базе
> данных мы захотим хранить path \\host\directory\filename,
> то придётся использовать нечто вроде LPCTSTR fname =
> "\\\\\\\\host\\\\direcory\\\\fiename";
>
Ну что тут скажешь. Здесь мы имеем дело с типичным программерским подходом к освоению продукта - "читаем маны только если нельзя победить проблему жутким софтоизвратом".
http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html
...
NO_BACKSLASH_ESCAPES
Disable the use of the backslash character (‘\’) as an escape character within strings. With this mode enabled, backslash becomes any ordinary character like any other.
...
> Ничего такого для Microsoft нет. Пишем обычную строку:
> LPCTSTR fname = "\\\\host\\direcory\\fiename"
>
Прикольная "обычная строка" - всюду двойные бэкслэши :)))
> Поинт, в том, что негоже по сети передовать строки так, как
> принято в том или другом языке программирования. Если надо
> по сети передать строку "\\aaa\bbb", то ровно это, ровно
> эти байты и должны проезжать по сетке, а не эскейп
> последовательности.
>
Пойнт в корне неверен. Данные по сети передаются не из воздуха в воздух. Как правило они передаются от системы А к системе Б. И одной из задач архитекторов сети была независимость передающих механизмов от условий передатчика и приёмника.
Простейший пример: на одном сервере fs хранит русские имена в КОИ8, а на другом - в 1251. Будешь передавать 8-битным символом - на выходе получишь кракозябры. Будешь передавать специально разработаным кодом (например utf8) при помощи эскейп последовательностей - приёмник всё корректно переконвертит, и пользователь увидит родные и знакомые слова: "Финансовый Отчёт.doc" а не "юПЫЛДВЩЦУКИ мОВЛВ.doc" :) Конечно было бы классно если бы всегда всё передавалось как есть, без всего этого гимора. Но мы не живём в идеальном мире.
> Поправьте, если я не прав.
> Спасибо.
>
Вообще тема это очень интересная, непростая и в общем-то не имеет никакого отношения к MS vs Unix флеймам. Это скорее проблема уровня приложений, стандартов, умолчаний, соглашений, best practices etc.
> ПС. RFC ftp умалчивает спецификацию последовательности байт
> представляющих имя ресурса ftp.
|
| |
Спасибо. 03.06.06 05:36
Автор: void <Grebnev Valery> Статус: Elderman
|
> > Столкнулся второй раз с "юникс стилем" программ
> > использующих сетевой обмен данными...
> >
> > Когда посылаешь файл в каталог на FTP
> > (ftp.xxx.com/directory/filename), то такой формат
> имени
> > удалённого файла, directory/filename, одинаково хорошо
> > работает для MS Windows и Unix based FTPs.
> > Когда же используешь нотацию directory\filename, то MS
> надо
> > это и посылать. Для юниксов же надо посылать
> > directory\\filename в сеть!
>
> Это как раз понятно. RFC0959 упоминает о том что
> контрольный канал у фтп работает на 7-битном ASCII. Отсюда,
> естесственно нужда в escape-последовательностях. Плюс
> необходимость эскапировать служебные символы FTP.
>
> > Т.е, LPCTSTR для MS remoteFileName=
> "directory\\filename"
> > (что ясно и понятно), а для юникс remoteFileName=
> > "directory\\\\filename" (что ясно и смешно).
> > Такая нежная восприимчивость юникса к эскейп
> > последовательнотям всего лишь в имени файла,
> передаваемого
> > по сети (передаваемого по сетиимени немного
> удивляет и
> > настараживает неискушённого программиста, вроде меня.
> >
>
> Добро пожаловать в мир Cи! А кто это у вас с собой?
> Pathnames из MSDOS? Хм. Ну что ж - вольному воля :)
>
> > Казалось бы используй / вместо \\. Но не ту-то было.
>
> А в чём проблема?
>
> > Первый
> > раз столкнулся в с тем, как приложения первоначально
> > написанные для юникс, интерпретируют строки,
> передаваемые
> > по сети - для MySQL. Легко проверить, что если в базе
> > данных мы захотим хранить path
> \\host\directory\filename,
> > то придётся использовать нечто вроде LPCTSTR fname =
> > "\\\\\\\\host\\\\direcory\\\\fiename";
> >
>
> Ну что тут скажешь. Здесь мы имеем дело с типичным
> программерским подходом к освоению продукта - "читаем маны
> только если нельзя победить проблему жутким софтоизвратом".
>
> http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html
> ...
> NO_BACKSLASH_ESCAPES
>
> Disable the use of the backslash character (‘\’) as an
> escape character within strings. With this mode enabled,
> backslash becomes any ordinary character like any other.
> ...
>
> > Ничего такого для Microsoft нет. Пишем обычную
> строку:
> > LPCTSTR fname = "\\\\host\\direcory\\fiename"
> >
>
> Прикольная "обычная строка" - всюду двойные бэкслэши :)))
>
> > Поинт, в том, что негоже по сети передовать строки
> так, как
> > принято в том или другом языке программирования. Если
> надо
> > по сети передать строку "\\aaa\bbb", то ровно это,
> ровно
> > эти байты и должны проезжать по сетке, а не эскейп
> > последовательности.
> >
>
> Пойнт в корне неверен. Данные по сети передаются не из
> воздуха в воздух. Как правило они передаются от системы А к
> системе Б. И одной из задач архитекторов сети была
> независимость передающих механизмов от условий передатчика
> и приёмника.
> Простейший пример: на одном сервере fs хранит русские имена
> в КОИ8, а на другом - в 1251. Будешь передавать 8-битным
> символом - на выходе получишь кракозябры. Будешь передавать
> специально разработаным кодом (например utf8) при помощи
> эскейп последовательностей - приёмник всё корректно
> переконвертит, и пользователь увидит родные и знакомые
> слова: "Финансовый Отчёт.doc" а не "юПЫЛДВЩЦУКИ мОВЛВ.doc"
> :) Конечно было бы классно если бы всегда всё передавалось
> как есть, без всего этого гимора. Но мы не живём в
> идеальном мире.
>
> > Поправьте, если я не прав.
> > Спасибо.
> >
>
> Вообще тема это очень интересная, непростая и в общем-то не
> имеет никакого отношения к MS vs Unix флеймам. Это скорее
> проблема уровня приложений, стандартов, умолчаний,
> соглашений, best practices etc.
>
> > ПС. RFC ftp умалчивает спецификацию последовательности
> байт
> > представляющих имя ресурса ftp.
Спасибо.
> http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html
> ...
> NO_BACKSLASH_ESCAPES
За это спасибо вдвойне. Ибо мне это надо в проекте. И то, что сейчас сделано, и работает - действительно жутчайший софтоизврат. То, что Вы пропостили, мне значительно поможет.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
