[22]

ASCII は、かつて米国で広く用いられた符号化文字集合でした。

RFC 20

[3] RFC 20 は、 USAS X3, 4-1968 を添付しています。

[4] RFC 0020 - ASCII format for Network Interchange (2011-05-08 17:22:46 +09:00 版) https://tools.ietf.org/html/rfc0020
[46] rfc20.pdf, 2015-02-05T22:59:10.000Z, 2025-07-08T04:16:17.496Z https://www.rfc-editor.org/rfc/rfc20.pdf

[5] RFC 20 自体は、 ASCII は7ビット符号ですが、最上位ビットを常に0とした8ビット符号として使用することを提案しています。

[18] IETF 等には、無料で入手できない本来の US-ASCII ではなく RFC 20 を参照するのが望ましいと強硬に主張する人がいます。

[40] JOSE は ASCII(STRING) という関数風の記法で仕様を記述しています。 >>30, >>39, >>41, >>29

[30] RFC 7515 - JSON Web Signature (JWS) (2020-03-29 16:13:43 +09:00) https://tools.ietf.org/html/rfc7515#section-1.1
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation
of STRING, where STRING is a sequence of zero or more ASCII
characters.
[39] RFC 7516 - JSON Web Encryption (JWE), 2022-11-23T02:47:58.000Z https://datatracker.ietf.org/doc/html/rfc7516#section-1.1
[41] RFC 7517: JSON Web Key (JWK), 2022-11-25T08:33:34.000Z https://www.rfc-editor.org/rfc/rfc7517.html#section-1.1
[29] RFC 7518 - JSON Web Algorithms (JWA) (2019-11-27 04:11:14 +09:00) https://tools.ietf.org/html/rfc7518#section-1.1
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation
of STRING, where STRING is a sequence of zero or more ASCII
characters.

[43] Correct classification of RFC 20 (ASCII format) to Internet Standard, 2024-06-06T05:16:37.000Z https://datatracker.ietf.org/doc/status-change-rfc20-ascii-format-to-standard/

[6] Rich Salz on Twitter: "Better late than never: IESG is going to declare RFC 20 standards-track. http://t.co/fn0SiyMx0m Yes, 20. 7-bit ASCII." ( (2014-12-10 11:06:10 +09:00 版)) https://twitter.com/RichSalz/status/542040814093086721

[7] Mail Archive Sign in STD 80, RFC 20 on ASCII format for network interchange (2015-01-29 17:58:51 +09:00 版) https://mailarchive.ietf.org/arch/msg/ietf-announce/rlIsY8yvvKhbkbkuk2mcQ-ylSNw

[45] 存在が忘れられていた RFC 20 が「発見」されてインターネット標準になってしまうサクセス(?)ストーリー。標準化団体行政史という観点でも実に面白い。

[47] それまで電子配布はされていなかったのが、西暦1999(平成11)年9月1999-09に平文版が配布されるように。

[48] 当時は平文に書き起こされたものだけだったはず。その後いつのまにか紙原本をスキャンした PDF 版が配布されるように。 >>46 の日付は西暦2015(平成27)年2015で、その年かそれ以前の数年くらいのタイミングか。

[50] PDF 版を見るまでわからなかったがPDF版には手書きの正誤指示 (かなり重要) があって、平文版は何の注釈もなく修正後本文になっている。

[49] よく見ると原文の附属書は RFC 版から省略されている。

[51] ANSI 規格には # を応用が £ にしてもよい、みたいな規定 ( ISO/IEC 646の版 ) も入っていて、インターネットは「応用」としてそこちゃんと決めないといけないんじゃないんかい、何も考えずに RFC 20 を参照だけしている RFC はどうすんの、と思ったりも。

US-ASCII (IANA charset)

[11] RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (2015-03-22 13:14:46 +09:00 版) http://tools.ietf.org/html/rfc2046#section-4.1.2

RFC 2046 (MIME) 4.1.2 の定義

[1]

MIME charset US-ASCII は ANSI X3.4‐1986 で定義される文字集合です。
ISO/IEC 646:1991 の IRV と同じ物です。

ISO/IEC 646の版や ISO/IEC 2022 の符号拡張法を使う場合は、適切な札付けする必要があります。 (ということなので、つまり US-ASCII で符号拡張法は使えません。)

[12] US-ASCII が表すものには歴史的に混乱と曖昧性がありましたが、 MIME の US-ASCII は任意の7ビット文字コードではなく、 ANSI X4.3-1986 US-ASCII 符号化文字集合を指しています。 IRV 以外のISO/IEC 646の版や符号拡張法、右半面や多バイトを使うものは、 US-ASCII ではありません。 >>11

[13] charset 名 ASCII は予約されており、いかなる目的でも使ってはなりません >>11。

[14] しかし IANA登録簿では US-ASCII の別名となっているわけですが。。。

[15] MIME で定義されていたり de facto の意味を持つとされている制御文字は、 CRLF, FF, TAB (HT) だけです。他の CL の制御文字と DEL は、 text/plain 以外の媒体型でその用法を規定している場合及び情報交換の当事者間の合意がある場合に限って意味を持ちます。 >>11

text/* の charset の既定値

[2] MIME の規定によれば、 text/* 媒体型の charset 引数が省略された時の既定値は US-ASCII です。

これは、 MIME を作った時に、米国のインターネットで普通に利用されていたものをそのまま既定値にしただけです。

(そしてそれは RFC 822 の規定に整合していますが、当時の慣習には必ずしも一致しません。欧州や亜細亜では 8ビット化や ESC による符号拡張を使う、 RFC 822 の拡張版 (厳密に言うと、 RFC 822 は ESC による符号拡張を使うとも使わないとも言っていないので拡張とは呼ばないかもしれません。) が使われていました。)

文字集合としての ASCII

[16] 「ASCII」というとき、本来の符号化文字集合としての ASCII ではなく、 ASCII で規定された94文字ないし128文字の文字集合を指していることもあります。

[17] 例えば、 Unicode の U+0000-U+007F、あるいは U+0020-U+007E のことを、 ASCII文字と言うことがあります。

[25] この意味での ASCII については、 ASCII文字を参照。

[23] ASCIIアート (AA) のように、 ASCII が本来の意味を離れて文字一般を表していることすらあります。

Web における ASCII

[19] 符号化ラベル ascii や us-ascii は、 (その超集合である) windows-1252 の別名として解釈されます。

windows-1252

[20] そもそも7ビット符号である US-ASCII が8ビット符号として使われた時、右半面は (著者は使ってはいけないのですが、受信した実装が) どう解釈するべきか明確でありませんでした。そのため実装は様々で、中には最上位ビットを無視する (セキュリティー的に問題ある) ものもありました。

[28] ASCII符号化とASCII復号は、仕様書上のアルゴリズムとして定義されています。単独の文字コードとしての利用はできません。

実利用例

[52] null, 2012-12-19T19:33:13.000Z, 2025-10-21T06:15:56.275Z https://www.anc.org/MASC/texts/175841.txt

ANSI_X3.4-1968

[53] Revised KBO section, 2003-08-25T17:32:23.000Z, 2025-10-21T06:16:18.495Z https://www.astro.princeton.edu/~dss/LSST/lsst-general/msg.167.html

Content-Disposition: attachment; filename=lsstkbo3.tex
Content-Transfer-Encoding: quoted-printable
Content-Type: text/x-tex; name=lsstkbo3.tex; charset=ANSI_X3.4-1968

[54] [Cmake] Shared library versioning, 2003-08-29T15:13:08.000Z, 2025-10-21T06:17:15.228Z https://cmake.org/pipermail/cmake/2003-June/003923.html

Content-Disposition: attachment; filename=cmake_soversion.diff
Content-Type: text/x-patch; name=cmake_soversion.diff; charset=ANSI_X3.4-1968
Content-Transfer-Encoding: 7bit

メモ

[8] (2014-10-28 14:57:07 +09:00 版) http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecma%20philosophy%20on%20codes.pdf

[9] (2014-10-28 16:25:56 +09:00 版) http://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/ECMA-7,%201st%20Edition,%20April%201965.pdf

[10] (2015-03-03 13:01:37 +09:00 版) http://trafficways.org/ascii/ascii.pdf

[21]

RFC 959 - File Transfer Protocol ( (2016-06-05 16:18:06 +09:00)) https://tools.ietf.org/html/rfc959#page-3

ASCII
The ASCII character set is as defined in the ARPA-Internet
Protocol Handbook. In FTP, ASCII characters are defined to be
the lower half of an eight-bit code set (i.e., the most
significant bit is zero).

[26] Improve representation guidelines for bytes and code points (annevk著, 2017-03-23 22:25:17 +09:00) https://github.com/whatwg/infra/commit/543b2c48b6e1babb50d77e5a3ba5b86be8b56eb9

[31]

RFC 42 - Message Data Types (2021-01-24T08:11:18.000Z, 2021-03-10T04:59:23.963Z) https://tools.ietf.org/html/rfc42

2. U.S. Ascii
3. EBCDIC
4. Mod 33 TTY Ascii

[32]

RFC 80 - Protocols and Data Formats (2021-01-31T16:13:15.000Z, 2021-03-10T05:02:05.722Z) https://tools.ietf.org/html/rfc80

1) Character code translation (viz., decimal, octal,
hexidecimal, 8 bit ASCII, 7 bit ASCII, EBCDIC, and
binary).

[33]

RFC 1090 - SMTP on X.25 (2021-02-01T01:04:16.000Z, 2021-03-12T08:51:07.587Z) https://tools.ietf.org/html/rfc1090#section-8

The character code used on X.25 is the full ASCII-8 code, with no
escapes or modifications.

[34]

RFC 1154 - Encoding header field for internet messages (2021-01-24T13:41:10.000Z, 2021-03-13T08:01:54.039Z) https://tools.ietf.org/html/rfc1154#section-4.1

On some transport services, only the 7 bit subset of ASCII can be
used. Where full 8 bit transparency is available, the text is
assumed to be ISO 8859-1 [3] (ASCII-8).

[35]

RFC 1314 - A File Format for the Exchange of Images in the Internet (2021-01-31T10:24:09.000Z, 2021-03-13T09:39:32.003Z) https://tools.ietf.org/html/rfc1314#page-11

2 = ASCII 8-bit ASCII terminated with a null (variable
length)

[36] Federal Information Processing Standards Publication: code for information interchange - fipspub1-2-1977.pdf, 2017-12-04T14:22:25.000Z, 2022-03-23T03:43:20.364Z https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub1-2-1977.pdf

[37] Federal Information Processing Standards Publication: for bit sequencing of the American national standard code for information interchange in serial-by-bit data transmission - fipspub16-1.pdf, 2017-12-04T17:01:31.000Z, 2022-03-23T03:44:25.205Z https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub16-1.pdf

[38] Federal Information Processing Standards Publication: subsets of the standard code for information interchange - fipspub15.pdf, 2017-12-05T12:26:05.000Z, 2022-03-23T03:52:16.238Z https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub15.pdf

[27] ANSIコードページに対するOEMコードページのことを ASCII と俗に言うらしいです。

RFC 20

TELNET ASCII

POSIX Portable Character Set