一昨日のことですが、中国・四国地方から文字化けのニュースがありました。IT系のメディアではなくNHKです。

Jアラートとは「全国瞬時警報システム」なのだそうで、最近北朝鮮のミサイル発射の問題のニュースに出てくることがあります。この緊急情報の送受信訓練で、メールでテスト電文を配信したところ文字化けして読めないものだったというニュースです。

上記リンク先には画像があり、携帯端末上で文字化けした文面が写っています。ぱっと見た感じでは、UTF-8のテキストをシフトJISとして解釈しようとしたように見えますが、冒頭の「発表」と末尾の「しまね防災情報」は見えています。前後の定型文がシフトJISで用意されていて、間に挟む本文もシフトJISでなければいけないところにUTF-8のバイナリを入れてしまったといった可能性が考えられます。

まあ、訓練で問題が見つかったのだから良かったとはいえるでしょう。プログラム自体は変えていなくても、そこに外部から与えるデータとして元々の想定とは異なるものを入れてしまったということもあり得るので、通しでやってみるのは重要なことです。

それにしてもIT系でない一般のニュースで「文字化け」という言葉を見るのはなかなか感慨深いものがあります。これをきっかけに拙著『プログラマのための文字コード技術入門』にも注目が集まる......かな?

ユーモラス、と言っていいのか分かりませんが、興味深いニュース記事がありました。

この記事の伝えるところによると、「「任●(にんきょう)団体山口組」(●は「侠」の旧字体)が、組織名を「任侠(にんきょう)山口組」に変更する通達を流していた」のだそうです。その理由として、「表記される際、「侠」の旧字体が正しく表記されないケースがあったことに不満を募らせたとみられる」と書かれています。

「「侠」の旧字体」は、当ブログ記事の題にあるように「俠」です。この字はJIS第3水準、面区点番号1-14-26にあります。人名用漢字にも入っています。

SKKの第3第4水準漢字辞書では「にんきょう」から「任俠」に変換できます。Macでも入力できます。もうこうした第3第4水準を避ける必要はないでしょう。

UTF-8のようなUnicodeの符号化方式で扱えるのはもちろん、JIS X 0213の符号化方式、EUC-JIS-2004Shift_JIS-2004で問題なく符号化できます。PythonやPHP, libiconvなどのコード変換はこれらの符号化方式に対応しています。

もっとも、上記のリンク先でもいまだに「●は「侠」の旧字体」のような読みにくい注釈を施しているのは残念なことです。JIS X 0213の全ての文字を扱えることがこれからの日本語処理の必須条件だという硬派な思想でビシッと筋を通して、第3水準漢字の組織名をいつでもどこでも使えるようにするのが良いのではないかと思います。

奥尻島は北海道の南西の方に浮かぶ島です。函館から飛行機で、また江差町からフェリーでアクセスできます。北海道の中では温暖な気候です。また、日本書紀に記されている安倍比羅夫が粛慎と戦った島だと考えられています。自治体としては奥尻町が島ひとつをカバーしています。

1993年の北海道南西沖地震でこの島は地震・津波・火災の大災害に見舞われました。当時私が住んでいた札幌は奥尻から遠く離れていますが震度3くらいあって、ちょうど風呂に入っていた時に大きめの揺れがきたのでよく覚えています。翌朝に見た被災地のテレビ映像は忘れられません。大津波が町を襲った後に火災が来るという、のちに東日本大震災でも見ることになる現象を私はこの時初めて知りました。この大災害の後、島では復興の意味もあって新たにワインを作るようになったそうです。

今回、奥尻町へのふるさと納税でこのワインを頂きました。もともと漁業の盛んな地域でウニやアワビが特産だそうですが、海の幸とワインを合わせてみるのもいいかもしれません。

IMG_20170428_220459.jpg

奥尻島ではワイナリーの見学もできるとのことで、旅行の際に行ってみるのも良さそうです。

大都市部から地方の支援ができて特産品のPRにもなるふるさと納税は今後も活用していきたいと思います。

このブログを電子マネーとクレジットカードの情報サイトにするつもりはないのですが、最近考えていることを少し整理。

電子マネーが増えていてスマホに色々入れることができるのですが、あまり多いのも無駄が発生するし管理の手間がかかるので考えものです。私もつい新しいものを試してしまうのでスマホの中が肥大化しがちです。そこで優先順位をつけて考えたい。以下は私なりに考えた優先順位とその理由です。何かの参考になれば幸いです。なおここではおサイフケータイのようにスマホ・携帯電話に入れることを前提としています。

最優先: iD または QUICPay

この2つはポストペイ型と呼ばれるもので、要はクレジットカード決済をスマホのタッチだけで行うものです。チャージしないで使えるので最も使い勝手が良い。また、チャージによるリスクもありません。(ここでいうリスクについては別記事参照: 「電子マネーiDの良さが今更ながら分かった」)

iDはNTTドコモと三井住友カード、QUICPayはJCBという違いがあります。手持ちのカードによってどちらを (あるいはどちらも) 使えるかが変わってくるでしょう。ちなみにiPhone の Apple Pay (Apple版おサイフケータイ) ではクレジットカードを使うのにiDかQUICPayを使うことになります。

次点: 交通系 特にSuica

iD・QUICPayで全て済めばいいのですが、そういうわけにもいかない。電車に乗るのにiDでは改札を通れないので交通系ICカードが要ります。

スマホに入れるのにはモバイルSuicaしかないようです。カードを別に持つならICOCAやKitacaなどでも。

オプション: 流通系 nanaco, WAON等

流通系電子マネーという言い方があるかどうか知りませんが、セブンアンドアイのnanacoやイオンのWAONのようなものを意図しています。こういうのはスーパーによって割引の日が設定されていたりします。nanacoは8の付く日にイトーヨーカドーで5%オフ、WAONは20日・30日にイオンなどで同様に5%オフになるなどの特典があります。

このカテゴリの電子マネーは特に必要というわけではありませんが、自分のよく使う店に応じたものを持つのも良いでしょう。

おわりに

この手の電子マネーやクレジットカードには何やかやと誘惑されるような特典があったりしますが、カードが増えたために却って手間が増えては本末転倒ですし、チャージした電子マネーの種類が多いほど「チャージしたけど使ってない」金額が増えることになってしまいます。ポイント還元率のちょっとした違いなどはあまり気にせず鷹揚に構えて、あまり振り回されない方が結果的に得かもしれません。

iDというのはSuicaやEdyのようなチャージして使う電子マネーと比べてあまりメジャーでない印象があるのですが、要するに自分のクレジットカードの決済をスマホのタッチひとつで行うものなので、チャージ不要で便利なものです。

使ってみると実は色々お得が隠されていることに気付きます。

dカードminiとローソン

dカードminiというものがあります。ドコモの携帯電話やスマホにちょちょっと設定するだけでiDが使えるようになるものだそうです。私は全然知らなかったのですが、これには意外なお得メカニズムが隠されています。

普通、iDを使うには自分のクレジットカードの会社に申し込んでiDのための番号を発行してもらう必要がありますが、dカードminiの設定をするとそれなしにiDが使えるようです。クレジットカードを登録しないなら請求はどうするのかというと、ドコモの携帯料金と一緒に請求されます。

ここでドコモの料金をクレジットカードで支払っていると、dカードminiの買い物もあわせた分だけクレジットカードのポイントが付きます。なおかつ、dカードminiの買い物200円につきドコモのdポイントが1ポイント付きます。両方のポイントが付くわけですね。これは普通のクレジットカードでiDを使う分にはない利点です。

なおかつ、ローソンとdカードのタイアップがあって、いつまでなのかは分かりませんがdカードでローソンの買い物が3%オフというキャンペーンがあります。これはdカードminiにも適用されるので、ローソンをよく使う人には良いでしょう。

ただしdカードminiは1か月に使える金額が最大でも3万円だそうなので、あくまでも「mini」なのでしょう。

セゾンiDで永久不滅ポイントが2倍、セブンイレブンだとさらに...

セゾンカードはiDに対応しています。セゾンカードで買い物をすると付与される永久不滅ポイントが、iDでは2倍になります。iDを使うだけでセゾンカードが高還元カードの仲間入りです。

あと、なかなか不思議に感じたのですが、セゾンカードをセブンイレブンやイトーヨーカドーで使うと、永久不滅ポイントとは別に、自分のnanacoにポイントが付く、というサービスがあったりします。nanaco番号をあらかじめウェブサイトから登録しておく必要があります。各種ウェブサイトの情報によると、セブンイレブンでは決済にiDを使ってもこのnanacoポイント付与の対象になる、ただしイトーヨーカドーではならない、ということだそうです。何でこういう違いがあるのかは知りませんが、セブンイレブンではセゾンiDを使うと永久不滅ポイント2倍なおかつnanacoポイントが付く、ということのようです。クレジットカードの世界は不思議が多い......。

iDバリュー

これは三井住友VISAカードでiDを使う場合のサービスらしいのですが、キャンペーン特典やカードのポイント交換でキャッシュバックされるような時のポイント残高のようなものと思えば良いでしょう。iDの請求額と相殺されます。例えばポイント交換でiDバリュー500円分をもらって、当月のiD請求額が2000円だったら、500円を引いて1500円が請求されます。ただしiDバリューには3か月といった有効期限があるのでそれまでiDの請求がないと無効になってしまいます。

おわりに: もっとアピールしても良いのでは

iDはせっかくの良いサービスなのにアピールが不十分という印象があります。頑張れiD!

以前もiDについて書いたことがあります。興味を持った方はこちらもどうぞ:

(追記) 電子マネーについては下記の書籍が面白い読み物でした。興味のある方はどうぞ:

Java 9では国際化機構で用いられるリソース文字列のファイル表現の文字コードとしてUTF-8がデフォルトで使用されることになるそうです。従来、ISO/IEC 8859-1がデフォルトであるためにUnicodeエスケープが必要となり、外部ツールで日本語テキストを「\u3042」のようなエスケープ文字列に変換する煩わしさがありましたが、ようやく解消されることになります。

Javaには古くから国際化のための枠組みが用意されています。その最も基本的な機構となる、多言語のメッセージ文字列を用意する仕組みとしては設定ファイルなどに用いるプロパティファイルという形式が用いられています。ところがこのファイルはデフォルトの文字コードがISO/IEC 8859-1という西欧向けの1バイトコードなのでした。

このため、JDKではnative2asciiというツールが提供されて、Shift_JISやEUC-JP等の文字コードからUnicodeエスケープを用いる形式に変換できるようにされていました。また統合開発環境のEclipseにはプロパティエディタというプラグインが開発され、コマンド操作なしにあたかも直接漢字を記述できるかのような操作が可能になっています。とはいえリソースファイル自体はもちろんUnicodeエスケープなので、普通のテキストエディタで表示すると欧文以外は全く読めないものになります。

Javaのプロパティファイル自体はUTF-8で記述されても読み込めるように既になっていたのですが、その重要な用途である国際化のリソースファイルとして読み込むResourceBundleクラスではなぜかISO/IEC 8859-1がデフォルトという状態が長く続いていました。実は自分でクラスを定義して一工夫してやるとUTF-8にできるという裏技(?)もあったりしたのですが、そういうのはデフォルトで提供してほしいものです。(この辺のことは拙著『プログラマのための文字コード技術入門』第7章に記しています)

オープンソースのWebアプリケーションフレームワークであるPlay Frameworkではリソースファイルにわざわざ別の仕組みを用意してUTF-8で直に書けるようにしています。リソースファイルがもっと早くUTF-8で符号化できるようになっていたらこのような措置はとられれなかったかもしれません。

遅きに失した感はあれども、ともかく改善されることになって良かったです。

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のコード対応表

iDとはどんなものか

電子マネーというとSuicaやEdyを思い浮かべることが多いでしょう。これらは事前に入金(チャージ)しておいて使います。一方、ポストペイ型電子マネーと呼ばれるiDやQUICPayというものもあります。これらは名前はずっと前から知っていたものの、どういうものなのかは何だかよく分からないでいました。Suicaで困らないし、まあいいや、と。

ただ最近機会があってiDを使うようになって、ああそうかこういうものだったのか、と今更ながらに理解しました。率直に言って、もっと早く使えば良かった。

思うに、iDを「電子マネー」と呼ぶから分からなくなるのではないか。利用者視点で単純化して言えば、iDとは「自分のクレジットカードの決済をスマホのタッチだけで行う仕組み」です。

ただしどのカードでもいいわけではなく、対応しているものに限られます。三井住友カードやセゾンカード、UCカードなどが対応しているそうです。(2017年5月27日追記: ほかにも道銀カードや横浜銀行、沖縄銀行など多数の地方銀行のカードも対応しているそうです)

上記の説明は例外をいろいろ省略しています。例えば携帯電話でなくてカードのタッチで決済したり、あるいはクレジットカードの契約なしに使う方法があったりもするようです。ただおそらく普通はスマホにカード情報を登録する使い方が多いだろうと思います。また実際にはいきなりカード番号そのものをスマホに入れるような運用ではなく、iDとしての番号 (iDのID番号?)を用います。この発行が必要なので、使い始めたいと思ったとき、カード会社に連絡して使えるようになるまで少々時間がかかるようです。

チャージ不要の2つの利点

利点は事前のチャージが要らないことです。通常のクレジットカード決済と同じで、iDに登録したカードに請求されます。チャージ不要というのは2つの意味で有利です。

1つは、残額を気にしなくていいこと。モバイルSuicaのようにスマホからチャージできるのは便利ですが、それでも、いくら入っているかを時々気にする必要がある。オートチャージ機能もありますが、あれは発動するタイミングが駅の改札だけらしいのと(使ってないのでよく知りません)、ちょっと高めの買い物だと結局残額を確認することになるでしょう。そういう煩わしさから解放されます。

もう1つは、チャージによるリスクを負わなくていいことです。ここでいうリスクとは、例えば、チャージしたものの使わずに退蔵してしまったとか、その電子マネーの使える店舗が減ってしまったとか、あるいは運営企業のビジネス上の判断によって使い勝手が悪くなったり価値が減ったり、極端には無価値になったりということもありえるでしょう。

そこまでいかないにしても、例えば1万円入金して1年間全く使わなかったとしたら、利息が付くわけではないので、同じ金額で個人向け国債を買えば最低でも金利0.05%分つまり5円増える(税引き前)のと比べると損しているとも言えます。

だから実はチャージしないで支払える方が利用者側にとっては良いと言えます。ただ、クレジットカードによってはモバイルSuicaへのチャージでポイント還元率が1.5%とかになっているのはその分のリスクプレミアムとみなせなくもないのでそこをどう評価するかが問題かもしれません。

おわりに

電子マネーやクレジットカードは、コンビニやスーパーの少額決済では現金をジャラジャラいわせるよりもスムーズで手早く済むこともあり、積極的に活用していきたいところです。iDはその有力な選択肢といえます。

月別 アーカイブ