- ベストアンサー
MYSQLバイナリデータ変換取得とは?解説とトラブルシューティング方法
- MYSQLのバイナリデータ変換取得についてbatファイルを使用している場合、出力されるデータが他のところも変換されて出力されることがあります。この問題はcharacterの設定かSQLの問題かを確認する必要があります。
- batファイルでunhex関数を使用してバイナリデータの変換を行っていますが、出力されるデータが他の部分も変換されてしまう問題が発生しています。この問題の原因はcharacterの設定かSQLの問題かをチェックする必要があります。
- バイナリデータを変換して取得する際、batファイル内でunhex関数を使用していますが、出力されるデータが他の箇所も変換されてしまう問題が発生しています。この問題の原因はcharacterの設定かSQLの問題かを確認する必要があります。
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
#1 です。 はい、補足で書かれたような事をやりたいのだろうと言うのはわかります。 では逆に聞きますが、移す先のDBではIDmはバイナリで格納するのですか? もしそうなら、その理由は? 前の回答のとおり、DB上は16進変換したASCIIの16桁で持っているべきなので「unhexせず」、そのまま varchar → varchar で何の問題もないと思います。 仮に何らかの理由でバイナリにする必要があったとしても、これも前の回答のとおり「CSVにはバイナリ値を入れられない」(厳密には「エディタ以外では予期せぬエラーが起こる可能性がある」)ので、ご質問の回答としては 「CSV上は文字列のままやり取りして、移行先でDBにインポートする時に初めてバイナリーに変換」 です。 しつこく言いますが、もし私が顧客なら、 「CSVにバイナリを格納する事の妥当性と安全性の担保」 「FeliCaアクセス時以外でIDmをバイナリで取り回す事の妥当性」 の確たる説明がなければ、検収印は押せません。
その他の回答 (1)
- utakataXEX
- ベストアンサー率69% (711/1018)
別カテで回答した者です。 また何点か指摘させていただきます。 >SET character SET sjis;>create_sql.sql >ECHO select unhex(`idm`),a.emp_code,a.emp_name_kana from a,b where b.emp_code=a.emp_code into outfile "C:/master.csv" fields terminated by ',';>>create_sql.sql >%MYSQLPATH%\mysql.exe -u root -proot test<create_sql.sql idm が テーブル a または b に入っているカラムだとしたら、unhex(`idm`) ではなく unhex(idm) では? それと、他のカラムと同様にちゃんと修飾した方がいいですよ。 unhex(a.idm) とか unhex(b.idm) とか。 さて、ここからはシステムの根幹を揺るがす指摘ですが、今後ハマらないためにも心して聞いてください。 前のご質問と合わせて考えるとこの idm は Felica の IDm ですね。 varchar(16)に16桁のHEX表示の文字列が格納されていると思います。 unhexを通した結果はバイナリです。 マルチバイト漢字などをHEXにした文字列であれば、漢字の文字列になるだけなのでこれは問題ありません。 しかし、Felica の IDm はマジなバイナリです。(わかりますかね?) これをCSVに入れてはいけません。 テキストに入れた時点で、そのファイルはテキストファイルではなくなります。 たまたま読める文字列(emp_code や emp_name_kana)が入っているだけで、ファイルフォーマットとしてはバイナリファイルになります。 (まあ、バイナリを含んだテキストファイルとも言えるが) バイナリなので、データの途中に制御文字が偶然含まれていたとしたら、Excelで開けるかもしれないし、開けなくなるかもしれない。 CSVをインポートする他のアプリケーションで開けるかもしれないし、開けなくなるかもしれない。 そんなものを業務データとしてやり取りできると思いますか? もし上司がそうしろ、と言っているなら、ここの回答を見せた方がいいですw お客がそうしろ、と言っていても同じ事です。 では、IDm はどのようにして扱うのか? (全然MySQLと関係ない話になりますが皆さんお許しを) Felica から(C言語なりなんなりで)ポーリングして取り出した時点ではバイナリですが、その後は16桁のHEXの文字列にします。 DBなど他の領域にデータストアするなら、この状態が適切です。(バイナリのまま格納する事はしない) ここまでは既にできているわけですよね? では、DBから再度 IDm を抜き出す時にバイナリにするか、と言うと、そんな事はしません。 例えば、DBから取得した IDm と、Felica端末でポーリングした IDm を比較するような場合であっても、 (1) DBから取得したIDm(16桁HEX表示文字列) (2) Felicaからポーリング→16桁HEX表示文字列に変換 (3) (1)(2) を比較 自分がこれまで関わったFelica関連の開発で、これ以外の方法はありません。 IDm をバイナリとして扱うのは、Felicaチップにアクセスする時だけです。 他の局面でバイナリとして扱う事はデメリットこそあれ、メリットにはなりえません。 まあ強いて言えば、文字化け状態のバイナリになっていれば、よりセキュアではあります。 でも、DBに格納してしまっている以上、メリットと言えるほどではないですね。
お礼
utakataXEX さん ありがとうございます。
補足
DBに登録されている Felica の IDm は、ASCIIコードで格納されており、 同じく、emp_code や emp_name_kanaもASCIIコードで格納されています。 別のシステムにインポートするために、Felica の IDmのみ、バイナリーコードに変換して 一つにCSV形式に出力したものを別のシステムのDBにインポートしたいです。
お礼
utakataXEX さん ありがとうございます。