Hi FileField dev team.

i found a problem is :

i use filefield for a new content type
and upload is fine with file name is "SS#27086.pdf"

and file will be save mydomain.com/files/SS#27086.pdf
but when i download this file with http or open it on browser it shown me is not found

seem problem with "#" character,

so i think we do need replace "#" to "_" or "-"

how about that,



quicksketch’s picture

Priority:Critical» Normal

Install http://drupal.org/project/transliteration.

This is still a bug that the # sign isn't converted into URL entity though. So we'll leave this open as a bug until I have time to confirm the problem.

tabvn’s picture

Yes, you are right, i have convert use url encode (urlencode) , but i think this is mistake in filefield theme funciton

i hope FileField Dev Team, fixs this in next version.


quicksketch’s picture

Status:Active» Fixed
new788 bytes

This patch fixes up this problem. Apparently when using public files you have to manually encode the URL, as Drupal just assumes that the URL is okay otherwise. Private files are already encoded just fine.

quicksketch’s picture

Title:Error with upload with file name has special character "#"» Encode public URLs to help with display of characters, such as "#"

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

basic’s picture

Status:Closed (fixed)» Needs work

This change appears to have broken URLs containing spaces. I have a few sites where the URLs are now getting double encoded. For example:
and http://bec.orvsd.org/sites/bec.orvsd.org/files/A.1%25201.doc results in the file not being accessible.

Commenting out / reverting this change fixes the problem for me. I am unsure how to fix this, using rawurlencode seems to break it more.

dooug’s picture

Version:6.x-3.10» 6.x-3.x-dev
Issue summary:View changes
Status:Needs work» Needs review
new973 bytes

I also experienced issues with the ampersand character being double escaped in the file url of the generic file display.

I did not revert the previous commit, but noticed that the code was calling drupal_urlencode() followed by file_create_url($path), which calls url() which also calls drupal_urlencode(). So the drupal_urlencode() in the theme_filefield_file() is unnecessary.

Attached is a patch that removes that function and worked for me to prevent the double escaped file urls.

dooug’s picture

new1.07 KB

Upon further review and testing. I realized that my partially reverting the original patch from comment #3 wasn't a solution.

However, I did notice that the theme_filefield_formatter_url_plain() function does the similar file url encoding with:

return file_create_url(field_file_urlencode_path($item['filepath']));


So, it makes sense to use that field_file_urlencode_path() function that is used elsewhere in the module, rather than the commited patch from comment #3.

I tested this and confirmed it solves double escaped/encoded ampersands (&) and hashes (#). I've attached the patch.

dooug’s picture

Title:Encode public URLs to help with display of characters, such as "#"» Properly encode public file urls with special characters in file name that were being double escaped

Changed issue title for clarification.

herved’s picture


I think this issue still needs work for I got double encoded urls after updating from Filefield 6.x-3.9 to 6.x-3.13.

Also I noticed other issues in the same file.
filefield\filefield_formatter.inc:68 :

  // Check for remote filepath, if so return the raw path with protocol prefix
  if (strpos($item['filepath'], 'http://') === 0 || strpos($item['filepath'], 'https://' === 0)) {  // <--- parenthesis mistake
    return l($file['filepath'], $item['filepath']);                                                                 // <--- unknown $file variable

filefield\filefield_formatter.inc:120 :
  if (strpos($path, 'http://') === 0 || strpos($path, 'https://' === 0)) {                            // <--- parenthesis mistake


pwolanin’s picture

The use of drupal_urlencode() looks clearly incorrect since for public files the output should never depend on whether we are using clean urls.

Patch in #8 looks like a reasonable fix, but it would be helpful to have some test cases even for manual verification, or better yet add a set of tests to \FileFieldTestCase