@URLEncode - Different behaviour in R6 and R7

HCL Domino Domino Forum
1

@URLEncode appears to be giving different results on R6 and R7 servers.

I’m running the code below as part of a WebQuerySave agent. The agent converts the contents of the ‘test’ field (editable on the browser, a RichText field on the form) to an encoded version of the text (stored in a new field - ‘encodedVersion’). The code executes correctly, but the contents are different on different servers. On R6, line breaks are encoded by %20%20, on R7 by %20%00. This causes problems when unescaping in JavaScript - it appears unable to decode %00.

Whilst a workaround is possible, can anyone tell me if this is a configuration problem or an actual bug?

The code (syntax, etc is OK - just the result differs):

strStatement={@URLEncode(“Domino”;“} & doc.test & {”)}

vntResult=evaluate(strStatement)

doc.encodedVersion=vntResult

2

Subject: RE: @URLEncode - Different behaviour in R6 and R7

It seems to me that the behavior in 7 is closer to correct, since it at least lets you tell the difference between a newline and two spaces. If you don’t like the character %00, perhaps this would work for you – it should be OK in both 6 and 7:

doc.encodedVersion=evaluate({@URLEncode(“Domino”;@ReplaceSubstring(test; @Newline; @Char(10)))}, doc)

BTW it’s easier to supply the document as an argument to Evaluate so that you can refer to its fields, instead of trying to calculate them into the formula as literals. You old code would have choked on quotes within the data – even in 6.

3

Subject: RE: @URLEncode - Different behaviour in R6 and R7

Another BTW: the difference between the versions is not in @URLEncode – it’s in whether you’re allowed to use a newline inside of a string literal in macro code. By not trying to convert your field into a literal, you bypass this difference.

4

Subject: RE: @URLEncode - Different behaviour in R6 and R7

Hi Andre,

Thanks for your reply - that explains it.

I’ve already put in the @ReplaceSubstring to solve it, I just wondered whether it was a bug.

The reason I couldn’t use the document field to evaluate was because the test field is a RichText field, so doesn’t exist at WebQuerySave on a new document.

Thanks for your help,

Colin.

5

Subject: RE: @URLEncode - Different behaviour in R6 and R7

You’re mistaken – rich text fields do exist in a Webquerysave of a new document. It’s just not valid to use a rich text field as an argument to @URLEncode. You would have to write: @URLEncode(“Domino”; @ReplaceSubstring(@Text(rtf); @Newline; @Char(10)))

Now you really have me wondering what bizarre kind of application you have, that requires you to generate a URL that includes the contents of a rich text field.

6

Subject: RE: @URLEncode - Different behaviour in R6 and R7

It’s not that he’s creating such a URL (that would be bizarre), but that he’s feeding it to JavaScript as an escaped string. Something Ajaxy, perhaps?

7

Subject: RE: @URLEncode - Different behaviour in R6 and R7

So the difference is in how Domino Servers ND6 and ND7 handle strings within macro code?

And this difference would only show itself in @URLEncode and @URLDecode?

Thanks!

8

Subject: RE: @URLEncode - Different behaviour in R6 and R7

So the difference is in how Domino Servers ND6 and ND7 handle strings within macro code?

I speculate that this is the case; it would appear to be so, based on what he describes happening.

And this difference would only show itself in @URLEncode and @URLDecode?

I would think any formula could be affected.