информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
тут всё не просто 02.06.06 11:59  Число просмотров: 2118
Автор: 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.
<programming>
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

За это спасибо вдвойне. Ибо мне это надо в проекте. И то, что сейчас сделано, и работает - действительно жутчайший софтоизврат. То, что Вы пропостили, мне значительно поможет.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach