ITの最近のブログ記事

前の記事で,Pythonの識別子のUnicodeの扱いについて取り上げました。では,同じくUnicodeの様々な文字を識別子に使えるJavaとはどのように類似しているか,あるいは違っているでしょうか。

Javaの識別子の仕様

Javaは最初からUnicodeを前提に設計されており,変数名やメソッド名等の識別子にも世界の様々な文字を使えるようになっています。

識別子の仕様は言語仕様Java Language Specification 3.8. Identifiersに見えます。が,読んでみると実は,このセクションにはほとんど中身がなく,実質的にはJava APIのCharacterクラスの2つのstaticメソッド isJavaIdentifierStart(int) および isJavaIdentifierPart(int) にて,識別子に使える文字が規定されています。前者が識別子先頭,後者が2文字目以降です。

前者のメソッドのAPIドキュメントにはこう記されています:

  • isLetter(codePoint) が次を返す: true
  • getType(codePoint) が次を返す: LETTER_NUMBER
  • 参照される文字が通貨記号である ('$' など)
  • 参照文字が連結句読点文字である ('_' など)

一方,後者のメソッドつまり2文字目以降の定義は次のように記されています:

  • 汎用文字である
  • それが通貨記号である ('$' など)
  • それが連結句読点文字である ('_' など)
  • 数字である
  • 数値汎用文字である (ローマ数字文字など)
  • 連結マークである
  • 非スペーシングマークである
  • 文字の isIdentifierIgnorable(codePoint) が true を返す

少々とっつきにくく見えるかもしれませんが,Unicodeの文字カテゴリを前提としているので,その知識があれば「あれのことだな」と思いあたるでしょう。例えば最初の「汎用文字」はカテゴリLo, Luなどをまとめたもの,「数字」はカテゴリNd,「非スペーシングマーク」はMnといった具合です。最後の項目のメソッドは,制御文字の類いかどうかを判定するものです。

Pythonの識別子

Python3では,言語仕様の2.3. Identifiers and keywordsにて識別子の字句構造が定義されています。形式的に定義されているところを引用します:

identifier   ::=  xid_start xid_continue*
id_start     ::=  <all characters in general categories Lu, Ll, Lt, Lm, Lo, Nl, the underscore, and characters with the Other_ID_Start property>
id_continue  ::=  <all characters in id_start, plus characters in the categories Mn, Mc, Nd, Pc and others with the Other_ID_Continue property>
xid_start    ::=  <all characters in id_start whose NFKC normalization is in "id_start xid_continue*">
xid_continue ::=  <all characters in id_continue whose NFKC normalization is in "id_continue*">

Pythonの仕様書では,識別子の仕様は Unicode Standard Annex UAX-31 "Unicode Identifier and Pattern Syntax" に準拠していることが明示されています。これは一般的な言語の識別子の仕様(の雛形)として利用できるものです。Unicode仕様があまりに巨大なので,言語設計者の役に立つようなガイドラインとして作られたものだろうと思います。

実はJavaの方も内容的にはこれに準じているように見えます。ただし仕様書から参照されてはいません。

というわけで,JavaとPythonとで使える文字にあまり違いはありません。通貨記号の扱いが異なるのと,連結句読点(カテゴリPc)かアンダースコアのみかの違い,またUAX-31で互換性のために用意されている "Other_ID_{Start|Continue}" を含むか否かのような細かな出入りはあるようですが,大筋では大体同じものが使えると思ってよさそうです。

正規化の問題

ただし,JavaとPythonの小さくない違いとして,Pythonの方はUnicodeのNFKC正規化にて同一性をチェックされるということがあります。つまり,識別子の文字に,「é」のような文字を含む際に,「e + 合成用アクセント記号」としているか,あるいは合成済みの「é」の符号位置を用いているかという違いの取り扱いです。Pythonではこれらは正規化されて同じものとみなされます。

Javaにはこの規則はありません。Javaは正規化の仕様ができる前のUnicode仕様に基づいて設計されたので,比較的最近Unicode対応したPythonとは事情が異なります。

Javaで以下のようなコードを書いてみると実験できます。

public class JavaIdentifierTest {
    public static void main(String[] args) {
	int é = 0;
	int e\u0301 = 1;
	System.out.println(é);  // -> 0
	System.out.println(e\u0301);  // -> 1
    }
}

コード中のUnicodeエスケープ \u0301 は合成用アキュートアクセントです。JavaのUnicodeエスケープはコンパイルの早い段階で処理されるので,文字列リテラル専用ではなく,このように識別子の一部に用いることもできます。2つ変数を定義しており,どちらも同じ「é」を表しますが,片方は合成済みの符号位置,もう片方は結合文字を使っています。可能であれば,Unicodeエスケープを用いずに「基底文字e + 合成用アキュートアクセント」をエディタから入力してみても良いでしょう。Javaではこの2つの変数は同一視されずに別物として扱われます。

Pythonで同じことを試そうとすると,エスケープでなしに合成列をどうにかしてターミナルにペーストしてやる必要があります。私のMacの環境では,pythonコマンドでインタプリタを起動して,

>>> print('e\u0301')

として出力された é をマウスで選択してコピーすると,「e + 合成用アクセント」としてコピーできるようです (どこかで勝手に正規化されないことを祈りましょう)。確かめるには,

>>> len('é')
2

のように長さが2になっていればOK。これを変数名として,

>>> é = 1

のように変数として用いてみます。一方,キーボードから普通に入力したéは合成済みの符号位置になるので,Macの場合なら入力方式「ABC - 拡張」から Option-e e と打鍵して,

>>> é
1

とすることで,さっき代入した値が出てくることがわかります。つまり,文字éの符号化として合成済みの単一の符号位置を用いても,結合文字を用いて2つの符号位置で符号化しても,識別子としては同一のものとして扱われていることがわかります。

プログラミング言語Pythonで,変数名のような識別子に使える文字の種類は何だったかなとウェブを検索したところ,出てきたページに,UnicodeのカテゴリMn (結合文字)が使えないという意味の説明がありました。おや,そんなことあるかな,とちょっと調べてみました。

カテゴリMnとは

Unicodeは符号位置ごとに文字のカテゴリを属性として与えています。例えばラテンアルファベット大文字AであればUppercase Letter (Lu),ドル記号($)であればCurrency Symbol (Sc)などです。漢字や平仮名のように大文字小文字の区分のない文字はOther Letter (Lo)に分類されます。個々の符号位置のカテゴリはUnicode Consortiumが配布しているUnicodeData.txtに記されています。

これらのカテゴリのうち,結合文字はNonspacing Mark (Mn), Spacing Mark (Mc), Enclosing Mark (Me)になります。日本での使用で見るものはMnが多いでしょう。フランス語に用いるCOMBINING ACUTE ACCENT (U+0301)や,片仮名の濁点COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK (U+3099)などがこれです。

Unicodeに言語仕様から対応しているプログラミング言語では識別子に英語以外の様々な言語の文字に対応していることがあります。最初からUnicode前提に設計されたJavaでは変数名に「あ」「字」のような平仮名や漢字を使うこともできます。Pythonのバージョン3系も同様です。

ここで,もしカテゴリMnつまり結合文字が使えないと,多言語対応に支障が生じることになります。上記のフランス語のアクセント記号などは基底文字のアルファベットと合成済みの符号位置,例えばé (U+00E9)が用意されているので結合文字がなくても表現できますが,全てにおいてそうとは限りません。初期のUnicodeとは異なり,今日では結合文字を使って表現可能な文字は独立した符号位置に収録されない傾向にあります。例えば比較的最近Unicodeに追加された文字に,日本語でかつて使われていた変体仮名がありますが,濁点つきの文字は結合文字を使って表現できるため収録されていません。

手っ取り早く試してみる

Pythonのインタプリタを使うと手っ取り早く試すことができます。pythonコマンドを実行して,

>>> ㇷ゚ = 1
>>> ㇷ゚
1

よし,大丈夫ですね。ここで,最初の行は変数「ㇷ゚」(プの小書きです) に整数1を代入しています。ここでエラーにならなければOK。次の行は変数の値を確認しています。「ㇷ゚」はブラウザでは1文字に見えていると思いますが,実際には2つの符号位置の並び,つまり基底文字「ㇷ」と結合半濁点とで実現されています。「ㇷ」のカテゴリがLo, それに続く半濁点がMnです。つまり,この変数がエラーにならないということは,変数名としてカテゴリMnの結合文字が使えたことになります。

小書きの「ㇷ゚」を入力するのには,Macではアイヌ語入力方式にして「p [リターン]」と打鍵すればよし。Windows 10では「ぷ」から変換キーを何度か叩けば出てくるはずです。コマンドプロンプトでは半濁点が1文字分の幅をとってしまうようですがプログラムの動作には支障ありません。

言語仕様

きちんと確認するにはPythonの言語仕様にあたる必要があります。変数名のような識別子については,2.3. Identifiers and keywordsに記載されています。

ここを見ると,識別子の2文字目以降にはカテゴリMnの文字が使えることがわかります。識別子は先頭に数字が使えない言語が多く,先頭とそれ以降とで扱いが異なるのが普通ですが,特に結合文字は2文字目以降でないと意味がありません。

私が最初に見たウェブの記事は,識別子先頭と後続との違いを考慮していなかったようです。

ちなみにPython2では識別子はASCIIの英数字とアンダースコアに限定されていたようです。

どういうときに使われるか

さて,変数名にアルファベット以外が使えるといっても,通常のプログラムでは用いないことがほとんどでしょう。ではどういうときに使われるか。

フレームワークなどで,入力ファイルから自動生成するような場合が一例に挙げられます。Pythonのポピュラーなライブラリpandasでは,CSVファイルを簡単に読み込んで様々な処理ができますが,その中で以下のようにデータ項目にアクセスできます。

>>> import pandas as pd
>>> df = pd.read_csv('sample.csv')
>>> df
   ID      名前        生年月日
0   1    Taro  1980-10-11
1   2  Hanako  1981-11-12
>>> for row in df.itertuples():
...   print(row.名前)
...   print(row.生年月日)
... 
Taro
1980-10-11
Hanako
1981-11-12

最後のforループで,「row.生年月日」のように,named tupleの機能によって読み込んだCSVファイルの列名からデータにアクセスしています。

余談

Unicodeにいろいろな文字があるので風変わりな見た目のコード,例えば楔形文字を使って 𒐪 = 8 のようなコードを書くこともできますが,あとで困るかもしれないのでほどほどに。

拙著『[改訂新版] プログラマのための文字コード技術入門』(技術評論社,2018)についての感想で,初版にAppendixとして入っていたSKKとEmacsによるJIS X 0213対応の話が無くなっていることを惜しんでくれているものがありました。

これは初版執筆時に著者(私だ)がEmacsとSKKを使ってEUC-JIS-2004のプレーンテキストとして原稿を書いていたことを紹介し,当時の一般的な日本語入力環境が抱えていた問題点をこれによって解消できることを説明したものです。

当時の日本語入力環境というのは,おおまかにいえばJIS X 0208の第1・第2水準漢字に制約されており,それ以外の文字は入力できないか,できたとしても単漢字変換や文字パレットのような使いにくい方式によるしかないというものでした。そういう状況を改善し,現代日本で使われている文字は第1・第2水準漢字に限らず,分け隔てなくストレスなしに使えるようにするということが,EmacsとSKKでは2000年のJIS X 0213制定後まもなくして実現されていたのです。それがJIS X 0213という規格の狙いでもありました。

本書はその性質上,JIS X 0208にない文字をふんだんに含んでいるわけですが,その執筆のためにEmacsとSKKの組み合わせが絶大な威力を発揮したのです。

ただ,初版刊行後,何年も経つうちに一般的な日本語入力環境も大きく進歩して,EmacsとSKKを使わずとも同じようなことはだいぶ可能になりました。いま私がこのブログを書くのに使っている環境でも,「とかられっとう」と打てば「吐噶喇列島」に変換され(噶はJIS第3水準),著作権記号「©」も「ちょさくけん」等の言葉から変換でき(JIS X 0213で追加された非漢字),「きもと」と打てば「生酛」に変換できる(酛は第3水準)。Macに至ってはJIS X 0213に収録されたアイヌ語表記用片仮名を用いた本格的なアイヌ語入力方式が実装されており,ローマ字「cep」から「チェㇷ゚」を入力できるようになっています。それは,JIS X 0213が目指したあるべき進歩の道でした。

そこで,このAppendixはもはや現在の状況にそぐわないと判断し,改訂新版からは取り除くことにしたのです。

ただ、著者としてはこのAppendixを気に入ってもらえたことは大変嬉しいのです。多分、私が重要だと考えていたところが詰まっていて、今読み返しても力を感じる文章でもあるからでしょう。その辺を汲み取ってもらえたのか,編集者は本編の文章の脚注としてこのAppendixのごく短いダイジェストを挿入してくれました。

もっとも,今の日本語環境が全然問題ないかというとそうでもなく,Unicodeに色々な文字や記号が収録された結果,文字入力時に「意図にふさわしいコードが入力されているのか」を容易に判断できないことも増えています。先の著作権記号にしても,絵文字スタイルが変換候補に出てきたり,著作権とは異なるただの丸付きC (U+24B8)があったりして、判断に困ります。こういう点は,文字コードの「一意な符号化」という観点から問題があります。SKKには「$」を打鍵するとカーソル位置の文字の符号位置を表示する機能があり,そういう入力支援の面でアドバンテージがあります。

公共図書館等で本書初版を所蔵しているところも多いようなので,どんな内容だったか気になる方は初版のAppendix A.5をチェックしていただくのも良いと思います。

「エンジニアHub」にて記事を執筆しました。「文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう!」として公開されています。

若手エンジニア向けのWebメディアとのことで、プログラミング上の注意点にフォーカスした内容になっています。コード例にはJava, Python, Rubyを用いています。

拙著をすでにお読みの方には復習となる内容ですが、まだの方はこの機会に是非お読みいただければと思います。記事の最後に拙著『[改訂新版]プログラマのための文字コード技術入門 (WEB+DB PRESS plusシリーズ)』の版元へのリンクも設定されていますので、興味を持たれた方には書籍の方もお読みいただければ幸いです。

当記事編集担当の方には「とても品質の高い記事」とのことで感謝のお言葉をいただきました。読者のお役に立つことを願っています。

ブログをさぼっている間に時間がずいぶん経ってしまって、授賞式がもう1年半も前のことなのですが、本業の方で情報処理学会から山下記念研究賞という賞を頂きました。大変光栄なことで、これを励みにより良い研究をしていきたいと思います。

受賞した研究は、複雑化した情報システムの現状を理解する活動に役立てるためのもので、私の著書の題材である文字コードとは全然関係ないのですが、ややこしくなってしまったものを解き明かすということが動機となっている点では共通しているといえるのかもしれません。

受賞者には賞状とメダルが贈られます。メダルの柄はチャールズ・バベッジのDifference Engine、19世紀のイギリスで開発された一種の機械的な計算機です。コンピュータの元祖といえばENIACを思い浮かべる人が多いと思いますが、絵になるのはこちらということなのでしょうか。

DSC01044-2.jpg

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

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

最優先: 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で符号化できるようになっていたらこのような措置はとられれなかったかもしれません。

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

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はその有力な選択肢といえます。

私はだいぶ前からiPodを使っていて、つまりはiTunesで音楽データを管理しているのですが、最近はAndroidスマホを使っています。外出するのにiPod Touchとスマホという同じようなものを2個持ち歩くのは如何なものかと思っていました。iPhoneにしろという声もあるでしょうが、スマホでFeliCaの機能をよく使うのでその選択肢はありません。

iTunesの曲をAndroidで聴くにはどうしたらいいか。多分やり方は色々あるのだろうけど面倒くさそうだなという先入観が先に立っていました。

ところが、Google Play Music を使えばそれができそうだと最近ようやく分かりました。

Google Play Musicは有料聴き放題サービス(だけ)ではない

Google Play Musicは最近テレビCMもよくやっているのですが、そのせいで、定額制の音楽聴き放題サービスなのだと思っていました。そして、別に興味ないやと思っていました。そのサービスはもちろん提供されているのですが、実はそれだけではなかった。

私にとってのGoogle Play Musicの要点をあげると下記2点です。

  • 基本機能は無料で使える (聴き放題サービスは有料)
  • 自分のPCに持っている音楽データをサーバにアップロードしてスマホなどで聴ける

これを使ってPCに入っている曲をスマホで聴けるようにすれば、わざわざスマホとiPodを一緒に持ち歩かなくていいのではないか。

Google Play MusicにiTunesの曲をアップロードしてみた

Google Play Musicのウェブサイトにアクセス、Googleアカウントでログインしてアップロードできます。ミュージックマネージャというアプリをダウンロードして実行することになります。私はMacで行いました。

ウェブサイトの案内に沿っていけば困るようなことは何もないので、手順の説明は省略します。というか、あまりにスムーズすぎたので何も覚えていません。

今回アップロードしたファイルには、iTunes Storeで購入したもの、CDからリッピングしたもの、Moraで購入したものが含まれます。いずれもiTunesで管理していたもので、問題なくアップロードできました。アップロード元を選ぶ際に、iTunesで管理されている音楽を指定することができます。

ただし、DRMのかかっているものはアップロードできません。私の持っているものでは、何年も前にiTunes Storeで購入したものがDRMつきなのでアップロードできませんでした。これはAppleのiTunes Matchというサービスを使えばDRMフリーのファイルに置き換えられるそうですが、iTunes Matchの利用には料金が発生するようです。

今後新たに曲が増えた時どうやって同期すればいいかという問題がありますが、ミュージックマネージャの環境設定で「iTunesに追加した曲を自動的にアップロード」という設定が可能です。これにチェックをつけておけば、何もせずともサーバにアップロードされます。

Androidスマホで聴いてみる

あとはスマホ側でアプリを使ってアップロードした音楽を聴いてみます。Google Play Musicのアプリは私のスマホに最初から(?)入っていました。

このアプリは基本的にストリーミングで聴けますが、外出先でそれはつらいので、あらかじめダウンロードして聴くこともできます。Wi-Fi接続時のみストリーミングとか、ダウンロード済みのものだけ表示するという設定も可能です。

iTunesのプレイリストも取り込んでくれるし、iTunesに新しく入れた曲も先の自動アップロードの設定で勝手にサーバに取り込まれます。(スマホ側では「更新」ボタンを押すと同期できる模様)

割とあっさり、理想的な環境になりました。こんなに簡単だったとは!

イヤホンが問題だったりする

これでiTunesの曲をいつでもスマホで聴けるようになりました。が、実際の使用上、問題になるのがもうひとつありました。イヤホンです。

iPod Touch用のリモコン付きのイヤホンでは、リモコン操作で停止・再生、次の曲・前の曲への移動ができて、よく使っていました。同じことがAndroidスマホでもできるかどうか。

Android対応のイヤホンを買って試してみました。製品やアプリにもよるのかもしれませんが、私の試した組み合わせでは、停止、再生、次の曲へ移動はできたものの、前の曲への移動ができませんでした。うーむ惜しい。

アプリによる改善も含めて、イヤホンの件は今後の課題として試してみたいと思います。

最近のブログ記事

クリエイターが知っておくべき著作権の解説書を読んだ
ちょっと長い書名の本、『クリエイターが知…
いつのまにか日本の医療業務を支えていたEUC-JIS-2004
日本医師会のORCAプロジェクトによる「…
Time Capsuleでフレッツ光を使う設定
アップルのバックアップ装置兼無線LANル…
Evernote リマインダー考
Evernoteはあまりヘビーに使いこな…
全国の地名のローマ字
当サイトで新しいデータを公開しました。 …

広告