Develop Reference

Keeps getting gibberish in client side while trying to get value in hebrew

I made a java server which the client requests info and gets response from the server. I am using BufferedWriter in order to send info to the client, and the info is in hebrew. The problem is that the client just gets gibberish if the server sends hebrew to him. I already tried different encoding, like ISO-8859-8, UTF-8, Unicode and so on, but none of them helped. I made a check and in the server side, and the string in the server is fine, in hebrew and I also made it so save it to file in hebrew and it worked. I really don't know what to do.. I tried almost every solution here and nothing worked.

Don't use the BufferedWriter for it, I just tinkered a little bit and found out that if you want to write something with UTF-8 encoding (e.g some non-Latin characters) you could just use the DataOutputStream variable, which has the method writeUTF().
It goes like this:
DataOutputStream out = new DataOutputStream(socket.getOutputStream());
out.writeUTF(someString);
out.flush();

How can I accept JSON as string in Jersey

I am trying to maintain some logs of a couple of Javascript objects in my webapp. The easiest way to log them would be to stringify them and put them on a jersey path as a string.
My logger works fine with regular strings but gives Error 400: The request sent by the client was syntactically incorrect when I pass a JSON stringified object. There are two things that I can't explain and are going wrong with my code:
Everything seems to be working fine on my development server but not on the server where I am deploying it. I develop on a Mac / Homebrew / Tomcat enviroment and deploy on a CentOS server.
Even on the CentOS server, logging works fine when I pass a simple one word strings as message but passing a JSON string throws up the error.
My Logger code looks like this:
#PUT
#Path("logEvent/{fn_event}/{fn_message}")
public void logEvent(#PathParam("fn_event") String event,
#PathParam("fn_message") String message)
throws Exception {
:
:
:
}
I have tried investigating catalina logs but it doesn't tell anything. Access logs give no more information than specifying "Error 400".

This may happen if you don't escape quotes in your JSON string. Try to escape it with \"

Json String may be having "Spaces" etc etc.
So when you call http://yourserver/logEvent/oneword/onewordMessage it may work fine but when you call http://yourserver/logEvent/oneword with space and with & and so many things/or one message with " and not " etc
Then in second case, your path may be incorrectly encoded. Form Encode your json stream, and then pass it as path.
Better move to Post, and pass the stream as Body of Request. Not sure why you will prefer using "entire" json file as path of your service

jetty ,websockets and UTF8 encoding

I'm having a little problem. I'm building a small server in java, based on jetty websockets implementations.
The clients are the browsers and I send information using the websockets javascript api.
Everything works great until I send those special characters such as : ă Ț î ș ê ñ ü
So here is the problem. Client 1 sends a message to the server with one of this characters. Server prints the message and then send the message to client 2.
Client 2 receives the message and prints the message on a browser html page and works great The characters are showed correctly.
The problem is when I wanna print the String on the server site. Instead of ă is shows me the ? char. This is causing me problems because I want to insert the text in a database(mysql- with ut8 encoding enabled)
So.. what seems to be problem. The text that is send from the browser is not UT8 encoded? or the jetty websocket implementation is not receiving String in utf8 encoding??
Thanks

Here's a function I use to HTML-encode all special characters in a string (but not html itself (like < or >)). If you apply it before sending a string to the server, everybody should see the same and you can store it in a database table:
function toHtmlEncoded(string){
return string.replace(/[\u0080-\uC350]/g,
function(a) {return '&#'+a.charCodeAt(0)+';';}
);
}

First read this http://kunststube.net/encoding/
Then check everywhere you've converted bytes into Strings (or the reverse). Common places to make a mistake include calling getBytes() on a String without specifying an encoding. Other pitfalls include not setting the encoding in the database connection string.

Server side fix for receiving string containing '&'(ampersand)

We have already shipped a client (.NET WinForms) application which sends customer data to Java server. While most of the data sent by client are accepted at server side, some records are truncated because of the presence of & character in it, as client sends raw & and do not URL encode it, we have fixed it by using the below code:
string dataBefore="A & B";
string dataBefore = System.Web.HttpUtility.UrlEncode(dataBefore);
It is impossible for us to update all the client applications(which are already shipped) and we are thinking of a server side fix.
With the help of Fiddler, we have made sure the data has left client in full, but when server reads as below:
//in java
String dataReceied=request.getParameter("data");
it gets truncated if data contains &
Could someone help us suggesting a server side(java) fix for this? Is it possible to access the request stream in java(instead of request.getParameter())?

You can get access to the raw query string using HttpServletRequest.getQueryString() (javadoc), which:
returns a String containing the query string or null if the URL contains no query string. The value is not decoded by the container.
You can them perform manual decoding on that string, instead of using getParameter().
#Wesley's idea of using getParameterMap() may not be useful, because you don't know which order the parameters were supplied in.
I'd suggest implementing this logic as a servlet filter, to decouple the fixing of the broken parameters from your actual servlet logic. This would involve writing a custom subclass of HttpServletRequestWrapper which overrides getParameter() and manuyally decodes the query string. Your servlet would then be able to use the HttpServletrequest API as though everything was tickety boo.

It is cut off because & signifies a new URL parameter in a request like this:
google.com?query=java&page=2. Java converts all these parameters to a Map, so that's where it goes wrong.
Have you tried iterating through request.getParameterMap()? The remaining data is most likely in the name of the next parameter. If that does not work, check out the API of HTTPServletRequest to see if there is another way to get your data.
Good luck!
PS How angry are you guys at the intern that wrote & shipped that client? That sounds messed up!

java.io.IOException: Server returns HTTP response code 505

I have HTML based queries in my code and one specific kind seems to give rise to IOExceptions upon receiving 505 response from the server. I have looked up the 505 response along with other people who seemed to have similar problems. Apparently 505 stands for HTTP version mismatch, but when I copy the same query URL to any browser (tried firefox, seamonkey and Opera) there seems to be no problem. One of the posts I read suggested that the browsers might automatically handle the version mismatch problem..
I have tried to dig in deeper by using the nice developer tool that comes with Opera, and it looks like there is no mismatch in versions (I believe Java uses HTTP 1.1) and a nice 200 OK response is received. Why do I experience problems when the same query goes through my Java code?
private InputStream openURL(String urlName) throws IOException{
URL url = new URL(urlName);
URLConnection urlConnection = url.openConnection();
return urlConnection.getInputStream();
}
sample link: http://www.uniprot.org/uniprot/?query=mnemonic%3aNUGM_HUMAN&format=tab&columns=id,entry%20name,reviewed,organism,length

There has been some issues in Tomcat with URLs containing space in it. To fix the problem, you need to encode your url with URLEncoder.
Example (notice the space):
String url="http://example.org/test test2/index.html";
String encodedURL=java.net.URLEncoder.encode(url,"UTF-8");
System.out.println(encodedURL); //outputs http%3A%2F%2Fexample.org%2Ftest+test2%2Findex.html

AS a developer at www.uniprot.org I have the advantage of being able to look in the request logs. In the last year according to the logs we have not send a 505 response code. In any case our servers do understand http 1 requests as well as the default http1.1 (though you might not get the results that you expect).
That makes me suspect there was either some kind of data corruption on the way. Or you where affected by a hardware failure (lately we have had some trouble with a switch and a whole datacentre ;). In any case if you ever have questions or problems with uniprot.org please contact help#uniprot.org then we can see if we can help/fix the problem.
Your code snippet seems normal and should work.
Regards,
Jerven Bolleman

Are you behind a proxy? This code works for me and prints out the same text I see through a browser.
final URL url = new URL("http://www.uniprot.org/uniprot/?query=mnemonic%3aNUGM_HUMAN&format=tab&columns=id,entry%20name,reviewed,organism,length");
final URLConnection conn = url.openConnection();
final InputStream is = conn.getInputStream();
System.out.println(IOUtils.toString(is));
conn is an instance of HttpURLConnection

from the API documentation for the URL class:
The URL class does not itself encode or decode any URL components
[...]. It is the responsibility of the caller to encode any fields,
which need to be escaped prior to calling URL, and also to decode any
escaped fields, that are returned from URL.
so if you have any spaces in your url-str encode it before calling new URL(url-str)

#posdef I was having same HTTP error code 505 problem. When I pasted URL that I was using in Java code in Firefox, Chrome it worked. But through code was giving IOException. But at last I came to know that in url string there were brackets '(' and ')', by removing them it worked so it seems I needed URLEncodeing same like browsers.