Bug - Pocket Query download with accented characters in name

[+sTeamTraen]

If I create a Pocket Query with an accented (non-USASCII) character in its name, such as "Rhône-Alpes", and I check the box to include the PQ name in the filename, and I download the PQ's ZIP file manually (by clicking on the PQ in the "Pocket Queries Ready for Download" tab, then the filename assigned for the download on Windows is wrong. Specifically, instead of proposing "12345678_Rhône-Alpes.zip", the system uses the filename "12345678_Rhô". That is wrong for two reasons:

 

1. ô is an HTML entity that only has meaning in the context of a Web page, not a file system download.

2. More importantly, the filename is truncated after the HTML entity, so the file is not correctly saved as a ZIP file (unless the user /a/ does not have automatic file saves enabled, and /b/ notices the mistake in the "Save File As" dialog).

 

Perhaps there is no 100% generic way to fix problem 1, although most file systems can handle UTF-8 characters in filenames these days; but 2 is clearly a bug.

 

Problem is reproducible on Firefox and Chrome, and presumably other browsers too. There is no problem if the PQs are downloaded via the API (for example, if GSAK does the downloading).

[+NYPaddleCacher]

If I create a Pocket Query with an accented (non-USASCII) character in its name, such as "Rhône-Alpes", and I check the box to include the PQ name in the filename, and I download the PQ's ZIP file manually (by clicking on the PQ in the "Pocket Queries Ready for Download" tab, then the filename assigned for the download on Windows is wrong. Specifically, instead of proposing "12345678_Rhône-Alpes.zip", the system uses the filename "12345678_Rhô". That is wrong for two reasons:

 

1. ô is an HTML entity that only has meaning in the context of a Web page, not a file system download.

2. More importantly, the filename is truncated after the HTML entity, so the file is not correctly saved as a ZIP file (unless the user /a/ does not have automatic file saves enabled, and /b/ notices the mistake in the "Save File As" dialog).

 

Perhaps there is no 100% generic way to fix problem 1, although most file systems can handle UTF-8 characters in filenames these days; but 2 is clearly a bug.

 

Problem is reproducible on Firefox and Chrome, and presumably other browsers too. There is no problem if the PQs are downloaded via the API (for example, if GSAK does the downloading).

 

When I save a file downloaded from a browser it shows the name of the file in a form element, and it can be changed before the file is saved. At the end of the day a filename is just a string of characters that helps you identify the contents. If it doesn't display with the diacritics the contents of the file are unchanged. I recently was sent a file by someone in China that used chinese characters and after saving the PDF file with the original file name, it wouldn't not open using Acrobat. I just saved it using a file name that made it obvious what it was and I can now read and print it.

[+sTeamTraen]

When I save a file downloaded from a browser it shows the name of the file in a form element, and it can be changed before the file is saved. At the end of the day a filename is just a string of characters that helps you identify the contents. If it doesn't display with the diacritics the contents of the file are unchanged. I recently was sent a file by someone in China that used chinese characters and after saving the PDF file with the original file name, it wouldn't not open using Acrobat. I just saved it using a file name that made it obvious what it was and I can now read and print it.

I have set Firefox up so that when I download a PDF file (defined as one with "content-type: something/, it will be immediately saved to the desktop under the default name. The problem is that this bug means that the default name /a/ does not have the UTF-8 characters in it (I repeat, ô for example in meaningless outside of HTML), but more seriously /b/ is truncated, so that /c/ among other effects, the extension .PDF is lost.

 

Yes, I could set up my browser so that PDF downloads always put up a dialog box, where I can then manually correct the filename. But I shouldn't have to, if his was designed and implemented correctly. Receiving a file sent to you on an e-mail is one thing; we all have to put up with what the human at the other end sent us. Having a file download behave differently because it has a non-USASCII character in it is rather different.