国際化

多機能な CultureInfo クラスを利用して .NET の世界を身近なものにする

Michael Kaplan

翻訳元: Make the .NET World a Friendlier Place with the Many Faces of the CultureInfo Class (英語)

この記事で使用する技術: .NET Framework および C#

この記事で取り上げる話題:

• CultureInfo の機能
• コレーション、大文字と小文字の変換、書式設定、およびリソース読み込み
• .NET Framework 2.0 における CultureInfo の変更点

目次

1. プロパティからの CultureInfo 取得
2. 初期設定からの CultureInfo 取得
3. 入力メソッドからの CultureInfo 取得
4. CultureInfo オブジェクトの新規作成
5. 大文字変換と小文字変換
6. コレーション
7. 書式設定と文字列解析
8. リソース読み込み
9. エンコード
10. 入力言語
11. 最近の変更点
12. カスタム カルチャとその未来
13. 補足記事: Parse と ParseExact の比較

Microsoft .NET Framework において、最も広範に使用されるクラスの 1 つが CultureInfo です。このクラスのオブジェクトは、リソース読み込み、書式設定、文字列解析、大文字と小文字の変換、並べ替えや、言語、ロケーション、または開発システムの差異に依存するその他の仕様への対応を行うために使用されます。 このクラスは比較的複雑なクラスであり、あらゆる状況で正しく使用するには工夫が必要です。

この記事では、CultureInfo を使用するシナリオについて解説します。また、CultureInfo の動作、ベスト プラクティス、および誤った決断の結果についての十分な情報も提供します。これらの情報を参考にすることで、CultureInfo とそれに関連した System.Globalization 名前空間内のクラスを将来のプロジェクトで使用する場合に正しい選択ができるようになります。

すべてはオブジェクトの作成から始まりますが、CultureInfo オブジェクトを取得するにはさまざまな方法があります。CultureInfo.CurrentCulture、CultureInfo.CurrentUICulture、CultureInfo.InvariantCulture など組み込みのプロパティからカルチャを利用することができます。また、選択した入力メソッドまたはインストールした入力メソッドに基づく組み込みの CultureInfo を使用することもできます。アプリケーションが作成した CultureInfo インスタンスを使用することもできますし、あるいはカルチャをまったく使用しないことも可能です。

ページのトップへ

1. プロパティからの CultureInfo 取得

CultureInfo.CurrentCulture プロパティから返される CultureInfo インスタンスは、ユーザーが Windows の [地域のオプション] (図 1 参照) で選択したロケールに基づいています。このロケールは、プログラマからは "ユーザー ロケール" と呼ばれ、Windows XP および Windows Server 2003 の [標準と形式] では "言語" と呼ばれます。.NET ではこのロケールの値をスレッド レベルで変更できます。ただし、アプリケーション実行中に [地域のオプション] で言語を変更しても、ロケールの値は変更されません。実際、CultureInfo.ClearCachedData メソッドを呼び出さない限り、個々の設定変更すら検出されることはありません。

図 1 CurrentCulture を示す Windows の [地域のオプション]

残念ながら、ユーザーが [地域のオプション] で設定を変更しても、特定のイベントが発生することはありません。現在の入力言語を変更したときにはイベントが発生しますが、全般的な設定を変更してもイベントは発生しないのです。ただし、ユーザーによってこの設定が変更されると必ず、WM_SETTINGSCHANGE メッセージが Windows からブロードキャストされます。.NET Framework アプリケーションがこのコンテキスト内の変更に対応するためのコードを図 2 に示します。このコードでは、該当するメッセージ、つまり LPARAM に "intl" 文字列を含む WM_SETTINGCHANGE を待機します。このメッセージが渡されると、変更されたロケール全体または個々の設定のいずれかに対して適切な変更を行います。ユーザーがコントロール パネルから行った変更に .NET ベースのアプリケーションが対応するには、このコードで使用されているようなメソッドを使用することが重要です。

図 2 [地域のオプション] の変更への対応

private const int WM_SETTINGCHANGE = 0x001A;

[DllImport("kernel32.dll", ExactSpelling=true)]
private static extern int GetUserDefaultLCID();

CultureInfo m_ciOld = new CultureInfo(GetUserDefaultLCID());

protected override void WndProc(ref Message m) {
  switch(m.Msg)
  {
    // システム全体の、またはポリシー設定の変更
    case WM_SETTINGCHANGE: 

      if(m.LParam != IntPtr.Zero) {
        int localeCur = GetUserDefaultLCID();
        string val = Marshal.PtrToStringAuto(m.LParam);

        if(val == "intl") {
          // ロケール設定の変更
          Thread thread = Thread.CurrentThread;

          if(thread.CurrentCulture.LCID != localeCur() &&
            thread.CurrentCulture.LCID == m_ciOld.LCID) {
            // ユーザーの既定ロケールが変更された場合
            // 使用中のカルチャを変更します
            thread.CurrentCulture = new CultureInfo(localeCur);
          }
          else
          {
            // 個々の設定の一部が変更された場合
            // キャッシュ データをクリアして、変更内容を取得します
            thread.CurrentCulture.ClearCachedData();
        }

        m_ciOld = new CultureInfo(localeCur);
      }
    }
    break;
  }

  base.WndProc (ref m);
}

CurrentCulture またはその他のオプションを使用するかどうか決断する場合は、CurrentCulture の設定が、日付、時刻、数値の書式や並び順などの情報の表示形式に関するユーザーの設定を表していることに留意してください。

ページのトップへ

2. 初期設定からの CultureInfo 取得

CurrentUICulture オブジェクトの初期設定は、Windows のインターフェイス言語に基づいています。Windows に MUI (Multi-lingual User Interface) 機能が組み込まれている場合、この設定はユーザーによって行われますが、組み込まれていない場合は、Windows がローカライズされている言語によって決まります。アプリケーションの開発者は、ユーザー インターフェイスとともに単一または複数の希望する言語を提供します。利用可能な複数の言語からユーザーが 1 つの言語を選んで変更できるようにする場合、言語選択用に独自のユーザー インターフェイスを用意することもできます。ユーザー インターフェイスの言語を選択するときには、ほとんどの場合において CurrentUICulture のみが使用できます。通常、CurrentUICulture の値は CurrentCulture の値と同じになりますが、異なることもあります。適切なユーザー インターフェイス言語を利用できる場合は、この点に常に留意する必要があります。

ページのトップへ

3. 入力メソッドからの CultureInfo 取得

入力言語とは、カルチャとキーボード レイアウトのペアです。この組み合わせによって、キーボード上の物理的なキーが言語の文字にマッピングされます。System.Windows.Forms.InputLanguage クラスでは、以下の機能が提供されます。

• コンピュータにインストールされている入力言語の完全なリストを格納したコレクションへの読み取り専用アクセス。このアクセスには InstalledInputLanguages プロパティを使用します。
• 既定の入力言語への読み取り専用アクセス。このアクセスには DefaultInputLanguage プロパティを使用します。既定の入力言語は、新規スレッドまたは新規プロセスの初期入力言語として使用されます。
• 現在のスレッドが使用している入力言語への読み書きアクセス。このアクセスには CurrentInputLanguage プロパティを使用します。

さらに、Windows フォームでは、InputLanguageChanging および InputLanguageChanged という 2 つのイベントが用意されています。両イベントは、内部に CultureInfo を含む InputLanguage オブジェクトを提供します。CultureInfo は、ユーザーの入力言語に関連した操作を行う場合に役立ちます。これには、言語に関する保存情報や適切なディクショナリまたはシソーラスの選択情報が格納されています。

ユーザー設定やアプリケーション設定の変更に依存しないオブジェクトが必要になる場合は多々あります。そのために、InvariantCulture が作成され、開発者に公開されました。

前述のカルチャの 1 つに準拠するのと同様に重要なことですが、(不変カルチャも含めて) カルチャを一切使用しないのが適切な選択になることがあります。これらのシナリオのいくつかは、後述のコレーションに関するセクションで説明します。重要なのは、どのような場合にこうした決断が必要になるかを認識することです。

ページのトップへ

4. CultureInfo オブジェクトの新規作成

ほとんどのアプリケーションでは必要ありませんが、特定のユーザー設定に依存しない CultureInfo オブジェクトを単純に作成する機能が非常に役立つ場合もあります。これらのシナリオには、利用可能な CultureInfo の選択の列挙、他のカルチャ設定を使用したアプリケーションの動作確認、特定のカルチャで発生したバグの再現、外部から提供された情報 (ASP.NET ページへの HTTP 要求など) を基に現在のカルチャまたは UI カルチャに割り当てるオブジェクトの作成などが含まれる場合があります。以上で、CultureInfo の取得方法の説明が終わりました。以下のセクションでは、CultureInfo オブジェクトを使用した処理について説明します。

ページのトップへ

5. 大文字変換と小文字変換

大文字と小文字の変換は最も簡単な処理と言われていますが、いくつかの誤解から非常に多くのバグを生じさせる処理でもあります。大文字と小文字の変換とは、文字列を大文字から小文字に、小文字から大文字に変換することです。その際、チュルク語の変換規則を採用している言語が 2 つ (トルコ語とアゼリ語) あるため、注意が必要です。図 3 に示すように、これら 2 つのカルチャでは、1 と 2 がそれぞれ同じ文字の大文字と小文字に対応し、また 3 と 4 が同様に同じ文字の大文字と小文字に対応します。その他のカルチャでは、1 と 4 が同じ文字の大文字と小文字に対応します。

図 3 チュルク変換規則

チュルク規則に従って大文字変換や小文字変換を行った後、チュルク規則を使用せずに結果を比較する場合、文字列を識別する際にコードに深刻な問題が発生することがあります。

チュルク変換規則を使用するかどうかを決断するにあたり、特殊なシナリオを調べることが重要になります。もちろん、トルコ語またはアゼリ語を使用するユーザーは、変換にあたりチュルク規則に従った文字列が表示されることを期待します。また、ファイル名やレジストリ キーにかかわる処理において、チュルク規則を使用してはならないことは言うまでもありません。ユーザーに表示される文字列は、外部ソース、またはアプリケーションの実行ユーザーと整合性を持たせる必要のある文字列と区別することが重要です。

代替的な対応規則を持つカルチャは他にありませんし、そのような規則を持つ他の言語も知りませんが、この例外的なケースに適切に対応できれば、将来発生しうる問題についても対処できます。CurrentCulture を適切に使用してトルコ語を処理することにより、将来のカルチャについて同様の問題が発生した場合でもユーザーの期待通りに処理できるようになります。

ページのトップへ

6. コレーション

コレーションについて CultureInfo の観点から述べてきましたが、コレーションに関連したメソッドはすべて System.Globalization.CompareInfo から提供されます。ただし、CompareInfo を取得するには、CultureInfo.CompareInfo プロパティを使用するか、カルチャ名または ID を静的 CompareInfo.GetCompareInfo に渡すかのいずれかの方法を使用する必要があります。そのため、カルチャの観点からコレーション メソッドの選択方法について説明するほうが簡単なのです。

コレーティングまたはソーティングとは、アイテムの単純な並べ替えのことです。これは最も基本的な機能の 1 つであり、誰もが適切に動作することを期待します。並べ替えは完全に透過的に行われるのが理想的です。Windows エクスプローラに似た一覧表示画面でヘッダー列をクリックするとき、ユーザーは使用しているカルチャや言語の規則に従って列が並べ替えられることを想定しています。

幸運なことに必要な処理の大部分は既に作成済みであり、開発者が行うことは適切なカルチャと設定を選択することだけです。CurrentCulture、InvariantCulture、および CompareOptions.Ordinal の 3 つを組み合わせて使用することで、考えられるほとんどすべてのシナリオに対処できます。

CurrentCulture は、ユーザーにデータを表示しているときにそのデータを直感的に並べ替えたり、比較したりする場合に使用します。これは既定の設定ですが、明示的に指定したほうが良い場合も少なくありません。明示的に指定することによって、FxCop などの静的な分析ツールからの警告を回避できます。また、すべてのオプションについて考慮したということを意識できます。

InvariantCulture は、言語的な観点から適切な結果が必要になる場合に使用します。ただし必要なのは、ユーザー設定が変更された場合でも並び順が変化しないという結果です。このプロパティは並べ替えを行う場合に使用されることはあまりなく、文字列の比較を行う場合に、より頻繁に使用されます。

CompareOptions.Ordinal は順序フラグ (.NET Framework 2.0 に新たに追加された OrdinalIgnoreCase と同様のフラグ) であり、文字列を不変のバイナリ値で比較する場合に使用します。これは、最速の比較方式であるだけでなく、並べ替えの重み付けが行われていない文字 (双方向レンダリングで使用される方向書式文字など) に対し、その文字を無視するのでなく何らかの重み付けを行う場合に最適な比較方式でもあります。

ファイル名を決定したりそれらのファイル名が等しいかどうかを判定する場合、4 番目の要件が必要になることがあります。残念ながら、上記した 3 つの方法では、マネージ コードおよびアンマネージ コードの両方において、この問題に対する完全な回答を得ることはできません。正しい解答を得る唯一の方法は、ファイルを作成し、既に例外が存在している場合にその例外をトラップすることです。

CultureInfo について最後に説明する機能は、リソース読み込み、ロケールに基づくエンコード、および入力メソッドです。これらは、より理解しやすい機能、または解読が難しい場合にも壊れにくい機能と考えることができます。

ページのトップへ

7. 書式設定と文字列解析

文字列解析を行う場合、コードを保護するために、可能であれば Parse よりも ParseExact の使用を考慮したほうがよいでしょう。Parse 使用による柔軟性は、それが必要とされる場合にはすばらしいものですが、関連した問題を発生させるリスクを負わないために、不要であれば使用しないことを推奨します。補足記事 "Parse と ParseExact の比較" では、これら 2 つのメソッドの相違点について解説しています。

カルチャの使用全般にあたって、最も管理が難しく、また困難が伴う機能は書式設定と文字列解析です。観念的には、書式設定と文字列解析とは逆の処理と言えます。そのため、ここではひとまとめにして説明します。書式設定と文字列解析が逆の処理とはならない場合が 2 つあります。その 1 つがカスタム書式を使用した数値、日付、または時刻の文字列変換です。書式設定の対象文字列は、解析やデータの取得に使用されることはありません。もう 1 つは書式文字列が既定ではなく、ParseExact の代わりに Parse が使用される場合です。これは、Parse の発見的解決法が情報の読み取りに失敗することがあるためです。

このサポートの核となるのが IFormatProvider インターフェイスです。このインターフェイスは、System.Globalization 名前空間に含まれる多数のクラス (CultureInfo、NumberFormatInfo、DateTimeFormatInfo など) にサポートされています。IFormatProvider インターフェイスには、1 つのメソッド、GetFormat が用意されています。文字列解析および書式設定を実行するコードはこのメソッドを使用して正しい書式情報を取得します。書式設定および文字列解析を実行するメソッドの大部分には、IFormatProvider を許可するオーバーライドが少なくとも 1 つ用意されています。

単一のインターフェイスが使用されるという点は欠陥にもなりえます。コードでは、NumberFormatInfo が DateTime.Parse に渡されるケースについても対処する必要があります。この場合、パラメータは無視されることになります (ただし、現行バージョンの FxCop においても、IFormatProvider が渡される場合に警告は表示されません)。書式設定の際や、数値の書式や文字列解析のメソッドに DateTimeFormatInfo が渡される場合に、同様の問題が発生することがあります。通常は CultureInfo を使用することを推奨します。なぜなら、オブジェクトを特にカスタマイズしていて、かつ適切なオブジェクトを渡しているという場合を除けば、より特殊な DateTimeFormatInfo クラスや NumberFormatInfo クラスを CultureInfo から取得できるからです。FxCop の将来のバージョンでは、低速バージョンの NULL (別の 2 つのタイプのうちの 1 つかどうかをまずチェックする必要があるため低速) しかパラメータとして渡されなかった場合に警告を表示する機能が追加されるかもしれません。

ページのトップへ

8. リソース読み込み

他の言語をサポートするアプリケーションの場合、CurrentUICulture を既定で使用するという単純なルールを設定することで、リソース読み込みを簡単に処理できるようになります。ASP.NET アプリケーションまたは Windows フォーム アプリケーションのいずれかをローカライズする場合、リソース読み込みメソッドでは既定でこの設定が使用されます。もちろん、異なる言語を使用する別の CultureInfo を渡すことで、既定の設定をオーバーライドすることもできます。

ユーザーの期待に一致するように CurrentUICulture を設定してください。CurrentUICulture では、Windows の UI 言語、HTTP_ACCEPT_LANGUAGE ヘッダーに含まれる情報を基にした、ユーザーについての Web サーバーの判断、アプリケーションに用意したその他のインターフェイス選択のいずれかを使用できますが、どれを使用するかはアプリケーションの設定に完全に依存します。推奨されるルールの 1 つは、Windows MUI と同じモデルを採用し、アプリケーションがサポートする言語の一覧を各言語のネイティブ名 (CultureInfo.NativeName) を使用して提供することです。これは非常に単純ですが、常識的な方法でもあります。なぜなら、ユーザーが言語名を読めなかったとしたら、インタフェースをその言語に切り替えることもできないからです。

ページのトップへ

9. エンコード

エンコードは、System.Text.Encoding クラスとそのインターフェイスをサポートするさまざまなクラスによって提供されます。エンコードに関しては多くの記事で扱われていますが、カルチャ固有のサポートについては、ANSI、OEM、Mac、EBCDIC など各言語のコード ページに限定されています。レガシ コード ページとの間で双方向変換を実際に行う場合、特定のカルチャについて考慮するよりも、コード ページについて知る必要があります。したがって、カルチャベースのエンコード機能は非常に限定されています。コード ページベースのエンコードについて調べ、正しいコード ページ変換を使用してデータをエンコードするのが最良の方法です。

ページのトップへ

10. 入力言語

入力言語 (入力メソッドと呼ばれることもあります) のサポートは、InputLanguage クラスによって提供されます。.NET Framework では、ユーザーが既にインストール済みの言語しか使用できないため、このクラスの機能は限定されたものとなります。すべての InputLanguage オブジェクトには Handle プロパティが用意されています。ハンドルは常に特定のサイズ (32 ビット プラットフォームでは 32 ビット、64 ビット プラットフォームでは 64 ビット) を持つわけではありませんが、InputLanguage の Handle のサイズは 32 ビットに固定されており、そのうち上位 16 ビットは LCID の値です。InputLanguage のカルチャは、この LCID から作成されます。

スペル チェックや文法チェックを実行するツールの使用方法など、アプリケーションで言語固有の選択を行う場合、このカルチャが非常に役立ちます。Microsoft Word のようなアンマネージ アプリケーションでは、まさにこうした目的のために、入力言語ハンドルの上位 16 ビットに格納された LCID が使用されます。それにより、入力メソッドが指定された言語を基に、ドキュメントが適切な言語になるようにいくつかの部分にタグが付けられます。

この手順に従う場合、単に選択された言語を基にするのではなく、入力された文字を基に文字処理を行うロジックを組み込むのもよいでしょう。それにより、ユーザーがキーボードをまったく無関係な言語と組み合わせるなど (アラビア語キーボードをハンガリー語と組み合わせるなど)、Word ですら処理できないような非常事態を回避できます。.NET Framework にはキーボード言語を取得する手段は用意されていませんが、図 4 に示すように P/Invoke を使用できます。

図 4 キーボード言語の取得

[DllImport("user32.dll")]
private static extern bool GetKeyboardLayoutName(StringBuilder pwszKLID);
private const int KL_NAMELENGTH = 9;

private CultureInfo CultureOfCurrentLayout() {
    StringBuilder sb = new StringBuilder(KL_NAMELENGTH);

    if(GetKeyboardLayoutName(sbKLID)) {
        int klid = int.Parse(
           sbKLID.ToString().Substring(KL_NAMELENGTH - 1),
           NumberStyles.AllowHexSpecifier, CultureInfo.InvariantCulture);

        // 数値の下位 16 ビットのみを残します
        klid &= 0xffff;

        return new CultureInfo(klid, false);
    }

    return(null);
}

この関数は、言語、地域、スクリプトなどキーボード設計の基となる情報を示す CultureInfo を返します。

ページのトップへ

11. 最近の変更点

Windows-Only Cultures .NET Framework では、さまざまなバージョンの Windows のカルチャと比較して、より広範なカルチャがサポートされています。しかし、Windows XP SP2 に新たに 25 のロケールが追加されたことで、それが逆転しました。これにより、CurrentCulture と CurrentUICulture の両プロパティ、および InputLanguage クラスに重大な問題が発生します。これらのプロパティは、Windows のロケール識別子 (LCID) の値を使用して単純にカルチャを作成していたからです。

この問題に対するソリューションとして、.NET Framework 2.0 では、Windows では利用できるものの Framework では利用できないオブジェクトを作成する場合に、CultureInfo オブジェクトを合成する機能が用意されます。これまでのセクションで説明した原則に従うことにより、これらの "Windows 専用" の CultureInfo オブジェクトをアプリケーションでうまく処理できるようになります。

拡張された新しい CultureTypes 列挙体 .NET Framework 1.x では、CultureTypes 列挙体が以下のように定義されていました。

[Flags]
public enum CultureTypes 
{
    NeutralCultures        = 0x0001,
    SpecificCultures       = 0x0002,
    InstalledWin32Cultures = 0x0004,
    AllCultures            = NeutralCultures | SpecificCultures |
                             InstalledWin32Cultures,
}

この列挙体には新しいタイプのカルチャ (Windows 専用、カスタム、および代替) を追加する余地があまりありません。そのため、.NET Framework 2.0 では、図 5 に示すように、更新された CultureTypes 列挙体が用意されています。

図 5 更新された CultureTypes 列挙体

public enum CultureTypes 
{
    NeutralCultures         = 0x0001,  // "en"、"de"、"zh" など
                                       // 中立的なカルチャ
    SpecificCultures        = 0x0002,  // "en-us"、"zh-tw" など
                                       // 非中立的なカルチャ
    InstalledWin32Cultures  = 0x0004,  // Win32 システムにインストールされ
                                       // Framework にも存在する
                                       // カルチャ
    
    AllCultures             = NeutralCultures | SpecificCultures | 
                              InstalledWin32Cultures,
    
    UserCustomCulture       = 0x0008,  // ユーザー定義のカスタム カルチャ
    ReplacementCultures     = 0x0010,  // ユーザー定義の
                                       // 代替カスタム カルチャ
    WindowsOnlyCultures     = 0x0020,  // Win32 には存在するが
                                       // Framework には存在しないカルチャ
    FrameworkCultures       = 0x0040,  // Framework 付属のカルチャに一致する
                                       // 言語タグ
}

この列挙体には、新しいカルチャ タイプを追加する余地が確保されているだけでなく、将来においてカルチャを拡張することも可能になっています。AllCultures を使用する既存のコードも継続して動作しますが、新しいコードでは CultureTypes 列挙体に新たに追加されたメンバを使用するべきです。これらのメンバーは列挙体の値とフラグから構成されており、この値とフラグを組み合わせて使用できます。たとえば、UserCustomCultures に NeutralCultures または SpecificCultures フラグを関連付けて使用できます。CultureInfo.GetCulture を呼び出す場合、最も限定されたカルチャ タイプを渡すことで要件を満たすことができます。

ページのトップへ

12. カスタム カルチャとその未来

.NET Framework 2.0 には、カスタム カルチャの作成機能も新規追加されています。この機能は、CultureAndRegionInfoBuilder クラスを使用して新しいカルチャを作成することによって実現されます。この記事で提示したベスト プラクティスに従うことにより、カスタム カルチャを使用したマネージ アプリケーションが、まず間違いなく正しく動作するようになるでしょう。

CultureInfo は豊富な機能を持った強力なクラスであり、コンピュータやアプリケーションのユーザー インターフェイスに共通する、ほとんどすべての側面を包含しています。このクラスが提供する強力な機能を利用するにあたり、各状況で CultureInfo のどの機能を使用するかについて確実に正しい選択を行うことが重要です。若干の考慮を払うことによって、CultureInfo を利用する際の効率性と有効性が最大化されることも少なくありません。

ページのトップへ

13. 補足記事: Parse と ParseExact の比較

文字列を解析するためのメソッドとして、Parse と ParseExact の 2 つが用意されています。Parse メソッドの機能は COM に根差しており (COM 自体は旧バージョンの Visual Basic に根差しています)、処理コストの程度にかかわらず文字列から日付への変換が行われました。不適切な文字列解析を行うことのリスクは、処理に悪影響が伴うことにあります。この悪影響の 1 つは、dd/mm/yy や mm/dd/yy の日付書式を指定する場合に明らかとなります。Microsoft .NET Framework に用意されている DateTime.Parse メソッドは、以前のメソッドとほぼ同じ目的に使用されますが、残念なことに以前と同じ問題をいくつか抱えています。余分なチェックが行われるため処理に時間がかかり、正しく検出されない新しい書式は今後も常にいくつか存在します。覚えているかもしれませんが、こうした動作を "邪悪な日付解析" と侮蔑的に呼ぶことがありました。

一方、DateTime.ParseExact メソッドは、DateTimeFormatInfo オブジェクトで指定された正しい書式を受け取り、その書式を使用して処理を行うだけです。書式に一致しないデータが処理されることはありません。また、余分なスペースを許容するかどうかを巡る興味深い議論がマイクロソフト社内で行われています。簡単に言うと、ParseExact メソッドの目的は、"書式があり、その書式が設定された文字列がある場合に、解析を実行する" という流れに沿っています。ParseExact を使用することで処理速度が高速化され、セマンティックとしてもより正確になります。そのため、DateTime.Parse メソッドの柔軟性が不必要な場合には ParseExact メソッドを使用することを強く推奨します。

Michael Kaplan はマイクロソフトの技術を先導する一人であり、Windows と .NET Frmework の双方の開発を担当しています。専門分野は、コレーション、キーボード、ロケール、および Unicode のサポートです。Kaplan は C# で記述されたツール MSKLC (Microsoft Keyboard Layout Creator) の開発者であり所有者でもあります。Kaplan の連絡先は phelland@microsoft.com (英語) です。

この記事は、MSDN マガジン - 2005 年 3 月号からの翻訳です。