Hi, Haresh,

Yes, using 'setBytes' method may be the best solution.
Blob data also includes 0x5C code.
and 'setBytes' method is for the Blob data.

 x955C(SJIS) -> '0x39353543' includes no 0x5C character.


regards

Osamu Shimono



> I looked into the various aspects of the problem and solutions.
>
> 1. what has been said about the '\' character in the responses is right.
> This is causing problem.
>
> So I tried/thought solutions suggested...
>
> a. use utf-8 instead of shift_jis
> not practical as there is lot of shift_jis data by now in database
>
> b. insert one more escape character before (or after) the 0x5c
> which will solve the problem with involves good amt of work in my code
>
> c. modify my.ini file to set 'default-character-set=sjis'
> My app will be hosted with commercial hosting service provider. hense i am
> not in control of it.
> and may not be able to do this.
>
>
> 2. This raises a question.
> Fine we can solve the problem for '\'
> Are there any other characters which MySQL would not like?
> Do I have to take care of any other character(s)?
>
> 3. I tried another solution. It seemed to work.
> I do not know how and why.
> here is what I did.
>
> Instead of doing following
>
> request.setCharacterEncoding ("Shift_JIS");
> String name = request.getParameter("name");
> String newName = insertSingleQuote(name); // insert single quote around
the
> string
> newName = replaceChar(newName, '\\', "\\\\");
> ....
> String sql = "insert into test_table values (" + newName + ")";
> statement.executeUpdate(sql);
>
> I DID FOLLOWING
>
> //request.setCharacterEncoding ("Shift_JIS"); // do not need this now.
> String name = request.getParameter("name");
> byte [] arrShift_JIS = name.getBytes("Shift_JIS"); // instead of using
> utf-8 string into the sql query directly use the byte array in shift_jis
> form
> PreparedStatement preparedStatement = connection.prepareStatement("insert
> into test_table values (?)");
> preparedStatement.setBytes(1, arrShift_JIS);
> preparedStatement.executeUpdate();
>
>
> Now this seems to solve the problem (possibly the JDBC
driver/implementation
> will do appropriate escaping....)
> So my question to u guys is ...
> a. why does this work?
> b. is this a right solution? and
> c. will it take care of all the problematic characters?
>
> regards,
> Haresh Gujarathi