Excel ソリューションのグローバリゼーションとローカリゼーション

  • [アーティクル]

ここでは、Windows で英語以外の言語を設定しているコンピューター上で実行される Microsoft Office Excel ソリューションで特に考慮が必要な事項について説明します。Microsoft Office ソリューションのグローバリゼーションとローカリゼーションは、ほとんどの点で Visual Studio を使用して他の種類のソリューションを作成する場合と同じです。概要については、「アプリケーションのグローバライズとローカライズ」を参照してください。グローバリゼーションとローカリゼーションの情報は、MSDN Web ページ (Globalization and Localization Issues for Solutions Created with Microsoft Visual Studio Tools for the Microsoft Office System) でも参照できます。

既定では、Microsoft Office Excel のホスト コントロールは、マネージ コードを使用して渡されるデータや操作されるデータがすべて英語 (米国) の書式で設定されている限り、Windows のどの地域設定でも正常に動作します。.NET Framework 4 か .NET Framework 4.5を対象とするプロジェクトでは、この動作は共通言語ランタイム (CLR) までに制御されます。

対象: このトピックの情報は、Excel 2013 と Excel 2010 のドキュメント レベルのプロジェクトおよびアプリケーション レベルのプロジェクトに適用されます。詳細については、「Office アプリケーションおよびプロジェクト タイプ別の使用可能な機能」を参照してください。

さまざまな地域設定と Excel の形式のデータ

日付や通貨など、ロケールに依存する書式設定を持つすべてのデータは、Microsoft Office Excel に渡したり、Office プロジェクトのコードからデータを読み込んだりする前に、英語 (米国) のデータ形式 (ロケール ID 1033) を使用して書式設定する必要があります。

既定では、Visual Studio で Office ソリューションを開発する場合、Excel オブジェクト モデルはロケール ID 1033 によるデータの書式設定を予期します (これは、オブジェクト モデルがロケール ID 1033 にロックされているとも言います)。この動作は、Visual Basic for Applications の動作方法と一致します。ただし、この動作を Office ソリューションで変更できます。

Bb157877.collapse_all(ja-jp,VS.110).gifExcel オブジェクト モデルで常にロケール ID 1033 が予期される理由

既定では、Visual Studio を使用して作成される Office ソリューションは、エンド ユーザーのロケール設定の影響を受けず、常にロケールが英語 (米国) であるものとして動作します。たとえば、Excel で Value2 プロパティを取得または設定する場合、データはロケール ID 1033 が予期する方法で書式設定する必要があります。別のデータ書式を使用すると、予期しない結果が得られる場合があります。

マネージ コードに渡されるデータや、マネージ コードによって処理されるデータに英語 (米国) の書式を使用した場合でも、Excel では、エンド ユーザーのロケール設定に従って、データが正確に解釈および表示されます。Excel がデータを正確に書式設定できるのは、マネージ コードによってデータと共にロケール ID 1033 が渡されるからです。このロケール ID は、データが英語 (米国) の書式であることを示し、ユーザーのロケール設定に合わせてデータを再度書式設定する必要があることを示します。

たとえば、エンド ユーザーの地域オプションがドイツ語 (ドイツ) ロケールに設定されている場合、ユーザーは 2005 年 6 月 29 日という日付が 29.06.2005 として書式設定されることを期待します。しかし、ソリューションがこの日付を文字列として Excel に渡す場合は、英語 (米国) の書式に従って 6/29/2005 と書式設定する必要があります。セルが日付セルとして書式設定されていれば、Excel はこの日付をドイツ語 (ドイツ) の書式で表示します。

Bb157877.collapse_all(ja-jp,VS.110).gifExcel オブジェクト モデルに他のロケール ID を渡す

共通言語ランタイム (CLR) は、ロケールに依存するデータを受け入れる Excel オブジェクト モデルのすべてのメソッドとプロパティに自動的にロケール ID 1033 を渡します。オブジェクト モデルへのすべての呼び出しについてこの動作を自動的に変更する方法はありません。ただし、InvokeMember を使用してメソッドを呼び出し、メソッドの culture パラメーターにロケール ID を渡すことで、特定のメソッドに別のロケール ID を渡すことができます。

文書テキストのローカライズ

プロジェクト内の文書、テンプレート、またはブックには、アセンブリや他のマネージ リソースとは別にローカライズが必要な静的テキストが含まれている場合もあります。それを行う簡単な方法は、文書のコピーを作成し、Microsoft Office Word または Microsoft Office Excel を使用してこのテキストを翻訳することです。どの文書も同じアセンブリにリンクできるため、コードを変更しなくても、このプロセスを実行できます。

この場合でも、文書のテキストを操作するコードがテキストの言語と一致していることを確認する必要があります。さらに、ブックマーク、名前付き範囲、および他の表示フィールドが、Office ドキュメントの再設定に対応していることを確認する必要もあります。この再設定は、異なる文法やテキストの長さに合わせて調整する場合に必要となります。含まれるテキストが比較的少ないドキュメント テンプレートの場合は、テキストをリソース ファイルに保存して実行時に読み込む方法も考えられます。

Bb157877.collapse_all(ja-jp,VS.110).gif[テキストの方向]

Excel では、テキストが右から左へ表記されるようにワークシートのプロパティを設定できます。デザイナーに配置したホスト コントロールまたは RightToLeft プロパティがあるコントロールは、このような設定を実行時に自動的に満たします。Word 文書の場合、テキストの配置を変更できるだけで、双方向テキストの設定はないので、コントロールをこの設定に割り当てることはできません。代わりに、テキストの配置を各コントロールに設定する必要があります。テキストが右から左へ表記されるようにすべてのコントロールを設定するコードを書くことはできます。

Bb157877.collapse_all(ja-jp,VS.110).gifカルチャの変更

ドキュメント レベルのカスタマイズのコードは、通常、スレッド カルチャに対して、そのスレッドで実行されている他のすべてを行った変更は、Excel のメイン UI スレッドを共有します。; 変更は、カスタマイズに制限されません。

Windows フォーム コントロールは、アプリケーション レベルのアドインがホスト アプリケーションによって起動される前に初期化されます。このような場合は、UI コントロールを設定する前にカルチャを変更する必要があります。

Language Pack のインストール

Windows で英語以外を設定している場合は、Visual Studio Tools for Office Runtime Language Pack をインストールして、Windows と同じ言語で Visual Studio Tools for Office Runtime メッセージを表示できます。どのエンド ユーザーが Windows で英語以外に設定しているコンピューターでソリューションを実行する場合、Windows と同じ言語でランタイム メッセージを表示適切な言語パックが必要です。Visual Studio Tools for Office Runtime の言語パックはから Microsoft ダウンロード センター使用できます。

さらに、ClickOnce メッセージ用に、再頒布可能な .NET Framework Language Pack が必要です。.NET Framework Language Pack は、Microsoft ダウンロード センター から利用できます。

地域設定と Excel COM 呼び出し

マネージ クライアントが COM オブジェクトのメソッドを呼び出して、カルチャ固有の情報を渡す必要がある場合、現在のスレッド ロケールに一致する CurrentCulture (ロケール) が使用されます。現在のスレッド ロケールは、既定でユーザーの地域設定から継承されます。ただし、Visual Studio の Office 開発ツールを使用して作成された Excel ソリューションから Excel オブジェクト モデルを呼び出す場合は、自動的に英語 (米国) のデータ形式 (ロケール ID 1033) が Excel オブジェクト モデルに渡されます。日付や通貨など、ロケールに依存する書式設定を持つすべてのデータは、Microsoft Office Excel に渡したり、プロジェクトのコードからデータを読み込んだりする前に、英語 (米国) のデータ形式を使用して書式設定する必要があります。

データの格納に関する考慮事項

データが正しく解釈および表示するためには、アプリケーションが厳密に型指定されたオブジェクトではなくリテラル文字列でデータを、Excel ワークシートの式など、(ハードコーディングされた) 格納する場合に問題が発生する可能性があることを検討してください。カルチャに依存しないスタイルまたは英語 (米国) (LCID 値が 1033) のスタイルを想定して書式設定されたデータを使用する必要があります。

Bb157877.collapse_all(ja-jp,VS.110).gifリテラル文字列を使用するアプリケーション

可能性がある値は、ハードコーディングされた、英語 (U.S.) 形式で書かれた日付リテラルや、ローカライズされた関数名を含む Excel ワークシートの式などです。また、"1,000" などの数値を含むハードコーディングされた文字列がこれに該当する場合もあります。一部のカルチャでは、この数値は "1000" と解釈されますが、それ以外のカルチャでは "1.0" を意味します。誤った形式で数値を計算したり比較したりすると、結果が不適切なデータになることがあります。

Excel では、文字列の解釈は文字列と共に渡された LCID に従って行われます。これは、文字列の書式と、渡された LCID が対応しない場合に問題になることがあります。Visual Studio の Office 開発ツールを使用して作成した Excel ソリューションでは、すべてのデータを渡すときに LCID 1033 (en-US) が使用されます。Excel は、地域設定と Excel ユーザー インターフェイス言語に従ってデータを表示します。VBA (Visual Basic for Applications) の動作も同様です。文字列は en-US として書式設定され、ほとんどの場合、VBA は LCID として 0 (ニュートラル言語) を渡します。たとえば、次の VBA コードは、現在のユーザーのロケール設定に従って、2004 年 5 月 12 日を正しい形式の値で表示します。

'VBA
Application.ActiveCell.Value2 = "05/12/04"

同じコードを Visual Studio の Office 開発ツールを使用して作成したソリューションで使用し、COM 相互運用機能を通じて Excel に渡すと、日付の書式を en-US スタイルに設定した場合と同じ結果が得られます。

次に例を示します。

Me.Range("A1").Value2 = "05/12/04"

this.Range["A1"].Value2 = "05/12/04";

できるだけリテラル文字列ではなく厳密に型指定されたデータを使用してください。たとえば、日付をリテラル文字列ではなく Double として格納し、操作時に DateTime オブジェクトに変換します。

次のコード例では、ユーザーがセル A5 に入力した日付を取得して Double として格納し、それを DateTime オブジェクトに変換してセル A7 に表示します。セル A7 には、日付を表示する書式が設定されている必要があります。

Private Sub ConvertDate_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
    Handles ConvertDate.Click

    Try
        Dim dbl As Double = Me.Range("A5").Value2
        Dim dt As System.DateTime = System.DateTime.FromOADate(dbl)
        Me.Range("A7").Value2 = dt

    Catch ex As Exception
        MessageBox.Show(ex.Message)
    End Try
End Sub

private void ConvertDate_Click(object sender, EventArgs e)
{
    try
    {
        double dbl = (double)(this.Range["A5"].Value2);
        System.DateTime dt = System.DateTime.FromOADate(dbl);
        this.Range["A7"].Value2 = dt;
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

Bb157877.collapse_all(ja-jp,VS.110).gifExcel ワークシート関数

ほとんどの場合、どの言語のバージョンの Excel でも、ワークシート関数の名前は内部で変換されます。ただし、言語や COM 相互運用機能に問題が発生する可能性があるため、コード内では英語の関数名のみを使用することを強くお勧めします。

Bb157877.collapse_all(ja-jp,VS.110).gif外部データを使用するアプリケーション

レガシ システムからエクスポートされたコンマ区切り値を含むファイル (CSV ファイル) などの外部データを開いたり使用したりするコードは、ファイルが en-US 以外の形式でエクスポートされる場合に影響を受けることもあります。データベースへのアクセスは、すべての値がバイナリ形式なので、影響を受けないと考えられます。ただし、データベースで日付が文字列として保存されていたり、バイナリ形式を使用しない操作が実行されたりする場合は、この限りではありません。また、Excel のデータを使用して SQL クエリを作成する場合、使用する関数によってはデータを en-US 形式にする必要があります。

参照

処理手順

方法 : Office Multilingual User Interface を使用する

概念

Office ソリューションの省略可能なパラメーター

その他の技術情報

Office ソリューションのデザインと作成