# replaced by %23 when creating a web link

THANK YOU ADOBE!!!

this issue has been fixed with the last update to version:

2020.009.20067

Additional note to the Acrobat community  users:

If you get an error "The Web Capture operation you have requested has failed because of an error"

Is because when you type in an http URL using a URI producing application, such as the Acrobat Weblink plug-in , you don't need to type https://www.adobe.com.

Just type your desired URL as:

https://adobe.com

Website written in HTML5 will handle this standard convention.

You will notice that your web browser will find the page and convert the whole URL automatically to:

https:// www.adobe.com

Hi,

Today a new optional update was released that addresses this issue.

Update Acrobat and see how it goes.

Creating a URL with the Weblink plug-in  seems to be working now.

I am getting a different error though.

"The Web Capture operation you have requested has failed because of an error"

Just checking on my end what is the issue.

This is nothing to do with Unicode or spaces or JavaScript. Acrobat has always had major problems understanding the structure of a URI, and it makes an invalid assumption about reserved characters.

The RFC3986 standard defines which characters can and cannot be used in a URI, and also defines a set of "reserved" characters that have a special meaning (such as / : ? # ). Any character not on the permitted list, such as a space, must be percent-encoded (commonly called "URL-encoding"). The RFC is perfectly clear about the rules:

1. If a reserved character is being used for a reserved purpose (such as # to indicate an anchor name, or ? to show the start of a parameter list) then it must NEVER be percent-encoded. Browsers must process the character using its defined reserved function.
2. If a reserved character is being used for any other purpose (a parameter might want to define mystring=has#tagz) then it must ALWAYS be percent-encoded, so it must be written mystring=has%23tagz . Browsers must process the character as plain text.

Some browsers are a little flexible when it comes to spaces in URLs, but they will always follow RFC3986 when they encounter a ? # or %

Acrobat always applies rule 2 and percent-encodes everything, no matter what. For the vast majority of URIs that is going to break things, and there is no way to tell Acrobat to stop messing about with the string. Adobe will argue it is playing safe by guaranteeing there will never be any "illegal" characters in a web link, but it's totally wrong to forcibly change the intention of user-entered data. It should leave the URI exactly as entered; if it's invalid that's the author's problem.

Have you noticed if this happened after an update took place in your machine?