Why is the plus () sign an illegal character when uploading attachments, but when you save an attachment (or export as Word), all spaces are replaced by the plus sign? Can you change the behaviour to insert "%20" instead of ""? Currently, you need to convert all plus signs to spaces before re-uploading an attachment that has been downloaded.
[ucdavis.edu]
- is duplicated by
-
CONFSERVER-9545 Allow '+' in the filename
- Closed
- relates to
-
CONFSERVER-2487 Attachments containing spaces download with + in their filenames.
-
- Closed
-
- was cloned as
-
-
- Closed
-
[CONFSERVER-7760] Make the plus-sign a legal character for attachments
Are you sure this has been fixed?
This still doesn't work for me in 3.4.3... I get "Magics+-2.10.0.tar.gz contains illegal characters ('&', '', '?', '|' or '=')."
John Price
added a comment - On a related note, it'd be nice to allow the & as well since it's a legal file name character (at least in Windows). In my case, AT&T is a client and there are tons of documents with that symbol. I realize it would require various code changes to encode the & in URLs etc.
John Price
added a comment - On a related note, it'd be nice to allow the & as well since it's a legal file name character (at least in Windows). In my case, AT&T is a client and there are tons of documents with that symbol. I realize it would require various code changes to encode the & in URLs etc. 
Laura Kolker
added a comment - Just a heads up: I'm noticing that the Remote API appears to allow plus signs in attachment filenames when it does not allow them in the normal attachment UI. I'm not sure if this is by design or not, but it seems related to this issue. I've attached a screenshot (RemoteAPIAllowsPlus.jpg)
Laura Kolker
added a comment - Just a heads up: I'm noticing that the Remote API appears to allow plus signs in attachment filenames when it does not allow them in the normal attachment UI. I'm not sure if this is by design or not, but it seems related to this issue. I've attached a screenshot (RemoteAPIAllowsPlus.jpg) Hi guys,
Thanks for your feedback.
At the moment, we'd prefer to resolve the issue where attachments are downloaded with plus signs in the name (CONF-2487). If we solved this bug, would uploading files with plus signs still be necessary?
If so, I can close this issue as a duplicate, and you can place your votes against that bug to help us prioritise it.
Regards,
Matt
Dear Atlassian,
This is a very important aspect for ease of use when regularly updating attachments. Do you have any updates on how your investigations are going?
At the moment, one workaround we found is to start off by uploading files with "underscores" instead of spaces, eg "this_is_a_file.xls".
However, it will take quite a while for new users to get used to this, and it seems quite tedious to have a filename's spaces renamed to + symbols, only to find that you can not reupload it without renaming it again.
Can Confluence be configured so that it will rename spaces into Underscores instead?
regards,
Paul
Thanks for the suggestion. To fix this, we'd need to investigate the reason why this limitation was introduced. I think it would involve a change to our wiki markup parsing and URL generation for attachments.
I believe this issue should be reopened or at least marked as WontFix, because it hasn't been fixed.
This is a clear example of a "leaky abstraction" when implementation details are filtered out to the user to his or her chagrin. User Joe has a file in his desktop, called "Joe+&&+". That name is perfectly legal in his operating system (it is in most). Then he tries to upload to Confluence and... whack! not legal now. Why, he asks? Then we have to tell him about URLEncoding....
Come on boys! There are clear mechanisms to avoid these problems. Please use them.