元々日本語というものは、文字種が多すぎるために、デジタル化の難しいものでした。
コンピュータはデータを電気信号を使って複数の機器同士で受け渡しするのに、文字種が多いということはそれだけどの文字なのかを区別するために 多くの情報量を必要とするからです。
このときの特定の文字をどのような電気信号で表現するかをコードと呼び、また文字情報をコードにおきかえることをエンコード(符号化)、戻すことをデコード(復号化)と言ったりします。
コード表現について
コードというものを考えるのに、どうしても表記の理解が必要になったりするので記載します。良く言うデジタルデータとは電気信号の On/Off の連続であり、これを1と0の2進数(binary)で表現します。11110110
という信号は 文字で書くと長いので16進数(hexadecimal)表記を使って、F6
と表記します。16進数でも11
ということもあるので、区別のため 0x11
というふうに英語の hex のxをとって先頭にマークして表記する時もあります。
10進 | 16進 | 2進 |
---|---|---|
0 | 0 | 0000 |
1 | 1 | 0001 |
2 | 2 | 0010 |
3 | 3 | 0011 |
4 | 4 | 0100 |
5 | 5 | 0101 |
6 | 6 | 0110 |
7 | 7 | 0111 |
10進 | 16進 | 2進 |
---|---|---|
8 | 8 | 1000 |
9 | 9 | 1001 |
10 | A | 1010 |
11 | B | 1011 |
12 | C | 1100 |
13 | D | 1101 |
14 | E | 1110 |
15 | F | 1111 |
アルファベットのように基本的な文字は、電子データ上はこの2進数で8文字つまり8ビット=1バイトとして表現され、たとえば “Z” の 字は 01011010
= 5A
という信号の並びです。
Unicode
もともと日本語を含む各言語は、それぞれの国や使われる機種、あるいはその上で動作するプログラムの違いから、互いに自分のシステムで処理しやすいように異なるエンコードが用いられていました。
しかしそれだと コンピュータが壊れてしまったりして入れ替えようとすると、前の機械で使用していたデータが せっかくバックアップしていても 使えなくなってしまったり、別のソフトでそのデータを使いまわそうとすると使えなかったりするなど不便がありました。
変換するソフトがあってもどちらかのシステムがバージョンアップしてしまうと一部の文字が読めなくなったり文字化けを起こすこともあります。
今ではそういう不便をできるだけ少なくするように ひとつひとつの文字には世界で規格統一されており名前と番号が決められています(Character Set)。この番号表全体あるいは個別の番号を Unicode (ユニコード) というふうに呼びます。
Unicodeではひとつずつの文字に対する番号を U+
という記号に16進数を続けて表現し、たとえばあ
なら U+3042
というコードが振られています。
実際にデジタルデータとして記録や通信に使用するのは UTF-8とか UTF-16などのエンコード (符号化)方式で、これはデータを転送する際に 信号の区切りなどを分かるように決められた計算式を通し エラーを防ぐなど細工を施すように工夫されています。UTF-8だとあ
は E3 81 82 のような3バイトのデータの列にエンコードされます。
また UTF-8は 半角英数字なら 1バイトしか消費しないという特徴があります。Webサイトで使われる HTML や JavaScriptなどのファイルには、半角英数字のブラウザーへの指示情報を多く含まれるため、日本語のような多言語を混ぜた際に 全体のファイルサイズを小さくすることができて転送効率が良く、2010年以降においては日本ではほぼ標準となっています。
Unicodeを管理しているのは Unicode コンソーシアムで、世界の多くの主要企業や団体が会員となって運用を行なっています。 Unicode コンソーシアムは 国際標準化機構 ISOとの間で統一した体系をとるように協調して規格を定めています。
したがってプログラムは Unicodeに従った文字データの保存と取り出しができるようになっていれば、お互いにデータの再利用が可能だということになります。
文字爆発
Unicodeには 0x000000〜0x10FFFF で およそ110万の番号があります。 0x0000〜0xFFFF の 65,536個ごとに用途が決められブロックに区切られていて、0面〜16面があります。
2000年以前の段階では最初の0面の中だけで5万程度しか登録されていませんでした。しかし様々な国の事情や、研究目的の古代文字、日本の旧字や細かい字形の異なる異体字など、さらには絵文字のようなこれまで存在しなかった新しい文字が作られるなどして、2019年のバージョン12の段階で約14万字と大きく数が増加しています。
この内 漢字に関するものは7万を超える巨大な集合です。
新しい概念は日々生まれ続けるので、それを説明するための言葉も生まれ続けます。表音文字では人間の口の形という物理的な限界がありますが、漢字のような表意文字は概念の数だけいくらでも作ることができます。
普通はすでにある文字同士を組み合わせて熟語を作りますが、それが特に昔の手書きの時代においては自分で好きに組み合わせて新しい文字をつくることもできましたし、単に書き写し間違ったものが広まってしまったこともあるでしょう。
複数の部の組み合わせや位置関係から意味を説明するので、同じような文字もたくさんあります。例えば同じ「サキ」と読める崎
と㟢
は山
の位置が違いますが、意味の差は極めて些細で かなり主観的なものです。さらに一見すると同じ嵜
や 﨑
は良く見ると大
の部分が立
になっている別の字ですが、これも楷書が成立する前の篆書の時代には原字は同じであって意味に違いはありません。これを気にするのは、「人間の右手と左手はどちらの形が正しいか」を決めるようなものです。
それでも人にはコダワリというものがあって、特に自分や先祖の氏名や出身地に使われていたりすると、違う字形を受け入れ難いという人は多くいます。日本人はその傾向が強く、明治期にそれまでに苗字がなかった人々が血筋などに関係なく新たに自由に名前を付けたりしたものですから、名前に使われる文字が世界一 多い国となってしまっており、そのため どの文字を整理しようとしても必ず誰かが面倒になります。
一応法律上は 名前に使用可能な文字に一定の制限はあり、国が規定する人名用漢字は常用漢字を合わせて3000ほどで、子供の命名に使用できるのはその範囲内です。しかし苗字にいたっては これが規定される以前にできたものが大半であり、特殊な異体字を使っている人が多くいます。
異体字セレクタ
Unicode の基本の考え方では、文字の細やかな字形の違いというものには立ち入らず、あくまで文字が示す意味が論理的に違うかどうかに基づいてコードを定めるポリシーです。あ
とぁ
では語頭で使えるかどうかなど意味が違う文字ですが、aとaとa
などは微妙に形は違ってもそれは装飾の問題であり、フォント設定でどうにかすべきということです。
この点、漢字においては非常に複雑です。崎
(U+5D0E)と﨑
(U+FA11)のほか、高
(U+2FBC)と髙
(U+9AD9)のような割とメジャーなもの、渚
(U+6E1A)と渚󠄀
(U+FA46)、梅
(U+6885)と梅󠄀
(U+FA44) など、
ほとんど同じ字であっても違うコードが振られているものがあります。
これは日本の人名に多く含まれていたので、Unicode以前のWindowsやもっと前のワープロの時代に日本が独自に拡張していたものの名残で、収録の必要があるかどうか理想に対し、過去データを損失なく使い続けるために現実的な需要からやむを得ず互換性のために用意されたものが入いっています。
これらの文字、特にU+F900〜U+FAFFのあたりの文字には、システムによっては対応する正字(番号の小さい方)に自動で置き換えられてしまうことがあり、扱いには注意が必要です。データを保存して開き直すと表記が変わることがあります。
またこの初期の拡張に対して漏れてしまった字で、単一のコードが存在しない文字もあります。
よく取り上げられるものでは 葛飾区(かつしかく) の 葛
と 葛󠄀󠄀城市(かつらぎし) の 葛󠄀󠄀
の違いなどがあります。(⼓の中が異なる)
コードがないものをどうやってデータとして登録しているのか、その鍵が異体字セレクタ(Variation Selector)というものです。
この異体字セレクタとは Unicodeの U+FE00〜U+FE0F、U+E0100〜U+E01EFの 領域にある制御番号で、VS-1〜VS-16、VS-17〜VS-256 と、制定された時期により2つのエリアに分かれて存在します。 (2020年現在)
この特殊な制御文字は、それ自体は見える文字ではないのですが、何らかの文字と連続して記録することによって、前の文字の字形を制御する効果を持ちます。この作用を受ける文字とセレクタとを合わせて 異体字シーケンス (Variation Sequence) と呼びます。混乱しますが、異体字セレクタもシーケンスも どちらも略すとVSとなります。
異体字セレクタにはいくつかの種類があり、特に日本語の範囲でいうと 漢字用の IVS( Ideographic Sequence) が中心となるでしょう。これには VS-17〜VS-256を使います。
VS1〜VS16 は SVS (Standard Variation Sequence) と呼ばれるもののためのセレクタで、言語によらない標準的な変形のために用意されています。例えば ❤︎ (U+2764) に VS16 (U+FE0F) をつけると❤️(赤いハート)となります(環境によってはうまく表示されないかもしれません)。
しかし 歴史的な事情もあって、漢字に固有のものでもSVSを使うようなものもあります。梅︀
(U+6885 & U+FE00)などもそのうちの1つです。
修飾子
このところ大きな影響を持つUnicodeの動きとして、絵文字にかかる修飾子 (Emoji Modifier)の存在があります。
たとえば “Bye-Bye” を示す絵文字 👋 (U+1F44B) が ありますが、これに 肌の色 U+1F3FB〜U+1F3FFを使うことで 👋 👋🏻 👋🏼 👋🏽 👋🏾 👋🏿 のように色を変えられます。手だけでなく顔も👨 👨🏻 👨🏼 👨🏽 👨🏾 👨🏿 のようにできます。
絵文字は元々日本で生まれたものですが、あくまで日本のローカルな文化によって構成されていたため、当初 肌の色は1つしかありませんでした。ですがこれは海外では批判され、やがて特定の国籍や人種・性別にとらわれない多様な文字を用意すべきという 世界のダイバーシティー論議に影響を受けて変化していきました。
結合子
修飾子と似たような効果を持つものとして、結合制御(Combining)を含むコードが有り、たとえば普通は付けられないル
に゛
を付けてル゙
としたり、 セ
に゜
を付けて、セ゚
のような文字を出すことができます (U+30BB & U+309A)。他にも犬
に○
をつけて犬⃝
などと書いたりも できます (U+72AC & U+20DD)。
これらの制御機能付きの文字は、組み合わせによって、実際に表示される字形は フォントの指定によって字形は変わるので、必ずしも期待通りの表示には ならないことがありますが、OSなど ソフトのヴァージョンアップが追いついている限りは おおむね 同じような表示になります。
最も強力なものが U+200D のゼロ幅結合子 (zero width joiner = zwj) です。
これは○
のような文字幅がなく、任意の文字同士を結合して1文字のように見せることができます。この「1文字のように見える」というのを「書記素(grapheme)が1である」といいます。
これも元はそれほど使い道が なかったものですが、💑(U+1F491)の「男女のカップル」の絵文字があり、これもダイバーシティの問題からコンビネーションが必要になりました。
女性同士の👩❤️👩 (U+1F469 & 200D & 2764 & FE0F & 200D & 1F469)、
男性同士の👨❤️👨 (U+1F468 & 200D & 2764 & FE0F & 200D & 1F468)があります。
U+1F469 は女性👩、U+1F468 は男性👨で、色付きのハート❤️を組み合わせ zwjで3個結合したものです。
👪 (U+1F46A) の「家族」の絵文字も 母+父+息子 の家族構成だったため、多様な家族構成が有るべきとなり、👨👩👦 👨👩👧 👨👦👦 👨👩👧👧 👨👨👦👦 のように多様なバリエーションがあります。
男の子 👦 (U+1F466)と 女の子 👧 (U+1F467) と男性👨・女性👩とをzwjで かなり柔軟に組み合わせることができます。
これらの文字が増えたことによって自由度が高まったのは良いことですが、問題もあります。
まず使うコンピュータやバージョンによって一貫性のない表示になってしまう可能性があることです。Unicodeが世界の文字を1つのコードで表すことで、異なるシステムでも文字化けしないことに意味があるのに、こうした拡張が頻繁に行われつづければ、非対応機種では正しく表示できないことになります。
また書記素が1でも 文字数は1ではないが ために、字数制限のあるプログラムで文字落ちを起こす可能性もあります。例えば文字数が制限されているような入力枠に、家族の絵文字などをコピペで貼り付けると家族が分かれてしまうことがあります。
(機種で違う動きをします)もうひとつは 複雑な文字ができたことで、どう読んでよいか分からないという、難読漢字や特殊な異体字と同じ問題を抱えていることです。
高
(U+2FBC)と髙
(U+9AD9)の字の意味の違いを 他人が理解できないように、👨👩👧👧 と 👨👨👦👦の違いは小さくて見えづらいですし、知らずに間違ったものを選択してしまって、相手に不快感を与えるかもしれません。
また読み方がわからないために どうやって入力してよいか困る可能性があります。漢字変換で入れるには読みがわからなければいけませんし、Touch Bar とかスマホの特別なキーボードがあれば文脈から提案がされますが、古いキーボードだと入力は面倒です。目が不自由だったり手指が不自由で主に音声入力をしていたり 何らかの障害のために使用が困難な人も 増えるかもしれません。
メールなどで受け取ったものを 音声読み上げシステム等で読ませようとしても 正しく読み上げられるかどうかは分かりません。学校の漢字教育でも習ってない絵文字の読みを耳で聞いて、理解できるかも不明です。
東アジア圏の表意文字である漢字が何万もの登録があることからすれば、絵文字が多様な世界各国の文化を取り込み続ければ、さらに膨大な文字が増え続ける可能性があり、システム側の対応も いたちごっこになる可能性があります。
絵文字にカナ
読みがわからない問題については、日本には少し分があります。日本には漢字にフリガナを付ける文化がありますから、👦とか👧とか書くのは既存のシステムで対応可能です。
また、日本の漢字には 送りがな の文化もあります。“🎅” だけだと よく見えなくても、“🎅クロース” と書けばこれは “サンタクロース” のことと、読みのヒントになります。
“👮♀️” では よく分からなくても、“👮♀️リスウーマン” とすれば婦人警官と漢字で書くより豊かなカタカナ表現が可能です。この字は 警官(U+1F46E)に♀(U+2640)にVS16(U+FE0F) とをつなげた複雑なもので、読み上げシステムが正常に機能するか怪しいですが、もし「ポ」が欠けて「リスウーマン」だけ読み上げられたとしても 流れで推定できるでしょう。
新しい絵文字が出てきたときに、フリガナが あれば仮にシステムが非対応でも読むことができます。その意味ではフリガナによる補足は保険としても有効でしょう。
また別の活用法としては元々難読漢字のものを置き換えることもできます。
🎋(U+1F38B) は 七夕 のことですが、この「たなばた」の読みは 特殊で分かりにくい当て字です。 2文字あるので送り仮名で補うのもやりにくいです。これを “🎋なばた” とすると、送りがなの助けを借りて 漢字よりも高い表現力と 読みの推定しやすさの両方が得られます。フリガナが使えない環境で有効と考えられます。
漢字の再発明
絵文字の普及し急激にバリエーションを増やしたことは文字爆発に拍車をかけて様々な懸念が有るものの、ゼロ幅結合子が大きく活用される状況は他の言語、特に日本語を含む漢字の世界では大きな弾みとなる可能性があります。
例えば 2019年から元号が “令和” となりましたが、これに伴って㋿
(U+32FF)という文字(?)ができました。㍼
㍽
㍾
㍻
という文字が日本語システムで使われてきたことから、この一文字を入れざるを得なかったわけですが、結合子があるのなら 令
と和
を つなげば良いのであって、今後は新たに年号が変わっても文字を作る必要はないでしょう。
漢字の中には いくつか同じ部の連続する文字があり、木
×3=森
、車
×3=轟
、田
×3=畾
、虫
×3=蟲
、力
×3=劦
などは まだ普通のうちですが、さらに鹿
×3=麤
、魚
×4=䲜
、雷
×4=䨻
、虎
×2=虤
、龍
×2=龖
、龍
×3=龘
など、ワンパターンな配置で さほど特別な意味のない字があります。規則化すれば こういうタイプの字にいちいちコードを割り当てる必要はないということです。
同じ理屈で、部首の組み合わせで文字を作ることも考えられます。
U+2F00〜U+2EF3 の領域は 漢字部首記号が収められており、⼻
⼶
⼺
⽧
⺈
⺉
のような単独では文字として使えないものがこのブロックにあります。結合子が使えるのであれば、書き順に従って つないでいけば 理論上あらゆる漢字を表現可能なはずです。しんにょうの点の数なども ⻌
⻍
のどちらでも好きに使えます。
読めない漢字が無限に増えてしまう可能性は否定できませんが、部首が持つ意味については 敏感になるでしょう。いまは使われないと言いますが、ベトナムの 𡨸喃(チュノム) に似た運用になるかもしれません。
絵文字を含め、日本で作られた文字は世界に大きなインパクトを与えましたが、逆に世界の文字システムが日本語に対しても多大な影響を与えています。
今後も日本語を考える上では日本語の中だけでなく、世界の多様性や外国語とのシステムの並行運用について、注意を向けておかなければなりません。