Hey Alexandra I will get to the bottom of this with very long answer.
I do have to thank Dave again for how he documents his answers with very specific answers. Dave reference to RFC3986 is spot on which led me to dig up more. Below is my suggestions.
IN ADDITION TO THE JAVASCRIPT OPTION THAT I POSTED EARLIER BELOW IS THE MOST UP TO DATE SOLUTION THAT I WAS ABLE TO CONFIRM
****************** DO NOT USE THE WEBLINK PLUG-IN ***********************
************* UNTIL ADOBE CAN LOOK INTO THIS *****************
*********** AND FIX IT ************
Links work perfectly fine if you just enable from EDIT -->>> PREFERENCES---->>> GENERAL --->>> check the tickbox "Create Links from URLs" and then just right-click on the document and select from the context menu "Edit Text & Images" (OR , opening the "Edit PDF Tool") ---> select "Add Text" and type in the desired URL with its opening parameters in just plain text.
NOTE 1 : You can also use copy and paste the URL text string from a file text editor such as Notepad and paste it in the text box. (DO NOT copy from MS Word or Wordpad , they both will convert the text string to a hyperlink automatically; this is what we're trying to avoid). This method won't work when you copy a hyperlinks that are already encoded as Text/HTML and paste it in the text box in Acrobat; it will create the same issue because it trigger to use the problematic weblink creation tool in Acrobat.
NOTE 2: When you're done adding your URLs to your document, SAVE and close it . Reopening your document in Acrobat will apply the conversion to hyperlinks automatically and most importantly without the incorrect %23 encoding.
HERE IS MORE OBSERVATIONS FOR THE COMMUNITY THAT MAY BE INTERESTED IN LOOKING INTO THIS:
- copying a URL from a hyperlink that was generated with MS Word, Wordpad, and/or from a web browser application and pasting it directly into an opened PDF document in Acrobat will trigger the incorrect percent encoding to UTF-8.
- Manually creating a web link using the "Add-Edit link" tool will also trigger the incorrect percent encoding.
- Both of these methods fail to decode strings of plain text that contain special characters, such as the "#" in this case, into valid UTF-8 encoded URL formats
- These methods are failing to properly convert text to URL because the Acrobat WebLink plug-in that handles this part of the conversion is doing it improperly.
- Not only the Acrobat WebLink plug-in seems to be glitchy but is also partially encoding only some of the special charachters with the correct encoding to UTF-8.
- You WOULD NOT see this problem if the Weblink plug-in was DECODING UTF-8 to TEXT STRINGS instead of encoding it to UTF-8, ASCII or to ISO-8859-1. AND you would've also be able to manuallly fix this problem if Acrobat allow these weblinks to be properly tagged as and containerized as text annotation in the document structure.
That is the Bug! It should NOT encode, IT SHOULD DECODE to begin with.
In a web page that use the older HTML 4, for example, it will accept both the text string "#" or %23 in a URL created with the Weblink plug-in, even with Acrobat Pro DC Weblinking acting out.
You can test with the URLs below using the weblink method in Acrobat:
https://www.w3.org/TR/REC-html40/interact/forms.html%23form-content-type
And you can also type it like this in any of your browsers address bar and it will also open up the page successfully:
https://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type
To see the HTML document type used in that page and its encoded character set, hit "CTRL+U in your keyboard and you will see this clearly outline in the first three lines:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
Notice the HTML document type and the type of content accepted to include the character set.
By itself this is not a bug, but as mentioned by Dave is related to security that is constantly under revision by the Internet Society AND (as addressed in the RFC ), that was imporved in HTML5 and now it results in a violation of those HTML5 standards.
Now compare how a page with HTML5 displays this same information:
//JUST THE FIRST LINE !DOCTYPE HTML is how you identify HTML5 it doesn't have any other disclaimer notes; simple
<!DOCTYPE HTML>
<html class="spectrum--medium" lang="en">
//THEN SCROLL DOWN PASS ALL THE SUPPORTED LANGUAGES AND YOU WILL SEE THE ENCODING TYPE
<meta charset="UTF-8"/>
That said, it is worth noting that back in 2016 a vulnerability was addressed in the XMPCore libraries (which are used by the Weblink plug-in)
See the quote below here: https://www.cvedetails.com/cve/CVE-2016-4216/
- "XMPCore in Adobe XMP Toolkit for Java before 5.1.3 allows remote attackers to read arbitrary files via XML data containing an external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue."
To fix this exploit Adobe recommended to update the xmpcore library:
So I'm thinking if this may explain in a very indirect way why your version of Acrobat DC 2017 works as if there is no problem.
The dates prior to when this vulnerability was addressed coincide with the same timeframe that your version was released. Something worth examining between Acrobat Pro DC and Acrobat DC 2017 and compare what the XMPs that the Weblink driver is registering with looks like .
In Acrobat Pro DC there is no bug when it comes to enforcing this UTF-8 decoding and encoding . At least we have a clear indication that the secuirty mechanism is doing its job.
But the actual bug that I am identifying for the Adobe community lives in the Weblink plug-in driver registration process that is used in Acrobat Pro DC.
It is causing an unnecessary and incorrect encoding of string text to UTF-8 in the PDF itself which doesn't let the HTML 5 web pages that already enforce UTF-8 to properly fall back to the appropriate decoding.
Let's use this URL: https"//www/adobe.com/#page=3 as an example.
You can clearly visually spot that the conversion is incomplete after a link is created with the Weblink plug-in because the "#" sign gets encoded to the %23 but not the "=" sign, for example, to include all the other reserved special characters..
If the link used in my example above was encoded correctly to UTF-8, ASCII, or ISO-8859-1 (also known as ISO-Latin-1), should look like this:
https"//www/adobe.com/%23page%3D3
But this is also incorrect.
See the default character-set in HTML5 for UTF-8 and how it works.
If this Web-link plug-in was doing its job correctly, when you manually type in an URL address as plain text in the Weblink tool like this :
https"//www/adobe.com/#page=3
it should read like this:
https"//www/adobe.com/#page=3
No changes should occur.
And if the Weblink plug-in was actually encoding the text string correctly to UTF-8 , ASCII, or ISO-8859-1, then it should read or look like this:
https%3A%2F%2Fwww.adobe.com%23page%3D3
Using Dave's referenced link for the RFC it clearly states: "URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component"
To see this for yourself use this online ENCODER/DECODER tool: https://www.urlencoder.org/
From further digging more information out of the Acrobat DC SDK documentation, the Weblink plug-in is having an issue somewhere with Unicode paths(if on MS Windows (because Unicode is separate from the default encoding standard of the OS which nowadays is UTF-16--->> This is not a problem in macOS and other Unixlike OSs because Unicode is the standard already) , Host Function Tables used by the Weblink plug-in (https://help.adobe.com/en_US/acrobat/acrobat_dc_sdk/2015/HTMLHelp/Acro12_MasterBook/API_References_S...) , XMPCore libraries, Weblink extended API, incorrect character sets or character tables, and not limited to incorrect XMP metadata. More importantly look here: https://help.adobe.com/en_US/acrobat/acrobat_dc_sdk/2015/HTMLHelp/Acro12_MasterBook/API_References_S...
Also look at good old document here:
The document linked below actually explains how the URI actions are "parsed" on the Acrobat side of the house:
16
Replies
AdChoices