Edit

Page

Page title:

Page body:

[1] [DFN[[RUBY[[[Unicode]]][ユニコード]]]]は、世界中の様々な[[文字]]や[[記号]]を含む[[符号化文字集合]]と、
その運用のための[[正規化]]、[[照合順序]]等の規定によって構成される[[文字コード]]規格です。

[20] [[Unicode]] は[[計算機]]関係の企業によって構成される[[標準化団体]] [[Unicode Consortium]] 
による [[The Unicode Standard]] において規定されています。

;; [44] 団体や同団体による関連仕様については、 [[Unicode Consortium]] を参照。

* 仕様書

[35] 中心となる[[仕様書]]は
[CITE[The Unicode Standard]]
です。
かつては書籍として販売されていましたが、現在では無料で [[PDF]] を入手できます。
[SEE[ [[The Unicode Standard]] ]]

[36]
周辺仕様群は
[[UTS]] / [[UTR]] として [[HTML]] で出版されています。[[文字]]の特性その他のデータは [[UCD]]
としてテキストファイルで配布されています。

[27] [[仕様書]]ではないですが、
[[Unicode® Technical Notes]]
というシリーズもあります。

* Unicode と ISO/IEC 10646

[21] [[ISO/IEC]] による[[国際標準]]である [[ISO/IEC 10646]] が規定する [[UCS]]
は、[[符号化文字集合]]としては実質的に [[Unicode]] と同じです。
[WEAK[(「実質的」にというのは、理論上は [[UCS]] の方が [[Unicode]] より多くの[[文字]]を[[符号化]]できる余地があるからです。)]]
[[ISO/IEC]] [[JTC1/SC2/WG2]] と [[Unicode Consortium]] の [[UTC]] は共同で標準化作業を行っています。

;; [15] 標準化団体同士の協力関係だけでなく、中心メンバーも重複しているようです。

;; [81] 
[[ISO/IEC]] は[[国家]]を基本単位とする国際的な[[標準化団体]]で各国代表が審議に参加し、
[[Unicode Consortium]] は[[企業コンソーシアム]]で[[IT業界]]の主要企業
(主に[[米国]]企業) で構成されるという違いがあります。

[23] 当初は [[ISO/IEC 10646]] と [CITE[The Unicode Standard]] 
は実質同じものを規定するだけで別の仕様でしたが、
現在では [[ISO/IEC 10646]] が一部の規定で [CITE[The Unicode Standard]] を参照していたり、
[[UNICODE]] という名前の[[文字集成]]を定義していたりします。
改正のたびに [[ISO/IEC 10646]] から [CITE[The Unicode Standard]]
への依存性が強まっています。

;; [82] 
世界各地の多くの[[文字]]の[[符号化]]が完了して各国の関心は低下しており、
[[ISO/IEC]] 側の影響力も実務能力も下がっていて、
[[Unicode]] 側の決定を追認するだけの傀儡に近づいています。

[24] 
[[Unicode]] の方は 
[CITE[The Unicode Standard]] に各[[文字]]について詳細な解説が含まれるだけでなく、
[[UAX]],
[[UCD]] などとして実装のために必要な情報を大量に公開し、
自由に利用できるとしています。
その内容のほとんどは [[Unicode]] 独自のものであり、 [[ISO/IEC 10646]] 
には含まれていません。
[[ISO/IEC 10646]] は[[文字]]の[[例示字形]]を示す程度のことしかしていません。
[[ISO/IEC 10646]] 単体で実用レベルまで実装するのは不可能です。

[25] 最近の [[IETF]] や [[W3C]] の仕様は、大抵は [[ISO/IEC 10646]] ではなく 
[CITE[The Unicode Standard]]
を参照しています。
現在でも
[[ISO/IEC 10646]]
を参照する必要があるのは、
政府機関のシステム要件など[[政治的]]なしがらみがある場合くらいのものです。
[SEE[ [[Unicodeの版]], [[ISO/IEC 10646の版]] ]]

[14] [CITE[The Unicode Standard]] と [[ISO/IEC 10646]] の改訂には時間差があります。
どちらのどの版がおおよそどの版までとは言えますが、厳密な対応関係は無いようです。
[CITE[The Unicode Standard]] の改正は毎年のように機動的に行われていますが、
[[ISO/IEC]] の審議には時間がかかります。
世間のニーズに敏感に反応できるのは [[Unicode]] の方だけです。

[EG[

[83] 例えば[CH[㋿]]の[[元号合字]]の追加は[[令和改元]]直後に
[CITE[The Unicode Standard]]
が改正されましたが、
[[ISO/IEC]]
ではタイムリーに行えたのは追加を委員会で承認するところまでで、
実際の改正までかなり時間がかかっています。
[SEE[ [[元号合字]] ]]

]EG]

[30] [[仕様書]]構成としての関係性は
[CITE[[[The Unicode Standard]]]]
も参照。

** 対応国内規格

[22] [[Unicode]] そのものに対応する [[JIS]] はありませんが、 [[ISO/IEC 10646]] 
に対応する [[JIS]] として [[JIS X 0221]] があります。ただし数年に一度しか更新されないため、
基本的に古い内容です。
[CITE[The Unicode Standard]] より更新が遅い [[ISO/IEC 10646]]
を更に年単位で遅れて翻訳したものです。

;; [39] [[文字コード]]に限らず情報系分野全般に言えることですが、 [[JIS]]
には影響力が無いだけでなく内容が古いので、参考にもなりません。
人によっては最新の[[英語]]の仕様より少し古くても[[日本語]]で読みたいと思うかもしれませんが、
新版で変更されたり修正されたりしている古い規定が含まれていることも多いので、
[[JIS]] の存在はむしろ有害です。

[31] 
[[JIS X 0221]]
は
[[ISO/IEC 10646]]
に含まれる事項を翻訳しただけなので、
[[ISO/IEC 10646]]
が単独実装不能なのと同様、
[[JIS X 0221]]
も単独実装不能です。
[[Unicode]]
を知りたいなら、
[[日本語]]だからといって
[[JIS X 0221]]
を読んでも意味がありません。

[32] 
[[JIS]]
以外の各国規格もありますが、事情は同様です ([[ISO]] 改正への追随頻度は国によって違います)。
[SEE[ [[ISO/IEC 10646]] ]]

** ISO/IEC 10646 のせいでおかしくなった Unicode

[65] 
旧 [[DIS 10646]] を支持する人は [[Unicode]] と統合されて 
[[ISO 10646]] 
がおかしくなったような言い方をしますが、
[[ISO 10646]] との統合で [[Unicode]] が劣化した部分もあります。

[[鏡像文字]]の[[名前][文字の名前]]
[SEE[ [[書字方向依存グリフ]] ]]

* Unicode の版

[26] 
[[Unicodeの版]]は厄介な問題です。
[SEE[ [[Unicodeの版]] ]]

* 符号化方式

[37] [[文字コード]]に関する[[参照処理モデル]]に従えば、任意の[[文字コード]]は [[Unicode]]
の[[符号化方式]]の一種とみなすことができます。また、 [[Encoding Standard]]
は[[文字符号化]]を [[Unicode]] を[[符号化]]または[[復号]]する[[アルゴリズム]]として定義しています。

[38] そのような広義の [[Unicode]] の[[符号化方式]]ではなく、専ら [[Unicode]]
(または [[ISO/IEC 10646]]) の[[符号化文字集合]]の[[符号化]]を目的とした[[符号化方式]]も数多く存在します。

[FIG(list short)[
- [[UTF-8]]
- [[UTF-16]]
- [[UTF-32]]
- [[UCS-2]]
- [[UCS-4]]
- [[UTF-1]]
- [[UTF-EBCDIC]]
- [[UTF-7]]
- [[UTF-9]]
- [[RFC 4042 UTF-9]]
- [[UTF-18]]
- 各種 [[ACE]]
- [[BOCU-1]]
- [[SCSU]]
- [[CESU-8]]
- [[WTF-8]]
- [[WTF-8 (Windows Transformation Format)]]
- [[GB 18030]]
- [[HUC Braille Tables]]
- [[IMCUE]]

]FIG]

[85] [[UTF]] も参照。

;; ここに示したものの他に、それぞれのバリエーションも色々あります。

[40] しかしながら、過去のしがらみが無い場合には、専ら [[UTF-8]]
を用いるのが好ましいと現在では考えられるようになってきています。

[47] 符号化方式に関連して、次の概念があります。

[FIG(short list)[
- [[BOM]]
- [[エンディアン]]
]FIG]

* 符号点

[41] [[Unicode]] には、 [[U+0000]]-[[U+10FFFF]] の[[符号点]]
([[符号位置]])
があります。

;; [[U+]] は [[Unicode]] [[符号位置]]の[[16進数表記]]を表す記号です。

[42] しかしそのすべてに[[文字]]が割り当てられているわけではありません。
大部分にはまだ[[文字]]が割り当てられていません (将来の改訂で[[文字]]が割り当てられる可能性があります)。

[43] また次のような特別な[[符号点]]もあります。

[FIG(short list)[ [33] [[Unicode]] の特別な[[符号点]]
- [[サロゲート]]
- [[非文字]]
- [[タグ文字]]
-- [[Unicode言語タグ]]
- [[制御文字]]
- [[異体字選択子]]
- [[互換性文字]]
- [[零幅文字]]
- [[Unicodeの推奨されない文字]]
]FIG]

* Unicode / UCS の部分集合

[45] 次の[[部分集合]]が定義されています。
[FIG(short list)[
- [[TCVN 6909]]
- [[JIS X 0221]] (附属書1)
- [[ISIRI 6219]]
]FIG]

* 文字集合

[46] [[Unicode]] には色々な[[文字]]が収録されています。
[SEE[ [[Unicodeの符号空間]] ]]

* レンダリング

[50] [[文字のレンダリング]]参照。

* Unicodeアルゴリズム

[59] 
[DFN[Unicode[RUBYB[アルゴリズム][algorithm]]]]は、
[[Unicode文字]]が関わる指定された結果を達成するために使う処理の論理的記述です。
要求される結果の正確な論理的記述を実現しつつ、
その論理的記述の段階を正確になぞることなく自由に実装できるようにするべく、
意図的に緩い定義となっておる、
とされます。
[SRC[>>48 D17]]

[60] 
[DFN[[RUBYB[名前付き][named]]Unicode[RUBYB[アルゴリズム][algorithm]]]]は、
[CITE[The Unicode Standard]]
や他の
[[Unicode Consoritum]]
が出版した[[規格]]で規定され、
参照しやすいように明示的な名前が与えられた
[[Unicodeアルゴリズム]]です。
[SRC[>>48 D18]]

[61] 
[CITE[The Unicode Standard]]
では、
[[名前付きUnicodeアルゴリズム]]を
[[titlecase]]
で呼んでいます。
[SRC[>>48 D18]]

[62] 
外部から[[名前付きUnicodeアルゴリズム]]を参照するときは、
[[Bidirectional Algorithm]]
を
[[Unicode Bidirectional Algorithm]]
のように、
頭に「Unicode 」と付けてわかりやすくしても構いません。
[SRC[>>48]]

[63] [[頭字語]]の略称で呼ばれるものもあります。
[SRC[>>48]]

[FIG(middle list)[ [64] [[名前付きUnicodeアルゴリズム]]
- [[Canonical Ordering]]
- [[Canonical Composition]]
- [[Normalization]]
- [[Hangul Syllable Composition]]
- [[Hangul Syllable Decomposition]]
- [[Hangul Syllable Name Generation]]
- [[Default Case Conversion]]
- [[Default Case Detection]]
- [[Default Caseless Matching]]
- [[Bidirectional Algorithm]] ([[UBA]])
- [[Line Breaking Algorithm]]
- [[Character Segmentation]]
- [[Word Segmentation]]
- [[Sentence Segmentation]]
- [[Hangul Syllable Boundary Determination]]
- [[Standard Compression Scheme for Unicode]] ([[SCSU]])
- [[Unicode Collation Algorithm]] ([[UCA]])
]FIG]

* 上位層プロトコル

[28] 
[[Unicode]]
のいくつかの挙動は、
[[上位層プロトコル]]の規定に委ねられています。
[[Unicode]]
にとっての[[上位層プロトコル]]とは、
[[Unicode文字列]]を扱う[[プロトコル]]や[[データ形式]]
([[マーク付け言語]]、[[スタイル言語]])、
[[アプリケーション]]などを指しています。

[34] 
[RUBYB[[[上位層プロトコル]]][higher-level protocol]]は、
[[Unicode文字]]の解釈に関して
[CITE[The Unicode Standard]]
の[[適用範囲]]を超えて拡張する任意の[[合意][当事者間の合意]]です。
[SRC[>>48 D16]]

[49] 
かかる合意は、
データ中で形式的に広告する必要はなく、
文脈により暗示されるものであっても構いません。
[SRC[>>48 D16]]

[58] 
[[Unicodeアルゴリズム]]は、
[[適合]]する[[上位層プロトコル]]に認められる範囲を制限することがあります。
[SRC[>>48 D16]]

[FIG(short list)[ [29] [[上位層プロトコル]]への委任
- [[制御符号]]
- [[続け字]]
- [[annotation characters]]
]FIG]

[REFS[
- [48] [CITE[[[The Unicode Standard]], Version 13.0 - ch03.pdf]], [TIME[2020-03-09T17:53:34.000Z]], [TIME[2020-12-20T02:08:18.239Z]] <https://www.unicode.org/versions/latest/ch03.pdf#G2212>
]REFS]

* 歴史

[86] [CITE[Proposed Unicode Characters]], [TIME[2025-06-30T04:07:50.000Z]], [TIME[1997-01-05T18:51:39.475Z]] <https://web.archive.org/web/19970105185019/http://stonehand.com/unicode/alloc/Pipeline.html>

>post-Unicode 2.0

[89] 
[[Unicodeによる文化摩擦]]

* メモ

[52] かつては

> [DFN[When the world wants to talk, it speaks Unicode.]]

を[[標語]]としていました。 [[Unicode Consortium]] の[[Webサイト]]にも掲載されていました
[SRC[>>53]] が、21世紀に入る前に削除されたようです。

[REFS[
- [53] [CITE[Unicode]] ([TIME[2017-05-20 13:23:48 +09:00]]) <https://web.archive.org/web/19990427073550/http://www.unicode.org:80/>
]REFS]

- [2] ''Unicode Home Page'' <http://www.unicode.org/>
- [3] 元々、米国の計算機販売者がアジア市場に売り込むに当たって経費を抑えるために、世界中の文字を同一の16ビット平面に押し込んだ文字コードを作ろうとしたのが始まりとか。
-- [WEAK[Unicode と [[UCS]] の歴史についてはどっちも open な標準化団体の規格ではないことと、大宗教論争に突入してしまったために情報が錯乱していて、細かいことは (何が正しいのか) よくわかってません。]]
- [4] 1992年ごろ、開発の最終段階に差し掛かっていた [[ISO/IEC]] の新しい[[符号化文字集合]]規格, [[DIS10646]] に政治的圧力をかけて乗っ取って、結果 [[ISO/IEC10646]] はそれまでとは全く異なる、 Unicode に髭をつけたような規格になった。
- [5] それ以降 Unicode と ISO/IEC 10646 はほぼ同期している。
- [6] 後に [[Unicoder]] 共もようやく「世界中の文字を16ビットで表現」なんて妄想だったことに気づいて、 [[UTF-16]] という最悪な選択をした。 [WEAK[それによって Unicode の宣伝文句の1つだった「16ビット固定長」が崩れた。 Unicode の失敗を象徴するできごとなれど、 Unicoder は「そもそも元から[[結合文字]]があるから固定長ではなかった」などと粗末な言い訳をする始末。]]
- [7] 実は [[UnicodeConsortium]] ≒ [[JTC1/SC2/WG2]] の米国代表団だったりする。ちょっと前まで投票も一緒にやってたらしいよ。
- [8] 最近 ISO/IEC 10646 の Unicode 依存がますます進んでおり、 ISO/IEC 10646:2003 には、規格規定中に十何回も「Unicode 参照」なんて書いてある。
- [9] >>8 そのうち[[要約JIS]] みたいに、 10646 は「Introduction」だけになって、「2. 適合性 The Unicode Standard, Version 100.0 Conformance を参照。」とかになるんじゃないの(w
- [10] ん? うんこーどが[CODE[明確で注意深く構築された規格]]だって? 冗談は程々にしておかないと嫌われるよ?

[87] [CITE[Questions about Japanese]], [TIME[2025-06-30T04:31:24.000Z]], [TIME[1997-01-05T19:11:43.913Z]] <https://web.archive.org/web/19970105190422/http://stonehand.com:80/unicode/faq/cjk/japanese.html>

[TIME[1995-02-01]]

>EUC, JIS, and Shift-JIS are character encoding standards currently in use in Japan. These standards will most likely continue to be used in parallel with the Unicode standard in many Japanese applications, just as ASCII or Latin1 will continue to be used to represent European text. The choice of a character standard to use for text encoding is up to individual implementers.

[88] >>87 この頃は謙虚だなというかこの時代にこれからは [[Unicode]] だけになるとか言ってたら誇大妄想狂だよなw

[11]
私は
([[名無しさん]] [WEAK[2004-03-30 05:45:12 +00:00]])

[12]

>> The number of characters used for human communication desn't seem to be rising much, and there's plenty of space left in the current specification. IIRC Unicode still uses less than 200,000 of the million-odd possible code points.
> Famous last words.  From my handy dead-tree copy of Unicode 2.0, page
2-4, under the "Full Encoding heading":
>> There are over 18,000 unassigned code positions that are available for
future allocation. This number far exceeds anticipated character encoding
requirements for all world characters and symbols.
> Cough, cough.  It is nearly a universal truth that things tend to expand
to fill the available space (and/or time).  Why do you (apparently) think
that Unicode is exempt?
>> I suppose you could argue that Unicode adds alphabets. But do you think Unicode still hasn't reached the 20% mark?
> They add more than "alphabets", and that's part of the problem. Again
quoting Unicode 2.0 (page 1-3 this time):
>> Graphologies unrelated to text, such as musical and dance notations, are
outside the scope of the Unicode Standard.
> Yeah, right. What did the Unicode Consortium add in 3.1? -- musical notation.
So, as I said, I will not (anymore) be surprised when the Unicode
Consortium adds (literally) chicken scratching, probably shortly after
they add (if they haven't already) dance notation (human and otherwise),
every possible organic chemistry carbon ring symbol, Feynman diagrams,
CAD/CAM symbols, traffic sign symbols, trademarks, logos, etc. ad nauseum.
N.B. no smiley. [that reminds me; they'll probably add all of the smiley
variants too (if they haven't already)]
> I was once a Unicode fan -- the above quotations from earlier Unicode
Standards and "The Ten Unicode Design Principles" that were also in the
earlier standards were sound principles.  Unfortunately the Unicode
Consortium appears to have abandoned many of those principles.

[CITE@en[Re: UTF-8 versions (was: Re: RFC 2047 and gatewaying)]],
[[Bruce Lilly]], 2003年1月 ([[ietf-822]] 投稿)。

([[名無しさん]] [sage])

[13]
<mid:3E219D4B.9060608@Sonietta.blilly.com>

[16]
[[Unicode]] 5.0 には、どうも[[文字列]]の[[適合性]]に関する規定がないみたいです。
適合性の章 (3章) の中には、
D13 ([[非推奨文字]]の定義) に「非推奨の文字は使うべきではない」と書かれていたりして、
定義の中に[[適合性]]に関する規定とも読み取れるものが紛れ込んではいるのですが・・・。
3章は基本的には[[処理]]の [[Unicode]] に対する[[適合性]]を規定するだけで、
[[文字列]]に関する[[適合性]]には触れていないみたいです。

[17] <http://www.unicode.org/errata/> 見ると前のバージョンでは正常だった[[例示字形]]があとのバージョンでエンバグしたってのがめっちゃいっぱいあるんだけど、なんでそんなことすんのか理解に苦しむなー。
同じフォントで印刷しろよー。

[18] [CITE@en-us[Unicode Terminology: English - Japanese]]
( ([TIME[2010-07-23 03:54:01 +09:00]] 版))
<http://www.unicode.org/terminology/term_en_ja.html>

[19] [CITE@en-us[Unicode Utilities: UnicodeSet]]
( ([TIME[2011-04-17 10:53:56 +09:00]] 版))
<http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AtoNFKC%3D%2F%5C%25%2F%3A%5D&g=>

[51] [CITE[The Unicode Archives]]
([TIME[2017-05-16 12:23:25 +09:00]])
<http://unicode.org/pipermail/unicode/>

[54] [CITE@en-us[Unicode 10.0.0]]
([TIME[2017-06-21 00:05:01 +09:00]])
<http://www.unicode.org/versions/Unicode10.0.0/>

[55] [CITE@en-us[Unicode Mail List Archives]]
([TIME[2011-11-17 03:44:17 +09:00]])
<http://unicode.org/mail-arch/>

[56] [CITE@en[draft-faltstrom-unicode11-00 - IDNA2008 and Unicode 11.0.0]]
([TIME[2018-06-19 18:15:24 +09:00]])
<https://tools.ietf.org/html/draft-faltstrom-unicode11-00>

[72] [CITE@ja[Xユーザーのryo-aさん: 「@Zwegabin これに関しては「世の中に存在するグリフを全部収録してやる」というUnicodeの思想が強い気もします。実際にガラケーで使用されていた実績があるので収録に繋がったのかなと。 (じゃあKPS 9566の"金正恩"はなんで収録されとらんのだというと難しいところですが……)」 / X]], [TIME[午前2:15 · 2024年5月9日][2024-05-08T17:15:21.000Z]], [TIME[2024-05-10T09:23:36.000Z]] <https://twitter.com/geo_vitya/status/1788256386591367357>

[73] >>72 そんな「Unicodeの思想」なんてなくない? 少なくても「グリフを全部収録」は目指してないよね。
[[Unicode]] が符号化してるのは「文字」だけだから。

[74] 
[[将軍様専用文字]]の反例もそうだし、[[絵文字]]の中でも
[CC[EMOJI COMPATIBILITY SYMBOL]] たちはどこかに消えてなくなってしまったのだから、
「文字を全部収録」はやっぱり目指してないんじゃないの?

[75] 
熱心な人が [[Unicode]] 界隈にたまたまいる分野は収録されるけどそれ以外は放置プレイされがちな印象があるなあ

[76] 
有名な古代文字は符号化されてるのにマイナーな地方文字は提案されても証拠不十分で放置だったりするしなあ。
提案されててもそんな感じだから、誰かが持ち込まないものはどれだけ「存在」してても相手にもしてもらえないし。
「思想」はないでしょ。

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)