piu lentoの日々 (piu lento days)

大げさな題だ。

Ceronで思わぬ情報を目にして少し慌てた。: Blu-rayディスク(以下、BD)はCD・DVD用の不織布ケースで保管すべきでないとのこと。BDの表面(読み取り面、以下同)の保護層はDVDなどより薄いため、CD・DVD用の粗い不織布では傷が付いたり保護層が歪むことがあるので、BD対応の不織布にすべきだそうだ。 (→ 参照)

僕は そんなことは全く知らずにCD・DVD用のファイルケースに入れていた(BDのリーフレットに書いてあったのかも知れないが、読んだことがないｗ)。まあ、BDは ほとんど持っておらず(全部で12枚。うち1枚はボックスに入っていたので対象外)、観ることも まずないが、一応、持っているものは ちゃんと保管しておきたいので、どうなっているかチェックした。

結果は大丈夫だった。目視だけだが、表面に傷や歪みはなかった。ただ、今後もずっと仕舞ったままだろうから、駄目になるリスクを減らそうと思った。

事後の推測だが、実際には粗い不織布でも問題ない気がする。というのは、確かにBDの保護層は薄いけど、そんなことで駄目になったら全く手軽に扱えず、今までにかなり多くの問題が起こっているはずだけど、聞いたことがないからだ。薄くても大丈夫なのは、メーカーが強力な保護層を開発したおかげではないか。

調べたら、TDKの技術(DURABIS)が採用されたそうだ。

そして、保護層は一種の塗料だと考えると、(塗料は乾燥後に硬くなるものと柔らかいままのがあるが、)硬いものなら不織布で押された程度で跡が付く(歪む)とは思えない。傷については分からないが、頻繁に出し入れしなければ大丈夫だろう。

一つ気になるのは不織布の材質だ。不織布は「布」とは書くが、実際にはプラ(PEやPPなどのようだ)なので、それと保護層が(化学的に)反応したら駄目で、跡が付くだろう。「BD対応」というのは実は そのことかも知れないと、想像した。

それが正しいとしたら、BD対応の不織布でも、材質やBDとの相性によっては「くっ付く」可能性があるだろう。ただ、表面が平坦なので跡が付きにくく(薄く広く付く)、読み取りの問題が起こりにくいのではないだろうか。

CD・DVD用の不織布のケースで更に安全を見るとしたら、ディスクに強い力が掛からないように、ケースの左右を押さないようにすればいいのではないか。

上に書いたように ほとんど再生することがないので、BD対応の不織布を使ったケースを買うのはもったいない。最初は、いかにも柔らかそうな、ティシューをディスクと不織布の間に挟むことを考えたが無理があった。ティシューを均一に挟むのは難しく、しわや段差が却って良くなさそうなので止めた。

それから、クリーニングのカバーの不織布(上の写真の背景の白)は目が細かそうなので試そうと思ったが、ティシュー同様に挟むのが難しそうだし、本当にBDに いい(目が充分細かい・柔らかい)のか分からないので止めた。

結局、ディスクに何も接しなければ良いだろうと思い、スピンドルケースに入れ、軸の余分なところに段ボールで作ったスペーサーを挟んで ぐらつかないようにし、ケースの前後(元の上下)を挟んで垂直に立てて保管することにした。

却って悪いことにならなければいいが・・・ まあ、何年か経たないと分からない。

ところが、書いたあとで考えたら、PCの内蔵ドライブは寿命で壊れてしまって(ポータブルのDVD用しか残っていない)、そもそもBDを再生できるドライブがない。つまり、元々再生できないんだから気にする必要は なかったという、大山鳴動オチかも知れないｗ

チェックをした時に気になったのは、(BDだけではないが、)クローゼットの中の段ボールに まとめて入れていたボックス物や紙ジャケが湿気気味でカビが生えそうな感じだったことだ。※ ただ、同じように段ボールに入れていたファイルケースの中は乾燥していたのが不思議だが、ボックスなどは紙製のために湿気を吸収しやすいせいかと思っている。それで、少し高いところに移し、段ボールの口を開けておいた。: 僕としては、こっちの今後が気になる。

※その後、一部の内側にカビが生えていることが分かった。いつ生えたかは不明(旧居か こっちか)。どうすればいいのだろうか?

そういえば、少しだけど以前からクローゼットの中がカビ臭かったので、こっちで? うむ、なぜ・・・

「濁音に苦労した話」の続きである。元の稿に加筆したように、SpotifyのAPIで取れる曲情報でもcombining charactersが使われている(= 本体と(半)濁点が分離している)場合があることが分かった。

確かに、APIとそれ以外で別の情報を格納して別々に出すのは無駄だし、合理的でない。

表示は文字列が綺麗に出ればいいが、APIで取った曲情報は自作の音楽再生履歴記録システム MlhiのDBに格納しているので、今ひとつ良くない。というのは、今はまだ完全でない(イマイチな)ので余り使っていないが、将来は自分が聴いた曲をフレキシブルに(要するに、手軽に思ったとおりに)検索できるようにする予定で、その時に、combining charactersの濁音や半濁音を含む曲が出て来ない可能性があるからだ。

そういえば、以前、なぜか検索出来ない曲があったが、それだったのかも知れない。

(1/27 14:55) ちなみに、DBを調べたところ、曲情報(タイトル、アーティスト名、アルバム名、アルバムアーティスト)のいずれかにcombining characters(濁音、半濁音)が使われているものは、延べ27曲だった。DB全体は約1万曲なので、割合は約0.3%未満と少ない。ただ、僕は洋楽やクラシック音楽を聴くことが多く、曲情報が英語のものが多いから、日本の曲での割合は数%くらいではないか。

これを解決するには、以下の方法が考えられる。

1. DBに正規化した曲情報を格納する。
   • 今までにDBに格納した内容は正規化する。
2. 検索時に、検索文字列とDBの内容を正規化して比較する。
   • DBには、取得した情報をそのまま格納する。
3. × 検索時に、検索文字列として、正規化したものとそうでないものを両方指定する。
   • 正規化された文字を逆変換(分離)するのが面倒そうだが、uconvでできそうだ(本当?)。
   • 曲情報に正規化されている文字と そうでないものが混ざっているので、検索パターンが多くなり過ぎる。

Bが筋が良さそうだが、結構面倒そうだ(そもそも、DBに使っているSQLiteはUnicodeのこういう処理に対応しているのだろうか??※)。一方、前者は やればできそうなので、そうすることにした。

※ sqlean: All the missing SQLite functionsというソフトがあり、それは限定的なUnicode処理機能(upper/lower, like, unaccent)を持つので、SQLite自体は対応していないようだ。

ここで問題になったことがある。: 前の稿に書いたように、uconvで正規化すると、かな に正規化漏れが起こるのと、漢字の旧字体が新字体に変換されてしまう。前者は自作の処理(テーブル変換)で対応できているが、後者に対応するには、日本語の文字(漢字)を正規化しない必要がある。※

※幸い、日本語の漢字には濁点のような着脱可能な要素が なさそうなので、正規化対象から除外するだけで良い。ただ、例えば「辶」(しんにょう)のように、場合によって個数が違う点のような要素はある(→ 興味深い読み物があった)。が、それは純粋に文字の形の問題と思われ、意味や読みは変わらないので別件としたい。

他には、たまに、富と冨ののような着脱可能っぽい点はあるが、それらは同じ文字らしいし、相互に入れ替えて意味を変えることはないので(しんにょうと同様に)ヨシ、だ。

そもそも、今までに、(遊びをのぞいてｗ)漢字に かな のように点や丸を付けて意味などを変えたことはないし、そういうことを教わったこともないから、それで良さそうだ。

UnicodeやICUに不慣れなので、日本語を除外して正規化することができるのか分からなかったが、いろいろ調べたら できそうなことが分かった。

Unicodeにはscriptという概念があり、Latin文字(いわゆる英字)、カタカナ、ひらがな、漢字※のようなカテゴリ(Unicodeにはcategoryという概念があるが、それではない)を示すことができる。それを使って、uconvの正規化ルール(日本語除外フィルタのようなもの)を指定すればできそうだ。

※実際には、Unicodeの資料では漢字は"Han"と書かれており、おそらく中・日・韓の漢字を一緒にしたもの(≒ CJK Unified Ideographs)を差していると理解している。

具体的には、以下のコマンドで日本語(正確には、漢字、ひらがな、カタカナ)以外の文字を正規化できるはずだ。

uconv -f utf-8 -t utf-8 -x '::[ [:^Katakana:] & [:^Hiragana:] & [:^Han:] ]; ::nfc;'

処理内容は、-xの最初のルール(最初の ; まで)でカタカナ、ひらがな、漢字を除外し、残ったものに正規化(NFC)を実行する("::nfc")。

実は、上の処理には欠陥がある。おそらく韓国語(ハングル文字)はcombining charactersをバリバリ使っているはずだが、それも除外されるのではないか(ハングル文字がHanに含まれているとした場合: 実際には、scriptには"Hangul"というのがあるから、ハングル文字はHanには含まれていなさそうだ)。

が、僕の好みからして、曲名などが韓国語で書かれた曲は聴かないだろうから、とりあえずは良しとする。あと、中国語には簡体字も繁体字もあるし(それは関係ないのかも知れないが)、どうなのか想像も付かないｗ

上の処理は、以下のテストパターンで うまく行った。

• パ が 神: 正規化されずに出た。
• Ā (A + U+0304: Combining Macron): Ā (U+0100: Latin Capital Letter A with Macron)になった。※

※Āを使ったのは たまたま最初に できた(macronなるものが付いた単体のĀがあった)からである。この文字がどういう意味なのか全く分からないし、実際に使われるのかも知らない。

と、出来そうになって気分がいいところで、「残りはあとで」にしたｗ

参考にしたページは以下である。

• ICU Documentation: General Transforms
• ICU Documentation: Transform Rule Tutorial
• Programming with Unicode: 3. Definitions
• Regular-Expressions.info: Unicode Regular Expressions

uconvに指定するルールの書き方は最初と2番目(特に後者)が参考になった。最後に残った謎(どうやって日本語を除外するか? そうするパターンをどうやって書くか?)を解く鍵になったのは、最後のUnicode Regular Expressionsだった。

それについては最初の2つを丹念に読めば分かったのだろうが、余りにも知らない概念が多いうえに機能が多過ぎてチンプンカンプンだった(→ 読む気が起こらなかった)。一方で、-Regular Expressionsは馴染みの正規表現の話なので良く分かった。※ 更に、Hanが かな を含むという思い違いに気付かせてくれて、上のルールが出来た。

※実際、このページを見付けた切っ掛けは、ICU(uconv)のルールが全然思ったように動かないので諦めて、grepで正規表現で除外しようと思い、「『漢字全部』の うまい指定」があればと思って"Unicode regexp"で検索したことだ。

ちなみに、grepは-PオプションでUnicodeに対応した動作(PCRE)になる。

PS. Unicode(ICU)の処理には、カタカナ→ローマ字みたいなものがあって(→ Script Transliterationの表の「キャンパス: kyanpasu」)、「誰が使うの?」と思う。ちゃんと動くのならいいが、正規化みたいに中途半端だったら実装するだけ無駄だし、ほとんどの開発者は知らないので、使われない気が・・・ (いやいや、僕が無知なだけだよね)

PS2. こういう細かい話は嫌いだけど好きだ。: 実装や確認は面倒でやりたくないけど、豆知識的に調べるのは好きだ。発展したのがタモリかｗ

Chromeブラウザはメモリを大食いするのでメインには使っていないが、追跡されたくないとかプロファイルを完全に分離したい場合などに使っている。それが数日前から、妙な感じになって居た。普通は、タブを多く開くと使用メモリ量が多くなって警告メールが来る※はずなのが、来なくなったのだ。

※システム全体がメモリ不足になるのを防ぐために、定期的に「大食いアプリ」のメモリ量をチェックして出すようにしている。

うるさくなくていいけど却って気持ち悪いのでｗ、手で使用メモリ量を確認したら確かに少ないようだ。そういえば、近頃バージョンが上がったので改良されたのかと思った。

ただ、不思議なことに、調べてもそういう情報がない。Chromeのリリースノートのようなページには、「詳細は追ってブログに出る」のようなことが書いてあったので、これから分かるのかも知れない(→ 調べると、97での変更内容は山ほどあるので出なさそうだ)。あるいは、Linux版(の情報)は どうでもいいのかも知れないｗ

なお、一つだけ、外部のページ"Google Releases New Version of Chrome With Extra Security and Memory Safety Features"(2022/1)に近いことが書いてあった。以下に引用する。

... it is important to note that Chrome 97 also incorporates several upgrades to how it uses and manages memory. A common complaint that several users tend to have about Chrome is that it uses too much memory, and to fix this the new version of Chrome is no longer going to keep user profiles and settings saved after it is exited completely which will prevent these settings from using RAM in the background.

ただ、良く読むと終了後の話のようなので、違うのかも知れない。

「それじゃ、同じChromeベースのVivaldiも?!」と期待して調べたら、残念ながら大食いだった。大体、1タブで370MBくらい食う。Firefox(96.0.1)は約230MBなので、約1.6倍だ。そして、最新のChrome(97.0.4692.99)を調べたら約220MB/タブと、わずかながらFirefoxより少ない。

Vivaldi(5.0.2497.48)のUA文字列には"Chrome/96"とあるから、ベースは一つ前のようで、メモリ削減の改良がされていないのだろうと想像した。

ここで、省メモリだという評判のあるEdgeを思い出した(これもChromeベースなので、省メモリになっているかも知れないとも思った)。大嫌いなMS製だが、もし かなり省メモリなら(我慢して)使うのもありだと思って試したら、約370MB/タブ(Edge 98)とVivaldiと同様だったのでがっかりした。

どうやら、省メモリなのはWindowsでの話のようだ。想像だが、ChromeやVivaldiもWindows版とLinux版ではメモリ管理方法が異なっていて、Linux版は ずさんでメモリを浪費しているのではないか? あるいは、Windowsではアプリの使用量は少なく見えるが、実際には陰で大量に使っているのかも知れない。

まあ、いずれにしても、Edgeを使う意味は全くないことが分かった(そもそも使いたくないから、それでいいｗ)。

参考までに、以下に、各ブラウザのタブ1個当たりのメモリ使用量(増分)をまとめる。

• Firefox(96): 約230MB/タブ
• Chrome(75): 約220MB/タブ
• Vivaldi(5): 約370MB/タブ
• Edge(98): 約370MB/タブ

※すべてLinux版で、約6個のタブを開いて増加したメモリ使用量から求めた。メモリ使用量はpsコマンドの"RSS"(resident set size)を使った。

結局のところ、Chromeの使用メモリ量が減ったと言っても、ようやくFirefox並みになっただけなので、すぐに移る意味は ないことに気付いた。そもそも、Chromeには標準で縦のタブバーがないなど使いにくいので、移るとしてもVivaldiだ。それが更新されて省メモリになるのを待ち、それから使い勝手で判断することにした。

Vivaldi以外に ほのかに期待しているのは、同じく大食いのElectronやSpotifyも使用メモリ量が減らないかということだ。それらもChrome(chromium)を使っているはずなので、改良の効果があるのではないか。

以前にも書いたが、MozillaにはThunderbirdでも嫌気が差しているので、Firefoxから移れば離脱できそうだ。Mozillaは もう少し、ユーザーや開発者が喜ぶ(せめて、怒らない・使う気を なくさせない)ような進め方を考えればいいのにと思う。

夏が来た!
夏が来た!

上下の違いが分かる方は居るだろうか?: 同じに見えるけど違う。ブラウザ(かなり古いもの?)やフォントによっては、分かるかも知れない。

答えは、題にあるように、濁音「が」の造りである。今まで知らなかったのだが、Unicodeのひらがな・カタカナは、濁音や半濁音を半角カナ的に 本体+(半)濁点 のように分離して記述し、なおかつ くっつけて一文字のように表示することができる。Combining charactersとかいって、日本語以外でも そういう処理ができるとのことだ。

上の例の「が」は、最初の行はcombining charactersで 「か」+「”」(← 見にくいのでダブルクォートにした) で、2番目は普通に書いてある。全く区別できない。※ 良く出来過ぎていることに、マウスでコピーする時は1文字として扱われるし、等幅フォントのエディタやターミナル(コンソール)でも くっついた状態で表示される。

※おそらく、フォントの字体としては、本体に濁点を加えたものが濁音の文字になっており、combining charactersの濁点は それを再現するような位置に表示されるようにできているのだろう。ただ、この方式ではすべての濁音で濁点が同じ位置に置かれるが、そこはフォントの 描き方でうまく合わせたのだろうか。

↑ ちょっと確かめたら、そう単純なことではないようだ。というのは、下の左図のように、「ヾ」と「ヷ」では濁点の大きさや形が明らかに違うからだ。ということは、フォントに濁点を付けるための情報があるのか、表示する時に、combining charactersの濁点が付く場合は自動で濁音の字に変換されるのか。見たところ、濁点の形が微妙に違う気がする(特に、線の太さ)ので前者なのかも知れないが、本当に そこまでやっているのかという気はする。どちらにしたって、「余計なところに力を入れ過ぎていないか?」と言いたくなる。 (1/22 5:18)

その後、文字に色を付けて濁点を重ねて比べたところ(下の右図)、同じ文字の濁点の形状は、combining charactersでもそうでなくても同様だが、異なる文字同士では異なっている(この例では、「ヾ」の濁点は「ヷ」のより大きい)ことが分かった。 (1/22 14:19)

僕が見付けた唯一の識別方法は、エディタ(ペーストする)で濁点側から1文字削除することだ。Combining charactersの場合は濁点だけが消えるが、そうでない場合は全部消える。

そして、今回の切っ掛けに関係することは、どういう訳か、Spotifyで出る曲情報(タイトル、アーティスト名、アルバム名)※の中に、本体と濁点・半濁点が分離して記述されたものがあるのだ。全部ではなく、たまにあるのが不思議だ。特定のレーベルという訳でもない気がするが、老舗(例: ビクター、ソニー)や昔の曲に多い気がしている(と書きつつ、1990年代の(一番下の図)もあるので関係ないかも)。

想像だが、レーベルが曲情報を電子形態に登録する際、打ち込む人の癖などで分離してしまったか、それ以前の半角カナも使うシステム(そういうものがあったかは不明)から変換した時に、濁点・半濁点を統合しないままだったのではないか。

※詳しく確認していないのだが、同じSpotifyでも、アプリから取れる情報(Dbusのイベントで取れるもの)とAPIで取れる情報の記述が異なるようだ。前者は分離していることがあるが、後者はそうではない。 ← どちらも同じように分離している場合があることが分かった。例: 飯島真理 「palette(パレット)」(2007)の「パ」。 (1/25 16:31)

それで何も問題が起こらなければ気付かずに過ごせたのだが、自作のSpotifyのミニプレーヤーMinispが駄目だった(これが発端である)。次の左図のように、combining charactersである「が」のあとに空白が出来て、半角カナ的な見苦しさになってしまっている。今見ると、本体(か)と濁点の間隔も少し広い。本来は右側のようになるべきである。

どうやら、表示に使っているTcl/Tk(wish)がcombining charactersに対応していないようだ(調べた限りではTcl/Tkのページの"Unicode combining characters"の項にはコメントだか状況説明が書いてあるだけのようだし、 そういう設定や属性などがなかったので非対応なのではないか)。

これを何とかしようと調べたら、Rubyのソフト(unicode_utils)の紹介が出て来たものの、インストールするのが面倒なので試行錯誤したら、既存のプログラム iconvでは駄目だったものの、既に入っているパッケージ icu-devtoolsのuconvでできることが分かった。

Combining charactersを まとめる(くっついた文字にする)のは「正規化」という処理で、uconvのマニュアルに例(下記)が書いてあった。

uconv -f utf-8 -t utf-8 \
  -x '::nfkc; [:Cc:] >; ::katakana-hiragana;'

上は他の処理も混ざっているので、以下の例のように、曲のタイトル、アーティスト名、アルバム名をそれぞれ正規化してから表示するようにし、上の右図のように解決した。

echo "夏が来た!" | uconv -f utf-8 -t utf-8 -x '::nfc;'
→ 夏が来た!

※正規化処理は、マニュアルではNFKCだが、調べたらNFCのほうが良さそうなので そうした。この辺りは全く詳しくないので手探りだ。また、上のコマンドでnfc前後の :: と ; は なくていいようだが、例にならって付けている。

今 上の参照ページを読んだら、NFCでも今ひとつな場合(「例6: 神と神」)があって気に入らないが、仕方ない(レーベルも、旧字体は余り使わないだろう)。一番いいのは、正規化しなくてもwishで綺麗に表示できるようにすることか。

あるいは、(一番最初に考えた方式の、)uconvでなくプログラムで変換するのがいいか。ひらがな とカタカナだけの対応になるが、濁音・半濁音と そうでない音の文字の順序には概ね規則性(元の音のコード= 濁音-1, 半濁音-2)があるので、それでcombining charactersを くっついた文字に置換するのだ。これなら漢字の旧字体は問題ない。

というか、いちいち計算するのでなく、今の追加処理のテーブル方式で全部処理するほうが良さそうだ。濁音・半濁音は多くないから、テーブルを作るのは容易だ。 → 基本的に、uconvを使うのを止めて追加処理だけにすればできるので、早速そうした。

この方式なら、あとから追加変換が必要になことが分かっても、変換テーブルに追加するだけなので容易だ。 (1/21 17:05)

ところがどっこい!ｗ

下の左図の「グ」のように、なぜか、頑固に正規化できない文字がある(図で「ベ」は くっついているので、処理されていない訳ではないことが分かる)。

更に調べたら、どうやらuconv(使っているのは uconv v2.1 ICU 66.1)が正規化しない(素通しする)文字があるようだ。ひらがな・カタカナの濁音・半濁音について調べたところ、以下の文字が駄目だった(正規化されずにそのまま出て来た)。

ど ば べ ぼ ぱ ぺ ぽ ガ ギ グ ズ ゼ ゾ ダ ヷ ヾ

ところで、上の最後のほうにある見慣れない文字、Unicodeにある「ヷ」、「ヸ」、「ヹ」、「ヺ」って実際に使われたのだろうか? どういう読み?? 謎だ。 (→ 4/1に出た、参考になるページがあった。)

その後、PHPの国際化関数のTransliteratorのtransliterator_transliterate()でuconvと同様の正規化処理を試したら、なぜか上の文字も正規化できた。よって、下ではICUやUnicodeのライブラリの問題と書いているが、uconvの問題の可能性が高い。だが、どうしたらこういう抜けが起こるのか見当がつかない。 (1/27 16:08)

実際には、原因はuconvではなく、それが使っているICUやUnicodeのライブラリの問題だろう(日本語に詳しくない人が作った??)から、パッケージを(Linuxディストリビューションのものでない、)オリジナルの最新に入れ替えるか、設定とか調整すれば直せる気はするのだが、パッケージの交換は あとあと面倒になるのでせず、設定・調整はuconvなどのマニュアルを読んでも分からない用語が多くて どうすればいいか分からなかったので、以下のような力技で対応した。

1. 起動時(初期化)
   1. uconvで正規化できない濁音・半濁音を調べてリストを作る。
   2. それらの正規化後の文字のリストを作る。
2. 曲情報(タイトル、アーティスト名、アルバム名)を表示する前
   1. uconvで正規化する。
   2. uconvで正規化できなかった文字がある場合は、正規化した文字に置換する。

これなら、将来ICUやUnicodeのライブラリが更新されて、すべての濁音・半濁音が正規化できるようになれば(なんか、永遠にそうならない気が・・・ｗ)、自動的に追加処理が不要になる。

処理を実装し、上の右図のように、駄目だった文字が ちゃんと表示され、(今のところは)一件落着となった。ただ、いつものように、他にも何か問題がありそうなので、表示やログを注視しながら音楽を聴いている。

これ、日本語以外でも あったらお手上げだが、読めなくて気付かないだろうから良し?ｗｗｗ

PS. 中程("1/21 17:05"の辺り)に書いたように、これを書いたあとで、実は、uconvを使うのでなく一番最初に思い付いた単純なテーブル変換方式が一番良かったというオチだった(今のところは)。Unicodeの考えは基本的には いいと思うが、(何かで必要なのだろうが)複雑な概念をいろいろ作り出して、それが日本語や実際の用途に合わない、あるいは完全な実装ができていないために、いろいろなところで苦労してそうなのが残念だ。

元日に実家に行ったら、母が「スマホにしようと思う」とか言い出したので驚いた。そもそも、使えるあてもないのに、なぜそんな考えになったのか分からなかったが、下のまとめを読んで分かった。

【悲報】ガラケー歴20年目のワイ。ドコモから最後通告が届く

ドコモが、ガラケーを持っている人に脅迫的な案内を出しているからではないか。古い端末が修理できなくなるのは当たり前のことで仕方ないが、それとスマフォへの移行は関係ない。ドコモが従来型の端末を出して(あるいは、他社の製品を)、それを紹介するだけでいいのに、余りにも恣意的にスマフォに移行させて、金を巻き上げる魂胆が透けて見える。

この件については、意図しているのか単に頭が悪いのか、以下の異なるものをごちゃまぜにしているように思う。

• ガラケー終了 (メーカーのやる気の問題)
• 3G終了 (電波・キャリアの問題)
• i-mode終了 (ドコモの都合)
• スマフォブーム(に乗じて収益を増やしたいキャリアの魂胆)

最初の2つについては、4Gなどで使える、ガラケーでもスマフォでもない従来型の端末、フィーチャーフォンを出せばいいのだ(今は1機種だけあるようだ)。高齢者はアプリとかの高機能なものは要らなくて、電話機能に加えてメールと写真程度で充分ではないか。

でも、それらすらガラケーの範疇になるのかも知れない。であれば、これまでガラケー・i-mode※で たっぷり稼いで来た責任があるのだから、ガラケーを使いたい人が居なくなるまでスマフォを押し付けようとすべきではない。それと電波(3G→4G)は全然別なのに、分かっていない人には もっともらしい説明になるのが嫌らしい。

これは、良くある詐欺の、「これからは＊が使えなくなるので、これを買って下さい」みたいだ。

※i-modeについては、勝手な(まさにガラパゴスそのもの)規格・仕様(そのために、世の中の標準的仕様と合わないことが多くて移行が難しいだろう)をでっち上げた責任は大きい。ユーザーが不利益を被らずに終了させる責任は大いにある。

その点、Apple・ジョブズ(iPhone)は(いくら大嫌いでもｗ)すごい。まあ、少なくとも3Gがなければできなかっただろうし最初は無理があったけど、標準規格ベースで あれだけのもの(サービスと言える)を成立・普及させたのだ。

例えば、3Gが終わって使えなくなるiPhone(Androidも)の機種はあるが、それらで使えていたサービスが使えなくなることは まずない。対応する機種に換えれば それで済む。ごく当たり前のこと・考え方ではあるが、できない会社は多い。

それにしても、これからしばらくは、ガラケーしか使えないのにスマフォを押し付けられて文鎮化させてしまう、あるいは、詐欺(フィッシング、ガラケー・3G詐欺なんてのも出そうだ)などに引っかかる高齢者、ガラケー難民(?)が増えそうだ。全く無責任だ。

そもそも、高齢者に限らず、今もこれからも「普通の携帯電話」が必要な人・場合は多い※のに、それを切り捨てるのは正しい進み方ではないと思う(まあ、会社自体が正しい進み方をしていたかという疑問はあるが)。

※例えば、「(それしかないので)いつでもどこでもデカくて重いタッチパネル端末を使え」ってのは、無理もいいところだ。

(てな、全然おめでたくない話を年頭から書くのは さすがに気が引けたので保留していたが、日が経った(それでもイライラは減らない)のと、丁度 最初に挙げたまとめが出て状況が分かった気がしたので、出した。)

PS. 母については、以前聞かれて、(本文にも書いた、)従来型の端末があることを教えて居たのに、再びスマフォなどと言い出したので、そこでブチ切れた。たまたま とか高齢だからという訳ではなく、あの人は、昔から人の話を聞き流す(賛成でなくても分からなくても、賛成のような分かったような返事をする)癖があり、それを目の当たりにして、昔からのトラウマが出たような(フラッシュバック?)嫌な気分が続いている。

スマフォに移るにしても、そういう考えになった理由や経緯を説明してくれれば まだいいのだが、あの人は僕が子どもの頃からそれをせず唐突に言い出すので、いつも混乱させられ、嫌な目に遭って来た(説明不足のために、こっちが被害・誤解を受けた)。

あと、ガラケーですらまともに使えない癖に、ある時、「こんなのテキトーに使えば使える」とか口走ったのにも大変ムカついた。テキトーに使える機械なんてない! だったら、スマフォもそうすればいいのに その気はなく、以前僕の余ったものを試すか聞いても乗り気でなかった。「(その癖に、)なぜ今スマフォなんだ!」と、正月から何重ものイライラが爆発した。

(18:25 わずかに変更・修正)