& ampersand in filenames create broken links when using views (see note) with public and/or any links in private file system

This was actually fixed as part of the XSS security fix in the 3.4, which didn't have a related issue in the issue queue. It should now be corrected to handle special characters like & < > " '.

I'm having this problem with FileField 3.9. & turns into %2526 in a link's href for both node view and node edit.

The problem exists when Drupal is set to private files mode. In public mode, the ampersand shows up in the link correctly and the download works.

I'm working around this by adding a str_replace in my theme's template.php:

function THEME_filefield_file($file) {
  // Views may call this function with a NULL value, return an empty string.
  if (empty($file['fid'])) {
    return '';
  }

  $path = $file['filepath'];
  $url = file_create_url($path);
  // Decode ampersands.
  $url = str_replace('%2526', '&', $url);
...

I'm sure there's a better way.

I don't plan on fixing this issue personally. I'd be happy to review patches by users who are experiencing this problem.

I've got the same issue in 3.10 -- it's not just private fields, it also breaks in views, but only in certain circumstances.

In my case, I was putting the "Path to file" formatted field into a view, and then "excluding from display" -- I then rewrote another field as a link, and put the "path to file" field into the href setting.

Basically, I think this means that any time you take the field value and try to use a Drupal module that then uses l() or url() -- or if you're directly putting the filepath into l() or url() then the path gets passed through drupal_urlencode() and php's rawurlencode()

It seems that trying to work around this would be a huge headache... What if the filefield just threw a validation error when it encounters an ampersand? Wouldn't that make the most sense?

better title

i was wrong.. i just tried testing l() and url() used together in PHP and there's no issue with the ampersand. i only see this problem (with my public file system) when using views as i'd described above...

i'm not sure what about that approach causes it to break.

in the attached screenshot, the field_research_file_fid token refers to the field that is "excluded from display"

that field is configured with the "Path to file" formatter

OK -- to anyone out there who finds this... i fixed my issue by changing to "URL to file" output instead of "Path to file" in the view field settings...

Sorry that doesn't help anyone having private file system problems.. unless you're using views like i was!

We fixed this issue when using the "Generic File" formatter in #1249486: Properly encode public file urls with special characters in file name that were being double escaped. There are probably still lingering problems when doing Views, since we don't provide a custom handler for the display of file paths.