ISO/IEC 8859
ISO 8859(より正式にはISO/IEC 8859)はコンピュータでの利用を目的とした8ビット文字コードの標準である。ISOとIECが合同で定めた。この標準は複数の部(part)に分かれており、それぞれがISO/IEC 8859-1、ISO/IEC 8859-2などのように番号付きで出版されている。それぞれの部自体を、非公式に標準として参照することがある。2009年現在、15の部(破棄されたISO/IEC 8859-12標準を除く)が存在する。
ASCIIの印字可能文字のビットパターンは95個ある。これは現代英語の情報交換には十分だが、ラテン文字を使う他の言語のほとんどでは、ASCIIに含まれない文字をさらに追加する必要がある。たとえば「ß」(ドイツ語)、「ñ」(スペイン語)、「å」(スウェーデン語と他の北ゲルマン語群)などである。ISO 8859では、8ビットバイトの第8ビットを使ってさらに128文字分の領域を確保することで、この問題を改善することを目指している(第8ビットはかつて、データ伝送手順の情報に使われる以外は、未使用のままだった)。しかし、単一の8ビット文字コードで収容できる以上の文字が必要になったため、ラテン文字を含めるのに必要な最低10個をはじめ、複数のマッピングが開発された。
ISO 8859-n符号化は印字可能文字のみを含み、未割り当ての符号位置にマップされる制御文字と組み合わせて使うように設計されていた。この目的のためにIANAが登録した一連の文字コードは、ISO 646からC0制御集合(符号位置0から31にマップされる制御文字)を、ISO 6429からC1制御集合(符号位置127から159にマップされる制御文字)を追加し、その結果完全な8ビット文字マッピングのほとんど(ないしはすべて)に文字を割り当てている。これらの集合はその推奨MIME名(推奨MIME名が規定されていない場合その正式名称)としてISO-8859-nという名前を持つ。多くの人が、用語ISO 8859-nとISO-8859-nを同等な意味を持つものとして用いる。ISO 8859-11はTIS-620とほとんど同じであるためか、このようなキャラクタセット名を割り当てられていない。
ISO 8859標準はタイポグラフィのためではなく、信頼性の高い情報交換のために設計されている。この標準は高品質のタイポグラフィに必要な文字(たとえば必須でない合字、左右の区別のある引用符、ダッシュなど)を省略している。その結果、高品質の電子組版のためのシステムでは、しばしばASCIIとISO 8859標準と相互交換のできないあるいは独自の拡張をほどこして使用したり、Unicodeを代わりに使ったりしている。
おおざっぱに言って、ある文字や記号がすでに広く使われているデータ処理文字集合の一部でなく、なんらかの言語用のタイプライタの鍵盤でも通常は提供されていない場合、その文字や記号は採用されていない。それゆえいくつかのヨーロッパ言語で使われている向きのある二重引用符「«」と「»」は含まれたが、英語などいくつかの言語で使われる向きのある二重引用符「“」と「"」は含まれなかった。フランス語の「œ」と「Œ」は「oe」、「OE」とタイプできるため採用されなかった。「Ÿ」はテキストがすべて大文字でも必要とされるが、省略された。しかしながら、これらの文字は最近のISO 8859-15で新しいユーロ記号 € の導入に際して含められることになった。同様にオランダ語の 'ĳ' と 'Ĳ' の文字も収録されなかった。オランダ語話者は、代わりにこれらを2文字でタイプしてきたからである。ルーマニア語の「Ș/ș」と「Ț/ț」(コンマアクセント付きの文字)も最初は収録されなかった。これらの文字は当初「Ş/ş」と「Ţ/ţ」(セディーユ付きの文字)に統合されていたためである。ユニコードコンソーシアムは、下付きコンマの字形はセディーユの字形のグリフ変種であると考えてきた。しかしながら、後にUnicode標準とISO 8859-16でも、下付きコンマを区別して追加した。
ISO 8859エンコーディングのほとんどで、各種のヨーロッパ言語で必要なダイアクリティカルマーク付き文字を提供している。そうでないものは非ラテン文字を提供しているもの(ギリシア文字、キリル文字、ヘブライ文字、アラビア文字、タイ文字)である。エンコーディングのほとんどは前進文字のみを含むが、ヘブライ文字とアラビア文字のものは結合文字をも含んでいる。しかしながら、この標準は東アジア言語(CJK)用の用字系は何も提供していない。それらの漢字系書記体系には数千もの符号位置が必要だからである。ベトナム語はラテン文字ベースの文字を使うが、96個の位置には(結合ダイアクリティカルマークを使わない限り)やはりおさまらない。日本語の音節文字(ひらがなとカタカナ、仮名を参照)のそれぞれは収まるが、ISO 8859では符号化されていない。また世界の他の表音文字も符号化されていない。
ISO 8859は以下の部に分かれている:
ISO 8859の各部はしばしば、互いに借用し合っている言語に対応するよう設計されているので、各言語で必要とされる文字は、通常は1つの部に収容されている。しかしながら、文字と言語の組み合わせによっては転写なしでは収容できない。そのため、変換を可能な限りスムーズにしようとする努力がなされてきた。たとえば、ドイツ語はその7つの特殊文字をすべてのラテン変種 (1-4, 9-10, 13-16) で同じ符号位置に持ち、多くの符号位置で文字のセット間の違いはダイアクリティカルマークにのみ存在する。とくに、1-4の変種は共同で設計され、ある特定の符号化文字は特定の1位置に出現するか、あるいはまったく出現しないという特性を持つ。
どの部でも位置 0xA0 には必ずノーブレークスペースが存在し、0xAD にはほとんどの部でソフトハイフンが存在する。これらの位置には改行のみを示している。他の空のフィールドは未割り当てであるか、使用しているシステムが表示できないかのいずれかである。
ISO/IEC 8859-7:2003とISO/IEC 8859-8:1999の版で新規追加された文字がある。LRMはleft-to-right mark (U+200E) の頭字語で、RLMはright-to-left mark (U+200F) の頭字語である。
1991年から、Unicode Consortiumは、ISOと協力してUnicode標準とISO/IEC 10646: 国際符号化文字集合 (UCS) を開発する作業をしてきた。この2つの標準が作成された目的の1つは、各文字に (当初は) 16ビットの符号値を割り当てることによって ISO 8859の文字レパートリを統合することであった。いくつかの符号値は未割り当てのまま残った。時を経て、それらのモデルは文字を固定ビット幅の値よりむしろ抽象的な数値の符号値にマップするよう再構成された。その結果、より多くの符号位置と符号化法に対応できるようになった。
UnicodeとISO/IEC 10646は現在、100万を超える符号空間におよそ100,000の文字を割り当て、すべての利用可能な符号位置を表現できるいくつかの標準エンコーディングを定義している。UnicodeとUCSの標準エンコーディングは1つから4つの8ビット符号値の並びを使用する (UTF-8) か、1つか2つの16ビット符号値を使用する (UTF-16) か、1つの32ビット符号値を使用する(UTF-32もしくはUCS-4)。1つの16ビット符号値を使用して利用可能な符号位置の17分の1だけを表現可能なより古いエンコーディング (UCS-2) も存在する。これらの符号化形式のうち、UTF-8のバイト並びのみが固定された順序を持っている。他のものは特殊な符号化帯域外の手段で解決される、プラットフォーム依存のバイト順序の問題がある。
より新しいバージョンのISO 8859は文字をそのUnicode/UCS名称とU+nnnn記法で表現している。これは事実上、ISO 8859の各部をUCSの非常に小さな部分集合から単一の8ビットバイトに写像する、Unicode/UCSの符号化方式の1つになったに等しいと言えよう。UnicodeとUCSの最初の256文字はISO-8859-1の文字と同じである。
ISO 8859の部やその派生を含む1バイトキャラクタセットは、安定していてソフトウェアへの実装が簡単であるという利点から、1990年代を通じて好んで使われてきた。つまり、1バイトと1文字が等価であるという単純な構造であるため、ほとんどの単一言語アプリケーションにとっては十分実用になるいっぽう、結合文字や字形の変化がない。
1文字に複数バイトを使用するためには比較的多くのコンピュータ資源が必要だが、これが減少し始めたため、プログラミング言語とオペレーティングシステムはそのシステムのコードページに加え、Unicodeのネイティブサポートを追加した。Windows NTはきわめて早期にUnicodeを導入した。しかしながら、Windows 9xのUnicodeサポートは特殊な互換レイヤをリンクするか、Windows APIのきわめて限られたサブセットのみを使って設計する必要があったため、Unicodeはほとんど使われることがなかった。Unicode対応オペレーティングシステムが広まるにつれ、ISO 8859や他のレガシーエンコーディングは人気を失っていった。ISO 8859と1バイト文字モデルの残存勢力が、多くのオペレーシングシステム、プログラミング言語、データ格納システム、ネットワークアプリケーション、表示ハードウェア、エンドユーザアプリケーションソフトウェアの奥深くに残っているが、昨今のコンピュータアプリケーションはほとんどがUnicodeを内部的に使用しており、他のエンコーディングとの相互変換が必要な場合には変換テーブルに頼っている。
ISO/IEC 8859標準はISO/IEC第1合同技術委員会 (JTC 1) 第2小委員会 (SC 2) 第3作業部会 (WG 3) によって保守されていた。2004年6月、WG 3は解散し、保守業務は SC 2 に転送された。小委員会に唯一残っている作業部会であるWG 2はISO/IEC 10646の開発に専念しているため、現在ISO/IEC 8859標準は更新されていない。