サーバ管理者日誌

新元号が「令和」と発表されて、美しい年号だと率直に思いました。『万葉集』巻五、梅花（うめのはな）の歌三十二首の序文に拠ったということで、場面の描写も美しいと感じました。
さらに源流を遡れば、 張衡[https://ja.wikipedia.org/wiki/%E5%BC%B5%E8%A1%A1_(%E7%A7%91%E5%AD%A6%E8%80%85)] の「帰田賦」に「於是仲春令月　時和氣清」とあり、梅花序文の作者とされる大伴旅人が、漢詩集である 懐風藻[https://ja.wikipedia.org/wiki/%E6%87%90%E9%A2%A8%E8%97%BB] をなしたことを考えれば、恐らくこれは知っていた上で、引き歌的に使ったものではないかと思いますが、作品としては別のもので、「万葉集が出典」とするならば、それが事実だと思います。
さて、「令和」の令の字なのですが、歴史的な事情によって、UNICODE上には、一般的な 「令 (U+4EE4)」[https://www.compart.com/en/unicode/U+4EE4] と 「令 (U+F9A8)」[https://www.compart.com/en/unicode/U+F9A8] が登録されています。
一般的な入力では、U+4EE4の方の「令」が使われるはずなのですが、字形が同じで、コードが二つあるというのは様々なトラブルを引き起こす原因になり得ますから、少しやっかいな文字です。
今回の改元は、事前に発表されて予定されているという、ITシステムが初めて経験するケースなので、改元時のトラブルがあってはならないということで、準備をしてきていると思うのですが、こういう文字の問題をテストケースに入れて、テストしてきている事業者は少ないのではないかと思います。
対応としては、自分のシステムからは年号文字列として「令和」を出すときには、U+4EE4を出せば良いとして、U+F9A8 の「令和」を受け取った時にどうするかと、検索に掛けるときにどうするかという対応を決めて、改修するなら、その様に改修して、テストする必要がある訳ですが、これを30日でやるのは難しそうな気もします。
実際のところ、何も意識しないで別物と扱って、U+F9A8 の「令和」が入っていそうで失敗する…という局面で、文字コードを確認するとか、コピペ元を用意して混入を避けるとか、しばらくは運用で回避ということもできそうで、大問題にはならないと思うのですが、もしかすると、私の考えが不足していて、U+F9A8 の「令和」が存在することで、想像を絶する何かが起きる場合があったりするのかも知れません。
思いつくケースでは、入力をチェックするコードでは、U+4EE4とU+F9A8を同一視しているために、正しく年号である「令和」が入力されていると判定をするにも関わらず、集計系のコードでは、U+F9A8が別物として扱われて、エラーになったり、集計から漏れたりということはありそうな気がします。
いずれにしても、世の中の様々なことにIT技術が使われている今日では、IT技術の側面から問題がないかどうかを検討した方が良いことは、様々な分野に存在して、新元号の決定という、一見、IT技術とはローマ字の頭文字程度の関りしかないと思われていた分野にあっても、やっぱり検討しておいたら良かったというケースになったのが関心深い出来事でした。
「新元号を決めるための有識者会議にIT技術者を入れるべきだった」と主張したいわけではありません。むしろ反省です。例えば、IT技術者としてこういう文字にはこういう技術的な問題があるといった主張を提言していく方法もあったでしょう。
技術者も政治から遠ざかっていては、技術の将来も、それに携わる私たちの将来も、この国の将来も危うくなるのではないかと危惧される事態が最近いくつか起きています。
無事、無罪判決が出たCoinhive事件もそうですし、今、お読みいただいている様な形で表示されるページを他人に伝えたとして、全国各地で、検挙者が出ている事件がそうです。
技術的により良い答えを知っているのだったら、世の中にそれを広めて、実装させていくことも、技術者の大事な使命だと改めて感じました。
【本日の日記は、いわゆる「無限アラート」事件に関する主張のために、アラートモードでお読みいただきました】