Open URL not working correctly

[Bob_Elmore]

I am building an exam in Captivate 9, and on certain screens I need the learner to view an image.  Since my options are limited, I am using a shape with the "Open URL or file" option.

This works fine when the URL contains no spaces, but when the URL has spaces Captivate inserts additional text into the URL, and then it does not work.

For example, I enter this URL in Captivate,

and Captivate changes it to this incorrect URL at runtime,

Note that it changes the %20 to %2520, which of course does not work.

Has anyone else run into this?  Adobe, is there a reason for this?

Obviously the easy solution would be to remove the spaces, but I don't have access to this website.

Thanks.

[RodWard · Accepted solution]

This is default behaviour due to the fact that it's a rule of the internet that there should be no spaces in HTTP web URLs.  Having spaces in the links would cause those links to break when users try to browse content on the web because web browsers are programmed to assume that the space means the end of a link. 

It's quite common for computer users to be confused about this behaviour because the same does not happen when dealing with links on a local networked LAN or for links to files on your own computer hard drive.  In a non-HTTP environment, such as a LAN network, spaces in links don't stop them from working.

I would suggest that you ensure any files you intend to link to use underscore characters (_) instead of spaces.  Then you won't find Captivate trying to make them web-compliant by adding these extra characters.

A better alternative would be to avoid trying to use Open URL or File actions at all inside a quiz but instead add Smart Shape Buttons to those quiz questions where you need to have an image appear and use Advanced Actions and Variables to toggle the visibility of the images by clicking on the button.

[Bob_Elmore]

Thanks Rod.  I will look into your suggestion.

[creative_soldier0D44]

While you're right about the best practice not being to use spaces, and for the default behavior of URL encoding, saying that it's a rule of the Internet not to have ENCODED spaces (%20) in a URL is just wrong. That happens everywhere, in many, many HTTP URLs. Note that I'm not talking about un-encoded spaces themselves...in that single case you'd be correct. However, that's not what Bob's question was.

What Captivate 9 is clearly mistakenly doing is re-encoding the already encoded URLs and picking up on % as a special character, which it then encodes as %25, making it %2520 (NOT an legitimate URL encoded value) instead of the original %20. This result is common when something is encoded twice.

Given all this, Jefferbob is probably correct in his solution that if you took out the encoded spaces and replaced them with actual spaces, then Captivate encoded them once, it would come out working correctly.

[RodWard]

Who said it was am internet rule not to have ENCODED spaces in a URL?

I don't see that statement anywhere in the previous posts.

[creative_soldier0D44]

That's what the original question was concerning (hence the %20 in his images) so unless you're implying that you just felt like stating something unrelated for posterity's sake, I applied your answer referencing spaces to his question talking about encoded spaces.

Regardless of the confusion, the fact that you reference this as default behavior tells me you think it's correct or valid. Re-encoding URLs that have already been encoded without checking to see if they're already encoded is just a silly practice. It forces people to enter the URLs with actual spaces (something that WOULD break, without the subsequent encoding) in order to get the desired result. This is something Captivate should make abundantly clear in docs, or correct all together in code.

[RodWard]

it's best not to make assumptions on other people's behalf and misquote their statements, even if that's what you THINK they meant.

If you feel Captivate's handling of this issue could be improved, by all means log an enhancement request via the form linked from the Community page.

[Jefferbob]

Enter the URL into Captivate **with** spaces instead of the %20 encodings. Captivate will do the encoding. As you have it now, Captivate is encoding the % to be %25, then adding the 20.

[Bob_Elmore]

OK, thanks.  I suppose that makes sense, from Adobe's perspective. Too bad Adobe doesn't recognize the %20 as the space inserted on web pages.

Though, as Rod pointed out, best to avoid the spaces if you can, but we don't always have access to edit the web pages we are referencing.

[kthayer]

I'm tagging on to this issue from a few years ago because our Saba tech support referred me to this thread. However, I'm not sure this will work for our scenario. We are only having this problem publishing to HTML5 from Captivate 9 and the problem is related to Saba group URLs that are getting changed. Their URLs do not have %20 but rather %2 in them such as the following:   https://inforsb.sabacloud.com/Saba/Web_spf/NA3T1SNB0031/app/shared;spf-url=common%2Fgroupdetail%2Fte...

When the course is played in Saba, the 52 is added and breaks the link as follows: https://inforsb.sabacloud.com/Saba/Web_spf/NA3T1SNB0031/app/shared;spf-url=common%252Fgroupdetail%25...

Other click boxes with direct URLs are fine. It's only the Saba generated URLs that are getting changed.

Any ideas?

Thanks,

Kris

[Arc-en-ciel]

Hi there, we're using Captivate 9 still (will be upgrading soon) are are republishing all of our modules to HTML5. Some of the modules have existing links to an internal SharePoint site and we get the Page not found message. I had traced the issue down to folders with spaces in them and noticed the %20 was being replaced by %2520 and then searched in the community and found this thread. We have tried replacing the %20 with spaces in the URL in Captivate but they are still coming out as %2520 once we publish. Has anything else worked? Thanks!

[Arc-en-ciel]

Not sure what happened the other day. I set up a one-slide module, added a button that opened a URL and replaced the %20 references within the URL with spaces. I published and it worked. I went back to the previous module and tried again and it worked. Strange.

Thanks for the workaround.