![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||
|
To represent large character sets, ISO 2022 builds on ISO 646's property that 1 byte can define 94 graphic (printable) characters (in addition to space and 33 control characters).
So the control characters are always available no matter which character table is currently shifted in? -- Abdull 20:17, 7 June 2007 (UTC)
The comment appears to indicate that ISO-2022 is not useful except with 7-bit displays. Since both GL and GR are mapped, it applies to 8-bit and 7-bit displays (with the latter requiring extra effort on the part of the application developer). Tedickey ( talk) 22:15, 25 July 2009 (UTC)
The comment regarding disadvantages is also misleading, since (applying to cut/paste - apparently), it ignores the actual terminal implementations which may pass selections around as UTF-8. Tedickey ( talk) 22:18, 25 July 2009 (UTC)
"Display" is the wrong word; "system" is slightly better. IIRC, the typical PC console driver is 9-bit (512 glyphs can be used at a time, or so) plus 8 bits of colour (4 background, 4 foreground) plus a few bits for bold/underline/blink, plus some more stuff I've forgotten.
The article has many problems, such as the introduction saying that it's a 7-bit encoding (helpfully contradicting the rest of the article!), but not as many problems as ISO 2022. ⇌ Elektron 04:13, 29 January 2010 (UTC)
Reference 4, "DICOM ISO 2022 variation" is an incorrect url. It points to a simple test email message in a sourceforge project which does not appear to have any relation to DICOM. I've searched to try to find the correct link, with no success. I'd be very interested in the correct target of this link if it could be found. Dlmason ( talk) 12:25, 7 April 2012 (UTC)
Missing an history section. 84.97.14.22 ( talk) 19:01, 19 July 2012 (UTC)
I've removed an old neutrality tag from this page that appears to have no active discussion per the instructions at Template:POV:
Since there's no evidence of ongoing discussion, I'm removing the tag for now. If discussion is continuing and I've failed to see it, however, please feel free to restore the template and continue to address the issues. Thanks to everybody working on this one! -- Khazar2 ( talk) 04:26, 27 June 2013 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on ISO/IEC 2022. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 02:27, 8 April 2017 (UTC)
The article currently says "UTF-1, the multi-byte Unicode transformation format compatible with ISO/IEC 2022". I don't think it's "compatible" in the way the statement implies because while the standard allows multi-byte encodings, it requires the elements to have constant-length (e.g. all elements have to be 3 bytes) while UTF-1 is variable-length. UTF-1 is registered as a "Coding system different from ISO 2022" (see: https://www.itscj.ipsj.or.jp/itscj_english/iso-ir/ISO-IR.pdf), just like UTF-8 is. Escape sequences are provided for both UTF-8 and UTF-1, but using the "designate other coding system" method. If UTF-8 is not "compatible" then neither is UTF-1. -- 157.52.11.237 ( talk) 14:24, 24 October 2017 (UTC)
"Because of its escape sequences, it is possible to construct attack byte sequences that round-trip from ISO/IEC 2022 to Unicode and back."
This statement is incredibly scary and also confusing, which is not a good combination. What kinds of attacks? Why do escape sequences make them possible? What other encodings is this in contrast to (UTF-8?)? Why is round-tripping relevant?
There is a link, but there's not any more detail on the destination page, only discussion about popularity of encodings and discussion around measuring if they are in use in a specific piece of software.
Can someone please clarify this part of the article?
01:15, 31 July 2018 (UTC) — Preceding unsigned comment added by 178.197.231.171 ( talk)
The introduction in the article is far to technical to be an introduction, and misses the things that ought to be in an introduction. Eg is UTF-8 replacing the need for ISO2022? Is it expected that ISO2022 encodings will be phased out? When was the standard written? There are too many standards being referred to without an explanation of what they are (the reader of an article should not have to refer to lots of other articles to understand what they are reading); eg rather than just referring to a standard, use a sentence to describe what it is, followed by the standard's name in parenthesis). FreeFlow99 ( talk) 15:42, 27 April 2022 (UTC)
The present Encodings and conformance paragraph, whose current phrasing was introduced here, is kind of messy, because of how it speaks about letters "absent in"[sic] the ISO Basic Latin alphabet. In truth, the ISO Basic Latin alphabet too is one of the short alphabets (writing systems) trivially representable with 256-character encodings. The present paragraph tries to simultaneously talk about how there's this class of small writing systems to be contrasted with larger ones (that really require ISO 2022 or similarly expansive solutions), but then it also somewhat messily tries to convey or imply that these small writing systems already require extended ASCII because their charset exceeds what's in plain US-ASCII. That's trying to fight a two-front battle, which is really not very enlightened – or easy to fix. But I hope someone has a good idea how to fix this, because I'm not sure how. — ReadOnlyAccount ( talk) 07:50, 19 December 2023 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||
|
To represent large character sets, ISO 2022 builds on ISO 646's property that 1 byte can define 94 graphic (printable) characters (in addition to space and 33 control characters).
So the control characters are always available no matter which character table is currently shifted in? -- Abdull 20:17, 7 June 2007 (UTC)
The comment appears to indicate that ISO-2022 is not useful except with 7-bit displays. Since both GL and GR are mapped, it applies to 8-bit and 7-bit displays (with the latter requiring extra effort on the part of the application developer). Tedickey ( talk) 22:15, 25 July 2009 (UTC)
The comment regarding disadvantages is also misleading, since (applying to cut/paste - apparently), it ignores the actual terminal implementations which may pass selections around as UTF-8. Tedickey ( talk) 22:18, 25 July 2009 (UTC)
"Display" is the wrong word; "system" is slightly better. IIRC, the typical PC console driver is 9-bit (512 glyphs can be used at a time, or so) plus 8 bits of colour (4 background, 4 foreground) plus a few bits for bold/underline/blink, plus some more stuff I've forgotten.
The article has many problems, such as the introduction saying that it's a 7-bit encoding (helpfully contradicting the rest of the article!), but not as many problems as ISO 2022. ⇌ Elektron 04:13, 29 January 2010 (UTC)
Reference 4, "DICOM ISO 2022 variation" is an incorrect url. It points to a simple test email message in a sourceforge project which does not appear to have any relation to DICOM. I've searched to try to find the correct link, with no success. I'd be very interested in the correct target of this link if it could be found. Dlmason ( talk) 12:25, 7 April 2012 (UTC)
Missing an history section. 84.97.14.22 ( talk) 19:01, 19 July 2012 (UTC)
I've removed an old neutrality tag from this page that appears to have no active discussion per the instructions at Template:POV:
Since there's no evidence of ongoing discussion, I'm removing the tag for now. If discussion is continuing and I've failed to see it, however, please feel free to restore the template and continue to address the issues. Thanks to everybody working on this one! -- Khazar2 ( talk) 04:26, 27 June 2013 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on ISO/IEC 2022. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 02:27, 8 April 2017 (UTC)
The article currently says "UTF-1, the multi-byte Unicode transformation format compatible with ISO/IEC 2022". I don't think it's "compatible" in the way the statement implies because while the standard allows multi-byte encodings, it requires the elements to have constant-length (e.g. all elements have to be 3 bytes) while UTF-1 is variable-length. UTF-1 is registered as a "Coding system different from ISO 2022" (see: https://www.itscj.ipsj.or.jp/itscj_english/iso-ir/ISO-IR.pdf), just like UTF-8 is. Escape sequences are provided for both UTF-8 and UTF-1, but using the "designate other coding system" method. If UTF-8 is not "compatible" then neither is UTF-1. -- 157.52.11.237 ( talk) 14:24, 24 October 2017 (UTC)
"Because of its escape sequences, it is possible to construct attack byte sequences that round-trip from ISO/IEC 2022 to Unicode and back."
This statement is incredibly scary and also confusing, which is not a good combination. What kinds of attacks? Why do escape sequences make them possible? What other encodings is this in contrast to (UTF-8?)? Why is round-tripping relevant?
There is a link, but there's not any more detail on the destination page, only discussion about popularity of encodings and discussion around measuring if they are in use in a specific piece of software.
Can someone please clarify this part of the article?
01:15, 31 July 2018 (UTC) — Preceding unsigned comment added by 178.197.231.171 ( talk)
The introduction in the article is far to technical to be an introduction, and misses the things that ought to be in an introduction. Eg is UTF-8 replacing the need for ISO2022? Is it expected that ISO2022 encodings will be phased out? When was the standard written? There are too many standards being referred to without an explanation of what they are (the reader of an article should not have to refer to lots of other articles to understand what they are reading); eg rather than just referring to a standard, use a sentence to describe what it is, followed by the standard's name in parenthesis). FreeFlow99 ( talk) 15:42, 27 April 2022 (UTC)
The present Encodings and conformance paragraph, whose current phrasing was introduced here, is kind of messy, because of how it speaks about letters "absent in"[sic] the ISO Basic Latin alphabet. In truth, the ISO Basic Latin alphabet too is one of the short alphabets (writing systems) trivially representable with 256-character encodings. The present paragraph tries to simultaneously talk about how there's this class of small writing systems to be contrasted with larger ones (that really require ISO 2022 or similarly expansive solutions), but then it also somewhat messily tries to convey or imply that these small writing systems already require extended ASCII because their charset exceeds what's in plain US-ASCII. That's trying to fight a two-front battle, which is really not very enlightened – or easy to fix. But I hope someone has a good idea how to fix this, because I'm not sure how. — ReadOnlyAccount ( talk) 07:50, 19 December 2023 (UTC)