How to download attachment with special characters in its name through REST call?

I have a Confluence page with the following file attached to it:
Test1 - :::;;;’’~!@#$%^&*()_+`-=[]{}"’|<>,.?/.txt

What should be API call to download it?
server/download/attachments/id/{what should go here?}

Thank you

Attachments page in confluence with this file contains download link, which is not functional:

However, the file can be viewed and edited successfully through respective “View” and “Edit” links on the same page.

I found this useful link regarding allowed characters:

Confluence’s List of Illegal Characters
Characters not allowed in Confluence pagenames:
: ; < > @ / \ | # [ ] { } ^
Characters not allowed to start Confluence pagenames:
$ … ~

Does it also apply to attachment names and API calls?

i had a hard time creating a file with the name you proposed :slight_smile:

on linux it is not possible to create files containing the forward slash “/” (See this SO article: )

Escaping the forward slash would be %2F, maybe this works for you, however i recommend not using the forward slash in file names because of linux/macosx users.

i think this is why you are facing the mentioned problem.

removing the forward slash, i was able to create a file called “Test1 - :::;;;’’~!@#$%^&*()_+`-=[]{}”’|<>,.?.txt" and uploaded it to a page.

The generated link: server/download/attachments/9634073/Test1%20-%20%3A%3A%3A%3B%3B%3B%E2%80%99%E2%80%99~%21@%23%24%25%5E%26*%28%29_%2B%60-%3D%5B%5D%7B%7D%22%E2%80%99%7C%3C%3E%2C.%3F.txt?api=v2


If you are talking about the REST-API this call gives you all information confluence can give you about your attachments:

AJS.$.get(‘server/rest/api/content/’ + AJS.params.pageId + ‘/child/attachment’, console.log);

in the _links property of the result you will find the “self” link (i think this is based on Following the “self”-link you are able to get the download link for your attachment as generated by confluence. in my case this looked like this:

self-link: server/rest/api/content/9634073/child/attachment?_=1523538394077


  "results": [
      "id": "att9634075",
      "type": "attachment",
      "status": "current",
      "title": "Test1 - :::;;;’’~!@#$%^&*()_+`-=[]{}\"’|<>,.?.txt",
      "metadata": {
        "mediaType": "text/plain",
        "labels": {
          "results": [],
          "start": 0,
          "limit": 200,
          "size": 0,
          "_links": {
            "self": "server/rest/api/content/att9634075/label"
        "_expandable": {
          "currentuser": "",
          "properties": "",
          "frontend": ""
      "extensions": {
        "mediaType": "text/plain",
        "fileSize": 5
      "_links": {
        "webui": "/display/ES/Attachment+Test?preview=%2F9634073%2F9634075%2FTest1+-+%3A%3A%3A%3B%3B%3B%E2%80%99%E2%80%99~%21@%23%24%25%5E%26*%28%29_%2B%60-%3D%5B%5D%7B%7D%22%E2%80%99%7C%3C%3E%2C.%3F.txt",
        "download": "/download/attachments/9634073/Test1%20-%20%3A%3A%3A%3B%3B%3B%E2%80%99%E2%80%99~%21@%23%24%25%5E%26*%28%29_%2B%60-%3D%5B%5D%7B%7D%22%E2%80%99%7C%3C%3E%2C.%3F.txt?version=1&modificationDate=1523537554822&api=v2",
        "self": "server/rest/api/content/att9634075"
      "_expandable": {
        "container": "/rest/api/content/9634073",
        "operations": "",
        "children": "/rest/api/content/att9634075/child",
        "history": "/rest/api/content/att9634075/history",
        "ancestors": "",
        "body": "",
        "version": "",
        "descendants": "/rest/api/content/att9634075/descendant",
        "space": "/rest/api/space/ES"
  "start": 0,
  "limit": 50,
  "size": 1,
  "_links": {
    "self": "server/rest/api/content/9634073/child/attachment?_=1523538320155",
    "base": "server",
    "context": ""

@matthias.steinboeck, I cannot tell how grateful I am for the time you took writing your thoughtful reply to this question. I despaired already expecting a reasonable feedback on this serious problem.

You might think that the problem is artificial and exaggerated. It is not. We encounter massive amounts of malformed attachment names in Confluence instances of our client. We and our clients are facing serious problems dealing with them.

How these files appear? In our observations, not manually. We see third party plugins as main source of malformed files. It seems that any plugin can give any file in Confluence any incompatible name.

I regret that you spent too much time creating malformed file in Confluence. It is not related to your Linux (although, I m working on Windows). To create malformed attachment:

  1. Upload any plain file, e.g. “Notes.txt”
  2. Go to attachments list
  3. Find “properties” link next to your attachment
  4. View “name” entry field in properties
  5. Fill whatever trash in “name”
  6. Save properties with success
  7. Enjoy wild file name

Some Confluence links on this malformed attachment work, some - not. It seems that Confluence is smart enough to download such attachments with in-place character substitution. I saw improper characters implicitly replaced by underlines when downloading these attachments to local disk.

In general, I think there must be some internal server control to prevent this mess. However, because such names were already widely spread through plugins, it might break compatibility of many client installations.

What I mean, it is a serious fundamental problem in Confluence with these names, not just a silly fantasy of tech geeks devising how to break the system.

Hey @boris.zinchenko no probs dude, having some serious problems with confluence server on my own i thought why not give your topic a try.
i totally agree there is a lot of in-transparent - some times even inconsistent - stuff.

I tried to follow your steps, but confluence 6.4.3. did not accept illegal characters.

I totally understand your problem with 3rd party plugins (having some on my own concerning the consistency of the macro-id). that sounds like a mess :frowning: fortunately i did not make the file-name experience yet, so its hard for me to give you any pointers there.

I guess (hope) Atlassian has some internal convention about how to handle file names, but how they exactly do that i don’t know and besides the error message i don’t know of any other resource giving any pointers… :confused:

@matthias.steinboeck, Thank you for an apt feedback. I m delighted to know that Atlassian blocked this dangerous option at least in the latest server release. Who knows, maybe our discussion here triggered this change! I m running my tests on cloud Confluence, which traditionally lags behind on premise servers. There dangerous renaming is still in effect. Please see attached screen. Hitting “save” button saves this ugly name very fine.