Scott Hanselman のDeveloper Interview question listを閲覧していて、次の質問に出くわしました。
DateTime.Parse(myString) の何が問題になっていますか?
不明な形式または出所の文字列を解析することには固有のリスクがあることはわかっていますが、他の理由はありますか? 代わりに DateTime.ParseExact を使用するのですか? 最初に myString.ToString() にする必要がありますか?
16539 次
8 に答える
28
さらに、ロケールの問題によりDateTime.Parse()、例外がスローされる可能性があり、それをキャッチする必要があります。代わりにDateTime.TryParse()またはを使用してください。DateTime.TryParseExact()
于 2008-10-02T13:46:48.833 に答える
14
システムで現在のスレッド カルチャを使用することは、多くの場合、悪い考えです。「さまざまな形式を試して、いずれかが機能するかどうかを確認してください」。
特定のカルチャを使用した ParseExact は、より制御された正確なアプローチです。(現在の文化を指定したとしても、それが起こっていることを読者に明らかにします。)
于 2008-10-02T13:47:19.940 に答える
6
MSDN は次のように述べています。
Parse(String) メソッドは、現在のカルチャの書式設定規則を使用して日付と時刻の文字列表現を解析しようとするため、異なるカルチャ間で特定の文字列を解析しようとすると、失敗するか、異なる結果が返される可能性があります。特定の日付と時刻の形式が異なるロケール間で解析される場合は、DateTime.Parse(String, IFormatProvider) メソッドまたは ParseExact メソッドのオーバーロードの 1 つを使用して、形式指定子を指定します。
于 2008-10-02T13:47:36.757 に答える
3
その質問は、開発者がその問題を知っているかどうかを確認するためのものです。解析できない場合、Parse は例外をスローするため、最初に TryParse を使用する必要があります。また、ロケールは考慮されないため、Web シナリオでは、英国のユーザーが 02/10/2008 と入力し、サーバーが en-US ロケールを使用している場合、2008 年 10 月 2 日ではなく 2008 年 2 月 10 日になります。
他にも問題があるかもしれませんが、最初に頭に浮かんだのはこれらの2つです。
于 2008-10-02T13:49:39.513 に答える
1
不明なユーザー入力に加えて、環境が不明である可能性があるため、入力形式を制御しても、解析が期待するものは異なる可能性があると思います..
于 2008-10-02T13:48:22.153 に答える
1
私の直感的な反応は、あなたが未知のフォーマット/起源でヒットしたということになるでしょう. 他にも理由があるかもしれません。たとえば、その 1 行から、それが文字列であることがわかりmyStringますか? （もちろんそうだと思います。）
通常は、代わりに TryParse メソッドをお勧めします。少し冗長ですが、無効な入力の場合にコードが適切に動作する限り、例外を防ぐのに役立ちます。
もちろん、これに対するあなたの言い回しに基づいて...私はあなたがすでにそれをすべて知っていたと思います. :)
于 2008-10-02T13:49:42.510 に答える
0
答えは、DateTime.Parse（myString）を囲むコードと解析の要件によって異なります。
文字列が正規表現に基づいた有効な形式であることをすでに確認している可能性があり、文化情報に興味がない可能性があります。また、データが既知の日付規則を持つ既知のファイル形式からのものであることを知っているかもしれません。そのため、例外をスローすることがまさに望ましいことかもしれません。
文脈がなければ、質問は非常に曖昧であり、それに対する本当の答えは、「コードが何が間違っているかについて、コードが使用されている文脈に依存します。
于 2011-11-01T10:52:54.443 に答える
0
このブログ投稿で説明していますが、一般的なことは、解析に関連付けられた cultureinfo がないことです。
于 2008-10-02T13:47:00.613 に答える