このキーワード
友達に教える
URLをコピー

Unicodeとは?

この記事はその主題が日本に置かれた記述になっており、世界的観点から説明されていない可能性があります。ノートでの議論と記事の発展への協力をお願いします。(2018年6月)
 | この項目には、JIS X 0213:2004 で規定されている文字が含まれています(詳細)。
Unicode

文字符号化スキーム
UTF-7
UTF-8
CESU-8
UTF-16
UTF-32
UTF-EBCDIC
SCSU
Punycode (IDN/IDNA)
GB 18030
その他
UCS
マッピング
書字方向
BOM
漢字統合
UnicodeとHTML
Unicodeと電子メール
Unicodeフォント

Unicode(ユニコード)は、符号化文字集合文字符号化方式などを定めた、文字コードの業界規格である。文字集合(文字セット)が単一の大規模文字セットであること(「Uni」という名はそれに由来する)などが特徴である。

1980年代に、Starワークステーションの日本語化 (J-Star) などを行ったゼロックス社が提唱し、マイクロソフトアップルIBMサン・マイクロシステムズヒューレット・パッカードジャストシステムなどが参加するユニコードコンソーシアムにより作られた。1993年に、国際標準との一致が図られ、DIS 10646の当初案から大幅に変更されて、Unicodeと概ね互換のISO/IEC 10646が制定された。

目次

  • 1 概要
  • 2 文字集合
  • 3 文字符号化スキーム
  • 4 拡張領域
    • 4.1 サロゲートペア
    • 4.2 コーディング
    • 4.3 拡張領域に含まれる文字
  • 5 歴史
    • 5.1 ユニコードのバージョン
    • 5.2 各バージョンとその特徴
    • 5.3 構成要素のバージョン
  • 6 Unicodeの諸問題
    • 6.1 バージョンごとの非互換性
    • 6.2 日本語環境でのUnicodeの諸問題
      • 6.2.1 YEN SIGN 問題
      • 6.2.2 波ダッシュ・全角チルダ問題
  • 7 ブロックの一覧
  • 8 脚注
    • 8.1 注釈
    • 8.2 出典
  • 9 参考文献
  • 10 関連項目
  • 11 外部リンク

概要

Unicode は世界で使われる全ての文字を共通の文字集合にて利用できるようにしようという考えで作られ、UnixWindowsmacOSPlan 9Javaなどで利用されている。

Unicodeでは、文字集合中の文字をあらわす符号位置(コードポイント、符号点を参照)に、「Unicodeスカラ値」という非負整数値が割り振られている。Unicodeスカラ値を文章中などに記す場合などは "U+" の後に十六進法でその値を続けることで表す。BMP(Basic Multilingual Plane, 基本多言語面)内の符号位置は U+0000 〜 U+FFFF の4桁(16ビット)で表すことができ、SMP(Supplementary Multilingual Plane, 追加多言語面もしくは補助多言語面)以降は U+10000 〜 U+10FFFF の5桁または6桁(最大21ビット)を必要とする。

収録されている文字は、各国で標準として規定されている文字集合や実際に使用されている文字を持ち寄り、委員会により取捨選択されている。日本の文字については当初より JIS X 0201JIS X 0208補助漢字を、Unicode 3.1 では JIS X 0213 の内容も収録している。

また収録において、元の各文字集合内で分離されている文字は尊重するが、異なる文字集合に同一の文字が収録されているとみなされるものは、同じ符号位置に割り当てる方針を取っている。この際に集合が膨大であるという理由で、漢字について、中国日本韓国の各規格の漢字を統合CJK統合漢字としたことは大きな議論となった。

Unicodeでは文字符号化方式も標準化したため、従来見られたShift JISEUC-JPとの間の混乱のようなものは回避されている。

Unicode以前の文字コードとの相互運用性もある程度考慮されており、歴史上・実用上の識別が求められる場合には互換領域がとられ、元のコード→Unicode→元のコードというような変換(ラウンドトリップ変換)において、元通りに戻るよう配慮されている文字もある。しかし、正規のJIS X 0208の範囲内であればトラブルは少ないが、複数の文字集合が混在したり、Shift JISの実態であるCP932EUC-JPの亜種であるCP51932とeucJP-MSなど、対応が違うために文字化けを起こすことがある。

文字集合

Unicodeでは、符号位置の連続する範囲をブロックと呼び、名前が付けられている。 Unicodeに収録されている文字については、後節「ブロックの一覧」を参照。

文字符号化スキーム

ISO/IEC 10646#文字符号化方式」も参照

Unicodeでは文字符号化方式を「文字符号化スキーム」(Character Encoding Scheme) と言う。

UTF-7
詳細は「UTF-7」を参照
UTF-16(後述)で表したUnicodeをBase64で変換して表す符号化方式。ただし、ASCIIのアルファベット範囲等についてはBase64に変換しない等、特殊な符号化スキームを行う。RFC 2152で定められており、Unicode標準及びUnicodeの関連仕様には含まれない。かつてのSMTP等のように、7ビット単位でしかデータを扱えない通信方式を利用する場合を想定して作られている。ステートフルエンコーディングであり、運用上問題が多いため、現在ではこの方式は推奨されていない。Unicode文字を7ビット単位伝送通信にどうしても通さなければならない場合は、替わりにUTF-8をQuoted-printableあるいはBase64で変換するなどの方式が好ましい。
UTF-8
詳細は「UTF-8」を参照
可変長(1-4バイト)の8ビット符号単位で表現する文字符号化形式及び文字符号化スキーム。ASCIIに対して上位互換となっており、文字の境界が明確である、UTF-16符号化スキームやUTF-32符号化スキームとの変換・逆変換に際して乗除算などの高負荷処理が必要ない、などの特長を持ち、インターネットではもっとも一般的に利用されている。
なお、UTF-8はもともと8ビットを符号単位とするためBOM(バイト順マーク;後述)は必要ないが、UTF-8であることが識別できるよう、データストリームの先頭に EF BB BF(U+FEFFのUTF-8での表現)の3バイトが付与されることがある。UTF-8のBOMはバイト順を表すものではなく、UTF-16符号化スキーム等における「真の意味でのBOM」と同じコードポイントを利用しているがゆえに慣用的にこう呼ばれているに過ぎない。
UTF-16
詳細は「UTF-16」を参照
BMP文字を16ビット符号単位一つで、その他の文字をサロゲートペア(代用対)という仕組みを使い16ビット符号単位二つで表現する文字符号化形式及び文字符号化スキーム。UCS-2ともBMPの範囲で互換性がある。
UTF-16符号化スキームでは、通常はファイルの先頭にバイト順マーク (BOM) が付与される。BOMとは、通信やファイルの読み書き等、8ビット単位の処理でバイト順を識別するための印であり、データストリームの先頭に付与される。値はU+FEFF。システムが読み込んだ先頭2バイトが FF FEならリトルエンディアン、FE FFならビッグエンディアンとして後に続く文書を処理する。
RFC 2781 ではBOMが付いていないUTF-16文書はビッグエンディアンとして解釈することになっている。Windowsのメモ帳で作成した「Unicodeテキスト」はBOMが付与されるようになっている。ビッグエンディアンの符号化スキームをUTF-16BEリトルエンディアンの符号化スキームをUTF-16LEとして区別することもある。プロトコルもしくはアプリケーションの設定などの手段で符号化スキームにUTF-16BEUTF-16LEを指定している場合にはBOMを付与することは許容されない(BOMの符号位置はZERO WIDTH NON-BREAKING SPACEとみなす)。Windows上の文書における「Unicodeテキスト」は特に明記のない場合、リトルエンディアンのUTF-16符号化スキームのことを指す。TCP/IPネットワークでは、プロトコルヘッダやMIME等の手段で符号化スキームが指定されずBOMも付与されない場合、ビッグエンディアンとして扱うと決められている(→ エンディアン)。
UTF-32
詳細は「UTF-32」を参照
Unicodeのすべての符号位置を単一長の符号単位として32ビットで表現する文字符号化形式及び文字符号化スキーム。実際に使われるのは21ビット(Unicodeの符号空間がU+10FFFFまでであるため)であり、この21ビットの範囲内ではUCS-4と互換性がある。
UTF-32符号化スキームでもUTF-16符号化スキームと同じく、ビッグエンディアンリトルエンディアンが存在し、それぞれUTF-32BEUTF-32LEと呼ばれる。プロトコルもしくはアプリケーションの設定などの手段で符号化スキームにUTF-32BEUTF-32LEを指定している場合にはBOMを付与することは許容されない(BOMの符号位置はZERO WIDTH NON-BREAKING SPACEとみなす)。
単純な符号化スキームであるが、テキストファイルなどではファイルのサイズが大きくなる(すべてBMPの文字からなる文章の場合はUTF-16符号スキームの2倍、すべてASCII文字の場合はASCII/UTF-8の4倍のサイズとなる)ため、ストレージ用として使われることは稀である。そのためか、Microsoft Officeでの「エンコードされたテキストファイル」の読み書きでは、Office 2016 でもいまだに符号化スキームには対応していない。フリーウェアシェアウェアテキストエディタのうち多数の符号化スキームに対応しているものでも、この符号化スキームには対応していないものが存在する。
ただし、すべてのUnicode文字を処理する場合には、すべての文字を単一の符号単位で表現したほうが処理に適するため、内部の処理ではUTF-32符号化形式(あるいはUCS-4)で扱うこともある。実例として、Linux 上のC言語環境では wchar_t は32ビット整数型である。
UTF-16符号化スキームなどと同様にUTF-32符号化スキームにもBOMがあり、データストリームの先頭に付される。先頭の4バイトがFF FE 00 00ならリトルエンディアン、00 00 FE FFならビッグエンディアンになる。UTF-16のリトルエンディアンとUTF-32のリトルエンディアンは最初の2バイトが等しいため、4バイトまで読んで判断する必要がある。


以下はエイプリルフールに公開されたジョークRFCである (RFC 4042)。UTF-9に関しては同名の規格が実際に検討されていた(ただし、内容は大きく異なる)が、ドラフト段階で破棄されているため重複にはならない。

UTF-9
可変長の9ビット符号単位で表現する符号化方式。1バイト8ビット(オクテット)ではなく9ビット(ノネット)であるような環境での利用を想定している。UTF-8と比較した場合、Latin-1領域が1バイト、CJK統合漢字領域が2バイトで表現できる特長があり、データ量が少なくなる。ワード長が9の倍数のコンピュータ(PDP-10ACOS-6など)であれば計算コストも低い。
UTF-18
Unicode符号位置を単一の18ビット符号単位で表現する符号化方式。UTF-8に対するUTF-16のようなものだが、RFC公開時点のUnicodeで文字が定義されていた4つの(BMP、U+1xxxx、U+2xxxx、U+Exxxx)を余った2ビットで識別するため、代用符号位置は使わない。

以下はドラフト段階で破棄された規格案。

UTF-5
国際化ドメイン名での利用を想定し、0-9、A-Vの32文字で表現する文字符号化スキーム。国際化ドメイン名にはPunycodeが採用されたため、利用されていない。
UTF-9
可変長(1-5バイト)の8ビット符号単位で表現する文字符号化形式または文字符号化スキーム。ISO-8859-1に対して一部互換である。しかし、UTF-8が普及しつつあり、それと比べて欠点がいくつかあったため、破棄された。

拡張領域

サロゲートペア

1980年代の当初の構想では、Unicodeは16ビット固定長で、2 = 65,536 個の符号位置に必要な全ての文字を収録する、というもくろみであった。しかし、Unicode 1.0公表後、拡張可能な空き領域2万字分を巡り、各国から文字追加要求が起こった。その内容は中国、日本、台湾、ベトナム、シンガポールの追加漢字約1万5千字、古ハングル約5千字、未登録言語の文字などである。このようにしてUnicodeの、16ビットの枠内に全世界の文字を収録するという計画は早々に破綻し、1996年のUnicode 2.0の時点で既に、文字集合の空間を16ビットから広げることが決まった。この時、それまでの16ビットを前提としたシステム(たとえばJavaのchar型や、Windows NTWindows 95のAPI)をなるべくそのままにしたまま、広げられた空間にある符号位置を表現する方法として、サロゲートペアが定義された。

サロゲートペアは16ビットUnicodeの領域1024文字分を2つ使い(前半 U+D800 〜 U+DBFF、後半 U+DC00 〜 U+DFFF)、各々1個ずつからなるペアで1024 × 1024 = 1,048,576文字を表す。これはちょうど16面ぶんであり、第1面〜第16面(U+10000 〜 U+10FFFF)の文字をこれで表すこととした。加えて第0面(基本多言語面)も使用可能なので、Unicodeには合計で 1,048,576 + 65,536 - 2,048 = 111万2,064文字ぶんの空間が確保されたことになる。

サロゲートはUnicodeの符号位置の U+10000 〜 U+10FFFF の範囲を16ビットユニットのペア(2つ)で表現する集合で、最初の16ビットユニットを high surrogate、二番目を low surrogate と称する。high surrogates は U+D800 〜 U+DBFF の範囲、low surrogates は U+DC00 〜 U+DFFF の範囲である。

コーディング

サロゲートのエンコーディングは、

       $hi = ($uni - 0x10000) / 0x400 + 0xD800;
       $lo = ($uni - 0x10000) % 0x400 + 0xDC00;

デコードディングは、

       $uni = 0x10000 + ($hi - 0xD800) * 0x400 + ($lo - 0xDC00);

となる。

コード変換例:

U+10437(

・・・・・・・・・・・・・・・・・・
出典:wikipedia
2018/09/08 05:31

HAPPY Wikipedia

あなたの考える「Unicode」の意味を投稿しよう
「Unicode」のコンテンツはまだ投稿されていません。
全部読む・投稿 

Unicodeスレッド一覧

・・・・・・・・・・・・・・・・・・
「Unicode」のスレッドを作成する
Unicodeの」
友達を探す
掲示板を探す
このページ
友達に教える
URLをコピー

注目のキーワード

錦織圭/北島康介/2014_FIFAワールドカップ・アジア予選/サッカー日本女子代表/消費税/東京スカイツリー/ダルビッシュ有/イチロー/香川真司/野田内閣/復興庁/石川遼/HKT48/AKB48/ワールド・ベースボール・クラシック日本代表/黒田博樹/尖閣諸島/バレンタインデー/ONE_PIECE

キーワードで探す

 
友達を探す
掲示板を探す
無料コミックを探す
占い・診断
着メロを探す
GAMEを探す
デコメを探す
きせかえツールを探す
FLASH待ち受けを探す
ハッピーWiki
ハッピーメール
ハッピーランド
HAPPY NEWS
2010Happy Mail