アスキー表

使い方

1. テーブル全体を閲覧：128個のASCII文字すべてがコードポイント順（0〜127）に並んだグリッドで表示される。各セルには可視文字（または制御コードの略称）・10進コード・16進数/8進数/2進数が表示される。
2. カテゴリでフィルター：ドロップダウンで制御文字（0〜31）・印刷可能文字（32〜126）・文字・数字・記号に絞り込む。例えば句読点ブロックだけが必要なときに便利だ。
3. 検索：検索ボックスは文字名（「LF」）・略称・数値（10進数または16進数）で一致する。0x41・65・Aのいずれを入力しても同じセルに移動する。
4. セルをクリックすると、そのセルの任意の表現をクリップボードにコピーできる。ANSIエスケープに\x1B、Unixの改行に0x0A、スペースの10進数32が必要なときに便利だ。

ASCIIの略史

ASCII（American Standard Code for Information Interchange）は1961年5月、IBM技術者のBob Bemerが当時使われていた互換性のない十数種の文字コードを置き換えることを目標に、アメリカ規格協会のX3.2小委員会に提案した。最初に公開された版はASA X3.4-1963で、小文字が追加されたのは1967年の改訂からだ。規格はその後ANSI X3.4-1986の名のもとで何度も再確認され、国際的な双生兒であるISO/IEC 646（およびヨーロッパのECMA-6）を通じてすべての現代的文字エンコーディングの基盤を形成している。

ネットワーク利用のため、ASCIIは1969年10月16日にVint Cerf（UCLA）によって執筆されたRFC 20「ネットワーク交換のためのASCIIフォーマット」で規定された。RFCの勧告（「上位ビットが常に0の8ビットバイトに埋め込まれた7ビットASCII」）は今日もすべての現代的プログラミング言語とプロトコルがプレーンテキストを考える方法だ。米国連邦政府は1968年のリンドン・B・ジョンソン大統領の大統領令により、1969年7月1日以降すべての連邦コンピューターにASCIIサポートを義務付け、業界全体での採用を保証した。

なぜ7ビットなのか？

X3.2委員会は2つの魅力のない選択肢の間で苦悩した。6ビットのコード（ITA2などの古い電信アルファベットで使用）は信頼性が低かった。ノイズの多い回線での1ビットの反転がシフトビットに当たると、以降のすべての文字が誤デコードされるからだ。8ビットのコードは高価なメモリと低速なモデムの時代には無駄に見えた。妥協案は7ビット＝128コードポイントで、8番目のビットをパリティ用に空けておくものだった。すべてのバイトで1ビットの合計数が偶数（または奇数）になるようにパリティビットを設定することで、1ビットの伝送エラーを100%検出できた。これは1960年代のアコースティックカプラーとシリアルケーブルが引き起こしていた正確な問題だった。

エラー率が下がりモデムが高速化するにつれ、8番目のビットは転用された。各国の「拡張ASCII」コードページ（Latin-1、Windows-1252、Mac Roman、KOI8-R、…）はコード128〜255をアクセント付き文字や罫線文字に使用したが、これらのマッピングは互いに互換性がなく、最終的にUnicodeとUTF-8に置き換えられた。

128コードポイントの構成

7ビット = 2⁷ = 128種類のコードで、33個の制御文字（0〜31とDEL=127）と95個の印刷可能文字（32〜126）で構成される：

今も重要な制御文字

33個の制御文字のほとんどはテレタイプや紙テープのコマンドとして生まれ、今では歴史的な遺物だ。日常的なコンピューティングで今も重要な役割を果たしているものがいくつかある：

• NUL（0x00）：CおよびCから派生したあらゆる言語での文字列を終端する。ファイルパスに埋め込みのNULをペーストすることは、古いコードをクラッシュさせる古典的な方法だ。
• BEL（0x07、\a）：ターミナルのビープ音。printf '\a'で今も発生させられる。
• BS（0x08、\b）：バックスペース。プログレスバーライブラリが前の行を上書きするために使用する。
• HT（0x09、\t）：水平タブ。TSVファイルのタブ文字とPythonインタープリターの永遠のインデント議論に使われる。
• LF（0x0A、\n）：ラインフィード。Unixの改行コードだ。
• CR（0x0D、\r）：キャリッジリターン。Windowsの改行コードの半分。プログレスバーでは単独で「行頭に戻る」に使われる。
• ESC（0x1B、\e / \x1B）：エスケープ文字。Bemerの元々の発明で、今はあらゆるANSIターミナルエスケープシーケンス（色・カーソル移動・画面消去）のプレフィックスだ。
• FS / GS / RS / US（0x1C〜0x1F）：ファイル・グループ・レコード・ユニットセパレーター。1960年代のレコード指向のテープストレージ向けに設計され大部分は忘れ去られたが、RFC 7464「JSON Text Sequences」がRSをストリーミングJSONレコードのプレフィックス区切り文字（application/json-seq）として復活させた。GSは一部の小売りバーコードプロトコルに今も登場する。
• DEL（0x7F）：「rub out」。Teletype Model 33のRUB OUTキーはコード127を送信した。2進数では1111111、7ビットすべてが1だからだ。紙テープの文字を削除するにはオペレーターがテープを戻してRUB OUTを押し、既存の穴すべてに穿孔した。受信側はすべてのビットが1のバイトを無視することになっていた。

改行コード戦争

3つのプラットフォームが3つの異なる慣例を選択し、ソフトウェアはその後ずっとその代償を払い続けている。機械的な起源はタイプライターとテレタイプで、2つの別々の動作が必要だった。キャリッジリターンは印字ヘッドを1列目に戻し、ラインフィードは紙を1行分送った。異なるシステムがこれを1バイトで符号化するか2バイトで符号化するかの決定を独自に行った：

インターネットプロトコルの大半はCRLFを義務付けている。HTTP・SMTP・FTP・MIME・標準インターネットメッセージフォーマットはすべてCRLFを指定する。RFC 5322は明確だ。メッセージボディでは「CRとLFはCRLFとして一緒にのみ現れなければならない。独立して現れてはならない」と。しかしソースコード内では慣例はチームによって異なり、そのためgitはcore.autocrlfを提供している。Windowsでtrueに設定すると、gitはワーキングツリーではCRLFでチェックアウトするがリポジトリにはLFで保存するため、同じソースファイルがどのプラットフォームでも同じblobハッシュを生成する。プロジェクトレベルの代替は.gitattributesエントリの* text=autoだ。

ターミナルカラー用ANSIエスケープシーケンス

エスケープ文字（ESC、0x1B）はターミナル出力に色を付けるANSIエスケープシーケンスのプレフィックスだ。標準はECMA-48（1976年）で、後にANSI X3.64として採用されISO/IEC 6429に統合された。文法はESC [ + パラメーター + 最後の1文字。ESC [の部分はControl Sequence Introducer（CSI）と呼ばれ、言語によって\e[、\x1b[、\033[のいずれかで表記される。一般的なSelect Graphic Renditionコード：

• 0: リセット / 標準 · 1: 太字 · 4: 下線 · 7: 反転表示
• 30-37：前景色（黒・赤・緑・黄・青・マゼンタ・シアン・白）
• 40-47：背景色（同順）
• 90-97 / 100-107：明るい前景色 / 背景色

printf '\033[1;31mERROR\033[0m'は「ERROR」を太字の赤で印刷し、その後リセットする。すべての現代的なターミナルエミュレーター（および2019年以降のWindows Terminal）がこれらをサポートしている。

ASCIIとUnicodeおよびUTF-8

ASCIIは128コードポイントを定義し、Unicode 16.0（2024年リリース）は154,000以上を網羅する。重要な橋渡しはUTF-8だ。ウェブで支配的なテキストエンコーディングで（2026年には約98%のウェブサイトが使用）、UTF-8は7ビットのASCIIバイト（0x00〜0x7F）がこれまでと同じ文字をエンコードし、上位ビットがゼロになるよう設計されている。実際的な帰結として、すべての有効なASCIIファイルはバイトごとに同一の有効なUTF-8ファイルでもある。127を超えるコードポイントは各バイトの上位ビットが1のマルチバイトシーケンス（2〜4バイト）でエンコードされ、レガシーのASCIIパーサーがそれらをASCII文字と混同しないことを保証する。

主要プログラミング言語でのASCII

ケースビットトリック

ASCIIレイアウトの小さくも優雅な特性：大文字と対応する小文字はちょうど1ビットだけ異なる。Aは65 = 0100 0001で、aは97 = 0110 0001だ。ビット5だけが異なる。これにより大文字小文字を区別しない比較が単一のビット演算で実現する。x | 0x20で小文字に強制し、x & 0xDFで大文字に強制でき、どちらもルックアップテーブルより高速だ。これは1967年の改訂での意図的な設計の選択であり、レイアウトが一部で「ランダム」に見える理由の一つだ。アルファベット順だけでなくハードウェアフレンドリーな特性をエンコードしているのだ。

よくある落とし穴

1. 数字の0とNUL制御文字の混同。NULはコード0で、文字「0」はコード48だ。いかなるプログラミング言語でも互換性はない。
2. 1バイト＝1文字と仮定すること。ASCIIテキストでのみ当てはまる。UTF-8テキストは可変幅文字を持つため、ラテン文字以外のスクリプトでは文字数とバイト長が大きく異なる場合がある。
3. 1ファイル内に複数の改行コードを混在させること。同じファイル内にCR / LF / CRLFが混在すると多くのパーサーが混乱し、開くOSによって幽霊の空行や改行の欠落が生じる。
4. C文字列の末尾NULでの1つずれ。文字列が末尾のNUL用の余分な1バイトを必要とすることを忘れることが、元祖バッファーオーバーフロー脆弱性だ。
5. 「拡張ASCII」の可搬性の誤った前提。コード128〜255はLatin-1、Windows-1252、KOI8-R、Mac Romanなどでそれぞれ異なる文字を表す。UTF-8が唯一安全な現代的選択だ。
6. 信頼されていない入力への埋め込みESC。ユーザー提供のデータをサニタイズせずにターミナルにログ出力すると、攻撃者が色変更・カーソル移動・画面消去などのANSIエスケープシーケンスを注入でき、悪意のあるコンテンツを隠すことがある。

よくある質問

DELのコードがなぜ0でなく127なのか？

127を2進数で表すと1111111、7ビットすべてが1だからだ。紙テープの文字を削除するにはオペレーターがテープを戻してRUB OUTを押し、既存の穴すべてに穿孔した。受信側はすべてのビットが1のバイトを無視することになっていたため、「削除された」文字はその後の読み取りで不可視になった。この慣例は初期のテレタイプコードから受け継がれた。

「拡張ASCII」とは何か、使っても安全か？

標準ASCIIはコードポイント0〜127（7ビット）を網羅する。「拡張ASCII」はコードポイント128〜255に追加文字（Latin-1・Windows-1252・KOI8-R・Mac Romanなど多数）を割り当てる8ビットエンコーディングを大まかに指す。落とし穴は、追加文字の意味がエンコーディングごとに異なること。この名称は技術的に誤りで（これらのコードページはASCII標準の拡張ではない）、システム間での使用は安全ではない。UTF-8が現代的で可搬性のある代替であり、元の0〜127の範囲と後方互換性がある。

スペース（32）は何も表示しないのになぜ「印刷可能」と見なされるのか？

印刷行上で水平スペースを占め、文字と同じように印字ヘッドを進めるからだ。対照的に制御文字は可視出力を生成せずにデバイスの状態を変化させる（BELはビープ音を鳴らし、BSはヘッドを後退させ、LFは紙を送る）。この分類はグリフの有無ではなく、プリンター上でその文字が何をするかに基づいている。

CRとLFはキーボードのEnterキーと同じですか？

ほぼそうだが、キーボードが生成するバイトはOSに依存する。Windowsでは通常CRLFを生成し（0x0D 0x0A）、LinuxとモダンなmacOSではLFのみ（0x0A）、クラシックMac OS pre-XではCRのみ（0x0D）だ。多くのエディターはファイルの既存の改行コードまたは設定されたプロジェクトの慣例に基づいて保存時にこれを正規化する。

ファイル・グループ・レコード・ユニットセパレーターがなぜここにあるのか？

1960年代のレコード指向のテープストレージ向けに設計された。File > Group > Record > Unitの階層だ。大部分は使われなくなったが、2つの意外な場所で復活した。RFC 7464「JSON Text Sequences」（メディアタイプapplication/json-seq）がRS（0x1E）をストリーミングJSONレコードの区切りプレフィックスとして使用し、小売バーコードプロトコルのGS1アプリケーション識別子セパレーターがGS（0x1D）を使用している。

ASCIIは2026年でもまだ重要か？

非常に重要だ。「テキストベース」のあらゆる現代プロトコル（HTTPヘッダー・JSON・YAML・ソースコード・コマンドライン引数・環境変数・DNSホスト名）はASCIIの範囲内で動作する。UTF-8は任意テキストの支配的なエンコーディングだが、UTF-8の最初の128バイト値はバイトごとに正確にASCIIだ。URLエンコーディングからターミナルカラー、テキストエンコーディングのバグのデバッグまで、テーブルを知ることは今も必要だ。