cgroups

title: cgroups(7)

summary: управляемые группы в Linux

text:
# cgroups(7)

## ИМЯ
cgroups - управляемые группы в Linux

## ОПИСАНИЕ
Управляемые cgroup-ы, обычно называемые cgroups, это свойство ядра Linux, которое позволяет объединять процессы в иерархические группы, и в этих группах отслеживать и ограничивать разные типы ресурсов. Ядро предоставляет интерфейс работы с cgroup-ами через псевдо-файловую систему, называемую cgroupfs. Группировка реализована в базовой части ядра cgroup, а слежение за ресурсами и ограничениями — в подсистемах самих ресурсов (память, ЦП и т. п.).

### Терминология
cgroup — это набор процессов, которые связаны с набором ограничений или параметров, определяемых через файловую систему cgroup.

subsystem — компонент ядра, который изменяет поведение процессов в cgroup-у. Реализованы различные подсистемы, они позволяют делать разные вещи, например ограничивать количество времени ЦП и память доступную для cgroup-ы, подсчитывать время ЦП, используемое группой и останавливать и возобновлять выполнение процессов в cgroup-е. Подсистемы иногда также называют контроллерами ресурсов (или просто, контроллерами).

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

### Cgroups версии 1 и 2
Впервые реализация cgroup появилась в Linux 2.6.24. Постепенно добавлялись различные контроллеры cgroup, позволяющие управлять различными типами ресурсов. Однако, разработка этих контроллеров была, по большей части, не скоординированной, что привело к несогласованности между контроллерами, и управление иерархиями cgroup стало очень сложным (расширенное описание проблем можно найти в файле исходного кода ядра Documentation/cgroup-v2.txt).

Вследствие проблем в первой реализации cgroup (cgroups версии 1), начиная с Linux 3.10 началась работа на новой независимой реализацией, учитывающей возникшие ошибки. Сначала помеченная как экспериментальная и скрытая параметром монтирования -o __DEVEL__sane_behavior новая версия (cgroups версии 2) в конце концов была добавлена в Linux 4.5. Различия между версиями описаны далее.

Хотя cgroups v2 создавалась как замена cgroups v1, старая система всё ещё существует (и для обеспечения совместимости её не хотелось бы удалять). В настоящее время, в cgroups v2 реализованы не все контроллеры, доступные в cgroups v1. Эти две системы реализованы таким образом, что контроллеры v1 и v2 можно монтировать одновременно. То есть, например, можно не только использовать контроллеры, поддерживаемые версией 2, но и использовать контроллеры версии 1, которые пока не поддерживаются версией 2. Единственным ограничением является то, что один и тот же контроллер не может быть запущен одновременно в иерархии cgroups v1 и cgroups v2.

## CGROUPS ВЕРСИИ 1
В cgroups v1 каждый контроллер можно смонтировать в отдельную файловую систему cgroup, которая представляет собой собственную иерархию процессов в системе. Также возможно совместное монтирование нескольких (или даже всех) контроллеров cgroups v1 в единую файловую систему cgroup, при этом совместно смонтированные контроллеры управляют одной иерархией процессов.

Для каждой смонтированной иерархии дерево каталогов отражает иерархию управляемой группы. Каждая управляемая группа представляется каталогом, каждый её потомок управляемой cgroups представляется дочерним каталогом. Например, /user/joe/1.session представляет управляемую группу 1.session, которая является потомком cgroup joe, которая является потомком /user. В каждом каталоге cgroup есть набор файлов, доступных на чтение и запись, через которые доступны ограничения ресурсов и другие общие свойства cgroup.

### Задачи (нити) и процессы
В cgroups v1 процессы и задачи различаются. Процесс может состоять из нескольких задач (чаще всего называемых нитями, если смотреть из пользовательского пространства, и так они будут называться далее в этой справочной странице). В cgroups v1 возможно независимо управлять членством cgroup для нитей процесса.

В некоторых случаях способность cgroups v1 разделять нити по разным cgroups вызывает проблемы. Например, это не имеет смысла для контроллера memory, так как все нити процесса находятся в одном адресном пространстве. Из-за таких проблем способность независимого управления членством cgroup для нитей процесса была удалена в первой реализации cgroups v2, но позже восстановлена в более ограниченном виде (смотрите описание «режим нитей» ниже).

### Монтирование контроллеров v1
Для использования cgroups требуется собрать ядро с параметром CONFIG_CGROUP. Также с каждым контроллером v1 связан параметр настройки, который должен быть задан, если нужно работать с этим контроллером.

Чтобы использовать контроллер a v1, его нужно смонтировать в файловую систему cgroup. Обычно для этого используют файловую систему tmpfs(5), смонтированную в /sys/fs/cgroup. Таким образом, можно смонтировать контроллер cpu следующим образом:

```
mount -t cgroup -o cpu none /sys/fs/cgroup/cpu
```

Можно смонтировать несколько контроллеров вместе в одной иерархии. Например, так контроллеры cpu и cpuacct одновременно монтируются в одной иерархии:

```
mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct
```

Для одновременно смонтированных контроллеров процесс находится в одной cgroup всех одновременно смонтированных контроллеров. Отдельно смонтированные контроллеры позволяют процессу находиться в cgroup /foo1 одного контроллера и в /foo2/foo3 другого.

Можно смонтировать все контроллеры v1 вместе в одной иерархии:

```
mount -t cgroup -o all cgroup /sys/fs/cgroup
```

(Параметр -o all можно опустить, так как по умолчанию монтируются все контроллеры, если ни один не указан явно)

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

Заметим, что на многих системах контроллеры v1 автоматически монтируется в /sys/fs/cgroup; в частности, такие точки монтирования автоматически создаёт systemd(1).

### Размонтирование контроллеров v1
Смонтированная файловая система cgroup может быть размонтирована с помощью команды umount(8) как показано в этом примере:

```
umount /sys/fs/cgroup/pids
```

Но заметим: файловая система cgroup размонтируется только, если она не занята, то есть не имеет дочерних cgroup. Если это не этот случай, то действием umount(8) будет только сокрытие монтирования. То есть, чтобы действительно удалить точку монтирования, сначала нужно удалить все дочерние cgroup, что, в свою очередь, можно выполнить только после перемещения всех процессов-членов из этих cgroup в корневую cgroup.

### Контроллеры cgroups версии 1
Все контроллеры cgroups версии 1 управляются параметрами настройки ядра (список далее). Также, включение свойства cgroups управляется параметром настройки ядра CONFIG_CGROUPS.

cpu (начиная с Linux 2.6.24; CONFIG_CGROUP_SCHED)

Cgroups может гарантироваться минимальное количество «общих ЦП» в занятой системе. Это значение не ограничивает использование ЦП cgroup, если ЦП не заняты. Дополнительную информацию смотрите в Documentation/scheduler/sched-design-CFS.txt.

В Linux 3.2 в этот контроллер было добавлено управление «полосы пропускания» ЦП. Если ядро собрано с параметром CONFIG_CFS_BANDWIDTH, то внутри каждого диапазона планирования (определяемого через файл в каталоге cgroup) процессам в cgroup возможно задать верхнее ограничение выделяемого времени ЦП. Данное ограничение учитывается даже, если ЦП не занят. Дополнительную информацию смотрите в файле исходного кода ядра Documentation/scheduler/sched-bwc.txt.

cpuacct (начиная с Linux 2.6.24; CONFIG_CGROUP_CPUACCT)

Включает учёт использования ЦП группами процессов.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/cpuacct.txt.

cpuset (начиная с Linux 2.6.24; CONFIG_CPUSETS)

Эту cgroup можно использовать для привязки процессов в cgroup к указанному набору ЦП и узлов NUMA.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/cpusets.txt.

memory (начиная с Linux 2.6.25; CONFIG_MEMCG)

Контроллер памяти поддерживает учёт и ограничение памяти процесса, памяти ядра и подкачки, используемой cgroups.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/memory.txt.

devices (начиная с Linux 2.6.26; CONFIG_CGROUP_DEVICE)

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

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/devices.txt.

freezer (начиная с Linux 2.6.28; CONFIG_CGROUP_FREEZER)

freezer cgroup может приостанавливать и возобновлять работу всех процессов в cgroup. Заморозка cgroup /A также влияет на её потомков, например, процессы в /A/B тоже приостанавливаются.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/freezer-subsystem.txt.

net_cls (начиная с Linux 2.6.29; CONFIG_CGROUP_NET_CLASSID)

Помещает classid, задаваемые для cgroup, в сетевые пакеты, создаваемые cgroup. Эти classid затем можно использовать в правилах межсетевого экрана, а также для ограничения трафика с помощью tc(8). Применяется только к пакетам, выходящим из cgroup, и не применяется к входящему трафику cgroup.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/net_cls.txt.

blkio (начиная с Linux 2.6.33; CONFIG_BLK_CGROUP)

blkio cgroup контролирует и ограничивает доступ к заданным блочным устройствам, применяет управление вводом-выводом посредством пропусков (throttling) и ограничения сверху листовых узлов и и промежуточных узлов в иерархии хранилища.

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

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/blkio-controller.txt.

perf_event (начиная с Linux 2.6.39; CONFIG_CGROUP_PERF)

Этот контроллер позволяет выполнять слежение perf за набором процессов, сгруппированных в cgroup.

Дополнительную информацию смотрите в файле исходного кода ядра tools/perf/Documentation/perf-record.txt.

net_prio (начиная с Linux 3.3; CONFIG_CGROUP_NET_PRIO)

Позволяет для cgroups задавать свой приоритет на каждый интерфейс.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/net_prio.txt.

hugetlb (начиная с Linux 3.5; CONFIG_CGROUP_HUGETLB)

Поддерживает ограничение cgroups на использование огромных страниц.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/hugetlb.txt.

pids (начиная с Linux 4.3; CONFIG_CGROUP_PIDS)

Этот контроллер позволяет ограничивать количество процессов, которые могут быть созданы в cgroup (и её потомках).

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/pids.txt.

rdma (начиная с Linux 4.11; CONFIG_CGROUP_RDMA)

Контроллер RDMA позволяет ограничивать использование ресурсов RDMA/IB определённой cgroup.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v1/rdma.txt.

### Создание cgroups и перемещение процессов
Первоначально, в файловой системе cgroup содержится только корневая cgroup, «/», которой принадлежат все процессы. Новая cgroup создаётся посредством создания каталога в файловой системе cgroup:

```
mkdir /sys/fs/cgroup/cpu/cg1
```

Данная команда создаёт новую пустую cgroup.

Помещение процесса в эту cgroup выполняется с помощью записи его PID в файл cgroup cgroup.procs:

```
echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs
```

В этот файл единовременно должен записываться только один PID.

Запись в файл cgroup.procs значения 0 приводит к помещению в соответствующую cgroup записывающего процесса.

При записи PID в cgroup.procs в новую cgroup одновременно перемещаются все нити процесса.

Внутри иерархии процесс может быть членом только одной cgroup. Запись PID процесса в файл cgroup.procs автоматически удаляет его из cgroup, в которой он числился до этого.

Для получения списка процессов, числящихся в cgroup, можно прочитать файл cgroup.procs. Возвращаемый список PID не обязательно упорядочен. Также PID могут повторяться (например, во время чтения списка PID может использоваться повторно).

В cgroups v1 отдельные нити могут перемещаться в другую cgroup посредством записи ID нити (т. е., ядерный ID нити, возвращаемый clone(2) и gettid(2)) в файл tasks из каталога cgroup. Этот файл можно прочитать, чтобы получить набор нитей, принадлежащих cgroup.

### Удаление cgroups
Удаляемая cgroup не должна содержать дочерних cgroups и процессов (не зомби). Если это соблюдается, то можно просто удалить соответствующий каталог. Заметим, что файлы в каталоге cgroup невозможно и ненужно удалять.

### Выпуск уведомлений cgroups v1
Для определения того, как ядро выполняет уведомления об опустевших cgroup, можно использовать два файла. Cgroup считается пустой, если не содержит дочерних cgroup и процессов.

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

По умолчанию файл release_agent пуст, то есть агент освобождения не вызывается.

Содержимое файла release_agent также можно задать в параметре монтирования при монтировании файловой системы cgroup:

```
mount -o release_agent=файл …
```

Будет ли программа release_agent вызываться для определённой ставшей пустой cgroup, задаётся значением файла notify_on_release в каталоге, соответствующем cgroup. Если этот файл содержит значение 0, то программа release_agent не вызывается. Если он содержит 1, то программа release_agent вызывается. По умолчанию в этом файле содержится 0 для корневой cgroup. В момент, когда создаётся новая cgroup, значение в этом файле наследуется из соответствующего файла родительской cgroup.

### Именованные иерархии cgroup v1
В cgroups v1 возможно монтирование иерархии cgroup, у которой нет присоединённых контроллеров:

```
mount -t cgroup -o none,name=какое-то_имя none /some/mount/point
```

Можно смонтировать несколько экземпляров таких иерархий; каждая иерархия должна иметь уникальное имя. Единственной целью таких иерархий является слежение за процессами (смотрите описание о выдаче уведомлений ниже). В пример можно привести иерархию cgroup name=systemd, которая используется systemd(1) для слежения за службами и пользовательскими сеансами.

Начиная с Linux 5.0, параметром ядра cgroup_no_v1 (описан ниже) можно выключить иерархию cgroup v1 с определённым именем: cgroup_no_v1=named.

## CGROUPS ВЕРСИИ 2
В cgroup v2 все смонтированные контроллеры располагаются в единой унифицированной иерархии. Хотя (различные) контроллеры могут одновременно монтироваться в иерархиях v1 и v2, невозможно одновременное монтирование одного контроллера в обеих иерархиях v1 и v2.

Далее приведено краткое описание новых правил поведения cgroups v2, и в некоторых случаях, расширено в последующих подразделах.

1.

Cgroups v2 предоставляет унифицированную иерархию всех смонтированных контроллеров.

2.

«Внутренние» процессы запрещены. За исключением корневой группы cgroup, процессы могут располагаться только в крайних узлах (группа cgroup, которая не содержит дочерних групп cgroup). Подробности несколько более тонкие, чем эти и описаны ниже.

3.

Требуется указывать активные cgroup-ы через файлы cgroup.controllers и cgroup.subtree_control.

4.

Удалён файл tasks. Также удалён файл cgroup.clone_children, использовавшийся контроллером cpuset.

5.

Улучшенный механизм уведомлений о пустых cgroup доступен через файл cgroup.events.

Дополнительную информацию смотрите в файле исходного кода ядра Documentation/cgroup-v2.txt.

Некоторые новые упомянутые выше функциональные возможности появились с добавлением в Linux 4.14 «режима нитей» (смотрите далее).

### Унифицированная иерархия cgroups v2
В cgroups v1, способность монтировать различные контроллеры в разные иерархии предназначалась для повышения гибкости при разработки приложения. Однако на практике выяснилось, что гибкость не так полезна как ожидалось, и во многих случаях добавляет сложности. Поэтому в cgroups v2, все доступные контроллеры монтируются в одну иерархию. Доступные контроллеры монтируются автоматически, то есть не нужно (но можно) указывать контроллеры при монтировании файловой системы cgroup v2 с помощью команды вида:

```
mount -t cgroup2 none /mnt/cgroup2
```

Контроллер cgroup v2 доступен только, если он уже не смонтирован в иерархии cgroup v1. Или, иначе говоря, невозможно использовать тот же контроллер одновременно в иерархии v1 и унифицированной иерархии v2. Это означает, что сначала может потребоваться размонтировать контроллер v1 (как описано выше), чтобы он стал доступен в v2. Так как systemd(1) по умолчанию интенсивно использует некоторые контроллеры v1, в некоторых случаях проще загрузить систему с отключёнными контроллерами v1. Для этого укажите параметр cgroup_no_v1=список в командной строке загрузки ядра; в списке через запятую перечисляются имена отключаемых контроллеров или указывается слово all для выключения всех контроллеров v1 (этот вариант корректно отрабатывается systemd(1) и она начинает работать без указанных контроллеров).

Заметим, что во многих современных системах systemd(1) автоматически монтирует файловую систему cgroup2 в каталог /sys/fs/cgroup/unified при запуске системы.

### Контроллеры cgroups v2
Следующие контроллеры, описанные в файле исходного кода ядра Documentation/cgroup-v2.txt, поддерживаются в cgroups версии 2:

io (начиная с Linux 4.5)

Приемник контроллера blkio версии 1.

memory (начиная с Linux 4.5)

Приемник контроллера memory версии 1.

pids (начиная с Linux 4.5)

Совпадает с контроллером pids версии 1.

perf_event (начиная с Linux 4.11)

Совпадает с контроллером perf_event версии 1.

rdma (начиная с Linux 4.11)

Совпадает с контроллером rdma версии 1.

cpu (начиная с Linux 4.15)

Приемник контроллеров cpu и cpuacct версии 1.

### Управление поддеревом cgroups v2
Каждая cgroup в иерархии v2 содержит следующие два файла:

cgroup.controllers

Доступный только для чтения файл со списком контроллеров, доступных в этой cgroup. Содержимое этого файла совпадает с содержимым файла cgroup.subtree_control в родительской cgroup.

cgroup.subtree_control

Список контроллеров, активных (включённых) в cgroup. Набор контроллеров в этом файле является поднабором cgroup.controllers этой cgroup. Изменение набора активных контроллеров выполняется записью строк в этот файл с именами контроллеров через пробел; перед именами указывается «+» (включить контроллер) или «-» (выключить контроллер), как в следующем примере:

```
echo '+pids -memory' > x/y/cgroup.subtree_control

```

Попытка включить контроллер, который отсутствует в cgroup.controllers, приводит к ошибке ENOENT при записи в файл cgroup.subtree_control.

Так как список контроллеров в cgroup.subtree_control является поднабором из cgroup.controllers, то контроллер, отключённый в иерархии cgroup, невозможно включить в поддереве ниже этой cgroup.

Файл cgroup cgroup.subtree_control определяет набор контроллеров, которые выполняются в дочерних cgroup. Когда контроллер (например pids), есть в файле cgroup.subtree_control родительской cgroup, то соответствующие файлы интерфейса контроллера (например pids.max) автоматически создаются в дочерних cgroup и могут использоваться для влияния на управление ресурсами в дочерних cgroup.

### Правило cgroups v2 «нет внутренним процессам»
Cgroups v2 вводит так называемое правило «нет внутренним процессам». Грубо говоря, это правило означает, что за исключением корневой cgroup, процессы могут располагаться только в краевых узлах (cgroup, которая не содержит дочерних cgroup). Это позволяет не решать как делить ресурсы между процессами, которые являются членами cgroup A и процессами в дочерних cgroup-ах A.

Например, если существует cgroup /cg1/cg2, то процесс может располагаться в /cg1/cg2, но не в /cg1. Это решает проблему с неясностью в cgroups v1 в плане разделения ресурсов между процессами в /cg1 и её дочерних cgroup-ах. Рекомендуемый подход в cgroups v2 — создать подкаталог leaf для всех конечных cgroup, в котором будут содержаться только процессы и отсутствовать дочерние cgroup-ы. То есть процессы, которые раньше находились в /cg1 теперь должны помещаться в /cg1/leaf. Преимуществом этого является явное указание родства между процессами в /cg1/leaf и в других потомках /cg1.

На самом деле, правило «нет внутренним процессам» не столь категорично как утверждалось выше. Более точно, правило состоит в том, что (не корневая) cgroup не может одновременно (1) иметь процессы-члены и (2) распределять ресурсы в дочерних cgroup, то есть иметь непустой файл cgroup.subtree_control. Таким образом, cgroup может иметь процессы-члены и дочерние cgroup, но перед тем как в этой группе можно будет включить контроллеры, члены-процессы нужно вывести из cgroup (например, в дочерние cgroup).

С добавлением в Linux 4.14 «режима нитей» (смотрите далее) для некоторых случаев применение правила «не внутренних процессов» было ослаблено.

### Файл cgroup.events в cgroups v2
В cgroups v2 появился новый механизм получения уведомления при появлении пустой cgroup. Файлы cgroups v1 release_agent и notify_on_release удалены и заменены новым, более общим файлом cgroup.events. В этом доступном только для чтения файле содержится пара ключ-значение (пары разделяются символом новой строки, ключ и значение разделяется пробелами), которые определяют события или состояние cgroup. В настоящее время доступен только один ключ, populated, который имеет значение 0, означающее, что эта cgroup (и её потомки) не содержат процессов (не зомби), или 1, означающее, что cgroup содержит процессы.

За файлом cgroup.events можно установить наблюдение и получить уведомление, когда cgroup изменяет состояние с пустой на непустую и наоборот. При наблюдении за файлом с помощью inotify(7) во время перехода генерируются события IN_MODIFY, а при наблюдении с помощью poll(2) во время перехода в возвращаемом поле revents устанавливаются биты POLLPRI и POLLERR.

Механизм уведомлений cgroups v2, предоставляемый полем populated в файле cgroup.events имеет, по крайней мере, два преимущества над механизмом cgroups v1 release_agent. Во-первых, уведомление менее требовательно, так как один процесс может следить за несколькими файлами cgroup.events. Для сравнения, механизм cgroups v1 требует создания процесса для каждого уведомления. Во-вторых, уведомление может бы поручено процессу, который находится внутри контейнера, связанного с только что созданной пустой cgroup.

### Файл cgroup.stat в cgroups v2
Каждая cgroup в иерархии v2 содержит файл cgroup.stat, доступный только для чтения (появился в Linux 4.14), который состоит из строк с парами ключ-значение. В этом файле появляются следующие ключи:

nr_descendants

Общее количество видимых (т. е., живых) cgroups — потомков этой cgroup.

nr_dying_descendants

Общее количество прекративших работу cgroups — потомков этой cgroup. cgroups входит в состояния прекращения жизнедеятельности после удаления. Она остаётся в таком состоянии на неопределённых срок (зависит от системной нагрузки), хотя ресурсы освобождаются до уничтожения cgroup. Заметим, что существование несколькими cgroups в состоянии прекращения жизнедеятельности нормально и не указывает на проблему.

Процесс не может стать членом прекратившей работу cgroup, и такая cgroup не может опять заработать.

### Ограничение на количество дочерних cgroups
Каждая cgroup в иерархии v2 содержит следующие файлы, которые можно использовать для просмотра и изменения количества дочерних cgroup в cgroup:

cgroup.max.depth (начиная с Linux 4.14)

Этим файлом задаётся ограничение глубины вложенности дочерних cgroup. Значение 0 означает запрет на создание дочерних cgroup. Попытка создать потомка, чья глубина вложенности превышает ограничение, завершается ошибкой (mkdir(2) завершается ошибкой EAGAIN).

Запись строки "max" в этот файл означает, что ограничение отсутствует. Значением по умолчанию для файла является "max".

cgroup.max.descendants (начиная с Linux 4.14)

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

Запись строки "max" в этот файл означает, что ограничение отсутствует. Значением по умолчанию для файла является "max".

## ДЕЛЕГИРОВАНИЕ CGROUPS: ДЕЛЕГИРОВАНИЕ ИЕРАРХИИ МЕНЕЕ ПРИВИЛЕГИРОВАННОМУ ПОЛЬЗОВАТЕЛЮ
В контексте cgroups, делегирование означает передачу управления частью поддерева иерархии cgroup непривилегированному пользователю. Cgroups v1 предоставляют поддержку делегирования на основе файловых прав доступа в иерархии cgroup, но эти правила менее ограничительны по сравнению с v2 (смотрите далее). Поддержка делегирования в cgroups v2 планировалась изначально. В основном, этот раздел описывает делегирование для cgroups v2, попутно указывая различия с cgroups v1.

Для описания делегирования необходима некоторая терминология. Делегирующий это привилегированный пользователь (т.е., корневой объект), которому принадлежит родительская группа cgroup. Делегат это непривилегированный пользователь, которому будут предоставлены права, необходимые для управления некоторой субиерархией в родительской группе cgroup, также называемой делегированным поддеревом.

Для делегирования, делегирующий создает определённые каталоги и файлы, доступные на запись делегату, обычно, назначая владельцем объектов идентификатором пользователя-делегата. Предполагая, что нужно делегировать иерархию с корнем (например) /dlgt_grp и что пока нет каких-либо дочерних cgroups в cgroup, меняем владельца на идентификатор пользователя-делегата у следующего:

/dlgt_grp

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

/dlgt_grp/cgroup.procs

Смена владельца этого файла означает, что делегат может перемещать процессы в корень делегированного ему поддерева.

/dlgt_grp/cgroup.subtree_control (только cgroups v2)

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

/dlgt_grp/cgroup.threads (только cgroups v2)

Смена владельца этого файла требуется для делегирования поддерева с нитями (смотрите описание «режима нитей» далее). Это позволяет делегату записывать в файл ID нитей (также может быть изменён владелец файла для делегирования поддерева домена, но пока это ни к чему не приводит, так как, судя по описанному далее, невозможно перемещать нить между cgroup домена просто записывая ID нити в файл cgroup.threads).

В cgroups v1 соответствующим файлом вместо делегируемого должен быть файл tasks.

Делегирующий не должен изменять владельцев файлов интерфейса контроллера (например, pids.max, memory.high) в dlgt_grp. Эти файлы используются со следующего уровня над делегируемым поддеревом, чтобы распределить ресурсы в поддерево, и делегат не должен иметь права изменять ресурсы, распределённые в делегируемое поддерево.

Информацию о других делегируемых файлах cgroups v2 смотрите описание файла /sys/kernel/cgroup/delegate в ЗАМЕЧАНИЯХ.

После выполнения вышеуказанных шагов делегат может создавать подгруппы cgroups в рамках делегированного поддерева (подкаталоги cgroup и файлы в них будут принадлежать делегату) и перемещать процессы между группами cgroup в поддереве. Если в dlgt_grp/cgroup.subtree_control есть контроллеры, или право владения этим файлом перешло к делегату, то делегат также может управлять дальнейшим распределением соответствующих ресурсов в делегированном ему поддереве.

### Делегирование cgroups v2: nsdelegate и пространство имён cgroup
Начиная с Linux 4.13 появился второй способ делегирования cgroup в иерархии cgroups v2. Этого можно достичь монтированием или перемонтированием файловой системы cgroup v2 с параметром монтирования nsdelegate. Например, если файловая система cgroup v2 уже смонтирована, то её можно перемонтировать с параметром nsdelegate следующим образом:

```
mount -t cgroup2 -o remount,nsdelegate \

                 none /sys/fs/cgroup/unified
```

Данный параметр монтирования заставляет пространства имён cgroup автоматически устанавливать границы делегирования. При этом на процессы внутри пространства имён cgroup накладываются следующие ограничения:

- Запись в файлы интерфейса к контроллерам в корневом каталоге пространства имён завершаются ошибкой EPERM. Процессы внутри пространства имён cgroup по-прежнему могут писать в делегированные файлы корневого каталога пространства имён cgroup (такие как cgroup.procs и cgroup.subtree_control) и могут создавать новые иерархии в корневом каталоге.

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

Возможность определения пространств имён cgroup для границ делегирования делает пространства имён cgroup ещё более полезными. Чтобы понять почему, предположим, что у нас уже есть одна иерархия cgroup, которая была делегирована непривилегированному пользователю, cecilia, посредством старого способа делегирования, описанного выше. Также предположим, что cecilia тоже хочет делегировать одну иерархий из имеющихся в делегированной иерархии (например, делегированная иерархия может быть связана с непривилегированным контейнером, запущенным cecilia). Даже, если пространство имён cgroup namespace было передано, так как обе иерархии принадлежат непривилегированному пользователю cecilia, могут быть выполнены следующие неправомерные действия:

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

- Процесс в нижележащей иерархии может перемещать процессы в и из нижележащей иерархии, если cgroup вышестоящей иерархии видима откуда-то ещё.

Использование параметра монтирования nsdelegate предотвращает обе эти возможности.

Параметр монтирования nsdelegate действует только, когда применяется к начальному пространству имён монтирования; для других пространств имён монтирования он игнорируется.

Замечание: в некоторых системах systemd(1) автоматически монтирует файловую систему cgroup v2. Чтобы попробовать работу с nsdelegate , может быть полезно загрузить ядро с следующими параметрами командной строки:

```
cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller
```

Эти параметры заставляют ядро загружаться с выключенными контроллерами cgroups v1 (т. е., контроллеры доступны из иерархии v2) и указывают systemd(1) не монтировать и использовать иерархию cgroup v2, таким образом позволяя вручную смонтировать иерархию v2 с желаемыми параметрами после загрузки.

### Сдерживающие правила делегирования cgroup
Некоторые сдерживающие правила делегирования обеспечивает то, что делегат может перемещать процессы в рамках делегированного поддерева, но не сможет перемещать процессы извне делегированного поддерева в поддерево и наоборот. Непривилегированный процесс (т. е., делегат) может записать PID «целевого» процесса в файл cgroup.procs только, если всё следующее верно:

- Писатель имеет права на запись в файл cgroup.procs в группе назначения cgroup.

- Писатель имеет права на запись в файл cgroup.procs в ближайшем общем предке для cgroups источника и назначения. Заметим, что в некоторых случаях, ближайшим общим предком может быть сама cgroup источника или назначения. Это требование не выполняется в иерархиях cgroups v1, в следствие чего сдерживание в v1 менее ограничительно, чем v2 (например, в cgroups v1 пользователь, которому принадлежат две разных делегированных подиерархий, может перемещать процесс между этими иерархиями).

- Если файловая система cgroup v2 смонтирована с параметром nsdelegate, то писатель способен видеть cgroup источника и приёмника из своего пространства имён cgroup.

- В cgroups v1: эффективный UID писателя (т. е., делегата) совпадает с реальным пользовательским ID или сохранённым set-user-ID процесса назначения. До Linux 4.11 это требование также применялось к cgroups v2 (это исторически сложившиеся требование, унаследовано от cgroups v1, которое позднее сочли ненужным, так как достаточно других сдерживающих правил cgroups v2).

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

## РЕЖИМ НИТЕЙ CGROUPS ВЕРСИИ 2
Ограничения, налагаемые cgroups v2, но отсутствующие в cgroups v1:

- Нет понитевого управления: все нити процесса должны быть в одной cgroup.

- Нет внутренних процессов: cgroup не может иметь одновременно процессов-членов и выполняемых контроллеров в дочерних cgroup.

Эти ограничения добавлены из-за того, что их отсутствие вызывало проблемы в cgroups v1. В частности, возможность понитевого контроля членства в cgroups v1 приводило к бессмысленности некоторых контроллеров (особенно это касалось контроллера memory: так как нити используют одно адресное пространство, нет смысла разделять нити по разным memory cgroup).

В первоначальном решении проекта cgroups v2 не учитывалось, что для некоторых контроллеров, таких как cpu, было бы важным и полезным задействовать понитевое управление. Чтобы приспособиться под такие случаи, в Linux 4.14 для cgroups v2 добавлен режим нитей.

Режим нитей позволяет следующее:

- Создание поддеревьев нитей, в которых нити процесса могут размещаться по нескольким cgroup внутри дерева (поддерево нитей может содержать несколько многонитевых процессов).

- Концепцию контроллеров нитей, которые могут распределять ресурсы между cgroup в поддереве нитей.

- Ослабление «правила отсутствия внутренних процессов», то есть внутри поддерева нитей cgroup может одновременно содержать нити и контроль ресурсов над дочерними cgroup.

Также, в режиме нитей каждая не корневая cgroup теперь содержит новый файл, cgroup.type, который отражает и, в некоторых случаях, может использоваться для изменения «типа» cgroup. Этот файл содержит одно из следующих значений типа:

domain

Обычная cgroup v2, предоставляющая попроцессное управление. Если процесс является членом этой cgroup, то все нити процесса (по определению) находятся в одной cgroup. Это тип cgroup по умолчанию, предоставляет такое же поведение, обеспечиваемое для cgroup начальной реализацией cgroups v2.

threaded

Данная cgroup является членом поддерева нитей. В эту cgroup нити могут добавляться, а контроллеры cgroup включаться.

domain threaded

Доменная cgroup, которая служит корнем поддерева нитей. Этот тип cgroup также называется «корнем нитей».

domain invalid

Эта cgroup находится внутри поддерева нитей в «некорректном» состоянии. В cgroup невозможно добавлять процессы, а контроллеры cgroup включать. Единственным действием с этой cgroup (помимо удаления) является преобразование в группу с типом threaded посредством записи строки "threaded" в файл cgroup.type.

Обоснованием сущестования этого «переходного» типа при создании поддерева нитей (вместо того, чтобы ядро сразу преобразовывало все cgroup в корне нитей в тип threaded) является задел для возможных будущих расширений модели режима нитей.

### Сравнение контроллеров домена и нитей
С добавлением режима нитей теперь в cgroups v2 различают два типа контроллеров ресурсов:

- Контроллеры нитей: эти контроллеры поддерживают понитевое управление ресурсами и могут включаться в поддеревья нитей; в результате появляются соответствующие файлы интерфейса контроллера внутри cgroup в поддереве нитей. В Linux 4.19 имеются следующие контроллеры нитей: cpu, perf_event и pids.

- Контроллеры домена: эти контроллеры поддерживают только попроцессное управление ресурсами. С точки зрения контроллера домена все нити процесса всегда находятся в одной группе. Контроллеры домена нельзя включить внутри поддерева нитей.

### Создание поддерева нитей
Существует два способа создания поддерева нитей. Первый:

1.

Записываем строку "threaded" в файл cgroup.type из cgroup y/z, которая в этот момент имеет тип domain. При этом происходит следующее:

- Типом cgroup y/z становится threaded.

- Типом родительской cgroup, y, становится domain threaded. Родительская cgroup является корнем поддерева нитей (также называемая «корнем нитей»).

- Все остальные cgroup в y, которые ещё не относятся к типу threaded преобразуются в тип domain invalid (так как они внутри уже существующих поддеревьев нитей с новом корне нитей). Все в дальнейшем создаваемые cgroup в y также будут иметь тип domain invalid.

2.

Записываем строку "threaded" в каждую cgroup с domain invalid в y, чтобы преобразовать их в тип threaded. В результате этого шага все нити в корне нитей теперь имеют тип threaded и поддерево нитей теперь полностью работоспособно. Требование записи "threaded" в каждую такую cgroup несколько обременительно, но это позволит расширить модель режима нитей в будущем.

Второй способ создания поддерева нитей:

1.

В существующей cgroup, z, которая имеет тип domain: (1) включаем один или несколько контроллеров нитей и (2) делаем процесс членом z (эти два шага можно выполнять в любом порядке). При этом происходит следующее:

- Типом z становится domain threaded.

- Все дочерние cgroup x, не имеющие типа threaded, преобразуются в тип domain invalid.

2.

Как и ранее, делаем работоспособным поддерево нитей записывая строку "threaded" в каждую cgroup с domain invalid в y, чтобы преобразовать их в тип threaded.

Следствием одного из этих путей создания поддерева нитей является то, что cgroup корня нитей может быть родителем только cgroup с типом threaded (и domain invalid). cgroup корня нитей не может быть родителем cgroup с типом domain и cgroup с типом threaded не может быть на одном уровне с cgroup с типом domain.

### Использование поддерева нитей
В поддереве нитей можно включать контроллеры нитей для каждой подгруппы, чей тип был изменён на threaded; после того, как это сделано, файлы интерфейса соответствующего контроллера появятся в дочерних cgroup.

Процесс можно перемещать в поддерево нитей посредством записи его PID в файл cgroup.procs одной из cgroup внутри дерева. В результате все нити процесса становятся членами соответствующей cgroup,а процесс — членом поддерева нитей. После этого нити процесса можно размещать по поддереву нитей посредством записи ID нитей (смотрите gettid(2)) в файлы cgroup.threads различных cgroup внутри поддерева. Все нити процесса должны быть расположены в одном поддереве нитей.

Как и при записи в cgroup.procs, при записи в файл cgroup.threads накладываются некоторые сдерживающие правила:

- Писатель должен иметь права на запись в файл cgroup.threads целевой cgroup.

- Писатель должен иметь права на запись в файл cgroup.procs в общем предке для cgroups источника и назначения (в некоторых случаях, общим предком может быть сама cgroup источника или назначения).

- Целевая и cgroup назначения должны быть в одном поддереве нитей (попытка переместить нить вне поддерева нитей посредством записи ID этой нити в файл cgroup.threads другой cgroup с типом domain завершится ошибкой EOPNOTSUPP).

Файл cgroup.threads существует в каждой cgroup (включая cgroup c типом domain) и может быть прочитан для нахождения набора нитей, представленных в группе. Для набора ID нитей, получаемых при чтении этого файла, не гарантируется порядок и отсутствие повторов.

Файл cgroup.procs в корне нитей отражает PID всех процессов, являющихся членами поддерева нитей. Файлы cgroup.procs других cgroup в поддереве недоступны для чтения.

Доменные контроллеры невозможно включить в поддереве нитей; в cgroup ниже корня нитей отсутствуют интерфейсные файлы контроллера. С точки зрения доменного контроллера поддеревья нитей невидимы: многонитевые процессы внутри поддерева нитей видятся доменным контроллером как процесс, расположенный в cgroup корня нитей.

В поддереве нитей правило «нет внутренних процессов» не применяется: cgroup может иметь одновременно процессы-члены (или нить) и выполняемые контроллеры в дочерних cgroup.

### Правила записи в cgroup.type и создание поддеревьев нитей
При записи в файл cgroup.type накладывается несколько правил:

- Можно записать только строку "threaded". Другими словами, единственный возможный переход это преобразование domain cgroup к типу threaded.

- Последствия от записи "threaded" зависит от текущего значения в cgroup.type:

- domain или domain threaded: начинается создание поддерева нитей (корнем будет родитель этой cgroup) посредством первого способа, описанного выше;

- domain invalid: эта cgroup (находящаяся внутри поддерева нитей) переводится в работоспособное состояние (т. е., threaded);

- threaded: ничего не происходит («нет действия»).

*

Нельзя писать в файл cgroup.type, если тип родителя domain invalid. Иначе говоря, все cgroup поддерева нитей должны быть преобразованы в состояние threaded по нисходящей.

Также для создания поддерева нитей с корнем cgroup x требуется выполнить несколько условий:

- Не должно быть процессов-членов в дочерних cgroup x (сама cgroup x может иметь процессы-члены).

- Не должно быть включённых доменных контроллеров для x в файле cgroup.subtree_control.

Если какое-либо из этих ограничений нарушено, то попытка записи "threaded" в файл cgroup.type завершится ошибкой ENOTSUP.

### Тип cgroup «domain threaded»
Согласно способам, описанным выше, тип cgroup можно измениться на domain threaded в следующих случаях:

- В дочернюю cgroup записывается строка "threaded".

- Внутри cgroup включён контроллер нитей и процесс стал членом cgroup.

Cgroup с типом domain threaded, x, может снова стать domain, если перечисленные выше условия не соблюдаются — то есть, если удалены все потомки cgroup x с типом threaded, у x выключены все контроллеры нитей или больше нет процессов-членов.

Когда cgroup x с типом domain threaded возвращается к типу domain:

- Все потомки x с domain invalid, находящиеся не ниже уровня поддеревьев нитей, получают тип domain.

- Корневым cgroup, находящимся ниже поддеревьев нитей возвращается тип domain threaded.

### Исключения для корневой cgroup
Корневая cgroup иерархии v2 рассматривается отдельно: она может быть родителем cgroup сразу обоих типов: domain и threaded. Если строка "threaded" записывается в файл cgroup.type одного из потомков корневой cgroup, то

- Типом этой cgroup становится threaded.

- Тип всех потомков этой cgroup, не являющихся частью уровня ниже поддеревьев нитей, изменяется на domain invalid.

Заметим, что в этом случае нет cgroup, чей тип стал domain threaded (в принципе, корневая cgroup может рассматриваться как корень нитей для cgroup, чей тип был изменён на threaded).

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

### Контроллер «cpu» cgroups v2 и нити реального времени
Начиная с Linux 4.19, контроллер cgroups v2 cpu не поддерживает управление нитями реального времени(нити, запланированные к выполнению планировщиками SCHED_FIFO, SCHED_RR, SCHED_DEADLINE; смотрите sched(7)). Поэтому контроллер cpu можно включить в корневую cgroup только, если все нити реального времени находятся в корневой cgroup (если есть нити реального времени вне корневой cgroups, то запись (write(2)) строки "+cpu" в файл cgroup.subtree_control завершится ошибкой EINVAL).

В некоторых системах systemd(1) помещает определённые нити реального времени в некорневую cgroups иерархии v2. В таких системах такие нити должны помещаться раньше в корневую cgroup, до включения контроллера cpu.

## ОШИБКИ
Следующие ошибки могут возникать при mount(2):

EBUSY

При монтировании файловой системы cgroup версии 1 не указан параметр name= (для монтирования именованной иерархии) или имя контроллера (или all).

## ЗАМЕЧАНИЯ
Дочерний процесс, созданный fork(2), наследует членство родителя в cgroup. Членство в cgroup сохраняется при execve(2).

### Файлы в /proc
/proc/cgroups (начиная с Linux 2.6.24)

В этом файле содержится информация о контроллерах, с которыми было собрано ядро. Пример содержимого файла (переформатирован для читабельности):

```
#subsys_name    hierarchy      num_cgroups    enabled
cpuset          4              1              1
cpu             8              1              1
cpuacct         8              1              1
blkio           6              1              1
memory          3              1              1
devices         10             84             1
freezer         7              1              1
net_cls         9              1              1
perf_event      5              1              1
net_prio        9              1              1
hugetlb         0              1              0
pids            2              1              1

```

Поля файла, слева направо:

1.

Имя контроллера.

2.

Уникальный ID иерархии cgroup, на которой смонтирован контроллер. Если к одной иерархии привязано несколько контроллеров cgroups v1, то для каждого в этом поле будет показан одинаковый ID иерархии. Значение поля равно 0, если:

1.

контроллер не смонтирован на иерархию cgroups v1;

2.

контроллер привязан к унифицированной иерархии cgroups v2; или

c)

контроллер отключён (смотрите ниже).

3.

Количество контролируемых групп в этой иерархии, использующих этот контроллер.

4.

В этом поле содержится значение 1, если этот контроллер включён, или 0, если он выключен (с помощью параметра cgroup_disable командной строки загрузки ядра).

/proc/[pid]/cgroup (начиная с Linux 2.6.24)

Этот файл описывает управляемые группы, которым принадлежит процесс с соответствующим PID. Отображаемая информация отличается для иерархий cgroups версии 1 и 2.

Для каждой иерархии cgroup, членом которой является процесс, существует одна запись, состоящая из трёх полей через двоеточие:

```
ID иерархии:список контроллеров:путь cgroup

```

Пример:

```
5:cpuacct,cpu,cpuset:/daemons

```

Поля, разделяемые двоеточием, слева направо:

1.

Для иерархии cgroups версии 1 это поле содержит уникальный ID номер иерархии, который может совпадать с ID иерархии в /proc/cgroups. Для иерархии cgroups версии 2 это поле содержит значение 0.

2.

Для иерархии cgroups версии 1 это поле содержит список контроллеров, привязанных к иерархии, перечисленных через запятую. Для иерархии cgroups версии 2 это поле пусто.

3.

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

### Файлы /sys/kernel/cgroup
/sys/kernel/cgroup/delegate (начиная с Linux 4.15)

Этот файл экспортирует список файлов cgroups v2 (один на строку), которые можно делегировать (т. е., у которых можно изменить владельца на пользовательских ID делегата). В будущем, наборов доступных для делегирования файлов может измениться или вырасти, а этот файл предоставляет способ, которым ядро информирует приложения пользовательского пространства о необходимых для делегирования файлах. В Linux 4.15 в этом файле можно увидеть следующее:

```
$ cat /sys/kernel/cgroup/delegate
cgroup.procs
cgroup.subtree_control
cgroup.threads

```

/sys/kernel/cgroup/features (начиная с Linux 4.15)

Со временем набор возможностей cgroups v2, предоставляемых ядром, может измениться или вырасти, или некоторые возможности по умолчанию могут быть отключены. Этот файл предоставляет способ, которым приложения пользовательского пространства могут узнать о том, какие возможности поддерживает работающее ядро и какие из них включены. Возможности перечисляются по одной на строку:

```
$ cat /sys/kernel/cgroup/features
nsdelegate

```

В этом файле может появляться следующее:

nsdelegate (начиная с Linux 4.15)

Поддержка параметра монтирования nsdelegate ядром.

## СМОТРИТЕ ТАКЖЕ
prlimit(1), systemd(1), systemd-cgls(1), systemd-cgtop(1), clone(2), ioprio_set(2), perf_event_open(2), setrlimit(2), cgroup_namespaces(7), cpuset(7), namespaces(7), sched(7), user_namespaces(7)


charsets

package: man-pages-ru

title: charsets(7)

text:
# charsets(7)

## ИМЯ
charsets - стандарты наборов символов и интернационализация

## ОПИСАНИЕ
В этой справочной странице представлен обзор различных стандартов наборов символов и их использование в Linux до повсеместного распространения Юникода. Часть данной информации будет полезна людям, работающим в старых системах или со старыми документами.

Обсуждаемые стандарты: ASCII, GB 2312, ISO 8859, JIS, KOI8-R, KS и Юникод.

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

### ASCII
ASCII (American Standard Code For Information Interchange; американский стандартный код для обмена информацией) — первоначальный 7-битный набор символов, разработанный для американского варианта английского языка. Также известен как US-ASCII. В настоящее время описан в стандарте ISO 646:1991 IRV (International Reference Version).

Существуют различные варианты (из 7 бит) ASCII, в которых американский символ доллара и знаки пунктуации заменяются на знаки валют различных стран (Германия, Франция, Испания и другие). Все эти наборы устарели; в glibc не поддерживаются локали, которые в действительности не содержат набор ASCII.

Юникод, при использовании UTF-8, является совместимым с ASCII; простой (plain) текст ASCII по-прежнему отображается корректно в современных системах, использующих UTF-8.

### ISO 8859
ISO 8859 — это серия из 15-и 8-битных наборов символов, каждый из которых имеет в своей нижней (7-битной) половине коды ASCII, невидимые управляющие символы в позициях от 128 до 159 и 96 графических символов фиксированной ширины в позициях 160–255.

Из них самой важной является последовательность ISO 8859-1 («Latin Alphabet No .1» / Latin-1). Она широко распространена, поддерживается различными системами и постепенно заменяется Юникодом. Символы ISO 8859-1 также являются первыми 256 символами Юникода.

Поддержка в консоли других наборов символов 8859 осуществляется в Linux с помощью пользовательских утилит (таких, как setfont(8)), меняющих привязки клавиатуры, таблицу графики EGA и передающих драйверу консоли таблицу соответствий символов шрифтам.

Ниже приводится краткое описание каждого набора:

8859-1 (Latin-1)

Latin-1 охватывается большинство западноевропейских языков, таких, как: албанский, баскский, датский, английский, фарезский, галисийский, исландский, ирландский, итальянский, норвежский, португальский, испанский и шведский. Отсутствие лигатуры Ĳ/ĳ голландского языка, œ французского языка и старых „немецких“ кавычек считается приемлемым.

8859-2 (Latin-2)

Latin-2 охватывает множество славянских и центрально и восточно-европейских языков: боснийский, хорватский, чешский, немецкий, венгерский, польский, словацкий и словенский. Замена румынского ș/ț на ş/ţ считается приемлемым.

8859-3 (Latin-3)

Latin-3 охватывает эсперанто, мальтийский и турецкий языки (но турецкий сейчас охватывается 8859-9).

8859-4 (Latin-4)

Latin-4 охватывает северо-европейские языки: эстонский, латвийский и литовский языки. Но сейчас они охватываются 8859-10 и 8859-13.

8859-5

Кириллические символы болгарского, белорусского, македонского, русского, сербского и (почти полностью) украинского языков. Никогда широко не использовался, смотрите ниже описание KOI8-R/KOI8-U.

8859-6

Был создан для арабского языка. Таблица начертаний (глифов) 8859-6 — это шрифт отдельных форм букв постоянной ширины; корректная программа отображения должна объединить их, используя корректные начальные, промежуточные и конечные формы.

8859-7

Был создан для современного греческого языка в 1987 году, обновлён в 2003 году.

8859-8

Поддерживает современный иврит без niqud (знаки пунктуации). Niqud и полный библейский иврит не входят в этот набор.

8859-9 (Latin-5)

Это вариант Latin-1, в котором исландские буквы заменены турецкими.

8859-10 (Latin-6)

Latin-6 добавляет последние инуитские (гренландские) буквы и буквы сами (Sami Lappish), отсутствующие в Latin-4, для того, чтобы объединить шрифты всех нордических языков.

8859-11

Поддерживает тайский алфавит и очень похож на стандарт TIS-620.

8859-12

Этот набор не существует.

8859-13 (Latin-7)

Поддерживает балтийские языки, в частности, латвийские символы не вошедшие в Latin-4.

8859-14 (Latin-8)

Это кельтский набор символов для старого ирландского, мэнского, гаэлльского, уэльского, корнуэльского и бретонского языков.

8859-15 (Latin-9)

Latin-9 похож на широко используемый Latin-1, но в нём заменены некоторые мало используемые символы на знак евро, а также французские и финские лигатуры, отсутствующие в Latin-1.

8859-16 (Latin-10)

Этот набор включает в себя многие южно-европейские языки, и самое главное, румынский язык поддерживается более полно чем в Latin-2.

### KOI8-R / KOI8-U
KOI8-R — набор символов не ISO, являлся популярным в России до Юникода. Нижняя часть таблицы описывает ASCII, верхняя — набор символов кириллицы, более совершенный по сравнению с ISO 8859-5. KOI8-U, основанный на KOI8-R, имеет более полную поддержку украинского языка. Ни один из этих наборов не совместим с ISO-2022 (в отличии от ISO 8859).

Поддержка символов KOI8-R в консоли осуществляется Linux с помощью пользовательских утилит, меняющих привязки клавиатуры, таблицу графики EGA и передающих драйверу консоли таблицу соответствий символов шрифтам.

### GB 2312
GB 2312 это национальный китайский стандартный набор символов для упрощенного китайского. Как и в JIS X 0208, символы берутся из массива 94x94 и состоят из двух байт. Набор символов используется для кодировки EUC-CN. EUC-CN является наиболее важной кодировкой для Linux и включает в себя ASCII и GB 2312. Заметим, что EUC-CN часто называют GB, GB 2312 или CN-GB.

### Big5
Big5 — ранее популярный набор в Тайване для отображения традиционного китайского языка (Big5 является и кодировкой и набором символов). Он включает в себя ASCII. Символы, не входящие в ASCII, представлены двумя байтами. Первый байт (символ представлен двумя байтами) берётся из диапазона xa1–0xfe. Big5 и его расширение широко используются в Тайване и Гонконге. Он не совместим с ISO 2022.

### JIS X 0208
JIS X 208 является стандартным набором для японского языка. Существуют несколько других японских стандартов, например, JIS X 0201, JIS X 0212 и JIS X 0213, но первый — самый распространенный. Символы берутся из массива 94x94 и представлены двумя байтами, каждый из которых находится в интервале 0x21–0x7e. Заметьте, что JIS X 0208 является набором символов, а не кодировкой. Это означает, что JIS X 0208 не может представлять текстовую информацию самостоятельно, а является лишь компонентом для кодировок, таких как EUC-JP, Shift_JIS и ISO-2022-JP. EUC-JP — наиболее важная кодировка для Linux и включает в себя ASCII и JIS X 0208. В EUC-JP для символов JIS X 0208 отводится по 2 байта, значение каждого из которых равно коду JIS X 0208 плюс 0x80.

### KS X 1001
KS X 1001 это корейский национальный стандарт для наборов символов. Как и в JIS X 0208, символы берутся из матрицы 94x94 и состоят из двух байт. KS X 1001, так же как и JIS X 0208, является компонентом для кодировок EUC-KR, Johab и ISO-2022-KR. EUC-KR является наиболее важной кодировкой для Linux и включает в себя ASCII и KS X 1001. KS C 5601 это старое название KS X 1001.

### ISO 2022 и ISO 4873
Стандарты ISO 2022 и 4873 описывают модель управления шрифтами, основанную на практике работы с VT100. Эта модель (частично) поддерживается ядром Linux и xterm(1). Были определены некоторые наборы символов на основе ISO 2022, особенно популярного в Японии.

Имеется 4 набора графических символов, называемых G0, G1, G2 и G3. Один из них является текущим набором символов для кодов со старшим битом, равным нулю (изначально G0), другой — текущим набором для кодов со старшим битом, равным единице (изначально G1). Каждый набор графических символов имеет 94 или 96 символов и, по сути, является 7-битным набором символов. Используются либо коды 040–0177 (041–0176), либо 0240–0377 (0241–0376). Размер G0 всегда равен 94-м символам и содержит коды 041–0176.

Переключение с одного набора символов на другой производится с помощью функций сдвига ^N (SO или LS1), ^O (SI или LS0), ESC n (LS2), ESC o (LS3), ESC N (SS2), ESC O (SS3), ESC ~ (LS1R), ESC } (LS2R), ESC | (LS3R). Функция LSn делает набор символов Gn текущим для кодов со старшим битом, равным нулю. Функция LSnR делает набор символов Gn текущим для кодов со старшим битом, равным единице. Функция SSn делает набор символов Gn (n=2 или 3) текущим только для следующего символа (независимо от значения старшего бита).

94-символьный набор становится набором символов Gn c помощью последовательности ESC ( xx (для G0), ESC ) xx (для G1), ESC * xx (для G2), ESC + xx (для G3), где xx является символом или парой символов, которая содержится в ISO 2375 International Register of Coded Character Sets (международном реестре кодированных наборов символов). Например, ESC ( @ выбирает в качестве G0 набор символов ISO 646, ESC ( A выбирает стандартный набор символов UK (со знаком фунта вместо знака номера), ESC ( B выбирает ASCII (со знаком доллара вместо знака валюты), ESC ( M выбирает набор символов для африканских языков, ESC ( ! A выбирает кубинский набор символов и т.д. и т.п.

96-символьный набор назначается набором символов Gn с помощью последовательности ESC - xx (для G1), ESC . xx (для G2) или ESC / xx (для G3). Например, ESC - G выбирает иврит в качестве G1.

Мультибайтный набор символов назначается набором символов Gn управляющей последовательностью ESC $ xx или ESC $ ( xx (для G0), ESC $ ) xx (для G1), ESC $ * xx (для G2), ESC $ + xx (для G3). Например, ESC $ ( C выбирает корейский набор символов для G0. Набор японских символов выбирается при помощи ESC $ B, а его более новая версия — при помощи ESC & @ ESC $ B.

ISO 4873 оговаривает более направленное использование наборов символов, при котором G0 постоянен (всегда ASCII), так что G1, G2 и G3 могут быть заданы только для кодов с установленным старшим битом. При этом ^N и ^O больше не используются, ESC ( xx может быть использована только с xx=B, а ESC ) xx, ESC * xx и ESC + xx эквивалентны ESC - xx, ESC . xx и ESC / xx, соответственно.

### TIS-620
TIS -62 — это национальный стандартный набор тайских символов, включающий ASCII. Как и в стандартах ISO 8859, тайские символы находятся в интервале 0xa1–0xfe.

### Юникод
Юникод (ISO 10646) — стандарт, которым можно представить любой символ из всех известных человеку языков. В структуре Юникода на кодирование каждого символа выделяется 20.1 бит. Так как большинство компьютеров не поддерживают целых чисел размерностью 20.1 бит, то Юникод, обычно, кодируется в 32-битных целых, а также или серией 16-ти битных целых (UTF-16, 2 16-битных целых требуется только при кодировании редких символов), или серией 8-битных байт (UTF-8).

Для представления Юникода в Linux используется 8-битный формат преобразования Юникода (UTF-8 - 8-bit Unicode Transformation Format). UTF-8 — это формат непостоянной длины для кодирования Юникода. В нём используется 1 байт для кодирования 7-и битов, 2 байта для 11-и битов, 3 байта для 16-и битов, 4 байта для 21-ого бита, 5 байтов для 26-и битов, 6 байтов для 31-ого бита.

Пусть 0, 1, x соответствует нулю, единице и случайному биту. Байт 0xxxxxxx соответствует Юникоду 00000000 0xxxxxxx, что, в свою очередь, соответствует символу в ASCII 0xxxxxxxx. То есть, коды ASCII совпадают с кодами UTF-8 и людям, использующим только ASCII, ничего делать не нужно: ни в коде, ни в файлах.

Байт 110xxxxx является началом 2-байтного кода, и 110xxxxx 10yyyyyy преобразуется в 00000xxx xxyyyyyy. Байт 1110xxxx — начало 3-байтного кода, и 1110xxxx 10yyyyyy 10zzzzzz преобразуется в xxxxyyyy yyzzzzzz (если UTF-8 используется для кодирования 31-битного ISO 10646, то это прогрессия продолжается до 6-байтных кодов).

Для большинства текстов, кодированных наборами ISO 8859, это означает, что символы, не входящие в ASCII, теперь кодируются двумя байтами. Это приводит к тому, что обычный текстовый файл становится больше на 1-2 процента. Обычные текстовые файлы на греческом или русском языке увеличиваются на 100%, так как почти все символы в этих языках находятся за пределами ASCII. Для пользователей японского языка 16-ти битные символы теперь, в основном, представляются 3-мя байтами. Хотя для некоторых наборов символов (особенно ISO-8859-1) и есть алгоритмы преобразования в Юникод, в большинстве случаев для преобразований требуются таблицы соответствий, которые могут быть большими для 16-битных кодов.

Заметим, что UTF-8 является самосинхронизирующимся: 10xxxxxx — это «хвост», а любой другой байт — «голова» кода. Только байты ASCII в потоке UTF-8 представлены без изменений. В частности, в поток не встраиваются NUL ('\0') или '/' для формирования части какого-то большего кода.

Так как символы ASCII, в частности, NUL и '/', не изменяются, то ядро не замечает, что используется UTF-8. В нём никак не учитывается для чего используются эти байты.

Визуализация потоков данных Юникода обычно производится с помощью таблицы «подшрифтов», переводящей единицы набора Юникода в образы символов (глифы). Внутри ядра Юникод используется для описания подшрифта, загруженного в видеопамять. Это означает, что в консоли Linux в режиме UTF-8 можно использовать набор символов с 512-ю различными символами. Этого недостаточно для японского, китайского и корейского языков, но достаточно для большинства других.

## СМОТРИТЕ ТАКЖЕ
iconv(1), ascii(7), iso_8859-1(7), unicode(7), utf-8(7)

branch: sisyphus


complex

title: complex(7)

summary: основы комплексной математики

text:
# complex(7)

## ИМЯ
complex - основы комплексной математики

## ОБЗОР
\#include <complex.h>

## ОПИСАНИЕ
Комплексные числа — это числа вида z = a+b*i, где a и b являются вещественными числами, и i = sqrt(-1), где i*i = -1.

Существуют и другие способы представления комплексных чисел. Пара вещественных чисел (a,b) может быть представлена как точка на плоскости, которая задаётся координатными осями X и Y. Эта же самая точка может быть также описана парой вещественных чисел (r,phi), где r — это расстояние от нулевой точки отсчёта 0, а phi — угол между осью X и прямой 0z. Итак, z = r*exp(i*phi) = r*(cos(phi)+i*sin(phi)).

Основные операции с комплексными числами, заданными в виде z = a+b*i и w = c+d*i, следующие:

сложение: z+w = (a+c) + (b+d)*i

умножение: z*w = (a*c - b*d) + (a*d + b*c)*i

деление: z/w = ((a*c + b*d)/(c*c + d*d)) + ((b*c - a*d)/(c*c + d*d))*i

Почти все математические функции имеют своих комплексных собратьев, но есть и только комплексные функции.

## ПРИМЕР
Ваш C-компилятор может работать с комплексными числами, если он поддерживает стандарт C99. Компоновку программы нужно производить с параметром -lm. Здесь мнимая единица представлена как I.

```
/* проверка что exp(i * pi) == -1 */
#include <math.h>        /* для atan */
#include <stdio.h>
#include <complex.h>
int
main(void)
{

    double pi = 4 * atan(1.0);

    double complex z = cexp(I * pi);

    printf("%f + %f * i\n", creal(z), cimag(z));
}
```

## СМОТРИТЕ ТАКЖЕ
cabs(3), cacos(3), cacosh(3), carg(3), casin(3), casinh(3), catan(3), catanh(3), ccos(3), ccosh(3), cerf(3), cexp(3), cexp2(3), cimag(3), clog(3), clog10(3), clog2(3), conj(3), cpow(3), cproj(3), creal(3), csin(3), csinh(3), csqrt(3), ctan(3), ctanh(3)


title: cp1251(7)

summary: набор символов CP\ 1251 в восьмеричном, десятичном и

text:
# cp1251(7)

## ИМЯ
cp1251 - набор символов CP 1251 в восьмеричном, десятичном и шестнадцатеричном виде

## ОПИСАНИЕ
В страницы кодов Windows включены некоторые 8-битные расширения набора символов ASCII (также известного как ISO 646-IRV). В CP 1251 кодируются символы, используемые в кириллических письменностях.

### Символы CP 1251
В следующей таблице показаны символы из набора CP 1251, являющиеся печатными и отсутствующие в справочной странице ascii(7).

Вос

Дес

Шес

Симв

Описание

200

128

80

Ђ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «ДЕРВЬ»

201

129

81

Ѓ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «ГЕ»

202

130

82

‚

ОДИНОЧНАЯ LOW-9/НИЖНЯЯ КАВЫЧКА

203

131

83

ѓ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ГЕ»

204

132

84

„

ДВОЙНАЯ LOW-9/НИЖНЯЯ КАВЫЧКА

205

133

85

…

ГОРИЗОНТАЛЬНЫЙ ЭЛЛИПС

206

134

86

†

ТИПОГРАФСКИЙ КРЕСТИК

207

135

87

‡

ДВОЙНОЙ КРЕСТИК

210

136

88

€

ЗНАК ЕВРО

211

137

89

‰

ЗНАК ПРОМИЛЛЕ

212

138

8A

Љ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «ЛЬ»

213

139

8B

‹

ОДИНОЧНАЯ ОТКРЫВАЮЩАЯ УГЛОВАЯ КАВЫЧКА

214

140

8C

Њ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «НЬ»

215

141

8D

Ќ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «КЭ»

216

142

8E

Ћ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «ГЕРВЬ»

217

143

8F

Џ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «ДЖЕ»

220

144

90

ђ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ДЬЖЕ»

221

145

91

‘

ОТКРЫВАЮЩАЯ ОДИНАРНАЯ КАВЫЧКА

222

146

92

’

ЗАКРЫВАЮЩАЯ ОДИНАРНАЯ КАВЫЧКА

223

147

93

“

ОТКРЫВАЮЩАЯ ДВОЙНАЯ КАВЫЧКА

224

148

94

”

ЗАКРЫВАЮЩАЯ ДВОЙНАЯ КАВЫЧКА

225

149

95

•

МЕТКА В ЦЕНТРЕ

226

150

96

–

СРЕДНЕЕ ТИРЕ

227

151

97

—

ДЛИННОЕ ТИРЕ

230

152

98

НЕ ОПРЕДЕЛЕНО

231

153

99

™

ЗНАК ТОРГОВОЙ МАРКИ

232

154

9A

љ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ЛЬ»

233

155

9B

›

ОДИНОЧНАЯ ЗАКРЫВАЮЩАЯ УГЛОВАЯ КАВЫЧКА

234

156

9C

њ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «НЬ»

235

157

9D

ќ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «КЭ»

236

158

9E

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ГЕРВЬ»

237

159

9F

џ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ДЖЕ»

240

160

A0

НЕРАЗРЫВНЫЙ ПРОБЕЛ

241

161

A1

Ў

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА КРАТКАЯ «У»

242

162

A2

ў

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА КРАТКАЯ «У»

243

163

A3

Ј

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «ЙЕ»

244

164

A4

¤

СИМВОЛ ВАЛЮТЫ

245

165

A5

Ґ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Г» С ПОДЪЁМОМ

246

166

A6

¦

ПРЕРЫВИСТАЯ ВЕРТИКАЛЬНАЯ ЧЕРТА

247

167

A7

§

СИМВОЛ ПАРАГРАФА

250

168

A8

Ё

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ё»

251

169

A9

©

ЗНАК ОХРАНЫ АВТОРСКОГО ПРАВА

252

170

AA

Є

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ УКРАИНСКАЯ БУКВА ЯКОРНОЕ «Е»

253

171

AB

«

ОТКРЫВАЮЩАЯ ЛЕВАЯ КАВЫЧКА «ЁЛОЧКА»

254

172

AC

¬

ЗНАК ОТРИЦАНИЯ

255

173

AD

МЯГКИЙ ПЕРЕНОС

256

174

AE

®

ЗАРЕГИСТРИРОВАННЫЙ ТОВАРНЫЙ ЗНАК

257

175

AF

Ї

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА ЙИ

260

176

B0

°

ЗНАК ГРАДУСА

261

177

B1

±

ЗНАК ПЛЮС-МИНУС

262

178

B2

І

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА БЕЛОРУССКО-УКРАИНСКАЯ «И»

263

179

B3

і

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА БЕЛОРУССКО-УКРАИНСКАЯ «И»

264

180

B4

ґ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ГЕ» С ПОДЪЁМОМ

265

181

B5

µ

ЗНАК МИКРО

266

182

B6

¶

ЗНАК АБЗАЦА

267

183

B7

·

ТОЧКА В ЦЕНТРЕ

270

184

B8

ё

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ё»

271

185

B9

№

ЗНАК «НОМЕР»

272

186

BA

є

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА УКРАИНСКАЯ «є»

273

187

BB

»

ЗАКРЫВАЮЩАЯ КАВЫЧКА «ЁЛОЧКА»

274

188

BC

ј

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ЙЕ»

275

189

BD

Ѕ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «ДЗЕ»

276

190

BE

ѕ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ДЗЕ»

277

191

BF

ї

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ЙИ»

300

192

C0

А

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «А»

301

193

C1

Б

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Б»

302

194

C2

В

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «В»

303

195

C3

Г

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Г»

304

196

C4

Д

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Д»

305

197

C5

Е

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Е»

306

198

C6

Ж

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ж»

307

199

C7

З

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «З»

310

200

C8

И

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «И»

311

201

C9

Й

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Й»

312

202

CA

К

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «К»

313

203

CB

Л

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Л»

314

204

CC

М

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «М»

315

205

CD

Н

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Н»

316

206

CE

О

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «О»

317

207

CF

П

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «П»

320

208

D0

Р

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Р»

321

209

D1

С

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «С»

322

210

D2

Т

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА Т

323

211

D3

У

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «У»

324

212

D4

Ф

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ф»

325

213

D5

Х

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Х»

326

214

D6

Ц

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ц»

327

215

D7

Ч

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ч»

330

216

D8

Ш

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ш»

331

217

D9

Щ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Щ»

332

218

DA

Ъ

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА ТВЁРДЫЙ ЗНАК

333

219

DB

Ы

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ы»

334

220

DC

Ь

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА МЯГКИЙ ЗНАК

335

221

DD

Э

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Э»

336

222

DE

Ю

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Ю»

337

223

DF

Я

КИРИЛЛИЧЕСКАЯ ЗАГЛАВНАЯ БУКВА «Я»

340

224

E0

а

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «а»

341

225

E1

б

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «б»

342

226

E2

в

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «в»

343

227

E3

г

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «г»

344

228

E4

д

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «д»

345

229

E5

е

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «е»

346

230

E6

ж

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ж»

347

231

E7

з

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «з»

350

232

E8

и

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА и

351

233

E9

й

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «й»

352

234

EA

к

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «к»

353

235

EB

л

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «л»

354

236

EC

м

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «м»

355

237

ED

н

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «н»

356

238

EE

о

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «о»

357

239

EF

п

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «п»

360

240

F0

р

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «р»

361

241

F1

с

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «с»

362

242

F2

т

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «т»

363

243

F3

у

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «у»

364

244

F4

ф

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ф»

365

245

F5

х

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «х»

366

246

F6

ц

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ц»

367

247

F7

ч

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ч»

370

248

F8

ш

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ш»

371

249

F9

щ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «щ»

372

250

FA

ъ

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА ТВЁРДЫЙ ЗНАК

373

251

FB

ы

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ы»

374

252

FC

ь

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА МЯГКИЙ ЗНАК

375

253

FD

э

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «э»

376

254

FE

ю

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «ю»

377

255

FF

я

КИРИЛЛИЧЕСКАЯ СТРОЧНАЯ БУКВА «я»

## ЗАМЕЧАНИЯ
CP 1251 также известна как Windows Cyrillic.

## СМОТРИТЕ ТАКЖЕ
ascii(7), charsets(7), cp1252(7), iso_8859-5(7), koi8-r(7), koi8-u(7), utf-8(7)


title: cp1252(7)

summary: набор символов CP\ 1252 в восьмеричном, десятичном и

text:
# cp1252(7)

## ИМЯ
cp1252 - набор символов CP 1252 в восьмеричном, десятичном и шестнадцатеричном виде

## ОПИСАНИЕ
В страницы кодов Windows включены некоторые 8-битные расширения набора символов ASCII (также известного как ISO 646-IRV). В CP 1252 кодируются символы, используемые во многих западно-европейских письменностях.

### Символы CP 1252
В следующей таблице показаны символы из набора CP 1252, являющиеся печатными и отсутствующие в справочной странице ascii(7).

Вос

Дес

Шес

Симв

Описание

200

128

80

€

ЗНАК ЕВРО

202

130

82

‚

ОДИНОЧНАЯ LOW-9/НИЖНЯЯ КАВЫЧКА

203

131

83

ƒ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «F» С НЁБНЫМ КРЮЧКОМ

204

132

84

„

ДВОЙНАЯ LOW-9/НИЖНЯЯ КАВЫЧКА

205

133

85

…

ГОРИЗОНТАЛЬНЫЙ ЭЛЛИПС

206

134

86

†

ТИПОГРАФСКИЙ КРЕСТИК

207

135

87

‡

ДВОЙНОЙ КРЕСТИК

210

136

88

ˆ

МОДИФИКАТОР БУКВЫ ШЛЯПА, УДАРЕНИЕ

211

137

89

‰

ЗНАК ПРОМИЛЛЕ

212

138

8A

Š

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «S» С ГАЛОЧКОЙ

213

139

8B

‹

ОДИНОЧНАЯ ОТКРЫВАЮЩАЯ УГЛОВАЯ КАВЫЧКА

214

140

8C

Œ

ЛАТИНСКАЯ ЗАГЛАВНАЯ ЛИГАТУРА «OE»

216

142

8E

Ž

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «Z» С ГАЛОЧКОЙ

221

145

91

‘

ОТКРЫВАЮЩАЯ ОДИНАРНАЯ КАВЫЧКА

222

146

92

’

ЗАКРЫВАЮЩАЯ ОДИНАРНАЯ КАВЫЧКА

223

147

93

“

ОТКРЫВАЮЩАЯ ДВОЙНАЯ КАВЫЧКА

224

148

94

”

ЗАКРЫВАЮЩАЯ ДВОЙНАЯ КАВЫЧКА

225

149

95

•

МЕТКА В ЦЕНТРЕ

226

150

96

–

СРЕДНЕЕ ТИРЕ

227

151

97

—

ДЛИННОЕ ТИРЕ

230

152

98

˜

МАЛАЯ ТИЛЬДА

231

153

99

™

ЗНАК ТОРГОВОЙ МАРКИ

232

154

9A

š

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «S» С ГАЛОЧКОЙ

233

155

9B

›

ОДИНОЧНАЯ ЗАКРЫВАЮЩАЯ УГЛОВАЯ КАВЫЧКА

234

156

9C

œ

ЛАТИНСКАЯ СТРОЧНАЯ ЛИГАТУРА «OE»

236

158

9E

ž

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «Z» С ГАЛОЧКОЙ

237

159

9F

Ÿ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «Y» С УМЛЯУТОМ

240

160

A0

НЕРАЗРЫВНЫЙ ПРОБЕЛ

241

161

A1

¡

ПЕРЕВЁРНУТЫЙ ВОСКЛИЦАТЕЛЬНЫЙ ЗНАК

242

162

A2

¢

ЗНАК ЦЕНТА

243

163

A3

£

ЗНАК ФУНТА

244

164

A4

¤

СИМВОЛ ВАЛЮТЫ

245

165

A5

¥

ЗНАК ИЕНЫ

246

166

A6

¦

ПРЕРЫВИСТАЯ ВЕРТИКАЛЬНАЯ ЧЕРТА

247

167

A7

§

СИМВОЛ ПАРАГРАФА

250

168

A8

¨

УМЛЯУТ

251

169

A9

©

ЗНАК ОХРАНЫ АВТОРСКОГО ПРАВА

252

170

AA

ª

ПОРЯДКОВЫЙ ИНДИКАТОР (ЖЕНСКИЙ РОД)

253

171

AB

«

ОТКРЫВАЮЩАЯ ЛЕВАЯ КАВЫЧКА «ЁЛОЧКА»

254

172

AC

¬

ЗНАК ОТРИЦАНИЯ

255

173

AD

МЯГКИЙ ПЕРЕНОС

256

174

AE

®

ЗАРЕГИСТРИРОВАННЫЙ ТОВАРНЫЙ ЗНАК

257

175

AF

¯

МАКРОН

260

176

B0

°

ЗНАК ГРАДУСА

261

177

B1

±

ЗНАК ПЛЮС-МИНУС

262

178

B2

²

ЦИФРА ДВА ВВЕРХУ МЕЛКИМ ШРИФТОМ

263

179

B3

³

ЦИФРА ТРИ ВВЕРХУ МЕЛКИМ ШРИФТОМ

264

180

B4

´

ОСТРОЕ УДАРЕНИЕ

265

181

B5

µ

ЗНАК МИКРО

266

182

B6

¶

ЗНАК АБЗАЦА

267

183

B7

·

ТОЧКА В ЦЕНТРЕ

270

184

B8

¸

СЕДИЛЬ

271

185

B9

¹

ЦИФРА ОДИН ВВЕРХУ МЕЛКИМ ШРИФТОМ

272

186

BA

º

ПОРЯДКОВЫЙ ИНДИКАТОР (МУЖСКОЙ РОД)

273

187

BB

»

ЗАКРЫВАЮЩАЯ КАВЫЧКА «ЁЛОЧКА»

274

188

BC

¼

ДРОБЬ ОДНА ЧЕТВЁРТАЯ

275

189

BD

½

ДРОБЬ ОДНА ВТОРАЯ

276

190

BE

¾

ДРОБЬ ТРИ ЧЕТВЁРТЫХ

277

191

BF

¿

ПЕРЕВЁРНУТЫЙ ВОПРОСИТЕЛЬНЫЙ ЗНАК

300

192

C0

À

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ГРАВИСОМ

301

193

C1

Á

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С АКУТОМ

302

194

C2

Â

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» СО ШЛЯПОЙ

303

195

C3

Ã

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ТИЛЬДОЙ

304

196

C4

Ä

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С УМЛЯУТОМ

305

197

C5

Å

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С КРУЖОЧКОМ СВЕРХУ

306

198

C6

Æ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «AE»

307

199

C7

Ç

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «C» С СЕДИЛЬЮ

310

200

C8

È

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С ГРАВИСОМ

311

201

C9

É

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» C АКУТОМ

312

202

CA

Ê

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» СО ШЛЯПОЙ

313

203

CB

Ë

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С УМЛЯУТОМ

314

204

CC

Ì

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С ГРАВИСОМ

315

205

CD

Í

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С АКУТОМ

316

206

CE

Î

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» СО ШЛЯПОЙ

317

207

CF

Ï

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С УМЛЯУТОМ

320

208

D0

Ð

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «ETH»

321

209

D1

Ñ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «N» С ТИЛЬДОЙ

322

210

D2

Ò

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С ГРАВИСОМ

323

211

D3

Ó

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С АКУТОМ

324

212

D4

Ô

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» СО ШЛЯПОЙ

325

213

D5

Õ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С ТИЛЬДОЙ

326

214

D6

Ö

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С УМЛЯУТОМ

327

215

D7

×

ЗНАК УМНОЖЕНИЯ

330

216

D8

Ø

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» СО ШТРИХОМ

331

217

D9

Ù

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С ГРАВИСОМ

332

218

DA

Ú

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С АКУТОМ

333

219

DB

Û

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» СО ШЛЯПОЙ

334

220

DC

Ü

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С УМЛЯУТОМ

335

221

DD

Ý

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «Y» С АКУТОМ

336

222

DE

Þ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «THORN», рус «ТОРН»

337

223

DF

ß

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА ОСТРАЯ «S»

340

224

E0

à

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ГРАВИСОМ

341

225

E1

á

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С АКУТОМ

342

226

E2

â

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» СО ШЛЯПОЙ

343

227

E3

ã

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ТИЛЬДОЙ

344

228

E4

ä

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С УМЛЯУТОМ

345

229

E5

å

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С КРУЖОЧКОМ СВЕРХУ

346

230

E6

æ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «AE»

347

231

E7

ç

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «C» С СЕДИЛЬЮ

350

232

E8

è

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С ГРАВИСОМ

351

233

E9

é

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С АКУТОМ

352

234

EA

ê

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» СО ШЛЯПОЙ

353

235

EB

ë

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С УМЛЯУТОМ

354

236

EC

ì

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С ГРАВИСОМ

355

237

ED

í

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С АКУТОМ

356

238

EE

î

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» СО ШЛЯПОЙ

357

239

EF

ï

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С УМЛЯУТОМ

360

240

F0

ð

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «ETH»

361

241

F1

ñ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «N» С ТИЛЬДОЙ

362

242

F2

ò

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С ГРАВИСОМ

363

243

F3

ó

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С АКУТОМ

364

244

F4

ô

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» СО ШЛЯПОЙ

365

245

F5

õ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С ТИЛЬДОЙ

366

246

F6

ö

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С УМЛЯУТОМ

367

247

F7

÷

ЗНАК ДЕЛЕНИЯ

370

248

F8

ø

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА O СО ШТРИХОМ

371

249

F9

ù

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С ГРАВИСОМ

372

250

FA

ú

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С АКУТОМ

373

251

FB

û

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» СО ШЛЯПОЙ

374

252

FC

ü

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С УМЛЯУТОМ

375

253

FD

ý

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «Y» С АКУТОМ

376

254

FE

þ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «THORN», рус. «ТОРН»

377

255

FF

ÿ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «Y» С УМЛЯУТОМ

## ЗАМЕЧАНИЯ
CP 1252 также известна как Windows-1252.

## СМОТРИТЕ ТАКЖЕ
ascii(7), charsets(7), cp1251(7), iso_8859-1(7), iso_8859-15(7), utf-8(7)