Talk:C0 and C1 control codes

message: ::What are "the 3 not identified by Unicode"?  The Unicode 15.1 version of the Unicode chart of C1 controls and Latin-1 Supplement, and the 1992 version of ISO/IEC 6429, have the same set of C1 controls, except that Unicode has 0x84 as IND and ISO/IEC 6429 doesn't, but, as the note attached to IND says, it was "Deprecated in 1988 and withdrawn in 1992 from ISO/IEC 6429 (1986 and 1991 respectively for ECMA-48)".  I'll attach references in response to the "[citation needed]" for that.
::Otherwise, the table matches both that version of Unicode and that version of ISO/IEC 6429. Guy Harris (talk) 09:56, 29 May 2024 (UTC)
replies: text: 0x80, 0x81, and 0x99. Search below for "Notes Regarding Omissions" Spitzak (talk) 18:52, 29 May 2024 (UTC)
replies: text: OK, those aren't mentioned in ISO/IEC 6429 or ECMA-48, either; the notes in question say they were proposed for ISO 10646, but not accepted. Guy Harris (talk) 19:14, 29 May 2024 (UTC)
thread_title: 2024

message: Control code 0x9C is listed as:
0x9C 	SI 	ST 	String Terminator
However, SI is the abbreviation for:
0x0F 	SI 	Shift In
Is the SI in String Terminator supposed to be ST?
24.234.114.35 21:34, 4 May 2007 (UTC)
replies: text: Fixed, source RFC 1345 says ST. --217.184.142.52 (talk) 19:52, 16 June 2008 (UTC)
thread_title:  Is "String Terminator" abbreviated "SI"? 

message: A few of the entries describe the use of a control key as a shortcut in many Windows programs and CUA X11 programs. For example: "In many programs, a keyboard input of Ctrl-Y is a "redo" command to undo the last Ctrl-Z undo command."
That's true, but the fact that Microsoft, when porting their Office software from the Mac to their own OS, used control keystrokes as a substitute for the missing command key has nothing to do with the meaning of any control character as a C0 control code.
Even if I'm completely wrong, I can't imagine how the undo/redo meanings of ^Z/^Y could be relevant but the clipboard meanings of ^X/^C/^V, the file command meanings of ^N/^O/^S, or the select-all meaning of ^A, the find-related meanings of ^F/^G/^R, etc. --75.36.140.83 07:36, 24 September 2007 (UTC)
replies: text: That stuff appears to have been removed. Guy Harris (talk) 01:08, 30 May 2024 (UTC)
thread_title:  CUA stuff 

message: Do we really need to include the RFC 1345 acronymns?  Aside from some limited usage in a UNIX utility, I haven't come across any evidence that they saw use elsewhere. Caerwine Caer’s whines 22:32, 16 June 2008 (UTC)
replies: text: I'd tend to agree - though deciding whether to remove them would take some investigation Tedickey (talk) 00:43, 17 June 2008 (UTC)
thread_title:  RFC 1345 

message: The comments about backspace, and its linked topic do not mention its use for underlining and bold.  The comment in the table is rather crowded, but rather than a blanket "deprecated", the point should be made that while composition of characters is not generally supported in terminals, the underline/bold generally are Tedickey (talk) 12:19, 19 June 2008 (UTC)
replies: text: agree Tedickey (talk) 18:44, 2 November 2008 (UTC)
thread_title: Backspace

message: Just a friendly reminder.  This article is not about every possible usage of a control character, nor even about usage on every system where 00HEX–1FHEX are control characters.  This is about a specific set control characters, the C0 and C1 sets as defined by ISO/IEC 2022.  Some of those meanings are generalized, so while instances where an application or system further defines their usage are relevant, a use which is totally unrelated to the character as defined in ISO/IEC 2022 belongs in either a separate article or in control character. Caerwine Caer’s whines 02:58, 12 July 2008 (UTC)
thread_title:  This article is not about all control characters 

message: The section C1 (ISO 8859 and Unicode) will become clearer if "if being used in an environment where 8-bit characters are not supported or where these octets are being used instead to add additional graphics characters" is removed. Also, I have passed a '+' outside the parentheses in a table column label.  —Preceding unsigned comment added by 122.169.5.54 (talk) 08:46, 12 January 2010 (UTC)
replies: text: The sentence could be broken up, but removing it would lose the hint for why 7-bit controls are useful.  (Sending 2 bytes instead of 1 is not necessarily a good thing). Tedickey (talk) 09:33, 12 January 2010 (UTC)
thread_title:  unclear lines 

message: Would anyone object were we to add Octal to the table also? We already have decimal and hex. Maratrean (talk) 08:16, 29 October 2011 (UTC)
replies: text: Octal is wonderful, but hasn't its time passed? An extra column would be quite confusing, so why add it? There are probably lots of people who really have no interest in octal, so I think a good reason for adding it would be needed. Johnuniq (talk) 09:10, 29 October 2011 (UTC)
replies: text: I object too. Of course, octal is derived from hex (or decimal), so it would just be a dependent addition (deriveable). Of course one can add: so is decimal - all right. Only, decimal is used directly nowadays (e.g. when entering by keyboard). Someone else could argue: hey letys add UTF-8, UTF-16, and such. So I do object. -DePiep (talk) 22:14, 30 October 2011 (UTC)
thread_title:  Octal 

message: 7F is delete. Which control code operates this? Kg pwn (talk) 22:55, 14 June 2012 (UTC)
replies: text: In Unix, it's sometimes referred to as "Ctrl-?" or "^?"... AnonMoos (talk) 05:25, 15 June 2012 (UTC)
replies: text: Yeah, but is it like... C2... or something  — Preceding unsigned comment added by Kg pwn (talk • contribs) 19:25, 1 August 2012 (UTC)
thread_title: 7F

message: I suggest to restructure this article, as is:
* Principles 
*:(why control codes)
* History 
*:(main dates)
* Interoperability
** Main standards interoperability issues
**: utf-8, windows-1252, etc.
** Main protocols and applications
**: terminal, file text, unix, videotext, etc
* Code assignations
**C0 set
**C1 set
* Example of sequence using control code  — Preceding unsigned comment added by 84.97.14.22 (talk) 17:25, 19 July 2012 (UTC)
thread_title:  Restructuration 

message: http://www.itscj.ipsj.or.jp/ISO-IR/2-6.htm  — Preceding unsigned comment added by 77.198.9.102 (talk) 23:21, 24 July 2012 (UTC)
thread_title: Various standards

message: What this article doesn't really make clear is why C0 and C1 are in Unicode. The use of U+2400 ... U+243F is immediately obvious, and I guess it makes some sense to reserve NUL, TAB, CR and LF.
But what are you supposed to do when you encounter SI? Obviously you aren't meant to switch to a different character set, because if people wanted to encode a character not in Unicode they'd use a PUA character. Maybe it's part of a quoted string of bytes to send to some machine for which SI does make sense? No, because then you'd use the visual representation ␏.
If you find BEL, are you supposed to sound a bell? Of course not. A Unicode text is just that, text, not a string of instructions to do something. Even when displayed, it tends to be scrollable and no bell moment exists. And you wouldn't want to allow text to ring bells anyway. Again, for quoted bytes there's the visual representation.
What about SOH? Again, meaningless in text unless quoted. Most of these control codes are useless as part of text. Insofar as they make sense at all, it's as formatting, which isn't within the Unicode scope, but within things like HTML and CSS, or whatever format your word processor uses. The only reason it makes sense to reserve NUL, TAB, CR and LF is the sheer ubiquity of simple file formats (we call them text files, but they do contain formatting in addition to text) and memory representations of strings that need these.
So the question is, what is the purpose of the C0 and C1 control codes?  — Preceding unsigned comment added by 82.139.81.0 (talk) 18:44, 28 May 2014 (UTC)
replies: text: They're in Unicode to preserve compatibility with ASCII etc. character sets. AnonMoos (talk) 03:36, 7 February 2015 (UTC)

text: C1 comes from ISO-6429 (aka EMCA-48), and ISO-2022 (aka ECMA-35).  It is not so much for compatibility (since the Unicode standard merely lists the names without attempting to describe functionality) as because ISO10646 grew out of the standardization work for the older encodings.  Because Unicode does not describe functionality, it does not standardize C0/C1, merely makes a few assumptions relying upon those other documents as the relevant standards TEDickey (talk) 12:05, 7 February 2015 (UTC)
thread_title:  Purpose 

message: These control codes had names in Unicode 1.0 but these names were later removed. The article should explain when and why.
10646-1 forbids the use of C1 controls, requiring an ESC FE sequence instead. The article should detail when and why this came about and whether or not it is still in force in Unicode.  — Preceding unsigned comment added by 82.139.82.82 (talk) 03:22, 6 September 2015 (UTC)
replies: text: That (ESC Fe) was made obsolete a long time ago, and removed.  See this for example. TEDickey (talk) 12:55, 6 September 2015 (UTC)
thread_title:  Missing information 

message: While it's interesting that Unicode has a subset of C0/C1 codes, deleting most of the content of this topic to replace it by a redirect to a summary paragraph should have some discussion involving the editors who've been maintaining the page. TEDickey (talk) 08:28, 4 August 2016 (UTC)
thread_title:  merge vs deletion 

message: Why are there no C1 control pictures in the UCS? 1234qwer1234qwer4 (talk) 15:19, 2 June 2019 (UTC)
replies: text: For instance this?  Likely disinterest on the part of the committee members who were not involved in software development TEDickey (talk) 16:25, 2 June 2019 (UTC)

text: The Unicode Public General Mail List is probably a better place to ask this question.  Google "c1 control pictures" site:unicode.org to see the discussions that have already taken place. If your question is "Why do C0 controls get pictures but not C1 controls?" then the short answer is compatibility with a legacy encoding that had C0 control pictures. DRMcCreedy (talk) 16:31, 2 June 2019 (UTC)

text: Actually, asking on a mailing list can get mixed results.  If I wanted to know, I'd ask Frank.  Either way, unless someone points to a mail-archive discussing the relevant issues, the best you'd get would be a primary source (unsuitable for topic development). TEDickey (talk) 19:15, 2 June 2019 (UTC)
thread_title:  C1 control pictures 

message: I'd like to add a link to JSON streaming#Record separator-delimited JSON but I am unsure where it would fit best. --RokerHRO (talk) 22:40, 5 March 2021 (UTC)
replies: text: Perhaps in the rightmost column of the table in C0 and C1 control codes#Basic ASCII control codes - there's a big box for FS/GS/RS/US, mentioning various uses of those control characters. Guy Harris (talk) 22:59, 5 March 2021 (UTC)
thread_title:  JSON_streaming#Record_separator-delimited_JSON 

message: This text in C0 codes is certainly anachronistic and arguably simply wrong:
* This large number of codes was desirable at the time, as multi-byte controls would require implementation of a state machine in the terminal, which was very difficult with contemporary electronics and mechanical terminals
State machines per se were neither difficult nor expensive. Shift states were required for existing coding systems such as BAUDOT, and were significantly less complex than the shift registers already needed for sending and receiving serial communication.
A state machine that could interpret VT-100 style escape sequences however would have been prohibitive in 1964.
The prime reason for avoiding shift states (or state machines in general) was to cope better with unreliable transmission, though I don't have a citation for that.
To describe 32 as a "large number" is laughable compared with the hundreds of controls that are implemented as sequences of bytes by typical terminal emulators. 
Bitwise interpretation of ASCII codes                                               	Bitwise interpretation of ASCII codes
Maybe this table might be useful in an article, once we've figured out which article	Maybe this table might be useful in an article, once we've figured out which article
bits                                                                                	meaning
00000001111111                                                                      	no action; ignored
00_____                                                                             	controls
__00___                                                                             	Transmission controls, affecting DCEs
__01___                                                                             	layout controls, driving the motors in printers
__10___                                                                             	Terminal controls, including shift states and device-specific functions
__11___                                                                             	File format markers
01_____                                                                             	Digits & punctuation
1______                                                                             	Letters
_0_____                                                                             	Upper-case
_1_____                                                                             	Lower-case
Although ASCII was designed as a coding system for transmission, unlike previous coding systems it could also function as an encoding for computation, with each printable character fitting into a single machine word ("byte", as we would know it today). This meant that there were needed to be in excess of 64 codes, dictating a minimum of 7 bits.
As only around 80-90 graphic characters were envisaged, it would have seemed foolhardy to "skim" on control codes; clearly at least 16 would be useful.
As there are broadly 4 classes of control codes, and a need for at least 5 transmission controls and 6 format controls, it made logical sense to reserve 4 groups of 8 codes, or 32 in all.
The eventual ASCII standard included codes that deviated from this simple arrangement, but this initial framework is still plain to see.
Martin Kealey (talk) 03:04, 13 August 2022 (UTC)
thread_title:  State machines