パスワードを忘れた? アカウント作成

yasuokaさんのトモダチの日記みんなの日記も見てね。 最新から新しい日記やタレこみを確認できますよ。

12856427 journal
日記

yasuokaの日記: 「ポケモンGO」における紛争の準拠法 1

日記 by yasuoka

昨日の私(安岡孝一)の日記に対し、いくら管轄が日本の裁判所になっても、「抵触法を考慮することなく、カリフォルニア州法に準拠する」である以上、日本の法律を準拠法にできないのではないか、という趣旨の御質問をいただいた。とりあえず、法の適用に関する通則法第十一条を見てみよう。

第十一条 消費者(個人(事業として又は事業のために契約の当事者となる場合におけるものを除く。)をいう。以下この条において同じ。)と事業者(法人その他の社団又は財団及び事業として又は事業のために契約の当事者となる場合における個人をいう。以下この条において同じ。)との間で締結される契約(労働契約を除く。以下この条において「消費者契約」という。)の成立及び効力について第七条又は第九条の規定による選択又は変更により適用すべき法が消費者の常居所地法以外の法である場合であっても、消費者がその常居所地法中の特定の強行規定を適用すべき旨の意思を事業者に対し表示したときは、当該消費者契約の成立及び効力に関しその強行規定の定める事項については、その強行規定をも適用する。

少なくとも消費者契約法に関する紛争であれば、この強行規定で突っぱねれば「カリフォルニア州法に準拠する」必要は無い。このあたりが日本の消費者契約法の強力なところで、消費者が日本にいる限り、事業者がどういう契約や主張をしようと、日本の法律でカタが付く仕掛けになっている。その契約や主張(の一部)が「無効」であることを、消費者契約法第八~十条あたりをタテに争えばいいのだ。元記事の『「ポケモンGO」利用規約に仕組まれた"ワナ" 用意周到に「責任回避」が準備されている!』(東洋経済ONLINE、2016年7月25日)では、このあたりもちゃんと検討したのかしら?

12855811 journal
日記

yasuokaの日記: 「ポケモンGO」における紛争の管轄地 1

日記 by yasuoka

ネットサーフィンしていたところ、関田真也の『「ポケモンGO」利用規約に仕組まれた"ワナ" 用意周到に「責任回避」が準備されている!』(東洋経済ONLINE、2016年7月25日)という記事を見つけた。何でも、日本の「ポケモンGO」の利用規約には、Nianticに都合のいいことしか書いてないらしい。たとえば、以下の記述。

実際に紛争が起きた場合は、さらなるハードルがある。「抵触法を考慮することなく、カリフォルニア州法に準拠する」とし、日本の法律では争うことができないとされている。

バカバカしい。いくら、そういう「契約」があったとしても、日本の消費者契約法は、そんな甘い作りにはなっていない。しかも、消費者契約法ガラミでの紛争が起こったなら、民事訴訟法第三条の七に従って、粛々と日本の裁判所に訴えを起こすだけのことだ。

そして、そもそも訴訟になること自体を回避するため、「仲裁合意」という項目が設けられている。仲裁とは、紛争を第三者である仲裁人の判断に委ね、その判断に従うという合意に基づき紛争を解決する手続のことをいう。

もちろん、日本にも仲裁法が存在していて、その附則第三条第二項には「消費者は、消費者仲裁合意を解除することができる。」という強力な項目がある。訳の分からない「契約」に書かれた「仲裁合意」など、解除してしまえばいい。

Nianticがそこまでして責任を回避したいのは、気持ちとしてはわからなくもない。ただ、日本の法律を調べもせずに、平気で記事にする東洋経済ONLINEには、正直なところ虫酸が走る。いっそ「住居侵入罪の教唆」あたりでNianticを告発して、さて、どういう反応を示すのか、私(安岡孝一)個人としては見てみたい気がする。

12847843 journal
アメリカ合衆国

yasuokaの日記: クリエイティブ・エイジェンシーが考えるユーザーインターフェースの歴史

日記 by yasuoka

ネットサーフィンしていたところ、郷上亮の「今さら聞けないユーザーインターフェイス(UI)の基本」(freshtrax、2016年7月13日)という記事を、エキサイトニュースで見つけた。何でも

1. インターフェイスの歴史、2. 良いUIと悪いUIの違い、3. UIのこれから、という3つのセクションに分け、インターフェイスの本質をまとめた。

という記事らしいが、中でも「1. インターフェイスの歴史」のデキが特に悪い。たとえば「歴史を変えたユーザーインターフェイス達」のこれ。

黒電話の「ダイヤル」
驚きかもしれないが、この黒電話の「ダイヤル」もれっきとしたインターフェイスである。このダイヤルの発明によって“クランクハンドルを手で回す”なんていう今では考えられないような手間を省くことが出来、人間と電話機との窓口として大活躍した。

何が言いたいのかサッパリ理解できない。「ダイヤル」は相手の電話番号を回すためのもので、「クランクハンドル」は電話機の蓄電池に充電(ないしはベルを鳴らすために発電)するためのものだ。私(安岡孝一)の記憶する限り、1893年12月にLexingtonで導入されたCommon Battery Systemが「クランクハンドル」を無くした嚆矢だが、その時点ではもちろん「ダイヤル」ではなく、それまでと同じように交換手を呼び出していたはずだ。

iPodの「クリックホイール」
そのダイヤルを音楽プレイヤーに持ち込んだのがスティーブ・ジョブズである。iPodに搭載された「クリックホイール」も人間と音楽プレイヤーをより密接に繋げることに成功した歴史的なインターフェイスだと言えるだろう。

アメリカ贔屓なのは仕方ないのだろうが、UIとしての「クリックホイール」の話をするのなら、知的財産高等裁判所平成25年(ネ)第10086号くらいは目を通しておくべきだと思う。

「QWERTY配列」
当時のタイプライターには「隣同士のキーを高速で打つとジャムる」という致命的な弱点があった。そこで良く使われる単語をリストアップし、出来るだけ隣同士のキーを叩く必要が無いようにして結果生まれたのが「QWERTY配列」である。これも人間とタイプライターとの距離をより密接にしたと言えるだろう。

「当時」っていつ? 「良く使われる単語をリストアップ」したのは誰? 「出来るだけ隣同士のキーを叩く必要が無い」はずなのに、どうして英語で頻度が高い「TH」や「ER」は隣り合ってるの? 『On the Prehistory of QWERTY』(ZINBUN, No.42 (2011年3月), pp.161-174)でも指摘しておいたはずだけど、読んでないのかしら?

まあ、このbtraxっていうクリエイティブ・エイジェンシーでは、過去の歴史をちゃんと調べずに、「ユーザーインターフェースの歴史」とやらをデッチ上げるのが趣味なのだろう。ただ、不思議なのは、この「今さら聞けないユーザーインターフェイス(UI)の基本」という記事は、日本語版だけがあって英語版や中国語版は無い。日本人だけを騙そうとしてるのかしら?

12846958 journal
日記

yasuokaの日記: KS X 1001で重複している262組530字

日記 by yasuoka

7月9日の日記に続いて、KS X 1001:2004のオンラインPDF版を見ていたところ、附属書2表2「부호값이 2개 이상인 한자」が全体的におかしいことに気づいた。ここには本来、262組530字が掲載されているべき(cf.李春澤: 韓国標準規格と日本工業規格の漢字について, 学術情報センター紀要, 第3号(1990年9月), pp.21-47)なのに、実際には226組458字しか掲載されていない。私(安岡孝一)が個人的にチェックしてみたところ、串喇癩蘿烙珞酪欄襤拉秊捻怒露鷺菉尿壘肋凜菱濾殮簾囹怜玲羚聆零了淪裏裡燐璘粒がぬけていて、則(「칙 F6CE」が2つ並んでいて意味不明)が紛れ込んでいる。うーん、どういう意図があるんだろ?

12843605 journal
政府

yasuokaの日記: 「空家等に関するデータベース」におけるマイナンバー

日記 by yasuoka

とある経緯で、「空家等に関するデータベース」にマイナンバーが使えるかどうか、私(安岡孝一)個人として検討してみた。この日記の読者の役に立つかどうかは多少疑問なのだが、検討の概要をざっと書き連ねておくことにする。まずは、空家等対策の推進に関する特別措置法第十一条を見てみよう。

第十一条 市町村は、空家等(建築物を販売し、又は賃貸する事業を行う者が販売し、又は賃貸するために所有し、又は管理するもの(周辺の生活環境に悪影響を及ぼさないよう適切に管理されているものに限る。)を除く。以下第十三条までにおいて同じ。)に関するデータベースの整備その他空家等に関する正確な情報を把握するために必要な措置を講ずるよう努めるものとする。

この条でいう「データベースの整備」や「必要な措置」に関しては、『空家等対策特別措置法の解説』(大成出版社、2015年9月)では、以下のように説明されている。

  1. 調査の結果「空家等」に該当する建築物等については、法第11条に基づき、例えば空家等の所在地を一覧表にし、又は地図上に示したものを市町村の内部部局間で常時確認できるような状態にしておくなど、空家等の所在地について市町村内の関係部局が情報共有できる環境を整備することが重要である。
  2. 「データベースの整備」について、その具体的な内容・方法については各市町村の判断に委ねられているが、「データベース」には、空家等の所在地、現況、所有者等の氏名などについて記載することが考えられる。また、これらに加えて、空家等のうち少なくとも「特定空家等」に該当するものについては、「データベース」内に「特定空家等」に該当する旨並びに市町村長による当該「特定空家等」に対する措置の内容及びその履歴についても併せて記載する等により、継続的に把握していくことが必要である。なお、上記情報はいずれも個人情報であり、空家の所有者等の了解なく市町村内から漏洩することのないよう、その取扱いには細心の注意を払う必要がある。
  3. 市町村によっては、その区域内の空家等の数が多い、又は市町村内の体制が十分でない等の事情から、把握した空家等に関するすべての情報について「データベース」化することが困難な場合も考えられる。そのような場合であっても、「特定空家等」に係る土地については、地方税法に基づき固定資産税等の住宅用地特例の対象から除外される場合があり、その点で税務部局と常に情報を共有する必要があることから、2で述べたとおり、少なくとも「特定空家等」に該当する建築物等については「データベース」化することが必要である。
  4. 「その他空家等に関する正確な情報を把握するために必要な措置」とは、例えば、住民等からの情報提供を効果的に活用するための体制の整備などを想定している。

ここで問題となるのが「市町村内から漏洩することのないよう」という部分である。「空家等」は、そこに人が住んでいないから「空家等」なのであって、したがって「空家等の所有者等」の住所は、既にその「空家等の所在地」とは異なっているはずである。もちろん、よその市町村(たとえば息子夫婦のところ)に移っている場合もあって、むしろ、そちらのケースの方が対応が大変なのだ。さらに、共有名義で相続してたりすると、もう目もあてられない。そんなケースについて、市町村をまたぐ「個人情報」に関し、本人(ら)の同意を得るのは、現実には困難(というかほとんど不可能)だったりする。そこで、「正確な情報を把握するために必要な措置」の一つとして、「所有者等」のマイナンバーをデータベースに付加してしまう(つまりは「特定個人情報」にしてしまう)ことで、本人同意なしに取り扱えるようにしたいわけだ。

上記の解説中「地方税法に基づき固定資産税等の住宅用地特例の対象から除外される場合」というのは、地方税法第三百四十九条三の二(最初のカッコ書き)のことだ。

第三百四十九条の三の二 専ら人の居住の用に供する家屋又はその一部を人の居住の用に供する家屋で政令で定めるものの敷地の用に供されている土地で政令で定めるもの(前条(第十二項を除く。)の規定の適用を受けるもの及び空家等対策の推進に関する特別措置法(平成二十六年法律第百二十七号)第十四条第二項の規定により所有者等(同法第三条に規定する所有者等をいう。)に対し勧告がされた同法第二条第二項に規定する特定空家等の敷地の用に供されている土地を除く。以下この条、次条第一項、第三百五十二条の二第一項及び第三項並びに第三百八十四条において「住宅用地」という。)に対して課する固定資産税の課税標準は、第三百四十九条及び前条第十二項の規定にかかわらず、当該住宅用地に係る固定資産税の課税標準となるべき価格の三分の一の額とする。

つまり、「空家等」が立っている土地は「住宅用地」ではないので、いわゆる住宅用地減税が適用されなくなる、ということだ。ただ、この部分の立法措置は、正直ねじれている。土地の所有者と、家屋の所有者が同一である場合には、この措置は効果を発するのだろうが、そうでない場合には本当に効果があるのか疑問だ。しかも、現場としてヤヤコシイのは、「そうでない場合」の方だったりする。土地の所有者を、「空家等に関するデータベース」に記載しておくべきかどうか、という問題が発生してしまうからだ。

その一方、土地や家屋の固定資産税については、もちろんマイナンバーが利用できる(番号法別表第一第十六号)ので、それと「空家等に関するデータベース」をどう関連づけるか、ということになる。ここでヒントとなりそうなのが、空家等対策の推進に関する特別措置法第十条だ。

第十条 市町村長は、固定資産税の課税その他の事務のために利用する目的で保有する情報であって氏名その他の空家等の所有者等に関するものについては、この法律の施行のために必要な限度において、その保有に当たって特定された利用の目的以外の目的のために内部で利用することができる。

この条における「氏名その他の空家等の所有者等に関するもの」に、マイナンバーが含まれうるかどうか、ということになるわけだ。うーん、でも、番号法に「空家等対策の推進に関する特別措置法」が出てこない以上、やっぱり現時点では自治体条例(番号法第九条第二項)に頼るしかないかしら…。

12840222 journal
日記

yasuokaの日記: 「緊」の「又」を「攵」に作る漢字 2

日記 by yasuoka

KS X 1001:2004のオンラインPDF版を見ていたところ、49-44(D1CC)に妙な漢字が入っているのに気づいた。49-44は本来「緊」なのだが、右上の「又」が「攵」に化けているのだ。私(安岡孝一)の手元にあるKS X 1001の旧版(1998年版や2002年版)では、ちゃんと「緊」になっているので、2004年版PDFの「表1」を作った時に文字化けしてしまったと思われる。

ただ、私個人は、この「漢字」に見覚えがある。Batangだ。BatangのU+7DCAには、この「緊」の「又」を「攵」に作る字形が入っていて、かなり閉口した覚えがある。そう思って、KS X 1001:2004オンラインPDF版の48-18(D0B2)を見てみると、案の定「匀」に化けている。48-18は本来「勻」のはずなのに、Batangでは「匀」に化けてしまうのだ。しかも、この問題はHANYANGのフォントでは茶飯事で、たとえばAdobeMyungjoStd-Mediumでも、同じように「勻」が「匀」に化けてしまうし、「緊」の右上の「又」も「攵」に化けてしまう。うーん、KS X 1001:2004の紙の規格票は、どうなってるんだろ?

12837866 journal
お金

yasuokaの日記: ISO 20022におけるカタカナコード

日記 by yasuoka

昨日の日記に対して、ではカタカナはどうなるのか、との御質問をいただいた。ISO 20022の「XML電文」ではUTF-8を使うので、もちろんカタカナだって通る。ただ、濁点や半濁点については注意が必要だ。たとえば「ガ」に対しては、U+30ACで表すのか、<U+30AB U+3099>で表すのか、という問題がついて回る。ただし、<U+FF76 U+FF9E>は、ISO 20022の「XML電文」では御法度だ。

ちなみに、現在の全銀協電文フォーマットは、JIS X 0201系では「ガ」を「B6 DE」で、EBCDIC(EBCDIK)系では「ガ」を「86 BE」で表している。いずれも「カ」+「゛」なわけで、それとの親和性を考えると、今後の「XML電文」では<U+30AB U+3099>を用いた方が、あるいは安全かもしれない。ただ、その場合においても、一応U+30ACも受け取れるようにしておかないと、どこかでマズイことが起こる気がする。

その一方、もっとマズイことになりそうなのは、「ッ」などの小書きカナだろう。EBCDIC系との変換ガラミで、現在の全銀協電文フォーマットでは、JIS X 0201カタカナのうち、小書きカナや「ヲ」や「ー」等の使用を非推奨としている。でも「XML電文」になったら、やっぱり「ッ」や「ャ」も使いたくなると思うのだ。このあたり、私(安岡孝一)個人としては、全銀協電文フォーマットのうちEBCDIC系を先行廃止すべきだと思ってるのだけど、さて、そういうのは、どこで議論してもらえばいいんだろ?

12836987 journal
お金

yasuokaの日記: ISO 20022における漢字コード

日記 by yasuoka

ISO 20022において、どの程度の漢字を流すことができるのか、という趣旨の御質問をいただいた。ISO 2022ではなくISO 20022で、銀行決済における「XML電文」に関する話らしい。私(安岡孝一)の知る限り、ISO 20022は文字コードとしてUTF-8を規定していて、それ以上でもそれ以下でもない。つまり、XMLに使えるUTF-8なら何でもOKということだ。

ただ、これは現実には問題を引き起こしている。たとえば、SEPA (Single Euro Payments Area)では、「XML電文」で送られてきた「発信者名」において、受取側(の銀行とか)で理解できない文字が入ってたら、その文字を捨ててしまう運用が行われている(ところが多いらしい)。さすがにこれはまずいだろう、とのことで、2009年頃からSEPA Requirements for an Extended Character Setという、いわば「縮退マップ」が模索されているのだが、現時点ではBest Practices扱いで、アクセント付きラテン文字すら強制には至っていない。

すなわち、ISO 20022に従った「XML電文」において、いくら日本国内で漢字を使えるようにしても、国際的には無意味ということである。それどころか、カタカナのやり取りすら国際的には怪しい。国際的な「XML電文」においては、「発信者」などの名前は、現時点ではA~Zの26文字(つまりはICAO 9303)にとどめておくべきだろう。

その一方、国内の「XML電文」において、漢字を使えるようにするのは、それなりに意味がある気がする。ただ、日本の人名用漢字において、たとえば「渚」と「渚」を見分ける必要があるのなら、互換漢字(U+FA46)の使用はISO 20022では御法度なので、IVSを使わねばならない。IVSを使う場合、<U+6E1A U+E0100>と<U+6E1A U+E0103>のどちらを使うのか、は意識しなければならず、その意味では、使える漢字の一覧表と、そのIVS一覧表を準備する必要がある、ということだろう。

「FinTech」とか言って騒いでる人たち、このあたりのこと、ちゃんと理解してるのかしら? 正直、大変だなぁ…。

12836322 journal
日記

yasuokaの日記: NDL書誌情報における文字コード講座

日記 by yasuoka

上綱秀治の『文字コード講座』(NDL書誌情報ニュースレター, 35号36号37号)の連載が終了した、との御連絡をいただいた。この記事は、参考文献の1つに

安岡孝一, 安岡素子. 文字符号の歴史 欧米と日本編. 共立出版, 2002, 286p.

を挙げていながら、かなりアチコチに問題があって、私(安岡孝一)としては気になっていたのだ。たとえば、第1回のこの部分。

文字コードはコンピュータ上で文字を扱うためのものです。その歴史は同様に米国を中心として始まり、コンピュータの性能の向上やネットワークの発達とともに広く進展してきました。

『文字符号の歴史 欧米と日本編』の第1章「電信符号の歴史」(pp.15-59)を読まなかったのかしら? この章でも示したとおり、文字コードは、もともと通信において文字を扱うためのものであって、その後コンピュータにも導入されたに過ぎない。もちろん、コンピュータにおける通信は「情報交換」という形で抽象化されていて、実際ASCII (American Standard Code for Information Interchange)とか、JIS C 6220-1969「情報交換用符号」とかいう規格名称にも反映されているわけだ。

日本語用の文字コードとして最初に制定されたJIS文字コードには片仮名が含まれました。片仮名と日本語固有の句読点を合わせると約60文字[3]になります。これをISO 646(現 ISO/IEC 646)の英数字128文字と同時に用いるためには、約190文字の文字集合が必要となり、256文字を表現できる8ビットが必要となります。そのため、日本では、1969年にISO 646(現ISO/IEC 646)を8ビットに拡張し、片仮名や句読点を加えたJIS X 0201(当初はJIS C 6220-1969)という独自の規格を定めました。

「最初に制定されたJIS文字コード」は、私の知る限りJIS C 0803-1961なので、6ビットだと思う。『文字符号の歴史 欧米と日本編』の「2.1.8 JIS C 0803の制定」(pp.82-88)にも、そう書いておいたはずだ。通信における文字コードや、文字コードにおける「シフト」をちゃんと理解していないから、「8ビットが必要」とか訳の分からないことを書いてしまうのだ。

ISO 2022-JPでは、漢字とASCIIや半角カナ文字等を混在させるためにエスケープ・シーケンスを用いますが、この方法では文字の処理に時間がかかるという欠点がありました。それを改良するため、マイクロソフト社などが考え出した文字コード体系を「Shift JIS」(S-JISと略されることがある)と呼びます。

「それを改良するため」って何のこと? シフトJISを搭載した「MULTI 16」の発売は1982年1月。一方、ISO-2022-JPの登場は、その前身の「JUNETコード」まで遡っても1986年9月。ISO-2022-JPを改良するためにシフトJISを考え出す、というのは、そもそも時間の順序が逆だ。

第2回では、もっと衝撃的な文が現れる。

UTF-8は、ASCIIコードに当たる部分は1バイトで表し、それ以外の文字を2~6バイトの可変長で表します。しかし、UTF-8ではUCS-2の範囲の文字しか扱えません。

あー、そのー、『文字符号の歴史 欧米と日本編』の「3.3.3 UTF-8」(pp.232-233)、ちゃんと読んだ? 6バイトも使って「UCS-2の範囲の文字しか」扱えないの?

さすがに読むのがツラクなってきたのだが、それでも、第3回も目を通してみよう。

Unicodeで日本の文字を扱うときに注意すべき文字について説明します。
(1)改行コード

それ「日本の文字」なのか? しかも、それは本当に「Unicode」の問題なのか? U+FEFFとかならまだしも、ASCII以来の問題であるCR・LFを「Unicodeで日本の文字を扱うときに注意すべき文字」として説明するのは、私には到底理解できない。第1回でASCIIを扱ってるんだから、説明したいならそこで説明しておくべきだろう? うーむ…。

12830598 journal
中国

yasuokaの日記: 通用規範漢字表とGB 2312における漢字の配列

日記 by yasuoka

ネットサーフィンしていたところ、辻田正雄の『「通用規範漢字表」について』(佛教大学文学部論集, 第100号(2016年3月), pp.27-42)という論文に行き当たった。2013年に「通用規範漢字表」が出来上がるまでのスッタモンダが描かれており、個人的には楽しく読めたのだが、文字コード屋の私(安岡孝一)としては、どうしても納得できかねる部分があった。

「通用規範漢字表」の各級内の配列は 一 丨 ノ ヽ 乙 の形序配列である。これは、《GB13000.1字符集汉字字序(笔画序)规范》に従ったものである。その理由は多音字や定音未決定字等の存在から音序は不都合であり、形序の唯一性を重視したことである(39)

(39) 王敏、陈双新《字表中的字是如何排序的?》《语言文字周报》2015年4月22日。《GB13000.1 字符集汉字字序(笔画序)规范》は《GB 2312-80信息处理交换用汉字编码字符集・基本集》(1981年5月1日実施)の配列と基本的に同じである。「通用規範漢字表」がコンピュータ処理をも考慮したものであることはこの配列からも窺うことができる。

GB 2312-80における漢字の配列は、第一級漢字(16-01~55-89)がピンインのアルファベット順、第二級漢字(56-01~87-94)が簡化字の部首画数順である。「形序配列」ではない。また、GB 13000は、いわゆるCJKの康煕字典順であり、やはり「形序配列」ではない。その一方でGF 3003-1999は、確かに「形序配列」ではあるものの、CJK統合漢字20902字のみを並べ直したものであり、「通用規範漢字表」を議論するには不十分だ。

もちろん、「通用規範漢字表」がコンピュータ処理をも考慮したものであることは、現時点においては間違いない。ただしそれは、問題となっていた6774「⿰土夅」・7146「⿰石达」・7373「⿰钅麦」の3字が、ISO/IEC 10646:2014 Amendment 2 (2016年5月1日制定)において、それぞれU+9FCD・U+9FCE・U+9FCFに収録されたからであり、そのための努力を中国その他が惜しまなかったからである。「通用規範漢字表」が「形序配列」になっているのは確かに事実なのだろうが、残念ながらそれは、現代的なコンピュータ処理とは全く無関係である。

typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...