4

ネットワーク経由でデータをパケット化するためのカスタム逆シリアル化システムを作成しており、次の方法で double をシリアル化しています。

private static string EncodeDouble(double raw)
{
    long value = BitConverter.DoubleToInt64Bits(raw);
    return EncodeInteger(value);
}

このEncodeInteger関数は単に整数をタグ付き文字列に変換するだけなので、逆シリアル化コードは正しいデータ型を取得したことを認識します。

反対側では、次のようにデシリアライズしています。

private static double DecodeDouble(string raw)
{
    long value = DecodeInteger<long>(raw);
    return BitConverter.Int64BitsToDouble(value);
}

繰り返しDecodeIntegerますが、タグを削除し、値が long の範囲内にあることを確認してから、long にキャストします。何か問題が発生した場合、例外がスローされるだけなので、これは安全です。

私の懸念の理由は、参照ソースに足を踏み入れた後、この直接の安全でないキャストが表示されることです。

public static unsafe double Int64BitsToDouble(long value) {
    return *((double *)&value);
}

私が予見する問題は、long の値がネットワークを経由するため、任意に変更できることです。値が勝手に変更されることは気にしていませんが、無効な基になるdouble表現が送信された場合に CLR で問題が発生する可能性があります。

有効な にマッピングされない潜在的なlong値があるかどうかはわかりませんが、ある場合、何が表示される可能性がありますか? CLR がクラッシュして、サービス拒否状態が発生する可能性はありますか? または、キャッチできる例外はありますか?double

4

1 に答える 1

2

私の知る限り、ここには「無効な」値はありません。あなたが最初に考えていたものではない値だけです。したがって、サービス拒否に関して心配する必要はあまりありません。対照的に、無効なバイナリ表現を持つdecimal 可能性があることに注意してください-これらは例外をスローし、単一の呼び出しは失敗します-それでもサービス拒否ではありません(単に:失敗が表示されます)。

doubleただし、個人的には、 aを alongから a にエンコードすることstringは、おそらく難しい/非効率的な方法であるとアドバイスします。どうしても必要な場合はstring、代わりにビットを base-64 でエンコードすることを検討してください。

于 2013-09-07T13:23:07.677 に答える