Talk:Управляющие коды C0 и C1

Эта статья имеет рейтинг List-class по шкале оценки контента Википедии . Она представляет интерес для следующих WikiProjects :

Вычислительная техника : CompSci Эта статья находится в рамках WikiProject Computing , совместных усилий по улучшению освещения компьютеров , вычислений и информационных технологий в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.Вычисления Википедия:WikiProject Computing Шаблон:WikiProject Computing ??? Данная статья пока не получила рейтинга по шкале важности проекта . Эта статья поддержана WikiProject Computer science . Чем вы можете помочь WikiProject Computer science : редактировать история смотреть удалять Вот некоторые задачи, ожидающие внимания: Запросы статей  : Запрошенные статьи/Прикладные искусства и науки/Информатика, вычисления и Интернет Очистка  : Статьи по информатике, требующие внимания Статьи по информатике, требующие внимания экспертов Копирование  : Вычислительная техника Расширять  : Информатика Информационное поле  : Статьи по информатике без информационных блоков Поддерживать  : Хронология вычислений с 2020 г. по настоящее время Фото  : Найдите фотографии биографий компьютерных ученых (см. Список компьютерных ученых ) Вычислительные статьи, требующие изображений Заглушки  : Заготовки по компьютерным наукам Нессылки  : WikiProject Computer science/Unreferenced BLPs Project-related : Tag all relevant articles in Category:Computer science and sub-categories with {{WikiProject Computer science}}

и если да, могут ли они проверить коды в таблице C1 (особенно 3, не идентифицированные unicode) по ней? Plugwash 02:34, 23 января 2006 (UTC) ECMA 48, европейская версия этого стандарта, доступна в сети. -- Random832 23:32, 1 июля 2007 (UTC) [ ответить ]

Предположительно ECMA-48 идентичен (и доступен бесплатно). Документы ISO (и ANSI) все стоят денег. Tedickey ( talk ) 10:23, 10 марта 2008 (UTC) [ ответить ]

Что такое «3 не идентифицированных Unicode»? Версия Unicode 15.1 таблицы Unicode элементов управления C1 и Latin-1 Supplement, а также версия ISO/IEC 6429 1992 года имеют тот же набор элементов управления C1, за исключением того, что в Unicode 0x84 указан как IND, а в ISO/IEC 6429 — нет, но, как говорится в примечании, приложенном к IND, он был «устаревшим в 1988 году и отозван в 1992 году из ISO/IEC 6429 (соответственно в 1986 и 1991 годах для ECMA-48)». Я прикреплю ссылки в ответ на «[нужна ссылка]» для этого.

В противном случае таблица соответствует как этой версии Unicode, так и этой версии ISO/IEC 6429. Гай Харрис ( обсуждение ) 09:56, 29 мая 2024 (UTC) [ ответить ]

0x80, 0x81 и 0x99. Поиск ниже по запросу "Notes Regarding Omissions" Spitzak ( обсуждение ) 18:52, 29 мая 2024 (UTC) [ ответить ]

Хорошо, они не упоминаются ни в ISO/IEC 6429, ни в ECMA-48; в примечаниях, о которых идет речь, говорится, что они были предложены для ISO 10646, но не приняты. Гай Харрис ( обсуждение ) 19:14, 29 мая 2024 (UTC) [ ответить ]

Управляющий код 0x9C отображается как:

0x9C SI ST Терминатор строки

Однако СИ — это аббревиатура для:

0x0F Сдвиг SI внутрь

Должно ли SI в String Terminator быть ST?

24.234.114.35 21:34, 4 мая 2007 (UTC) [ ответить ]

Исправлено, источник RFC 1345 говорит ST. -- 217.184.142.52 (обсуждение) 19:52, 16 июня 2008 (UTC) [ ответить ]

Коды C1 были включены в серию кодировок ISO-8859-n [...].

Я думаю, это неправильно, если ISO-8859-n означает ISO/IEC 8859. У меня есть доступ только к черновым версиям ISO/IEC 8859, но в них прямо говорится, что использование (кодовых точек C1) выходит за рамки ISO/IEC 8859; это указано в других международных стандартах, например, ISO/IEC 6429. , см. здесь. -- Абдулл 08:10, 8 июня 2007 (UTC) [ ответить ]

есть тонкое, но важное различие между ISO/IEC 8859-1 и набором символов IANA ISO-8859-1. Один из них является неполным стандартом без управляющих кодов, другой добавляет их, чтобы сделать стандарт пригодным для использования. Plugwash 21:42, 1 июля 2007 (UTC) [ ответить ]

Стандарт Unicode утверждает, что кодовые точки 0x00 — 0xFF унаследованы от ISO 8859-1 (а не от какого-либо набора символов IANA), но стандарт Unicode делает ложное заявление; нечерновик ISO/IEC 8859-1:1998 явно заявляет, что все кодовые точки управляющих символов находятся вне его области действия. Я обновил страницу, чтобы указать, где Unicode на самом деле получил кодовые точки 0x00-0x1F, 0x7F и 0x80-0x9F. Гай Харрис ( обсуждение ) 0:53, 29 мая 2024 г.

И Unicode не описывает, что делает большинство из них ; см. раздел 23.1 «Управляющие коды» спецификации Unicode 15.0. Гай Харрис ( обсуждение ) 00:31, 30 мая 2024 (UTC) [ ответить ]

Было бы неплохо получить ссылку на то, откуда Unicode взял кодовые точки. DRMcCreedy ( обсуждение ) 00:45, 30 мая 2024 (UTC) [ ответить ]

"Получил [их] от" в каком смысле? Резервирование 0x00-0x1F и 0x80-0x9F для управляющих символов C0 и C1 соответственно пришло из ISO 2022. Семантика для нескольких управляющих кодов, которым назначена семантика, и псевдонимы имен символов пришли из ISO 6429. Управляющие коды C0 и C1 § Unicode используют раздел 23.1 "Управляющие коды" спецификации Unicode в качестве ссылки. Гай Харрис ( обсуждение ) 01:06, 30 мая 2024 (UTC) [ ответ ]

Областью действия ISO 8859, по сути, является определение конкретных графических наборов символов для использования с уровнем 1 ISO 4873. ISO 4873 , в свою очередь, является подмножеством ISO 2022. Следовательно, концепция элементов управления C0 и C1 определяется стандартами, которым должен соответствовать ISO 8859. Примечательно, что сам Unicode не соответствует ни одному из этих стандартов.

Актуальность ISO 8859 заключается не в том, что сам ISO 8859 определяет что-либо, связанное с управляющими кодами (как вы правильно заметили, он этого не делает), а в том, что Unicode закончил с управляющими кодами C0 и C1 (несмотря на то, что сам по себе не основан на ISO-2022) из-за того, что изначально предусматривал, что существующие данные, соответствующие ISO 8859-1 (которые обычно используют некоторый набор управляющих кодов, хотя они все равно соответствовали бы ISO 8859-1, если бы не использовали), должны быть напрямую сопоставлены с U+0000–U+00FF. Так уж получилось, что Unicode продолжал использоваться с подмножеством набора C0 из ISO 6429 (т. е. с использованием LF или CR + LF , в отличие от собственного LSEP Unicode , в качестве соглашения о конце строки), и подобные алгоритму переноса строк Unicode отражают эту устоявшуюся практику.

Безусловно, контрольные коды не возникли из-за ISO 8859, и попытки найти информацию о них в самом ISO 8859 не увенчаются успехом.

-- HarJIT ( обсуждение ) 15:26, 1 июня 2024 г. (UTC) [ ответ ]

В правке от 30 мая 2024 г. удалена формулировка, которая, по моему мнению, нуждалась в ссылке («Unicode наследует кодовые точки 0x00–0x1F и 0x80–0x9F из ISO/IEC 6429:1992»), поэтому мой комментарий/запрос теперь неактуален. DRMcCreedy ( обсуждение ) 15:52, 1 июня 2024 (UTC) [ ответ ]

Несколько записей описывают использование клавиши управления в качестве сочетания клавиш во многих программах Windows и программах CUA X11. Например: «Во многих программах ввод с клавиатуры Ctrl-Y является командой «повторить» для отмены последней команды отмены Ctrl-Z».

Это правда, но тот факт, что Microsoft при портировании своего программного обеспечения Office с Mac на свою собственную ОС использовала нажатия клавиш Control в качестве замены отсутствующей клавиши Command, не имеет ничего общего со значением любого управляющего символа как управляющего кода C0.

Даже если я полностью не прав, я не могу себе представить, как значения отмены/возврата ^Z/^Y могут быть релевантны, если не считать значений буфера обмена ^X/^C/^V, значений команд файлов ^N/^O/^S или значения выделения всего ^A, значений поиска ^F/^G/^R и т. д. --75.36.140.83 07:36, 24 сентября 2007 (UTC) [ ответить ]

Похоже, этот материал был удален. Гай Харрис ( обсуждение ) 01:08, 30 мая 2024 (UTC) [ ответить ]

Действительно ли нам нужно включать аббревиатуры RFC 1345? Помимо ограниченного использования в утилите UNIX, я не нашел никаких доказательств того, что они использовались где-то еще. Caerwine Caer’s whines 22:32, 16 июня 2008 (UTC) [ ответить ]

Я склонен согласиться, хотя решение об их удалении потребует некоторого расследования. Тедики ( обсуждение ) 00:43, 17 июня 2008 (UTC) [ ответить ]

Комментарии о backspace и связанная с ним тема не упоминают его использование для подчеркивания и жирного шрифта. Комментарий в таблице довольно переполнен, но вместо того, чтобы сказать "устарело", следует отметить, что хотя композиция символов обычно не поддерживается в терминалах, подчеркивание/жирный шрифт обычно являются Tedickey ( обсуждение ) 12:19, 19 июня 2008 (UTC) [ ответ ]

Я думаю, что описание Backspace неверное. Этот символ не имеет разных применений для ввода и вывода (как, например, символы CR или ESC): он всегда перемещает курсор влево, поэтому фраза «Чтобы обеспечить устранение неоднозначности между двумя потенциальными применениями Backspace» не имеет смысла.

Более точное описание может быть выполнено в том же стиле символов CR или ESC, например:

Переместить курсор на одну позицию влево. Клавиша Backspace на клавиатуре отправит этот символ, который обычно используется для удаления символа слева от курсора; для этого используется последовательность из трех символов BS SPACE BS (0x08 0x20 0x08). В ранних компьютерных технологиях, где символ, однажды напечатанный, не мог быть стерт, клавиша Backspace иногда использовалась для создания комбинаций из двух символов, например, à, которую можно было получить с помощью последовательности из трех символов a BS ` (0x61 0x08 0x60), метода печати подчеркивания или надчеркивания символов, объединяющего _ или - с любым символом, или стандартного метода в языке программирования APL для создания новых операторов, объединяющих два существующих оператора, например, / BS - Aacini ( обсуждение ) 05:35, 2 ноября 2008 (UTC) [ ответить ]

согласен Тедики ( обсуждение ) 18:44, 2 ноября 2008 (UTC) [ ответить ]

Просто дружеское напоминание. Эта статья не обо всех возможных вариантах использования управляющего символа и даже не об использовании в каждой системе, где 00 _HEX –1F _HEX являются управляющими символами. Речь идет о конкретном наборе управляющих символов, наборах C0 и C1, определенных в ISO/IEC 2022. Некоторые из этих значений обобщены, поэтому, хотя случаи, когда приложение или система дополнительно определяет их использование, являются релевантными, использование, которое совершенно не связано с символом, определенным в ISO/IEC 2022, следует либо в отдельной статье, либо в разделе управляющий символ . Caerwine Caer’s whines 02:58, 12 июля 2008 (UTC) [ ответить ]

Раздел C1 (ISO 8859 и Unicode) станет понятнее, если «при использовании в среде, где 8-битные символы не поддерживаются или где эти октеты используются вместо этого для добавления дополнительных графических символов» будет удалено. Кроме того, я передал '+' за скобками в заголовке столбца таблицы. — Предыдущий комментарий без знака добавлен 122.169.5.54 (обсуждение) 08:46, 12 января 2010 (UTC) [ ответить ]

Предложение можно было бы разбить, но если его удалить, то будет потерян намек на то, почему 7-битные элементы управления полезны. (Отправка 2 байтов вместо 1 не обязательно хорошая вещь). Tedickey ( talk ) 09:33, 12 января 2010 (UTC) [ ответить ]

Я переименовал заголовок «C1 (ISO 8859 и Unicode)» в «C1 set», поскольку C1 не определен ни в ISO 8859, ни в Unicode. C0 и C1 могут использоваться в тексте ISO 8859 или Unicode, но они не определяют C0 или C1. — Предыдущий неподписанный комментарий добавлен 88.112.175.168 (обсуждение) 10:06, 27 сентября 2011 (UTC) [ ответить ]

Итак, что такое «C0 Controls and Basic Latin» и «C1 Controls and Latin-1 Supplement» в стандарте Unicode?

1. http://www.unicode.org/charts/PDF/U0000.pdf
2. http://www.unicode.org/charts/PDF/U0080.pdf — Предыдущий неподписанный комментарий добавлен 84.97.14.22 ( обсуждение ) 06:27, 19 июля 2012 (UTC)[ отвечать ]

ECMA-35 и ECMA-48 определяют использование C0/C1 для ISO-8859-1. Без документа, подобного документу для Unicode (или UTF-8), все упомянутые вами документы показывают изображения кодов, которые отображаются из ISO-8859-1; поведение C0/C1 не было указано. Надежный источник по этому вопросу не оставил бы возможности угадывать, что может иметься в виду TEDickey ( talk ) 08:16, 19 июля 2012 (UTC) [ ответить ]

Я просто хочу сказать, что стандарт Unicode

1. распознать эти значения как управляющий символ,
2. дает их диапазон и псевдонимы
3. как символ, неявно приписывает им последовательность байтов в зависимости от используемой UTF.

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

Кроме того, можно установить ссылку на управляющие символы Unicode .

В стандарте Unicode версии 6.1 на странице 23 говорится: «Базовый элемент управления типом — это «Использование, определяемое протоколами или стандартами за пределами стандарта Unicode», и классифицирует их как категорию Cc со статусом абстрактного символа».

И они добавляют «Управляющие коды. Шестьдесят пять кодовых точек (U+0000..U+001F и U+007F..U+009F) определены специально как управляющие коды для совместимости с управляющими кодами C0 и C1 фреймворка ISO/IEC 2022. Некоторым из этих управляющих кодов даны специальные интерпретации стандартом Unicode. (См. раздел 16.1, Управляющие коды.)»

§16.1 находится на странице 544 для C0.

На странице 545 дополнительная семантика поясняется как минимум для одиннадцати из них «Спецификация семантики управляющего кода» — Предшествующий неподписанный комментарий добавлен 84.97.14.22 ( обсуждение ) 11:18, 19 июля 2012 (UTC)[ отвечать ]

Но в этом-то и суть: в параграфе, как он написан, говорится, что Unicode "предоставляет" эти коды, но в контексте (и там нет никаких пояснений) указывается, что Unicode не дает определения их поведения. Коды C1 без перевода были бы незаконны в кодировке UTF-8 (потому что значения в 128-159 являются байтами продолжения). Без пояснений параграф вводит в заблуждение. Слово "предоставляет" неуместно в этом контексте - "назначает" было бы более идиоматичным и соответствовало бы источникам, которые вы указываете TEDickey ( talk ) 22:32, 19 июля 2012 (UTC) [ ответить ]

C1 не является незаконным в UTF-8. U+0085 (NEL / Следующая строка) кодируется как C2 85 в UTF8. Я нашел этот документ, который предполагает, что:

Я не знаю, правда ли это утверждение. Но я протестировал несколько эмуляторов терминала, и GNU Screen и Mosh были единственными эмуляторами терминала, которые поддерживали C2 85 как символ новой строки. -- Hirsutism ( обсуждение ) 21:07, 11 октября 2012 (UTC) [ ответ ]

Screen не является эмулятором терминала, как и mosh — это приложения, которые используют терминалы и полагаются на них для предоставления многих функций, связанных с эмулятором терминала. TEDickey ( обсуждение ) 21:31, 11 октября 2012 (UTC) [ ответить ]

Да, Mosh делает эмуляцию терминала. Смотрите здесь: "... возможность построить чистый эмулятор терминала UTF-8 с нуля ...". Mosh значительно переосмысливает управляющие символы и управляющие последовательности, прежде чем отправить их в конечный эмулятор терминала. - Hirsutism ( обсуждение ) 22:36, 11 октября 2012 (UTC) [ ответить ]

Я знаю мнение его разработчика(ов), но поскольку он полагается на терминал (и ncurses) для функциональности, он как screen - переводчик, который не является полным эмулятором терминала. Вы вряд ли найдете авторитетный источник, который согласится с этим мнением. TEDickey ( talk ) 22:56, 11 октября 2012 (UTC) [ ответить ]

Мы застряли в косвенных вопросах. Точное определение термина «эмулятор терминала» не имеет значения для этой страницы Википедии. Здесь важно следующее: Putty + Mosh распознают NEL (закодированный как C2 85) как символ новой строки. Даже это эмпирическое доказательство — косвенные вопросы... основная дискуссия о том, полностью ли спецификация Unicode распознает NEL (или другие символы C1). -- Hirsutism ( обсуждение ) 15:28, 12 октября 2012 (UTC) [ ответ ]

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

Начиная с VT100 (который широко использует C1)...

что неверно. Быстро просматривая, я вижу другие ошибки. Если вы просто утверждаете, что можете найти кого-то, кто согласится с вашей точкой зрения, это, конечно, легко сделать (Google — ваш друг). TEDickey ( talk ) 23:03, 12 октября 2012 (UTC) [ ответить ]

Кто-нибудь будет возражать, если мы добавим в таблицу еще и восьмеричную систему? У нас уже есть десятичная и шестнадцатеричная. Maratrean ( talk ) 08:16, 29 октября 2011 (UTC) [ ответить ]

Octal замечателен, но разве его время не прошло? Дополнительный столбец будет довольно запутанным, так зачем его добавлять? Вероятно, есть много людей, которым восьмеричная система на самом деле неинтересна, поэтому я думаю, что нужна веская причина для ее добавления. Johnuniq ( talk ) 09:10, 29 октября 2011 (UTC) [ ответить ]

Я тоже возражаю. Конечно, восьмеричная система выведена из шестнадцатеричной (или десятичной), так что это будет просто зависимое сложение (выводимое). Конечно, можно добавить: так же как и десятичная - хорошо. Только десятичная система в настоящее время используется напрямую (например, при вводе с клавиатуры). Кто-то другой может возразить: эй, пусть добавят UTF-8, UTF-16 и т. д. Так что я возражаю. - DePiep ( talk ) 22:14, 30 октября 2011 (UTC) [ ответить ]

Столбец «C» содержит много пропущенных записей. В языке «C» обычно используют восьмеричные управляющие последовательности для выражения и ввода этих пропущенных записей. Почему бы не заполнить пропущенные записи в столбце «C» восьмеричными числами — например, «\003» — это решает OP, завершает столбец и предоставляет ссылку для программистов, желающих использовать обсуждаемые управляющие коды. — Предыдущий комментарий без знака добавлен 92.21.236.161 (обсуждение) 00:20, 5 февраля 2015 (UTC) [ ответить ]

7F — удалить. Какой код управления этим управляет? Kg pwn (обсуждение) 22:55, 14 июня 2012 (UTC) [ ответить ]

В Unix это иногда называют "Ctrl-?" или "^?"... AnonMoos ( обсуждение ) 05:25, 15 июня 2012 (UTC) [ ответ ]

Да, но это как... C2... или что-то в этом роде — Предыдущий неподписанный комментарий добавлен Kg pwn (обсуждение • вклад ) 19:25, 1 августа 2012 (UTC)[ отвечать ]

Ни то, ни другое - ECMA-35 / ISO-2022 делают SPACE и DELETE особыми случаями (не управляющими символами и не членами C0/C1). Кстати, позиции, используемые для тех, что находятся в диапазоне 128-255, являются печатными символами. TEDickey ( talk ) 23:55, 1 августа 2012 (UTC) [ ответить ]

Предлагаю реструктурировать статью следующим образом:

• Принципы

  (почему контрольные коды)

• История

  (основные даты)

• Взаимодействие
  • Основные проблемы совместимости стандартов

    utf-8, windows-1252 и т.д.

  • Основные протоколы и приложения

    терминал, текстовый файл, unix, видеотекст и т. д.

• Кодовые назначения
  • С0 набор
  • С1 набор
• Пример последовательности с использованием управляющего кода — Предшествующий неподписанный комментарий, добавленный 84.97.14.22 ( обсуждение ) 17:25, 19 июля 2012 (UTC)[ отвечать ]

http://www.itscj.ipsj.or.jp/ISO-IR/2-6.htm — Предыдущий неподписанный комментарий добавлен 77.198.9.102 (обсуждение) 23:21, 24 июля 2012 (UTC) [ ответить ]

Все эти ссылки являются циклическими или указывают на статьи об использовании сочетаний клавиш в Windows, что не имеет ничего общего с управляющими кодами. Я рекомендую отменить их добавление. Spitzak ( talk ) 05:20, 21 сентября 2013 (UTC) [ ответить ]

Я частично согласен с вашим наблюдением, но не с вашим выводом.

Я намеренно добавил ссылки, поскольку семантически существует разница между управляющим символом, заданным в нотации ^X (определяет комбинацию клавиш с Ctrl, а не конкретную функцию — связанные функции зависят от операционной системы и приложения), управляющим символом, заданным в нотации \x (специфическое форматирование для некоторых языков программирования), именованными управляющими символами, различающимися по функции (перевод строки, табуляция, звонок, нуль) или именованными управляющими символами, различающимися по коду (NUL, ETX и т. д.) в определенных стандартах, таких как ASCII и т. д.

Хотя это и не является циклическим, в настоящее время некоторые ссылки имеют одну и ту же цель (которая часто не отражает правильно указанную выше семантику), но это проблема неоптимального целевого связывания в перенаправлениях, а не проблема добавления локальных ссылок к терминам как есть. Нам придется перенацелить некоторые перенаправления и реструктурировать некоторые статьи, чтобы создать семантически более правильные цели ссылок, но это не произойдет в одночасье. Однако мы создадим осведомленность об этой «неравномерности», только начав включать ссылки — со временем это создаст импульс, который поможет сместить цели, чтобы они стали более семантически правильными. Если мы не добавим ссылки, ни семантические различия, ни структура не станут очевидны большинству пользователей, поэтому изменения в этой области будут происходить только случайным образом и без четкого направления, а не систематически следуя некоторой общей структуре.

-- Matthiaspaul ( обсуждение ) 11:12, 21 сентября 2013 (UTC) [ ответить ]

Обозначение ^X на самом деле указывает на символ со значением ASCII 'X', сложенный с помощью xor'а 0x40. Хотя часто это одно и то же, это не символ для последовательности клавиш. Например, ^@ означает символ, который, скорее всего, будет получен при нажатии ctrl+space. В любом случае, я думаю, что ссылки, ведущие к обсуждению сочетаний клавиш Windows, неверны, эти сочетания клавиш обрабатываются напрямую с клавиатуры, и ни в одной точке не используется управляющий код C0/C1. Spitzak ( talk ) 01:52, 29 мая 2014 (UTC) [ reply ]

Что эта статья на самом деле не проясняет, так это то, почему C0 и C1 находятся в Unicode. Использование U+2400 ... U+243F сразу очевидно, и я думаю, что имеет смысл зарезервировать NUL, TAB, CR и LF.

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

Если вы найдете BEL, вы должны звонить в колокол? Конечно, нет. Текст Unicode — это просто текст, а не строка инструкций что-то сделать. Даже при отображении он, как правило, прокручивается, и никакого момента звонка не существует. И вы бы не хотели, чтобы текст звонил в колокола в любом случае. Опять же, для цитируемых байтов есть визуальное представление.

А как насчет SOH? Опять же, бессмысленно в тексте, если не кавычки. Большинство этих управляющих кодов бесполезны как часть текста. Если они вообще имеют смысл, то только в качестве форматирования, которое не входит в область действия Unicode, а входит в такие вещи, как HTML и CSS, или любой другой формат, который использует ваш текстовый процессор. Единственная причина, по которой имеет смысл резервировать NUL, TAB, CR и LF, — это явная повсеместность простых форматов файлов (мы называем их текстовыми файлами, но они содержат форматирование в дополнение к тексту) и представления строк в памяти, которым это нужно.

Итак, вопрос в том, каково назначение управляющих кодов C0 и C1? — Предыдущий неподписанный комментарий добавлен 82.139.81.0 ( обсуждение ) 18:44, 28 мая 2014 (UTC) [ ответить ]

Они в Unicode для сохранения совместимости с наборами символов ASCII и т. д. AnonMoos ( обсуждение ) 03:36, 7 февраля 2015 (UTC) [ ответить ]

C1 происходит от ISO-6429 (он же EMCA-48) и ISO-2022 (он же ECMA-35). Это не столько для совместимости (так как стандарт Unicode просто перечисляет имена, не пытаясь описать функциональность), сколько потому, что ISO10646 вырос из работы по стандартизации старых кодировок. Поскольку Unicode не описывает функциональность, он не стандартизирует C0/C1, а просто делает несколько предположений, полагаясь на эти другие документы как на соответствующие стандарты TEDickey ( talk ) 12:05, 7 февраля 2015 (UTC) [ ответить ]

Указанные источники обсуждают smtp, а не ISO 10646 как таковой:

Ниже представлен проект RFC, обновляющего SMTP с целью разрешить и поощрить использование ISO 10646 (теперь, конечно, DIS).

и без более подходящего дополнительного источника утверждения не соответствуют источнику TEDickey ( talk ) 23:55, 7 апреля 2015 (UTC) [ ответить ]

Если вы читаете этот абзац:

В интернет-сообщениях используется метод динамического уплотнения (метод уплотнения 5), начальное состояние которого G=32, P=32, R=32, при этом каждый октет указывает значение C. (В переводе на нормальный английский это предложение означает: «Текст находится в 8-битной Latin-1, пока мы не дойдем до первого HOP, если таковой имеется!») Переходы к другим наборам символов, представленным строками и, в некоторых случаях, плоскостями, выполняются с помощью последовательности, которая начинается с кода HOP («High Octet Preset») (десятичное 129). SGCI («Single Graphic Character Introducer») не используется (т. е. мы используем «уровень 1» метода 5).

Мне совершенно ясно, что здесь обсуждается, как проект ISO 10646 применяется к SMTP. Он не вводит HOP или SGCI сам по себе, он извлекает их из проекта. Было бы здорово, если бы кто-то мог найти старые проекты ISO 10646, и мы могли бы процитировать их вместо этого, но даже при отсутствии копий этих старых проектов я не думаю, что есть какая-либо другая правдоподобная интерпретация этого параграфа. SJK ( talk ) 12:23, 9 апреля 2015 (UTC) [ ответить ]

Без указанного проекта вы не сможете отличить интерпретацию, которую вы хотите сделать, от столь же правдоподобной, которая относится к некоторой функции ISO-2022, которая прокомментирована как не входящая в ISO 10646. Таким образом, ваш комментарий по теме представляет собой оригинальное исследование . Как я уже сказал, вам нужен дополнительный источник для предоставления информации, а не интерпретация TEDickey ( talk ) 00:43, 10 апреля 2015 (UTC) [ ответить ]

Пожалуйста, ознакомьтесь с работой Кена Уистлера «Формальные псевдонимы имен для управляющих символов», L2/11-281, Консорциум Unicode, 20 июля 2011 г., которая объясняет ситуацию гораздо лучше, чем моя предыдущая ссылка:

Заметки относительно пропусковЯ намеренно опустил три названия кодов управления и их сокращения.которые встречаются в одном (устаревшем) RFC, но которые являются артефактом раннегонеодобренные проекты 10646. А именно:0080 ЗАПОЛНЯЮЩИЙ СИМВОЛ (PAD)0081 ПРЕДУСТАНОВКА ВЫСОКОГО ОКТЕТА (HOP)0099 ОДИН ГРАФИЧЕСКИЙ ПЕРСОНАЖ ВВОДИТ (SGC)Эти 3 были предложены (по спецификации) в ранних проектах 10646, для того, что сталонеудачное архитектурное направление для 10646. Они были бы полностью забытытеперь за исключением постоянного (и пагубного) RFC, который перечисляет их безуказывая на их провальный статус. Никто никогда не реализовал их, поэтому ониявляются не более чем курьезами кодировки символов.

Итак, эта ссылка подтверждает правильность моего вывода. Я заменю свою предыдущую ссылку этой. SJK ( talk ) 10:52, 10 апреля 2015 (UTC) [ ответить ]

Эти управляющие коды имели имена в Unicode 1.0, но эти имена были позже удалены. Статья должна объяснить, когда и почему.

10646-1 запрещает использование элементов управления C1, требуя вместо этого последовательность ESC FE. Статья должна подробно описывать, когда и почему это произошло, и действует ли это до сих пор в Unicode. — Предыдущий неподписанный комментарий добавлен 82.139.82.82 ( обсуждение ) 03:22, 6 сентября 2015 (UTC) [ ответить ]

Это (ESC Fe) давно устарело и удалено. Посмотрите, например, это. TEDickey ( talk ) 12:55, 6 сентября 2015 (UTC) [ ответить ]

Хотя интересно, что в Unicode есть подмножество кодов C0/C1, удаление большей части содержимого этой темы для замены его перенаправлением на абзац с резюме должно вызвать обсуждение с участием редакторов, которые поддерживают страницу. TEDickey ( обсуждение ) 08:28, 4 августа 2016 (UTC) [ ответить ]

Почему в UCS нет контрольных изображений C1? 1234qwer1234qwer4 ( обсуждение ) 15:19, 2 июня 2019 (UTC) [ ответ ]

Например, это? Вероятное отсутствие интереса со стороны членов комитета, которые не были вовлечены в разработку программного обеспечения TEDickey ( обсуждение ) 16:25, 2 июня 2019 (UTC) [ ответить ]

Unicode Public General Mail List, вероятно, лучшее место, чтобы задать этот вопрос. Погуглите, "c1 control pictures" site:unicode.orgчтобы увидеть обсуждения, которые уже состоялись. Если ваш вопрос: «Почему элементы управления C0 получают изображения, а элементы управления C1 — нет?», то краткий ответ — совместимость с устаревшей кодировкой, в которой были элементы управления C0. DRMcCreedy ( talk ) 16:31, 2 июня 2019 (UTC) [ reply ]

На самом деле, спрашивать в списке рассылки может быть неоднозначно. Если бы я хотел знать, я бы спросил Фрэнка. В любом случае, если кто-то не укажет на почтовый архив, где обсуждаются соответствующие вопросы, лучшее, что вы получите, это первоисточник (непригодный для развития темы). TEDickey ( talk ) 19:15, 2 июня 2019 (UTC) [ ответить ]

Я хотел бы увидеть статью, объясняющую происхождение терминов «C0» и «C1» и отвечающую на все эти вопросы. -- RokerHRO ( обсуждение ) 16:25, 14 апреля 2020 (UTC) [ ответ ]

См. коды управления C0 и C1 § Элементы управления C1 :

В 1973 году ECMA-35 и ISO 2022 ^[1] попытались определить метод, чтобы 8-битный «расширенный ASCII» код мог быть преобразован в соответствующий 7-битный код, и наоборот . ^[2] В 7-битной среде Shift Out ( SO ) изменил бы значение 96 байтов 0x20 через 0x7F ^{[a] [4]} (т. е. всех, кроме управляющих кодов C0), чтобы они стали символами, которые 8-битная среда напечатала бы, если бы использовала тот же код с установленным старшим битом. Это означало, что диапазон 0x80 через 0x9F не мог быть напечатан в 7-битной среде, ^[2] поэтому было решено, что никакой альтернативный набор символов не может их использовать, и что эти коды должны быть дополнительными управляющими кодами, которые стали известны как управляющие коды C1 . Чтобы разрешить 7-битной среде использовать эти новые элементы управления, последовательности до должны были считаться эквивалентными. ^[2] Более поздние стандарты ISO 8859 отказались от поддержки 7-битных кодов, но сохранили этот диапазон управляющих символов.ESC @ESC _

Существуют только C0 и C1, но ECMA-35/ISO 2022 допускает выбор четырех графических кодовых наборов, от G0 до G3, причем G0 по умолчанию является графическими символами ASCII. -- 03:05, 29 мая 2024 г. Гай Харрис

Я хотел бы добавить ссылку на потоковую передачу JSON#Record Separated-delimited JSON , но не уверен, где она лучше всего подойдет. -- RokerHRO ( обсуждение ) 22:40, 5 марта 2021 (UTC) [ ответить ]

Возможно, в самом правом столбце таблицы в кодах управления C0 и C1#Базовые коды управления ASCII — есть большой блок для FS/GS/RS/US, в котором упоминаются различные варианты использования этих управляющих символов. Гай Харрис ( обсуждение ) 22:59, 5 марта 2021 (UTC) [ ответить ]

Этот текст в кодах C0, безусловно, анахроничен и, возможно, просто неверен:

• Такое большое количество кодов было желательно в то время, поскольку многобайтовые элементы управления потребовали бы реализации конечного автомата в терминале, что было очень сложно с использованием современной электроники и механических терминалов.

Конечные автоматы сами по себе не были ни сложными, ни дорогими. Состояния сдвига требовались для существующих систем кодирования, таких как BAUDOT, и были значительно менее сложными, чем регистры сдвига, уже необходимые для отправки и получения последовательной связи.

Однако конечный автомат, который мог бы интерпретировать управляющие последовательности в стиле VT-100, был бы невозможен в 1964 году.

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

Называть 32 «большим числом» просто смешно по сравнению с сотнями элементов управления, которые реализованы в виде последовательностей байтов в типичных эмуляторах терминала.

Хотя ASCII был разработан как система кодирования для передачи , в отличие от предыдущих систем кодирования он также мог функционировать как кодирование для вычислений , при этом каждый печатаемый символ укладывался в одно машинное слово («байт», как мы знаем его сегодня). Это означало, что требовалось более 64 кодов, что диктовало минимум 7 бит.

Поскольку предполагалось использовать всего около 80–90 графических символов, казалось бы безрассудным «ограничиваться» управляющими кодами; очевидно, что по крайней мере 16 были бы полезны.

Поскольку существует 4 класса кодов управления, а также требуется не менее 5 элементов управления передачей и 6 элементов управления форматом, было бы логично зарезервировать 4 группы по 8 кодов, или всего 32.

Окончательный стандарт ASCII включал коды, которые отклонялись от этой простой схемы, но эта первоначальная структура все еще очевидна.

Мартин Кили ( обсуждение ) 03:04, 13 августа 2022 (UTC) [ ответить ]

Это пробельный символ. На компьютерах это обычный символ, как a или z.

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

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

Пожалуйста, не распространяйте эту информацию и оставьте ее тем, кто распечатывает информацию из Интернета и пользуется iУстройствами.

-- 2A02:3035:610:58B8:24DA:BC5F:806D:B752 (обсуждение) 21:08, 28 мая 2024 (UTC) [ ответить ]

Полагаю, вы имеете в виду запись в первой таблице, где SP описана как «[Перемещение] вправо на одну позицию символа».

Многие пожилые люди помнят печатающие терминалы, в которых символ пробела перемещал печатающую головку на одну позицию вправо и ничего не менял на бумаге. Это было большинство терминалов, когда разрабатывался ASCII. Страница 6 спецификации ASCII 1963 года говорит о символе в позиции 0x20 как о «разделителе слов [пробел, обычно непечатаемый]». :Однако на странице 11 он упоминается как графический символ.

Версия 1968 года также описывает пробел как «обычно непечатаемый», но помещает его в раздел «Графические символы», а не в раздел «Управляющие символы». Там говорится, что это

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

но не уточняет, каким образом это «применимо ... к устройствам отображения».

Терминалы отображения обычно стирали символ в текущей позиции отображения и перемещались на одну позицию вправо, когда получали символ пробела, и большинство, если не все программы эмуляторов терминала эмулируют терминалы такого рода. ( Однако Datapoint 3300 , похоже, поддерживал как поведение «перезаписи пробела», так и поведение без «перезаписи пробела», возможно, потому, что он был предназначен для замены телетайпов ASCII, таких как Teletype Model 33 , поэтому, хотя он, вероятно, не поддерживал полную перепечатку, вы, по крайней мере, могли перезаписать пробел другим символом. ^[1] )

Правильным решением, вероятно, было бы расширить «Переместиться вправо на одну позицию символа» до чего-то вроде «Переместиться вправо на одну позицию символа; на дисплейных терминалах это обычно стирает символ в текущей позиции символа». Гай Харрис ( обсуждение ) 23:27, 28 мая 2024 (UTC) [ ответить ]