4

を使用して日付/時刻文字列を解析しようとしていますDateTime.ParseExact。1 台のマシンを除いて、どこでも機能します。そのマシンでは解析されません。質問は次のとおりです。なぜですか。この動作を引き起こすために、そのマシンで何が異なる可能性がありますか?

ここに私がすでに見たいくつかのことがあります:

  • CultureInfoに渡されDateTime.ParseExactます。つまりCultureInfo.InvariantCulture
  • 不正なマシンの地域設定は、解析が機能するマシンの設定と同じです。
  • はい、文字列は正しい形式です。dd/MM/yyyy HH:mm:ss
4

4 に答える 4

6

私はいつも、地域の設定が難しい場合があり、アプリケーションのユーザーが自分のマシンを最初から正しくセットアップしているとは決して想定できません!

日付が文字列である必要がある場合に日付を解析するために使用してきたキャッチオールは、「dd/MMM/yyyy」形式で解析することです。たとえば、「14/JAN/2009」は、設定は。

ちなみに、このトリックはSQL Serverでも機能します:)

于 2009-01-14T03:10:22.150 に答える
1

例外情報 (Marc Gravell が尋ねたもの) やサンプル コードがなければ、解決策を推測するのは非常に困難です。

私の経験では、文化的な問題のために日付/時刻に問題がありました。あなたはすでにそれをハードコーディングしようとしていると言いました。

プロセスが実行されている実際の文化はどうですか? このコードが asp.net Web サイトにある場合、カルチャはユーザーのブラウザー設定 (要求で渡される) に基づいて設定されます。

コードでこれを実行して、現在のスレッド カルチャをハードコードし、この問題をさらにデバッグする方法として役立つかどうかを確認してください。

// Replace the culture with whatever you required.
System.Threading.Thread.CurrentThread.CurrentCulture = 
    CultureInfo.CreateSpecificCulture("en-GB"); 

それを試すとどうなるか教えてください。** 十分な情報がないときに回答を入力するのは嫌いです。これは答えというよりも提案です:)

于 2009-01-14T00:45:34.253 に答える
0

動作しないマシンの地域設定が、動作するマシンと一致していることを確認してください。今後このような問題を回避するには、解析時にカルチャを指定してください。

于 2009-01-14T01:13:59.780 に答える
0

より多くの情報が必要であるという Pure.Krome の意見に同意します。そのために、質問:

  • どの例外がスローされていますか?
  • どのメソッド オーバーロードを呼び出していますか? また、正確には何をそれに渡していますか?
  • .NET ランタイムのバージョンがすべてのボックスで同じであることを確認しましたか? Service Pack バージョンを含めますか?
  • 解析している文字列はプログラムによって生成されたものですか、それとも外部ソースからのものですか? 外部の場合、文字列が不正なボックスで何らかの方法で不適切にエスケープされていないことを確認しましたか? 文字列を作成するプログラムのバージョンが古く、バグがある可能性があります。
于 2009-01-14T01:49:48.007 に答える