2016-06-15 7 views
0

utf8_general_ci照合を使用して、VARCHAR(100)列のMySQLテーブルがあります。どのようにしてVARCHAR列に任意のバイナリデータを挿入できますか?

この列には任意のバイトシーケンス(無効なUTF8文字シーケンスを含むデータ)が含まれている行が表示されますが、このタイプのデータを入力できるようにするUPDATEまたはINSERT文の記述方法はわかりません。

例えば、私は次のことを試してみた:

UPDATE DataTable SET Data = CAST(BINARY(X'16d7a4fca7442dda3ad93c9a726597e4') AS CHAR(100)) WHERE Id = 1; 

しかし、私はエラーを取得する:

Incorrect string value: '\xFC\xA7D-\xDA:...' for column 'Data' at row 1 

は、どのように私は先の列の照合をバイパスするINSERTまたはUPDATE文を書くことができ、私は任意のバイトシーケンスを挿入することができますか?

+1

[すべてのソフトウェア開発者の絶対的な最小値、絶対にUnicodeと文字セットについて知っておく必要があります(言い訳はありません))www.joelonsoftware.com/articles/ Unicode.html](http://www.joelonsoftware.com/articles/Unicode.html)と[テキストを扱うエンコーディングと文字セットについて熟知しているすべてのプログラマーが絶対に必要とするものkunststube.net/encoding/](http ://kunststube.net/encoding/) – spencer7593

+0

文字エンコードの仕組みを知っています。 MySQLがINSERTやUPDATEでエンコーディングを無視する方法を理解できません。 –

+0

どのような種類のデータを扱っていますか?照合を拡張utf8に変更しようとしましたか? (utf8mb4_general_ci)。 –

答えて

0

varcharの代わりにBlobデータ型のいずれかを使用することを検討しましたか?私はthis'dあなたのユースケースから離れて苦痛の多くを取ることを信じる。

EDIT:あるいは、HEX and UNHEXの機能があります。これはMySQLがサポートしています。 Hexは、strまたは数値の引数を取り、引数の16進表現を文字列として返します。 Unhexはその逆を行います。 16進文字列を取り出してバイナリ文字列を返します。

+0

これはオプションではありません。この表はすでに存在し、使用頻度が高いです。私はちょうどデータがそこにいかにあるか把握できません。 –

+1

Encode Base64は、varchar(max)に入る文字列を生成します。 –

+0

@ JohnCappelletti:Base64でエンコードされた文字列を列に取得する方法は問いません。 –

-2

あなたはbase64では、そう、あなたはそれで有効なSQLを生成することができ、あらかじめご値をエンコードする必要があります。

UPDATE DataTable SET Data = from_base64('mybase64-encoded-representation-of-my-value') WHERE Id = 1; 
0

短い答えは、宣言VARCHARカラムに無効なUTF8文字で値を挿入することは可能であってはならないということですUTF8キャラクタセットを使用する。

これは、無効な値を無効にするためのMySQLの設計目標です。これを行う試みがあると、MySQLはエラーまたは警告を返すか、遭遇した最初の無効な文字で指定された値を自動的に切り捨てます(もっと緩やかに)。

文字セットの変換が不要な場合にMySQLが文字セット変換を実行することにより、より多くの通常の文字セットの問題が発生します。

しかし、あなたが報告している問題は、無効な文字がUTF8列に挿入されたことです。これは、latin1(ISO-8859)エンコーディングが提供され、キャラクタセットの変換が必要でしたが、ではなく、でした。

私は以前のバージョンのMySQLでは可能だったと思います。私は、BINARYに値をキャストしてからCONVERT(... USING UTF8)にワープすることができ、MySQLは文字セットの検証を実行しないと考えています。現在のMySQL Connectorでこれが可能かどうかは分かりません。

可能であれば、それは(IMO)コネクタのバグです。

文字セットチェック/検証を回避するには、MySQLサーバーにクライアントを信頼させ、文字セットのチェックが不要であることを確認するしかありません。 (これは、MySQLサーバが文字セット変換を行わないことを意味します。クライアントはサーバに横たわり、クライアントは有効なUTF8文字を供給していることをサーバに伝えます。

基本的に、クライアントはサーバーに「こんにちはサーバー、私はUTF8文字エンコーディングを送信するつもりです」と伝えます。

そして、サーバーは「わかりました。私たちは一致して以来、どんな文字セット変換もしません。あなたが送るものは有効なUTF8だと信じています。

そして、クライアントはいたずらに自分自身に笑い声を上げます。 "Heh、heh、私は嘘をつきました。実際には有効なUTF8ではない文字エンコーディングを送信しています。

古い学校のMySQL C API(mysql_stmt_preparemysql_stmt_execute)で準備されたステートメントを使用して、文字列バインドパラメータの値として無効なUTF8エンコーディングを提供する可能性が非常に高いと思います。

関連する問題