CFMail breaks up attachments filename with non ASCII

Hi CF-Devs out there!
My problem is, that when attaching files via cfmailparam - no
matter if inline or not - and using a filename that contains or a
non 7bit-ASCII character or a simple space, the filename is not
displayed correctly in Outlook nor Thunderbird. I am sure that this
topic has been discussed here earlier but I really don't find any
topic when using the Forum Search function... so please help anyway
:) I am still using CFMX 6.1 :(
My code is the following:
<cfmailparam type="#variables.attachments
.getContentType()#"
file="#variables.attachments.getFilename()#"
disposition="#this.dispositionType(variables.attachments
.isInline())#"
contentID = "#variables.attachments.getCid()#">
When I revise the generated email code then I find the
following:
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename*2=nger.csv;
filename*0*=UTF-8''emailempf; filename*1*=%c3%a4
Content-ID: <DEE13419-D022-9396-C8A4DF2AAAA7C4EF>
You can see that the filename (emailempfänger.csv)
breaks up into several pieces which according to
RFC 2231 is a
valid format but obviously is not interpreted correctly by e.g.
Outlook. Or am I missing something else?
I would appreciate your help. Thanks in advance.
Buergermeister

The filename you used does not contain any non 7bit ASCII
character. The problem only occurs if I use characters like
"ä","ö","ü" but even [space] does provoke the error.
The variables hold the following values (you can see them in
the source posted, too):
1) variables.attachments.getContentType() :
application/octet-stream
2) variables.attachments.getFilename() :
[AbsoluteFilePath]/emailempfänger.csv
3) this.dispositionType(variables.attachments.isInline()) :
attachment
4) variables.attachments.getCid():
DEE13419-D022-9396-C8A4DF2AAAA7C4EF
Cheers!

Similar Messages

  • UploadedFile and filenames with non-ascii chars

    Hi
    I'm using an UploadedFile object in my web app, and all works fine. However, when I try to upload a file, with a filename containing non-ascii chars (e.g. Spanish), I see that the getBytes method returns an empty byte array, the filename is not stored correctly (the non-ascii chars are lost, replaced by another representation), and that the content-type is application/octet-stream instead of image/png as supposed to be.
    If I rename that same file to have only ascii chars - everything is back to normal.
    How can I upload files with non-ascii chars in their name?

    Hi, back! Spent a few hours experimenting and found
    that everything is working great (including the creation
    of international non-ASCII foldernames) when I used
    utf-8 encoding in the sieve filters rules for the
    the match strings and the folder names... at least
    so far so good... for your ref and sorry for bothering.

  • Can't get the attachment filename out of a Part (with non ascii characters)

    Hello, all and happy new year :)
    My issue is with non ascii filename in attachments... Yes i've read the FAQ : http://www.oracle.com/technetwork/java/faq-135477.html#encodefilename
    I can't get the filename out of the BodyPart for those kind of attachments
    here's my unit test :
         * contains various parts from various mailer encoded in different ways...
         private enum EncodedFileNamePart{
              OUTLOOK("Content-Type: text/plain;\n name=\"=?iso-8859-1?Q?c'estd=E9j=E0no=EBl=E7ac'estcool.txt?=\" \nContent-Transfer-Encoding: 7bit\nContent-Disposition: attachment;\n filename=\"=?iso-8859-1?Q?c'estd=E9j=E0no=EBl=E7ac'estcool.txt?=\" \n\nnoel 2010\n","c'estdéjànoëlçac'estcool.txt"),
              GMAIL("Content-Type: text/plain; charset=US-ASCII; name=\"=?ISO-8859-1?B?ZOlq4G5v62znYWNlc3Rjb29sLnR4dA==?=\"\nContent-Disposition: attachment; filename=\"=?ISO-8859-1?B?ZOlq4G5v62znYWNlc3Rjb29sLnR4dA==?=\"\nContent-Transfer-Encoding: base64\nX-Attachment-Id: f_giityr5r0\n\namluZ2xlIGJlbGxzIQo=\n","déjànoëlçacestcool.txt"),
              THUNDERBIRD("Content-Type: text/plain;\n name=\"=?ISO-8859-1?Q?d=E9j=E0no=EBl=E7acestcool=2Etxt?=\"\nContent-Transfer-Encoding: 7bit\nContent-Disposition: attachment;\n filename*0*=ISO-8859-1''%64%E9%6A%E0%6E%6F%EB%6C%E7%61%63%65%73%74%63%6F;\n filename*1*=%6F%6C%2E%74%78%74\n\njingle bells!\n","déjànoëlçacestcool.txt"),
              EVOLUTION("Content-Disposition: attachment; filename*=ISO-8859-1''d%E9j%E0no%EBl.txt\nContent-Type: text/plain; name*=ISO-8859-1''d%E9j%E0no%EBl.txt; charset=\"UTF-8\" \nContent-Transfer-Encoding: 7bit\n\njingle bells\n","déjànoël.txt"),
              String content=null;
              String target=null;
              private EncodedFileNamePart(String content,String target){
                   this.content=content;
                   this.target=target;
              public Part get(){
                   try{
                   ByteArrayInputStream bis = new ByteArrayInputStream(this.content.getBytes());
                   Part part = new MimeBodyPart(bis);
                   bis.close();
                   return part;
                   catch(Throwable e){
                        return null;
              public String getTarget(){
                   return this.target;
         @Test
         public void testJavamailDecode() throws MessagingException, UnsupportedEncodingException{
              System.setProperty("mail.mime.encodefilename", "true");
              System.setProperty("mail.mime.decodefilename", "true");
              for(EncodedFileNamePart part : EncodedFileNamePart.values())
                   assertEquals(part.name(),MimeUtility.decodeText(part.get().getFileName()),part.getTarget());     
    I take a NullPointerExcepion in the decodeText because getFileName() return null for the EVOLUTION case, and work well with OUTLOOK, THUNDERBIRD and GMAIL.
    Evolution's content type is "Content-Disposition: attachment; filename*=ISO-8859-1''d%E9j%E0no%EBl.txt" wich doesn't look like the other (looks like the RFC 2616 or RFC5987 to do it.)
    How can i handle this situation except by writting my own decoder?
    Thanks for your answers!
    Edited by: user13619058 on 4 janv. 2011 07:44

    Set the System property "mail.mime.decodeparameters" to "true" to enable the RFC 2231 support.
    See the javadocs for the javax.mail.internet package for the list of properties.
    Yes, the FAQ entry should contain those details as well.

  • Problems with non-ASCII characters on Linux Unit Test Import

    I found a problem with non-ASCII characters in the Unit Test Import for Linux.  This problem does not appear in the Unit Test Import for Windows.
    I have attached a Unit Test export called PROC1.XML  It tests a procedure that is included in another attachment called PROC1.txt. The unit test includes 2 implementations.  Both implementations pass non-ASCII characters to the procedure and return them unchanged.
    In Linux, the unit test import will change the non-ASCII characters in the XML file to xFFFD. If I copy/paste the the non-ASCII characters into the Unit Test after the import, they will be stored and executed correctly.
    Amazon Ubuntu 3.13.0-45-generic / lubuntu-core
    Oracle 11g Express Edition - AL32UTF8
    SQL*Developer 4.0.3.16 Build MAIN-16.84
    Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
    In Windows, the unit test will import the non-ASCII characters unchanged from the XML file.
    Windows 7 Home Premium, Service Pack 1
    Oracle 11g Express Edition - AL32UTF8
    SQL*Developer 4.0.3.16 Build MAIN-16.84
    Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
    If SQL*Developer is coded the same between Windows and Linux, The JVM must be causing the problem.

    Set the System property "mail.mime.decodeparameters" to "true" to enable the RFC 2231 support.
    See the javadocs for the javax.mail.internet package for the list of properties.
    Yes, the FAQ entry should contain those details as well.

  • How to send an attached file containing with non-ascii code ?

    Hi,
    I want to send a attaced text file containing with non-ascii code(Traditional Chinese). Is there any way to solve the encoding problem?
    Currently, it transfer into non-meaningful code in receiving side.
    Thanks for the help in advance.

    Here is the code:
    Session _gSession = null;
    MimeMessage message = null;
    Properties props = new Properties();
    props.put("mail.smtp.host", smtpHost);
    _gSession = javax.mail.Session.getInstance(props, null);
    message = new MimeMessage(_gSession);
    message.setFrom(new InternetAddress(emailSender , emailSender));
    InternetAddress ia[] = new InternetAddress[1];
    ia[0] = new InternetAddress(emailReceiver, emailReceiver);
    message.setRecipients(Message.RecipientType.TO, ia);
    message.setSubject("Test Encoding Attached File");
    message.saveChanges();
    BodyPart messageBodyPart = new MimeBodyPart();
    DataSource fds = new FileDataSource("Big5_Code.txt");
    messageBodyPart.setDataHandler(new DataHandler(fds));
    messageBodyPart.addHeader("Content-ID","meme");
    MimeMultipart multipart = new MimeMultipart("related");
    multipart.addBodyPart(messageBodyPart);
    message.setContent(multipart);
    transport.connect();
    transport.send(message);

  • Filling clob with non ascii characters

    Hello,
    I have had some problems with clobs and usage of german
    umlauts (����). I was'nt able to insert or update
    strings containing umlaute in combination with string
    binding. After inserting or updating the umlaut
    characters were replaced by strange (spanish) '?'
    which were upside down.
    However, it was working when I did not use string bindung.
    I tried varios things, after some time I tracked
    the problem down to to oracle.toplink.queryframework.SQLCall.java. In the
    prepareStatement(...) you find something
    like
    ByteArrayInputStream inputStream = new ByteArrayInputStream(((String) parameter).getBytes());
    // Binding starts with a 1 not 0.
    statement.setAsciiStream(index + 1, inputStream,((String) parameter).getBytes().length);
    I replaced the usage of ByteArrayInputStram with CharArrayReader:
    // TH changed, 26.11.2003, Umlaut will not work with this.
    CharArrayReader reader = new CharArrayReader(((String) parameter).toCharArray());     
    statement.setCharacterStream(index + 1, reader, ((String) parameter).length() );
    and this worked.
    Is there any other way achieving this? Did anyone
    get clobs with non ascii characters to work?
    Regards -- Tobias
    (Toplink 9.0.3, Clob was mapped to String, Driver was Oracle OCI)

    I don't think the console font is the problem. I use Lat2-Terminus16 because I read the Beginner's Guide on the wiki while installing the system.
    My /etc/vconsole.conf:
    KEYMAP=de
    FONT=Lat2-Terminus16
    showconsolefont even shows me the characters missing in the file names; e.g.: Ö, Ä, Ü

  • Problems with non-ascii keywords

    I have some problems with non-ascii keywords that makes the whole keyword feature useless for me. I don't know if I'm doing something wrong or if there something I'm missing completely.
    The problem is that when I enter something like "grön" iPhoto sometimes refuses me to type in "grön" on another photo and "eats" the "ö". And if I select the matching keyword from the popup list iPhoto has changed the originally "grön" to "gr¨ön" (if that comes out right on the web). Here are a few screenshots to show what happens
    If someone knows what happens I would really appriciate some hints on how to avoid this.
    Note that adding/editing keywords works just fine in Aperture.

    There is a long standing issue with iPhoto and non-ascii characters. I know of no solution.
    iPhoto menu -> Provide iPhoto Feedback and report it as a bug.
    Regards
    TD

  • Unable to play videos with non-ASCII-characters in filename

    Hi!
    I use a MediaPlayer to display MP4-videos in my application. This works quite well. Unfortunately I have a problem if the filename of the video to be shown contains non-ASCII-charcaters.
    I get the following message:
    -->file:D:\daten\avi\��� ����.MPG
    Error: Unable to realize com.sun.media.amovie.AMController@4b7651
    Failed to realizeThe first line shows the filename I pass to the setMediaLocation()-method of the MediaPlayer-object.
    What's wrong? If I rename the file to ABC.mpg it works fine.
    Thanks for your help
    Thomas

    Hi!
    I use a MediaPlayer to display MP4-videos in my application. This works quite well. Unfortunately I have a problem if the filename of the video to be shown contains non-ASCII-charcaters.
    I get the following message:
    -->file:D:\daten\avi\��� ����.MPG
    Error: Unable to realize com.sun.media.amovie.AMController@4b7651
    Failed to realizeThe first line shows the filename I pass to the setMediaLocation()-method of the MediaPlayer-object.
    What's wrong? If I rename the file to ABC.mpg it works fine.
    Thanks for your help
    Thomas

  • Cannot rename file with non-ASCII characters when using the

    My application moves files from one directory to another by calling File[] srcFiles = srcDir.listFiles() to get a list of files in the source directory, and then calling srcFiles.renameTo(destFile) to rename each file.
    This does not work (renameTo returns false and the file is not moved) under the following circumstances:
    - the file's leaf name contains non-ASCII characters, for example "�"
    - the OS is Solaris 9
    - the LANG and LC_* environment variables are unset, i.e. the C locale is being used
    If I set the LANG environment variable to, for example, en_GB.UTF-8 then the rename succeeds.
    I have tried calling srcFiles[index].getName().getBytes("UTF-8") and the non-ASCII characters are being replaced with ? (0x3f) characters when LANG is unset.
    Is this a bug in the JRE? I would argue that since my code does not actually manipulate the filename (I just use the File object that File.listFiles() gives me) then the rename should succeed. Of course I would not expect the file name to be displayed correctly if I printed it out.
    I have reproduced this behaviour with JDK 1.4.2_05 and 1.5.0_04 on Solaris 9.
    Francis

    Thanks for the info Alan.
    I considered setting the locale in the environment (this sounds like the "correct" fix to me and we might implement it later), but this application shares a WebLogic server with many other applications so we would have to do a huge amount of testing to make sure that the locale change wouldn't break the other apps. In the end I worked around the problem by making the code that generates the filenames in the first place strip out any non-ASCII characters (the names of the files are not critically important).
    Looking forward to JSR-203, in the meantime perhaps a note about this behaviour in the java.io.File javadoc would be useful.

  • Problem with non-ASCII file name in content disposition header

    Hi All,
    I am facing some problems with the non-ASCII file name incase of content-disposition header. I read from the RFC 2183 that if the file name contains non-ASCII characters then the same should be encoded before sending to browser. I did the same but realized 2 problems:
    1. The name of the file is truncated in case the file name is slightly long for e.g. �����������j�b�g��������������������������.txt
    2. Also when the same file is opened in notepad, the title is showing encoded name %E6%9C%80%E4%B8%8A%E4%BD%8D.....
    Overall, I feel that the browser is not understanding or responding to the encoded header values.
    Is there any solution to this problem? I am using Microsoft IE 6.0.
    The code snippet is given below:
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
              String fileName = "�����������j�b�g��������������������������.txt";          
              fileName = URLEncoder.encode(fileName, "UTF-8");
              resp.setCharacterEncoding("UTF-8");
              resp.setHeader("Content-Disposition", "attachment; filename=\"" + fileName + "\"");
              resp.setContentType("application/download-binary");
              String s = "This is inside txt file";
              resp.getOutputStream().write(s.getBytes("UTF-8"));
              return;
         }Any help or pointer would be highly appreciated.
    Thanks and Regards,
    Ashish

    The MIME standards for non-ASCII filenames are not widely implemented.
    Many mailers use an ad hoc method for encoding filenames. JavaMail
    supports both methods, but you need to set properties, such as the
    mail.mime.encodefilename property. See the JavaMail javadocs for
    the javax.mail.internet package.

  • File upload with non-ascii name

    I'm designing a system that includes file-uploads. My problem is that any non-ascii chars in the filename are encoded strangely when saved. &auml; is encoded to a&#778; etc.
    I use Tomcat with the -Dfile.encoding="UTF-8" in the Catalina file. I get the same result despite method; my own implementation, apache commons or Javazoom's uploadBean. All the JSP charset parameters are set.
    Any ideas?

    Hi amitads,
    I'm sure u've used Java enough. Also, u must have learned about the \ (backslash) escape character ?
    So, if u want to include a string like a single quote, u can write \' and for a double quote u can write \".
    Try this ... I'm sure it will help.
    Keep me posted.
    Cheers !!
    Sherbir.

  • Sending mail from servers with non-ASCII names

    As part of an effort to internationalize our product we're testing on machines with host names that include non-ASCII characters (accented e's and whatnot). When trying to send mail from these machines we're getting:
    javax.mail.MessagingException: 501 5.5.4 Invalid Address
    at com.sun.mail.smtp.SMTPTransport.issueCommand(SMTPTransport.java:1634)
    at com.sun.mail.smtp.SMTPTransport.helo(SMTPTransport.java:1068)
    at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:458)
    at javax.mail.Service.connect(Service.java:291)
    at javax.mail.Service.connect(Service.java:172)
    at javax.mail.Service.connect(Service.java:121)
    at javax.mail.Transport.send0(Transport.java:190)
    at javax.mail.Transport.send(Transport.java:120)
    at msgsendsample.main(msgsendsample.java:86)
    Looking at a network trace I see the EHLO command being sent as
    EHLO test[0xe9][0xdf]\r\n
    where the machine name is testéß. From a Unicode table 0xe9 0xdf = é ß.
    I found a reference from RFC 5336 (SMTP Extension for Internationalized Email Addresses) that says the hostname in the EHLO must be in the form of ACE (ASCII-compatible encoding) labels:
    3.7.1. The Initial SMTP Exchange
    When an SMTP connection is opened, the server normally sends a
    "greeting" response consisting of the 220 response code and some
    information. The client then sends the EHLO command. Since the
    client cannot know whether the server supports UTF8SMTP until after
    it receives the response from EHLO, any domain names that appear in
    this dialogue, or in responses to EHLO, MUST be in the hostname form,
    i.e., internationalized ones MUST be in the form of ACE labels.
    ACE encoding for my machine would be: java.net.IDN.toASCII("test4éß") --> "xn--testss-eva".
    I'm not sure if this RFC applies in this case - I didn't know anything about the guts of SMTP until yesterday - but it makes sense that you'd need to escape the hostname in the EHLO until you can negotiate capabilities.
    Looking at the JavaMail API it seems that if I were to call SMTPTransport.helo(String domain) myself without going through the higher-level Transport class that maybe I could work around the issue, but I haven't looked into it enough to know if that's feasible.
    Is anyone familiar with this problem? I'm using JavaMail 1.4.2 on Windows 2003 and Exchange as my SMTP server.
    thanks,
    Eric

    Same problem here (or at least in part). Some .mac folders did no longer show any messages, while they were there and could be seen online and with Thunderbird. After your remark I changed the name of a folder which contained a "´" and now it works. It is really strange because there is another folder with a "¨" in it which does not work (I will test if the name change works with this folder as well in a minute) whilst there is another one with such name which works fine. The update really messed up Mail and in Dutch we just use such characters so Mail without supporting them will be rather useless for me...

  • JavaMail with non-ascii file name attachment.

    Hello,
    I add a file to the mail, which file name is a Chinese name. After I sent it and receive in other email client (M$outlook), it could not display the correct file name for the attachment file.
    How can solve this ?

    The MIME standards for non-ASCII filenames are not widely implemented.
    Many mailers use an ad hoc method for encoding filenames. JavaMail
    supports both methods, but you need to set properties, such as the
    mail.mime.encodefilename property. See the JavaMail javadocs for
    the javax.mail.internet package.

  • Filenames with non-latin characters aren't found by the filesystem [S]

    This might be a bug, but I'm hoping it's just a config file problem.
    I have a few files here and there on my NTFS drive that have Japanese characters in their filenames.  Sometime recently (I don't have an exact date when they disappeared), they stopped showing up at all.  If I browse to a folder that used to contain filenames with Japanese characters, it just appears empty in Gnome.  Using ls from a terminal also says the directory is empty.  They used to work just fine, but a recent upgrade must have broken them.
    Does anyone have any ideas what I can do to get my files to appear again?  Is there some way to enable unicode support for filenames or something?
    Many thanks!
    Edit: Rebooting the system fixed it, though I still think that was a pretty strange problem.  Any ideas what was up?
    Last edited by ColdPie (2007-11-11 02:07:11)

    The funny thing is that bold font [when message unread in message list] shows OK, ie in greek, but when i click on unread message, it is assumed to have been read, so it changes over to medium [non bold] and the encoding changes as well into the one that is not greek and thus unreadable.  In ~/.sylpheed/sylpheedrc the fonts are:
    widget_font=
    message_font=-microsoft-sylfaenarm-medium-r-normal-*-*-160-*-*-p-*-iso8859-7
    normal_font=-monotype-arial-medium-r-normal-*-12-*-*-*-*-*-iso8859-7
    bold_font=-monotype-arial-bold-r-normal-*-12-*-*-*-*-*-iso8859-7
    small_font=-monotype-arial-medium-r-normal-*-12-*-*-*-*-*-iso8859-7
    In /etc/gtk, for gtk1.2 apps the file refering to greek encoding [el] seems to be fine [exactly the same as in slackware 9.1].

  • Cannot connect to WPA network with non-ascii password

    In my office somebody thought it would be a good idea to encrypt the wireless network with a WPA password containing a non-ascii character. It is fine by the WPA2 standards, but the airport password prompt doesn't allow me to introduce suche characters.
    I have also tried to put the password directly in Keychain but it didn't work either. Besides, I tried the /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resourc es/airport utility and it also didn't work.
    Any ideas, experiences, comments??
    Thanks a lot

    Anyway, it seems strange to me this limitation the Apple airport utility and that there is no command line way to overcome this "UI problem".
    It appears that OSX is enforcing WPA Personal's "no non-ASCII" rule, whereas Windows isn't.
    There may be a command-line fix, but I don't know what it might be.

Maybe you are looking for