Unicodeのまとめ情報

Unicode』の解説

thumb

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

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

概要

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に収録されている文字については、後節「ブロックの一覧」を参照。

文字符号化スキーム

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

UTF-7
UTF-16(後述)で表したUnicodeをBase64で変換して表す符号化方式。ただし、ASCIIのアルファベット範囲等についてはBase64に変換しない等、特殊な符号化スキームを行う。RFC 2152で定められており、Unicode標準及びUnicodeの関連仕様には含まれない。かつてのSMTP等のように、7ビット単位でしかデータを扱えない通信方式を利用する場合を想定して作られている。ステートフルエンコーディングであり、運用上問題が多いため、現在ではこの方式は推奨されていない。Unicode文字を7ビット単位伝送通信にどうしても通さなければならない場合は、替わりにUTF-8をQuoted-printableあるいはBase64で変換するなどの方式が好ましい。
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
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
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ビット固定長で、216 = 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(𐐷: DESERET SMALL LETTER YEE, IPA: /j/)のエンコードを考えてみる。

0x10437(1 0000 0100 0011 0111)から0x10000(1 0000 0000 0000 0000)を引くと、

結果は0x00437(0000 0000 0100 0011 0111)となる。

これを上位10ビット値と下位10ビット値に分割する。

00 0000 0001(⇒ 0x400に相当) + 00 0011 0111(0x037)

ハイ(高位)サロゲートを形成するために上位ビットに0xD800を加える。

0x0001 + 0xD800 = 0xD801。

ロー(下位)サロゲートを形成するために下位ビットに0xDC00を加える。

0x0037 + 0xDC00 = 0xDC37。

結果:

D801 DC37 (UTF-16 hex code units)

D8 01 DC 37(UTF-16BE hex bytes)

01 D8 37 DC(UTF-16LE hex bytes)

次の表は、この文字変換と他をまとめたものである。 色は、コードポイントからのビットがUTF-16バイトにどのように分配されるかを示した。 なお、UTF-16エンコーディングプロセスによって追加された追加ビットは黒で示されている。

厳密には正確ではないが、UTF-16UCS-2をサロゲートペアで拡張したようなものであると言える。またUnicodeは(現在のところ)UCS-4のうち、サロゲートペアで表現可能な空間のみを使うものとし(異体字セレクタなどは空間を別の軸の向きに広げるものとされている)ISO/IEC 10646もUnicodeに追随するような形で改訂されている。

サロゲートペアによって拡張された符号位置は、UTF-32ではそのまま表現できる。UTF-8では、通常4オクテット(Fx xx xx xx)を使って表現される。UTF-16ではサロゲートペアを使って表現する。UTF-8を使っているが4オクテット以上のオクテット列を扱えない場合に、サロゲートペアをそのままUTF-8で表現したような表現が使われることがあり、CESU-8と言う(詳しくはUTF-8#サロゲートペアの扱いを参照)。

サロゲートペア (Surrogate Pair) の日本語訳は代用対とされている。

拡張領域に含まれる文字

現在、拡張領域には次のように文字が割り当てられている。

日本では2000年にJIS X 0208を拡張する目的でJIS X 0213(いわゆるJIS第3・第4水準)が制定されたが、この際、新たに採用された文字でUnicodeになかったものの一部は、BMPに収録できず、第2面への収録となった(Unicodeが最終的にJIS X 0213への対応を完了したのは2002年である)。このため、JIS X 0213収録文字をUnicodeで完全にサポートするには、追加漢字面をサポートしたOSフォントアプリケーションが必要となる。Shift_JISなど、Unicodeにて規定されるもの以外のエンコーディングを利用する場合であっても、JIS X 0213に対応するフォントやアプリケーションが必要である。

常用漢字2010年改定で追加された字のうち「」はU+20B9Fで、追加漢字面に含まれる。そのため、改定後の常用漢字完全サポートを謳う場合、Unicodeに対応していて更にこの拡張領域にも対応している必要があると言える。ただ、現状ではこの字は、JIS X 0208に含まれる(=当然、Unicode策定当初からBMPに収録されている)異体字の「叱」(U+53F1) で代用されることが多い。

歴史

1984年、ISOの文字コード規格委員会 (ISO/TC 97/SC2) は文字セットの切り替えを行わずに世界中の文字を単一の文字集合として扱える文字コード規格 (ISO 10646) を作成することを決定し、専門の作業グループ (ISO/TC 97/SC 2/WG 2) を設置し、作業を始めていた。1980年代後半にはこの作業グループにおいてさまざまな提案が検討されている。1990年になって出来あがったISO/TC 97/SC 2/WG 2作成のISO 10646の初版ドラフト(DIS 10646#DIS 10646第1版)では、漢字コードは32ビットで表現され、各国の漢字コードはそのまま入れることになった。しかし中国は漢字を各国でばらばらに符号化するのではなく、あくまで統一して扱うことを求めてこのドラフトには当初から反対しており、今後の漢字コードの方針を決めるため、WG 2は CJK-JRG (Joint Research Group) と呼ばれるグループを別途設置し、そこで引き続き検討することにした。

このような公的機関の動きとは別に、1987年頃からXeroxのJoe BeckerとLee Collinsは、後にユニコードと呼ばれるようになる、世界中の文字を統一して扱える文字コードを開発していた。1989年9月には「Unicode Draft 1」が発表された。ここではその基本方針として、2オクテット(16ビット)固定長で全ての文字を扱えることを目指しており、そのために日本・中国・韓国の漢字を統一することで2万弱の漢字コードを入れ、さらに将来の拡張用に、3万程度の漢字の空き領域が別に用意されていた。このドラフトは少しずつ改良を加えられながら1990年4月にUnicode Draft 2、同年12月Unicode Final Draftとなった。さらに1991年1月にはこのUnicode Final Draftに賛同する企業によって、ユニコードコンソーシアムが設立された。

1991年6月、ISO/IEC 10646による4オクテット固定長コードを主体としたドラフト「DIS 10646第1版」は、2オクテット固定長コードであるUnicodeとの一本化を求める各国により否決され、ISO 10646とUnicodeの一本化が図られることになった。また中国およびUnicodeコンソーシアムの要請により、CJK-JRGにおいて、ISO 10646とUnicodeの一本化が図られることになった。CJK-JRGは各国の漢字コードに基づき独自の統合規準を定め、ISO 10646 / Unicode用の統合漢字コード表を作成することになった。CJK-JRGの会合は第1回が7月22日から24日にかけて東京で、第2回の会合が9月17日から19日にかけて北京で、第3回が11月25日から29日にかけて香港で開催された。これらの討議の結果、1991年末になって「ISO 10646=Unicode」用の統合漢字コード表が Unified Repertoire and Ordering (URO) の第1版として完成した。

Unicodeの最初に印刷されたドキュメントであるUnicode 1.0は、統合漢字表の完成に先行して漢字部分を除いたUnicode 1.0, Vol.1が1991年10月に出版され、後に1992年になって漢字部分だけのUnicode 1.0, Vol.2が出版された。

1992年、CJK統合漢字URO第二版が完成し、これを取り込んだ(ただし、UROには若干の間違いが発見されており、それらの修正が行われている。)DIS 10646第2版が、5月30日の国際投票で可決された。

1993年5月1日 「ISO/IEC 10646-1: 1993 Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and basic Multilingual Plane」が制定される。同年翌6月にUnicode 1.0は ISO/IEC 10646-1:1993にあわせた変更を行いUnicode 1.1となり、以後ユニコードとISO/IEC 10646とは歩調を合わせて改訂されていくことになる。

ユニコードのバージョン

ユニコードのバージョンは、メジャーバージョン (the major version)、マイナーバージョン (the minor version)、アップデートバージョン (the update version) の3つの部分から構成され、ピリオドでつなげて表示される。ただし、マイナーバージョン及びアップデートバージョンについては0の場合には省略して表示されることもある。メジャーバージョンはレパートリーの追加のような重要な変更が行われたときに改定される。ユニコードのドキュメントは書籍形態と電子版ドキュメント形態の両方で公表され、どちらもユニコードについての正式なドキュメントであるとされている。新たなバージョンがリリースされたときは新たなドキュメントが公表されるが、書籍として刊行されるのはメジャーバージョンが改定された場合および重要なマイナーバージョンの改定があった場合のみである。書籍版のバージョン1.0は、2巻に分けて刊行され、統合漢字部分を除いた第1巻は1991年10月に、統合漢字部分の第2巻は1992年6月に刊行された。そのため第1巻のみのものをUnicode 1.0.0、第2巻を含めたものをUnicode 1.0.1と呼ぶことがある。

各バージョンとその特徴

ユニコードのそれぞれのバージョン番号とその制定年月日、収録文字数他の特徴は以下の通りである。

構成要素のバージョン

ユニコードのバージョンには、上記のような「ユニコードの規格全体に付けられたバージョン」の他に「ユニコードを構成する個々の要素の規格に付けられたバージョン」が存在する。これに該当するものとしては、ユニコードを構成する各面ごとに付けられたバージョンや、ユニコードに収録されないこととされたスクリプトのリスト (NOR = Not The Roadmap) に付けられたバージョン、規格の一部を構成するUnicode Technical Note(Unicode技術ノート)、Unicode Technical Report(Unicode技術報告)、Unicode Technical Standard(Unicode技術標準)のバージョンなどが存在する。

バージョンごとの非互換性

Unicodeは同一のコードでもバージョンが変わったとき完全に異なった文字を定義し直したことがある。

そのうち最大のものがUnicode 2.0での「ハングルの大移動」である。これはUnicode 1.1までで定義されていたハングルの領域を破棄し、新しいハングルの領域を別の位置に設定し、破棄された領域には別の文字の領域を割り当てることとなった。その後、Unicode 3.0では、従来ハングルが割り当てられていた領域にCJK統合漢字拡張A、ついでUnicode 4.0で六十四卦が割り当てられた。このように、Unicode 1.1以前でハングルを記述した文書とUnicode 2.0以降でCJK統合漢字拡張Aを記述した文書には互換性がない。JCS委員長の芝野耕司はUnicodeに日本語の漢字を収録させる議論の中で、ハングル大移動について「韓国のとった滅茶苦茶な行動」と述べている。

日本語環境でのUnicodeの諸問題

YEN SIGN 問題

Shift_JIS では JIS X 0201 における円記号 "¥" が 0x5C に置かれている。これを Unicode のマッピングに合わせると YEN SIGN (U+00A5) にマップされる。しかし、0x5C は ASCII ではバックスラッシュ "" に相当し、C言語などでエスケープ文字として使われる事から、この文字のコードを変更すると問題が起きる。極端な例として、0x5C が円記号とエスケープ文字の両方の目的で使われているケース(たとえば printf("¥¥%d¥n", price); など)も考えられる。

そのため、Unicode を利用するアプリケーションでは、U+007F 以下のコードに関しては移動させないという暗黙のルールができている。

そうなると、Unicode 環境では円記号がバックスラッシュの表示に変わってしまうように思われるが、これは日本語用のフォントデータの 0x5C の位置には円記号の字形を当ててしまうことで対処している。これによって、日本語環境での表示上は 0x5C の位置で円記号を用いることができる。

この問題は日本語環境に限ったことではない。もともと ISO 646 上では、0x5C を含む数種の文字は自由領域(バリアント)として各国での定義を認めていた。そのため、日本語以外でも ASCII でバックスラッシュに相当するコードに異なる記号を当てているケースが多い。例えば、韓国ではウォン記号 (WON SIGN, U+20A9, "")、デンマークノルウェーではストローク付きO (LATIN CAPITAL LETTER O WITH STROKE, U+00D8, "") などである。(後者は後の時代には、0x5C はバックスラッシュのままとし、ISO 8859 シリーズを用いることが一般化した。)

波ダッシュ・全角チルダ問題

JIS X 0221 規定の JIS X 0208 と JIS X 0221 の対応表では、波ダッシュは WAVE DASH (U+301C, "") に対応させているが、マイクロソフトは Windows の Shift_JIS と Unicode の変換テーブルを作成する際に、JIS X 0208 において 1 区 33 点に割り当てられている波ダッシュ "" を、Unicode における全角チルダ (FULLWIDTH TILDE, U+FF5E, "~") に割り当てたため不整合が生じる。この結果、macOS 等の JIS X 0221 準拠の Shift_JIS ⇔ Unicode 変換テーブルをもつ処理系と Windows との間で Unicode データをやり取りする場合、文字化けを起こすことになる。そこで Windows 以外の OS 上で動くアプリケーションの中には、CP932 という名前でマイクロソフト仕様の Shift_JIS コード体系を別途用意して対応しているケースが多い。この原因とされている Unicode 仕様書の例示字形の問題に関しては、波ダッシュ#Unicodeに関連する問題を参照すること。

また、マイクロソフトは同様に、

  • CENT SIGN (U+00A2, "¢") に代えて FULLWIDTH CENT SIGN (U+FFE0, "¢")
  • POUND SIGN (U+00A3, "£") に代えて FULLWIDTH POUND SIGN (U+FFE1, "£")
  • NOT SIGN (U+00AC, "¬") に代えて FULLWIDTH NOT SIGN (U+FFE2, "¬")
  • EM DASH (U+2014, "—") に代えて HORIZONTAL BAR (U+2015, "―")
  • DOUBLE VERTICAL LINE (U+2016, "‖") に代えて PARALLEL TO (U+2225, "")
  • MINUS SIGN (U+2212, "−") に代えて FULLWIDTH HYPHEN-MINUS (U+FF0D, "-")

と割り当てており、これらの変換時にも問題が起こる。このうちセント・ポンド・否定については、IBMのメインフレームではShift_JISを拡張してこれらの半角版をコードポイント 0xFD-0xFF に割り当て、別途JIS X 0208からマップされた位置に全角版を収録していたため、WindowsをIBMメインフレームの端末として用いるケースを想定したといわれている

なお、Windows Vista や Microsoft Office 2007 に付属する IME パッドの文字一覧における JIS X 0213 の面区点の表示は、上記の文字についても JIS で規定されているものと同じマッピングを使用している。

参考文献

  • 用語の日本語表記は原則として次にならった。
    • - 付属:CD-ROM。
    • - 付属:CD-ROM。
    • - 付属:CD-ROM。
  • - 原タイトル:Unicode: a primer

Unicode』に 関連する人気アイテム

世界の文字と記号の大図鑑 ー Unicode 6.0の全グリフ

ユニコードは全世界のほとんど全ての文字と記号をコード化したものである。ラテン文字からギリシャ文字アラビア文字などの現用文字から今は使われなくなった古代エジプトのヒエログリフまで109242の文字や記号がコード化されている。もちろん、その中で膨大な数を占めているのはCJK統合漢字だ。この全グリフを並べた図鑑というのが今までなかった方が不思議なのだが、なかった。確かにユニコードのサイトへ行けばそれぞれの文字とコードの一覧は見られるし、CJK統合漢字などは、無味乾燥なお役所の規格書の型で出版もされている。

つまりは、個々の文字については一覧があるが、関係ない文字や記号まで収録する必要はなかったと思われていたのだ。だいたい10万字と一口に言っても一ページに100収録しても1000ページを超える。実際本書は1024ページある。確かにこの本自体は実用にはあまり役立たない。本気でこのコード体系を実装するためにはこの簡単な記述では無理だし、コンピュータに対応するグリフが入っていなければ、この本が指示するコードを打っても文字や記号は出てこない。欧米のコンピュータに統合漢字のグリフがはいっているとも思えないし、日本のコンピュータでマヤ文字が出るわけでもない。本書の原書が実用を重んじるアメリカではなく、ドイツで発行されたのは象徴的だ。
だから図鑑なのだ。子供の頃、図鑑が好きだった。物語の絵本よりも動物や恐竜の図鑑を見るのが好きだった。知らない国にいる知らない動物の、大昔に滅んだ動物の姿を見るのが好きだった。それは人間の知的好奇心そのものなのだ。文字は人間のそれぞれの言語に対する必然性から生まれたが、やがて言語と文字はかならずしも一致せず、文字は文字として独自の発展を見せる。この本ではその過程や結果が、図鑑として目の前に繰り広げられる。そして、重要なのはユニコードは全世界のコンピュータで取り扱うことの必然性について侃々諤々の議論が行われてきて、洗練され、整理されているということだ。だから見やすい。眺めているだけで楽しいという月並みな感想だけでなく、文字や記号にいちいちふられたU+1F4A9という何気ないコードの奥にコンピュータで文字を扱うことへの執念を感じる。つくづくコンピュータは文化を変えたと思う。
この本の出版を決意された研究社さんには頭が下がるが、この価格付けは消極的すぎませんかね。だから星一つ減点
ISBN978-4-327-37736-6 研究社刊 16000円+税

5つ星のうち 4.0すぐれた思想性

(参考になった人 16/17 人)

文字と記号の多様さと多彩さもさることながら、やはりイントロダクションの部分が、一定の思想性の枠組みを持って書かれていて、私には一番興味深く、また面白かった。
とくにピクトグラムと「エモジ(絵文字)」について触れた部分で、シュメール楔形文字がピクトグラムか否か、またそれとスマホ絵文字との違いなどに関する指摘は、短くはあったが、私の長年の問題意識をも、改めて刺激してくれた。絵文字は多層で輻湊するイメージ、意識、感情、そして情報を一時に伝えてくれるが、ならばそれは記号なのか否か、殷周青銅器の、縄文土器の、あるいはアラスカ先住民の「文様」をどう捉えるのか。

ああした「モチーフ」もユニコード化することで、またひとつ文化に関する視野が広がるのではないか、などと考えは広がった。
あとは、ここまで各文字がコードとして普遍還元化されてしまうと、そして誰にでも打ち込み使用できるようになると、それはもはや文字としての意味や機能を失い、たとえばアスキーアートや顔文字に見られる如く、アートやクリエイティビティの「素材」としてのみ使用されていくのではないか、とも遅ればせながら考えた。現にイントロダクションにも、いまやタイプデザイナーは各自デザインするフォント内に、ありとあらゆるグリフを取り込もうとしていることが指摘されており、もしもそれがフォントの枠をはみ出せば、それはもちろん脱構築された上での芸術となるだろう。
総じて言えば、人間の営為についての様々な示唆を与えて、考察を深めてくれる、「本の本」を越えた「書籍」と私には受け取れたのである。
最後に、まったく個人的かつ勝手な要望を蛇足的に付け加えるならば、私としては手に取りやすい縦長の判型になっていれば、と思ったことだった。

家に届いたばかりの『世界の文字と記号の大図鑑』を初めて手にとった時、胸の動悸が高ぶった。 一読してそれを机上に下ろした時、その動悸は未だ始めと同様に鳴り響いていた。

本書は値段から考慮しても一般向けとは言い難いが、文字を愛する者にとっては一種の「宝」と呼べるものではないかと思う。 使用範囲は広く、文字・記号の一望(これが千姿万態で飽きることはない)、パソコン上でのフォント活用、随筆(例えばヒエログリフで文章を書く際)、更にはプログラミング用途にもアプライできる。

最後のコーディングでの活用だが、例えば「漢字」の正規表現を書くことにしよう。

「々」という文字は一般的に漢字として認識されているように思われるが、Unicode では U+3005、つまり「CJKの記号及び句読点」の区間に位置づけされている。 故に、漢字の正規表現を盲目的に「CJK総合漢字」領域のみに絞ると、断片的にしか――つまり、「々」「〆」などをスキップしたブロックしか――文字列の漢字部をキャプチャすることができない。 これは本書から得られる薀蓄の一つなのである。

なるべく多くの人に此の価値を汲み取って頂きたいお勧めの一冊である。

「プログラミング」のキホン プログラムの動作の基本と高速データ処理のしくみ

5つ星のうち 4.0ほんとうの基本。

(参考になった人 6/6 人)

2進数とか16進数とかプログラミングに初歩の基本的なことが、図解で掲載されている。 学生時に数学でこの辺りのことをやってきてない人には、こちらも必要であると感じた。 とくにマイコン制御やネットワークがらみだと、16進数とか2進数や何ビットとかが C言語の入門書だけではこの辺りの解説はなくいきなりこうなるからこうだ言った書き方で、 きちんと仕組みを理解しないと、誤った制御等になってしまうので、この本は自分が 捜し求めていたものだったので、満足できた。

ユニコード』の解説 by はてなキーワード

ユニコードコンソーシアムにより作られ、標準化された文字コード。多言語の文字を扱うことが特徴。Unicode

概要

元々2バイトですべての言語の文字を現そうとした規格で、ゼロックスが提唱し、アメリカ企業が積極的に参加していた。アプリケーションを1度書けばすべての言語に対応できるからである。一方日本などCJK*1圏ではわずか2バイト(65536文字)ですべての文字が現せる訳がないので否定的であった。結局CJK圏の拡張コードなどを入れていくと2byteで収まり切らなくなり、拡張される事になった。

ユニコードの構造上文字を現すことが出来るが言語を区別できない為、多言語文字混在環境は実現出来ても多言語環境を実現するのはユニコードのみだけでは無理と言われている。

エンコード方法

エンコードの方法に「UTF-8」、「UCS-2UTF-16下位互換あり)」、「UCS-4(UTF-32と互換有り)」などがある。また、UCSには、上位バイトが先に来る「ビッグエンディアン方式」と最後に来る「リトルエンディアン方式(インテル形式)」がある。基本的にUCSは固定長、UTFは可変長であり、これらのエンコードの方式の多さが混乱を招いている。

Windowsでは

Windowsは、UCS-2を採用、一方Javaなどのアプリケーションは内部でUTF-16、外部でUTF-8を使っている。これは、既存のアプリケーションのコードを大幅に変えることなくユニコード対応に出来るからである。

なお、Windowsでは、JIS勧告と間違ったユニコードSJISマッピングを行ったために、「WAVE DASH - FULLWIDTH TILDE問題」などの互換性の問題を引き起こし、異機種間のアプリケーション間での互換性の問題にもなっている。またJISの円マーク(\ Halfwidth Yen)とASCIIバックスラッシュが同一コードの為、「\」記号をユニコードに変換するとCやJavaなどのアプリケーションが動かなくなってしまう「Japanese Yen問題」があるが、ASCIIの下位7bitのコードは変換しないと言う事で落ち着いている様である。

バージョン推移


Unicode』by Google Search

This page is provided by Matome Project.
Contact information.