none
2バイト文字列の分割について RRS feed

  • 質問

  • お世話になります。

    2つのサーバにそれぞれSQL Server 2005 Standard Editionがインストールされているのですが、
    ストアドで2バイト文字列の分割を行った際、1つのサーバで文字化けが発生します。

    文字化け自体はストアドの修正(DATALENGTH、LEFT、LENを使用)をおこない
    回避できるようになったのですが、原因の説明を求められています。
    ご存知の方がいらっしゃいましたら、ご教授ください。


    SQL Serverのバージョン
    文字化けしないサーバ:Aサーバ:9.00.3042.00
    文字化けするサーバ  :Bサーバ:9.00.1399.06


    ソースの概要
    Declare @wkStr1      As Varchar(200)
    Declare @wkStr2      As Varchar(200)

    @wkstr1にカーソルで varchar(100)の項目を代入
    Fetch Next From ex_cur Into @wkStr1 

    Set @wkStr2 = @wkStr2 + CONVERT(VARCHAR(30), @wkStr1) + ':'


    Aサーバは30バイト目が2バイト文字列の場合、29バイトまでで分割されますが
    Bサーバは後ろの':'とあわさり文字化けします。

    例:ここでは30バイト目ではなく9バイト目で分割
    CONVERT(VARCHAR(9), 'あいうえお') + ':'
    →Aサーバ「あいうえ:」
    →Bサーバ「あいうえ・」


    サーバ、データベース、テーブル、項目の言語系と思われるプロパティは
    すべて同じ設定で日本語になっています。

    よろしくお願いします。

    2009年10月20日 10:34

回答

  • こんにちは、nagino です。

    暗黙のキャストが発生しているのかもしれません。
    それぞれのサーバーで文字列を連結する直前で、それぞれ VARBINARY に変換した場合に差異がありますでしょうか。

    SELECT CONVERT(VARBINARY, @wkStr2)
    SELECT CONVERT(VARBINARY, CONVERT(VARCHAR(30), @wkStr1))

    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク 菊地俊介 2009年11月10日 2:02
    2009年10月20日 23:27
  • SP2 にて、CONVERT 関数の動作を変更していたような気がします。
    そのため、SP2 にて問題の現象が改善したのだと思います。
    自分の環境では試していないのですが、SP1ではこの現象が再現すると思います。

    • 回答としてマーク 菊地俊介 2009年11月10日 2:02
    2009年10月22日 13:02
  • 「SELECT CONVERT(VARBINARY, CONVERT(VARCHAR(30), @wkStr1))」
    が「値は両方のサーバで同じでした。」ということは
    「CONVERT(VARCHAR」の仕様変更ではなく、表示時の問題でしょうか。

    そもそも論になってしまいますが、マルチバイト文字を nvarchar でなく
    varchar で扱うことに問題があることはMSDNライブラリで教えてくれていますね。(→下記サイト)

    (回避策はとられたようですが、サロゲートが問題無いかちょっと心配だったり。。)

    char および varchar (Transact-SQL)
    http://msdn.microsoft.com/ja-jp/library/ms176089.aspx
    (抜粋)
    サイトで複数の言語をサポートする場合は、文字変換から生じる問題を最小限にするために、Unicode の nchar 型または nvarchar 型を使用することを検討してください。char 型または varchar 型を使用する場合は、次のように使い分けます。

    • 編集済み anningo 2009年10月22日 1:20 改行修正
    • 回答としてマーク 菊地俊介 2009年11月10日 2:02
    2009年10月22日 1:19

すべての返信

  • こんにちは、nagino です。

    暗黙のキャストが発生しているのかもしれません。
    それぞれのサーバーで文字列を連結する直前で、それぞれ VARBINARY に変換した場合に差異がありますでしょうか。

    SELECT CONVERT(VARBINARY, @wkStr2)
    SELECT CONVERT(VARBINARY, CONVERT(VARCHAR(30), @wkStr1))

    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク 菊地俊介 2009年11月10日 2:02
    2009年10月20日 23:27
  • naginoさん

    返信ありがとうございます。

    文字化けしないサーバ、文字化けするサーバの両方で、
    VARBINARY に変換した値を取得したのですが、
    値は両方のサーバで同じでした。

    他にも調査した方がよいものがあれば、
    ご教授ください。

    よろしくお願いします。
    2009年10月22日 0:27
  • 「SELECT CONVERT(VARBINARY, CONVERT(VARCHAR(30), @wkStr1))」
    が「値は両方のサーバで同じでした。」ということは
    「CONVERT(VARCHAR」の仕様変更ではなく、表示時の問題でしょうか。

    そもそも論になってしまいますが、マルチバイト文字を nvarchar でなく
    varchar で扱うことに問題があることはMSDNライブラリで教えてくれていますね。(→下記サイト)

    (回避策はとられたようですが、サロゲートが問題無いかちょっと心配だったり。。)

    char および varchar (Transact-SQL)
    http://msdn.microsoft.com/ja-jp/library/ms176089.aspx
    (抜粋)
    サイトで複数の言語をサポートする場合は、文字変換から生じる問題を最小限にするために、Unicode の nchar 型または nvarchar 型を使用することを検討してください。char 型または varchar 型を使用する場合は、次のように使い分けます。

    • 編集済み anningo 2009年10月22日 1:20 改行修正
    • 回答としてマーク 菊地俊介 2009年11月10日 2:02
    2009年10月22日 1:19
  • SP2 にて、CONVERT 関数の動作を変更していたような気がします。
    そのため、SP2 にて問題の現象が改善したのだと思います。
    自分の環境では試していないのですが、SP1ではこの現象が再現すると思います。

    • 回答としてマーク 菊地俊介 2009年11月10日 2:02
    2009年10月22日 13:02
  • >あんにんごさん

      ご高配ありがとうございます。


    NOBTAさん

      ありがとうございます!
      さっそく周囲にテスト環境の構築を図ってみます。

     
    2009年10月23日 2:02
  • こんにちは。

    回答してくださった皆様、詳しい情報をありがとうございます。

    kako17さん、フォーラムのご利用ありがとうございます。
    その後いかがでしょうか?皆様のアドバイスで問題は解決しましたか?
    よろしければ結果を教えていただけるとありがたいです。

    また、勝手ながら有用な情報と思われる回答へ回答マークをつけさせていただきました。

    今後ともフォーラムをよろしくお願いします。
    それでは!
    2009年11月10日 2:06