In Xpages Upload control,I can upload the photo file with special characters. But In the view, some of the special characters change to underscore (eg. {#[ to _ ) , some are not (like space,+). When using the function attachmentObject.getName() , I can get the original file name with special characters. Therefore I got a problem when i get back that kind of file. Is there any suggestion for me?? Thank You.
The issue comes from the hash (#) as this is a very special character in URLs. It cannot be easily translated into the special URL-Encoded form as it is a valid character for the URL scheme and has a special meaning there. Using the ExtLib @EncodeUrl function does also not work as this one will cut your string off right in front of that hash (which i consider a bug), leading to a resource request that cannot exist on your server and hence leading to a 404.
In order to finally solve this, I took an old function that I wrote back in 2009 (http://blog.gollmick.de/mgoblog.nsf/dx/some-more-Functions-for-XPages-URLEncode-URLDecode.htm) - and that one does the job as you need it here:
Assuming that your datasource is named document1
and you have the attachment in an item named body
and you are going to use the very first attachment of that item, you would need the following code to compute the path to your attachment correctly:
function @URLEncode(encodeObject, encSch:String) {
try {
var encScheme = ((encSch) && (encSch !== null))?encSch:"UTF-8";
return java.net.URLEncoder.encode(encodeObject.toString(),
encScheme);
} catch (e) {
print("ERROR in @URLEncode:" + e);
}
return null;
}
try {
var list:java.util.List = document1.getAttachmentList("Body"),
neo:NotesEmbeddedObject,
size = list.size(),
path = "";
if (0 < size) {
neo = list.get(0);
path = "0/" + document1.getDocument().getUniversalID() + "/$file/" + @URLEncode(neo.getName());
}
return path;
} catch (e) {
print(e.toString());
}
You will certainly need to modify this code to your needs, but this should give you the right hint for computing the right path for web. I have not yet tested that one in XPinC right now, so the computed path may still differ here.