URLs (Links) do not work in my PDFs (from Word Documents), because # ist replaced by %23, which results to an Error 404 in Browsers. Is there a workaround for this bug in Adobe Acrobat XI Standard?
I am having exactly the same problem with # being replaced with %23 and links not working (MS Word 2013, Acrobat XI Pro 11.0.11, Win 8.1). Why has this problem not been fixed?
Well version 11.0.12 is now out and still no fix. Sigh.
Yeah, that's a good idea Claire. I used Google's URL shortener since we already use that in a couple of places. Not an optimal solution, but it will work for now. I would still like to hear Adobe's plans to fix this. It doesn't look very professional having the shortened links in there, plus it obscures the location when the user hovers over the link. That's both irritating, and a potential security risk from an end user standpoint, since they don't know where the link will take them.
True, it's more a workaround rather than a fix.
I had this same issue (except with dashes in the URL) and this post saved me. As clairecessford mentioned, this is a workaround and not a fix. Please fix this Adobe and it's easier to Print as PDF instead of going through the Save As process.Given the date on the original post, this issue has been around for awhile now. And I'm running on the latest CC version so I know it's still a problem.
I disagree that this issue has been "answered" by suggesting we create bit.ly links for every instance in a PDF where we're linking to URLs that include anchor tags.
It's clearly an Acrobat/Office bug (we're on Office 2013 and latest Acrobat version). When I create a link in a Word doc like "http://yadda.com/document#anchorname", it should use that exact link when it converts to PDF, not translate the hashtag to %23 which works in some environments and not in others. I see that this thread is over 18 months old, but the problem shouldn't be marked as "Answered" by suggesting a manual work-around with the bit.ly suggestion. (Fine suggestion if there's just one link, not acceptable if there are dozens.)
Actually what it is, is you are name the file withal space and and a space encodes %23 which no wen browser accepts. What you have to do is rename the files you want to upload to either not use spaces. Or use underscores like on a PC instead of spaces.
Spaces aren't the issue in this case, it's Word/Acrobat converting (web-encoding) the # sign as %23, which in many web server configurations results in a 404 error. We follow the W3C guidelines for naming files/URLs, but it's Acrobat (or Office, hard to tell) that's causing the issue by not just leaving # anchor tags as-is when converting to PDF.
We use IIS7 and I've created a rewrite rule to handle the problem (see my stackoverflow comment) which works fine, but would still be nice if Acrobat would leave URLs exactly as authors create them. My opinion: Acrobat is trying to help the user by encoding links to ensure they're web-safe, but they should pull back a bit and allow W3C-accepted characters in URLs to come through as-is.
My memory is a little hazy, but I think the issue was related to auto-recognized urls. If you create a specific url link, the problem goes away. You can determine if this is an auto recognized url issue by turnning of the auto-recogonize urls in the preferences.
Uncheck the 2nd checkbox.
This is a bug that needs to be fixed. The bitly workaround is not acceptable for the reasons detailed by ArmandFrvr.
Please check with latest Acrobat version if you are using Acrobat 11 or Acrobat DC - Continuous and then let us know if the issue persists.
Problem seems to be fixed (finally) with the latest update to Acrobat 11 (11.0.13).
Note: I only had time for a quick check.
This is NOT FIXED in Adobe Acrobat Pro DC with this version info:
Very easy to reproduce - create a PDF and select the text you want to hyperlink to and then right click that text and chose Create Link (then choose Open a web page radio button in the pop-up then click Next) and enter a URL that has a # in it (i.e. https://www.w3.org/WAI/tutorials/page-structure/headings/#main-heading-before-navigation).
Save the PDF and click that link and see that your browser is trying to go to this:
see the # has become a %23 and this results in a 404 not found error page.
This is a bug that Adobe should fix as was stated by user 'Michael_E_Murphy' several years ago.
Since this bug still hasn't been fixed 5 years later, I found a solution to fix the incoming links on Apache web servers using mod_rewrite. Unfortunately this won't help if the PDF links to a website you don't own.
If you have access to an .htaccess file on your website you can try to detect the %23 and rewrite it to # automatically, rather than creating a manual redirect for every link. It's tricky because the %23 in the incoming REQUEST_URI is automatically decoded to # (so you have to actually look for # instead of %23), and then doubly tricky because the # in the destination url you redirect to is automatically re-encoded back to %23. You must use a noescape [NE] flag on your redirect to prevent the re-encoding and avoid an infinite loop. The good news is that Apache will only ever match %23, and never a literal # because the client-side anchor is stripped off before creating the server variables. So even though this pattern looks for #, you'll only find it for urls that contain %23 (such as the Adobe bug).
This worked for me but may be a little different for your needs (such as if done via VHOST instead of .htaccess):
RewriteEngine on RewriteBase / RewriteRule ^(.*)\#([^/]*)$ $1\#$2 [R=301,NE,L]
This pattern matches a link that ends with an anchor that has been converted into %23 (even though it matches a literal #) and redirects it to itself, while adding the noescape [NE] flag. This will not lead to an infinite loop of redirects, because once the # is written without %-encoding the anchor will no longer be visible to Apache after the first redirect. This should not affect any query strings because they are not matched by the RewriteRule pattern. If you want to automatically fix links containing both a query string and an anchor, you will need a more complicated solution involving a RewriteCond (because the %23 anchor then becomes part of the query string instead of part of the url path).
Disclaimer: If you're not familiar with mod_rewrite, be careful, it can easily break your website.
Hey guys, i believe, that can be frustrating.
But, i found ellegant workaround for this.
All what You need to do, is changing type of link.
After that, you can place there
It work correctly.
This worked for me! Unbelievable this is still a bug in 2020.
Here's a step-by-step of MSzotkovski's directions in case anyone needs it:
The URL should now launch correctly.
It's not really solving the root problem (improper decoding of special characters on Acrobat's end), but it's a reasonable workaround for small quantities of URLs.
Hey vresri, I apologize with my post. I just realized you guys posted the solution after I clicked on my reply button.
At least this shows that more people are noticing the same problem and we're getting somewhere.
I'm sorry to break the cheerful mood and be the actual party-pooper that is about to ruin the partially fructiferous pseudo-victory here.
I don't know how you're able to get over 18K views by suggesting a third-party solution in the Adobe community support forums.
I am 100% positive that if it was me who posted that link here, a lineup of MVP's and ACP's would've jump already to tell me that I can't do that, and 12 months later I would still be wondering why does my answer was never marked as a correct solution.
This problem has nothing to do with a particular operating system platform; I confirmed that it happens using any version of MS Windows 7 through MS Windows 10.
So it is most likely that a bug was introduced via recent updates of Acrobat Pro DC or no-one has ever cared to look into this since 2012...
Anyway, according to another user that I was helping out yesterday, the problem doesn't manifest with Acrobat DC 2017.
The person had uninstalled Acrobat Pro DC as a "band-aid" remedy (I quote). Moreover, in an environment where a user has to process thousands of documents with URL web links, bytly.com imposes a cap to a maximum limit of URLs that a user is able to fix using their service.
Here is my post to that person 3 hours ago before I posted in this thread:
If this problem is indeed a bug, when you use the Create Web Link wizard from the "Edit Tool" it seems as if something is not converting the hash or pund symbol appropriately to the corresponding Unicode symbol .
So lets us take a look at the slides below:
If you refer to a Unicode table, look for the ASCII punctuation and symbol symbol section for " # " (without the quotes" ) you will notice U+0023 <<<---------- SEE THE RELATIONSHIP WITH THE %23 NOW???
See a lot more here:
As you can see, this problem has nothing to do with web servers, plug-ins, MS Office add-ins, browser add-ons, macros, Active X control in Windows, and what not.
See the additional set of slides that I prepared and use this other method instead:
// YOU CAN USE THIS EXAMPLE URL TO TEST AND SEE FOR YOURSELF IF IT WORKS app.launchURL("http://www.adobe.com#page=3");
++++++COMPLETELY EDITED REPLY : TOO MANY TYPOS, BAD GRAMMAR, POORLY ORGANIZED CONTENT.
If you've used the Weblink plug-in that is found in the "Edit PDF" tool it won't work.
It seems like (just saying, it seems like ) this is a bug. When you used this weblink tool it generates simple URLs out of the text string that you input but it fails to treat this field as an annotation. That is why you can't work around it.
If it was treated as an annotation you would be able to manually edit its tag propperties and even its container attributes.
To work around this, don't use the weblink plug-in to generate URI actions. Instead, follow the recommendations I posted for another user here:
var numWeblinks = this.addWeblinks(); console.println("There were " + numWeblinks + " instances of text that looked like a web address," +" and converted as such.");
Using the methods that I described in the bullets and notes above work, and more importantly, you will be able to see those hyperlinks treated as annotations in Acrobat too.
Last thoughts, Bytly.com is not the appropriate workaround nor the solution to this problem. Hyperlinks that are created in Adobe Acrobat Pro from a text string work perfectly fine and the encoding and decoding from text string to UTF-8 also works perfectly.
Just make sure not to continue to use the Weblink plug-in and let Adobe look into this and fix it.
Today Adobe pushed out a new optional update that finally addresses this issue.
Apply this last update and see how your Acrobat behaves.
THANK YOU ADOBE!!!
this issue has been fixed with the last update to version:
I have the same issue on my Mac Pro Catalina. It's not a server issue, the "#" is replaced with a %23 and it takes you to a 404 web page on any browser or computer. This is a glitch I hope will be addressed. In the meantime, making a bitly link is a simple, but genius workaround.
Did you apply all updates?