Talk:ASCII/Archive 1

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.

Featured article review
of December 30, 2005

This review resulted in the passing of a new version of the article.

This was the promoted version and here's the diff. Looks like it's been more or less completely rewritten. Referencing looks inadequate for an article of this size, and the "see also" is too big. I support passing this review. Tuf-Kat 04:38, 2 December 2005 (UTC)

  • Many of the references were improperly put in the external links section. I fix some of it by moving them and I removed the link to Bob Bemer's website as it is either being blocked or no longer archived. I also collapsed the "see also" section into parallel lines. The article looks like featured quality. --maclean25 22:49, 17 December 2005 (UTC)


ASCII's "success"

ASCII is generally accounted the most successful software standard ever promulgated.

What does this really mean? If first computers were mostly build in

XJamRastafire
14:39 Sep 9, 2002 (UTC)

Well actually ASCII is only a successful for English, for other languages there has been a prolifertation of competing codes due to the 8-Bit limitation. Probably a good code to go for now is UTF-8. --HJH

Or, more to the point, Unicode, with UTF-8 as its character encoding. And 7-bit ASCII is a subset of Unicode, and also of UTF-8.

That was my line. I didn't say it was good, I said it was successful. I doubt there is a single serious text-handling application of any kind that doesn't recognize and process ASCII. I doubt there is any other software standard anywhere else, graphics, network, whatever, of which the equivalent statement is true. Ortolan88
Yes, I do believe that too. I was just asking, cause I am curious. There must be a certain key on which they have selected other non-alphabetical characters from the set of the Latin alphabet. Perhaps I exaggerated saying the code is obsolete today. Yes, it is perfect for a Latin based languages and specially for English. And in fact it is possible to (re)build such software standard elsewhere - but I guess this won't never happen. Thank you HJH and Ortolan88 for your answers. Long ago, when PC were not so common as these days, I visited one older friend who had made his own OS and his own ASCII-like code, but this is a history. --
XJamRastafire
11:46 Sep 10, 2002 (UTC)

ASCII is indeed a very successful standard. Today the plain ASCII files (with ASCII characters extended to 8 bits by adding one zero bit) are the only text encoding that will be interpreted correctly by all computers of the world. — Monedula 08:26, 11 September 2006 (UTC)

Strictly speaking, pure ASCII (that is the 7-bit standard) is not used much. Enhancements/extensions like ISO-8859-1 and UTF-8 are used, but not pure strict ASCII because it is not good enough outside the USA. The use of ASCII for programming languages (and the usage of []{}\| in them) have required the preservation of ASCII for the ASCII extensions since one want to preserve existing well-working software code. -- BIL (talk) 22:39, 12 January 2008 (UTC)

ASCII versions and variants

I might get around to this myself, but we need a mention, if not a better explanation of the differences / relationships between, the following:

  • ASA ASCII (1963)
  • ANSI X3.4-1968
  • ANSI X3.4-1977
  • ANSI X3.4-1986
  • ISO 646:1967, including an IRV and two 6-bit subsets
  • ISO 646:1972, including ISO 646-US, ISO 646-CA, ISO 646-CN, ISO 646-CU, ISO 646-DE, ISO 646-DK, ISO 646-ES, ISO 646-FR, ISO 646-HU, ISO 646-IT, ISO 646-JP, ISO 646-KR, ISO 646-NO, ISO 646-PT, ISO 646-SE, ISO 646-UK, ISO 646-YU, and ISO 646-IRV
  • ISO 646:1983
  • ISO/IEC 646:1991
  • ECMA-6 (1965, 1967, 1970, 1973, 1983, 1991 editions)
  • CCITT Recommendation V.3 (International Telegraph Alphabet No. 5) (1972?)
  • DIN 66003 (1974)
I've now made an entry for
ISO 646 national variations. A bit rough, and far from complete - there is an external link at the end of the page where more specific info for a number of languages may be extracted. -- Egil
07:44 Mar 9, 2003 (UTC)

…as well as the IANA registry's names for ANSI X3.4-1968, and the fact that they are the names approved on the Internet, such as in the "charset" parameter of a MIME header or in the encoding declaration of an XML document or parsed general entity. I finally got around to adding this. — mjb 23:10, 18 Jul 2004 (UTC)

…oh, and the IANA names for the other variants.

More aliases (same as V.3?):

  • IRA5 (CCITT International Reference Alphabet No. 5)
  • IA5 (CCITT International Alphabet No. 5)

The standards listed in this talk section are IMHO more important info than the aliases for mime charsets listed under "Aliases" in the article. I suggest removing "Aliases" and to add to "Variants" a list of standard names like the above. (IF we allow standards with tiny differences to ASCII, then there should be a parentesis about the difference.) -- David A 195.84.167.2 (talk) —Preceding comment was added at 22:10, 19 December 2007 (UTC)

Does someone have an official electronic copy of any of the X3.4 versions (not ECMA-6) that they can share, so we can get the whole IRV, C0, G0 stuff summarized? (It's not important enough to me to shell out my own money) — mjb 22:17 Nov 1, 2002 (UTC)

Dik T. Winter's info on character code standards describes ASCII-1963, ASCII-1965, USASCII-8, ASCII-1967, and the two 6-bit subsets of ISO 646:1967. — mjb 6 July 2005 09:57 (UTC)
ASCII was published as ASA X3.4-1963. This version did specify codes for lower case characters.

"did specify"? 210.170.202.147 (talk) 01:56, 24 March 2008 (UTC)

Overlap with Unicode

You say: ...the first 127 code points of each code are the same as ASCII, and the first 256 code points of Unicode are the same as ISO 8859-1. is this the truth? How does it match with UTF-8? An ASCII encoded file is a valid UTF-8 file, but an ISO 8859-1 encoded file is not. --Keichwa 20:25 Feb 24, 2003 (UTC)

UTF-8 is an encoding of Unicode, which is a character set. The first 256 code points of Unicode do match with the 256 code points of ISO 8859-1, however UTF-8's encoding of a series of those code points into a byte stream is different from ISO 8859-1's for the 128-255 range, using two bytes instead of one. --
Brion
20:29 Feb 24, 2003 (UTC)

You sure? I thought that other characters like Japanese ones are expressed in three bytes but not two. I am just unsure. See http://www.cl.cam.ac.uk/~mgk25/unicode.html -- Taku 20:32 Feb 24, 2003 (UTC)

Yes, I'm quite sure. :) UTF-8 is an encoding, not a character set. The Unicode characters at code points 128-255 are, by definition, the same as the ISO 8859-1 characters at code points 128-255. UTF-8 encodes these characters in two bytes (and various other characters which are not in ISO 8859-1 in from 2 to 6 bytes). These two-byte values are, obviously, not bit-for-bit identical to one-byte ISO 8859-1 encodings of the same code points. See
Brion
20:37 Feb 24, 2003 (UTC)
Umm doesn't UTF-8 as currently defined stop at 4 bytes (iirc it was 6 in the version that supported the old limit of UCS)? Plugwash 01:26, 26 December 2005 (UTC)

Link formatting

Anyone knows how to hide the underscore characters appearing for links in the character chart ? Lets have just the blue colour and make the underscore vanish. Jay 14:18, 2 Oct 2003 (UTC)

I don't think you can do this for individual pages. You can turn off all underscores in your
User preferences though. Angela
14:23, Oct 2, 2003 (UTC)

Grave accent vs single quotes

It is incorrect to imply that ASCII has an "accent" character. It has an apostrophe (in the 1983 version, which is aligned with ISO 646). It has a "grave accent" character in that same version. It does not have an "acute accent". Many Unix users do not much care for the (IMHO mistaken) changes made in the post-1978 versions of ASCII for ISO 646 alignment, particularly the deletion of the alternate interpretations "open single quote" and "close single quote" for ` and ', respectively, which were valid in the 1967 and 1978 versions, and are emphatically quotation marks and not accents or apostrophes in Unix programming, TeX, and the StandardEncoding vector in PostScript. 18.24.0.120 20:36, 6 Dec 2003 (UTC)

Hard-coded fonts for printable representations

The table for control characters has the "Printable representation" column.  There is a font prescription there, saying style="font-family:'lucida sans unicode','arial unicode ms'".  I understand the reason of this, but still it is incorrect.  Font prescriptions may be used only if there indeed is some reason to use this typeface, and not that one.  But here we only want a character to be displayed, and not to be displayed using a specific typeface.  So it is the browser's responsibility to find an appropriate font for this, not Wikipedia's. — Monedula 01:01, 5 Jun 2004 (UTC)

I understand your position, but your contention that it is entirely the browser's responsibility is not necessarily reflected in the HTML and CSS specifications. It's good practice, yes, but required, no. CSS in particular states "If there is a matching font face, but it doesn't contain a glyph for the current character, and if there is a next alternative 'font-family' in the font sets, then repeat step 2 with the next alternative 'font-family'. [...] If there is no font within the family selected in 2, then use a UA-dependent default 'font-family' and repeat step 2, using the best match that can be obtained within the default font.". A strict interpretation of this would prevent the browser from finding a match from all available fonts. Given that there are popular user agents that don't make an attempt to find a good font for characters not displayable in the current font, and given the nature of these particular glyphs (there's going to be very little distinction, visually or semantically, between how they render in any typeface), it seems that encouraging the renderer to use commonly deployed fonts that we know support those characters is a good and harmless practice. Ideally, the style info would only be forced upon those user agents that need it, but I doubt Wikipedia is going to implement browser-dependent stylesheets. - mjb 18:23, 12 Jun 2004 (UTC)

7-bit or 8-bit

I'm having difficulty understanding a certain aspect of ASCII. It is stated that ASCII is "strictly a 7-bit code", and we mention that historically, 8-bit bytes have been used to transmit ASCII, but that the high bit was either unused or was used for parity. Fair enough. But then we go on to show a chart in which ASCII codes are expressed in binary as 8-bit codes. Indeed, today it is quite common to label data stored and transmitted as 8-bit bytes as "ASCII".

I believe that ASCII was defined only in terms of 7-bit codes, but perhaps became, at some point, one of the following:

  • an 8-bit code in which the purpose of the high bit is entirely undefined (thus, the burden is on the decoder to know that only the first 7 bits encode the character);
  • an 8-bit code in which the high bit is undefined and allowed for use for any purpose other than determining which character is encoded (thereby relieving the burden mentioned above); or
  • an 8-bit code in which the high bit is explicitly defined as being used for padding (which seems to reflect actual practice, but I don't know if it is formally defined this way anywhere)

I thought that perhaps RFC 1345 was what defined ASCII as 8-bit first, but a brief Google search turns up references to ANSI X3.4 that call it an 8-bit code, so I'd appreciate some clarification here. - mjb 23:11, 18 Jul 2004 (UTC)

My computer teacher said the ASCII is 7-bit and extended ASCII is 8-bit and the chart in use looks like an incomplete extended ASCII chart. firstly the numbers match as far as I can tell those of Extended ASCII also the 8-bits then again a full ASCII chart of printable characters lists 224 characters so its gotta be incomplete. the person probably looked it up and got extended instead of regular --Shimonnyman 13:42, 5 September 2005 (UTC)
Extended ASCII *DOES NOT* reffer to any one character set. It is a name used to reffer to character sets in general that keep the lower 128 code values for ASCII whilst using the upper 128 for some kind of extention. Plugwash 13:48, 5 November 2005 (UTC)
For what it's worth: the original
Wordstar word-processing software used all 8 bits, but it had 7-bit encoding. It used a high-bit flag at the end of every word, sort of an error-checking routine. If you trim off all the high bits, you get straight 7-bit ASCII. --Cbdorsett
16:04, 7 January 2007 (UTC)

Pronunciation?

How is ASCII pronounced? The article gives 'aski' but then does that mean 'a ski' or 'ask e?'

The article previously stated that ASCII was pronounce as ass-key (and it is generally pronounced like that.) But I guess it offended someone :). --GatesPlusPlus 10:57, 28 Jan 2005 (UTC)
A new description using
stress. KJ
02:48, 2005 Mar 28 (UTC)
An anonymous user changed the pronounciation back to ASS-key, with no discussion. This might be an attempt to be helpful, but it follows my removal of the word penis from the article, so I suspect vandalism. Sigh. I've reverted the article back to ASK-EE. Would AS-key be better?
Chris Chittleborough 09:00, 10 September 2005 (UTC)

"You say 'toe may toe'"... How about 'ass ee'(The c is silent). That's how I say it anyways. E-)

It's fixed now. Accent on the first syllable. --Cbdorsett 16:06, 7 January 2007 (UTC)
How about "AIH ski"? P=) ~Kaimbridge~14:40, 4 January 2008 (UTC)

Suggest 26 possible wiki links and 64 possible backlinks for ASCII.

An automated Wikipedia link suggester has some possible wiki link suggestions for the ASCII article:

Additionally, there are some other articles which may be able to linked to this one (also known as "backlinks"):

* In

MBASIC programming language, can backlink ASCII: ...ed to disk in either a compressed binary format or as plain ASCII
text. Every source line was identified with a number, which...

  • In Galaxy Trek, can backlink ASCII: ...ships from attacking Federation Headquarters. The game uses ASCII graphics and can be played using RGB, Mono, or Composite gr...

Notes: The article text has not been changed in any way; Some of these suggestions may be wrong, some may be right.

LinkBot
11:26, 1 Dec 2004 (UTC)

ASCII order

The introductory section shows the list of characters in "ASCII order" - this seems a little circular. Characters in order of numerical value would not be a circular definition. --Wtshymanski 19:22, 19 Apr 2005 (UTC)

Request for references

Hi, I am working to encourage implementation of the goals of the

Fact and Reference Check Project has more information. Thank you, and please leave me a message when a few references have been added to the article. - Taxman
19:31, Apr 22, 2005 (UTC)

ASCII art

Shouldn't this article have at least one picture of ASCII art? 24.54.208.177 04:24, 24 Jun 2005 (UTC)

No, that's what ASCII art is for. Cburnett 06:27, Jun 24, 2005 (UTC)


June 2007 — Image:Ascii.jpg

How does a 128x128 pixel image count as ASCII art?! --Drlog 06:39, 22 June 2007 (UTC)

I don't think it does, so I've removed it. I've asked the guy who put it there to consider uploading a higher-resolution image and adding it to the ASCII art article. Cheers, CWC 11:32, 22 June 2007 (UTC)

Redirects for control characters

We should probably have redirects for the following:

For the record: I've changed the redirect from
Control-M. --32X
23:40, 9 February 2007 (UTC)

The whole table, not just printible?

I see that the printible ascii characters are included 3 times (two tables in introduction and another table below). Could someone include the entire table up to 255? Tell me how you get the binary information and I'll do it, or maybe I'll just leave it blank and then someone can fill in the rest.

Thanks!--142.51.21.39 18:51, 11 October 2005 (UTC)

As explained in the article, ASCII is a 7-bit code, so regardless of whether you're using 7-bit or 8-bit bytes, each character will only ever manifest as a value under 128 decimal. Historically, ASCII-encoded data was typically transmitted in 8-bit bytes, with the 8th bit used for either (1) nothing, (2) encoding characters beyond the range of ASCII, or (3) parity (something else unrelated to the encoded text itself). For situation #2 there emerged a number of standards like
ISO 8859 and C1 control codes, but these are not part of ASCII; they are supplements to it. It would be wrong for you to add them to the tables. It might be useful to have a separate table for the IANA-approved "us-ascii" character map, which explicitly defines ASCII as an 8-bit encoding with values 128-255 unassigned/disallowed, but I'm guessing this isn't what you had in mind. — mjb
20:17, 11 October 2005 (UTC)

Future of ASCII

I would like to see some discussion of whether we can depend on someone's being able to read or convert ASCII text saved today in 20 or 50 years from now? In other words, is it a good format to use for documents created for posterity? —Preceding unsigned comment added by 24.5.85.54 (talkcontribs) 19 October 2005

I assume ASCII documents will be readable in 50 years, since so many documents are using it, and because the future encoding Unicode is backwards compatible with ASCII. The fact that major programming languages like
ISO-8859-1 and other 8-bit encodings are readable then, is a good question. Programming languages use extended ASCII only for non-English strings and comments. -- BIL (talk
) 21:58, 29 December 2007 (UTC)
APL uses a non-ASCII character set, but it's one of the few. Characters used in APL form their own little range in Unicode. —Preceding unsigned comment added by 216.220.11.84 (talk) 06:48, 3 August 2008 (UTC)
Also, since it's a small and well specified standard it would be completely trivial to write a utility to convert it to whatever is needed in the future. As for your second question: if the document only contains characters that can be represented in ASCII, then why not? In fact, if you would save such a document as UTF-8 Unicode text, the result would be identical. Shinobu (talk) 13:55, 19 October 2008 (UTC)

Policy re External Links

There are lots of ASCII charts on the web, and people keep adding links to them. Since the article contains a perfectly good chart itself, I suggest that it should not link to yet-another-chart pages. I therefore removed links to

yep nuke it, its HIGHLY misleading to state that what appears to be one of the old IBM code pages is the most common extended ascii set today. Plugwash 13:50, 5 November 2005 (UTC)

I left http://www.jimprice.com/jim-asc.htm in, because it has some useful material explaining how to send a document "as ASCII". Chris Chittleborough 14:47, 7 November 2005 (UTC)

Note: The content related to ASCII http://www.paulschou.com/tools/xlate/ has been fixed, thank you for noticing my error. I have fixed it and provide this link as an educational tool. If you have any questions or requests I will be open to amend it if needed - Paul Schou


I've deleted a link to www.asciivalue.com. Despite its name, it allows non-ASCII input (codepoints > 127) and does not label its HTTP responses as ASCII.
I've left the link to http://www.paulschou.com/tools/xlate/ in, because it does lots of conversion and so could be useful. However, it also treats codepoints 128-255 as "ASCII". Should we delete this link?
Chris Chittleborough 11:55, 15 December 2005 (UTC)
I'd by inclined not to link to anything that propogates the myth that there exist ascii codes 128-255. Also most of the stuff on that site whilst usefull isn't really very much to do with the topic of this article. Plugwash 22:19, 25 December 2005 (UTC)
To be brutally honest i think MOST IF NOT ALL of the external links currently in this article deserve to go. we need one reasonally authoritive source for the code chart (unicode.org seems a good choice) in the references section and possiblly one converter tool for seeing the raw ascii values in the external links section. We are not a web directory we are an encyclopeidia and should be carrying references for our content and good links for people to read more on the subject but not a list of every trashy website thats perhipherally associated with a subject. Plugwash 22:19, 25 December 2005 (UTC)
Belated thanks to User:Plugwash for good work on this list. I've just deleted an ad for www.ascii.com from it and edited the text of two other links. Paul Schou has added an interesting comment, and his translation page now mentions that "Only codepoints < 128 are ASCII". I suggest we drop the link to www.asciivalue.com in favour of Mr. Schou's link. Chris Chittleborough 04:48, 1 February 2006 (UTC)
Link to www.asciivalue.com removed. Plugwash 12:54, 1 February 2006 (UTC)
Link reinstated by User:67.187.249.55 2 Feb 2006 and then removed again by Chris Chittleborough 17:20, 5 February 2006 (UTC)

Notes on External Links

Alt_codes and added links to it to a number of articles. Thanks, Nathanael! However, I have commented out the link in the ASCII page, on the assumption that not many people will QuickKey to enter ASCII characters :-) Chris Chittleborough
09:27, 8 February 2006 (UTC)

User:68.158.159.129 has added a link to http://www.asciilist.com/, which appears to be a work in progress and seems promising to me. —Chris Chittleborough 11:21, 6 April 2006 (UTC) (edited 22:45, 12 April 2006 (UTC))

I disagree. It is not authoritative, it exists just to drive traffic to the owner's Google ads, and contains no information that isn't already presented in the article. Charts like these are a dime a dozen. I'm deleting the link.—mjb 01:18, 13 April 2006 (UTC)
Mjb is right. (I use Firefox and the NoScript extension, so I didn't see the Google ads.) Good riddance. Cheers, Chris Chittleborough 10:00, 13 April 2006 (UTC)
User 74.229.83.147 (talk · contribs) inserted asciilist.com again with the HTML comment
Note: This was previously marked as spam and deleted; however, I found it as a very useful. The only other decent website that I have been able to find was www.asciitable.com, which is covered with watermarks and ugly ads. Please don't remove this as I think other people may find this helpful as well. -Will
User:Mjb has since reverted that edit. I suggest that if we do have a link to www.asciilist.com, it should be to the printer-friendly version, not the main page. Cheers, ChriWs Chittleborough 20:26, 14 April 2006 (UTC)
I already stated my reasons for removing it; no amount of "I thought it was still useful" makes up for the shortcomings I pointed out. Will is actually in a better position to make a case for improving the charts in the article on Wikipedia. However, I doubt he wants to do that. The IPs used by the person who added the asciilist.com link were 68.158.159.129 and 74.229.83.147, which are both fed by the same BellSouth router, 65.14.249.166, which is apparently in the state of Georgia. The asciilist.com domain is owned by Will Buckner ([email protected]) of Cumming, Georgia. The person posting here (and on my talk page) as "Will" (and who is the only person who seems to find asciilist.com worthy of inclusion) just started using the Wikipedia userid wcc44 today. I rest my case. >:Dmjb 03:39, 15 April 2006 (UTC)
I need to make myself clearer. I agree with Mjb's words and actions. I strongly oppose linking to a chart which is accompanied by ads. The point I was trying to make is that any case for linking to a chart which has ads would apply just as much to a printer-friendly version of that web page; therefore we should never link to the "unfriendly" version. (If there is no ad-free version of the chart, then I oppose any link to that site.) Chris Chittleborough 07:07, 15 April 2006 (UTC)
The printer friendly version is, of course, add free (wouldn't be too printer friendly otherwise :). The PDFs are also add free. Only the front page contains ads at all.
I still think that the arguments in favor of this external link are actually a case for adding a concise chart to Wikipedia (which has a Printable Version link on every article). There could be separate charts for each version of ASCII, too (1963, 1967, etc.). That way the material will be peer-reviewed and better disseminated.—mjb 18:55, 16 April 2006 (UTC)
Just because it's a "printable" version doesn't make it good enough. It needs to all fit on one printable page, yet make good use of space so that the fonts arent too small / etc. The version on asciilist.com was designed to fit entirely on one page and be a good quick reference (pin it up in your cubicle, etc.). Even if this could be accomplished on Wikipedia itself, would it really be worth the effort? It is providing something separate from the article. The article's purpose is to educate about ASCII itself (right?), whereas asciilist's printable page is meant as a "reference card" to the ASCII code. --Wcc 01:47, 17 April 2006 (UTC)
What about just linking to the printable page / PDF without ads? My intention in building the site was to provide a resource; the ads are just to help pay the bills. What would you guys think of a link directly to http://www.asciilist.com/index.php?a=showPrintableBasic ? This page contains no ads, and is a useful resource. It does add value to the article. The reason for which I created the page is that I, as a programmer, have been unable to find a good printable ASCII chart anywhere that isn't covered in ads and watermarks on the printable page and distracting from the content. While the article itself may provide all of the needed information on ASCII, it doesn't provide a quick, printable programmer's ASCII reference. Please consider allowing the add-free printable page to be added as an external link (I won't add it without approval). (And, yes, I am the owner of this site... I never denied that. That does not change the fact that it adds value to this article). Wcc 17:49, 15 April 2006 (UTC)

I've just deleted "ASCII Character Code Chart at Electronic Science Lobby", because it's not about ASCII (no DEL; 255 chars). This site has low-quality content and lots of Google ads. The link was added by User:61.17.232.207. —Chris Chittleborough 22:45, 12 April 2006 (UTC)

References and External links

I've just added http://www.wps.com/projects/codes/ into the External links section before I noticed it was in References. Rather than remove it I think the duplication is useful for clarity as I rarely think of references as offsite links. Is there a Wikipedia policy about this sort of duplication? Especially as in this case where the other website carries a lot more information than here. 86.16.135.53 11:41, 27 August 2006 (UTC)

I suggest we
(1) simplify the "References" section to just
<div class="references-small"><references/></div>
(2) move "Unicode.org chart on the ASCII range" to External links,
(3) drop the "Tom Jennings (October 29 2004)" link in favour of the one User:86.16.135.53 just inserted (enhancing the latter to wikilink to Tom Jennings), and
(4) drop the direct wikilink to
Alt codes
.
Cheers, CWC(talk) 12:33, 27 August 2006 (UTC) who also added the "References and External links" subheading

I've made these changes. We now have the following External Links (HTML comments shown in italics):

(The linkified dates are the result of a bot editing inside HTML comments.)

Cheers, CWC(talk) 20:28, 31 August 2006 (UTC)

Binary alphabet

I have proposed that Binary alphabet be merged into this article. Seems to be really about ASCII and not an alphabet. Srl 17:53, 25 November 2005 (UTC)

personally i'd say that article deseves and AFD i've never seen that term used and imo a redirection to here would mislead people is was a synonym of ASCII. Plugwash 22:06, 25 November 2005 (UTC)

"Binary alphabet" is used in the context of formal languages for referring to the fact that the alphabet is composed of two symbols. The article is however misleading, and in any case should not redirect here. Paolo Liberatore (Talk) 17:16, 30 November 2005 (UTC)

scandanavian

rfc 1459 states

Because of IRC's scandanavian origin, the characters {}| are considered to be the lower case equivalents of the characters []\

does this apply to scandanavian languages in general or not and if so is the fact this is easy to do in ascii a design feature or a coincidence? Plugwash 00:29, 26 December 2005 (UTC)

I'm not sure I understand the question. Danish and Norwegian have three additional letters (æøå and ÆØÅ) compared to English, and it was natural to steal the "next three" symbols from ASCII when making a national variant. These symbolas are not tradionallly common in Danish or Norwegian text. Swedish (and I believe Finnish) has different symbols for the letters denoting (ÄÖÅ and äöå) the same sounds as the Danish/Norwegian letters, but the sorting sequence is different (ÅÄÖ). They choose to use the same sequence as Danish/Norwegian for compatibility, rather than the "correct" sequence.
So it is a design feature of the Danish/Norwegian (and partly Swedish/Finnish) variants of ASCII that they are easily implementable from an ASCII base, but it is unlikley that the ASCII standard was designed with non-English variants in mind. --Per Abrahamsen 09:51, 2 January 2006 (UTC)

1986

What change was made in 1986?

Ben Arnold 10:41, 2 March 2006 (UTC)

Information about specific codes

Any information on the intended (and historical / actual) use for the FS, GS, RS, US codes? (GhostInTheMachine 15:27, 29 March 2006 (UTC))

They were intended for transmitting tabular information, the sort of thing you'd store in database tables nowadays. For example,
<message>      = <clients-file> { FS <clients-file> } EOD
<clients-file> = <client-header> { GS <invoice> }
<invoice>      = <invoice-header> { RS <line-item> }
<line-item>    = <product-code> US <price> US <amount> [ US <comments> ]

IIRC, Bob Bemer has written that he never saw them used. However, I believe Niklaus Wirth did use FS as the end-of-file indicator in the Oberon operating system. Chris Chittleborough 08:30, 30 March 2006 (UTC)

The Pick system used the codes as delimiters in the database records. GhostInTheMachine 10:20, 29 April 2006 (UTC)

The comment about

TECO using ESC to introduce commands was incorrect - ESC terminated textual arguments to commands (e.g. the text to be inserted or the name of a file) but the interpreter started out processing commands. I replaced it with a more correct comment and added a note about introducing terminal control sequences. I'd like to say something about using it in command-completion shells, but I don't use one so I'm not familiar with the semantics. Jordan Brown
05:37, 11 September 2006 (UTC)

The explanation for CR vs LF vs NL didn't agree with my understanding of the history - that UNIX and MacOS used single characters for simplicity - and so I "was bold" and fixed it, and added history further back tracing the use of CRLF in files to DEC OSes, which is where CP/M got it. Jordan Brown 05:37, 11 September 2006 (UTC)

In my opinion, the comment about nobody using ^N and ^O to switch character sets was incorrect, and so I removed it. Most if not all ANSI terminal implementations include this feature. One might wonder how often one *wants* to switch character sets, but it used to be quite common as I believe it was how you reached the line-drawing set on VT-100s. Granted, most of my use of this feature is to echo a ^O to recover from cat'ing a file that included a ^N. Jordan Brown 05:37, 11 September 2006 (UTC)

Thanks, Jordan Brown, for that good edit. You're right about ^N and ^O, they're part of
ISO-2022. Cheers, CWC(talk)
15:53, 11 September 2006 (UTC)
You're welcome. Here's another, clarifying why hitting Backspace may yield ^H. I'm not entirely happy with the first few words of that note - I don't exactly consider it an "ambiguity" - but it's the words that were there in the previous rev and I can't immediately come up with anything better. I also wonder whether this note is getting a bit too long. Jordan Brown 05:02, 13 September 2006 (UTC)
If a program doesn't handle the backspace key, and instead sends it to the screen, and the routine that handles writing strings to the screen outputs control codes like ^letter, then you'd get ^H, I think. It's the only scenario I can imagine right now. Shinobu (talk) 14:02, 19 October 2008 (UTC)

U+2400 etc not rendered?

Unicode has a block of "control picture" characters: U+2400 = SYMBOL FOR NULL, U+2401 = SYMBOL FOR START OF HEADING, and so on. The article uses these. However, it turns out that Internet Explorer does not render these characters, even though Firefox does. (Heartfelt rant about software development models omitted for brevity.) My tests used IE V6.0.2900.2180.xpsp_sp2_gdr.050301-1519 on XP service pack 2, and Firefox V1.5.0.1 on the same OS.

I have just edited the article to say that the PR column in the table of control characters may not render properly on some browsers.

Could people with other browsers take a close look at this page and report whether it renders the control picture characters properly? For instance, U+2400 should show up as "NUL" in small letters, probably arranged horizontally (NUL or diagonally (NUL).

Cheers, CWC(talk) 12:39, 20 April 2006 (UTC)

IEs font selection sucks. I've put template:unicode in place, if they still don't show can you use character map to tell us which fonts you have that contain them? Plugwash 12:50, 20 April 2006 (UTC)
Good move. But the control picture characters still aren't rendering for me in IE. I suspect that Firefox is constructing the "glyphs" itself from downsized capital letters. (Because some unicode characters are combinations of simple characters — eg. roman numerals — they can be rendered even if not defined directly in fonts.) I would hope that Microsoft's unicode font facilities, whose name currently escapes my mind, does this sort of combining. But, if so, why doesn't IE use combining? Oh, that's right: IE6 sucks. CWC(talk) 14:09, 20 April 2006 (UTC)
I don't think this is so much a failure in IE font handling as it is a gap in Windows' Unicode coverage. IE seems to do OK on a wide range of random Unicode characters. I presume that there simply isn't any font (that Windows searches) that includes these particular Unicode code points. I assume that there's a way to augment the fonts that Windows uses, but I haven't yet found anything that describes that process. (Yes, something could artificially construct these characters, but that would imply significant special-case work. It'd be simpler to supply an appropriate font.) Jordan Brown 06:03, 13 September 2006 (UTC)
Hi, Jordan. My guess (based only on stuff I've seen Mozilla browsers do) is that their cross-platform font-handling code has a facility to synthesize missing glyphs from other characters. I'd argue that Microsoft's unicode font system, whose name still escapes my mind, should do the same thing. So, yes, it's a possible defect in that system, not in IE, that causes the problem ... but can we please keep slagging IE anyhow?
(Maybe IE7 will fix things? Let's hope it comes with a better font handling system or better fonts.) Cheers, CWC(talk) 12:45, 13 September 2006 (UTC)
AHA! Imagine my surprise when I happened to look at this page on a different computer, also with IE6, and these characters looked OK! Judiciously trimming down the page yielded the answer: one computer had Arial Unicode MS and the other didn't. It looks like this font comes with MS Office, and it probably didn't get removed when I uninstalled the trial version of MS Office from this computer. (It's also available for purchase; see the article above.) Other fonts that MediaWiki:Common.css's .Unicode style looks for are: Code2000, TITUS Cyberbit Basic, Doulos SIL, Chrysanthi Unicode, Bitstream Cyberbit, Bitstream CyberBase, Thryomanes, Gentium, GentiumAlt, Visual Geez Unicode, Lucida Grande, Microsoft Sans Serif, and Lucida Sans Unicode. Perhaps some of them have these glyphs and are more readily available; I haven't had a chance to investigate. Jordan Brown 21:48, 13 September 2006 (UTC)
Code2000 is $5 shareware and has these glyphs, though they don't look all that good. Jordan Brown 22:26, 13 September 2006 (UTC)