Talk:ISO/IEC 2022

message: 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)
replies: text: I don't have ISO 2022 text, but according to JIS X 0202 (which corresponds to ISO 2022), you can designate control character sets (C0, C1) by escape sequences.  See control character sets registrations at http://www.itscj.ipsj.or.jp/ISO-IR/ .  ESC is guaranteed to be same code for all control character sets. --Fukumoto 16:42, 8 June 2007 (UTC)
thread_title: ISO 2022 vs ISO 646

message: 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)
replies: text: Rather than that link, this may be useful TEDickey (talk) 13:31, 7 April 2012 (UTC)
replies: text: Thanks, those examples are helpful, but are largely directed to VRs of type PN. There should (I hope) be a link that talks about other differences or issues in general DICOM encodings compared with ISO 2022 -- for example, the DICOM standard forbids certain control characters and shifts. I'm hoping there's a nice summary somewhere to list all the differences in simpler language than is used in the DICOM standard. Dlmason (talk) 12:31, 8 April 2012 (UTC)
thread_title:  DICOM ISO 2022 variation 

message: Missing an history section. 84.97.14.22 (talk) 19:01, 19 July 2012 (UTC)
thread_title:  Missing an history section. 

message: I've removed an old neutrality tag from this page that appears to have no active discussion per the instructions at Template:POV:
::This template is not meant to be a permanent resident on any article. Remove this template whenever:
::#There is consensus on the talkpage or the NPOV Noticeboard that the issue has been resolved
::#It is not clear what the neutrality issue is, and no satisfactory explanation has been given
::#In the absence of any discussion, or if the discussion has become dormant.
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)
thread_title:  removing POV tag with no active discussion per [[Template:POV]] 

message: 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:
*Added archive https://web.archive.org/web/20001216022100/http://tronweb.super-nova.co.jp/characcodehist.html to http://tronweb.super-nova.co.jp/characcodehist.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 02:27, 8 April 2017 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: I agree this statement is confusing. UTF-1 is certainly not ISO-2022 conformant. "Compatible" means... what, exactly? 204.225.215.56 (talk) 03:27, 29 June 2019 (UTC)
thread_title: UTF-1

message: "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)
thread_title:  Disadvantages list 

message: 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)
replies: text: I've now reworked the lede and initial sections; is this an improvement? --HarJIT (talk) 07:51, 28 April 2022 (UTC)
thread_title:  Introduction 

message: 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)
replies: text: The intent is that the ISO Basic Latin alphabet can be represented with only ASCII (i.e. only requiring seven bits or 127 codepoints, not eight bits unless you want to use the eighth as a parity bit), while other Latin alphabets (or e.g. Cyrillic alphabets) require either modified ASCII (e.g. DIN 66003, YUSCII, KOI-7), extended ASCII (e.g. Windows-1250, KOI-8) or both (e.g. VNI for DOS). I'm ignoring EBCDIC since it isn't directly relevant to PCs, only to mainframes, and would only confuse the issue. But I take your point that it isn't clear. --HarJIT (talk) 13:17, 19 December 2023 (UTC)
replies: text: I've reworked the paragraph somewhat now. --HarJIT (talk) 15:01, 19 December 2023 (UTC)
thread_title:  Encodings and conformance