こんにちは。

# 興味本位でソース追いかけただけで、
# myodbcもmysqlをsjis,cp932でも使ったことありません。
# utf8とeuc使うだけですが、それでも文字化けで悩むことは
# よくあるんですけど（苦笑

On Tue, 24 Apr 2007 13:21:19 +0900
"fujita" <t-fujita@xxxxxxxxxx> wrote:

> こんにちは。藤田です。
> 
> > MyODBC3.51.6／MyODBC3.51.9をインストールしてみたのですが
> > 残念なことに現象は変わりませんでした。
> そうでしたか・・・。
> 当方の環境がAccess97 or 2000 or 2003 で　sjis　なのでそこが
> 結果が違う原因でしょうか？
> 
> 
> ちなみに蛇足ですが以前に3.51.12のソースを少し調べたときにexecute.cの445行目
> 
>   case SQL_CHAR:
>   case SQL_VARCHAR:
>   case SQL_LONGVARCHAR:
>   case SQL_BINARY:
>   case SQL_VARBINARY:
>   case SQL_LONGVARBINARY:
>       {
>           to= add_to_buffer(net,to,"'",1);
>           to= mysql_odbc_escape_string(mysql,
>                                        to, (net->max_packet -
>                                             (ulong) (to - (char*) 
> net->buff)),
>                                        data, length,
>                                        (void*) net, extend_escape_buffer);
>           if ( to ) /* escape was ok */
>           {
>               to= add_to_buffer(net,to,"'",1);
>           }
>           return to;
>       }
> 
> が怪しいと思ったのですが・・・実力不足で判明しませんでした。
> 

# 余談ですが、SQL_*BINARY もエスケープするんですね。

mysql-connector-odbc-3.51.12-win-src.zip
MyODBC-3.51.09.tar.gz
（09は、公式で見つけることができなかったので、ネットから適当に
拾ってきました。svnにあるのかもだけど手抜きです）
で比較してみました。上記の部分は09、12共に同じコードでした。

mysql_odbc_escape_string がくさいのかなと探してみたのですが、
odbcのソースには含まれていませんでした。

ということで、mysql-5.1.17-beta.tar.gz を探してみると

----------------------------------------------------------------
char * STDCALL
mysql_odbc_escape_string(MYSQL *mysql,
			 char *to, ulong to_length,
			 const char *from, ulong from_length,
			 void *param,
			 char * (*extend_buffer)
			 (void *, char *, ulong *))
{
  char *to_end=to+to_length-5;
  const char *end;
#ifdef USE_MB
  my_bool use_mb_flag=use_mb(mysql->charset);
#endif

  for (end=from+from_length; from != end ; from++)
  {
    if (to >= to_end)
    {
      to_length = (ulong) (end-from)+512;	/* We want this much more */
      if (!(to=(*extend_buffer)(param, to, &to_length)))
	return to;
      to_end=to+to_length-5;
    }
#ifdef USE_MB
    {
      int l;
      if (use_mb_flag && (l = my_ismbchar(mysql->charset, from, end)))
      {
	while (l--)
	  *to++ = *from++;
	from--;
	continue;
      }
    }
#endif
    switch (*from) {
    case 0:				/* Must be escaped for 'mysql' */
      *to++= '\\';
      *to++= '0';
      break;
    case '\n':				/* Must be escaped for logs */
      *to++= '\\';
      *to++= 'n';
      break;
    case '\r':
      *to++= '\\';
      *to++= 'r';
      break;
    case '\\':
      *to++= '\\';
      *to++= '\\';
      break;
    case '\'':
      *to++= '\\';
      *to++= '\'';
      break;
    case '"':				/* Better safe than sorry */
      *to++= '\\';
      *to++= '"';
      break;
    case '\032':			/* This gives problems on Win32 */
      *to++= '\\';
      *to++= 'Z';
      break;
    default:
      *to++= *from;
    }
  }
  return to;
}
----------------------------------------------------------------
がありました。

期待する正常動作は、、、
"十"（0x8f5c）をマルチバイトと判断してcontinue（エスケープ処理をスキップ）

問題が発生しているのは、、、
マルチバイトと判断されず、\（5c）に反応して、
8f 5c → 8f 5c 5c → "十\"

ということでしょうか。

〜〜〜

mysql_odbc_escape_string がくさいと仮定すると・・・

myodbc本体に、mysql_odbc_escape_string は静的にリンク
されてるんですかね？
もっとも、静的にリンクされているからこそ

[mysql 13899] の

On Tue, 24 Apr 2007 20:58:23 +0900
"fujita" <t-fujita@xxxxxxxxxx> wrote:
> 藤田です。
> 
> すみません、もう少し引っ張らせて下さい。
> 私の環境でためしたところですが、
> 
> (Access97 or 2000 or 2003) + MyODBC 3.51.9 ではエラーにならず、
> (Access97 or 2000 or 2003) + MyODBC 3.51.12　以降ではエラーになります。
> 
> サーバーは全て同一で、クライアントPCのODBCを入れ替えただけで結果が
> 異なるのでAccessの問題とは言い切れないと思うのですがいかがでしょうか？

のように、myodbc＊だけ＊を変更した
だけで、問題が発生したりしなかったりするんでしょうけど。。。

# 最初の仮定があてずっぽなので、推測してもあれなんですが・・・

〜〜〜

ところで、素朴な疑問なのですが、

myodbcから（というか上位アプリのaccessなど含めてですが）は、
「SHOW VARIABLES LIKE 'char%';」
は実行できないのでしょうか？

誰が(access？odbc？)何をやっているかわからない状況のなか、
キャラクタセットが本当にcp932（というか期待値）になっているのかを
確認したほうがよさそうな気がするのですが。

# 「設定した」ではなく、
# 「設定した上で、実際に問い合わせして本当に期待値になっているか」
# 見た方がよいのでは？という話です。

あと、デバッグ用に myodbcd.dll なんていうのがあるようですね。
詳細ログ取れるようなので、何かヒントになるのかも。。。


ps.
妄想ですが、
SET NAMES binaly
しておいて、エスケープは自分でやってしまう。
・・・とか、ありなのかなぁ。いや、ないんだろうなぁ。
とかとか

-- 
goungoun <gounx2@xxxxxxxxxx>
http://goungoun.dip.jp/app/