none
xp_logeventの文字化けについて RRS feed

  • 質問

  • こんにちは、ログの表示の文字化けについて、聞きたいですが、

    お答えを出来れば、非常に助かります。

    現在、SQL Server 2012 sp1 を使用しています。日本語のログを表示したいのですが、以下のコマンドを実行してみましたが、SQ

    EXEC xp_logevent 60000, N'テスト'

    SQL serverログでは、ログメッセージが「???」という文字化けになります。

    おそらく、この問題を直面した方がいっらしゃいますが、以上の現象の原因と解消方法を教えて頂ければと思います。

    以上、よろしくお願いいたします。

    2015年11月2日 8:18

回答

  • SQL Server では、照合順序とコードページ(文字コード)の間に密接な関係があります。
    照合順序が決まると、そこ(カラムや文字データ等)のコードページが自動的に決まります。

    SQL_Latin1_General_CP1_CI_AS は非 Unicode のため、ストアドプロシージャの引数などで Unicode で受け渡ししたとしても、最終的にはコードページの変換が行われてしまいます。
    SQL_Latin1_General_CP1_CI_AS は確か Windows の ANSI (コードページ 1252)になるはずですので、日本語の文字は変換できる文字がなく、文字化けとなります。
    ※ Unicode 系の照合順序の場合で Unicode 文字データを扱う限りはコードページの変換が無いため、未対応文字でも格納自体は出来たりと、挙動が異なります。

    SQL_Latin1_General_CP1_CI_AS が必須要件ということであれば各種メッセージは英語やローマ字で記述するのが必須要件ということにもなります。

    なお、SQL_Latin1_General_CP1_CI_AS は SQL Server 6.5 までとの互換性の為に残されているだけの非常に古い照合順序ですので、理想論で言えばそこから見直し改修するのが好ましくはありますね。
    今の時代で非 Unicode の照合順序を使わないといけない理由はかなり限定されるケースに留まるかと思われます。


    MCITP(Database Developer/Database Administrator)

    • 回答としてマーク 星 睦美 2015年11月10日 8:22
    2015年11月5日 6:12

すべての返信

  • SQL serverログでは、ログメッセージが「???」という文字化けになります。

    との事ですが、このログメッセージはどこでどの様に確認されていますか?

    同様の手順を踏み、Windowsのアプリケーションログを確認しましたが正しかったです。

    また、インスタンスフォルダ内の「MSSQL\Log\ERRORLOG」ファイルも想定通り出力されておりました。

    2015年11月3日 1:45
  • aviator__さん

    お疲れ様です。ご回答ありがとうございます。Windowsのイベントログも見ました。WindowsのイベントログとSQL Serverログでは同じメッセージが表示されました。すみませんが、私のMicrosoftのアカウントは写真を挿入するのを失敗しましたので、ちょっとわかりづらいかもしれないです。

    さらに調べたところ、ポイントはSQL Server の照合順序にありそうです。

    今のSQL Serverのインスタンスの照合順序は「SQL_Latin1_General_CP1_CI_AS」、文字化けのログが表示されました。試しのため、「Japanese_CI_AS」を持つ別のインスタンスをインストールしてみると、文字化けがなくなりました。

    現在の案件では、「SQL_Latin1_General_CP1_CI_AS」の照合順序は必須のため、「SQL_Latin1_General_CP1_CI_AS」のままの照合順序で文字化けの問題を回避する方法をご存知ですしょうか


    2015年11月4日 0:53
  • 追加情報有難うございます。

    現在検証できる環境に無い為、カンでの追加検証の依頼になりますがご理解下さい。

    DECLARE @VALUE NVARCHAR(255) = N'テスト' COLLATE Japanese_CS_AS
    EXEC xp_logevent 60000, @VALUE
    みたいにやったらどうなりますでしょうか?
    2015年11月4日 5:13
  • aviator__さん

    追加での検証、ありがとうございます。

    実行してみましたが、残念ながら、まだ文字化けになっております。

    2015年11月5日 1:12
  • 「SQL_Latin1_General_CP1_CI_AS」の照合順序は必須とありますが、これはデータベースレベルの設定として必須なのでしょうか?
    例えばデータベースレベルは「Japanese_CI_AS」にして、テーブルレベル(カレムレベル)を全て「SQL_Latin1_General_CP1_CI_AS」にするといった形はNGでしょうか?

    それがNGだとすると、処理の前後で照合順序をALTER DATABASE文で書き換えるくらいしか思いつきません。
    ※その場合、余計な内容がLogにはかれるとは思いますが・・・

    お力になれずスミマセン
    2015年11月5日 1:58
  • SQL Server では、照合順序とコードページ(文字コード)の間に密接な関係があります。
    照合順序が決まると、そこ(カラムや文字データ等)のコードページが自動的に決まります。

    SQL_Latin1_General_CP1_CI_AS は非 Unicode のため、ストアドプロシージャの引数などで Unicode で受け渡ししたとしても、最終的にはコードページの変換が行われてしまいます。
    SQL_Latin1_General_CP1_CI_AS は確か Windows の ANSI (コードページ 1252)になるはずですので、日本語の文字は変換できる文字がなく、文字化けとなります。
    ※ Unicode 系の照合順序の場合で Unicode 文字データを扱う限りはコードページの変換が無いため、未対応文字でも格納自体は出来たりと、挙動が異なります。

    SQL_Latin1_General_CP1_CI_AS が必須要件ということであれば各種メッセージは英語やローマ字で記述するのが必須要件ということにもなります。

    なお、SQL_Latin1_General_CP1_CI_AS は SQL Server 6.5 までとの互換性の為に残されているだけの非常に古い照合順序ですので、理想論で言えばそこから見直し改修するのが好ましくはありますね。
    今の時代で非 Unicode の照合順序を使わないといけない理由はかなり限定されるケースに留まるかと思われます。


    MCITP(Database Developer/Database Administrator)

    • 回答としてマーク 星 睦美 2015年11月10日 8:22
    2015年11月5日 6:12
  • aviator__さん

    お返事、ありがとうございます。現在、使っているシステムのパッケージは少し古くて必ず、データベースレベル、テーブルレベルなどを「SQL_Latin1_General_CP1_CI_AS」の照合順序にしないといけないです。この問題に関しては、これで終わりたいと思います。事情を顧客に説明し、了承を得るようにします。いろいろ調査していただいて、ありがとうございます。

    2015年11月6日 9:02
  • naginoさん

    お返事、ありがとうございます。非常に参考になりました。照合順序を変えない限り、文字化けがなくならないようですね。現在のパッケージだと、SQL_Latin1_General_CP1_CI_ASの照合順序を使わないといけないですので、顧客に説明しかないですね。

    以上の教えて頂いた情報に基づいて、顧客に説明いたします。

    2015年11月6日 9:07