1

異なるカルチャで文字列入力を処理する際のアプリケーションの予測可能性について懸念しています。これは古いソフトウェアの問題であり、新しいソフトウェアでも問題になりたくありません。

私は一般的に 2 つの情報源を持っています。テキストを含む、ファイルからロードされた、WPF アプリケーションおよびストリームに入力された文字列。これらの文化的な文字列は、通常、使用される前にモデルに入力されます

public struct MyModel
{
    public String Name;
}

Result DoSomething(MyModel model);別のマシンで入力されたテキストが含まれている場合に、一部のロジックが実際に処理できることを確認する意味のあるテストを設計したいと考えています。

しかし、違いが重要なケースをどのように示すことができますか?

たとえば、次は失敗します。

 var inNativeCulture= "[Something12345678.9:1] {YeS/nO}";
 var inChineseCulture = inNativeCulture.ToString(new CultureInfo("zh-CN"));
 Assert.That(inChineseCulture, Is.Not.EqualTo(inNativeCulture));

[質問]

DoSomething文字列が InvarientCulture に変換されていない場合にテストが失敗するようにテストするにはどうすればよいですか?

私も気にする必要がありますか？つまり、Somethingフランス語のキーボードで入力された文字列は、常にSomething中国語のキーボードで入力されたものと同じになりますか?

グローバリゼーションの問題を軽減するために何をテストできますか?

4

1 に答える 1

3

文字列で IFormatProvider を受け取る ToString メソッドは、基本的にノーオペレーションです。ドキュメントには、「この文字列のインスタンスを返します。実際の変換は実行されません」と記載されています。

問題を回避することを懸念しているため、ここにいくつかの一般的なアドバイスを示します。まず、フロントエンド (ユーザー向け) の文字列とバックエンド (データベース、ワイヤ、ファイルなど) の文字列を明確に区別しておくと非常に役立ちます。フロントエンド文字列は、ユーザーの文化/アプリケーション言語に従って生成/受け入れられる必要があります。これらの文字列は永続化しないでください (機械ではなく人間だけが読み取るドキュメントを生成する場合など、いくつかの例外を除きます)。バックエンド文字列は、時間の経過とともに変化しない標準形式を常に使用する必要があります。グローバル化された文字列の生成/解析に使用されるデータが変更されるという事実を受け入れる場合は、ユーザーが直面する文字列を保持しないようにすることで、その影響から自分自身を切り離すことができます。

于 2013-03-07T21:06:16.323 に答える