山田祥平のRe:config.sys
さよならシフトJIS、主なしとて春な忘れそ
2018年12月14日 06:00
テキストファイルは万能だし、もっともつぶしのきくデータ形式だ。そして、少なくとも平成のパーソナルコンピューティングにおいてテキストファイルを支えたのはシフトJISという文字コードだった。いわゆるMS漢字コードとしてMS-DOSやWindowsの標準でもあった。その平成が終わろうとしている今、シフトJISはひっそりと消えていく。
シフトJISからUnicodeへ
Windows 10のInsider Previewでは、すでに来年(2019年)の春にリリースされる予定のプレビュービルドが評価用に提供されている。この原稿を書いている時点での最新ビルドは、Fast ring向けの18298で、このビルドの最終版が「19H1」として来春あたりに一般向けにリリースされることになる。現行の一般向けビルドは1809だが、不具合の発生で実際の本格的リリースは11月になってしまった。そういうことにも対応できるように19H1としたのだろうか。
さて、この最新ビルドで、標準アプリである「メモ帳」に大きな手が入った。といってもエンドユーザーはそのことに気がつかないかもしれない。新規作成時のデフォルトがBOMなしUTF-8になったのだ。BOMはバイトオーダーマークで、これがあると以降はUnicodeで表現されていることを示す。テキスト本文以外の数バイトのデータが付加されることになるが、デフォルトではBOMがない。また、UTF-8はUnicodeを使える8bitコード利用のスキームだ。
1982年とされるシフトJISの誕生からほぼ10年たった1991年にUnicode 1.0.0がリリースされ、翌1992年に漢字が導入されている。現在のUnicodeのバージョンは2017年の10.0.0で、変体仮名が取り入れられている。
シフトJISで書かれていてもUnicodeで書かれていても、プレーンテキストファイルであることにはかわりはないが、そこにあるテキストファイルはシフトJISであるという決め打ちが今後はできなくなると考えたほうがいい。
今回はメモ帳が先陣を切ったが、たとえばコマンドプロンプトやPower Shellにおける type コマンドで表示させようとしても表示ができない。typeコマンドというよりも、コンソール自体のコードページがシフトJIS決め打ちで、Windowsのシステム設定に依存し、処理対象となるファイルがシフトJISで書かれていると決め打ちしている。
ベータ機能として1803バージョンのWindows 10にも、システムロケールに「ワールドワイド言語サポートでUnicode UTF-8を使用」というオプションが用意されているが、それはtypeコマンドを実行するコンソールに影響するものではない。
メモ帳アプリなんて誰も使わないという論調もあるだろう。そしてそれ以前に今目の前にある日本語の文字列が、どんなコード体系なのかを気にするエンドユーザーも皆無といっていいかもしれない。実際には、iOSもAndroidも、多くのWebサイトもUTF-8が使われている。今、この記事が掲載されているページも、ソースを確認すると、<meta charset="UTF-8">といった文字列が見つかるはずだ。
それでも、平成のパーソナルコンピューティングにおける日本語をずっと支えてきたシフトJISには、本当にお疲れさまといってあげたい。よくもまあ、こんなアクロバティカルな実装を考えついたものだと感心するが、よくも悪くも、パーソナルコンピュータの日本語環境のスタンダードだったのだ。
あそこで半角カナを切り捨てていたら、いったいどうなっていただろうか。多少混乱してもそのほうがよかったのにと思いながらも、策定に関わっていた多くの人々には敬意を表したい。
もちろん次のWindowsが標準文字コードをUTF-8にすると宣言しているわけでもない。当面の間はちょっとした混乱もあるかもしれない。
WordもじつはUTF-8
Microsoft OfficeのWordは、日本語ワードプロセッサとして広く使われているアプリだが、そのデータ形式としてUTF-8が使用されている。もっともエンドユーザーからは、.docx拡張子を持つWordの文書ファイルは単なるバイナリデータのように見えるので、あまりそのことが話題になることはなかった。
ちなみに、.docx 拡張子を .zip に変更すると、Windowsからはアーカイブファイルのように見える。というか、これが .docxファイルの正体で、普通に、ZIPアーカイブファイルとして開くことができる。
アーカイブの中味を見ると、wordというフォルダがあり、そのなかにdocument.xmlというファイルが見つかる。これが、xmlとして記述されたUTF-8ベースの文書内容の実体だ。
この仕組みはオープンドキュメント形式でも同様だが、オープンドキュメントでのファイル名はcontent.xmlとなっている。
いずれにしても、リッチな表現のための属性を記述するのもテキストファイルなら、その記述が反映される本文もテキストファイルである。あらゆる表現がテキストファイルだけで完結している。そのことを古のパーソナルコンピュータで保証してきたのがシフトJISファイルだったのだが、そのお役御免が近づいているわけだ。
あいかわらずのOneDriveをなんとかしてほしい
文字データをシフトJISではなく、Unicodeで保存するとどんないいことがあるのか。たとえばUnicodeならあらゆる言語の文字を混在させることができる。Wordでしか文書を書かないエンドユーザーにはそんなこと当たり前じゃないかと言われそうだが、卑近な例でいえば、中国・広東州の都市シンセンの「セン」は中国語の簡体字で、日本語にはない漢字だ。だからこのセンに相当する漢字をシフトJISのテキストファイルに混在させることはできない。
また人名でも、フランス語の場合はいろんな記号が文字に付加される。先日、アナログレコードを整理していて見つけたフランソワーズ・アルディの「さよならを教えて」は1968年のヒット曲だが、彼女の名前の「フランスワーズ」は「Francoise」ではなく、「c」の下部にセディーユと呼ばれる「s」に似た記号がついた文字なのだが、その表記も混在できない。
自分がこれから書くであろう文章にシフトJISを使っていては困る問題がいろいろ出てくるであろうし、これまでもあった。今回の「メモ帳」アプリのデフォルトUTF-8設定を見て、そろそろそちらに移行してもいいかもしれないと思った次第だ。場合によってはずっとISO-2022JPで送信してきた電子メールも、UTF-8のHTMLに移行するべきかもとさえ感じている。
ただ、こうして作ったBOMなしUTF-8ファイルをWindows標準のクラウドストレージOneDriveにテキストファイルとして置き、AndroidのOneDriveアプリで開いても正常な表示ができない。シフトJISでももちろん文字化けする。いったいいつまでこういう仕様を放置しておくのだろうかと問い詰めたいところだ。
テキストファイルの汎用性をそのままに付加価値を与えるUnicode
文書をその構造や装飾を含めすべてを汎用性の高いテキストファイルで記述しておき、それを任意の処理系にかければ、記述したとおりの体裁で出力できるということの柔軟性は、個人的には初めてLaTeXを使ったときに実感した。電子組版システムのTeXのマクロパッケージで、まだPowerPointなどが一般的ではなかったころに、一般の日本語ワープロではできなかった表現もなんなくこなせ、その体裁だけがすばらしいと評価されて通った企画書もあったくらいだ。今となっては笑い話だ。
もっとも汎用性の高さでは紙に印字というのがもっとも高い。冒頭の写真は京都・北野天満宮所蔵の北野天神縁起絵巻の現物だが1219年に描かれたものとされている。そのオリジナルは存在せず、承久本というのが現在最古のオリジナルとされている。いずれにしても800年前の図入りドキュメントを普通に見られるのだからすごい(主なしとて春な忘れそ)。
もとい、TeX、LaTeXが気軽に使えるようになる前、テキストファイルの処理系がほしくなって、finというフィルタプログラムを日下部陽一氏の指導のもとに見よう見まねで作ってみたこともあった。インスタ映えならぬ、パソ通映えするメールやメッセージを作れるテキストフォーマッタ、早い話がroffの簡易版だ。
fill inがプログラム名の由来だが、Finishというにはおこがましいので、finにしたのだが、最後にeをつけてfineになることなく役割を終えている。適当にテキストを書いて、.(ドット)ではじまるコマンドを埋め込んでおけば、そのとおりに出力されるというプログラムだが、フリーで公開した80年代の終わりには、それなりに使っていただけたようだ。ただ64bit非対応で今となってはexeファイルの実行は不可能になってしまった。
アーカイブ内のドキュメントを見ると「使用されるにあたって、使用料金も登録も寄付も必要ありません。プログラム、およびドキュメント等の関連ファイルに対して、どのような改変を加えてもかまいません。配布方法に関しては、いかなる制限も設けません。もちろんその大小を問わず、金銭の授受が伴っても、それを禁止することはありません。したがって、極端な場合、このプログラムを商品として流通していただいてもかまいませんが、それを入手した方が、第三者へ配布する自由をさまたげないでください」などと書いてある。生意気なようでちょっとかっこいい。ちなみにfinの最初のバージョンをリリースしたのは1987年だ。
今、あらゆるGUIはWYSIWYGが当たり前だが、Wordの例を見てもわかるように、その根底にあるのはテキストだ。なにもかもがテキストで記述されている。とにかくつぶしがきくテキストファイル。そのデータをUnicodeに変えることもまた普遍のポータビリティを確保する1つの手段だといえる。ある処理系がいつまでも使い続けられるとは思わないほうがいい。試しにと思ってダウンロードしたfinも、LZH圧縮されていて、それをほどくためにユーティリティを追加ダウンロードする必要があった。過去には対応していたWindows 10も、今はLZHに標準対応していないのだ。そういうことはこれからも起こる。