7

I'm encoding a query parameter using GWT's com.google.gwt.http.client.URL.encode() method, but have found I can't use URL.decode() on the server to decode it because the implementation isn't available (I suspect it uses the javascript client side implementation). I get...

java.lang.UnsatisfiedLinkError: com.google.gwt.http.client.URL.decodeImpl(Ljava/lang/String;)Ljava/lang/String;

Can someone suggest what I'm supposed to use server side to decode the encoded string?

Alex Worden
  • 3,374
  • 6
  • 34
  • 34
  • I have the same problem - a class that I wrote decodes parameters as part of its functionality, and I've stored the parameters in my database. Later, on server side, I'm trying to create an object extracted from these parameters - which works perfectly client side. I'd prefer to avoid re-writing the class that's already working perfectly... Still seeking an answer. – Kieveli Jun 13 '12 at 14:28

3 Answers3

9

I solved my problem this way: on the client side, I encode the parameters using com.google.gwt.http.client.URL.encodeQueryString(), like:

URL.encodeQueryString(param)

On the server side, I get the parameters using the ServletRequest methods, like:

String myParam = req.getParameter("myparam");

PS I initially +1'd Riley Lark's answer, but then I got some problems with some characters too... Letting the ServletRequest do the job will handle all character's encoding for you. See Decoding international chars in AppEngine

Community
  • 1
  • 1
Ena
  • 3,481
  • 36
  • 34
3

java.net.URLDecoder is implemented on AppEngine and works perfectly with com.google.gwt.http.client.URL.encode().

Joseph Lust
  • 19,340
  • 7
  • 85
  • 83
Riley Lark
  • 20,660
  • 15
  • 80
  • 128
  • 1
    com.google.gwt.http.client.URL.encode() doesn't work correctly. I know for a fact that it doesn't encode a percent symbol. I have no faith that it works in conjunction with the unrelated java.net.URLDecoder so I'm using some home-baked common encode / decode functionality available on both the client and server. – Alex Worden May 25 '11 at 23:54
  • You asked what you could use with URL.encode(), and URLDecoder is the answer. I think you should accept this answer as the most straight-forward. As an aside, URL.encode() is implemented with the browser's javascript implementation of encodeURI, and at least in my tests in Chrome and Firefox the `%` character is encoded to `%25`. – Riley Lark May 26 '11 at 01:31
  • Sorry - your solution did not work for me. The two implementations are not compatible in my tests. – Alex Worden Jun 01 '11 at 21:07
-1

If you're not willing to use gwt-rpc you can encode/decode with Base64. Check this link for a gwt implementation of the Base64 encoder/decoder. Then all you have to do is Base64.encode(yourParameterValue) before sending the request to the server and Base64.decode(request.getParameter(yourParameterName)) on the backend right after receiving the request.

cheers!

Lucas de Oliveira
  • 1,642
  • 11
  • 16
  • Hi, It's not that I'm not willing to use gwt-rpc. Of course I'm using that everywhere in my app. In this case I've written some functionality that allows a user to request a file from the server which is delivered as an appropriate mime type etc... I need to pass query parameters in the request. Thanks for the Base64 encoder tip! We ended up writing our own common encode / decode functionality since the GWT encode doesn't work correctly (it doesn't encode a percent symbol!) and there's no guarantee it works correctly with the java URLDecode equivalent (mute point since it's broken anyway!) – Alex Worden May 25 '11 at 23:52
  • Not sure if it's a good idea to develop your own [de]coder as Base64 it's in agreement with many RFC's (in fact it's defined on the RFC 4648 - http://en.wikipedia.org/wiki/Base64#RFC_4648) but unfortunately is not implemented in GWT (not in 2.0.3 AFAIK). We've been using the Base64 [de]coder in all requests that are not gwt-rpc and they're working flawlessly so far. – Lucas de Oliveira May 26 '11 at 12:36
  • It's a safer bet to write your own that to attempt to mix'n'match two completely different implementations! :) – Alex Worden Jun 01 '11 at 21:00