Mitsuru Marunoさんの<003101c090b3$abb02f50$6b01a8c0@maru>から
>INSERT INTO文でバイナリを16進表記文字列に変換して挿入できました。

一応、回避策が見つかったということで、
以下蛇足になるかもしれませんが・・・

サーバのソースを眺めてみると、エスケープ処理が含まれる関数では、
ほとんどが、
1. マルチバイト文字の処理
2. エスケープ処理
という順番になっていて、しかも 1. にマッチした場合は、
2. はスキップされています。

ということで、SJIS 版サーバで 0x88 0x5c という文字列は
マルチバイト文字の方にマッチしてしまい、エスケープを
取り除く処理がスキップされてしまうのだと思われます。

ただ、そうなると、php で addslashes() を使った場合も、
同じ現象になるはず・・・？

# 以下、さらに余談

Mitsuru Marunoさんの<005301c090a5$9562fd30$6b01a8c0@maru>から
>ソースを見てみましたが、libmysqlプロジェクトでは、やはり
>mysql_real_escape_string関数をエクスポートしていませんでした。
>また、mysql_real_escape_stringとmysql_escape_stringを見てみると
>両者ともmysql_sub_escape_string関数を呼び出しているだけので、
>内容的には全く同じ物ですね。。。

エクスポートされてなくても、static link で使えるのでは
ないでしょうか。
ドキュメントにも以下のように書かれてますし。
>> 22.1 MySQL C API
>>  C API コードは MySQL とともに配布されます。これは
>>  libmysqlclient ライブラリに含まれ、C プログラムから
>>  データベースへのアクセスを許します。 

それから、ソースにあるように、mysql_escape_string() とは違い、
mysql_real_escape_string() の処理は charset によって変化するので、
例えば、0x95 0x5c というバイナリを変換する場合、
SJIS の場合、マルチバイトとして扱われるので、そのまま -> 0x95 0x5c
EUC の場合は、エスケープ処理される -> 0x95 0x5c 0x5c
となるように思えます。
最終的には、INSERT して SELECT すると、
SJIS・・・ そのまま -> 0x95 0x5c
EUC ・・・ エスケープを取り除く -> 0x95 0x5c
となって、同じ結果ではありますが。

-- 
Toshihiro Fujimori (藤森 利浩)
Taisei Inc.
PGP Key ID: 0xBE1C7568 (DH/DSS)
http://www.rcc.or.jp/%7Efuji/