0

顧客プロジェクトの場合、DB に対してクエリが実行され、結果がファイルに書き込まれます。このファイルは、後で別のレガシー システムの入力として使用されるため、シフト JISである必要があります。ウィキペディアの記事は、次のことを示しています。

シングルバイト文字 0x00 から 0x7F は、それぞれ ASCII 文字セットのバックスラッシュとチルダの代わりに 0x5C の円記号 (U+00A5) と 0x7E のオーバーライン (U+203E) を除いて、ASCII エンコーディングと一致します。

いくつかのテスト中に、円記号 (U+00A5) が正しく 0x5C になる一方で、上線 (U+203E) が予想される 0x7E ではなく 0x3F (疑問符) になることを確認しました。

StreamWriter を使用してファイルに通常の出力を行っていますが、以下は再現するための最小限のコードです。

    static void Test()
    {
        // Get Shift-JIS encoder.
        var encoding = Encoding.GetEncoding("shift_jis");

        // Declare overline (U+203E).
        char c = (char) 0x203E;

        // Get bytes when encoded as Shift-JIS.
        var bytes = encoding.GetBytes(c.ToString());

        // Expected 0x7E, but the value returned is 0x3F.
    }

この動作は正しいですか? EncoderFallback をサブクラス化できると思いますが、これは、最初から動作すると予想していたものよりもはるかに多くの作業のように思えます。

4

1 に答える 1

1

さらに調査した結果、シフト JISは誤称であると結論付けなければなりません。むしろ、これはコードページ 932です。Unicode と Microsoft は、これと Unicode の間のマッピング テーブルを提供しています。これは明らかに、文字をマッピングするために使用されているものです。(0x5C, U+00A5) と (0x7E, U+203E) の間のマッピングが含まれていないことに注意してください。

元の質問に「円記号（U + 00A5）が正しく0x5Cになることを確認しました」と書いたことに注意してください。どうやら、Encoding.GetEncoding(String) メソッドは、System.Text.InternalDecoderBestFitFallback として定義された DecoderFallback を持つエンコーディングを返します。これは、通常は失敗する一部の文字に追加のマッピングを提供していると思います。円 (U+00A5) の追加のマッピングが含まれている必要がありますが、残念ながらオーバーライン (U+203E) のマッピングは含まれていません。これを EncoderExceptionFallback に置き換えると、迷惑な文字で失敗した場合。

したがって、シフト JIS の場合、これは誤りであると判断します。しかし、コードページ 932 の場合、これは予想される結果です。

于 2013-01-09T08:17:16.500 に答える