○SSL接続対応版について
MySQL Connector/ODBC(MyODBC)にSSL接続対応機能を付加する試みです．
postgresql の ODBC では以前より公式にサポートされている機能ですが，何故か MySQL Connector/ODBC ではなかなか公式の機能に組み込まれずファイアウォール 内外でのデータのやり取りを考えるMySQL サーバの構築の際に難儀していたの ですが，構成時のコスト的な問題やデータの扱いやすさなどを考えると こういうアプローチもありかなと思い手がけてみました．
実際には，同様の考えのパッチアプローチはMySQLフォーラムなどでも見つける ことが出来ますのでそれらを参考にしつつ，SSL関係の設定インターフェースなど に手を入れて，コンパイルしバイナリ化（実はこれが一番厄介と思われる．．） しています．
○MySQL Connector/ODBC SSL接続対応版のダウンロード
ノンセットアップ版(コマンドラインインストーラ版）のみ配布しています．
MySQL Connector/ODBC 3.51.15 SSL接続対応版(rev070525)
SHA256: 7e5af3ff0d97c5bd5be6d0fee44a97e5e730dabbfcf05af3e352891d14461e8c
※オリジナルの 3.51.18でSSL対応が完全に行なわれました．ありがたいことです．このため独自リリース必要性がなくなったためダウンロードは停止しました．ダウンロード停止だけで一応情報だけは残しておきます．多忙のため，詳細は後程．．
なお，GPLに基づきソースコードのパッチ部の公開を予定しています．
開発の都合上，まだソースコードが整備されていない状況のため，パッチが 綺麗に取れないのと一部手動のコンパイルを必要とする状態です．現在別案件に多大な時間が割かれており整備に必要なまとまった 時間が取れないためパッチコードが公開できる品質に達しておりません．まとまった時間がとれ次第そのあたりを整理して公開させていただきたいと思います．
○インストールについて
インストールなどの詳細はアーカイブ内の「README-SSL-J.TXT」をご確認ください． 基本的にオリジナルのノンセットアップ版を元にしていますのでSSL版の特記事項は ありません．
○変更履歴
rev070525:
MySQL Connector/ODBC 3.51.15ベース初版
rev070424:
varchar binary の文字列の文字化けの修正(一般非公開)
rev070418:
MySQL Connector/ODBC 3.51.14ベース初版(一般非公開)
rev070129:
MySQL Connector/ODBC 3.51.12ベース初版(一般非公開)
○よくある質問
現在ホームページ公開前の仲間内への試験公開の際にあった質問などから とくに記憶にあるものを掲示しています．
Q MySQL Connector/ODBC 3.51.14 以上では varchar binary のフィールドが化けてしまう ので，MySQL Connector/ODBC 3.51.12 版も作成してほしい．
この問題についてはSSL対応版では独自にクローズしています． 本質的な要因は MySQLサーバ側の問題となると思われます．
Q. SSL で繋がらない．
Windows 版 MySQL 5 のバイナリ配布にある mysql.exe は SSL接続をサポートしています．すくなくとも こちらの mysql.exe で 接続できる状況が必要です．mysql.exe で 接続して `\s' と入力することで 接続にSSLが使われているかを確認できます．まずこちらで SSL接続できる準備が出来る状況を準備してから ODBC側の問題かの切り分けを確認してください．
Q. クライアント証明書は絶対に用意しなければなりませんか？
MySQLのSSLライブラリの仕組み上必ず必要となります．Q 日本語が文字化けする．
オリジナルでもよくある質問のようですが，MySQL 4.1 以上では，漢字変換は サーバ側が行う方式になっております．よってクライアント側のキャラクタセットを サーバ側に渡すことで対応します．通常， Initial Statement(STMT) に"SET NAMES sjis" や "SET NAMES cp932"と指定して利用します．（下項に関連事項記載あり） なお，MySQL 4.0以下では，漢字変換がサーバでサポートされていないため，ujis なサーバの日本語データはこのMySQL Connector/ODBC では扱えません．ujis のサーバからの文字列 をODBCで漢字コード変換するタイプの古いバージョンのMyODBCがあったような気が しましたが，どういったものであったかは失念しました．
Q ujis のデータベース に `\'で格納されているのに MySQL Connector/ODBC 経由で見ると`\' が `＼'になってしまう．
これは MySQL サーバ側の漢字変換に関連した話であり，MySQL Connector/ODBC が直接関与しない問題ですが，私の理解している範囲では，MySQL では 異キャラクタコードの変換には ucs2 を経由します．ucs2 では，`＼'がないので MySQL では，入力の際に`＼'は `\' に変換します．こうなると，MySQL ではオリジナルがなんであったのか判らなくなるので，，MySQL Connector/ODBC からの接続で漢字コード変換が必要となる場合に `\' で出力するか`＼'で出力するかが問題となってきますが，MySQLでは `＼'で出力する仕様になっています． なお，この問題を解決するためには MySQL Connector/ODBC のInitial Statement(STMT)を `SET NAMES cp932'にすることでの回避方法が出ている場合がありますが，これだと 今度は `〜' などが化けます． これらの問題を完全に解決するには ujis なデータベースは捨てて eucjpms なデータベース へ移行し，MySQL Connector/ODBC のInitial Statement(STMT)は`SET NAMES cp932'と します．Q. ujis から eucjpms に移行したが `SET NAMES cp932' で， `〜'の文字化けが直らない．
よくあるケースとしては ujis 上でダンプしたファイルをそのまま eucjpms のデータベースに流し込んでいる場合が考えられます．MySQLでは，データベース以外にもテーブルやフィールド毎にキャラクタコードを設定できます．ダンプファイルなどには キャラクタセットが書き込まれているので，そのダンプファイルを戻すとデータベース自体が eucjpms になっていても テーブルやフィールドは ujis に戻ってしまい `〜'などが文字化けします．
例えばダンプファイル中のテーブル定義が
DROP TABLE IF EXISTS `address`;
CREATE TABLE `address` (
`owner` varchar(128) NOT NULL default '',
`nickname` varchar(16) NOT NULL default '',
`firstname` varchar(128) NOT NULL default '',
`lastname` varchar(128) NOT NULL default '',
`email` varchar(128) NOT NULL default '',
`label` varchar(255) default NULL,
PRIMARY KEY (`owner`,`nickname`),
KEY `firstname` (`firstname`,`lastname`)
) ENGINE=MyISAM DEFAULT CHARSET=ujis;の場合，DEFAULT CHARSET=ujis; の `ujis' を `eucjpms' に書き換えて戻す必要があります．
また，varchar binary フィールドなどでは
DROP TABLE IF EXISTS `test`;
CREATE TABLE `test` (
`n_state` int(11) NOT NULL,
`c_name` varchar(16) character set ujis collate ujis_bin default NULL,
`n_state_group` smallint(6) default NULL,
PRIMARY KEY (`n_state`)
) ENGINE=MyISAM DEFAULT CHARSET=ujis;となっており，DEFAULT CHARSET=ujis; の部分以外に，character set ujis collate ujis_bin を `character set eucjpms collate eucjpms_bin' と書き換えなおさないとやはり文字化けが発生します．
○お約束
o 本ソフトウェアの使用（またはそれを使用できなかったこと）により生じた派生的，付随的，または間接的な損害（営業上の利益の損失、業務の中断、営業情報の喪失などによる損害を含む）等について，一切責任を負いません。
o 本ソフトウェアが，どのような環境のもとでも正確に作動しうる旨の保証はしません．
以上．