Loading article…
ユニバーサル符号化文字セット（UCS、Unicode）は、国際規格ISO / IEC 10646「情報技術 - ユニバーサル符号化文字セット（UCS）」 （およびその規格への修正）で定義された標準文字セットであり、多くの文字エンコーディングの基礎となっており、これまで表現されていなかった文字体系の文字が追加されるにつれて改善されています。[ 1 ]
UCSには110万を超えるコードポイントが使用可能/割り当て可能ですが、2000年以前には、基本多言語面（BMP）である最初の65,536のみが一般的に使用されていました。この状況は、2006年に中華人民共和国（PRC）が、管轄区域内で販売されるすべてのソフトウェアはGB 18030をサポートしなければならないと決定したことで変化し始めました。これにより、PRCで販売されるソフトウェアはBMPを超える必要が生じました。[ 2 ]
このシステムは、BMPにおいても、意図的に多くのコードポイントを文字に割り当てられないままにしています。これは、将来の拡張を可能にするため、あるいは他のエンコーディング形式との競合を最小限に抑えるためです。
UCSの初版では、UCS-2の拡張であるUTF-16が、BMP外のコードポイントを表すために定義されました。BMPのS（特殊）ゾーンにあるコードポイントの範囲は、文字に割り当てられていません。UCS-2ではこれらのコードポイントにコード値を使用することは許可されていませんが、UTF-16ではペアでの使用が許可されています。UnicodeもUTF-16を採用しましたが、Unicodeの用語では、上位半分のゾーン要素は「上位サロゲート」、下位半分のゾーン要素は「下位サロゲート」となります。
別のエンコーディング方式であるUTF-32（以前はUCS-4と呼ばれていた）は、コード空間の1文字をエンコードするために4バイト（合計32ビット）を使用します。これにより、UTF-32は（2024年時点において）APIおよびソフトウェアアプリケーション内のすべてのコードポイントをバイナリ形式で表現することを可能にします。
国際標準化機構（ISO）は1989年に世界共通の文字セットの策定に着手し、1990年にISO 10646の草案を公表した。ヒュー・マクレガー・ロスはその主要な立案者の一人であった。
この研究は、1987年からゼロックスとアップルによって開発されてきたUnicode規格の開発とは独立して行われた。
ISO 10646の原案は、現行規格とは大きく異なっていた。原案では以下のように定義されていた。
合計で 2,147,483,648 文字になるように見えるが、実際には、グループ、プレーン、行、セルを指定する4 バイトのいずれかに、 C0 および C1 制御コード( 16 進表記で 0x00 ～ 0x1F および 0x80 ～ 0x9F ) のバイト値を使用することをポリシーで禁止していたため、標準では 679,477,248 文字しかコード化できなかった。たとえば、ラテン語の大文字 A は、グループ 0x20、プレーン 0x20、行 0x20、セル 0x41 に位置していた。
この初期のISO/IEC 10646規格の文字を符号化する方法は、次の3つのいずれかである。
そのため、1990年当時、ユニバーサル文字セットに関する2つの構想が存在していました。1つはUnicodeで、各文字に16 ビットが割り当てられ（65,536文字が使用可能）、もう1つはISO/IEC 10646です。ソフトウェア企業はISO規格の複雑さとサイズ要件を受け入れることを拒否し、多くのISO国内機関に反対票を投じるよう説得することに成功しました。ISOの担当者は、現状のままでは規格のサポートを継続できないと認識し、Unicodeとの統合に向けて交渉を行いました。その結果、2つの変更が行われました。1つは文字数の制限（制御コード値の禁止）が撤廃され、コードポイントの割り当てが可能になったこと、もう1つは基本多言語面の文字レパートリーがUnicodeの文字レパートリーと同期されたことです。
一方、時が経つにつれ、Unicode規格自体にも変化が生じました。65,536文字では不十分であることが明らかになり、バージョン2.0以降の規格では、UTF-16サロゲートメカニズムによって17プレーンから1,112,064コードポイントのエンコードがサポートされるようになりました。そのため、ISO/IEC 10646はUTF-16でエンコードできる文字数に制限され、6億7,900万文字以上ではなく、100万文字強に制限されました。ISO/IEC 10646のUCS-4エンコーディングは、UTF-16の範囲に制限され、UTF -32という名前でUnicode規格に組み込まれましたが、プログラムの内部データ以外ではほとんど使用されていません。
Plan 9オペレーティングシステムの設計者であるロブ・パイクとケン・トンプソンは、7ビットASCIIとの下位互換性も備えた、高速で優れた設計の新しい混合幅エンコーディングを考案しました。これはUTF-8と呼ばれるようになり[ 3 ]、現在最も普及しているUCSエンコーディングです。
ISO/IEC 10646とUnicodeは、文字レパートリーと番号が同一です。つまり、同じ番号を持つ同じ文字が両方の規格に存在しますが、Unicodeはより頻繁に新しいバージョンをリリースし、新しい文字を追加しています。Unicodeには、ISO/IEC 10646の範囲外の規則と仕様があります。ISO/IEC 10646は、ISO/IEC 8859などの以前の規格を拡張した単純な文字マップです。一方、Unicodeは、照合、形式の正規化、アラビア語やヘブライ語などの右から左に書く文字のための双方向アルゴリズムに関する規則を追加しています。特に双方向文字を使用するプラットフォーム間の相互運用性を確保するには、ISO/IEC 10646をサポートするだけでは不十分であり、Unicodeを実装する必要があります。
これらの規則とアルゴリズムをサポートするために、Unicodeは、文字のデフォルトの双方向クラスを決定するプロパティや、文字が他の文字とどのように結合するかを決定するプロパティなど、セット内の各文字に多くのプロパティを追加します。文字がヨーロッパ数字の「8」や分数の「¼」などの数値を表す場合、その数値も文字のプロパティとして追加されます。Unicodeは、これらのプロパティによって、複数の言語が混在するテキストの相互運用性をサポートすることを意図しています。
一部のアプリケーションはISO/IEC 10646文字をサポートしていますが、Unicodeを完全にサポートしているわけではありません。そのようなアプリケーションの1つであるXtermは、文字とグリフが1対1で対応し、方向性が1つだけのISO/IEC 10646文字をすべて正しく表示できます。単純な重ね打ち方式で一部の結合記号を処理できますが、ヘブライ語（双方向）、デーヴァナーガリー文字（1文字が複数のグリフに対応）、アラビア語（両方の機能を持つ）は表示できません。ほとんどのGUIアプリケーションは、このようなスクリプトを処理する標準のOSテキスト描画ルーチンを使用していますが、アプリケーション自体が常に正しく処理できるとは限りません。
ISO/IEC 10646 は、ISO/IEC 10646 規格群の一般的な非公式な引用であり、ほとんどの文章で使用できます。また、Unicode は別の規格ですが、 UCS について議論する際にも、非公式にUnicodeという用語がよく使われます。ただし、UCS を出版物として参照する場合は、ISO/IEC 10646:{年} の形式で発行年を明記する必要があります。例えば、ISO/IEC 10646:2014 のように記述します。
1991年以来、UnicodeコンソーシアムとISO / IECは、 Unicode標準（「Unicode」）とISO/IEC 10646を並行して開発してきました。Unicodeバージョン2.0の文字レパートリー、文字名、およびコードポイントは、最初の7つの改訂版を含むISO/IEC 10646-1:1993と完全に一致しています。2000年2月にUnicode 3.0が発行された後、対応する新規および更新された文字がISO/IEC 10646-1:2000を通じてUCSに追加されました。2003年には、ISO/IEC 10646のパート1とパート2が1つのパートに統合され、それ以来、Unicode標準とほぼ同期して、標準に文字を追加する多数の改訂が行われています。