Что такое префикс в группе

Использование префиксов

На странице настроек для работы с товарами в блоке «Префиксы» можно указать следующие параметры:

Префикс артикула – указывается значение, которое будет подставляться автоматически к артикулу;
Префикс копии товара – указывается значение, которое будет использоваться в качестве префикса к названию товара при его копировании;
Дублировать артикул при копировании товара – включение / выключение дублирование артикула для копии товара.

После заполнения параметров нажмите кнопку «Сохранить».

Смотрите также:

Основные параметры страниц товаров на сайте

Настройка интерфейса страницы со списком товаров

Настройка отображения характеристик в карточке товара

Назначение менеджеров для товарных групп

Настройка мультицен

Создание политики именования групп рассылки в Exchange 2013

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

Политика именования групп используется для:

применения согласованной стратегии именования групп, создаваемых пользователями;
идентификации групп рассылки в общей адресной книге;
указания на назначение или состав группы;
указания на пользователей потенциальных членов группы;
указания региона использования группы;
предотвращения использования неуместных слов в именах групп.

Как работает политика именования групп? Когда пользователь создает группу, в поле «Отображаемое имя» вводится имя группы. После создания группы Microsoft Exchange применяет политику именования групп, добавляя префиксы и суффиксы, определенные в политике. Полное имя отображается в списке групп рассылки в Центре администрирования Exchange(EAC), общей адресной книге и поля Кому:, Копия:и От: в сообщениях электронной почты. Если пользователь указывает заблокированное слово, при попытке сохранения новой группы появляется сообщение об ошибке с просьбой убрать слово и повторить сохранение.

Ниже приведены несколько примеров политики именования групп. В каждом из них означает описательное имя, которое группе присвоил тот, кто ее создает. Система Exchange добавляет префиксы и суффиксы, определенные в политике, и отображает имя, когда группа создана.

Текстовые строки с подчеркиваниями, используемые в качестве префикса (DG) и суффикса (Users): группы DG__Users
Несколько префиксов (DG и Contoso) и один суффикс (Users) с использованием текстовых строк: группы DG_Contoso__Users
АТрибут (Department), используемый как префикс: Department_ Предположим, у преподавателей в учебном заведении заполнен атрибут Department. Вот пример имени группы, созданной сотрудником отдела психологии: Psychology_Cognitive201 В этом примере знак подчеркивания указан в качестве второго префикса, чтобы отделить имя отдела от имени группы.

Что нужно знать перед началом работы?

Предполагаемое время для завершения: 5 минут.
Для выполнения этой процедуры (процедур) необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в записи «Группы рассылки» в разделе Разрешения получателей .
Максимальная длина имени группы 64 символа. Сюда включается общее число символов префикса, имени, указанного пользователем, и суффикса.
Политика именования групп применяется только к группам, созданным пользователями. Когда вы или другие администраторы используете Центр администрирования Exchange для создания групп рассылки, политика именования групп игнорируется и не применяется к имени группы.
Имена групп создаются без пробелов. Рекомендуется использовать знак подчеркивания (_) или другой заполнитель между строками текста, атрибутами и именем группы.
При создании и редактировании группы рассылки можно использовать Windows PowerShell для переопределения политики именования групп. Дополнительные сведения см. в статье Переопределение политики именования групп рассылки.
Сведения о сочетаниях клавиш, которые могут применяться к процедурам, описанным в этом разделе, см. в статье Сочетания клавиш для Центра администрирования Exchange в Exchange 2013.

Возникли проблемы? Обратитесь за помощью к участникам форумов Exchange. Посетите форумы по адресу Exchange Server.

Использование Центра администрирования Exchange для создания политики именования групп

В EAC выберите Значок «Дополнительные параметры групп».> >Настройка политики именования групп.
В разделе Политика именования групп в раскрывающемся меню выберите Атрибут или Текст, чтобы настроить префикс.
- Атрибут Выберите атрибут и нажмите кнопку ОК.
- Текст Введите текстовую строку и нажмите кнопку ОК. Обратите внимание, что введенная текстовая строка (или выбранный атрибут) отображается в виде гиперссылки. Щелкните гиперссылку, чтобы изменить строку или атрибут.
Чтобы добавить другие префиксы, нажмите кнопку Добавить.
В качестве суффикса выберите в раскрывающемся меню Атрибут или Текст, после чего настройте суффикс.
Чтобы добавить другие суффиксы, нажмите кнопку Добавить. После добавления префикса или суффикса отображается предварительный вид результата применения политики именования групп.
Чтобы удалить префикс или суффикс из политики, щелкните Удалить
Для добавления или удаления заблокированных слов выберите пункт Заблокированные слова.
- Чтобы добавить слово в список, введите слово для блокировки и нажмите кнопку Добавить
- Чтобы удалить слово из списка, выберите его и нажмите кнопку Удалить.
- Чтобы изменить существующее заблокированное слово, выберите его и нажмите кнопку Редактировать.
Завершив настройку, нажмите кнопку Сохранить.

Как проверить, все ли получилось?

Чтобы проверить, успешно ли создана политика именования групп, выполните указанные ниже действия.

В EAC выберите Группы>Подробнее>Настройка политики именования групп. На странице Политика именования групп политика, которую вы определили, указана в разделе Предварительный просмотр политики.
В Windows PowerShell выполните следующую команду для отображения политики именования групп:

Get-OrganizationConfig | Format-List DistributionGroupNamingPolicy

Префикс или постхак

В то время, как поддержка CSS в браузерах улучшается с каждым днём — включая впечатляющие успехи команды разработчиков IE9 — всё больше и больше авторов увлекаются CSS3. По этой причине им приходится сталкиваться с браузерными префиксами — свойствами вида -*- , вроде -moz-border-radius , -webkit-animation и так далее.

И конечно же, по поводу этих префиксов слышится ворчание. Звучат призывы совсем отказаться от них или объединить все специфичные браузерные префиксы в один вида -beta- . Главная причина всего этого шума — никто, на самом деле, не хочет писать одно и то же свойство четыре или пять раз подряд только для того, чтобы, скажем, скруглить уголки.

Даже если это ворчание и можно понять, оно всё равно несправедливо. На самом деле, мы должны благодарить производителей браузеров за использование префиксов и безусловно поощрять их развитие. Более того, я уверен, что префиксы должны стать основой процесса развития стандарта CSS. И я говорю это не от большой любви к повторению правил, а, напротив — от большого желания видеть последовательное развитие CSS. Я верю, что префиксы на самом деле могут ускорить развитие и совершенствование CSS.

Вспоминая ужасы Скопировать ссылку

Для понимания того, почему браузерные префиксы в принципе существуют, очень поучительно будет вспомнить историю с блочной моделью, которая чуть не убила CSS на пороге второго тысячелетия. Противоречивые реализации блочной модели в браузерах привели тогда к серьёзному кризису. Для того, чтобы обезопасить себя от такой ситуации в будущем, мы должны придумать новый механизм на основе существующих возможностей языка и изобрести принципиально новый тип хаков.

Для наших самых маленьких читателей, пропустивших всё веселье — история произошла следующая: среди первых браузеров, поддерживающих CSS, Netscape внедрил блочную модель, найденную в CSS-спецификации. Это означало, что свойства width и height соотносились с шириной и высотой границ содержимого блока. А Internet Explorer внедрил интуитивную блочную модель, в которой свойства width и height обозначали размеры по внешней границе блока.

Какая бы из реализаций ни казалась удачнее, факт оставался фактом — в тот момент на рынке существовало два браузера принципиально несовместимых друг с другом, и у каждого из них была большая пользовательская база. Дело было в конце 90-х, когда мы боролись как проклятые, чтобы вырваться из трясины предупреждений «этот сайт лучше всего отображается в…», и обычной была ситуация, когда одна и та же вёрстка отлично работала в одном браузере, но напрочь разваливалась в другом.

Суть проблемы состояла в том, что каждый из браузеров не мог изменить своего поведения до зеркального соответствия другому. Представим на секунду, что команда разработчиков IE решает изменить поддержку CSS для большего соответствия спецификации. Подобный поступок привёл бы к тому, что десятки или даже сотни тысяч сайтов, работавших в IE, не просто где-то там сломаются, а буквально развалятся на части в определённых версиях браузера. И пока всё сообщество веб-стандартистов будет рукоплескать этому поступку, весь остальной мир откажется от браузера по причине полной его бесполезности. И даже если Рабочая группа CSS (CSS Working Group) решит изменить спецификацию для соответствия поведению IE, то Netscape столкнётся ровно с теми же трудностями.

Таким образом и был придуман механизм переключения . Вся эта история со «стандартным» (standards mode) и «хитрым» (quirks mode) режимами выросла как раз из этой ситуации. Механизм переключения решал многие проблемы, но его появление спровоцировали именно сложности с блочной моделью. Вдумайтесь: из-за того, что два браузера вели себя по-разному, сегодняшние браузеры вынуждены поддерживать два основных режима обработки страниц и выбирать нужный на основании SGML-декларации, в которой вообще ничего не сказано про обработку страниц.

Более того, все CSS-хаки первой волны были посвящены именно этой проблеме. Название классического представителя хаков той поры говорит само за себя: «хак для блочной модели» (The Box Model Hack). Фактически, сам хак был основан на ошибке в синтаксической обработке значения свойства voice-family , но почему-то никто ни разу не назвал его «voice-family-хак».

Самое смешное, что это был не единственный случай, в котором непоследовательность внедрения спецификации привела к проблемам. Спустя некоторое время после появления механизма переключения , спасшего CSS, команда разработчиков IE внедрила некоторые CSS-свойства позиционирования. Одним из внедрённых свойств было clip . Наученные горьким опытом шумихи с блочной моделью, инженеры Microsoft с большим вниманием отнеслись к спецификации и сделали всё в точности так, как там было сказано.

Вскоре после публичного релиза браузера, Рабочая группа CSS серьёзно поменяла принцип работы свойства clip . Синтаксис выглядел точно так же, однако приводил совсем к другим результатам.

В очередной раз спецификация вошла в противоречие с публично доступным браузером — или, если хотите, наоборот. Окончательным решением стало возвращение к прежнему поведению и полный отказ от нового. Фактически, это свойство стало бесполезным для элементов с непредсказуемой высотой и шириной — т.е. для всех незамещаемых элементов в нормальном потоке, вроде элементов и

. Подробнее о типах элементов (replaced, non-replaced) можно прочитать в документации W3C. Несмотря на то, что были предложены и другие варианты решения, они так и не были реализованы, и свойство clip утратило часть своей полезности.

Представим себе другой исход Скопировать ссылку

Предположим, что вместо внедрения свойства clip разработчики IE внедрили бы свойство -ms-clip . В этом случае было бы не так сложно справиться с последующим изменением поведения в спецификации. Из-за того, что префикс обозначает для свойства статус «в разработке», в дальнейшем производителю браузера будет гораздо проще пересмотреть работу свойства. Таким образом, разработчики IE могли бы поменять поведение свойства -ms-clip , в следующем релизе и объяснить разработчикам, что они обновили экспериментальное свойство для соответствия спецификации.

И даже если бы они решили, что сделать это невозможно, вся опасность «неправильного» внедрения была бы изолирована в рамках префиксной версии свойства. Другие производители браузеров могли бы внедрить новую версию свойства clip (со своим префиксом) и это никак бы не повлияло на то, что сделали разработчики IE. Один производитель никак не смог бы навредить своими действиями спецификации и другим производителям.

В этом состоит польза префиксов: это способ показать, что свойство находится «в разработке» и не обязательно будет вести себя так же в будущих релизах; это решение для разработчиков, которым необходимо внести изменения в работу свойства; это защита от неудачной или преждевременной реализации, которая вполне может случиться при первом внедрении. Префиксы придают столь необходимую гибкость процессу развития CSS.

Мы конечно можем заявить: «Когда браузер неправ по отношению к спецификации, то он должен изменить реализацию, даже если это сломает вёрстку сайтов». Благодаря предупреждению о рабочем статусе свойства, которое подразумевают префиксы, сделать это становится гораздо проще. Без использования префиксов это крайне сложно или, зачастую, просто невозможно. Microsoft так и не изменила способ расчёта width и height для устаревших сайтов — вместо этого она использовала объявление для включения другого поведения для новых (теоретически, более совместимых со стандартами) сайтов. Это был очень полезный и необходимый трюк, но один из тех, что срабатывают только один раз.

И даже сейчас мы страдаем Скопировать ссылку

И если вы думаете, что все эти глупости стали частью истории, вот вам два примера несовместимости, существующие прямо сейчас:

Браузеры на движках Mozilla и WebKit обрабатывают размытие для свойства box-shadow по-разному, и ни одна из реализаций полностью не соответствует спецификации. И пока я пишу эти строки, длинные и жаркие дебаты кипят в рассылке www-style. По меньшей мере одной, а, возможно, и обеим реализациям размытия тени придётся измениться для достижения совместимости. То же самое справедливо и для реализаций Opera и Microsoft.

Браузеры на движках Mozilla и WebKit поддерживают градиенты, используя категорически разный синтаксис для достижения простых результатов. А теперь представьте ситуацию, в которой производители браузеров внедрили бы градиенты без префиксов. В ней мы имеем три варианта:

Выбрать, какой браузер получит градиенты, а какой нет;
использовать CSS-хаки или фильтрацию браузеров для выдачи разных стилей разным браузерам;
полностью отказаться от использования градиентов.

И мы имеем здесь целых три варианта только потому, что градиенты, реализованные в этих браузерах, имеют очень разный синтаксис, что открывает дорогу для первого варианта. В случае, когда обе реализации имели бы схожий синтаксис значения, но различную реализацию — как в истории со свойством clip — у нас были бы только два последних варианта: хакать и фильтровать для выдачи разных стилей, либо просто отказаться от этой затеи.

Мы уже вдоволь находились по этим граблям за всю историю развития CSS. Нет смысла наступать на них ещё раз, если первая дюжина попыток закончилась плохо.

Пре-фикс или пост-хак Скопировать ссылку

Но настолько ли хороши префиксы? В конце концов, было же сказано, что префиксы — это всего лишь новые CSS-хаки. Как сказал Аарон Густавсон в недавней статье, это:

-moz-border-radius: 10px 5px; -webkit-border-top-left-radius: 10px; -webkit-border-top-right-radius: 5px; -webkit-border-bottom-right-radius: 10px; -webkit-border-bottom-left-radius: 5px; border-radius: 10px 5px;

…слишком напоминает вот эту историю:

padding: 10px; width: 200px; w\idth: 180px; height: 200px; heigh\t: 180px;

С точки зрения чрезмерного повторения и раздражения — да, они более чем похожи. Но, с другой стороны, они принципиально различаются: префиксы дают нам контроль над судьбой наших хаков. В прошлом нам приходилось выискивать кучу ошибок парсера только для того, чтобы заставить противоречивые реализации работать одинаково, как только мы выясняли, что они работают противоречиво. Таким образом, мы реагировали на имеющуюся проблему. Использование префиксов — это упреждающий подход.

Более того, префиксы — это временный хак. Со временем, когда реализация свойств станет более совместимой, браузеры просто откажутся от префиксов. И тогда авторы смогут писать всего одну строку вместо шести с чем-то для свойства border-radius . Без префиксов мы будем вынуждены ждать очередных сомнительных реализаций и год от года поддерживать их при помощи хаков.

Поэтому создание единого префикса, вроде -beta- или -w3c- — это, по меньшей мере, полшага назад. Это, конечно, позволит производителям помечать свойства префиксом «в разработке» и делать в дальнейшем необходимые изменения, но, к сожалению, полностью закроет для авторов возможность исключать поддержку или просто отдавать различные значения каждому отдельному браузеру, в случае очередной сомнительной реализации. С точки зрения авторов, единый префикс ничем не лучше, чем полный отказ от них.

Иногда мне кажется, что так же история обстоит и с методами предварительной обработки кода для работы с префиксами — серверными (при помощи Less) или клиентскими (куча JS-фреймворков). Использование этих инструментов позволяет просто писать правило border-radius и поручать им разворачивание этой строки в список необходимых правил с префиксами. С одной стороны, это уменьшает количество необходимого кода и повышает его чистоту и понятность. С другой стороны, этот подход мало чем отличается от ситуации с единым префиксом или вообще без них — всего одна неудачная реализация, и ваша вёрстка развалится.

Преимущество этого способа состоит в том, что если что-то пойдёт не так, то любой автор сможет вернуться, отключить препроцессинг и написать все префиксы вручную. Или сами препроцессоры кода могут обновиться для решения проблемы. В любом случае, это некоторый перебор сложности для авторов, хотя и не такой большой.

Обратная сторона этого способа более философская, но не менее важная: пряча свойства с префиксами за обработчиком, авторы могут забыть о том, что используют экспериментальные свойства, которые могут измениться. Неосознанно они могут начать думать, что используют что-то устоявшееся и стабильное, хотя это может быть совсем не так.

Делаем префиксы действительно важными Скопировать ссылку

Я настолько твёрдо уверен, что префиксы — это хорошая вещь, что готов перейти к следующему логическому заключению: префиксы должны занять центральное место в развитии стандартов. Они должны быть обязательными для только что реализованных свойств, и должны стать механизмом, декларирующим совместимость.

Вот что я имею в виду: предположим, что кто-то изобрёл новое свойство под названием text-curl . Тотчас же трое производителей реализуют его. Каждый из них будет обязан добавить префикс к своей реализации. Таким образом, получается следующая картина:

Со временем производители совершенствуют свои реализации в ответ на сообщения об ошибках и уточнения от Рабочей группы CSS. В какой-то момент Рабочая группа решает, что две из трёх реализаций вполне совместимы со спецификацией. Тогда две эти реализации начинают поддерживать оригинальное свойство. Третья — нет.

В этот момент авторы могут решить упростить свои стили до следующих:

В отличие от ситуации с хаками, которые только разрастаются со временем, мы просто отбрасываем ненужное. В итоге, всё, что остаётся — это одна строчка с text-curl .

И что же происходит, когда дебютирует очередная реализация? В первом своём релизе она также использует префикс, вне зависимости от количества уже существующих удачных реализаций. Значит, нам придётся вернуться к нашему CSS и поменять его следующим образом:

Как только Рабочая группа сочтёт реализацию свойства -ms-text-curl полной, префикс сможет быть отброшен в следующей версии IE. После чего CSS снова может быть уменьшен до единственной беспрефиксной строчки. И снова — количество хаков только уменьшается со временем.

Конечно, каждый из производителей продолжит поддерживать свойства с префиксами, так что даже если мы и не удалим эти правила, каждый из поддерживаемых браузеров распознает и использует свойство без префикса, если конечно оно будет следовать после правила с префиксом. Для любого браузера, который внедрил свойство с префиксом и не позаботился о том, чтобы привести его в беспрефиксное состояние, это свойство по-прежнему будет работать. Даже если CSS-код останется нетронутым, он всё равно продолжит функционировать.

Вернёмся к тому моменту, когда Рабочая группа называет две реализации полностью совместимыми и даёт им право избавиться от префиксов. Эта ситуация приводит к двум результатам. Во-первых, как я уже говорил, это говорит о том, что свойство имеет достаточный уровень совместимости, и это позволяет развивать процесс стандартизации дальше.

Но, с другой стороны — что, вероятно, более важно — это заставляет производителей и Рабочую группу сотрудничать в разработке тестов, необходимых для определения условий совместимости. В дальнейшем, эти тесты могут помочь остальным производителям достичь статуса совместимости гораздо раньше. Они могут выпустить версию с префиксом в одной публичной бете и отказаться от префикса буквально в следующем же бета-релизе.

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

Как предлагалось выше, модулю должно быть позволено достигнуть статуса возможной рекомендации только в случае, когда все его свойства имеют, как минимум, две реализации без префиксов, работающие в реальных условиях. Любые подобные свойства, появившиеся после этого, должны иметь префикс, от которого они смогут избавиться, только доказав на практике полную совместимость с уже существующими реализациями без префикса. Вместо того чтобы внушать сомнения, свойства с отброшенными префиксами могут стать гарантами стабильности, вместе с уже давно известными свойствами.

Заключение Скопировать ссылку

Если история развития веб-стандартов и научила нас чему-то, то скорее тому, что хаки будут необходимы всегда. Подставляя хаки при помощи префиксов и используя их в процессе стандартизации, мы действительно можем справиться с потенциальными проблемами и ускорить разработку CSS.

И когда в следующий раз вы начнёте ворчать по поводу указания одних и тех же правил четыре раза, по одному на каждый из браузеров, вспомните, что это временная проблема. Это немного напоминает вакцинацию — укол побаливает, это правда, но всё не настолько плохо по сравнению с болезнью, которую он предотвращает. И в нашем случае вы вакцинируетесь от многолетней возни с хаками, от фильтрации браузеров, и от других скверных вещей. Мы уже однажды пережили эту эпидемию. При должном использовании префиксы позволят надолго сдержать очередную вспышку этой напасти.

Характеристические группы, обозначаемые в заместительной номенклатуре только в префиксе

1 В русской химической литературе принято при составлении названий опускать последнюю букву «о».

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

определяют исходную структуру (главную цепь или старшую циклическую систему);
придают название исходной структуре
определяют и придают название группам, которые обозначаются префиксами;
проводят нумерацию атомов углерода в исходной структуре;
составляют полное название, придерживаясь алфавитного (без учёта умножающих приставок) порядка для всех отделяемых префиксов.

Характеристическая группа из таблицы 3 получает наименьший цифровой индекс, если она является единственным заместителем в ациклической или циклической структурах, не содержащих кратных связей, или в ароматической структуре. П р и м е р ы:При наличии в ациклической или циклической (неароматической) структурах еще и кратной связи уже этой связи дается наименьший номер. П р и м е р ы:В случае одновременного присутствия характеристических групп из таблицы 1 и углеводородных радикалов порядок нумерации должен быть таким, чтобы заместители получили наиболее низкие возможные номера. При написании названия углеводородные радикалы и характеристические группы перечисляются в префиксе в алфавитном порядке. П р и м е р ы:Характеристические группы, указанные в таблице 4, приведены в порядке убывания старшинства. Таблица 4

Характеристические группы, употребляемые в заместительной номенклатуре в качестве как суффиксов, так и префиксов

Обозначение в префиксе	Название класса соединений и группа	Обозначение в суффиксе
-онио-, ониа-	Катионы	-оний
	Карбоновые кислоты	-овая кислота
Карбокси-		-карбоновая кислота
Сульфо-	Сульфоновые кислоты	-сульфоновая кислота

Продолжение таблицы 4

Обозначение в префиксе	Название класса соединений и группа	Обозначение в суффиксе
	Сложные эфиры	R. оат
R-оксикарбонил-		R..карбоксилат
Ацилокси-		—
	Ацилгалогениды (Галогенангидриды)	-оилгалогенид
Галоформил-		-карбонилгалогенид
	Амиды	-амид
Карбамоил-		-карбоксамид
	Нитрилы	-нитрил 2
Циано-		-карбонитрил

Продолжение таблицы 4

Обозначение в префиксе	Название класса соединений и группа	Обозначение в суффиксе
Оксо-	Альдегиды	-аль
Формил-		-карбальдегид
Оксо-	Кетоны	-он
_{Гидрокси-}	Спирты	_-ол
Гидрокси-	Фенолы	-ол
Меркапто-	Тиолы	-тиол
_{Гидроперокси-}	Гидропероксиды	_
_Амино-	Амины	_-амин
_Имино-	Имины	_-имин

Окончание таблицы 4

Обозначение в префиксе	Название класса соединений и группа	Обозначение в суффиксе
_R-окси-	Простые эфиры	_
_R-тио-	Сульфиды	_
_{R-диокси-}	Пероксиды	_
1 Заключенный в скобки атом углерода входит в название исходного соединения, но не в суффикс или префикс. 2 При составлении названий к наименованию исходной структуры принято добавлять букву «о».

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

определяют тип характеристической группы, которую следует принять за старшую;
определяют исходную структуру (главную цепь или старшую циклическую систему);
придают название исходной структуре и старшей группе, которая будет обозначена суффиксом (в случае необходимости к суффиксу добавляют умножающую приставку);
определяют и придают название младшим группам, которые будут обозначены префиксами;
проводят нумерацию, придавая старшей группе наименьший номер;
объединяют частичные названия в общее полное название, придерживаясь алфавитного порядка для всех отделяемых префиксов (в случае необходимости к префиксам добавляют умножающие приставки).

Если в соединении присутствует одна характеристическаягруппа из таблицы 4, то именно она является старшей и будет фигурировать в качестве суффикса в названии соединения. П р и м е р ы:Бутиламин 1 Диэтиламин 1 Метилпропилэтиламин 2 1-Этилбутиламин 1 , 3-Гексанамин 1 2-Бензофуранамин 3 Если соединение содержит более одной характеристической группы, указанной в таблице 4, то за старшую группу принимают ту из них, которая характеризует класс веществ, перечисленный раньше других. После того, как выбрана старшая группа, выбирают исходную структуру, включающую в себя эту старшую группу или присоединенную к ней. Нумерацию исходной структуры проводят таким образом, чтобы старшая группа получила наименьший цифровой индекс. Наименования всех оставшихся групп, за исключением старшей, являются префиксами и располагаются в названии в алфавитном порядке без учета умножающих приставок. П р и м е р ы:

Старшая группа: Исходная структура (главная цепь): Видоизменение, связанное с ненасыщенностью: Главная цепь вместе со старшей группой: Префикс:

—ОН С—С—С—С—С С=С—С—С—С

СН₃—

-ол Пентан 4-Пентен 4-Пентен-2-ол Метил-

Полное название: 3-Метил-4-пентен-2-ол

Старшая группа: Исходная структура (главная цепь): Главная цепь вместе со старшей группой: Видоизменение, свя-занное с ненасыщен-ностью: Префиксы (в алфа-витном порядке):

—COOH C—C—C—C—C—C—C C—C—C—C—C—C—COOH C—C—C—C=C—C—COOH Br— HO— CH₃—

-овая кислота Гептан Гептановая кислота 3-Гептеновая кислота Бромо- Гидрокси- Метил-

Полное название: 2,6-Дибромо-5-гидрокси-5-метил-3-гептеновая кислота

Старшая группа:	—СООН
Исходная структура (главная цепь): Главная цепь вместе со старшей группой:	C—C—C—C—C C—C—C—C—COOH	Пентан Пентановая кислота
Префикс:		м-Бромфенил-

Полное название: 5-(м-Бромфенил)пентановая кислота

Старшая группа:	—СООС₂Н₅
Исходная структура (циклическая система): Исходная структура вместе со старшей группой:		Бензол Этилбензоат
Префикс:	CH₃—CH=CH—CH₂—CH₂—	3-Пентенил

Полное название: Этил(3-пентенил)бензоат Если соединение включает в себя несколько циклических структур, то исходной структурой является старшая из них.

Старшая группа:	—СООН
Исходная структура (старшая циклическая система): Исходная структура вместе со старшей группой:		Бензол Бензойная кислота
Префиксы (в алфавит-ном порядке):	(СН₃)₂N— NC—	Диметиламино- 4-Карбокси- циклогексил- Циано-

Полное название: 2-Диметиламино-4-(4-карбоксициклогексил)- 6-цианобензойная кислота

Старшая группа:	—СООН
Исходная структура (старшая циклическая система): Исходная структура вместе со старшей группой:		Бензол 1 Бензойная кислота
Префиксы (в алфавит-ном порядке):	CH₃—	Метил- 2-(4-Цианопирролил)-