“やじうまの杜”では、ニュース・レビューにこだわらない幅広い話題をお伝えします。

いささか旧聞には属しますが、以前投稿された“Windows Blog for Japan”のブログ記事が話題を集めていました。

さまざまな顧客に配慮しなければならないせいか、全体的に曖昧な表現が多く、個人的には少し意味の取りにくい文章だなと感じましたが、要するに

「“外字”を使うのはやめてくれ！ 代わりに業界標準の文字コード“Unicode”を使って」

ということのようです。

いわゆる「日本語版 Windows」では長らく“Shift_JIS”が標準とされており、それに含まれない文字は“外字”をインストールして表示する必要がありました。

しかし、最近のWindowsは多言語対応が完了しており、中核部分のバイナリはすべての言語で共通となっています。つまり、私たちが「日本語版 Windows」と呼んでるものは、実は「世界共通のWindowsバイナリ＋日本語リソース」のことです。実際、最新の「Windows 10」はフランス語化するのもタイ語化するのも割と簡単に行えます。

その各国語版Windows共通のバイナリはUnicodeを基盤としており、Shift_JISは“追加対応”されている状態です。それどころか、Unicodeは毎年のようにバージョンアップして新しい文字が追加されているにもかかわらず、Shift_JISはそのような動きがなく、単に“互換性維持”のために残されていると考えた方がよさそうです。

たとえば、去年5月には日本で改元があり、Unicodeには新元号の合字“㋿（U+32FF）”が追加されました。しかし、Shift_JISには追加されておらず、Unicodeに対応しない古いアプリケーションでは“㋿”という文字が表示できないという問い合わせがいくつもMicrosoftに寄せられたのだそうです。

Shift_JISですらそのような対応状況なのですから、“外字”はなおさらでしょう。同社によると、Windowsにおける外字のサポートは、作成されたPC上での使用に限られています。他のPCで作成された外字を他のPCに移植した場合はサポートされておらず、最悪の場合OSのハングアップやブルースクリーンも起こりえます。その場合は、外字をそのPCで再作成しなければならないこともあるそうです。

外字は人名地名に使用される漢字などを正確に表現するために必要とされますが、その多くはUnicodeでも定義されており、本当に“外字でなければ表示できない文字”は限られています。にもかかわらず、外字を使わなくても表示できる文字を表すために、Unicodeではなくわざわざ外字を利用するケースもあるとか……そういう設計は適宜見直したいものですね。いわんや、新規開発の場合をや。

また、Shift_JISや外字を利用することの弊害はそのOSのみに留まりません。まず、MacやLinuxなど、Windows以外の環境では一手間かけないと読めなかったりします。たとえば“OneDrive”に保存したテキストファイルをWebブラウザーで読もうとしたら文字化けして読めなかったりしたことはありませんか？

最近の「メモ帳」はテキストファイルを保存する際、Shift_JISではなく、デフォルトで“UTF-8N（BOMなしUTF-8）”を利用します。そうしておけば、文字化けは避けられたでしょう。

また、テキストをShift_JISで保存していることがクラウド移行への障壁となることも。移行プロジェクトの終盤に外字の利用が判明して、泣く泣く仮想マシン＋IaaSという構成にせざるを得なくなったり、プロジェクトそのものが頓挫するケースもあるのだそうです。Shift_JISや外字が隠れたコスト要因になってしまっているわけですね。

少し長くなったので、以下にShift_JISや外字を利用した場合の弊害をまとめましょう。

表示できない文字が年々増える（新元号の合字やUnicodeへ新たに追加された絵文字）

OSのクラッシュやブルースクリーンエラーを招くことがある

他の環境で読めないことがある

クラウドへの移行が難しくなる

歴史的な経緯のため、まだまだShift_JISでなければ問題が発生するという例は少なくありませんが（たとえばスクリプトファイルなど）、一般的なテキストデータやCSVデータはもうUnicodeにしてもよいのではないでしょうか。「TeraPad」など、Shift_JISを既定の文字コードにしているテキストエディターを愛用している人も、そろそろ保存時に利用する文字コードを意識した方がよさそうですね。