Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Спасибо. 03.06.06 05:36 Число просмотров: 2182
Автор: 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
За это спасибо вдвойне. Ибо мне это надо в проекте. И то, что сейчас сделано, и работает - действительно жутчайший софтоизврат. То, что Вы пропостили, мне значительно поможет.
|
<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
За это спасибо вдвойне. Ибо мне это надо в проекте. И то, что сейчас сделано, и работает - действительно жутчайший софтоизврат. То, что Вы пропостили, мне значительно поможет.
|
|
|