Unescaping Domino's @URLEncode Function
Recently I learnt some page encoding lessons, which are probably worth mentioning. I was working on a JavaScript news ticker and certain characters were causing problems. Namely the £ sign.
Using a special view I was supplying the ticker's JavaScript function with an array of news items. To prevent problems with the code I decided to encode the news titles in the Domino view itself and then Unescape() them in the JavaScript. This is where the problems began.
Here's a demo of the problem in a simple database you can download (includes a free ticker).
In the column formula I used @URLEncode("Domino"; Title) to create the encoded text. This view is then embedded on a Page. The Page stores JavaScript and a function on it unescapes the news title. The problem is that the page is sent to the browser without a specific character set, which means that browsers assume your default charset. Unless this happens to be UTF-8, which is what @URLEncode("Domino") uses, you'll get problems when code on that Page unescapes anything. The unescape method will use the charset of the page on which the encoded strings reside. You have to make sure the encoded strings are on a page with the same charset.
One solution would be to specify the charset of the Page as UTF-8. This isn't possible though, as, with Domino, you can't specify both a charset and a content-type of "other" for a Page both at once. Sounds like a bug to me. You can specify the charset when you chose content type HTML. Just not when you chose other.
The solution I ended up using was to change the column formula to use @URLEncode("ISO-8859-1"; Title) instead. This fixed the issue on this UK-based web application, but might not be the solution for a global site. In this case we really need to tell the browser what charset to use and a better solution is needed.
Anyway, I thought it was worth passing on. If you find yourself using @URLEncode() along with Unescape() you'll need to take character sets in to account.
This weekend I am going back to Scotland to ride the three Staines we didn't manage last time. Wish me luck.
Skip to the 
You can subscribe to an individual
I also think, it is a bug.
As you obviously use "json/x-javascript" as ContentType, you are making XmlHttpRequests, aren't you?
Don't know, if this will function properly, but give it a try:
Set ContentType to HTML in the page and call overrideMimeType() on the XHR object before sending it.
See
{Link}
for reference.
Ciao
Thomas
Hi Thomas. That would work for Ajax, but I'm just using content-type application/x-javascript and embedding the view on a Page called "ticker.js", so it wouldn't work for me.
As nice as escape() and unescape() are, Jake, I think you'll find that encodeURIComponent() and decodeURIComponent() are better matches for what you are trying to accomplish. encodeURIComponent() matches @URLEncode; you'd need to tag on a replace(/\+/g," ") to match @URLDecode("Domino",x) with decodeURIComponent.
Sometimes domino sends charset us-ascii when displaying certain design elements
(even if you have UTF-8 for output configured in the server doc/internet site).
I have noticed this behaviour for ?OpenPage and ?ReadForm but haven't done any further investigations about exactly why.
Stan. You're a genius.
Jake, what makes Stan's post even more incredible is if you read his blog and see where he's posting from. He's a great guy!
Agreed Richard. He never stops surprsing me, that man.
aha Jake I am happy you resume you're technical articles , if you need help installing on a fedora core 5 someday I might just help , I was happy to read about your DIY and plasterer housing and stuff , but I am thinking back about my domino career ( I got the lost job man you said we're lucky I was not).
I got diagnosed for something I don't know my manager told me , we don't have manager here , we don't design software , I got to stay home paid for sometimes then I got fired by a new guy they hired , they moved into business object and totally didn't give a chance to Domino.
The fuck, I got an offer to work in algeria but it's been a while I didn't design anything. I started do php with cbts.
The fuck with that I should have warned you before my last trip to england when you were doing the charity thing for the template , probably wouldn't have used it was .
My Question is :
Have you ever used the International function of Rnext err sorry I am old school now lol
R6. I didn't get the training or the doc. I am the worst domino admin ever :-/ couldn't setup antirelay on my linux server :-/
Well you're on my personalised google webpage
If you have some time have look at Ajax website 43things.com
hya sorry jake for bothering, do you think we will have an open beta for Hannover? Something I could get on with , I never touched eclipse. Did you?
sorry for advertising urls here :x
Jake
Just got back from a weekend at Glentress near Peebles. To go back 20 years - man that place rocks :-)
I might be the wrong side of 40 but even I had a play on the freeride course - the big box at the bottom IS rideable, I've got the video to prove it!
Hope you have a great time whichever of the 7 you ride.
Ian
Did anyone notice that www.notestips.com has been off-line for a while. Does anyone know why?
@ larry
Yes, but I've heard only rumors. I havn't seen or heard from Mike Golding in quite a while. Not sure if he's alive or dead at this point, or just retired. Or, maybe like Stan quietly recovering.
@ Jake
I expect you'll update Jake's Rides after the weekend? ;-)
Mike's still around -- his photo blog is still up to date:
{Link}
Notestips.com, though, has kind of fallen by the wayside. A matter of priorities, I guess -- it takes effort to keep updating a site, and photography has a much higher leisure-time priority level for Mike nowadays.
Ian. We were at Glentress Friday and Saturday (stayed in the motel at the entrance). I rode the box too! ;o) Most of the guys I was with are 40+ and led the pack most of the way!
Have you tried using "application/x-javascript; charset=UTF-8" as the content-type?
Hi Ketan. An inspired idea, but it doesn't work, sadly. Although it is sent to the browser, the browser doesn't act on it. I think Stan's approach is still best.
I've just had a play around with a page, some xml and various charset settings.
As far as I can tell, if you select a content-type of "other" then Jake you are correct, Domino does not sent the charset to the browser in the http header. Interesting to find that out. It does however alter how domino encodes the page. As Ketan suggested, if you put the charset after the content type it is sent to the browser, so you could have a mismatch between the charset specified and the actual encoding.
So you should always specify the charset correctly after the content type and in the charset select box. Also note that if you specify the charset in the an xml preamble then the browser will use that, but not in preference to any charset in the http header. So if you are spitting out xml and put a charset in the preamble you don't need to explicitly put it in the content type field, but you should match what you specify in the charset select box.
On to the subject of your original post Jake. The @urlencode will simply do a straight swap of the char specified to the hex code point or the target charset. (with % chars in front of each 2*hex byte.) Once that conversion has been done, domino will then encode it again along with everything else on the page into the target charset specified in the page properties and set it to the browser. The browser will then decode that using the charset specified, in the http header or the xml preamble or wherever it tries to work it out from. Only after that's been decoded will it get as far as being passed to any javascript decoding method you want to try. As Stan pointed out you were basically trying to decode a string using a method that didn't match your encoding method. Nothing really to do with the charsets used in sending it from domino to the browser and only related to the charsets in the encode/decode methods by accident. unescape() can accept %xx for ISO-8859-1 or %uxxxx for Unicode, so your workaround worked because you found a place where both the output from @urlencode matched the input for unescape().
This is all 20/20 hindsight with a little digging and playing by the way. Thanks for the leads from yourself Jake and Stan and Ketan. Just thought I'd put down my conclusions as I was still left asking questions at the end.
Final point of clarification. While it might be nice if Domino appended the correct charset to the end of the content type for you when you select content type other, Domino is not doing anything wrong and it does allow you to specify everything you need to. I'll leave it to IBM to claim that it's not a bug and is functioning as designed. I think I'd agree with them, as long as it was well documented so you knew what was going on. What you enter in that field is sent straight to the browser as the HTTP Content-type header. You tell Domino what charset to encode with using the select box. I can live with that.
Golly a 546 word reply. Too verbose?
Hello Guys,
This solution really halped me a lot.I was having problrms about displaying the £ sign on web.It was displaying it as #.So I used this @ function mentioned herre and then made an unescape for my javascript variable.It worked. @Text(@URLEncode("ISO-8859-1"; "£")).
Thanks a lot.
Those formulas tricks are quite good, but it doesn't work when it comes to manage long strings (> 2050 characters) ; you may experience a "Quoted string is too long" error.
The only way I found is to use a java script library using java.net.URLDecoder.decode("long string", "UTF-8") with Domino R7+, or org.apache.commons.codec.net.URLCodec with Domino R6.
More details in french here : {Link}