
拡張ASCIIは、一般的に元の96文字のASCII文字セットに加えて最大128文字を追加した文字エンコーディングのレパートリーです。「拡張ASCII」の正式な定義はなく、この用語の使用は批判されています。 [ 1 ] [ 2 ] [ 3 ] [ a ]
ISO規格ISO 8859は、ASCII文字セットの拡張を正式に定めた最初の国際規格でした。この規格でエンコードされた多くの言語バリアントの中でも、ほとんどの西ヨーロッパ言語をサポートするISO 8859-1は、欧米ではISO Latin-1として最もよく知られています。ISO 8859以降、他にも多くの拡張ASCIIエンコーディングが登場しました。EBCDICも同様に、数十年にわたり多くの拡張バリアントを開発してきました。
現代のオペレーティングシステムはすべて、数千もの文字をサポートするUnicodeを使用しています。しかし、拡張ASCIIはコンピュータの歴史において依然として重要な位置を占めており、複数の拡張ASCII文字セットをサポートするには、後々UTF-8エンコーディング方式を容易にサポートできるようなソフトウェアの記述方法が必要でした。
ASCIIは1960年代にテレプリンターや電信、そして一部のコンピュータ向けに設計されました。初期のテレプリンターは電気機械式で、マイクロプロセッサはなく、動作に必要なだけの電気機械式メモリしか搭載していませんでした。1文字ずつ完全に処理し、処理後すぐにアイドル状態に戻るため、制御シーケンスは1文字の長さでなければならず、そのため、そのような制御用に多数のコードを確保する必要がありました。これらはタイプライターから派生したインパクトプリンターで、金属活字に鋳造された固定のグリフセットしか印刷できず、これもグリフセットを最小限に抑える要因となりました。
7 ビット ASCII は、以前の 5 ビットおよび 6 ビット コードよりも改良されました。 2 7 =128 のコードのうち、33 は制御に使用され、95 の厳選された印刷可能な文字(94 のグリフと 1 つのスペース) には、英語のアルファベット (大文字と小文字)、数字、および 31 の句読点と記号が含まれます。標準的な米国のタイプライターのすべての記号に加えて、プログラミング タスク用に選択されたいくつかの記号が含まれます。 人気のある周辺機器の中には、64 文字の印刷サブセットのみを実装したものもありました。Teletype Model 33 は、「a」から「z」または 5 つのあまり一般的でない記号 ( `、{、|、}、および~ ) を送信できませんでした。また、そのような文字を受信すると、代わりに「A」から「Z」 (すべて大文字に強制) と、ほとんど同様の他の 5 つの記号 ( @、[、\、]、および^ ) を印刷しました。
ASCII文字セットは、米国英語での使用にはかろうじて十分な大きさですが、組版でよく使われる多くのグリフが欠けており、普遍的に使用するには小さすぎます。英語以外のアルファベットの文字を直接表現するために、より多くの文字や記号、より多くの種類の句読点や間隔、より多くの数学演算子や記号(× ÷ ⋅ ≠ ≥ ≈ π など)、一部のプログラミング言語で使用される独自の記号、表意文字、表意文字、枠線描画文字など、多くの文字や記号が望ましく、有用であり、あるいは必要とされています。
世界中のコンピュータユーザーにとって最大の問題は、それぞれの地域のアルファベットのニーズでした。ASCII の英語アルファベットは、アクセント付き文字をアクセントなしで書くか、 ßの代わりにssのような 2 文字の近似文字を使用すれば、ヨーロッパの言語にほぼ対応できます。7 ビット ASCII の修正されたローカル バリアントがすぐに登場し、あまり使用されていない記号を、英国のテレタイプで#を£に、日本で\ を¥に、韓国で₩に置き換えるなど、非常に望ましい記号や文字と交換しました。少なくとも 29 のバリアント セットができました。12 のコード ポイントが少なくとも 1 つの国のセットによって変更され、82 の「不変」コードだけが残りました。しかし、プログラミング言語は置き換えられた文字の多くに意味を割り当てていたため、C の3 文字のシーケンスやなどを使用して{と}を表す回避策が考案されました。[ 4 ]基本アルファベットが異なる言語では、ラテン文字を最も近いキリル文字に置き換えるなどの翻字が用いられることがあった(その結果、英語をキリル文字で印刷した場合、またはその逆の場合、奇妙ではあるが多少読みやすいテキストができた)。また、アクセント付き文字を作成するために、2つの文字を重ねて印刷する(多くの場合、バックスペースキーを間に挟む)方法も考案された。しかし、ユーザーはこれらの妥協策に満足せず、サポートも不十分な場合が多かった。??<??>
1970年代にコンピュータと周辺機器が8ビットバイトに標準化されると、コンピュータとソフトウェアは、プログラミングにほとんど追加コストをかけずに、またストレージにも追加コストをかけずに、256文字セットを使用するテキストを処理できることが明らかになりました(ただし、各バイトの未使用の8ビット目が、エラーチェック、ブール値フィールド、8文字を7バイトにパックするなど、何らかの方法で再利用されていないことが前提です)。これにより、ASCIIをそのまま使用でき、さらに128文字を追加することが可能になりました。多くのメーカーは、ASCIIに加えて最大128個の未使用コードで構成される8ビット文字セットを考案しました。こうして、主要な西ヨーロッパ(およびラテンアメリカ)の言語すべて、そしてそれ以上の言語を網羅するエンコーディングを作成できるようになりました。
128文字が追加されても、すべての用途、すべての言語、さらにはすべてのヨーロッパ言語を網羅するにはまだ不十分だったため、多くの独自仕様および各国独自のASCII派生8ビット文字セットの出現は避けられなかった。これらのセット間の変換(トランスコーディング)は複雑であり(特に文字が両方のセットに含まれていない場合)、しばしば行われず、文字化け(判読しにくいテキスト。多くの場合、ユーザーは手動で解読する方法を習得した)が発生した。1990年代後半には、各国および国際標準化団体による協力や調整の試みが行われたが、メーカー独自のセットが依然として圧倒的に人気を博していた。これは主に、国際標準が特定の文化でよく使われる文字やその文化特有の文字を除外していたためである。
メインフレームコンピュータ[ b ]やミニコンピュータ、特に大学では、数学、科学、言語の教育を支援する必要性を満たすために、ASCIIのさまざまな独自仕様の変更や拡張が登場しました。
ヒューレット・パッカードは、ワークステーション、端末、プリンタで使用するために、1978年か1979年頃に、拡張7ビット/8ビットASCII文字セットであるHP Roman Extensionにヨーロッパ文字を追加し始めました。これは後に、広く使用されている標準的な8ビット文字セットであるHP Roman-8とHP Roman-9(および多数の派生版)へと発展しました。
AtariとCommodoreのホームコンピュータは、独自の非標準ASCII(それぞれATASCIIとPETSCII、1963年のオリジナルのASCII規格に基づく)に多くのグラフィックシンボルを追加した。
TRS -80ホームコンピュータ用のTRS-80文字セットには、低解像度のブロックグラフィックスを実装した64個のセミグラフィックス文字(0x80~0xBF)が追加されました。(各ブロックグラフィックス文字は2x3ピクセルのグリッドとして表示され、各ブロックピクセルは下位6ビットのいずれかによって実質的に制御されます。)[ 5 ]
IBMは初代IBM PCで8ビット拡張ASCIIコードを導入し、後にさまざまな言語や文化に対応したバリエーションを作成しました。IBMはこのような文字セットをコードページと呼び、自社で開発したものだけでなく、他のメーカーが開発・使用したものにも参照番号を割り当てました。そのため、文字セットはIBMコードページ番号で示されることが非常に多いです。ASCII互換コードページでは、下位128文字は標準ASCII値を維持し、上位128文字には異なるページ(または文字セット)を使用できました。例えば、北米市場向けに製造されたDOSコンピュータはコードページ437を使用しており、これにはフランス語、ドイツ語、その他いくつかのヨーロッパ言語に必要なアクセント付き文字や、いくつかのグラフィック線描画文字が含まれていました。文字セットが大きくなったことで、英語とフランス語などの言語の組み合わせで文書を作成することが可能になりました(ただし、フランス語のコンピュータは通常コードページ850を使用します)が、例えば英語とギリシャ語の組み合わせでは文書を作成できませんでした(ギリシャ語にはコードページ737が必要でした)。
Apple Computerは、 Mac OS Romanなどの独自の8ビット拡張ASCIIコードをMac OSで導入した。また、Apple LaserWriterはPostscript文字セットも導入した。
デジタル・イクイップメント・コーポレーション(DEC)は、文字数は少ないものの、文字と発音記号の組み合わせが多い多国籍文字セットを開発しました。これはVT220以降のDEC製コンピュータ端末でサポートされました。後に、この文字セットは、Lotus International Character Set(LICS)、ECMA-94、ISO 8859-1などの他の文字セットの基礎となりました。
1987年、国際標準化機構(ISO)は、8ビットASCII拡張の規格であるISO 8859を公表しました。その中で最も普及したのはISO 8859-1(「ISO Latin 1」とも呼ばれる)で、これは最も一般的な西ヨーロッパ言語に必要な文字を網羅しています。8859グループの他の規格には、ラテン文字を使用する東ヨーロッパ言語向けのISO 8859-2、キリル文字を使用する言語向けのISO 8859-5などがあります。
ISO規格が一部のベンダー固有の拡張ASCII文字セットと異なる注目すべき点の1つは、拡張ブロックの最初の32コードポイントがISO規格では制御用として予約されており、印刷可能な文字には使用できないことです。[ c ]この方針は、 ASCIIの最初の32コードポイントを占めるC0制御コードブロックを模倣したものです。この規格の側面は、他の拡張ASCIIセットではほぼ普遍的に無視されていました。
Microsoft は Windows で ISO 8859 規格を使用する予定でしたが、[ 7 ]すぐにC1 制御コードを追加の文字に置き換え、独自の Windows-1252 文字セットを作成しました。追加された文字には、カーリー引用符、エムダッシュ、ユーロ記号、 ISO-8859-15のフランス語とフィンランド語の文字が含まれていました。これは世界で最も使用されている拡張 ASCII となり、8859-1 が指定されている場合でも Web 上でよく使用されます。[ 8 ] [ 9 ]
拡張コードを含むテキストデータ(文字の並び)を正しく解釈して表示するには、テキストを読み書きするソフトウェアは、そのテキストが記述された特定のエンコーディングを使用する必要があります。間違ったエンコーディングを選択すると、文字化けと呼ばれる、しばしば著しく誤った文字が表示されます。ASCIIはすべての「拡張ASCII」エンコーディングに共通しているため、間違ったエンコーディングを使用しても、英語(またはAZのみを使用する言語)は読みやすく、数字やほとんどの句読点も正しく表示されます。
SMTPやHTTPをはじめとする多くの通信プロトコルでは、ソフトウェアが複数のエンコーディングを正しく解釈できるように、コンテンツの文字エンコーディングにIANAが割り当てた文字セット識別子を付加することが求められます。しかし、ほとんどのソフトウェアは、ユーザーが優先するエンコーディングを示すシステム設定に依存するか、あるいは想定される設定でコンパイルされます。
現代では、Unicodeが非ASCIIエンコーディングのほぼすべての用途に取って代わりました。多くのインターネット標準がISO 8859-1を使用しており、Microsoft Windows(西ヨーロッパとアメリカ大陸で使用されるほとんどの言語)がISO 8859-1の上位互換であるCP1252を使用しているため、一般的に、有効なUTF-8ではないバイトストリームはCP1252またはシステム設定になっていると想定しても問題ありません。
ブラウザがISO-8859-1を検出すると、通常はWindows-1252にデフォルト設定されます。これは、Windows-1252には32個の国際文字が多く含まれているためです。