โดย sirares » 11/04/2011 8:49 pm
แก้ปัญหาได้แล้วครับผม คำตอบนี้เลยครับ
If I were you, I'd stop trying to stuff a character field full of binary gibberish.
When you use pack you are taking the hex values from the string and converting them to the characters of that value.
For example: 20 gets converted to space, because space is hex 20. 7F gets converted to the DEL command char. Anything above 7F gets converted to extended ascii.
Not much of a problem if the field is only expecting any single byte values, but a big problem when you are trying to ram that through an application that actually understands UTF-8 and unicode. The reason is this: unicode, and UTF-8 are multibyte character encodings. With UTF-8, certain characters in extended ascii tell us to expect some amount of following bytes for this character. When those following bytes do not match valid UTF-8 values, the very best thing that can happen is that they are replaced by a ?. The worst is that the whole string will be rejected as invalid.
If you absolutely must store binary data in your database, choose a binary safe format for it. varbinary for instance. Failing that, do not try to dump it into a field that has some strict rules on the characters that can be used. Much better to turn the info hash into a 40 byte string made up of ascii characters that can be safely stored and easily searched in any text field with any encoding that supports 0-9 and a-f (most of them).
ตอนนี้ผมแก้ฟิลด์ที่เก็บอักขระแปลกๆให้เป็น varbinary ก็สามารถเก็บอักขระแปลกๆ โดยที่ set name utf8 ก็ยังเซทอยู่ด้วยครับ ได้ครบแล้วครับ ฐานข้อมูลเป็ยไทย และเก็บอักขระแปลกๆได้
ขอบคุณท่าน zend_framework มากๆครับผม ที่เข้ามาช่วยแก่ปัญหาครับ
แก้ปัญหาได้แล้วครับผม คำตอบนี้เลยครับ
If I were you, I'd stop trying to stuff a character field full of binary gibberish.
When you use pack you are taking the hex values from the string and converting them to the characters of that value.
For example: 20 gets converted to space, because space is hex 20. 7F gets converted to the DEL command char. Anything above 7F gets converted to extended ascii.
Not much of a problem if the field is only expecting any single byte values, but a big problem when you are trying to ram that through an application that actually understands UTF-8 and unicode. The reason is this: unicode, and UTF-8 are multibyte character encodings. With UTF-8, certain characters in extended ascii tell us to expect some amount of following bytes for this character. When those following bytes do not match valid UTF-8 values, the very best thing that can happen is that they are replaced by a ?. The worst is that the whole string will be rejected as invalid.
If you absolutely must store binary data in your database, choose a binary safe format for it. varbinary for instance. Failing that, do not try to dump it into a field that has some strict rules on the characters that can be used. Much better to turn the info hash into a 40 byte string made up of ascii characters that can be safely stored and easily searched in any text field with any encoding that supports 0-9 and a-f (most of them).
ตอนนี้ผมแก้ฟิลด์ที่เก็บอักขระแปลกๆให้เป็น varbinary ก็สามารถเก็บอักขระแปลกๆ โดยที่ set name utf8 ก็ยังเซทอยู่ด้วยครับ ได้ครบแล้วครับ ฐานข้อมูลเป็ยไทย และเก็บอักขระแปลกๆได้
ขอบคุณท่าน zend_framework มากๆครับผม ที่เข้ามาช่วยแก่ปัญหาครับ