MYSQL バイナリデータ変換取得

Question

以下のようなbatでunhex(`idm`)を使って変換しているのですが、出力されるデータが他のところも変換されて出力されます。どうしてでしょうか？
characterの設定か、SQLがだめなのでしょうか？

ECHO OFF
SET MYSQLPATH="C:\Program Files\MySQL\MySQL Server 5.0\bin"
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
exit

utakataXEX · Accepted Answer

#1 です。

はい、補足で書かれたような事をやりたいのだろうと言うのはわかります。

では逆に聞きますが、移す先のDBではIDmはバイナリで格納するのですか？

もしそうなら、その理由は？

前の回答のとおり、DB上は16進変換したASCIIの16桁で持っているべきなので「unhexせず」、そのまま varchar → varchar で何の問題もないと思います。

仮に何らかの理由でバイナリにする必要があったとしても、これも前の回答のとおり「CSVにはバイナリ値を入れられない」（厳密には「エディタ以外では予期せぬエラーが起こる可能性がある」）ので、ご質問の回答としては

「CSV上は文字列のままやり取りして、移行先でDBにインポートする時に初めてバイナリーに変換」

です。

しつこく言いますが、もし私が顧客なら、

「CSVにバイナリを格納する事の妥当性と安全性の担保」
「FeliCaアクセス時以外でIDmをバイナリで取り回す事の妥当性」

の確たる説明がなければ、検収印は押せません。

utakataXEX · Answer

別カテで回答した者です。

また何点か指摘させていただきます。

＞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をインポートする他のアプリケーションで開けるかもしれないし、開けなくなるかもしれない。

そんなものを業務データとしてやり取りできると思いますか？

もし上司がそうしろ、と言っているなら、ここの回答を見せた方がいいですｗ
お客がそうしろ、と言っていても同じ事です。

では、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に格納してしまっている以上、メリットと言えるほどではないですね。

MYSQL バイナリデータ変換取得

#1 です。

別カテで回答した者です。

この回答への補足

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング