Аннотация:
Статья представляет собой описание принципов кодирования простейших типов в нотации ASN.1 BER. Приведены подробные примеры кодирования, рассмотрены сложные и не очевидные варианты кодируемых значений. К статье прилагается файл примеров на С++ (Windows) с дополнительными примерами кодирования для каждого рассмотренного в статье типа.
30.05.13 02:14: Перенесено модератором из 'Низкоуровневое программирование' — SergH
СЮ>Авторы: СЮ> Строжевский Юрий
СЮ>Аннотация: СЮ>Статья представляет собой описание принципов кодирования простейших типов в нотации ASN.1 BER. Приведены подробные примеры кодирования, рассмотрены сложные и не очевидные варианты кодируемых значений. К статье прилагается файл примеров на С++ (Windows) с дополнительными примерами кодирования для каждого рассмотренного в статье типа.
Унылая и бесполезная статья. Нет ссылко на стандартны, не сказано про то, как правильно читать эти стандарты. Заголовок не соответствует соежржанию, эту статью надо назвать "ASN.1. Стандарт кодирования BER для Чайников.". Да и БЕр не очень интересн т.к. прост, а вот PER был бы интересен. В общем, не зачёт.
СЮ>>Авторы: СЮ>> Строжевский Юрий
СЮ>>Аннотация: СЮ>>Статья представляет собой описание принципов кодирования простейших типов в нотации ASN.1 BER. Приведены подробные примеры кодирования, рассмотрены сложные и не очевидные варианты кодируемых значений. К статье прилагается файл примеров на С++ (Windows) с дополнительными примерами кодирования для каждого рассмотренного в статье типа. K>Унылая и бесполезная статья. Нет ссылко на стандартны, не сказано про то, как правильно читать эти стандарты. Заголовок не соответствует соежржанию, эту статью надо назвать "ASN.1. Стандарт кодирования BER для Чайников.". Да и БЕр не очень интересн т.к. прост, а вот PER был бы интересен. В общем, не зачёт.
Унылый и бесполезный комментарий: отсутствует внимательность (ссылка на стандарты прямо во введении к статье), автор комментария не знает даже как читать эти стандарты. За идею заголовка спасибо — видимо для определённого слоя читателей заголовок "для чайников" ближе и приятнее. А про PER — понимание вторичных кодировок (таких как PER) сложно без понимания BER. И интересы у всех людей разные — если кому нравится BER то они читают мою статью, если кому-то нравится PER — читают что-то другое или пишут свои прекрасные статьи.
K>Унылая и бесполезная статья. Нет ссылко на стандартны, не сказано про то, как правильно читать эти стандарты. Заголовок не соответствует соежржанию.....
И даже подраздел форума (asm) не соответствует содержанию
Здравствуйте, dilmah, Вы писали:
K>>Унылая и бесполезная статья. Нет ссылко на стандартны, не сказано про то, как правильно читать эти стандарты. Заголовок не соответствует соежржанию.....
D>И даже подраздел форума (asm) не соответствует содержанию
Здравствуйте, y-niko, Вы писали:
YN>Здравствуйте, Kernan, Вы писали:
YN>Унылый и бесполезный комментарий: отсутствует внимательность (ссылка на стандарты прямо во введении к статье), автор комментария не знает даже как читать эти стандарты.
Начнём с того, что стандартов всего 10 ITU-шных и один RFC. Из статьи не ясно что и где декларируется (а это очень интересно, т.к. разработчки руководствуются таки стандартами, а не статьями). Как минимум можно посвятить этому хороший обзац. Во вторых, та куцая ссылка это не ссылка на "ITU-T Rec. X.690", а ссылка на непойми что. Скачать ничего не получилось. У тебя, кстати, нет раздела "Литература" в которой все используемые для написания статьи стандарты должны быть перечислены. YN>За идею заголовка спасибо — видимо для определённого слоя читателей заголовок "для чайников" ближе и приятнее.
Ты просто вкратце передашь суть статьи, а суть её это "ASN.1 Стандарт кодирования BER для чайников.", т.к. не чаники просто откроют стандарт. YN>А про PER — понимание вторичных кодировок (таких как PER) сложно без понимания BER. И интересы у всех людей разные — если кому нравится BER то они читают мою статью, если кому-то нравится PER — читают что-то другое или пишут свои прекрасные статьи.
На самом деле, разобраться с BER не проблема, т.к. это TLV (кстати, что это за подход?). Реальная проблема это хитрые стандарты вроде PER которые используются в серьёзных системах и на практике народ имеет проблемы именно с ним и именно постое описание его они ищут в инете.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Как то не очень интересно в 21 веке ..
На самом деле оно актуально в телекоме более, чем ты думаешь. Даже новые стандарты по LTE-A (к примеру) используют ASN.1 для описания протокола. А дальше всё просто, запихал описание в программу и она тебе сгенерила парсер и сопутствующий хлам..
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, y-niko, Вы писали:
YN>>Здравствуйте, Kernan, Вы писали:
YN>>Унылый и бесполезный комментарий: отсутствует внимательность (ссылка на стандарты прямо во введении к статье), автор комментария не знает даже как читать эти стандарты. K>Начнём с того, что стандартов всего 10 ITU-шных и один RFC. Из статьи не ясно что и где декларируется (а это очень интересно, т.к. разработчки руководствуются таки стандартами, а не статьями). Как минимум можно посвятить этому хороший обзац. Во вторых, та куцая ссылка это не ссылка на "ITU-T Rec. X.690", а ссылка на непойми что. Скачать ничего не получилось. У тебя, кстати, нет раздела "Литература" в которой все используемые для написания статьи стандарты должны быть перечислены.
Стандарт кодирования ASN.1 всего один — X.609 (в статье говорится про последний стандарт на ASN.1). Всё остальное — вариации на тему. И для справки — никакие RFC стандартами не являются и расшифровывается эта аббревиатура как "Request For Comments", не более того. Для перехода в статус "стандарта" (по мнению IETF) RFC должно получить другое имя и стать STD.
YN>>А про PER — понимание вторичных кодировок (таких как PER) сложно без понимания BER. И интересы у всех людей разные — если кому нравится BER то они читают мою статью, если кому-то нравится PER — читают что-то другое или пишут свои прекрасные статьи. K>На самом деле, разобраться с BER не проблема, т.к. это TLV (кстати, что это за подход?). Реальная проблема это хитрые стандарты вроде PER которые используются в серьёзных системах и на практике народ имеет проблемы именно с ним и именно постое описание его они ищут в инете.
Напищи свою прекрасную статью про PER, если тебе интересно. Ну если сможешь, конечно
Здравствуйте, y-niko, Вы писали:
YN>Стандарт кодирования ASN.1 всего один — X.609 (в статье говорится про последний стандарт на ASN.1). Всё остальное — вариации на тему. И для справки — никакие RFC стандартами не являются и расшифровывается эта аббревиатура как "Request For Comments", не более того. Для перехода в статус "стандарта" (по мнению IETF) RFC должно получить другое имя и стать STD.
Это неверно. STD-номера просто ссылаются на RFC, которые получили статус стандартов. Не все RFC находятся на Standards Track и не все Standards Track документы в итоге становятся стандартами.
Здравствуйте, Kernan, Вы писали:
KA>>Как то не очень интересно в 21 веке .. K>На самом деле оно актуально в телекоме более, чем ты думаешь. Даже новые стандарты по LTE-A (к примеру) используют ASN.1 для описания протокола. А дальше всё просто, запихал описание в программу и она тебе сгенерила парсер и сопутствующий хлам..
Ага, вот тут описаны приключения человека, который делал реальный процессор SS7.
Спойлер: потребовалось написать специальный инструмент для разбора файлов MS Word 3.
Здравствуйте, y-niko, Вы писали:
YN>Стандарт кодирования ASN.1 всего один — X.609 (в статье говорится про последний стандарт на ASN.1).
Даже вики говорит, что их не 1, а 7. И что такое X.609 я не понимаю, может X.690? Кроме кодирования, есть стандарт описание самого языка. YN>Напищи свою прекрасную статью про PER, если тебе интересно. Ну если сможешь, конечно
Мне лениво что-то делать, особенно после попыток взять на слабо. Девушку свою на слабо бери, если она у тебя есть конечно же .
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, y-niko, Вы писали:
YN>>Стандарт кодирования ASN.1 всего один — X.609 (в статье говорится про последний стандарт на ASN.1). Всё остальное — вариации на тему. И для справки — никакие RFC стандартами не являются и расшифровывается эта аббревиатура как "Request For Comments", не более того. Для перехода в статус "стандарта" (по мнению IETF) RFC должно получить другое имя и стать STD. C>Это неверно. STD-номера просто ссылаются на RFC, которые получили статус стандартов. Не все RFC находятся на Standards Track и не все Standards Track документы в итоге становятся стандартами.
Из Википедии:
Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:
1) Выносится на всеобщее рассмотрение интернет-проект (Internet Draft). Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
2) Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.
3) Следующая стадия — проект стандарта (Draft Standard) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В проекты стандартов ещё могут вноситься мелкие правки, но они считаются достаточно стабильными и рекомендуются для реализации.
4) Высший уровень — стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.
5) Многие старые RFC замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус исторических (Historic)
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, y-niko, Вы писали:
YN>>Стандарт кодирования ASN.1 всего один — X.609 (в статье говорится про последний стандарт на ASN.1). K>Даже вики говорит, что их не 1, а 7. И что такое X.609 я не понимаю, может X.690? Кроме кодирования, есть стандарт описание самого языка. YN>>Напищи свою прекрасную статью про PER, если тебе интересно. Ну если сможешь, конечно K>Мне лениво что-то делать, особенно после попыток взять на слабо. Девушку свою на слабо бери, если она у тебя есть конечно же .
Мне 37 лет, и мне письками меряться уже давно не с кем — у меня всё-равно больше И статей у меня только на этом ресурсе уже 2 (первую из которых я написал аж 10 лет тому назад) в отличе от ленивых некоторых.
А со стандартом — да, перепутал местами две цифры.
Стандарт кодирования ASN.1 это X.690. Если всё-таки читать мою статью, то в ней прямо говорится, что обсуждение будет идти правил кодирования BER. Для них стандарт один.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kernan, Вы писали:
KA>>>Как то не очень интересно в 21 веке .. K>>На самом деле оно актуально в телекоме более, чем ты думаешь. Даже новые стандарты по LTE-A (к примеру) используют ASN.1 для описания протокола. А дальше всё просто, запихал описание в программу и она тебе сгенерила парсер и сопутствующий хлам.. C>Ага, вот тут описаны приключения человека, который делал реальный процессор SS7.
C>Спойлер: потребовалось написать специальный инструмент для разбора файлов MS Word 3.
C>http://laforge.gnumonks.org/weblog/2011/03/26/#20110326-parsing_dos_word_files_for_gsm_map
SS7 — это стэк протоколов, в поддержке отдельной реализации которого также участвовал и я, кстати говоря.
И лично знал многих из тех, кто очень успешно занимался разработкой всех уровней этого стэка.
Кстати в упомянутой статье говорится только про протокол MAP, протокол уровня приложения. До "реального процессора SS7" там как до Луны пешком.
Здравствуйте, y-niko, Вы писали:
YN>Мне 37 лет, и мне письками меряться уже давно не с кем — у меня всё-равно большеИ статей у меня только на этом ресурсе уже 2 (первую из которых я написал аж 10 лет тому назад) в отличе от ленивых некоторых. YN>А со стандартом — да, перепутал местами две цифры.
Как говорится, найдите в выделенном когнетивный диссонанс и расположите в нужном порядке. Игра для троллей от 2-х до 5-и лет. YN>Мне 37 лет
Аппеляция к возрасту...
Спасибо за статью (просвещение — дело нужное). Но нужно что-то делать со стилем изложения.
СЮ>Статья представляет собой описание принципов кодирования простейших типов в нотации ASN.1 BER. Приведены подробные примеры кодирования, рассмотрены сложные и не очевидные варианты кодируемых значений.
Дочитал пока до кодирования отрицательных целых чисел.
Автору удалось описать дополнительный код настолько бессвязно и косноязычно, что я так ничего и не понял до тех пор, пока не дочитал до фразы "А теперь приятная информация – в современных компьютерных системах целые числа (как положительные, так и отрицательные) автоматически кодируются и хранятся именно в том формате, который и был описан выше".
Юрий, скажите, как можно было написать вот такое: "Кодирование отрицательных целых построено так, что на самом деле кодируется не одно, а два целых значения – одно основное значение и другое целое значение, которое нужно вычесть из основного значения"? Я весь следующий абзац пытался найти намеки, в каком порядке эти значения записываются в поток вывода: сначала "основное", а затем "другое целое", или наоборот? И как они, собственно, разделяются?
Или вот прекрасный образчик потока сознания: "Так как число, которое надо вычесть из основного, должно быть больше основного числа, то кодирование отрицательных целых чисел начинается именно с выбора этого вычитаемого. Так как по правилам это вычитаемое должно разлагаться по основанию 256 так, чтобы все биты, кроме первого, представляющие индексы при соответствующих степенях 256, были равны 0, то ряд возможных вычитаемых представляет собой лидирующий октет 80 (1000 0000) и какое-то количество октетов 00, следующих за ним. То есть в качестве вычитаемых могут использоваться: 80256 (12810), ( 80 00 )256 (3276810), ( 80 00 00 )256 (838860810) и т.п.". Нет, если знать, о чем речь, то становится понятно: автор всего лишь хотел сказать, что отрицательные числа можно закодировать в бОльшее количество байт, чем минимально необходимо. Но это же и так азы!
Возможно, в стандарте описание всего этого счастья дано еще более косноязычно и бестолково. Но статья-то называется "простыми словами". Статья-то написана для людей, которые в компьютерах кой-чего понимают. Почему бы не использовать нормальную, устоявшуюся терминологию? Зачем своими словами пересказывать то, что и так известно каждому более-менее вменяемому программисту?
Честно говоря, от статьи с таким названием я ожидал гораздо менее формальной и более живой подачи материала. Не таблицы битов, а живые примеры с последующим разбором. Не нудное и невнятное описание вычитаний и оснований 256, а живые примеры кодирований чисел: вот тут у нас — бинарное число в дополнительном формате (обратите внимание — в формате big-endian), вот тут — число в виде строки (потому что флаги в заголовке такие-то), а вот тут у нас — напряглись, поднатужились — мантисса числа великой точности. Я вовсе не ожидаю, что после прочтения статьи я смогу во сне перечислить все возможные значения полей в служебных октетах. Как раз наоборот: ожидается, что в голове возникнет какая-то общая картина, что появится представление, как устроен протокол "с высоты птичьего полета".
Здравствуйте, Хреннос, Вы писали:
Х>Возможно, в стандарте описание всего этого счастья дано еще более косноязычно и бестолково. Но статья-то называется "простыми словами".
Стандарты как раз понятнее. Это несмотря на то, что ITU-T никогда не стремилась к излишней понятности
Здравствуйте, y-niko, Вы писали:
YN>SS7 — это стэк протоколов, в поддержке отдельной реализации которого также участвовал и я, кстати говоря. YN>И лично знал многих из тех, кто очень успешно занимался разработкой всех уровней этого стэка.
Ну дык. Я тоже знаю фанатов BDSM.
YN>Кстати в упомянутой статье говорится только про протокол MAP, протокол уровня приложения. До "реального процессора SS7" там как до Луны пешком.
Это часть OpenBTS/OpenBSC, которая таки полный стек реализует.
Здравствуйте, Хреннос, Вы писали:
Х>Спасибо за статью (просвещение — дело нужное). Но нужно что-то делать со стилем изложения.
Вполне допускаю, что именно для Вас мой стиль кажется странным и запутанным. А для кого-то он будет привлекательным и полезным.
Для кого-то описание дополнительного кода есть "азы", а кто-то об этом слышит в первый раз.
Так что Ваш "поток сознания" я также почитал, но замечаний как сделать статью лучше там не нашел. Но Ваше мнение я услышал, спасибо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, y-niko, Вы писали:
YN>>SS7 — это стэк протоколов, в поддержке отдельной реализации которого также участвовал и я, кстати говоря. YN>>И лично знал многих из тех, кто очень успешно занимался разработкой всех уровней этого стэка. C>Ну дык. Я тоже знаю фанатов BDSM.
YN>>Кстати в упомянутой статье говорится только про протокол MAP, протокол уровня приложения. До "реального процессора SS7" там как до Луны пешком. C>Это часть OpenBTS/OpenBSC, которая таки полный стек реализует.
Во-первых в OpenBTS нет реализации полного стека протоколов SS7, смотрите внимательнее документацию.
Во-вторых в моём комментарии я отвечал на замечание другого товарища о том, что якобы "вот в этой статье по ссылке был сделан реальный процессор SS7". Я ответил, что реализация только протокола МАР есть реализация только одного протокола из всего стека. И тут ваш комментарий что МАР реализован также и в OpenBTS, а вот там реализован полный стек протоколов. Этот протокол на самом деле много где реализован, и иногда даже там, где действительно есть реализация полного SS7. Как я понял вы хотели просто поделиться информацией (кстати ошибочной), а никак не отвечали на мой комментарий.
Здравствуйте, y-niko, Вы писали:
YN>Здравствуйте, Хреннос, Вы писали:
Х>>Спасибо за статью (просвещение — дело нужное). Но нужно что-то делать со стилем изложения. YN>Вполне допускаю, что именно для Вас мой стиль кажется странным и запутанным. А для кого-то он будет привлекательным и полезным.
Вопрос в количестве этих "кого-то".
Пока в теме отзывы преимущественно отрицательные.
YN>Для кого-то описание дополнительного кода есть "азы", а кто-то об этом слышит в первый раз.
Для тех, кто слышит о двоичном представлении чисел в первый раз, можно дать ссылку на википедию. Это действительно азы, безо всяких кавычек.
YN>Так что Ваш "поток сознания" я также почитал, но замечаний как сделать статью лучше там не нашел.
Жаль, жаль. Но ничего, я процитирую сам себя, и выделю ключевые моменты, чтобы они стали заметнее:
Честно говоря, от статьи с таким названием я ожидал гораздо менее формальной и более живой подачи материала. Не таблицы битов, а живые примеры с последующим разбором. Не нудное и невнятное описание вычитаний и оснований 256, а живые примеры кодирований чисел: вот тут у нас — бинарное число в дополнительном формате (обратите внимание — в формате big-endian), вот тут — число в виде строки (потому что флаги в заголовке такие-то), а вот тут у нас — напряглись, поднатужились — мантисса числа великой точности. Я вовсе не ожидаю, что после прочтения статьи я смогу во сне перечислить все возможные значения полей в служебных октетах. Как раз наоборот: ожидается, что в голове возникнет какая-то общая картина, что появится представление, как устроен протокол "с высоты птичьего полета".
YN>Но Ваше мнение я услышал, спасибо.
Судя по обиженному тону, мнение вы заслушали, но не услышали.
Раз уж пошёл разговор в глубину, постараюсь свести свои впечатления воедино. Для начала последовательно по тексту в порядке его чтения:
> ASN.1 создавался как некий общий стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте.
Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо.
> Здесь мы рассмотрим только самое сложное – двоичное кодирование (формат ASN.1 BER – Basic Encoding Rules).
BER не самое сложное. PER значительно сложнее.
> Данные, закодированные в формате ASN.1, представляют собой последовательность байт (или "октетов"), которые идут один за другим, без каких либо разрывов.
Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных.
> Часть идентификатора блока (до нескольких октетов).
Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более".
> Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: > 1000 0001 (81) > 1100 1001 (C9)
Тут в принципе верно, но стиль крайне неровный. Читателю потребуется самому совершить конверсии. Лучше было бы так:
"Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: длина длины (значение 129, или 0x81, то есть 128+1, где 1 — количество последующих октетов длины, и 201 (0xC9)."
Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000).
> Положительные целые числа в ASN.1 представляют собой последовательность "индексов" при соответствующих степенях разложения по основанию 256.
Тут уже потоптались без меня, не хочу повторять. Замечу лишь, что это очень хороший пример, почему исходная идея статьи — начинать с простых типов — была не вполне корректной. Если бы
а) вначале объяснили вообще представление беззнаковых и знаковых целых в BE октетной цепочке (для тех, кто этого не знает)
б) сказали бы, что оно применяется 1) в кодировании целых, 2) кодировании мантиссы в вещественных, 3) кодировании длины данного, если оно (грубо говоря) длиннее 127 октетов
— не нужно было бы косноязычить и заплетыком языкаться на таких простых вещах, и уж тем более не упоминать решение уравнений по основанию 256.
> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё.
Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной.
> Значение мантиссы числа представляет собой всегда беззнаковое целое.
Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос.
> Для примера возьмём число 0.15625. Для начала закодируем его в двоичном представлении по основанию 2. Коэффициенты разложения этого числа по основанию 2 будут находиться как: 0.1562510 = 1*2-3 + 1*2-5. То есть мантисса для нашего тестового числа будет иметь значение М = 1012, а значение экспоненты будет равно -5.
Я долго пытался понять, что такое 1012. Единственное верное прочтение — 101 в двоичной системе. Но в выбранном стиле эта двойка смещена так слабо, что практически не отличается в позиции от остальных. Надо было как-то иначе оформить.
> Теперь поставим дополнительное условие: значение мантиссы должно быть "нормализовано",
Без причины такое условие никому нафиг не надо. Надо было бы уточнить, например, "дополнительное требование для CER и DER для обеспечения единственности представления." Но для них всё равно требуется основание 2, а не 8 или 16.
> Кодирование отрицательных целых значений осуществляется по отдельным правилам. Фактически в закодированном отрицательном целом хранится не одно, а два целых числа: основное число и число, которое нужно вычесть из основного числа, чтобы при декодировании получить изначально закодированное отрицательное число.
Безумная форма описания дополнительного кода. Уже обсуждалось.
> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой).
Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому.
> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число).
Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов.
> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00).
Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации.
Во-первых, отличать их друг от друга жёстко нужно только в том случае, если это set, или они оба объявлены optional. Если sequence, и они оба обязательны, то никакой проблемы нет, на чтении будет обнаружено наличие двух REAL подряд, как и положено. Если первое обязательное, а после второго ничего нет, то достаточно самого факта присутствия или отсутствия второго значения. Если после второго другие типы (не REAL), то, аналогично, не требуется обёртка. Критерий здесь — наличие однозначного пути парсинга.
> Для внешней "обертки" используем класс тега PRIVATE (11) и номер тега выберем равный 2.
Как уже сказал — плохой, негодный метод. Для конкретной структуры (sequence), набора (set) положено вводить context-specific теги, пространство значений которых локально для данного группирующего контекста.
> В случае, когда между получателем закодированной информации и отправителем существует заранее согласованная и известная схема ASN.1-сообщений, то при использовании "оберточного кодирования" можно не указывать значение информационного октета для внутреннего, "обёрнутого", значения. В этом случае в качестве значения для "обёртки" будет уже использоваться примитивный тип,
Следовало бы сказать, что это зовётся implicit tagging, в отличие от ранее описанного explicit tagging. Тому, кто не знает описанных сущностей, будет крайне сложно понять, что имелось в виду. Далее, утверждение
> в качестве значения для "обёртки" будет уже использоваться примитивный тип,
я просто не смог распарсить. Implicit tagging означает, что тип вложенного значения известен на основании контекста и значения тега, и не нужно его описывать ещё раз. Что такое "примитивный тип"?
Primitive encoding? Если да, то зачем на это нажимать при описании? Это совершенно несущественно для описания различия между методами тегирования.
> В заключение скажу несколько слов о нотации, которой обозначаются "префиксные типы".
А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно.
Резюмирую.
1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна.
2. Ни одна из этих задач не решена. Для чтения дампов, например, главным вопросом является "мне тут поступило context-specific 0, и где искать, что это должно быть?", а также комплект стандартных граблей типа "если от SNMP устройства пришло C0 D1 E3 F3 в типе counter32, то это всё равно беззнаковое". Для создания — "а как надо сериализовать и нужно ли мне подымать полную машину включая ASN.1 compiler?"
Для просто интересующихся — эта статья способна только отбить интерес к теме. IMHO, лучше всего было бы начинать с того, что объяснить: "Посмотрите, как умные люди решают задачу платформенно-независимого представления любых данных, причём неограниченно расширяемо!" и уже от этого начинать плясать, через объяснения, зачем нужны те же классы, теги и длины (сразу на примерах); почему придумано constructed encoding; зачем нужны странности типа indefinite length; почему кодирование длинных тегов и OID'ов отличается от кодирования целых; показать представления с их вариантами; упомянуть пользу от CER и DER. Переходить ко всё более сложным; те же real'ы дать в самом конце.
3. Ну и язык надо исправлять везде и всюду. И попытки объяснять простое сложнейшими путями (типа решения уравнений по модулю 256) показывают, jIMHO, что у автора нет даже минимального опыта преподавания (такого, как рассказать что-то юным коллегам на работе).
Изначальная задумка интересна (на русском языке мало простых и внятных объяснений ASN.1). Но до адекватного состояния тут, увы, надо переделать чуть менее чем полностью.
Здравствуйте, y-niko, Вы писали:
YN>Как я понял вы хотели просто поделиться информацией (кстати ошибочной), а никак не отвечали на мой комментарий.
Смысл моего поста такой: ASN.1 — это полный BDSM. Использовать его по своему выбору может только полный извращенец.
Там где использовать его приходится (телефония, в основном) лучше взять готовые инструменты.
Здравствуйте, Kernan, Вы писали:
C>>Там где использовать его приходится (телефония, в основном) лучше взять готовые инструменты. K>Например? http://www.asnlab.com/asncpp/overview.html — для примера.
Х>Жаль, жаль. Но ничего, я процитирую сам себя, и выделю ключевые моменты, чтобы они стали заметнее:
Х>
Х>Честно говоря, от статьи с таким названием я ожидал гораздо менее формальной и более живой подачи материала. Не таблицы битов, а живые примеры с последующим разбором. Не нудное и невнятное описание вычитаний и оснований 256, а живые примеры кодирований чисел: вот тут у нас — бинарное число в дополнительном формате (обратите внимание — в формате big-endian), вот тут — число в виде строки (потому что флаги в заголовке такие-то), а вот тут у нас — напряглись, поднатужились — мантисса числа великой точности. Я вовсе не ожидаю, что после прочтения статьи я смогу во сне перечислить все возможные значения полей в служебных октетах. Как раз наоборот: ожидается, что в голове возникнет какая-то общая картина, что появится представление, как устроен протокол "с высоты птичьего полета".
YN>>Но Ваше мнение я услышал, спасибо.
Х>Судя по обиженному тону, мнение вы заслушали, но не услышали.
Ну уж и интонацию сообщений научились придумывать
А говорил я прежде всего о том, что если человек хочет улучшить статью то он приводит свои варианты того, что не нравится.
Пока из вашего комментария следует, что должен был примерно так написать про кодирование целых чисел:
"Для кодирования целых чисел используется дополнительный код. Каждый более-менее вменяемый программист должен его знать. Но если что-то непонятно то вот ссылка на Википедию. Ах да — иногда кодировать целые числа можно большим числом октетов чем это необходимо".
Напишите внятно, не косноязычно и понятно про дополнительный код, а потом и вместе обсудим что получиться.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Строжевский Юрий, Вы писали:
N>Раз уж пошёл разговор в глубину, постараюсь свести свои впечатления воедино. Для начала последовательно по тексту в порядке его чтения:
>> ASN.1 создавался как некий общий стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте.
N>Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо.
Думаю, что каждый может додумывать для чего именно создавался стандарт ASN.1. Сомневаюсь что вы являетесь здесь истиной в последней инстанции.
>> Здесь мы рассмотрим только самое сложное – двоичное кодирование (формат ASN.1 BER – Basic Encoding Rules).
N>BER не самое сложное. PER значительно сложнее.
Субъективное мнение. Для меня лично PER является "недо-ASN.1".
>> Данные, закодированные в формате ASN.1, представляют собой последовательность байт (или "октетов"), которые идут один за другим, без каких либо разрывов.
N>Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных.
Запомните раз и навсегда: нет такого "формата BER". BER расшифровывается как "Basic Encoding Rules". То есть это базовый набор правил кодирования. Все остальные "форматы" вроде DER и CER налагают только дополнительные ограничения на BER.
>> Часть идентификатора блока (до нескольких октетов).
N>Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более".
Мне слабо понятно почему это слово "часть" наводит на мысль, что остальная часть где-то спрятана.
>> Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: >> 1000 0001 (81) >> 1100 1001 (C9)
N>Тут в принципе верно, но стиль крайне неровный. Читателю потребуется самому совершить конверсии. Лучше было бы так:
N>"Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: длина длины (значение 129, или 0x81, то есть 128+1, где 1 — количество последующих октетов длины, и 201 (0xC9)."
N>Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000).
В статье в предыдущем параграфе разговор шел на уровне битового разбора, так что и пример также приведен с использованием двоичного разложения.
>> Положительные целые числа в ASN.1 представляют собой последовательность "индексов" при соответствующих степенях разложения по основанию 256.
N>Тут уже потоптались без меня, не хочу повторять. Замечу лишь, что это очень хороший пример, почему исходная идея статьи — начинать с простых типов — была не вполне корректной. Если бы N>а) вначале объяснили вообще представление беззнаковых и знаковых целых в BE октетной цепочке (для тех, кто этого не знает) N>б) сказали бы, что оно применяется 1) в кодировании целых, 2) кодировании мантиссы в вещественных, 3) кодировании длины данного, если оно (грубо говоря) длиннее 127 октетов N>- не нужно было бы косноязычить и заплетыком языкаться на таких простых вещах, и уж тем более не упоминать решение уравнений по основанию 256.
Что такое "представление беззнаковых и знаковых целых в BE октетной цепочке"?
И я тут уже выше одному оппоненту написал: считаете моё описание косноязычным — напишите своё и мы его пообсуждаем.
>> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё.
N>Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной.
Тип REAL содержит кодирование целых чисел. Моя статья умышленно построена на объяснении от сложных типов к простым.
>> Значение мантиссы числа представляет собой всегда беззнаковое целое.
N>Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос.
Хм, а в каком ещё "представлении" мантиса может иметь значение отличное от беззнакового целого?
>> Для примера возьмём число 0.15625. Для начала закодируем его в двоичном представлении по основанию 2. Коэффициенты разложения этого числа по основанию 2 будут находиться как: 0.1562510 = 1*2-3 + 1*2-5. То есть мантисса для нашего тестового числа будет иметь значение М = 1012, а значение экспоненты будет равно -5.
N>Я долго пытался понять, что такое 1012. Единственное верное прочтение — 101 в двоичной системе. Но в выбранном стиле эта двойка смещена так слабо, что практически не отличается в позиции от остальных. Надо было как-то иначе оформить.
Это издержки оформления на этом сайте. На своём сайте я постарался всё сделать красиво.
>> Теперь поставим дополнительное условие: значение мантиссы должно быть "нормализовано",
N>Без причины такое условие никому нафиг не надо. Надо было бы уточнить, например, "дополнительное требование для CER и DER для обеспечения единственности представления." Но для них всё равно требуется основание 2, а не 8 или 16.
Моя фраза относится к примеру кодирования числа REAL. То, что данное требование входит в число правил DER значения в рамках моей статьи не имеет.
>> Кодирование отрицательных целых значений осуществляется по отдельным правилам. Фактически в закодированном отрицательном целом хранится не одно, а два целых числа: основное число и число, которое нужно вычесть из основного числа, чтобы при декодировании получить изначально закодированное отрицательное число.
N>Безумная форма описания дополнительного кода. Уже обсуждалось.
Я уже сказал — напишите свой вариант.
>> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой).
N>Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому.
И что, мне отсылать читателя к стандарту? Типа "в вот ещё интересную информацию вы найдёте в X.690 в строке такой-то"?
>> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число).
N>Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов.
Именно "может", ибо я рассказываю про BER. Разберитесь для себя где есть разница между BER и DER.
>> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00).
N>Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации.
Почитайте стандарт: годится всё, кроме UNIVERSAL. Адекватность или неадекватность применения — это вопрос разрабатываемой схемы ASN.1 и выходит за рамки моей статьи.
N>Во-первых, отличать их друг от друга жёстко нужно только в том случае, если это set, или они оба объявлены optional. Если sequence, и они оба обязательны, то никакой проблемы нет, на чтении будет обнаружено наличие двух REAL подряд, как и положено. Если первое обязательное, а после второго ничего нет, то достаточно самого факта присутствия или отсутствия второго значения. Если после второго другие типы (не REAL), то, аналогично, не требуется обёртка. Критерий здесь — наличие однозначного пути парсинга.
Ну так я и написал "например при кодировании типа SET" и ранее написал "Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим".
>> Для внешней "обертки" используем класс тега PRIVATE (11) и номер тега выберем равный 2.
N>Как уже сказал — плохой, негодный метод. Для конкретной структуры (sequence), набора (set) положено вводить context-specific теги, пространство значений которых локально для данного группирующего контекста.
Как я и написал вопросы составления схем ASN.1 выходят за рамки моей статьи.
>> В случае, когда между получателем закодированной информации и отправителем существует заранее согласованная и известная схема ASN.1-сообщений, то при использовании "оберточного кодирования" можно не указывать значение информационного октета для внутреннего, "обёрнутого", значения. В этом случае в качестве значения для "обёртки" будет уже использоваться примитивный тип,
N>Следовало бы сказать, что это зовётся implicit tagging, в отличие от ранее описанного explicit tagging. Тому, кто не знает описанных сущностей, будет крайне сложно понять, что имелось в виду. Далее, утверждение
>> в качестве значения для "обёртки" будет уже использоваться примитивный тип,
N>я просто не смог распарсить. Implicit tagging означает, что тип вложенного значения известен на основании контекста и значения тега, и не нужно его описывать ещё раз. Что такое "примитивный тип"? N>Primitive encoding? Если да, то зачем на это нажимать при описании? Это совершенно несущественно для описания различия между методами тегирования.
>> В заключение скажу несколько слов о нотации, которой обозначаются "префиксные типы".
N>А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно.
Здесь я действитель отступил от общего стиля статьи, но только ради того, чтобы дать читателю информацию по совершенно неочевидной теме, в которой делают большинство ошибок даже "продвинутые" программисты. Эта информация будет нужна только в специфичных случаях.
N>Резюмирую.
N>1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна.
Вы выразитесь менее иносказаетльно — какие задачи я тут решал то по вашему мнению?
N>2. Ни одна из этих задач не решена. Для чтения дампов, например, главным вопросом является "мне тут поступило context-specific 0, и где искать, что это должно быть?", а также комплект стандартных граблей типа "если от SNMP устройства пришло C0 D1 E3 F3 в типе counter32, то это всё равно беззнаковое". Для создания — "а как надо сериализовать и нужно ли мне подымать полную машину включая ASN.1 compiler?"
N>Для просто интересующихся — эта статья способна только отбить интерес к теме. IMHO, лучше всего было бы начинать с того, что объяснить: "Посмотрите, как умные люди решают задачу платформенно-независимого представления любых данных, причём неограниченно расширяемо!" и уже от этого начинать плясать, через объяснения, зачем нужны те же классы, теги и длины (сразу на примерах); почему придумано constructed encoding; зачем нужны странности типа indefinite length; почему кодирование длинных тегов и OID'ов отличается от кодирования целых; показать представления с их вариантами; упомянуть пользу от CER и DER. Переходить ко всё более сложным; те же real'ы дать в самом конце.
N>3. Ну и язык надо исправлять везде и всюду. И попытки объяснять простое сложнейшими путями (типа решения уравнений по модулю 256) показывают, jIMHO, что у автора нет даже минимального опыта преподавания (такого, как рассказать что-то юным коллегам на работе).
N>Изначальная задумка интересна (на русском языке мало простых и внятных объяснений ASN.1). Но до адекватного состояния тут, увы, надо переделать чуть менее чем полностью.
Очень ценю ваши подробные комментарии! Правда, спасибо! И если считаете себя специалистом в области ASN.1 то напишите свою чудесную статью, увеличьте количество информации по ASN.1!
Здравствуйте, y-niko, Вы писали:
YN>А говорил я прежде всего о том, что если человек хочет улучшить статью то он приводит свои варианты того, что не нравится.
Понимаете, Юрий, некоторые вещи лучше переработать с нуля, нежели улучшать постепенно.
В случае данной статьи бессмысленно улучшать отдельные фрагменты. Это будет медленно, нервно, бестолково, а результат все равно будет недалек от оригинала.
Полностью переработать нужно несколько вещей. Постараюсь максимально подробно описать, как я это вижу:
Необходимо определить целевую аудиторию и писать статью именно для нее. Очевидно, что это не школьники (им ASN.1 нафиг не впился). Очевидно, что это люди, посещающие КЫВТ (статья выложена именно на нем). Очевидно, что это НЕ люди, профессионально и досконально разбирающиеся в протоколе ASN.1 (да, они могут прочитать статью из любопытства или ради прикола, но не ради получения полезных сведений — статья у нас называется "простыми словами"). Следовательно, аудитория статьи — люди, которым по долгу службы пришлось работать с ASN.1 и которые хотят понять, что это за зверь такой, и просто интересующиеся (типа меня) — слышали краем уха что-то и хотят получить общее представление о предмете. Следовательно, надо определить:
1 Уровень подачи материала. Мы пишем статью для начинающих, а не мануал для специалистов, поэтому не стоит вставлять в статью длинные списки, таблицы битовых полей и прочую конкретику. Конкретика — только там, где без этого не обойтись (при разборе конкретных примеров).
2 Стиль изложения. Бич русскоязычных технических статей — это суконность языка, наплевательское отношение к читателю ("кому надо — разберется"), громоздкие конструкции, полное отсутствие юмора. Гораздо приятнее читать статьи англоязычных авторов: они не вещают истину в последней инстанции, как это принято у нас. Они вместе с читателем открывают для себя тонкости описываемого протокола или явления. С оговорками ("вот этот аспект мы пока пропустим — он слишком сложен"), со ссылками на спецификации илистатьи, где предмет рассмотрен более углубленно.
3 Широта охвата темы. Очевидно, что начинающим гораздо полезнее дать общие принципы построения протокола, нежели чем ткнуть их носом в какую-то одну конкретную его область и начать знакомить с ее тонкостями. Тонкости (особенно если их много) лучше оставить на потом — как тему для других статей. Так мы и себе задел на будущее обеспечиваем, и читателя не отпугиваем обилием мелочей, которые непонятно, как применять.
YN>Пока из вашего комментария следует, что должен был примерно так написать про кодирование целых чисел: YN>"Для кодирования целых чисел используется дополнительный код.
Уже неплохо (заметим, это гораздо лучше ваших "двух чисел, которые надо вычесть одно из другого"). Только чуть больше конкретики:
Для кодирования целых чисел в BER используется знакомый каждому программисту дополнительный код(ссылка). Следует учесть, что порядок байт в протоколе ASN.1 — Big-endian(ссылка).
А еще я бы учел, что часть аудитории может быть незнакома с терминологией, используемой в телекоме, поэтому по ходу пьесы я бы объяснил, что такое "октет" и зачем он так назван.
YN>Каждый более-менее вменяемый программист должен его знать.
Суть верна, но. Фраза звучит по-гадски. Не стоит косвенно оскорблять читателя, называя его "невменяемым". Следует признать право читателя не знать многих, даже элементарных, вещей. Но и рассусоливать каждую мелочь тоже не нужно. Наиболее правильный подход — давать в статье краткое описание таких вещей, плюс ссылку на более полную статью или стандарт, если читателю захочется освежить память. Это своеобразный жест вежливости: вы не засираете текст тягомотными описаниями, но и не оставляете за бортом тех, кто кой-чего подзабыл.
Найти правильный баланс между краткостью и полнотой изложения — это и есть талант писателя (в т.ч. технических статей).
YN>Но если что-то непонятно то вот ссылка на Википедию.
Ссылку на википедию нужно давать без комментариев в стиле "гуру снисходит к дебилам". Это элементарная вежливость по отношению к читателю.
YN>Ах да — иногда кодировать целые числа можно большим числом октетов чем это необходимо".
Вот насчет количества байт в числе я бы остановился поподробнее (если это нужно). А если это не нужно для понимания протокола, значит, фраза просто создает лишний шум в голове у читателя, и я бы убрал ее вообще.
YN>Напишите внятно, не косноязычно и понятно про дополнительный код, а потом и вместе обсудим что получиться.
"Спердобейся", да?
Внятно, не косноязычно и понятно пишу про дополнительный код: "Для кодирования целых чисел в BER используется знакомый каждому программисту дополнительный код".
Но обсуждать тут абсолютно нечего: перед тем, как нырять в дебри словоблудия, нужно определить широту охвата темы (см. п. 3 выше). Вопрос стоит так: а стоит ли вообще обсуждать двоичное кодирование в статье такого уровня? Может быть, для этой статьи будет лучше просто рассказать читателю о том, какие типы кодирования имеются в ASN.1, нахрена их столько, и когда какой из них применяются? А более подробный разбор разных типов кодирования, может быть, лучше оставить на потом — для других ваших статей на ту же тему?
Мне очень жаль, что уровень комментариев на этом сайте столь низок.
Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль".
Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред.
Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может.
Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
На самом деле на сайте RSDN статья была выложена последней. До этого (за полгода до публикации на RSDN) она была опубликована на Хабре и на моём сайте.
Потом на моём сайте я опубликовал версию статьи с исправленными ошибками и неточностями. Но здесь никто (кроме редактора сайта, большое ему спасибо) не дал мне ни одного полезного замечания.
Больше замечаний мне дала жена, которая является профессиональным бухгалтером. Честно — я ожидал от местной аудитории бОльшего.
Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования). Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана. Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены. Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Здравствуйте, y-niko, Вы писали:
N>>Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо. YN>Думаю, что каждый может додумывать для чего именно создавался стандарт ASN.1. Сомневаюсь что вы являетесь здесь истиной в последней инстанции.
А ничего, что они явно упомянуты в ряде документов?
N>>Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных. YN>Запомните раз и навсегда: нет такого "формата BER". BER расшифровывается как "Basic Encoding Rules". То есть это базовый набор правил кодирования. Все остальные "форматы" вроде DER и CER налагают только дополнительные ограничения на BER.
Да, изобразить крик Вы смогли — "Запомните раз и навсегда". Только вот от того, называть BER правилами кодирования или форматом, неточностей на порядки меньше, чем называть их "ASN.1". Если у меня это максимум упрощение терминологии, не влияющее на понимание (и даже облегчающее для произвольного постороннего читателя), то у Вас — огрубление до полного бардака, потому что первая же встреча прочитавшего это с PER или XER введёт в когнитивный диссонанс. Как "вода, которая течёт вниз, хотя она течёт вверх" у египтян в Месопотамии.
>>> Часть идентификатора блока (до нескольких октетов). N>>Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более". YN>Мне слабо понятно почему это слово "часть" наводит на мысль, что остальная часть где-то спрятана.
Попробуйте взглянуть на текст, представив себе, что Вы ничего не знаете про предмет статьи.
N>>Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000). YN>В статье в предыдущем параграфе разговор шел на уровне битового разбора, так что и пример также приведен с использованием двоичного разложения.
Ну вот оно неровно. Или надо разжёвывать всё, и тогда сказать, что 201 == 0xC9. Или сократить, тогда в первую очередь не нужно битовое представление. Хотя я вижу, что Вы этот кусок практически передрали из X.690, пункт 8.1.3.5. Тогда неудивительно.
YN>Что такое "представление беззнаковых и знаковых целых в BE октетной цепочке"? YN>И я тут уже выше одному оппоненту написал: считаете моё описание косноязычным — напишите своё и мы его пообсуждаем.
Это вызов? Ну давайте попробую. Я даже никуда в сеть не заглядываю:
"Несколько слов про дополнительный код ((ссылка)) для тех, кто с ним не знаком. В дополнительном коде в представлении в N бит значения от 0 до 2**(N-1)-1 включительно (то есть те, у которых старший бит равен 0) означают равные им неотрицательные числа. Значения от 2**(N-1)-1 до 2**N-1 (то есть те, у которых старший бит равен 1) означают отрицательные числа от -2**(N-1) до -1 соответственно. Например, в 1 байте (8 бит) это от 0 до 127 и от -128 до -1; в 2 байтах (16 бит) — от 0 до 32767 и от -32768 до -1; и так далее.
Во внутреннем использовании компьютера обычно используются фиксированные количества бит в числовых действиях, в современных это в основном 4 или 8 октетов (32 и 64 бита соответственно), реже 1 или 2 байта (8 и 16 бит соответственно). Например, число 123 представляется как 7B, 00 7B, 00 00 00 7B или 00 00 00 00 00 00 00 7B. Аналогично, -120 представляется как 85, FF 85, FF FF FF 85, или FF FF FF FF FF FF FF 85. Для представлений в BER допускается произвольное количество октетов в представлении, но минимально необходимое для представления конкретного числа. Для примеров выше допускаются только однооктетные представления. Аналогично, например, число 987654 может быть представлено в трёх октетах как 0F 12 06, но равное ему представление 00 0F 12 06 уже запрещено. Число 127 ещё представляется как 7F, но 128 — уже как 00 80, потому что представление 80 значит -128, а не 128.
В примерах выше все числа были записаны так, что старшие цифры шли раньше в записи. Если их укладывать в память или в поток в том же порядке, получится так называемое big-endian представление ((ссылка)), в котором в октетах с меньшими адресами находятся старшие части числа. Это единственно допустимое представление для BER и потомков. Представление с обратным порядком, так называемое little-endian ((ссылка)), применяется во многих процессорах, как x86, но оно требует перестановки октетов для экспорта или импорта в BER.
Описанные правила применяются 1) для представления содержимого целого типа, 2) для представления мантиссы в содержимом вещественного типа (REAL), 3) для представления длины элемента, если она задана в длинной форме. В случае мантиссы в REAL она считается беззнаковой, правила дополнительного кода для отрицательных чисел не используются."
Я считаю, что это в разы понятнее, чем "... и число, которое надо вычесть из основного" или "решим уравнение" (которое тут нафиг не сдалось, зато способно отпугнуть 90% читающих). Если же кого-то надо учить таким основам, как двоичное представление чисел, 16-ричная система и т.д., то это надо делать отдельным документом (можно поставить на него ссылку).
>>> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё. N>>Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной. YN>Тип REAL содержит кодирование целых чисел. Моя статья умышленно построена на объяснении от сложных типов к простым.
Да, я уже прокомментировал, что это получилось методологически крайне неудобно. Это как учить первоклашек объяснению, что такое числа, в стиле Бурбаки. Не зря обычно учат от простого к сложному. Обратный подход постоянно порождает несуразности в изложении.
>>> Значение мантиссы числа представляет собой всегда беззнаковое целое. N>>Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос. YN>Хм, а в каком ещё "представлении" мантиса может иметь значение отличное от беззнакового целого?
В подавляющем большинстве представлений мантисса — нецелое значение, лежащее в диапазоне или 1<=M<b, или 1/b<=M<1, где b — основание системы счисления. Для нормализованных двоичных в IEEE754, например, это первый вариант, при b=2. Представление в BER отличается от них именно что принципиально, и это надо было подчеркнуть.
>>> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой). N>>Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому. YN>И что, мне отсылать читателя к стандарту? Типа "в вот ещё интересную информацию вы найдёте в X.690 в строке такой-то"?
Я про слово "фактически". Им принято вводить выводы, согласующиеся с фактами, но сделанные из ранее изложенного материала, а не другого источника. Если это правило изложено явно, то лучше написать где-то так: "Можно сказать иначе (и это явно сказано в X.690 пункт 8.3.2), что первые 9 бит представления целого числа не могут все совпадать друг с другом; такое совпадение означает, что можно устранить старший октет представления без ущерба для значения представленного числа."
>>> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число). N>>Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов. YN>Именно "может", ибо я рассказываю про BER. Разберитесь для себя где есть разница между BER и DER.
Это Вы разберитесь. Уже BER требует представления целого минимальным количеством октетов, независимо от знака. Процитировать, или сами найдёте? Зато оно почему-то не требует представления *длины* минимальной формой (то есть позволяет, например, 02, 81 02, 82 00 02, и так далее).
>>> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00). N>>Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации. YN>Почитайте стандарт: годится всё, кроме UNIVERSAL. Адекватность или неадекватность применения — это вопрос разрабатываемой схемы ASN.1 и выходит за рамки моей статьи.
Нет, это вопрос именно в рамках статьи, потому что не надо учить людей с самого начала плохому. Говоря "годится всё, кроме UNIVERSAL", Вы грубо вводите людей в заблуждение. Да, два объекта, один REAL, другой APPLICATION 0, будут различаться. Но два APPLICATION 0 будут путаться, даже если они "в душе" оба REAL! Точно так же как два PRIVATE 0 будут путаться. Но два CONTEXT 0 или невозможны согласно общим правилам ASN.1 (ещё до спускания на уровень BER), или являются грубой ошибкой кодирования. Принципиально тут именно различение тегов, между всеми значениями (в случае SET) или для однозначности разбора (в случае SEQUENCE).
В случае, если действовать по Вашему примеру (есть SET, внутри два REAL, надо различить, и на побочные эффекты плевать), а почему это UNIVERSAL не годится? Ну написали Вы вместо REAL — INTEGER, всё равно ведь сами разбираете? Различие достигнуто, а каким методом — неважно.
Итого: как в анекдоте, или трусы наденьте, или крестик снимите. Или мы используем таки BER для ASN.1, и тогда есть определённые правила, которые нельзя нарушать. Или мы его используем в сферическом вакууме, и тогда нам вообще всё пофиг, где какие типы и почему.
YN>Как я и написал вопросы составления схем ASN.1 выходят за рамки моей статьи.
Но всё равно для статьи надо брать адекватные примеры, даже если не объясняете, почему они взяты. Надеюсь, не нужно объяснять истока этого правила.
N>>А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно. YN>Здесь я действитель отступил от общего стиля статьи, но только ради того, чтобы дать читателю информацию по совершенно неочевидной теме, в которой делают большинство ошибок даже "продвинутые" программисты. Эта информация будет нужна только в специфичных случаях.
Это Вы так решили, что она "будет нужна только в специфичных случаях"? А почему? Обычный метод работы с ASN.1 таки начинается с составления схемы данных.
N>>Резюмирую.
N>>1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна. YN>Вы выразитесь менее иносказаетльно — какие задачи я тут решал то по вашему мнению?
Я дальше всё описал.
[...]
YN>Очень ценю ваши подробные комментарии! Правда, спасибо! И если считаете себя специалистом в области ASN.1 то напишите свою чудесную статью, увеличьте количество информации по ASN.1!
У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины. Всё-таки его использование чем дальше, тем меньшую долю составляет от всего, что есть в мире, и в моей практике он как-то не встречался ни разу, кроме суррогатов в виде SNMP.
Практически, все случаи, где бы оно могло применяться, у нас покрыты JSON'ом.
Здравствуйте, y-niko, Вы писали:
YN>Мне очень жаль, что уровень комментариев на этом сайте столь низок.
Извините за ещё один потенциально низкий комментарий, но рекомендую посмотреть в зеркало.
YN>Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль". YN>Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред. YN>Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может. YN>Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
Если четвёртый — это я, то с деталями плохо таки у Вас. Извините за назойливость.
А в общем, Хреннос прав, классическое "сперва добейся".
YN>Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
Я там рядом приводил ссылку, где я писал больше чем просто статью. Ещё я вёл курсы для сисадминов. Ещё у меня есть преподавательский опыт кроме этого. Но если считать критерием статьи именно для RSDN... Я не пишу ничего именно для RSDN, почти принципиально.
YN>На самом деле на сайте RSDN статья была выложена последней. До этого (за полгода до публикации на RSDN) она была опубликована на Хабре и на моём сайте.
Свой сайт — считайте, никто не увидел. Хабр очень неровен, выдержит всё, включая и такие статьи. И там очень специфический контингент — статья с чудовищными ляпами, но с кавайной картинкой, больше понравится, чем полностью правильная, но без картинок. Я бы не гордился этим, извините.
YN>Потом на моём сайте я опубликовал версию статьи с исправленными ошибками и неточностями. Но здесь никто (кроме редактора сайта, большое ему спасибо) не дал мне ни одного полезного замечания.
Потому что Вы все полезные замечания успешно проигнорировали.
YN>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования). Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана. Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены. Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Отлично. В таком случае прошу принять конструктивные замечания от меня и коллег Хреннос и Cyberax. (Впрочем, если Вы их заранее записали в помои, то итог будет неудивителен.)
Здравствуйте, netch80, Вы писали:
N>У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины.
Везде, где есть телефония все эти ваши SS7, GSM, UMTS, LTE, LTE-A — будут использовать ASN.1 до скончания времён наверное . В русскоговорящих странах эта информация практически не нужна, т.к. нет отрасли её использующей, поэтому если и писать статьи, то на английском .
Здравствуйте, Kernan, Вы писали:
N>>У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины. K>Везде, где есть телефония все эти ваши SS7, GSM, UMTS, LTE, LTE-A — будут использовать ASN.1 до скончания времён наверное .
"Узок их круг, страшно далеки они от народа." Я общался с H.323 и SNMP. Но вероятность встречи с кем-то ещё, имеющим такой опыт, чем дальше, тем уверенней стремится к 0.
K> В русскоговорящих странах эта информация практически не нужна, т.к. нет отрасли её использующей, поэтому если и писать статьи, то на английском .
Отрасль есть. Но её действительно настолько мало, что возиться с русским обычно невыгодно.
Здравствуйте, netch80, Вы писали:
N>"Узок их круг, страшно далеки они от народа." Я общался с H.323 и SNMP. Но вероятность встречи с кем-то ещё, имеющим такой опыт, чем дальше, тем уверенней стремится к 0.
О да. N>Отрасль есть. Но её действительно настолько мало, что возиться с русским обычно невыгодно.
Например? Что за конторы есть у нас которые производят оборудование или чипсеты для телекома? Я только интеграторов наблюдаю.
Здравствуйте, Kernan, Вы писали:
N>>Отрасль есть. Но её действительно настолько мало, что возиться с русским обычно невыгодно. K>Например? Что за конторы есть у нас которые производят оборудование или чипсеты для телекома? Я только интеграторов наблюдаю.
Зачем сразу чипсеты?
Вот тут я работаю (с перерывами) с ноября 2004-го.
Все решения построены как "стандартные серверы с собственным софтом". Не знаю, можно ли это считать интегратором.
Всего около 60 программистов (Киев, Чернигов, Сумы, несколько человек за пределами Украины).
Вся внутренняя кухня на SIP, но есть сопряжение с H.323.
Вот эта контора была вообще первой, кто запустил в Украине наложенные сервисы из серии "отправьте SMS на короткий номер", и сейчас обеспечивает их существенную часть. Её директор — мой старый знакомый и бывший коллега по ISP. В решениях тоже много всякого GSM и SS7 (в первую очередь в сопряжениях).
И да, я как-то ему (директору) помогал разбирать фигню в BER — когда он ещё сам это делал
Здравствуйте, y-niko, Вы писали:
YN>Мне очень жаль, что уровень комментариев на этом сайте столь низок.
Не соглашусь.
"Низкий уровень" — это когда комментарии идут уровня "гыгыгы", "кг/ам" или "пешы исчо".
Среди комментариев на вашу статью не было ни одного пустопорожнего. Были критические, были малоконструктивные (каюсь), были обсуждения каких-то малозначащих особенностей терминологии и протокола (заметим — в дискуссии активно участвовали вы сами).
YN>Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль". YN>Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред. YN>Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может. YN>Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
YN>Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
Другими словами, "вы все дураки и не лечитесь".
Понимаете, Юрий, мы ведь не со зла тут вас критикуем. Попытайтесь быть объективным: если бы не ваши попытки доказать оппонентам, что они дураки, дискуссия была бы гораздо продуктивнее и не свелась бы к "сперва добейся".
Что касается выделенного, поясню мою точку зрения: в статье подобной направленности ("протокол, вид сверху") и целевой аудитории (программисты и специалисты) не следует объяснять суть таких вещей, как представление чисел в двоичном виде. Достаточно упомянуть о существовании и привести ссылку на полное описание. Впрочем, если объяснение простое, а термин достаточно часто используемый и не всем читателям знаком, то можно и объяснить (как я это сделал бы для термина "октет").
YN>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования).
Жена — лицо заинтересованное, поэтому я бы не сильно доверял ее заверениям, что все читается легко и гладко.
YN>Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана.
В вашей квалификации как технического специалиста у меня лично нет никаких сомнений. Но для написания научно-популярных статей нужно быть больше, чем хорошим техническим специалистом.
Ваша статья (судя по заголовку) относится именно к таким — "просто о сложном". А вот написана она в стиле "сложно о простом", что, как бы, неожиданно для статей подобного плана.
YN>Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены.
Баз личных мнений, к сожалению, не обойтись. Впечатление от статьи, понятность формулировок — штука субъективная. Вы как автор вольны игнорировать мнения, которые лично вам кажутся неадекватными.
Очевидно, что если принимать во внимание все высказанные мнения, то ничего хорошего из этого не выйдет: на вкус и цвет товарищей нет.
Но также очевидно, что если игнорировать все мнения, не совпадающие с вашим собственным, то вы добровольно отсекаете от себя обратную связь, а значит, и возможность улучшить свой стиль.
Что касается "помоев" — вы сами их провоцируете, пытаясь поймать оппонентов на незнании или неумении что-то объяснить. Собственно, уже то, что вы используете в отношении высказавшихся здесь слово "оппонент", показательно: вы изначально ставите себя в позицию, когда любое критическое замечание в адрес вашей статьи надо обязательно опровергнуть. Гораздо конструктивнее было бы относиться к высказывающимся как к друзьям, а не врагам-оппонентам: не опровергать, а попросить объяснить; не ловить на незнании тонкостей, а выяснить, насколько вообще эти тонкости важны в рамках статьи.
YN>Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Юрий, ваше требование абсурдно.
Как я уже говорил, целевая аудитория вашей статьи — мало- и средне-знакомые с протоколом люди, которые по долгу службы или из любопытства хотели бы получить о нем представление. Вы же призываете их писать о том, о чем они пришли узнать от вас.
Здравствуйте, netch80, Вы писали:
K>>Везде, где есть телефония все эти ваши SS7, GSM, UMTS, LTE, LTE-A — будут использовать ASN.1 до скончания времён наверное . N>"Узок их круг, страшно далеки они от народа." Я общался с H.323 и SNMP. Но вероятность встречи с кем-то ещё, имеющим такой опыт, чем дальше, тем уверенней стремится к 0.
H.323 с его PER мало кто пинал напрямую, да. А вот бороться с (часто глючащим) SNMP приходилось многим.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
N>>>Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо. YN>>Думаю, что каждый может додумывать для чего именно создавался стандарт ASN.1. Сомневаюсь что вы являетесь здесь истиной в последней инстанции.
N>А ничего, что они явно упомянуты в ряде документов?
То есть моё "стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте" — это в корне ошибочное заявление, и официальная позиция только ваша?
N>>>Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных. YN>>Запомните раз и навсегда: нет такого "формата BER". BER расшифровывается как "Basic Encoding Rules". То есть это базовый набор правил кодирования. Все остальные "форматы" вроде DER и CER налагают только дополнительные ограничения на BER.
N>Да, изобразить крик Вы смогли — "Запомните раз и навсегда". Только вот от того, называть BER правилами кодирования или форматом, неточностей на порядки меньше, чем называть их "ASN.1". Если у меня это максимум упрощение терминологии, не влияющее на понимание (и даже облегчающее для произвольного постороннего читателя), то у Вас — огрубление до полного бардака, потому что первая же встреча прочитавшего это с PER или XER введёт в когнитивный диссонанс. Как "вода, которая течёт вниз, хотя она течёт вверх" у египтян в Месопотамии.
Во введении к статье я написал, что статья примеры в статье кодируются с применением правил BER. Где я там замещал BER на ASN.1 — мне непонятно.
>>>> Часть идентификатора блока (до нескольких октетов). N>>>Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более". YN>>Мне слабо понятно почему это слово "часть" наводит на мысль, что остальная часть где-то спрятана.
N>Попробуйте взглянуть на текст, представив себе, что Вы ничего не знаете про предмет статьи.
У меня нет такой аллергии на простое слово "часть".
N>>>Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000). YN>>В статье в предыдущем параграфе разговор шел на уровне битового разбора, так что и пример также приведен с использованием двоичного разложения.
N>Ну вот оно неровно. Или надо разжёвывать всё, и тогда сказать, что 201 == 0xC9. Или сократить, тогда в первую очередь не нужно битовое представление. Хотя я вижу, что Вы этот кусок практически передрали из X.690, пункт 8.1.3.5. Тогда неудивительно.
Я ещё раз повторю: ранее в статье я вел разговор на уровне битов. А то что двоичное представление в скобках дано в шестнадцатеричном формате, и это вам не нравится — пусть будет так.
YN>>Что такое "представление беззнаковых и знаковых целых в BE октетной цепочке"? YN>>И я тут уже выше одному оппоненту написал: считаете моё описание косноязычным — напишите своё и мы его пообсуждаем.
N>Это вызов? Ну давайте попробую. Я даже никуда в сеть не заглядываю:
N>"Несколько слов про дополнительный код ((ссылка)) для тех, кто с ним не знаком. В дополнительном коде в представлении в N бит значения от 0 до 2**(N-1)-1 включительно (то есть те, у которых старший бит равен 0) означают равные им неотрицательные числа. Значения от 2**(N-1)-1 до 2**N-1 (то есть те, у которых старший бит равен 1) означают отрицательные числа от -2**(N-1) до -1 соответственно. Например, в 1 байте (8 бит) это от 0 до 127 и от -128 до -1; в 2 байтах (16 бит) — от 0 до 32767 и от -32768 до -1; и так далее.
N>Во внутреннем использовании компьютера обычно используются фиксированные количества бит в числовых действиях, в современных это в основном 4 или 8 октетов (32 и 64 бита соответственно), реже 1 или 2 байта (8 и 16 бит соответственно). Например, число 123 представляется как 7B, 00 7B, 00 00 00 7B или 00 00 00 00 00 00 00 7B. Аналогично, -120 представляется как 85, FF 85, FF FF FF 85, или FF FF FF FF FF FF FF 85. Для представлений в BER допускается произвольное количество октетов в представлении, но минимально необходимое для представления конкретного числа. Для примеров выше допускаются только однооктетные представления. Аналогично, например, число 987654 может быть представлено в трёх октетах как 0F 12 06, но равное ему представление 00 0F 12 06 уже запрещено. Число 127 ещё представляется как 7F, но 128 — уже как 00 80, потому что представление 80 значит -128, а не 128.
N>В примерах выше все числа были записаны так, что старшие цифры шли раньше в записи. Если их укладывать в память или в поток в том же порядке, получится так называемое big-endian представление ((ссылка)), в котором в октетах с меньшими адресами находятся старшие части числа. Это единственно допустимое представление для BER и потомков. Представление с обратным порядком, так называемое little-endian ((ссылка)), применяется во многих процессорах, как x86, но оно требует перестановки октетов для экспорта или импорта в BER.
N>Описанные правила применяются 1) для представления содержимого целого типа, 2) для представления мантиссы в содержимом вещественного типа (REAL), 3) для представления длины элемента, если она задана в длинной форме. В случае мантиссы в REAL она считается беззнаковой, правила дополнительного кода для отрицательных чисел не используются."
N>Я считаю, что это в разы понятнее, чем "... и число, которое надо вычесть из основного" или "решим уравнение" (которое тут нафиг не сдалось, зато способно отпугнуть 90% читающих). Если же кого-то надо учить таким основам, как двоичное представление чисел, 16-ричная система и т.д., то это надо делать отдельным документом (можно поставить на него ссылку).
Насчет "дополнительного кода": для сведения на английском языке этот называется "two's complement binary number" из чего явно происходит его природа — представление в виде двух чисел. Попробуйте новичку сказать ваш первый абзац, а потом сказать мой вариант — два числа, вычитаемые одно из другого. Я считаю, что мой вариант гораздо ближе и к сути кодирования, и к человеку с его мышлением.
>>>> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё. N>>>Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной. YN>>Тип REAL содержит кодирование целых чисел. Моя статья умышленно построена на объяснении от сложных типов к простым.
N>Да, я уже прокомментировал, что это получилось методологически крайне неудобно. Это как учить первоклашек объяснению, что такое числа, в стиле Бурбаки. Не зря обычно учат от простого к сложному. Обратный подход постоянно порождает несуразности в изложении.
Это уже частное мнение.
>>>> Значение мантиссы числа представляет собой всегда беззнаковое целое. N>>>Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос. YN>>Хм, а в каком ещё "представлении" мантиса может иметь значение отличное от беззнакового целого?
N>В подавляющем большинстве представлений мантисса — нецелое значение, лежащее в диапазоне или 1<=M<b, или 1/b<=M<1, где b — основание системы счисления. Для нормализованных двоичных в IEEE754, например, это первый вариант, при b=2. Представление в BER отличается от них именно что принципиально, и это надо было подчеркнуть.
Вот тут уже вы явно заменяете понятия BER и ASN.1: представление мантиссы в виде целого числа характерно для ASN.1
>>>> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой). N>>>Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому. YN>>И что, мне отсылать читателя к стандарту? Типа "в вот ещё интересную информацию вы найдёте в X.690 в строке такой-то"?
N>Я про слово "фактически". Им принято вводить выводы, согласующиеся с фактами, но сделанные из ранее изложенного материала, а не другого источника. Если это правило изложено явно, то лучше написать где-то так: "Можно сказать иначе (и это явно сказано в X.690 пункт 8.3.2), что первые 9 бит представления целого числа не могут все совпадать друг с другом; такое совпадение означает, что можно устранить старший октет представления без ущерба для значения представленного числа."
Я написал по другому и смысл от этого остался прежним.
>>>> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число). N>>>Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов. YN>>Именно "может", ибо я рассказываю про BER. Разберитесь для себя где есть разница между BER и DER.
N>Это Вы разберитесь. Уже BER требует представления целого минимальным количеством октетов, независимо от знака. Процитировать, или сами найдёте? Зато оно почему-то не требует представления *длины* минимальной формой (то есть позволяет, например, 02, 81 02, 82 00 02, и так далее).
Да, здесь уже я подзабыл. Но для целей кодирования фактически применяется глагол "может", так как число закодированное в "длинной" форме по-сути имеет такое же значение как и число в "короткой".
>>>> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00). N>>>Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации. YN>>Почитайте стандарт: годится всё, кроме UNIVERSAL. Адекватность или неадекватность применения — это вопрос разрабатываемой схемы ASN.1 и выходит за рамки моей статьи.
N>Нет, это вопрос именно в рамках статьи, потому что не надо учить людей с самого начала плохому. Говоря "годится всё, кроме UNIVERSAL", Вы грубо вводите людей в заблуждение. Да, два объекта, один REAL, другой APPLICATION 0, будут различаться. Но два APPLICATION 0 будут путаться, даже если они "в душе" оба REAL! Точно так же как два PRIVATE 0 будут путаться. Но два CONTEXT 0 или невозможны согласно общим правилам ASN.1 (ещё до спускания на уровень BER), или являются грубой ошибкой кодирования. Принципиально тут именно различение тегов, между всеми значениями (в случае SET) или для однозначности разбора (в случае SEQUENCE).
Два CONTEXT 0 очень даже возможны. Просто при разборе значения будет невозможно определить что есть что (как впрочем и с двумя APPLICATION 0 и PRIVATE 0).
N>В случае, если действовать по Вашему примеру (есть SET, внутри два REAL, надо различить, и на побочные эффекты плевать), а почему это UNIVERSAL не годится? Ну написали Вы вместо REAL — INTEGER, всё равно ведь сами разбираете? Различие достигнуто, а каким методом — неважно.
N>Итого: как в анекдоте, или трусы наденьте, или крестик снимите. Или мы используем таки BER для ASN.1, и тогда есть определённые правила, которые нельзя нарушать. Или мы его используем в сферическом вакууме, и тогда нам вообще всё пофиг, где какие типы и почему.
YN>>Как я и написал вопросы составления схем ASN.1 выходят за рамки моей статьи.
N>Но всё равно для статьи надо брать адекватные примеры, даже если не объясняете, почему они взяты. Надеюсь, не нужно объяснять истока этого правила.
Все примеры, описанные в моей статье адекватны и проверены. Ваши претензии были высказаны только к каким-то частям моих высказываний.
Если найдёте некорректный пример — пишите.
N>>>А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно. YN>>Здесь я действитель отступил от общего стиля статьи, но только ради того, чтобы дать читателю информацию по совершенно неочевидной теме, в которой делают большинство ошибок даже "продвинутые" программисты. Эта информация будет нужна только в специфичных случаях.
N>Это Вы так решили, что она "будет нужна только в специфичных случаях"? А почему? Обычный метод работы с ASN.1 таки начинается с составления схемы данных.
Статья рассматривает исключительно только вопросы кодирования. Отступление было необходимо так как более наглядно показывало сущность "tagged values".
N>>>Резюмирую.
N>>>1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна. YN>>Вы выразитесь менее иносказаетльно — какие задачи я тут решал то по вашему мнению?
N>Я дальше всё описал.
N>[...]
YN>>Очень ценю ваши подробные комментарии! Правда, спасибо! И если считаете себя специалистом в области ASN.1 то напишите свою чудесную статью, увеличьте количество информации по ASN.1!
N>У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины. Всё-таки его использование чем дальше, тем меньшую долю составляет от всего, что есть в мире, и в моей практике он как-то не встречался ни разу, кроме суррогатов в виде SNMP. N>Практически, все случаи, где бы оно могло применяться, у нас покрыты JSON'ом.
У меня вопрос: эту вашу статью кто-нибудь читает? Уверен, что там написаны какие-то нужные факты, но я открыл первую часть и... Стили трафика? Изохронный? Наливной стиль трафика? Подложки, которые сгруппированы в классы? Вы стандартные книги по описанию протоколов читали или сами придумываете?
Что-то мне подсказывает, что если бы эти лекции и были кому-нибудь прочитаны пользы от них было бы мало. "Концентрация пищи для инженерного ума" тут чрезмерная Знаете, где-то услышал, что наиболее знающий человек это тот, который умеет просто объяснять самые сложные вещи. Вы наверное знающий, но с объяснениями на мой взгляд у вас туго.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
YN>>Мне очень жаль, что уровень комментариев на этом сайте столь низок.
N>Извините за ещё один потенциально низкий комментарий, но рекомендую посмотреть в зеркало.
Мне в зеркале комментарии искать?
YN>>Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль". YN>>Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред. YN>>Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может. YN>>Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
N>Если четвёртый — это я, то с деталями плохо таки у Вас. Извините за назойливость. N>А в общем, Хреннос прав, классическое "сперва добейся".
Про "сперва добейся" — это к чему?
YN>>Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
N>Я там рядом приводил ссылку, где я писал больше чем просто статью. Ещё я вёл курсы для сисадминов. Ещё у меня есть преподавательский опыт кроме этого. Но если считать критерием статьи именно для RSDN... Я не пишу ничего именно для RSDN, почти принципиально.
О, я почитал часть этой статьи. Мне искренне жаль ваших студентов.
YN>>На самом деле на сайте RSDN статья была выложена последней. До этого (за полгода до публикации на RSDN) она была опубликована на Хабре и на моём сайте.
N>Свой сайт — считайте, никто не увидел. Хабр очень неровен, выдержит всё, включая и такие статьи. И там очень специфический контингент — статья с чудовищными ляпами, но с кавайной картинкой, больше понравится, чем полностью правильная, но без картинок. Я бы не гордился этим, извините.
Здесь уровень комментариев и публики, увы, гораздо ниже чем на Хабре.
YN>>Потом на моём сайте я опубликовал версию статьи с исправленными ошибками и неточностями. Но здесь никто (кроме редактора сайта, большое ему спасибо) не дал мне ни одного полезного замечания.
N>Потому что Вы все полезные замечания успешно проигнорировали.
Замечания в стиле "а мне не нравится" были мною прокомметрированы как "предложите варианты". Единственный адекватный ответ здесь был ваш. Но вот только все-таки я считаю свой вариант проще и понятнее.
YN>>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования). Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана. Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены. Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
N>Отлично. В таком случае прошу принять конструктивные замечания от меня и коллег Хреннос и Cyberax. (Впрочем, если Вы их заранее записали в помои, то итог будет неудивителен.)
Вот последний то что вообще мне подсказал? Найдите хоть одно адекватное предложение от него
А замечания вида "надо всё переписать" это уже ерунда. Есть такая "болезнь" русских программистов — когда русский программист видит чужой код он всегда говорит "что за говно, надо переписать". Я к такому давно привык и такие общие "конструктивные замечания" игнорирую.
Здравствуйте, Хреннос, Вы писали:
Х>Здравствуйте, y-niko, Вы писали:
YN>>Мне очень жаль, что уровень комментариев на этом сайте столь низок.
Х>Не соглашусь.
Х>"Низкий уровень" — это когда комментарии идут уровня "гыгыгы", "кг/ам" или "пешы исчо".
Х>Среди комментариев на вашу статью не было ни одного пустопорожнего. Были критические, были малоконструктивные (каюсь), были обсуждения каких-то малозначащих особенностей терминологии и протокола (заметим — в дискуссии активно участвовали вы сами).
Конструктивный комментарий — это то, что описывает как проблему, так и возможное решение. Мнение вида "BER фигня, вот PER гораздо более интересен" и "очень косноязычно описано про дополнительный код" — это личные мнения. Замечания вида "надо всё переписать" — в ту же корзину. От предложений высказать как должно быть практически все оппоненты отказываются. Так что пока здесь класс обсуждающих мне кажется крайне низким.
YN>>Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль". YN>>Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред. YN>>Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может. YN>>Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
YN>>Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
Х>Другими словами, "вы все дураки и не лечитесь".
Х>Понимаете, Юрий, мы ведь не со зла тут вас критикуем. Попытайтесь быть объективным: если бы не ваши попытки доказать оппонентам, что они дураки, дискуссия была бы гораздо продуктивнее и не свелась бы к "сперва добейся".
Х>Что касается выделенного, поясню мою точку зрения: в статье подобной направленности ("протокол, вид сверху") и целевой аудитории (программисты и специалисты) не следует объяснять суть таких вещей, как представление чисел в двоичном виде. Достаточно упомянуть о существовании и привести ссылку на полное описание. Впрочем, если объяснение простое, а термин достаточно часто используемый и не всем читателям знаком, то можно и объяснить (как я это сделал бы для термина "октет").
Здесь в последнем абзаце противоречие: "не следует объяснять суть таких вещей, как представление чисел в двоичном виде" и "не всем читателям знаком, то можно и объяснить (как я это сделал бы для термина октет)".
Я ещё раз повторю, что читателей много и под каждого исправлять будет крайне затруднительно. Напишу я про октет, а завтра придёт ещё один знаток и будет стыдить, что я объясняю такие простые понятия.
YN>>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования).
Х>Жена — лицо заинтересованное, поэтому я бы не сильно доверял ее заверениям, что все читается легко и гладко.
Жена нашла мне две ошибки в кодировании и неточности в статье. Кстати в этом варианте статье по-моему две или три ошибки, но никто из "знатоков" так и не достиг уровня моей жены.
YN>>Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана.
Х>В вашей квалификации как технического специалиста у меня лично нет никаких сомнений. Но для написания научно-популярных статей нужно быть больше, чем хорошим техническим специалистом.
Х>Ваша статья (судя по заголовку) относится именно к таким — "просто о сложном". А вот написана она в стиле "сложно о простом", что, как бы, неожиданно для статей подобного плана.
Кто-то не понимает, кто-то понимает — это дело субъективное. Уверяю, что все кто действительно хотел прочитать мою статью успешно её поняли (я проверял).
YN>>Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены.
Х>Баз личных мнений, к сожалению, не обойтись. Впечатление от статьи, понятность формулировок — штука субъективная. Вы как автор вольны игнорировать мнения, которые лично вам кажутся неадекватными.
Х>Очевидно, что если принимать во внимание все высказанные мнения, то ничего хорошего из этого не выйдет: на вкус и цвет товарищей нет. Х>Но также очевидно, что если игнорировать все мнения, не совпадающие с вашим собственным, то вы добровольно отсекаете от себя обратную связь, а значит, и возможность улучшить свой стиль.
Х>Что касается "помоев" — вы сами их провоцируете, пытаясь поймать оппонентов на незнании или неумении что-то объяснить. Собственно, уже то, что вы используете в отношении высказавшихся здесь слово "оппонент", показательно: вы изначально ставите себя в позицию, когда любое критическое замечание в адрес вашей статьи надо обязательно опровергнуть. Гораздо конструктивнее было бы относиться к высказывающимся как к друзьям, а не врагам-оппонентам: не опровергать, а попросить объяснить; не ловить на незнании тонкостей, а выяснить, насколько вообще эти тонкости важны в рамках статьи.
Если будут высказаны корректные замечания, лишенные субъективных оценок и по возможности дополненные решением я всегда готов признавать свои ошибки.
И я оставляю за собой право высказываться максимально жестко при любой неточности в комментариях моих оппонентов.
YN>>Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Х>Юрий, ваше требование абсурдно. Х>Как я уже говорил, целевая аудитория вашей статьи — мало- и средне-знакомые с протоколом люди, которые по долгу службы или из любопытства хотели бы получить о нем представление. Вы же призываете их писать о том, о чем они пришли узнать от вас.
Это как в аудитории: одной половине лекция понятна, другой — нет. Есть неточность — поправьте. Непонятно — разбирайтесь в том что есть. Не устраивает этот вариант — ищите другие статьи или пишите свои. Может быть это и жесткое высказывание, но максимально отражающее положение вещей.
Здравствуйте, y-niko, Вы писали:
YN>Насчет "дополнительного кода": для сведения на английском языке этот называется "two's complement binary number" из чего явно происходит его природа — представление в виде двух чисел.
Лолчто???
Извините, вот после такого уже смешно дальше разговаривать, если всё Ваше описание было основано на этом безумном утверждении. Цитирую английскую википедию:
This is also equivalent to taking the ones' complement and then adding one, since the sum of a number and its ones' complement is all 1 bits.
В других источниках утверждается то же самое — это название фактически является анекдотом, когда перепутались "дополнение до единиц" и "дополнение до единицы", и термином "two's complement" (по-русски это должно звучать "дополнение до двух") было названо то, что по-нормальному должно было быть "zero's complement" ("дополнение до нуля") или "zeros' complement" ("дополнение до нулей").
Никаких двух чисел в Вашем понимании тут не предполагалось, это какой-то воспалённый бред, извините за откровенность.
Потому в русском эту идиому и не стали передавать, а ограничились нейтральным "дополнительный код".
YN> Попробуйте новичку сказать ваш первый абзац, а потом сказать мой вариант — два числа, вычитаемые одно из другого. Я считаю, что мой вариант гораздо ближе и к сути кодирования, и к человеку с его мышлением.
А я пытаясь вчитаться в Ваше описание чуть не спятил, настолько оно напоминает классическое (извините за длинную цитату):
-- Четыре тысячи двести шестьдесят восемь! Такой номер был
у одного паровоза в Печках. Этот паровоз стоял на шестнадцатом
пути. Его собирались увести на ремонт в депо Лысую-на-Лабе, но
не так-то это оказалось просто, господин фельдфебель, потому
что у старшего машиниста, которому поручили его туда перегнать,
была прескверная память на числа. Тогда начальник дистанции
позвал его в свою канцелярию и говорит: "На шестнадцатом пути
стоит паровоз номер четыре тысячи двести шестьдесят восемь. Я
знаю, у вас плохая память на цифры, а если вам записать номер
на бумаге, то вы бумагу эту также потеряете. Если у вас такая
плохая память на цифры, послушайте меня повнимательней. Я вам
докажу, что очень легко запомнить какой угодно номер. Так
слушайте: номер паровоза, который нужно увести в депо в
Лысую-на-Лабе,-- четыре тысячи двести шестьдесят восемь.
Слушайте внимательно. Первая цифра -- четыре, вторая -- два.
Теперь вы уже помните сорок два, то есть дважды два -- четыре,
это первая цифра, которая, разделенная на два, равняется двум,
и рядом получается четыре и два. Теперь не пугайтесь! Сколько
будет дважды четыре? Восемь, так ведь? Так запомните, что
восьмерка в номере четыре тысячи двести шестьдесят восемь будет
по порядку последней. После того как вы запомнили, что первая
цифра -- четыре, вторая -- два, четвертая -- восемь, нужно
ухитриться и запомнить эту самую шестерку, которая стоит перед
восьмеркой, а это очень просто. Первая цифра-- четыре, вторая--
два. а четыре плюс два -- шесть. Теперь вы уже точно знаете,
что вторая цифра от конца -- шесть; и теперь у вас этот порядок
цифр никогда не вылетит из головы. У вас в памяти засел номер
четыре тысячи двести шестьдесят восемь. Но вы можете прийти к
этому же результату еще проще...
Фельдфебель перестал курить, вытаращил на Швейка глаза и
только пролепетал:
-- Карре аb! / Снять головной убор! (нем.)/
Швейк продолжал вполне серьезно:
-- Тут он начал объяснять более простой способ запоминания
номера паровоза четыре тысячи двести шестьдесят восемь. "Восемь
без двух -- шесть. Теперь вы уже знаете шестьдесят восемь, а
шесть минус два -- четыре, теперь вы уже знаете четыре и
шестьдесят восемь, и если вставить эту двойку, то все это
составит четыре -- два -- шесть -- восемь. Не очень трудно
сделать это иначе, при помощи умножения и деления. Результат
будет тот же самый. Запомните,-- сказал начальник дистанции,--
что два раза сорок два равняется восьмидесяти четырем. В году
двенадцать месяцев. Вычтите теперь двенадцать из восьмидесяти
четырех, и останется семьдесят два, вычтите из этого числа еще
двенадцать месяцев, останется шестьдесят. Итак, у нас
определенная шестерка, а ноль зачеркнем. Теперь уже у нас сорок
два, шестьдесят восемь, четыре. Зачеркнем ноль, зачеркнем и
четверку сзади, и мы преспокойно опять получили четыре тысячи
двести шестьдесят восемь, то есть номер паровоза, который
следует отправить в депо в Лысую-на-Лабе. И с помощью деления,
как я уже говорил, это также очень легко. Вычисляем
коэффициент, согласно таможенному тарифу..." Вам дурно,
господин фельдфебель? Если хотите, я начну, например, с
"General de charge! Fertig! Hoch an! Feuer!" / Стрельба
залпами! (франц.) Готовьсь! На прицел! Пли! (нем.)/ Черт
подери! Господину капитану не следовало посылать вас на солнце.
Побегу за носилками.
Пришел доктор и констатировал, что налицо либо солнечный
удар, либо острое воспаление мозговых оболочек.
Заметьте, если бы Вы вместо этого сказали: "Попробуем представить двумя октетами. Вычтем 32639 из 2**16, что получится? вот результат и кладём в память" — всё было бы в разы проще и понятнее, и даже оправдало бы Вашу теорию про "разность двух чисел". Потому что она действительно верна, если докопаться до источников и взять "вторым числом" (на самом деле первым, потому что уменьшаемым) 2**N. Но то, что Вы вместо этого сделали, не лезет ни в какие ворота.
N>>В подавляющем большинстве представлений мантисса — нецелое значение, лежащее в диапазоне или 1<=M<b, или 1/b<=M<1, где b — основание системы счисления. Для нормализованных двоичных в IEEE754, например, это первый вариант, при b=2. Представление в BER отличается от них именно что принципиально, и это надо было подчеркнуть.
YN>Вот тут уже вы явно заменяете понятия BER и ASN.1: представление мантиссы в виде целого числа характерно для ASN.1
И точно так же используется в представлении в BER. Но я согласен с замечанием. Можно сказать и так.
N>>Нет, это вопрос именно в рамках статьи, потому что не надо учить людей с самого начала плохому. Говоря "годится всё, кроме UNIVERSAL", Вы грубо вводите людей в заблуждение. Да, два объекта, один REAL, другой APPLICATION 0, будут различаться. Но два APPLICATION 0 будут путаться, даже если они "в душе" оба REAL! Точно так же как два PRIVATE 0 будут путаться. Но два CONTEXT 0 или невозможны согласно общим правилам ASN.1 (ещё до спускания на уровень BER), или являются грубой ошибкой кодирования. Принципиально тут именно различение тегов, между всеми значениями (в случае SET) или для однозначности разбора (в случае SEQUENCE). YN>Два CONTEXT 0 очень даже возможны. Просто при разборе значения будет невозможно определить что есть что (как впрочем и с двумя APPLICATION 0 и PRIVATE 0).
Зависит от определения термина "возможны". Если так, чтобы не разобраться, где что было — насколько я знаю, компилятор такое не пустит.
N>>Но всё равно для статьи надо брать адекватные примеры, даже если не объясняете, почему они взяты. Надеюсь, не нужно объяснять истока этого правила. YN>Все примеры, описанные в моей статье адекватны и проверены. Ваши претензии были высказаны только к каким-то частям моих высказываний. YN>Если найдёте некорректный пример — пишите.
Я повторю, что включение PRIVATE в эту схему считаю методологически некорректным.
YN>У меня вопрос: эту вашу статью кто-нибудь читает? Уверен, что там написаны какие-то нужные факты, но я открыл первую часть и... Стили трафика? Изохронный? Наливной стиль трафика? Подложки, которые сгруппированы в классы? Вы стандартные книги по описанию протоколов читали или сами придумываете?
1. "Стандартные книги по описанию протоколов" игнорируют большинство поднятых мной вопросов. Я до сих пор не видел ни одну даже на английском, в которой бы обсуждались вопросы стиля трафика, а уж тем более на русском. С другой стороны, в спецификациях и стандартах эти понятия уже вовсю используются, и давно. Например, изохронный трафик описан в стандарте USB. "Наливной", да, мой термин, если видели лучше — предложите; но я сказал, что это bulk. Bulk traffic — общепринятый английский термин. Точно так же как синхронный (см. документы по RTP). В чём ещё замечания? Я пойду по Вашему пути: считаете, что что-то неправильно? Предлагайте. Я не становлюсь, в отличие от, в позу "я д'Артаньян, а вы все знаете кто", и, может, через год, но применю, если оно того стоит.
YN>Что-то мне подсказывает, что если бы эти лекции и были кому-нибудь прочитаны пользы от них было бы мало. "Концентрация пищи для инженерного ума" тут чрезмерная Знаете, где-то услышал, что наиболее знающий человек это тот, который умеет просто объяснять самые сложные вещи. Вы наверное знающий, но с объяснениями на мой взгляд у вас туго.
2. По факту я имею целую пачку "спасибо" за этот трактат, практически все — за упоминание примеров, которые можно брать за образцы, и за само по себе упоминание проблем, терминов и готовых решений. Я считаю, что свою задачу оно успешно выполняет.
YN>То есть моё "стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте" — это в корне ошибочное заявление, и официальная позиция только ваша?
Во-первых, Вы укоротили своё утверждение. Сразу же за этим следует фраза "Дополнительно нужно сказать, что стандарт ASN.1 кодирует информацию не в виде текста, а виде двоичных последовательностей." Она уже очевидно неверна, несмотря на кое-как влепленное замечание про XER. Но и процитированная Вами фраза, с одной стороны, некорректна, хотя бы по следующему:
* "произвольную" информацию — нигде такого не сказано; информация должна каким-то образом уложиться на правила ASN.1.
* "оторая бы понималась любым компьютером, имеющим представление об этом стандарте" — некорректно без учёта схемы данных; некорректно даже для BER! Потому что, получив INTEGER, мы не будем знать без схемы, что это — код ошибки, индекс сотрудника или количество транзакций за период.
а, с другой стороны, она неполна (это далеко не все цели). За пределами этого описания — сама задача по стандартизации схемы, по обеспечению совместимости между версиями, и многое другое, что не менее важно, а обычно и более. Для только цитированной фразы это неважно, но, когда Вы заявляете, цитирую, "Для начала поясню, для чего же создавался этот стандарт" — это уже становится некорректным.
YN>Во введении к статье я написал, что статья примеры в статье кодируются с применением правил BER. Где я там замещал BER на ASN.1 — мне непонятно.
Например, "бит 6 должен быть установлен в 0, если текущий блок содержит информацию только об одном значении, и должен быть установлен в 1, если внутри значения блока содержатся дополнительные ASN.1-кодированные блоки;" — это только BER!
А Ваше замечание про "далее по умолчанию BER, если не сказано обратное"... может, для черновика и годится. Однако статья, в которой в начале написано "далее мы, говоря "чёрное", будем подразумевать белое, а говоря "белое" — "чёрное"" — скорее всего не пройдёт редактора (и правильно).
N>>Попробуйте взглянуть на текст, представив себе, что Вы ничего не знаете про предмет статьи. YN>У меня нет такой аллергии на простое слово "часть".
Здравствуйте, y-niko, Вы писали:
N>>Если четвёртый — это я, то с деталями плохо таки у Вас. Извините за назойливость. N>>А в общем, Хреннос прав, классическое "сперва добейся". YN>Про "сперва добейся" — это к чему?
Про "сначала напишите сами что-то на RSDN, потом критикуйте".
YN>О, я почитал часть этой статьи. Мне искренне жаль ваших студентов.
Это было как раз не для студентов. Для студентов всё расписывается во много раз шире, и (по крайней мере вначале) не с такой плотностью примеров; ну и порядок изложения существенно меняются. Студентам надо давать одновременно очень простые примеры и базовую теорию (да хоть Шеннона), а затем набивать реальными примерами.
N>>Свой сайт — считайте, никто не увидел. Хабр очень неровен, выдержит всё, включая и такие статьи. И там очень специфический контингент — статья с чудовищными ляпами, но с кавайной картинкой, больше понравится, чем полностью правильная, но без картинок. Я бы не гордился этим, извините. YN>Здесь уровень комментариев и публики, увы, гораздо ниже чем на Хабре.
На Хабре к Вашей статье вообще ни одного замечания по сути, зато есть "из PDF'а лучше читать" и "а у нас в банке тоже с ASN.1 хотели работать". И да, один "а почему 128?" и ушёл, наверняка ничего не поняв. Это означает, что никто вообще ничего не понял в тексте, сказали "да, круто!" и побежали дальше. И что, это называется "уровень комментариев"? Это даже не студенты, те хотя бы десяток глупых вопросов задали бы.
YN>>>Потом на моём сайте я опубликовал версию статьи с исправленными ошибками и неточностями. Но здесь никто (кроме редактора сайта, большое ему спасибо) не дал мне ни одного полезного замечания. N>>Потому что Вы все полезные замечания успешно проигнорировали. YN>Замечания в стиле "а мне не нравится" были мною прокомметрированы как "предложите варианты". Единственный адекватный ответ здесь был ваш. Но вот только все-таки я считаю свой вариант проще и понятнее.
Спасибо за то, что признали адекватность Да, я тоже в такое попадаю регулярно, когда пытаюсь, например, объяснить что-то детям, что для меня очевидно, а для них — ново. Мне — просто и понятно. Им — надо всё разжевать с азов. Вы статью пишете для себя лично или для других?
N>>Отлично. В таком случае прошу принять конструктивные замечания от меня и коллег Хреннос и Cyberax. (Впрочем, если Вы их заранее записали в помои, то итог будет неудивителен.) YN>Вот последний то что вообще мне подсказал? Найдите хоть одно адекватное предложение от него
Согласен, именно по тексту статьи ничего не было (за его пределами — было). Тогда остаются два.
YN>А замечания вида "надо всё переписать" это уже ерунда. Есть такая "болезнь" русских программистов — когда русский программист видит чужой код он всегда говорит "что за говно, надо переписать". Я к такому давно привык и такие общие "конструктивные замечания" игнорирую.
Это общая болезнь и иногда такое переписывание даже полезно. Но для данной статьи вполне возможно обойтись рефакторингом: развернуть в порядок от простого к сложному, причесать терминологию, убрать смысловые диверсии — и получится вполне разумно.
Здравствуйте, y-niko, Вы писали:
YN>Жена нашла мне две ошибки в кодировании и неточности в статье. Кстати в этом варианте статье по-моему две или три ошибки, но никто из "знатоков" так и не достиг уровня моей жены.
Если в объяснении дополнительного кода, то, думаю, никто и не пытался, ибо бессмысленно
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
YN>>Жена нашла мне две ошибки в кодировании и неточности в статье. Кстати в этом варианте статье по-моему две или три ошибки, но никто из "знатоков" так и не достиг уровня моей жены.
N>Если в объяснении дополнительного кода, то, думаю, никто и не пытался, ибо бессмысленно
Да-да, характерный комментарий в стиле "не читал, но осуждаю".
Здравствуйте, y-niko, Вы писали:
YN>Конструктивный комментарий — это то, что описывает как проблему, так и возможное решение. Мнение вида "BER фигня, вот PER гораздо более интересен" и "очень косноязычно описано про дополнительный код" — это личные мнения. Замечания вида "надо всё переписать" — в ту же корзину. От предложений высказать как должно быть практически все оппоненты отказываются. Так что пока здесь класс обсуждающих мне кажется крайне низким.
Ключевое слово — "кажется".
Одно дело, когда вы пишете статью-справочник. Тогда да, стиль изложения по большому счету не важен, а ошибки и упущения очень легко обнаружить и отрапортовать в комментарии.
К сожалению, ваша статья — это не справочник, а научпоп (по крайней мере, ее название говорит именно об этом). Соответственно, фактические неточности не столь важны. Иногда в популяризаторских статьях сложные вещи специально упрощают для удобства понимания, опуская второстепенные детали.
В популяризаторских статьях критерии оценки кардинально другие: на первое место ставятся понятность изложения, простота понимания, образность, умение удержать внимание читателя. А это уже — личные мнения читателя, это уже не формализуешь и не проверишь по стандарту. Такие вещи нужно чувствовать.
Вы же пока стоит в позе д'Артаньяна среди низкопробных комментаторов, и требуете конструктива. Ну вот, к примеру, конструктив:
Попробуйте
YN>Здесь в последнем абзаце противоречие: "не следует объяснять суть таких вещей, как представление чисел в двоичном виде" и "не всем читателям знаком, то можно и объяснить (как я это сделал бы для термина октет)". YN>Я ещё раз повторю, что читателей много и под каждого исправлять будет крайне затруднительно. Напишу я про октет, а завтра придёт ещё один знаток и будет стыдить, что я объясняю такие простые понятия.
Да, вы абсолютно правильно заметили: здесь есть противоречие. И вы абсолютно правильно заметили, что у каждого читателя свое мнение. То есть, развивая этот тезис: противоречия при написании статьи есть всегда.
Так вот, талант писателя именно в том, чтобы найти компромисс между этими противоречиями.
В случае с моей фразой — объясню свою точку зрения. Исходим из того, что с двоичным представлением читатель знаком (ну или хотя бы слышал, что в компьютере числа хранятся в каком-то двоичном виде). Если браться описывать его в статье, то читатель, знакомый с двоичным кодированием, заскучает. Кроме того, описание получится довольно объемным, а статья-то не резиновая. Соответственно, можно просто сослаться на него по имени, а для интересующихся или подзабывших матчасть можно дать ссылку на википедию. Это компромисс между полнотой изложения и опусканием несущественных деталей.
С "октетом" история другая. Это термин, специфичный для телекома (ну, почти), и среднестатистический программист его вряд ли часто слышал. Объяснить его легко, поэтому объем статьи не сильно увеличится, а читатель, знакомый с термином, не успеет заскучать. Посему вполне логично дать объяснение этого термина, так сказать, инлайн.
Повторюсь — это моё личное мнение, и я его абсолютно не навязываю. Если вы считаете, что какой-то другой компромисс будет лучше — пожалуйста. Только неплохо бы, чтобы выбранное вами решение имело под собой рациональное зерно, а не просто было сделано в пику "оппонентам".
YN>>>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования).
Х>>Жена — лицо заинтересованное, поэтому я бы не сильно доверял ее заверениям, что все читается легко и гладко.
YN>Жена нашла мне две ошибки в кодировании и неточности в статье. Кстати в этом варианте статье по-моему две или три ошибки, но никто из "знатоков" так и не достиг уровня моей жены.
Как я уже говорил выше — вам указывают на ошибки немного другого рода.
Х>>Ваша статья (судя по заголовку) относится именно к таким — "просто о сложном". А вот написана она в стиле "сложно о простом", что, как бы, неожиданно для статей подобного плана.
YN>Кто-то не понимает, кто-то понимает — это дело субъективное. Уверяю, что все кто действительно хотел прочитать мою статью успешно её поняли (я проверял).
И вновь мы возвращаемся к вопросу аудитории. Заметьте: вы сейчас фактически ограничили аудиторию вашей статьи теми, "кто действительно хочет" ее прочитать и понять. А у действительно научно-популярной статьи аудитория не ограничивается энтузиастами. Наоборот: цель научпопа — привлечь даже тех, кто просто мимо пробегал.
YN>Если будут высказаны корректные замечания, лишенные субъективных оценок и по возможности дополненные решением я всегда готов признавать свои ошибки.
Формат вашей статьи фактически исключает такие комментарии.
YN>И я оставляю за собой право высказываться максимально жестко при любой неточности в комментариях моих оппонентов.
Позиция д'Артаньяна не поможет вам написать хорошую статью. Вы не оставляете читателю права на ошибку — а ведь формат статьи подразумевает, что читатель менее подкован в вопросах, которые затрагиваются в статье.
YN>>>Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Х>>Юрий, ваше требование абсурдно. Х>>Как я уже говорил, целевая аудитория вашей статьи — мало- и средне-знакомые с протоколом люди, которые по долгу службы или из любопытства хотели бы получить о нем представление. Вы же призываете их писать о том, о чем они пришли узнать от вас.
YN>Это как в аудитории: одной половине лекция понятна, другой — нет. Есть неточность — поправьте. Непонятно — разбирайтесь в том что есть. Не устраивает этот вариант — ищите другие статьи или пишите свои. Может быть это и жесткое высказывание, но максимально отражающее положение вещей.
И вновь позиция д'Артаньяна: "я вам дал Знание — а кто не понял, я не виноват".
Позиция комфортная, но, к сожалению, неконструктивная.
Здравствуйте, netch80, Вы писали:
YN>>А замечания вида "надо всё переписать" это уже ерунда. Есть такая "болезнь" русских программистов — когда русский программист видит чужой код он всегда говорит "что за говно, надо переписать". Я к такому давно привык и такие общие "конструктивные замечания" игнорирую.
N>Это общая болезнь и иногда такое переписывание даже полезно. Но для данной статьи вполне возможно обойтись рефакторингом: развернуть в порядок от простого к сложному, причесать терминологию, убрать смысловые диверсии — и получится вполне разумно.
Я процитирую ваше же высказываение "Но до адекватного состояния тут, увы, надо переделать чуть менее чем полностью".
И про "переворачивание порядка" я слышал уже не раз — порядок останется таким, каким он есть сейчас. Это особенность данной статьи.
Здравствуйте, y-niko, Вы писали:
YN>>>Жена нашла мне две ошибки в кодировании и неточности в статье. Кстати в этом варианте статье по-моему две или три ошибки, но никто из "знатоков" так и не достиг уровня моей жены. N>>Если в объяснении дополнительного кода, то, думаю, никто и не пытался, ибо бессмысленно YN>Да-да, характерный комментарий в стиле "не читал, но осуждаю".
Именно что *не* осуждают, потому что никто не стал вчитываться в необычно заумное объяснение общеизвестного и объясняемого значительно проще. Вот никто и не видит там ошибок.
Видимо, нашёл тот единственный комментатор с хабра, который задал вопрос по сути.
Но и то он молчит — наверно, ниасилил такое и нашёл альтернативу попроще.
Здравствуйте, y-niko, Вы писали:
N>>Это общая болезнь и иногда такое переписывание даже полезно. Но для данной статьи вполне возможно обойтись рефакторингом: развернуть в порядок от простого к сложному, причесать терминологию, убрать смысловые диверсии — и получится вполне разумно. YN>Я процитирую ваше же высказываение "Но до адекватного состояния тут, увы, надо переделать чуть менее чем полностью".
Переделать — да. Но именно "переписать с нуля" я не предлагал.
YN>И про "переворачивание порядка" я слышал уже не раз — порядок останется таким, каким он есть сейчас. Это особенность данной статьи.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
YN>>Насчет "дополнительного кода": для сведения на английском языке этот называется "two's complement binary number" из чего явно происходит его природа — представление в виде двух чисел.
N>Лолчто???
N>Извините, вот после такого уже смешно дальше разговаривать, если всё Ваше описание было основано на этом безумном утверждении. Цитирую английскую википедию:
N>
This is also equivalent to taking the ones' complement and then adding one, since the sum of a number and its ones' complement is all 1 bits.
N>В других источниках утверждается то же самое — это название фактически является анекдотом, когда перепутались "дополнение до единиц" и "дополнение до единицы", и термином "two's complement" (по-русски это должно звучать "дополнение до двух") было названо то, что по-нормальному должно было быть "zero's complement" ("дополнение до нуля") или "zeros' complement" ("дополнение до нулей").
N>Никаких двух чисел в Вашем понимании тут не предполагалось, это какой-то воспалённый бред, извините за откровенность. N>Потому в русском эту идиому и не стали передавать, а ограничились нейтральным "дополнительный код".
То воспалённый бред, то (ниже) моя теория про разность чисел верна. Вы как-то коррелируйте свои же комментарии.
И расскажите кому-нибудь про дополнение до единицы и до двух (особенно не программистам) — очень долго потом будете объяснять что это такое. А потом в конечном итоге придете к вычитанию двух чисел
YN>> Попробуйте новичку сказать ваш первый абзац, а потом сказать мой вариант — два числа, вычитаемые одно из другого. Я считаю, что мой вариант гораздо ближе и к сути кодирования, и к человеку с его мышлением.
N>А я пытаясь вчитаться в Ваше описание чуть не спятил, настолько оно напоминает классическое (извините за длинную цитату):
N>Заметьте, если бы Вы вместо этого сказали: "Попробуем представить двумя октетами. Вычтем 32639 из 2**16, что получится? вот результат и кладём в память" — всё было бы в разы проще и понятнее, и даже оправдало бы Вашу теорию про "разность двух чисел". Потому что она действительно верна, если докопаться до источников и взять "вторым числом" (на самом деле первым, потому что уменьшаемым) 2**N. Но то, что Вы вместо этого сделали, не лезет ни в какие ворота.
Я доволен тем, что я сделал. И уверен, что мои объяснения будут поняты бОльшим числом людей, нежели ваши.
N>>>Нет, это вопрос именно в рамках статьи, потому что не надо учить людей с самого начала плохому. Говоря "годится всё, кроме UNIVERSAL", Вы грубо вводите людей в заблуждение. Да, два объекта, один REAL, другой APPLICATION 0, будут различаться. Но два APPLICATION 0 будут путаться, даже если они "в душе" оба REAL! Точно так же как два PRIVATE 0 будут путаться. Но два CONTEXT 0 или невозможны согласно общим правилам ASN.1 (ещё до спускания на уровень BER), или являются грубой ошибкой кодирования. Принципиально тут именно различение тегов, между всеми значениями (в случае SET) или для однозначности разбора (в случае SEQUENCE). YN>>Два CONTEXT 0 очень даже возможны. Просто при разборе значения будет невозможно определить что есть что (как впрочем и с двумя APPLICATION 0 и PRIVATE 0).
N>Зависит от определения термина "возможны". Если так, чтобы не разобраться, где что было — насколько я знаю, компилятор такое не пустит.
Какой компилятор? Я вот свой написал, он пропустит. Или я скажем могу в шестнадцатиричном коде сразу написать такой случай. И он даже распарситься корректно.
Вопрос только в том, что _логически_ будет неясно что есть что, только и всего. А так все варианты допустимы.
N>>>Но всё равно для статьи надо брать адекватные примеры, даже если не объясняете, почему они взяты. Надеюсь, не нужно объяснять истока этого правила. YN>>Все примеры, описанные в моей статье адекватны и проверены. Ваши претензии были высказаны только к каким-то частям моих высказываний. YN>>Если найдёте некорректный пример — пишите.
N>Я повторю, что включение PRIVATE в эту схему считаю методологически некорректным.
Собственно почему? Вполне достойный кандидат.
YN>>У меня вопрос: эту вашу статью кто-нибудь читает? Уверен, что там написаны какие-то нужные факты, но я открыл первую часть и... Стили трафика? Изохронный? Наливной стиль трафика? Подложки, которые сгруппированы в классы? Вы стандартные книги по описанию протоколов читали или сами придумываете?
N>1. "Стандартные книги по описанию протоколов" игнорируют большинство поднятых мной вопросов. Я до сих пор не видел ни одну даже на английском, в которой бы обсуждались вопросы стиля трафика, а уж тем более на русском. С другой стороны, в спецификациях и стандартах эти понятия уже вовсю используются, и давно. Например, изохронный трафик описан в стандарте USB. "Наливной", да, мой термин, если видели лучше — предложите; но я сказал, что это bulk. Bulk traffic — общепринятый английский термин. Точно так же как синхронный (см. документы по RTP). В чём ещё замечания? Я пойду по Вашему пути: считаете, что что-то неправильно? Предлагайте. Я не становлюсь, в отличие от, в позу "я д'Артаньян, а вы все знаете кто", и, может, через год, но применю, если оно того стоит.
У меня других дел много и без вашей статьи. Просто почувствуйте разницу от конструктивной и не конструктивной критики.
Мне ваша статья просто не нравится и стиль её изложения меня ужасает. В добавок придумывание каких-то своих терминов создаёт огромные проблемы при дальнейшем изучении темы.
YN>>Что-то мне подсказывает, что если бы эти лекции и были кому-нибудь прочитаны пользы от них было бы мало. "Концентрация пищи для инженерного ума" тут чрезмерная Знаете, где-то услышал, что наиболее знающий человек это тот, который умеет просто объяснять самые сложные вещи. Вы наверное знающий, но с объяснениями на мой взгляд у вас туго.
N>2. По факту я имею целую пачку "спасибо" за этот трактат, практически все — за упоминание примеров, которые можно брать за образцы, и за само по себе упоминание проблем, терминов и готовых решений. Я считаю, что свою задачу оно успешно выполняет.
И что? Будем хвастаться у кого "спасибо" больше?
YN>>То есть моё "стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте" — это в корне ошибочное заявление, и официальная позиция только ваша?
N>Во-первых, Вы укоротили своё утверждение. Сразу же за этим следует фраза "Дополнительно нужно сказать, что стандарт ASN.1 кодирует информацию не в виде текста, а виде двоичных последовательностей." Она уже очевидно неверна, несмотря на кое-как влепленное замечание про XER. Но и процитированная Вами фраза, с одной стороны, некорректна, хотя бы по следующему: N>* "произвольную" информацию — нигде такого не сказано; информация должна каким-то образом уложиться на правила ASN.1. N>* "оторая бы понималась любым компьютером, имеющим представление об этом стандарте" — некорректно без учёта схемы данных; некорректно даже для BER! Потому что, получив INTEGER, мы не будем знать без схемы, что это — код ошибки, индекс сотрудника или количество транзакций за период.
N>а, с другой стороны, она неполна (это далеко не все цели). За пределами этого описания — сама задача по стандартизации схемы, по обеспечению совместимости между версиями, и многое другое, что не менее важно, а обычно и более. Для только цитированной фразы это неважно, но, когда Вы заявляете, цитирую, "Для начала поясню, для чего же создавался этот стандарт" — это уже становится некорректным.
Любая программа, умеющая парсить ASN.1, сможет понять тип, длину и значение любого ASN.1 кодированного сообщения. Информация о том, что именно означает вот именно этот INTEGER — за гранью этой статьи и в ней нет надобности при изучении общих правил кодирования.
YN>>Во введении к статье я написал, что статья примеры в статье кодируются с применением правил BER. Где я там замещал BER на ASN.1 — мне непонятно.
N>Например, "бит 6 должен быть установлен в 0, если текущий блок содержит информацию только об одном значении, и должен быть установлен в 1, если внутри значения блока содержатся дополнительные ASN.1-кодированные блоки;" — это только BER! N>А Ваше замечание про "далее по умолчанию BER, если не сказано обратное"... может, для черновика и годится. Однако статья, в которой в начале написано "далее мы, говоря "чёрное", будем подразумевать белое, а говоря "белое" — "чёрное"" — скорее всего не пройдёт редактора (и правильно).
Правило про "бит 6" верно для всех правил кодирования ASN.1 где собственно присутствует информация о длине значения.
Здравствуйте, y-niko, Вы писали:
YN>То воспалённый бред, то (ниже) моя теория про разность чисел верна. Вы как-то коррелируйте свои же комментарии.
Не Ваша. А то, что могло бы быть представлено тут, если бы Вы взяли правильную теорию и описали её как надо.
YN>И расскажите кому-нибудь про дополнение до единицы и до двух (особенно не программистам) — очень долго потом будете объяснять что это такое. А потом в конечном итоге придете к вычитанию двух чисел
Нет, не приду. Гораздо удобнее объяснять это через счётчик. Кстати, у Петцольда
объяснено именно через счётчик, и это всяко удобнее (напоминаю, что он писал даже не для программистов — а для американских школьников).
YN>Я доволен тем, что я сделал. И уверен, что мои объяснения будут поняты бОльшим числом людей, нежели ваши.
Пока что видим обратное. На хабре один сунулся, получил по мозгам и исчез. Тут хотя бы кто-то попытался осилить, и никто не сказал, что это лучше альтернатив, все говорят наоборот.
YN>Какой компилятор? Я вот свой написал, он пропустит.
N>>Я повторю, что включение PRIVATE в эту схему считаю методологически некорректным. YN>Собственно почему? Вполне достойный кандидат.
Аналогия: учим первоклашек арифметике. Пока что есть числа до 10. И рисуем, что 5+5=12, 5+6=13, и т.д. (числа от 10 записаны в восьмеричной). Потом, когда даём знание, что такое 10 и так далее, переключаемся на десятичную. Шок гарантирован. Взрослый, читающий про ASN.1, скорее всего шокирвоан не будет, но перечислит некоторые свойства Ваших родственников.
YN>У меня других дел много и без вашей статьи.
"А как пел..." простите, навеяло.
YN> Просто почувствуйте разницу от конструктивной и не конструктивной критики.
Ну я могу тоже гнать на Пушкина. Вы думаете, я не знаю этой разницы?
YN>Мне ваша статья просто не нравится и стиль её изложения меня ужасает. В добавок придумывание каких-то своих терминов создаёт огромные проблемы при дальнейшем изучении темы.
Факт хоть одной проблемы — в студию
YN>И что? Будем хвастаться у кого "спасибо" больше?
Почему нет? Только не "хвастаться", а спокойно сравнивать. Это тоже критерий (хотя далеко не единственный).
YN>Любая программа, умеющая парсить ASN.1, сможет понять тип, длину и значение любого ASN.1 кодированного сообщения.
В случае BER — да. В случае PER — уже нет. Вы опять путаете термины.
YN>Правило про "бит 6" верно для всех правил кодирования ASN.1 где собственно присутствует информация о длине значения.
О, появляются ранее не сформулированные ограничения. Это хорошо, результат становится более строгим.
Здравствуйте, Хреннос, Вы писали:
Х>Здравствуйте, y-niko, Вы писали:
YN>>Конструктивный комментарий — это то, что описывает как проблему, так и возможное решение. Мнение вида "BER фигня, вот PER гораздо более интересен" и "очень косноязычно описано про дополнительный код" — это личные мнения. Замечания вида "надо всё переписать" — в ту же корзину. От предложений высказать как должно быть практически все оппоненты отказываются. Так что пока здесь класс обсуждающих мне кажется крайне низким.
Х>Ключевое слово — "кажется".
Х>Одно дело, когда вы пишете статью-справочник. Тогда да, стиль изложения по большому счету не важен, а ошибки и упущения очень легко обнаружить и отрапортовать в комментарии.
Х>К сожалению, ваша статья — это не справочник, а научпоп (по крайней мере, ее название говорит именно об этом). Соответственно, фактические неточности не столь важны. Иногда в популяризаторских статьях сложные вещи специально упрощают для удобства понимания, опуская второстепенные детали. Х>В популяризаторских статьях критерии оценки кардинально другие: на первое место ставятся понятность изложения, простота понимания, образность, умение удержать внимание читателя. А это уже — личные мнения читателя, это уже не формализуешь и не проверишь по стандарту. Такие вещи нужно чувствовать.
Х>Вы же пока стоит в позе д'Артаньяна среди низкопробных комментаторов, и требуете конструктива. Ну вот, к примеру, конструктив:
Х>http://www.sciencedebate2008.com/popular-science-article-how-to-write/ (вкратце) Х>http://vikent.ru/enc/2670/ (длинновато, но по делу и с примерами)
Х>Попробуйте
Началось в того, что косноязычно написано про дополнительный код, заканчивается про правила написания научных статей
Послушайте, если нет желания (возможности) говорить про конкретные претензии к моей статье (например про то как надо переписать какое-то описание) то давайте лучше закончим этот разговор. Обсуждать что-то в стиле "грамма-наци" очень многие мастаки, но мне нужны замечания по моей статье конкретно.
Я — автор этой статьи, пишу авторский материал, которого нет не только в русскоязычном Интернете, но и в западном. Так что уж как пишу, так и пишу. Кстати у RSDN есть редактор, который предварительно эту статью отсматривал и достаточно долго. Всё прошло нормально
YN>>Здесь в последнем абзаце противоречие: "не следует объяснять суть таких вещей, как представление чисел в двоичном виде" и "не всем читателям знаком, то можно и объяснить (как я это сделал бы для термина октет)". YN>>Я ещё раз повторю, что читателей много и под каждого исправлять будет крайне затруднительно. Напишу я про октет, а завтра придёт ещё один знаток и будет стыдить, что я объясняю такие простые понятия.
Х>Да, вы абсолютно правильно заметили: здесь есть противоречие. И вы абсолютно правильно заметили, что у каждого читателя свое мнение. То есть, развивая этот тезис: противоречия при написании статьи есть всегда.
Х>Так вот, талант писателя именно в том, чтобы найти компромисс между этими противоречиями.
Х>В случае с моей фразой — объясню свою точку зрения. Исходим из того, что с двоичным представлением читатель знаком (ну или хотя бы слышал, что в компьютере числа хранятся в каком-то двоичном виде). Если браться описывать его в статье, то читатель, знакомый с двоичным кодированием, заскучает. Кроме того, описание получится довольно объемным, а статья-то не резиновая. Соответственно, можно просто сослаться на него по имени, а для интересующихся или подзабывших матчасть можно дать ссылку на википедию. Это компромисс между полнотой изложения и опусканием несущественных деталей. Х>С "октетом" история другая. Это термин, специфичный для телекома (ну, почти), и среднестатистический программист его вряд ли часто слышал. Объяснить его легко, поэтому объем статьи не сильно увеличится, а читатель, знакомый с термином, не успеет заскучать. Посему вполне логично дать объяснение этого термина, так сказать, инлайн.
Х>Повторюсь — это моё личное мнение, и я его абсолютно не навязываю. Если вы считаете, что какой-то другой компромисс будет лучше — пожалуйста. Только неплохо бы, чтобы выбранное вами решение имело под собой рациональное зерно, а не просто было сделано в пику "оппонентам".
Какое моё решение имеется в виду? Что я "октет" не объясняю?
YN>>>>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования).
Х>>>Жена — лицо заинтересованное, поэтому я бы не сильно доверял ее заверениям, что все читается легко и гладко.
YN>>Жена нашла мне две ошибки в кодировании и неточности в статье. Кстати в этом варианте статье по-моему две или три ошибки, но никто из "знатоков" так и не достиг уровня моей жены.
Х>Как я уже говорил выше — вам указывают на ошибки немного другого рода.
Пока мне указывают только на то, что кому-то нравится и не нравится. Ошибок никто мне не указал.
Х>>>Ваша статья (судя по заголовку) относится именно к таким — "просто о сложном". А вот написана она в стиле "сложно о простом", что, как бы, неожиданно для статей подобного плана.
YN>>Кто-то не понимает, кто-то понимает — это дело субъективное. Уверяю, что все кто действительно хотел прочитать мою статью успешно её поняли (я проверял).
Х>И вновь мы возвращаемся к вопросу аудитории. Заметьте: вы сейчас фактически ограничили аудиторию вашей статьи теми, "кто действительно хочет" ее прочитать и понять. А у действительно научно-популярной статьи аудитория не ограничивается энтузиастами. Наоборот: цель научпопа — привлечь даже тех, кто просто мимо пробегал.
И что, моё высказывание "кто-то не понимает, кто-то понимает — это дело субъективное" поменяет смысл от аудитории?
Для кого-то моя статья будет написана доступным языком, кто-то скажет что она ужасно запутана — всем не угодишь.
YN>>Если будут высказаны корректные замечания, лишенные субъективных оценок и по возможности дополненные решением я всегда готов признавать свои ошибки.
Х>Формат вашей статьи фактически исключает такие комментарии.
Это почему? И как относится к высказыванию замечаний формат статьи?
YN>>И я оставляю за собой право высказываться максимально жестко при любой неточности в комментариях моих оппонентов.
Х>Позиция д'Артаньяна не поможет вам написать хорошую статью. Вы не оставляете читателю права на ошибку — а ведь формат статьи подразумевает, что читатель менее подкован в вопросах, которые затрагиваются в статье.
Ошибься я — я признаю это. Ошибься оппонент — я укажу на его ошибки.
YN>>>>Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Х>>>Юрий, ваше требование абсурдно. Х>>>Как я уже говорил, целевая аудитория вашей статьи — мало- и средне-знакомые с протоколом люди, которые по долгу службы или из любопытства хотели бы получить о нем представление. Вы же призываете их писать о том, о чем они пришли узнать от вас.
YN>>Это как в аудитории: одной половине лекция понятна, другой — нет. Есть неточность — поправьте. Непонятно — разбирайтесь в том что есть. Не устраивает этот вариант — ищите другие статьи или пишите свои. Может быть это и жесткое высказывание, но максимально отражающее положение вещей.
Х>И вновь позиция д'Артаньяна: "я вам дал Знание — а кто не понял, я не виноват".
Х>Позиция комфортная, но, к сожалению, неконструктивная.
Я считаю эту позицию очень конструктивной. Нет никакой привязки к моей статье (можете искать другие), а если не найдёте другие — изучайте что есть. Не устраивает — пишите свои. Огромная свобода выбора.
И ещё раз — у меня нет желания переделывать статью под каждого, кто просто скажет "вот тут мне как-то не нравится". Я передалаю статью только в случае неточностей и ошибок. Пока никто на таковые мне не указал.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
YN>>То воспалённый бред, то (ниже) моя теория про разность чисел верна. Вы как-то коррелируйте свои же комментарии.
N>Не Ваша. А то, что могло бы быть представлено тут, если бы Вы взяли правильную теорию и описали её как надо.
А, ну то есть кто-то её до меня, такого умного, придумал? И моя теория значит "неправильная", а есть правильная?
YN>>И расскажите кому-нибудь про дополнение до единицы и до двух (особенно не программистам) — очень долго потом будете объяснять что это такое. А потом в конечном итоге придете к вычитанию двух чисел
N>Нет, не приду. Гораздо удобнее объяснять это через счётчик. Кстати, у Петцольда
объяснено именно через счётчик, и это всяко удобнее (напоминаю, что он писал даже не для программистов — а для американских школьников).
Скачал, почитал. Нет там про счетчики. Есть про инверсию битов.
Мне всё ещё кажется, что объяснение по принципу двух вычитаемых более органично и понятно
YN>>Я доволен тем, что я сделал. И уверен, что мои объяснения будут поняты бОльшим числом людей, нежели ваши.
N>Пока что видим обратное. На хабре один сунулся, получил по мозгам и исчез. Тут хотя бы кто-то попытался осилить, и никто не сказал, что это лучше альтернатив, все говорят наоборот.
Говорят пока только две людей, один из которых уже и не говорит — что-то вон про изменение стилистики статьи пытается рассказать.
YN>>Какой компилятор? Я вот свой написал, он пропустит.
N>
Я поясню — в мире великое множество компиляторов. Так что говорить "компилятор не пропустит" все-равно что говорить "кран не протекает" — необходимо конкретизировать объект.
N>>>Я повторю, что включение PRIVATE в эту схему считаю методологически некорректным. YN>>Собственно почему? Вполне достойный кандидат.
N>Аналогия: учим первоклашек арифметике. Пока что есть числа до 10. И рисуем, что 5+5=12, 5+6=13, и т.д. (числа от 10 записаны в восьмеричной). Потом, когда даём знание, что такое 10 и так далее, переключаемся на десятичную. Шок гарантирован. Взрослый, читающий про ASN.1, скорее всего шокирвоан не будет, но перечислит некоторые свойства Ваших родственников.
Здесь я уже вижу какой-то бред с вашей стороны.
Мы вроде бы про ASN.1 разговариваем, а не про десятичные и восмиричные числа. Вы ответьте — почему это вдруг PRIVATE не может быть использован? Что за идеология?
YN>>У меня других дел много и без вашей статьи.
N>"А как пел..." простите, навеяло.
Ну в "пении" и вам не откажешь
YN>> Просто почувствуйте разницу от конструктивной и не конструктивной критики.
N>Ну я могу тоже гнать на Пушкина. Вы думаете, я не знаю этой разницы?
Вижу, что уже начинаете понимать
YN>>Мне ваша статья просто не нравится и стиль её изложения меня ужасает. В добавок придумывание каких-то своих терминов создаёт огромные проблемы при дальнейшем изучении темы.
N>Факт хоть одной проблемы — в студию
Удивительно. То есть каждый преподаватель по вашему мнению может придумывать собственные термины и потом это не создаст проблем у студентов?
YN>>И что? Будем хвастаться у кого "спасибо" больше?
N>Почему нет? Только не "хвастаться", а спокойно сравнивать. Это тоже критерий (хотя далеко не единственный).
У нас нет одного доверенного "хранилища спасибок", так что сравнивание будет заведомо нечестным.
YN>>Любая программа, умеющая парсить ASN.1, сможет понять тип, длину и значение любого ASN.1 кодированного сообщения.
N>В случае BER — да. В случае PER — уже нет. Вы опять путаете термины.
PER — синтетический диалект, неотделимый от схемы. Причём для каждой схемы этот диалект может быть разным.
Но пусть даже вы и правы и говорить о чистом ASN.1 здесь некорректно.
YN>>Правило про "бит 6" верно для всех правил кодирования ASN.1 где собственно присутствует информация о длине значения.
N>О, появляются ранее не сформулированные ограничения. Это хорошо, результат становится более строгим.
Послушайте, я ведь знаю про ASN.1 никак не меньше вашего (а скорее всего и больше) и прекрасно знаю о большинстве "ограничений".
Я прекрасно представляю, что есть PER и XER, что есть схемы и многочисленные стандарты протоколов. Я работаю с ASN.1 уже более 10-ти лет.
Пытаться ловить меня на том, что "ага, а вот если эти правила использовать то выражение становиться ошибочным" — это я считаю достаточно низко и никому пользы не принесёт. Я просто начну писать более развёрнутые выражения, а это, смею вас уверить, у меня получается хорошо.
Прошу прощения за вмешательство, но уж очень интересная эта предметная область.
А именно: не найдётся ли у кого из вас исходного хода mib-compiler (или mib-browser) на Delphi.
Или может быть есть автономная dll (только не .net) с простым и понятным вызовом. Другими словами,
из набора MIB-файлов нужно сформировать дерево, где к каждому узлу было бы привязано описание OID и его числовое значение.
XML на выходе из какой-нибудь библиотеки тоже приемлем.
Готов оплатить хлопоты.
Здравствуйте, Alexio, Вы писали:
A>Уважаемые господа!
A>Прошу прощения за вмешательство, но уж очень интересная эта предметная область. A>А именно: не найдётся ли у кого из вас исходного хода mib-compiler (или mib-browser) на Delphi. A>Или может быть есть автономная dll (только не .net) с простым и понятным вызовом. Другими словами, A>из набора MIB-файлов нужно сформировать дерево, где к каждому узлу было бы привязано описание OID и его числовое значение. A>XML на выходе из какой-нибудь библиотеки тоже приемлем. A>Готов оплатить хлопоты.
Обратитесь на мой e-mail, есть на сайте www.strozhevsky.com
Здравствуйте, y-niko, Вы писали:
YN>>>То воспалённый бред, то (ниже) моя теория про разность чисел верна. Вы как-то коррелируйте свои же комментарии. N>>Не Ваша. А то, что могло бы быть представлено тут, если бы Вы взяли правильную теорию и описали её как надо. YN>А, ну то есть кто-то её до меня, такого умного, придумал?
Кого "её"?
YN> И моя теория значит "неправильная", а есть правильная?
Да. Это же очевидно по тому, что другие формы объяснения дополнительного кода встречаются и в учебниках, и в википедиях всяких, а такой выверт, как у Вас, нигде больше не находится, и никто его не понимает. Значит, она *методологически* неправильна.
N>>Нет, не приду. Гораздо удобнее объяснять это через счётчик. Кстати, у Петцольда
объяснено именно через счётчик, и это всяко удобнее (напоминаю, что он писал даже не для программистов — а для американских школьников). YN>Скачал, почитал. Нет там про счетчики. Есть про инверсию битов.
Глава 13. Можно это назвать и описанием через инверсию. Главное — понимание непрерывности стыка между представлениями -1 и 0, что и отличает дополнительный код от альтернатив (прямого и обратного кода), а у Вас это никак не отражается. Пусть даже это не было целью данного объяснения, но оно требует упоминания.
YN>Мне всё ещё кажется, что объяснение по принципу двух вычитаемых более органично и понятно
Со всякими "решим уравнение", пусть даже линейное? Очевидно, нет.
YN>>>Я доволен тем, что я сделал. И уверен, что мои объяснения будут поняты бОльшим числом людей, нежели ваши. N>>Пока что видим обратное. На хабре один сунулся, получил по мозгам и исчез. Тут хотя бы кто-то попытался осилить, и никто не сказал, что это лучше альтернатив, все говорят наоборот. YN>Говорят пока только две людей, один из которых уже и не говорит — что-то вон про изменение стилистики статьи пытается рассказать.
Потому что у него не хватает моральных сил лезть в Ваши "уравнения"
YN>>>Какой компилятор? Я вот свой написал, он пропустит. N>> YN>Я поясню — в мире великое множество компиляторов. Так что говорить "компилятор не пропустит" все-равно что говорить "кран не протекает" — необходимо конкретизировать объект.
Есть конкретизация по умолчанию: компилятор, соответствующий стандарту.
N>>>>Я повторю, что включение PRIVATE в эту схему считаю методологически некорректным. YN>>>Собственно почему? Вполне достойный кандидат. N>>Аналогия: учим первоклашек арифметике. Пока что есть числа до 10. И рисуем, что 5+5=12, 5+6=13, и т.д. (числа от 10 записаны в восьмеричной). Потом, когда даём знание, что такое 10 и так далее, переключаемся на десятичную. Шок гарантирован. Взрослый, читающий про ASN.1, скорее всего шокирвоан не будет, но перечислит некоторые свойства Ваших родственников. YN>Здесь я уже вижу какой-то бред с вашей стороны. YN>Мы вроде бы про ASN.1 разговариваем, а не про десятичные и восмиричные числа.
Слово "аналогия" есть в большинстве словарей. OK, конкретизирую: правильных словарей
YN> Вы ответьте — почему это вдруг PRIVATE не может быть использован? Что за идеология?
Это идеология ASN.1. Ваше замечание, по своей конструкции подразумевающее, что идеология тут является чем-то неуместным, само по себе неуместно в таком виде, из-за наличия чётко прописанных принципов построения представления (ещё до перехода на уровень битов и октетов).
N>>Ну я могу тоже гнать на Пушкина. Вы думаете, я не знаю этой разницы? YN>Вижу, что уже начинаете понимать
Боюсь, что это Ваша иллюзия, что я что-то "начинаю" тут понимать. Я понимал разницу между конструктивным и неконструктивным обсуждением очень давно, и стараюсь держаться в рамках конструктивности. Именно поэтому я трачу достаточно много времени на эти комментарии. Без этого проще было бы сказать "кг/ам" и посоветовать адекватный источник на английском. Например, статью Лаймана. Несмотря на то, что она датирована ещё 1993 годом, она актуальна, кроме мелких моментов, и по стилю превосходит не только Вашу, но и все другие встреченные мной источники. Если у меня будет сочетание времени и вдохновения, я не буду пытаться что-то делать с нуля — возьму её за основу, разве что чуть добавив вступительной "воды" с описаниями необходимости каждого элемента. По ясности изложения она, повторюсь, лучшая, и является отличным "предисловием" к собственно текстам стандартов.
YN>>>Мне ваша статья просто не нравится и стиль её изложения меня ужасает. В добавок придумывание каких-то своих терминов создаёт огромные проблемы при дальнейшем изучении темы. N>>Факт хоть одной проблемы — в студию YN>Удивительно. То есть каждый преподаватель по вашему мнению может придумывать собственные термины и потом это не создаст проблем у студентов?
Imago detected.
YN>>>Любая программа, умеющая парсить ASN.1, сможет понять тип, длину и значение любого ASN.1 кодированного сообщения. N>>В случае BER — да. В случае PER — уже нет. Вы опять путаете термины. YN>PER — синтетический диалект, неотделимый от схемы. Причём для каждой схемы этот диалект может быть разным. YN>Но пусть даже вы и правы и говорить о чистом ASN.1 здесь некорректно.
Спасибо. Давайте считать это ТЗ первого шага исправления статьи
YN>Послушайте, я ведь знаю про ASN.1 никак не меньше вашего (а скорее всего и больше) и прекрасно знаю о большинстве "ограничений". YN>Я прекрасно представляю, что есть PER и XER, что есть схемы и многочисленные стандарты протоколов. Я работаю с ASN.1 уже более 10-ти лет.
Именно. _Вы_ — работали. _Вы_ — знаете. Вы держите в голове все эти подводные камни. Новичок — не знает. Его слишком легко запутать сдвигом терминологии, напугать объяснениями типа "решим уравнение", счётом по основанию 256 (возможно, он до сих пор по 16 плохо умеет, надо ему помочь). Практическое знание и умение объяснять — слишком разные вещи. Я, заметьте, ни разу не сказал, что Вы плохо решаете задачи, связанные с ASN.1, пишете кривой код, или что-то подобное; для этого в любом случае тут нет материала, и, возможно, Вы это делаете лучше всех на планете Это возможно, и обратного никак не вытекает из того, что Вы плохо объясняете. Речь только про статью. Сейчас она — ужасна. (Зато мы уже знаем, как её исправить.)
YN>Пытаться ловить меня на том, что "ага, а вот если эти правила использовать то выражение становиться ошибочным" — это я считаю достаточно низко и никому пользы не принесёт. Я просто начну писать более развёрнутые выражения, а это, смею вас уверить, у меня получается хорошо.
Ура! Вот именно этого тут и добиваюсь я и все комментирующие. Невозможно быстро научить гениальной краткости, это особое умение. Но развернуть, пусть неудобно написанное, до понятного вида — это один из полезных промежуточных этапов. Далее, вероятно, Вы сами увидите, как сократить то, что стало ненужным. Так что ждём-с.
Здравствуйте, y-niko, Вы писали:
YN>Началось в того, что косноязычно написано про дополнительный код, заканчивается про правила написания научных статей
А вы таки почитайте. Там и про косноязычность есть.
YN>Я — автор этой статьи, пишу авторский материал, которого нет не только в русскоязычном Интернете, но и в западном. Так что уж как пишу, так и пишу. Кстати у RSDN есть редактор, который предварительно эту статью отсматривал и достаточно долго. Всё прошло нормально
"Мне 20 лет и я бородат". Извините, вырвалось.
Что касается редактуры статей на КЫВТе — дык, статьи нужны как воздух, поэтому берут все подряд. В прошлом году вон статью про криптографические фантазии
опубликовали.
YN>>>Здесь в последнем абзаце противоречие: "не следует объяснять суть таких вещей, как представление чисел в двоичном виде" и "не всем читателям знаком, то можно и объяснить (как я это сделал бы для термина октет)". YN>>>Я ещё раз повторю, что читателей много и под каждого исправлять будет крайне затруднительно. Напишу я про октет, а завтра придёт ещё один знаток и будет стыдить, что я объясняю такие простые понятия.
Еще раз повторю: на то у автора и голова на туловище растет, чтобы в подобных ситуациях искать компромисс.
Х>>Да, вы абсолютно правильно заметили: здесь есть противоречие. И вы абсолютно правильно заметили, что у каждого читателя свое мнение. То есть, развивая этот тезис: противоречия при написании статьи есть всегда.
Х>>Так вот, талант писателя именно в том, чтобы найти компромисс между этими противоречиями.
Х>>В случае с моей фразой — объясню свою точку зрения. Исходим из того, что с двоичным представлением читатель знаком (ну или хотя бы слышал, что в компьютере числа хранятся в каком-то двоичном виде). Если браться описывать его в статье, то читатель, знакомый с двоичным кодированием, заскучает. Кроме того, описание получится довольно объемным, а статья-то не резиновая. Соответственно, можно просто сослаться на него по имени, а для интересующихся или подзабывших матчасть можно дать ссылку на википедию. Это компромисс между полнотой изложения и опусканием несущественных деталей. Х>>С "октетом" история другая. Это термин, специфичный для телекома (ну, почти), и среднестатистический программист его вряд ли часто слышал. Объяснить его легко, поэтому объем статьи не сильно увеличится, а читатель, знакомый с термином, не успеет заскучать. Посему вполне логично дать объяснение этого термина, так сказать, инлайн.
Х>>Повторюсь — это моё личное мнение, и я его абсолютно не навязываю. Если вы считаете, что какой-то другой компромисс будет лучше — пожалуйста. Только неплохо бы, чтобы выбранное вами решение имело под собой рациональное зерно, а не просто было сделано в пику "оппонентам".
YN>Какое моё решение имеется в виду? Что я "октет" не объясняю?
Если бы вы прочитали написанное мной полностью, а не только последнюю фразу, вы бы поняли, какое решение имеется в виду.
Для экономии времени поясню: имеются в виду решения (что писать и что нет), которые вы будете принимать при написании следующих статей.
Х>>Как я уже говорил выше — вам указывают на ошибки немного другого рода.
YN>Пока мне указывают только на то, что кому-то нравится и не нравится. Ошибок никто мне не указал.
Нравится, не нравится, понятно, непонятно. Это и есть обратная связь от читателей научно-популярных статей. Именно по таким нечетким и расплывчатым маркерам авторы и совершенствуют свой стиль.
Х>>>>Ваша статья (судя по заголовку) относится именно к таким — "просто о сложном". А вот написана она в стиле "сложно о простом", что, как бы, неожиданно для статей подобного плана.
YN>>>Кто-то не понимает, кто-то понимает — это дело субъективное. Уверяю, что все кто действительно хотел прочитать мою статью успешно её поняли (я проверял).
Х>>И вновь мы возвращаемся к вопросу аудитории. Заметьте: вы сейчас фактически ограничили аудиторию вашей статьи теми, "кто действительно хочет" ее прочитать и понять. А у действительно научно-популярной статьи аудитория не ограничивается энтузиастами. Наоборот: цель научпопа — привлечь даже тех, кто просто мимо пробегал.
YN>И что, моё высказывание "кто-то не понимает, кто-то понимает — это дело субъективное" поменяет смысл от аудитории? YN>Для кого-то моя статья будет написана доступным языком, кто-то скажет что она ужасно запутана — всем не угодишь.
Автор научно- популярной статьи должен стремиться расширить свою аудиторию. Это вроде бы очевидно, не так ли? На то она и популярная, на то она и "просто о сложном".
Вы же не только не стремитесь к расширению аудитории, вы ее осознанно сокращаете. Это ошибка (надеюсь, я достаточно конкретно объяснил? ).
YN>>>Если будут высказаны корректные замечания, лишенные субъективных оценок и по возможности дополненные решением я всегда готов признавать свои ошибки.
Х>>Формат вашей статьи фактически исключает такие комментарии.
YN>Это почему? И как относится к высказыванию замечаний формат статьи?
Формат статьи прямо влияет на замечания к ней.
Если статья техническая, а ее целевая аудитория — узкие специалисты, то замечания будут по фактическому наполнению статьи. Замечания по стилю изложения, грамматике и построению — неформат, потому как специалист, если надо, ее перечитает.
А вот если статья популяризаторская, то замечания совсем другие. Для такой статьи главное — понятность, интересность, легкость освоения материала. Технических данных в статье может быть совсем немного (ее цель — ознакомить, а не дать всеобъемлющее представление). Соответственно, комментарии к таким статьям в основном фокусируются на стиле изложения, понятности, интересности и прочих плохо формализуемых вещах.
Что касается вопроса "почему" — отвечаю: очевидно, потому, что ваша статья популяризаторская.
YN>Я считаю эту позицию очень конструктивной. Нет никакой привязки к моей статье (можете искать другие), а если не найдёте другие — изучайте что есть. Не устраивает — пишите свои. Огромная свобода выбора.
По сути, ваша позиция сводится к фразе "я умываю руки".
YN>И ещё раз — у меня нет желания переделывать статью под каждого, кто просто скажет "вот тут мне как-то не нравится". Я передалаю статью только в случае неточностей и ошибок. Пока никто на таковые мне не указал.
Юрий, так вас же не просят переделывать под каждого. Вам как автору высказан некий (немалый) объем замечаний по стилю, построению, наполнению вашей статьи. Теперь вы, как автор, можете (подчеркиваю — можете, вас никто не обязывает) рассмотреть эти замечания, сделать для себя выводы и использовать их в своей дальнейшей работе. А будет ли эта работа связана с улучшением этой статьи, или же это будет совсем другая статья — не суть важно.
Пока же вы отгородились от всех замечаний ("не вижу конструктива"), умыли руки и фактически отказываетесь что-либо менять. Это, конечно, ваше святое право. К сожалению, результат обычно плачевен: следующая статья или не получает никаких откликов вообще (проваливается в вакуум), или получает шквал отрицательных откликов. И следующая. И следующая. Поверьте, я видел довольно много начинающих авторов. Огораживание от мнения читателей ни одному начинающему автору не помогло стать лучше, а вот отбить желание писать может запросто.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
YN>>>>Я доволен тем, что я сделал. И уверен, что мои объяснения будут поняты бОльшим числом людей, нежели ваши. N>>>Пока что видим обратное. На хабре один сунулся, получил по мозгам и исчез. Тут хотя бы кто-то попытался осилить, и никто не сказал, что это лучше альтернатив, все говорят наоборот. YN>>Говорят пока только две людей, один из которых уже и не говорит — что-то вон про изменение стилистики статьи пытается рассказать.
N>Потому что у него не хватает моральных сил лезть в Ваши "уравнения"
И это тоже.
Но основная причина в другом. Я считаю что в статье об ASN вообще не должно быть описаний сторонних форматов — на это есть ссылки. Представление чисел в дополнительном коде используется в огромном множестве областей, и найти внятное описание абсолютно не проблема (можно и несколько ссылок привести — на выбор). Ничего специфичного именно для ASN в дополнительном коде нет, поэтому вставлять его описание в статью значит перегружать ее абсолютно лишним материалом.
Об этом я высказался, я считаю, достаточно определенно. Так зачем повторяться-то?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
YN>>>>То воспалённый бред, то (ниже) моя теория про разность чисел верна. Вы как-то коррелируйте свои же комментарии. N>>>Не Ваша. А то, что могло бы быть представлено тут, если бы Вы взяли правильную теорию и описали её как надо. YN>>А, ну то есть кто-то её до меня, такого умного, придумал?
N>Кого "её"?
Мда...теорию, мы про неё и рассуждаем.
YN>> И моя теория значит "неправильная", а есть правильная?
N>Да. Это же очевидно по тому, что другие формы объяснения дополнительного кода встречаются и в учебниках, и в википедиях всяких, а такой выверт, как у Вас, нигде больше не находится, и никто его не понимает. Значит, она *методологически* неправильна.
Я лично знаю людей, которые эту простую формулу про разность двух чисел прекрасно понимают.
N>>>Нет, не приду. Гораздо удобнее объяснять это через счётчик. Кстати, у Петцольда
объяснено именно через счётчик, и это всяко удобнее (напоминаю, что он писал даже не для программистов — а для американских школьников). YN>>Скачал, почитал. Нет там про счетчики. Есть про инверсию битов.
N>Глава 13. Можно это назвать и описанием через инверсию. Главное — понимание непрерывности стыка между представлениями -1 и 0, что и отличает дополнительный код от альтернатив (прямого и обратного кода), а у Вас это никак не отражается. Пусть даже это не было целью данного объяснения, но оно требует упоминания.
Я просто резюмирую: нет в этой книге простого и удобного объяснения, тем более с помощью "счетчиков".
YN>>Мне всё ещё кажется, что объяснение по принципу двух вычитаемых более органично и понятно
N>Со всякими "решим уравнение", пусть даже линейное? Очевидно, нет.
Давайте так: вам надо вычислить как будет представляться число -100 в дополнительном коде. Уверяю вас, так или иначе здесь будет применено простейшее вычитание двух чисел.
И я уже устаю от какой-то истерии вокруг уравнения для первого класса: вычесть большее число из меньшего. И у меня просто не укладывается в голове, что люди, которые говорят что они программисты, считают этот подход сложным.
YN>>>>Я доволен тем, что я сделал. И уверен, что мои объяснения будут поняты бОльшим числом людей, нежели ваши. N>>>Пока что видим обратное. На хабре один сунулся, получил по мозгам и исчез. Тут хотя бы кто-то попытался осилить, и никто не сказал, что это лучше альтернатив, все говорят наоборот. YN>>Говорят пока только две людей, один из которых уже и не говорит — что-то вон про изменение стилистики статьи пытается рассказать.
N>Потому что у него не хватает моральных сил лезть в Ваши "уравнения"
Про уравнение для первого класса я написал выше.
YN>>>>Какой компилятор? Я вот свой написал, он пропустит. N>>> YN>>Я поясню — в мире великое множество компиляторов. Так что говорить "компилятор не пропустит" все-равно что говорить "кран не протекает" — необходимо конкретизировать объект.
N>Есть конкретизация по умолчанию: компилятор, соответствующий стандарту.
Вы мало значете про стандарт и компиляторы. Уверяю вас, что наличие двух идущих подряд одинаковых "tagged values" допустимо по стандарту и будет пропущено любым компилятором.
N>>>>>Я повторю, что включение PRIVATE в эту схему считаю методологически некорректным. YN>>>>Собственно почему? Вполне достойный кандидат. N>>>Аналогия: учим первоклашек арифметике. Пока что есть числа до 10. И рисуем, что 5+5=12, 5+6=13, и т.д. (числа от 10 записаны в восьмеричной). Потом, когда даём знание, что такое 10 и так далее, переключаемся на десятичную. Шок гарантирован. Взрослый, читающий про ASN.1, скорее всего шокирвоан не будет, но перечислит некоторые свойства Ваших родственников. YN>>Здесь я уже вижу какой-то бред с вашей стороны. YN>>Мы вроде бы про ASN.1 разговариваем, а не про десятичные и восмиричные числа.
N>Слово "аналогия" есть в большинстве словарей. OK, конкретизирую: правильных словарей
YN>> Вы ответьте — почему это вдруг PRIVATE не может быть использован? Что за идеология?
N>Это идеология ASN.1. Ваше замечание, по своей конструкции подразумевающее, что идеология тут является чем-то неуместным, само по себе неуместно в таком виде, из-за наличия чётко прописанных принципов построения представления (ещё до перехода на уровень битов и октетов).
Ну так приводите мне ограничения стандарта на существование внутри SET двух одинаковых "tagged values" Это возможно как с точки зрения стандарта, так и с точки зрения кодирования.
N>>>Ну я могу тоже гнать на Пушкина. Вы думаете, я не знаю этой разницы? YN>>Вижу, что уже начинаете понимать
N>Боюсь, что это Ваша иллюзия, что я что-то "начинаю" тут понимать. Я понимал разницу между конструктивным и неконструктивным обсуждением очень давно, и стараюсь держаться в рамках конструктивности. Именно поэтому я трачу достаточно много времени на эти комментарии. Без этого проще было бы сказать "кг/ам" и посоветовать адекватный источник на английском. Например, статью Лаймана. Несмотря на то, что она датирована ещё 1993 годом, она актуальна, кроме мелких моментов, и по стилю превосходит не только Вашу, но и все другие встреченные мной источники. Если у меня будет сочетание времени и вдохновения, я не буду пытаться что-то делать с нуля — возьму её за основу, разве что чуть добавив вступительной "воды" с описаниями необходимости каждого элемента. По ясности изложения она, повторюсь, лучшая, и является отличным "предисловием" к собственно текстам стандартов.
Найдите где-нибудь ещё описание кодирования REAL. Или напишите своё, не подглядывая ко мне
YN>>>>Мне ваша статья просто не нравится и стиль её изложения меня ужасает. В добавок придумывание каких-то своих терминов создаёт огромные проблемы при дальнейшем изучении темы. N>>>Факт хоть одной проблемы — в студию YN>>Удивительно. То есть каждый преподаватель по вашему мнению может придумывать собственные термины и потом это не создаст проблем у студентов?
N>Imago detected.
Вы опять придумали новый термин?
YN>>>>Любая программа, умеющая парсить ASN.1, сможет понять тип, длину и значение любого ASN.1 кодированного сообщения. N>>>В случае BER — да. В случае PER — уже нет. Вы опять путаете термины. YN>>PER — синтетический диалект, неотделимый от схемы. Причём для каждой схемы этот диалект может быть разным. YN>>Но пусть даже вы и правы и говорить о чистом ASN.1 здесь некорректно.
N>Спасибо. Давайте считать это ТЗ первого шага исправления статьи
YN>>Послушайте, я ведь знаю про ASN.1 никак не меньше вашего (а скорее всего и больше) и прекрасно знаю о большинстве "ограничений". YN>>Я прекрасно представляю, что есть PER и XER, что есть схемы и многочисленные стандарты протоколов. Я работаю с ASN.1 уже более 10-ти лет.
N>Именно. _Вы_ — работали. _Вы_ — знаете. Вы держите в голове все эти подводные камни. Новичок — не знает. Его слишком легко запутать сдвигом терминологии, напугать объяснениями типа "решим уравнение", счётом по основанию 256 (возможно, он до сих пор по 16 плохо умеет, надо ему помочь). Практическое знание и умение объяснять — слишком разные вещи. Я, заметьте, ни разу не сказал, что Вы плохо решаете задачи, связанные с ASN.1, пишете кривой код, или что-то подобное; для этого в любом случае тут нет материала, и, возможно, Вы это делаете лучше всех на планете Это возможно, и обратного никак не вытекает из того, что Вы плохо объясняете. Речь только про статью. Сейчас она — ужасна. (Зато мы уже знаем, как её исправить.)
Знаете, теперь аналогию приведу я.
Допустим я занимаюсь дизайном квартир на протяжении десятилетия. И вот наконец я сделал очередную квартиру и выставляю на всеобщее обозрение.
Допустим приходит человек, просто с улицы и начинает говорить мне, что обои сейчас не модные, и мебель расставлена в ошибочном порядке, и вообще ему не нравится. Он будет "послан лесом".
Допустим приходит человек, которого я знаю и ценю как профессионала в дизайне. Он выскажет своё мнение и замечаний у него будет на порядки меньше. Скорее всего я прислушаюсь к его мнению.
Допустим приходит человек опять с улицы, но который даёт мне конкретные замечания вида: здесь обои отклеились, здесь не прокрашено, здесь ручки на дверях плохо держаться. Такие замечания я исправлю в обязательном порядке.
Мне сейчас говорят замечания по статье люди, которых я не знаю, люди, которые не написали ни одной статьи, люди, единственная статья которых может быть выставлена как образец того, как нельзя писать про протоколы. У меня нет никакого доверия у вашим словам. Вы — никто для меня с профессиональной точки зрения. Вы люди, которые высказывают своё собственное мнение по поводу что правильно или нет в моей статье (по аналогии — что модно в дизайне, а что нет на основании передач по ТНТ). Вы люди с непонятными для меня целями — зачем вы пришли сюда и говорите что мне надо делать? Я прислушаюсь к вашему мнению исключительно в части исправления ошибок моей статьи и не более. Это моя личная позиция.
YN>>Пытаться ловить меня на том, что "ага, а вот если эти правила использовать то выражение становиться ошибочным" — это я считаю достаточно низко и никому пользы не принесёт. Я просто начну писать более развёрнутые выражения, а это, смею вас уверить, у меня получается хорошо.
N>Ура! Вот именно этого тут и добиваюсь я и все комментирующие. Невозможно быстро научить гениальной краткости, это особое умение. Но развернуть, пусть неудобно написанное, до понятного вида — это один из полезных промежуточных этапов. Далее, вероятно, Вы сами увидите, как сократить то, что стало ненужным. Так что ждём-с.
Я повторюсь: первоначально статья прошла проверку на совершенно неподготовленном человеке. Так что меня в ней пока всё устраивает.
Здравствуйте, y-niko, Вы писали:
YN>Я повторюсь: первоначально статья прошла проверку на совершенно неподготовленном человеке. Так что меня в ней пока всё устраивает.
Какая-то у вас нерепрезентативная социологическая выборка: один человек сказал, что статья вроде бы понятная, и вас стало все устраивать.
Здесь вам уже четверо хором талдычат на разные лады: статья непонятная, непонятная статья, язык сложный, примеры неудачные, напихано лишнее, не описано существенное. А вам как божья роса: "не знаю этих людей, хорошая статья".
Дело-то ваше, на самом деле. Если вас устраивает писать для узкого круга избранных джедаев, которые согласны расплетать ваши примеры и таблицы — не слушайте, ради бога. Кто вам может помешать?
Здравствуйте, Хреннос, Вы писали:
Х>Здравствуйте, y-niko, Вы писали:
YN>>Я повторюсь: первоначально статья прошла проверку на совершенно неподготовленном человеке. Так что меня в ней пока всё устраивает.
Х>Какая-то у вас нерепрезентативная социологическая выборка: один человек сказал, что статья вроде бы понятная, и вас стало все устраивать.
Х>Здесь вам уже четверо хором талдычат на разные лады: статья непонятная, непонятная статья, язык сложный, примеры неудачные, напихано лишнее, не описано существенное. А вам как божья роса: "не знаю этих людей, хорошая статья".
Х>Дело-то ваше, на самом деле. Если вас устраивает писать для узкого круга избранных джедаев, которые согласны расплетать ваши примеры и таблицы — не слушайте, ради бога. Кто вам может помешать?
Я слушаю, слушаю. Делаю вот только по-своему.
Автор(ы): Чарльз Петцольд
