国際化関連

「Microsoft Visual Studio 2005 品質および機能に関するアンケート」にご協力のお願い

ディベロッパー製品開発統括部 — Wed, 11 Oct 2006 07:24:00 GMT

早いもので、Visual Studio 2005 が昨年末にリリースされてから９ヶ月あまりとなりました。皆様も日常お使いの中で、使いやすくなった点やご不満な点など、様々なご意見をお持ちではないかと思います。
そこで我々ディベロッパー製品開発チームでは、日本のお客様のご意見を幅広くお伺いし、次期および将来の製品をより良いものにしていくため「Microsoft Visual Studio 2005 品質および機能に関するアンケート」と題しまして、機能面や品質に関するアンケートを実施させていただくことになりました。

できる限り多くのお客様よりご意見をお聞かせいただき、製品に反映していきたいと思います。お忙しいとは存じますが、ぜひアンケートにご協力いただけますようお願いいたします。

アンケートにはここからご参加いただけます。

時差のシナリオに関してのご意見をありがとうございました

ディベロッパー製品開発統括部 — Tue, 08 Aug 2006 07:04:00 GMT

みなさん時差のシナリオに関して、ご意見をお寄せいただきまして、大変ありがとうございました。

今回は、お寄せいただいたなかで、ご質問がいくつかありましたので、答えさせていただきたいと思います。ユーザー設定のタイムゾーンに関するご質問ですが、特定のルール情報を包括的に含めたものを作るのか、タイムゾーンとして独立したものを作って切り替えるのかといった点では議論の余地が残っています。カスタムカルチャに関連付けさせることができるようにするといった話もございますので、可能性としては"ja-JP-01"といったような指定でのCultureAndRegionInfoBuilder クラスで作成するカスタムカルチャで取り扱うことも考えられます。この場合は以前、カスタムカルチャのシナリオでご紹介した、名前をコンピュータ全体で取り扱ってしまう懸念が残ります。

時差の変更の際の曖昧／重複に関するご質問は、いただいた通り、春先に時計の針を進めた際の失われる時間、秋に戻す際の重複する時間の判断をする関数のこととなります。差分（オフセット）時間やサマータイム区別する文字列が表記に含まれる場合はこの問題は生じませんが、これらの情報がないまま時刻のみがログに記録されている場合など、ご指摘いただいたように対応の方法を考えることになります。

今回、その他の皆さんからもお寄せいただいた、ご経験に基づく詳細なシナリオは、日本のお客さまに基本クラスライブラリをよりよくお使いいただくうえで、いずれも大変参考になるご意見でした。今後のタイムゾーンに関する機能の詳細に関して、頂いたご意見をあわせて、CLRチームと検討をさせていただきます。

繰り返しになりますが、再度、御礼申し上げます。

日本における時差のシナリオに関してご意見をお聞かせください

ディベロッパー製品開発統括部 — Fri, 21 Jul 2006 05:30:00 GMT

先日、.NET Frameworkの基本クラスライブラリを作っているチームから、時差を表すTimeZone クラスの機能に関して問い合わせが来たので、こちらのblogをご覧の皆さまからもご意見をお聞かせいただければと思い、今回は書いてみます。

現在、日本国内では時差はないので、国内向けのアプリケーションを作る場合は、さほど考える必要性がありません。しかし、最近では多国籍な会社のお客様からの要求や、国内でも特定地域でのサマータイムの実験の要求なども出ています。.NET Frameworkの基本クラスライブラリ（BCL)では、DateTime.ToUniverslTime メソッドやTimeZone.ToUniversalTime メソッドを使ってローカルの時刻を元に世界協定時刻（UTC)を導くことができますが、特定のタイムゾーンの時刻を変換するには、独自の工夫が必要です。

原文からの受け売りになりますが、現状BCLチームが大きなデザインとして考えているのは以下の点になります。

タイムゾーンの列挙
タイムゾーン間の時刻変換
タイムゾーンのシリアル化
DateTimeに標準時からの差分を組み込む
歴史的経緯からサマータイムのルールが年毎に変わっていたもののサポート

少し視点を日本に向けて歴史的経緯からみると、日本で昭和20年代に実施され廃止された、夏時刻法および西部標準時をどう取り扱うべきか（または取り扱わないべきか）というところも考えなくてはいけないでしょう。

ここで、原文の方を読み進めると、以下の9つの点に関して英語ユーザーからの意見を募っています。

ユーザー設定のタイムゾーンの作成（時間帯を、既定でコンピュータ上にあるもの以外に、プログラム的に作成すること）
ユーザー設定のタイムゾーンを恒久的にコンピュータ上に書き戻す
サマータイム設定を切った状態でタイムゾーンのコピーの作成
サマータイムのため、時計の時刻を前後した際のローカルタイムが未確定、もしくは曖昧／重複にあるかどうかを問い合わせる関数
歴史的経緯によって基本になる差分が年毎に変わったタイムゾーン（前述の夏時刻法に対する実装が関係してきます）
稼動中のコンピューターの現在のタイムゾーンの変更
スレッド単位、もしくはプロセス単位のアンビエントタイムゾーン*1の設定
一行で簡潔に変換を可能にするヘルパ関数（TimeZone.Convert(time, "Pacific", "Eastern") のような）
"PST", "EDT"といったタイムゾーンを組み込んだDateTimeに対する解析と書式設定

お手数ですが、以上の点につきまして、トラックバックにてご意見をお寄せください。形式は「どのようなものでも」ということなのですが、「必要／不要／多分必要」のいずれかのランクをつけていただき、それに関する簡単な説明を加えていただけますと、実装担当者との意思疎通の際に助かります。原文には「実装のお約束はできませんが」といった前置きがありますので、恐れ入りますが、この点はご容赦ください。

将来のよりよい製品をお届けするために、ぜひ、ご協力をお願い申し上げます。

*1 CultureInfo クラスのようにスレッドのような実行単位に対して環境的に設定することを意味しているでしょう。間違っていた場合は、後日修正をこちらに追記いたします。

続Atlasプロジェクトの国際化（日本でどうする？）

ディベロッパー製品開発統括部 — Tue, 04 Jul 2006 10:42:00 GMT

以前、ご紹介させていただいたAtlasですが、CTPも数回出ましたし、Go-Liveという形態で使っても良いことに３月からなっていますね。私も少し自分のプロジェクトのページをUpdatePanelを使ってコンテンツの一部分を書き変えたリ、テキストボックスにAutoCompleteExtenderで読み仮名からの自動補完の機能を付けてみたリしています。

Atlasの全容が明らかになるにしたがって、なかなか奥が深いことがわかります。クライアント側のスクリプトライブラリにインターフェイスや名前空間、継承といったオブジェクト指向の基礎となる部分を実装し、それらを使って基本クラスライブラリを作り、それを土台にコンポーネントのモデルとUIフレームワークを構築、コンポーネントやコントロールを組み上げるというものが、ブラウザの違いを吸収する層の上にあるので、開発者の生産性やコードの再利用性などはかなり高いのではと思います。スクリプトライブラリはAtlasをインストールしていただければ、ソースコードをご覧いただけるので、研究調査の対象としても良いかもしれません。

クライアント側のプログラミングモデルは慣れていければプログラム的にJavaScriptを書くことも宣言的にXMLスクリプトも書くことはできると思いますが、開発ツールのサポートが必須ではないかと思います。反面サーバー側のタグによる宣言的モデルは、マークアップビューでの自動補完の機能が効いていますし、デザインビューでのプロパティグリッドやスマートタグも使えるので、Webページを開発なされる方は英語であってもそれなりに、お試しいただけるのではないかと思います。もちろんサーバー側のコントロールですので、動的な動作も現在のASP.NETのサーバー側のプログラミングの延長で行えます。

以前のblogではUIの改善のためにという形でご紹介をさせていただいたのですが、さらに興味深いのは、サーバー側にBridgeと呼ばれる他のサービスやデータを集約、橋渡しを行う箇所があることです。これらのことを考えていくと、使用者に対してWebでの体験を統括的に改善する術を提供できるのではないかと思います。

さて、以前に懸念している事項としていくつかの日本の使用シナリオを挙げ、トラックバックにて貴重なフィードバックをいただいたのですが、国際化のモデルはASP.NET 1.xから継続してあるカルチャを使うGlobalizationのモデルを使い、ブラウザのリクエストに拠って適当なカルチャをSys.CultureInfoに返すというスタイルです。多言語化は翻訳やコンテンツのみならず、照合順序なども考えないといけませんが、クライアント側のJavaScriptの機能で制限を受けてしまうことは考えられるかもしれません。他に、JSONのエンコーディングはUnicodeのいずれかのものでUTF-8が既定と先日IETFのドラフトで方向性が示されましたし、他のXMLなどによるデータのやりとりもそれに準拠することになると思いますが、これが現在のASP.NETのresponseEncodingなどで返されるコンテンツとうまく整合性がとれるのかなど、調査作業は山積しております。

懸念事項のうちの２番目として挙げさせていただいたIMEとの動作ですが、弊社のツールであるFiddlerなどを経由してHTTPの中身を覗いてみると、テキストボックスなどでは変換前の入力文字ごとにサーバーへ要求が送られているようです。しかし、AutoCompleteで別なコントロール(たとえば隣にあるボタン)をクリックすると、未確定候補が選択項目を上書きしてしまったりしますね。

Go-Liveとはいえ現状は、まだ開発途上であります。ぜひ、お使いいただいた中で、これ以外にも日本語を扱う上でお気づきになられたことがありましたら、トラックバックにてご意見やご要望をお聞かせください。

ナオキさん、フィードバックをありがとうございます。Fiddlerに加えてWeb Development Helperなどもお使いいただけますね。Fiddlerがなかったころは、文字化けの調査などにはWindows Serverのネットワークモニタ (NetMon)を使っていました。こちらであれば、Windows Serverのユーティリティとして日本語化もされていますので、使いよいかもしれませんね。

[2006/7/13: 更新] フィードバックへの返信を追加

国際対応アプリケーションを開発する時によくある問題

ディベロッパー製品開発統括部 — Wed, 05 Apr 2006 00:42:00 GMT

今回は国際対応アプリケーションを開発する時によくある問題についてお話したいと思います。

既にご存知かと思いますが、.NET Frameworkだけでなくマイクロソフトの次期OSであるWindows Vista上のIIS7といったサーバー製品も、自身の設定情報をレジストリやメタデータなどから、XML形式の構成ファイル(.config)に持たせるようデザインが変更されました。これには開発時から実際の運用時への構成の配置の便利さ、編集が容易である、ASP.NETのWeb.configファイルとの統合など様々なメリットが挙げられます。そこで１つの例として私がテスティング時によく直面する構成ファイルにおける問題についてお話しします。

日本で新製品を初めてテストする場合は、当然の事ながら必ず各種機能がひらがな、カタカナなどの日本語を使っても正しく動作するかを確認します。よく遭遇する問題としては、日本語が含まれた構成ファイルをアプリケーションが読み込む時にエラーが発生するケースです。.NET Framework SDKのドキュメント内の国際対応アプリケーションの開発にも書いてありますが、WindowsやVisual Studioのような国際対応アプリケーションを開発するときには、コアとなるコードとユーザーインターフェイスなどを切り分けるモデルを採用します。そして、そのコアコードを書くデベロッパーがアルファベット圏の人で、国際対応アプリケーションを意識したコーディングに慣れていない場合などには、ストレートにANSI既定として構成ファイルを読み込むようにコーディングしてしまう場合があるようです。彼らが使うアルファベットと数字だけの構成ファイルをアプリケーションが読み込めるようにコードを書いているので、構成ファイル内にXML宣言のエンコーディングがUTF-8と設定されている場合などは、特に国際対応アプリケーションのように感じてしまいます。即ちBOM（Byte Order Mark：UnicodeのUTF-16など16ビット幅のエンコーディング方式において、データー内のバイト順を指定するためにファイルの先頭に記入される16ビットの値。UTF-8のBOMは文書がUnicodeで記述されているかどうかを判別するために用いられる。）が無いUTF-8エンコーディングのファイルがアルファベットと数字及び記号だけでしたら、全くANSIと同じ文字コードになるからです。ここに日本語のような２バイト文字を使ったテストを行った時に初めて構成ファイルの解析エラーとなって問題が発生してしまう事があるのです。これはシングルバイトの文字が当たり前の彼らと、マルチバイト文字が当たり前の日本人との間でのエンコーディングに対する意識の違いかもしれません。

また日本語化する翻訳の人が、翻訳後にファイルを保存する時にも別の問題が発生する事があります。構成ファイル内のコメント等を日本語化する作業が開発スケジュールの最後にきた時などが特に危険です。コアコードは２バイト文字の日本語を正しく読み込めるように修正はされてはいますが、基本的にテンプレートとなる構成ファイル自体がアルファベットのANSIファイルベースとして作れられている事があります。

そこで翻訳の人がコメントをメモ帳などで日本語に編集しそのまま既定で保存した場合、XML宣言のエンコーディングはUTF-8と設定されているにもかかわらず、ANSI SHIFT-JISエンコーディングとして保存されてしまいます。そこで今度は、コアコードがXML宣言を見てUTF-8として読み込もうとしますが、実際はANSI SHIFT-JISなので解析エラーとなってしまいます。

従いまして、最初の問題は開発スケジュールの初期に修正されても、次の問題は開発スケジュールの最後の最後にまた発生するかもしれません。
結局製品が出荷されるまでは、どんなに面倒でも同じテストを繰り返す事が重要とされるわけです。

ひらがなやカタカナの取り扱い

ディベロッパー製品開発統括部 — Tue, 20 Dec 2005 07:44:00 GMT

まだ一部残ってはいますが、Visual Studio 2005や .NET Framework 2.0も生産過程に入って開発も一段落しました。先日のMSCのラウンチイベントをはじめとして、立ち上げに際してお客様の話を聞かせていただく機会が幾度とありましたが、もう間もなく稼動に入られるほど準備が整っているかたから、これから評価検討をなされる方まで、様々な方がいらっしゃるようです。今回もすべてのお客様のすべてのご要望を組み入れることは残念ながらできませんでしたが、これまでにお寄せいただいた沢山のご要望や、これからお聞かせいただくご要望に関しては、また今後の製品計画で検討して役に立てていかなければと思います。

閑話休題。さて、そんな中で、最近Unicodeも新しいバージョン5.0のベータが始まりました。Unicodeも弊社のOS製品に採用されて、もう、何年も使い込まれた枯れた技術になった感がありまが、最近では日本語以外の少数派の言語の充実ぶりが目立っています。しかし、意外と今でもひらがなやカタカナのような基本的な日本語の要素に目を向けてみると思わぬ発見があります。 UnicodeではひらがなはU+3040から始まりU+309Fまで、カタカナはU+30A0からU+30FFまでといったブロックとよばれる領域に割り当てられています。この中で、なかなか興味ことがらが4つほどあります。

必ずしもひらがなとカタカナの文字が一対一に割り当てられているわけではない。
必ずしもブロック名でカタカナやひらがなと指定されている文字が、五十音でいうところのそれらであるとは限らない。
ひらがなの小さな「か」「け」やカタカナの「ワ」に濁点のや「ヰ」に濁点といった見慣れない文字がある。
複合用の濁点（U+3099）や半濁点（U+309A）がある

1.はひらがなの領域にReserved（予約）という形式で文字が割り振られていないものがあることが、端的にあらわしています。これらはU+3040、 U+3097、 U+3098ですが、カタカナでは記号やひらがなにない文字が割り振られています。 2.に関しては濁音や半濁音、または長音記号など、がカタカナやひらがなと認識されるブロックに存在しています。 3.は、ひらがなに小さいカタカナの「ヵ」や「ヶ」が対応するものというもののようですが、日常見るものではありません。また、「ヷ」や「ヸ」といった旧仮名遣いのために使うカタカナ固有の文字はありますが、それらのひらがなバージョンはありません。ひらがなの「う」に濁点を打ったものはありますから、なにか規則的にこうなっているのかは不明です。 4.ですが、上記の3の状態を補うためなのかはよく分かりませんが、Unicode固有の概念の複合用の文字のための濁点や半濁点があります。

これらのことを踏まえて考えると、ひらがなやカタカナの判別やその相互変換、Unicode以外のエンコーディングや全角半角といった文字幅への変換は、意外と一筋縄ではいかないのかもしれません。試しにRegExのIsMatchによるIsHiraganaやIsKatakanaの文字クラスを使った正規表現の照合判別や、Visual BasicのStrConv関数、Win32 APIであるLCMapString関数などを使って動作を試してみるのも面白いのかもしれません。

なにか「この動作にはやられた」といったようなお話があれば、トラックバックなどでお聞かせいただければ幸いです。

[2005/12/29: 更新] 一部の言い回しの修正とリンクの追加、文字化けの修正をしました。
[2006/01/05: 更新] 文字化けが修正されていないのをエンティティ参照に変更しました。

エンコーディングの話 Part 2

ディベロッパー製品開発統括部 — Wed, 19 Oct 2005 10:43:00 GMT

(これは、8月17日の「エンコーディングの話 Part 1」の続きです。

やっと、上司から開放されました。長かったですね Part 1 から約２ヶ月も経ってしまいました、本当にすみません。

さて、Part 1 では、内部的な話を中心に話を進めて参りました。Part 2 では、外部とのインターフェース、具体的にはファイルのエンコーディングについて書いてみたいと思います。

ここまで、単に「Unicode」と呼んで参りましたが、Unicode というのは非常に漠然とした表現なので、これより先ではもう少し正確な表現を使いたいと思います。そこで、簡単に Unicode のエンコーディングに関して簡単にまとめたいと思います。詳しい方にとっては極めて大雑把でありながら、なじみの無い方にとっては細かすぎる感じがするかもしれませんが、そこは BLOG なので「まあ、こんなところか...」といった感じに流していただけると幸いです。

２つのUnicode

意外に知られていませんが、Unicode の規格には２種類あります。１つは Unicode コンソーシアムによって標準化されている The Unicode Standard で、もう１つは ISO/IEC 10646 という国際規格です。２種類あると言いましても、まったくの別ものというわけではなく、Unicode コンソーシアムと ISOの担当グループが緊密に連絡を取りながら開発を行っているので符号化文字集合としてはコードポイントまで含めて完全互換になっています。簡単にいえば、どちらの規格でもU+3041 はひらがなの「あ」を意味します。しかし、共通言語ランタイムやC# では、テクニカルレポート等を多く参照しているため、気を付けなければならない点があるのも事実です。近年では、ISO/IEC 10646が規定内容の一部としてThe Unicode Standardの技術内容を引用するなど、両者の互換性はますます高くなってきていますので、特に意識しなくてもあまり問題になることはありませんが、用語などには異なる部分もあるので、調べるときなどは違いを意識した方が良いときも依然あります。

ちなみに、.NET のランタイムやプログラミング言語の仕様では、The Unicode Standard を参照しています。

文字セットとエンコーディング

文字セットとエンコーディングは混同されてしまいがちですが、明確に区別して考えた方が良いでしょう。

Unicode の文字セットはUCS (Unicode Character Set)と呼ばれます。UCSには、符号化文字空間の大きさによってUCS2とUCS4の２種類があります。混同し易いのですが、文字集合を定義したものであってエンコーディングではありません。また、Unicode 3.2 から文字が大量に追加されたので、2バイトの UCS2 はUCS4のサブセットになっています。ちなみに、UCS という呼び方は本来 ISO の呼び方で、The Unicode Standard では、ISO の用語としてAppendix に記載されています。

一方、Unicode のエンコーティングはUTF (Unicode Transformation Format)と呼ばれていて、文字セットと同様UTF8, UTF16、UTF32 というようにビット数に応じていくつかの種類があります。UTF もUCSと同様もともとは ISOの用語ですが最新のThe Unicode Standard 4.0 では詳しい説明とともに規定されています。UTF7 というようなものも存在しますが、The Unicode Standard で規定されているのは、上記の３種類だけなので、ここでは省略します。

詳しくは規格を参照していただきたいのですが、話を進める上で必要なので、UTF8 と UTF16 だけ簡単におさらいしておきたいと思います。

UTF8 …. 8ビットのエンコーディングで、0x00 から 0x7f までの範囲は、ASCII と互換性があります。ASCII 文字は１バイトで表現されますが、一方で殆どの漢字は３バイトになります。ただ、文字の先頭が分かるようになっているので、shift-jis のようになにかで境界がずれると、そこから先はすべて化けるというようなことは起こりません。

UTF16 …. 16ビットのエンコーディングで、0x0000 から 0xffff までは UCS の番号をそのまま使用します。一般に、単にUnicodeといった場合、このUTF16を示すと考えて良いでしょう。メモ帳で保存するとき文字セットに「Unicode」を選択すると UTF16 で保存されます。文字セットがUTF16 というのは奇妙ですが、The Unicode Standard では、文字セットとエンコーディングを厳密に区別せず、Unicode という用語を使用しているため、間違というわけではありません。

また、0xffffを超えるコードポイントをもつ文字はサロゲートと呼ばれる方法で、２つの１６ビットで表現されます。

UTF16 は16ビットですが、CPUの構造上１バイトずつ下位桁から並べるもの（Little Endian）と、上位桁から並べるもの（Big Endian）があるので、UTF16 にはバイトの順序によって、さらに２種類に分かれます。明確に区別する必要がある場合にはUTF16BE, UTF16LE というように記述されます。なぜ、このような細かいお話をしたのは、単に UTF16 と指定した場合にはエンディアン（Endian）を識別するためにBOM（Byte Order Mark）と呼ばれる、特別な１６ビットを先頭に付加することができるのですが、このBOMの扱いがファイルに保存するエンコーディングを考える上で重要な意味を持ってくるからです。

まだまだ書きたいことは山ほどあるのですが、これ以上前置きが長くなってしまうと、本題がまた先送りになってしまいますので、そろそろVisual Studio の話に戻りましょう。

Visual Studio .NET 2005 （現在ベータ版配布中）ではVisual Basic .NET、C#、J#などのプログラミング言語のソースファイルの既定のエンコーディングをshift-jis からUTF8（シグネチャ付き）に変更しました。つまり、新しいプロジェクトを作成したときに、UTF8でソースファイルが作成されます。Visual Studio .NET 2003 までは、XML など一部を除いてソースファイルは、shift-jis で保存されていました。これは、過去との互換性を考慮しての判断だったのですが、最近のアンケート結果やイベント等を見ていると、Unicode がかなり浸透してきているようなので、思い切って変更することに決定しました。もともとC#の言語仕様ではソースファイルはいづれかのUnicodeエンコーディングで保存されることを基本としていますので。そういう意味では、機が熟して、本来あるべき仕様にすることができたということになります。

上では、さらっと、「UTF8（シグネチャ付き）」と書いてしまいましたが、「シグネチャ付き」とはいったい何を意味しているのでしょう。実は、ここでシグネチャと呼んでいるものが、上で説明したBOMです。８ビットのUTF8 にバイトの順番を示す BOMを付けるというのは、まったくもって不思議に思われる方も多いと思います。実際、「絶対に付けるべきではない」と主張されている方も多く、永遠に結論が出ることはないのではないかと思うような議論が繰り広げられています。

なんら根拠はありませんが、経験的には、マークアップ言語やOfficeドキュメントのように、構造を持っていてエンコーディングの指定が可能となるような文章を中心に扱っている方には「付けるべきでない」派が多く、プレーン（なんの構造も持たない）テキストファイルを扱う方には、「あった方が良い」という方が多いように思います。これは、歴史的に Windows では、shift-jis（日本では）が長年使われていましたがプレーンテキストではshift-jisと UTF8を区別する手段がないため、混在してしまうとどうにもならないということからきているのだと思います。このような場合 BOMでを付けることによってBOM がついているかいないかで、かなりの確率でエンコーディングを正しく知ることができるようになります。The Unicode Standard にも、UTF8 でバイトの順番を考える必要はないが、エンコーディングを判別するためのシグネチャとして使用しても良いと記述されています。この記述に合わせて Visual Studio では敢えて「BOM付き」でなく「シグネチャ付き」という言葉を使用しています。

我々は、ソースファイルに「シグネチャ付き」を選択したわけですが、実はプログラミング言語には言語仕様というキチンと定まった構造定義があるので、プレーンテキストではないですね。その気になれば言語仕様の中で、エンコーディングを指定する文法を入れることで判別できるようにすることも不可能ではありません。実際、リソースコンパイラ.rc では、文法中にコードページを指定できるようになっています。しかし、これはリソースコンパイラのように Windows に特化したものだからできたことで、それぞれ違った文法、構造をもったものが多数存在すが一般のプログラミング言語では現実できではないでしょう。すべての言語仕様をこのために変更できるとは思えませんし、仮にできたとしても、文法中にエンコーディングを入れる方法では、言語毎に判別方法が異なってしまいますので、エディタにとっては、たまったものではありません。しかも、コンパイラの結果は目で見ることができないことが多いため、間違ったエンコーディングで読み込んでしまっても、気が付かないというケースも考えなくてはなりません。

このようなことから、我々はソースファイルのエンコーディングの既定値として、UTF8（シグネチャ付き）を選択することにしました。

一方、xml に関しては、Visual Studio .NET 2003 と同様、同じ UTF8 ですが、「シグネチャなし」が既定になります。これは、xml の仕様書ではxml の宣言の前には空白もあってはならないと規定されているため、（BOM を内容の一部と捉えるか、ファイル形式の一部と捉えるかによっても違いますが）仕様を厳格に捉えると BOM があってはいけないということになるからです。そもそも、xml では、上でも触れましたように、その文法の一部としてエンコーディングを指定できるので、BOM みたいなものを付ける必要はまったくありません。

もっとも、最近では xml の仕様書でも、エンコーディング判別のステップの中に、UTF8　のBOM に関して明記してありますし、各種のツールでも対応しているものが多くなったので、以前ほど厳格ではなくなってきたという印象ではあります。

もう少し具体的に Visual Studio .NET 2005 のエンコーディングのサポートについて書きたいところですが、どこからともなく聞きなれた私を呼ぶ声が。。。と、いうわけで、Part 3（完結編？）はこの次ということで。

エンコーディングの話 Part 1

ディベロッパー製品開発統括部 — Wed, 17 Aug 2005 06:47:00 GMT

ここ数年、ソフトウェア自体やソフトウェア開発の国際化が急速に進んでいますね。国際化に対応するために、開発ツールもいろいろな対応が必要になってきています。一方で、開発ツールが高機能化し、多くのコードを自動生成するようになったことで、プログラムの要素と目に見えるもの（ユーザーインターフェースなど）の境目がなくなってきました。結果として、開発効率を向上するためには、プログラム中でも日本語が使用できることが必要になってきています。今回は、こういった国際化と日本における開発効率を両立するための重要なポイントでありながら、意外と語られていない文字のエンコーディング（符号化）について思いつくまま書くつもりです。

今までエンコーディングなんてあまり気にしていなかったという方にも読んでいただきたいので、最初にちょっとだけ、これまでの流れについて触れておきたいと思います。

PCの世界ではMS-DOSの時代から長い間shift-jisが使用されてきました。２０年くらい前は、shift-jis で全く問題ありませんでした。ソフトウェアの国際化は進んでいなかったですし、大半の開発者がプログラムは英語であたりまえと考えていたからです。しかし、ご存知の通り、shift-jis で保存されたテキストファイルは他言語のオペレーティングシステムでは正しく表示できませんし、一つのファイルに多言語のテキストを含めることもできません。これでは、国際化にも対応できませんし、プログラム要素に日本語を使うといったこともできません。そこで、Unicodeの登場です。Unicodeに対しては賛否両論いろいろご意見があるかもしれませんが、認知度や採用実績を考えるとUnicode以上のものは存在しないという点ではおおかたの合意が得られるのではないでしょうか。Microsoftも１０年以上前からオペレーティングシステムでUnicode採用してきていますし、今後もUnicodeを全面的に採用していくことになるでしょう。

そういえば、予断ですが、先日（といってもだいぶ前になりますが）開発環境展に行ってきました。そこでも比較的日本に特化していると思われる帳票のコーナーでさえ、頻繁にUnicode という単語を目にしたような気がします（気がするだけかも）。

さて、開発ツールの話に戻しますと、以前からVisual C++でUnicodeライブラリを使ってUnicodeアプリケーションが開発出来る他、Visual Basicも内部的Unicodeを使用していました。しかし、言語仕様や統合開発環境における本格的なUnicodeサポートとなると意外にも３年前のVisual Studio.NETが最初になります。Visual Studio.NETに含まれる、Visual Basic.NET、Visual C#やVisual J++といった開発言語（以下、まとめて .NET開発言語と呼びます）では、言語仕様を見ていただければ分かるように、言語文法中の文字の定義自体がUnicodeをベースにしています。もちろん、.NET開発言語のベースとなる共通言語ランタイムにおいても、名前や文字列はすべてUnicodeであり、内部的もUnicodeを使用するよう規定されています。

このことによって、クラスやメソッドなどの名前に日本語を使用することができるようになり、しかも日本語のメソッドは他言語（ここでは、英語、中国語など普通の言語、以下、「自然言語）として区別します）のオペレーティングシステム上で正しくコンパイル、実行できるようになりました。例えば、以前はデータベースのフィールド名が英語の場合には、「CustomerField」「RegistrationNumberField」のように分かりやすい名前をつけられても、日本語であった場合には、Field1、Field2というように単に番号を付けただけの名前になってしまっていましたが、.NET開発言語では、英語の場合と同様に「顧客Field」「登録番号Field」といった直感的に分かる名前を付けることができるようになりました。実際、Visual Studio.NETでは、このような分かりやすい名前を自動生成します。同様にMenuItemなども名前に日本語が使用できると、分かりやすい名前が生成できるようになりますね。ここで、国際化という観点では他国の開発者がソースコードを参照する場合のことも考えなければいけませんが、Field1というような名前のまま他の開発者にソースコードを渡すことはないでしょうから、どのみち名前の変更が必要になるのなら、元の名前が分かりやすいに越したことはありませんね。ただし、課題もあります。現状では、日本語の名前はIMEで確定しないとインテリセンスで選択されません。将来的には確定前であってもインテリセンスが動作するようにしたいものです。

ところで、「Unicodeでなくても日本語をクラス名に使用できるようにすることはできるのでは？」という疑問を持つ方もあるかもしれませんが、文字の検証や型安全性、さらにはセキュリティを考えたとき、どの言語のオペレーティングシステム上であっても一意に決まる文字でなければ、クラス名などに使用することはできません。

ここまでコンパイラにはUnicodeで渡っているという前提で書いてきたので、完全に（ライブラリも含めて）内部的な話でした。エンコーディングは渡す側－受け取る側、書き出す側－読み込む側の間の決め事なので、この決め事がしっかり決められている内部では、すんなりUnicodeへ移行できました。さて、問題はソースファイルなど、外の世界とのやり取りです。過去との互換性、他のツールとの互換性などなど考えなければならないことがいっぱい。

本当に書きたかったのは、これからなのですが、ん～、なにやら上司が呼んでいます。という訳で、今週はここまで。続きは近いうちに（できるだけ、来週書けるように頑張ります）。