Apple Devices meet 令和
2019年5月14日にiOS 12.3およびmacOS Mojave 10.14.5がリリースされ、Appleデバイスにも令和がやってきました。iOSでは[設定]→[一般]→[言語と地域]の[暦法]で[和暦]を指定することで西暦2019年5月1日以降の日付が令和になります。余談ですがタイ仏暦もサポートされているのですね(図1)。
macOS [System Preferences]→[Language & Region]の[Calendar]を[Japanese]にすることで同様の効果が得られます。こちらはiOSよりもさらに多くの暦法がサポートされています(図2)。
なお、元号と西暦の対応は、Swiftという言語ではなくOSのAPIでなされている点に留意する必要があります。2019年5月現在が令和元年なのか平成31年なのかはOSで決まります。実際、次のSwiftプログラムをmacOS Mojave 10.14.5で走らせると、
と表示されましたが、Ubuntu 18.04 LTSでは本原稿執筆現在も令和を知らないので、
と表示されました。なお、Ubuntuも19.04にはすでに令和が届いている模様です。
Unicode 12.1はまだ
元号の処理は基本的にはOSの処理ですが、そうでないものが1つあります。Unicodeにおける文字の正規化の扱いです。これに関してはOSのAPIというものはなく、対応は言語ごとです。具体的には次のSwiftコード、
のような正規化がそれに該当するのですが、iOSおよびmacOSでは“\u{32FF}”対応のフォントは搭載されても正規化は未実装でした。macOS(図3)とUbuntu(図4)のREPLの結果です。
メソッド名にもCompatibilityMapping
とあるとおり、これら本来はUnicodeとレガシー文字コードの相互変換を担保するために仕方なく用意されていたコードポイントでした。にもかかわらずU+32FFがUnicode 12.1に用意されてしまったのは呆れるよりほかありません。これを認めるのであれば、U+3004が〄に割り当てられてしまった以上、新JISマークも別途コードポイントを割り当てられるべきという無茶さえ通ってしまいかねません。
もっとも、元号という概念自体がレガシーではあるのですが……。
次回予告
次回はWWDC特集を予定しております。
- 第1特集
MySQL アプリ開発者の必修5科目
不意なトラブルに困らないためのRDB基礎知識
- 第2特集
「知りたい」「使いたい」「発信したい」をかなえる
OSSソースコードリーディングのススメ
- 特別企画
企業のシステムを支えるOSとエコシステムの全貌
[特別企画]Red Hat Enterprise Linux 9最新ガイド
- 短期連載
今さら聞けないSSH
[前編]リモートログインとコマンドの実行
- 短期連載
MySQLで学ぶ文字コード
[最終回]文字コードのハマりどころTips集
- 短期連載
新生「Ansible」徹底解説
[4]Playbookの実行環境(基礎編)