I've stored an email address in a cookie, and I'm sending it to a jsp file on google appengine to be verified. The # is coming through as %40. I need to get it back to an #, and convert any other special chars that might have been encoded. Are there classes available through appengine that deal with this conversion?
Look at URLDecoder and URLEncoder:
http://download.oracle.com/javase/6/docs/api/java/net/URLDecoder.html
Looking at the JRE whitelist they are both fine to use.
Related
How to provide support for GB18030 character set? My service gives a 403 while connecting to Virtual Machines (via RDP) that have these characters in the VM name. I believe for this I need to set the requestURI encoding to support these special characters? How do I do that? Should these be converted to and from UTF-8/16 or is there some other wat this can be achieved?
URL:http://localhost:8080/admin/users/8VHlQMoMAeGAfwADT%2FtM2Q%3D%3D
When i try to hit the above URL using advanced rest client, i am getting 400:Bad Request.
I need special characters to be passed in URl path via URL encoding only. But %2F is not being accepted.How to enable jboss to accept encoded slash in url? kindly help.
First of all you have to know that JBoss by default is not allowing the escaped slashes in paths for security reasons.
However you can set the following system property to true
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH
I deployed an existing Maven project in my Tomcat Server on Windows7 environment. I'm using tomcat7 , spring-security-core 3.1.0 .
However, everytime I'm logging in my webapp, I received an error
java.lang.IllegalArgumentException: Non-hex character in input
The code is working perfectly fine in Linux environment. So I was thinking it's because I'm using windows7 in my local environment. When I look into the internet I saw that's it's a encoding issue between linux and windows.
I tried setting up
JAVA_TOOL_OPTIONS -Dfile.encoding=UTF8
but haven't succeeded. Please help me out. Thanks in advance!
Most likely, when you login, events happen is such order:
Spring selects an entity from DB by username.
Spring must check inputted password for match with stored encoded password.
To check for a match, Spring uses PasswordEncoder, which you have most likely configured.
Your password encoder expects that stored encoded password is a hexidecimal char sequence (previously encoded by this PasswordEncoder). Thus, it tries to decode CharSequence into byte[], but fails (source).
The solution is to persist users with previously encoded password, e.g. by BCryptPasswordEncoder.
Answer Alex Derkach is right for me!
In my case i have DB with straight store password(develop) looks like User=roor, psw=root.
So when i comment(delete) .passwordEncoder(new StandardPasswordEncoder("53c433t")); ! its work
!!But is wrong, password must be stored in encrypted form!!!
A possible reason for this is mixing password encoders. There're different implementations of PasswordEncoder. And, for example, if you use SymmetricPasswordEncoder for encoding and StandardPasswordEncoder for decoding you may get this exception.
I am using a java library (edtftpj) to FTP a file from a web app hosted of a tomcat server to an MVS system.
The FTP transfer mode is ASCII and transfer is done using FTP streams. The data from a String variable is stored into an MVS dataset.
The problem is all the ampersand characters get converted to & . I have tried various escape characters including \& , ^& and X'50' (hex value), but none of it helped.
Anyone has any idea how to escape the ampersands please?
Nothing in the FTP protocol would cause this encoding behavior.
Representing & as & is an XML based escaping representation. Other systems might use the same scheme, but as a standard, this is an XML standard encoding.
Something in the reading of the data and writing of the data thinks it should be escaping this information and is doing the encoding.
If anything on the MVS system is using Java it is probably communicating via SOAP with some other connector, which implies XML, which could be causing the escape sequence to be happening.
Either way, the FTP protocol itself part is not part of the problem, ASCII transfer should only encode things like line endings, & is already a valid ASCII character and would not be affected. It is the MVS system that is doing this escaping if anything.
Binary transfer is preferred in almost every case, since it doesn't do any interpretation or encoding of the raw bytes.
Using FTP in ASCII-mode to/from a MVS (z/OS) will always perform code page conversions (i.e ASCII <-> EBCDIC) for the data connection. Thus it's very important to setup the connection with the appropriate parameters depending on dataset type and page codes. Example:
site SBD=(IBM-037,ISO8859-1)
site TRAck
site RECfm=FB
site LRECL=80
site PRImary=5
site SECondary=5
site BLKsize=6233
site Directory=50
As alternative, use BINARY mode and manually perform the conversions with some of the standard tools or libraries on the receiving end.
Ref links:
1. Preset commands to tackle codepage problem.
2. Coverting ASCII to EBCDIC via FTP on MVS Host.
3. Transferring Files to and from MVS.
4. FTP code page conversion.
5. FTP File Transfer Protocol and Z/OS (pdf).
On the web site I am trying to help with, user can type in an URL in the browser, like following Chinese characters,
http://localhost:8080?a=测试
On server, we get
GET /a=%E6%B5%8B%E8%AF%95 HTTP/1.1
As you can see, it's UTF-8 encoded, then URL encoded. We can handle this correctly by setting encoding to UTF-8 in Tomcat.
However, sometimes we get Latin1 encoding on certain browsers,
http://localhost:8080?a=ß
turns into
GET /a=%DF HTTP/1.1
Is there anyway to handle this correctly in Tomcat? Looks like the server has to do some intelligent guessing. We don't expect to handle the Latin1 correctly 100% but anything is better than what we are doing now by assuming everything is UTF-8.
The server is Tomcat 5.5. The supported browsers are IE 6+, Firefox 2+ and Safari on iPhone.
Unfortunately, UTF-8 encoding is a "should" in the URI specification, which seems to assume that the origin server will generate all URLs in such a way that they will be meaningful to the destination server.
There are a couple of techniques that I would consider; all involve parsing the query string yourself (although you may know better than I whether setting the request encoding affects the query string to parameter mapping or just the body).
First, examine the query string for single "high-bytes": a valid UTF-8 sequence must have two or more bytes (the Wikipedia entry has a nice table of valid and invalid bytes).
Less reliable would be to look a the "Accept-Charset" header in the request. I don't think this header is required (haven't looked at the HTTP spec to verify), and I know that Firefox, at least, will send a whole list of acceptable values. Picking the first value in the list might work, or it might not.
Finally, have you done any analysis on the logs, to see if a particular user-agent will consistently use this encoding?