2017年6月アーカイブ

Unicode 10.0が2017年6月20日にリリースされました。今回は8,518文字が追加されています。

日本語話者にとって最も関係しそうなのは変体仮名の導入でしょう。

変体仮名とは

現在、平仮名は1音につき1文字ですが、以前は同じ音に対して複数の書き方がありました。例えば、平仮名の「か」は漢字「加」が元になっているもので、これ以外に「か」と読む平仮名はありませんが、かつては「可」を元にした仮名も使われていて同じく「か」と読まれました。そうした複数のバリエーションがあった仮名を明治時代に標準化したものが今の平仮名です。このとき採用されなかった異体が変体仮名と呼ばれるものです。

変体仮名は今日では文章を綴るのには使われませんが、そば屋の看板などで装飾的に用いられることがあります。

Unicodeにおける変体仮名

変体仮名はUnicodeではBMPでなく面01に配置されました。U+1B000-1B0FFのKana SupplementブロックおよびU+1B100-1B12Fの Kana Extended-Aです。例えば先ほど例に挙げた「可」に基づいた「か」は符号位置U+1B019にあり、文字名はHENTAIGANA LETTER KA-3とされています。読みを「KA」のように示して、複数ある異体は数字で区別されています。全部で285文字の変体仮名が収録されています。

符号化の方式としては、単純にひとつの符号位置にひとつの文字が対応する形になっています。複数の読まれ方をする字がありますが(例えば「惡」に基づく字、「あ/を」)、こうしたものもひとつの符号位置にのみ置かれ、読みが違うからといって重複して配置されてはいません。標準化の途中の段階では、音価に相当する符号位置を与えて異体字セレクタのようなもので変種を示すといった案もあったようですが、最終的には扱いやすい形式に落ち着いたことになります。

漢字の追加も

今回、CJK統合漢字拡張Fが追加されています。7,473文字と結構大きな追加です。使う機会があるかどうかはまた別の話ですが......。

拡張Fのコード範囲は2CEB0-2EBE0となっています。

Google検索結果からサイトを除外できる

Google Chromeの拡張機能のPersonal Blocklistというのを知りました。

これをインストールすると、Google検索結果から指定したサイトのページを除外することが簡単な操作でできます。いつものGoogle検索結果画面に、当該サイトをブロックするという機能が追加されるので、このサイトはおかしいと判断したらそこを押せば検索結果から綺麗さっぱり見えなくなります。そのとき限りではなく、その後も適用されます。もちろん、誤操作や濡れ衣で不当にブロックしてしまったものは後で戻すことも可能です。

手元のPCのブラウザで動く拡張機能であるわけですが、どのサイトをブロックした(あるいは元に戻した)という情報はGoogleのサーバにも送られ、Googleの検索結果に影響するのだそうです。たくさんの人がブロックしているサイトは情報の信頼性に問題があるとみなされるということなのでしょう。もちろん、それを悪用する人も出てくることは容易に予想できるので、全く鵜呑みにするというものでもないでしょうけど。

キュレーションサイト問題の改善につながるか

私がこれに期待するのは昨年来話題のキュレーションサイト(パクリサイト)問題の改善です。ひとの写真や文章を勝手にコピペしていいかげんな記事を量産するサイト、こういうのは信頼性が低いサイトの代表であるので見てもしようがないし、写真を何度も無断利用されている私にとっては不快極まるサイトです。

早速、検索結果に出てくる目障りなキュレーションサイトをいくつかブロックしてみました。きちんとしたサイトが上位に出るようになってせいせいしました。事前に思った以上に、精神衛生上よいと感じます。私同様に、キュレーションサイトに著作物を無断利用された方がこの拡張機能を活用し高く評価している記事があります。この方はこの機能の効果を「スッキリ」と表現されていて私の感想とよく一致します (「Google Chrome機能拡張「Personal Blocklist」役立たずの検索結果をサイトごとブロック!」)。

Googleとキュレーションサイトといえば、数箇月前にキュレーション対策とみられるGoogleの検索アルゴリズム変更が話題になりました。

記事を見ると確かに、旅行系のキュレーションサイトRetripが順位を下げていると報じされてはいるのですが、個人的にはあまり体感していません。検索語にもよるのでしょう。このアップデートのあとも、出鱈目な記事として他サイトで批判されているRetripのページがGoogle検索の1位を飾っているのを目にしてもいます。また、最大手とみなされているNaverまとめはこのアップデートの影響を受けていないようだともされています。

DeNAやリクルートがキュレーションサイトを閉鎖する中、Line株式会社はNaverまとめをやめるという発表をいまだにしていません。それどころか、同社の上級執行役員メディア担当の島村武志氏は「引用される、されないの定義に関しても、どこの誰かは分からない人に引用されているから権利者は怒るのであって、ネット界隈で有名な人に引用されたら「ありがとうございます」となるのではないでしょうか」(「「お前が言うな」の声も想定していた----キュレーション騒動を受けてNAVERまとめが新方針を打ち出した理由」TechCrunch Japan, 2017年1月10日)と合法な引用と著作権侵害の区別もついていないだけでなく有名人にされるならいいだろうという非常識な発言で大いに失望させてくれました。さらには「ネットに落ちている情報をもとに〔...〕記事をまとめる」(同) と他者の著作物を「落ちている」もの扱いして、Naverまとめに著作権を侵害された写真家有賀正博氏には「この人たちに一次権利者の権利保護を期待しても無駄です」(NAVERまとめが、パクリサイトの運営を決してやめない理由とは)と斬って捨てられました。

Personal Blocklistを使う人が増えれば、皆が認めるようなコピペ粗製乱造サイトは検索順位の下の方に沈んでいくのではないかな......と期待したいところです。

Pythonとlibiconv, nkf, Javaのコード変換を比較した記事がありました。

ASCIIとJIS X 0201の違いに起因する円記号問題とチルダ・オーバーライン問題、それにUnicodeのFTPサイトが原因と思われる全角ダッシュの件という既知の問題が多いので目新しくないのですが (『プログラマのための文字コード技術入門』をお読みいただければわかります)、Pythonについて目新しげな話がありました。

Pythonでは他と違って、二重(白抜き)の括弧をU+FFxxの位置にあるものでなくU+29xxに割り当てているそうです。うむ。そうか、そうきたか。

JISの公式な対応表ではU+FFxxの方になっています。文字名でいうとFULLWIDTH {LEFT|RIGHT} WHITE PARENTHESISです。

ただ、ここで「なぜFULLWIDTHなのか」という疑問を持った方もいるでしょう。本来UnicodeのFULLWIDTH/HALFWIDTH云々というのは、シフトJISのように1バイトコードと2バイトコードとの間で重複符号化のある符号化方式との往復変換の救済用に設けられたものです。ところがこの括弧記号はJIS側の符号化方式(Shift_JISやEUC)で重複符号化されているものではないので、本来FULLWIDTHになるきちんとした理由はありません。にもかかわらず、UnicodeにJIS X 0213の文字を追加する作業でなぜかFULLWIDTHの方に入れてしまいました。

一般に用いられている変換表は、(多少ヘンだと思ったかもしれないにせよ)このUnicodeの作業を反映したものになっています。JIS X 0213の追補1でもそうなっています。Pythonのような判断をしたものは私はほかに見たことがありません。

Pythonがこうしたのは、強い信念のもとでの判断なのか、そうでなく何か行きがかり上そうなっただけなのか、ちょっと興味を惹かれるところではあります。

UnicodeにはのちにU+2E28, 2E29に{LEFT|RIGHT} DOUBLE PARENTHESISというのが追加されて(バージョン5.1らしい)、どうもこっちがいいんじゃないかという気もしてくるのですが、後から出してこられるのはつらい。3.2の時にあれば良かったのですが。

ちなみにこの二重の括弧は、文章や辞書において文中に入れる注記の類に用いられることのある記号です。

【追記 2017年6月7日】 JISとUnicodeの間のコード変換表はこちらから入手できます。JISの公式な定義と同等です: JIS X 0213のコード対応表

広告