>Another alternative is to use the URLEncoder and URLDecoder classes. This
>takes all non alpha-numeric characters not including periods and changes
them
>into their HTML equivalent. This would convert any possible character or
>string that would cause a problem with databases such as escape characters
and
>such.
Beware that this might not be portable. Default (and only available)
encoding scheme until version 1.3 is on byte ASCII. In 1.4 beta 2, default
has been changed to UTF8. So, data encoded with version 1.3 would have to be
decoded in 1.4 specifying a non default scheme. However, such programs will
not work with version 1.3, which make the switch from 1.3 to 1.4 very
problematic. One possibility would be to test for Java version and act
accordingly. Such a program would only compile under 1.4 but should run in
1.3. Sun is aware of this problem, but put it in the "ease of use" category,
which makes me think it could really stay like this in final release. The
reason is obviously that such encoding is not intended for persistent data
and should not be used in that case. Once again, the secure solution is
prepared statements.
Pierre-Yves
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
