MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-974

nls: fileDownloadActionListener : mulitibyte char filename is garbled

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.6-core, 1.2.6-core
    • Fix Version/s: 1.2.10-core, 1.0.10-core
    • Component/s: None
    • Labels:
      None

      Description

      A simple reproducible testcase is to use the
      fileDownloadActionListener.jspx demo and change the filename to be japanese
      or chinese characters and also change your browser's language accordingly.

      On Firefox, it appears fine.
      On IE, the filename is garbled.

      1. trunk.patch
        10 kB
        Kenneth tang
      2. patchAfterReview.patch
        11 kB
        Jeanne Waldman
      3. filedownload.jspx
        0.5 kB
        Kenneth tang

        Activity

        Hide
        Kenneth tang added a comment -

        IE and Firefox demands different encoding behavior on filename in content-disposition header.
        IE : URL encoded using UTF-8
        FF : RFC2047 (I tested it using UTF-8 and quoted-printable)

        As JSF and Trinidad does not depend on Javamail, we may need to add a local copy of MIME encode function into Trinidad.

        Please note on two known issues:

        1. FF does not work well with open file
        Tested using FF 2.0.0.12. Using the proposed behavior above,

        • it works well with "save as", the non-ascii filename can be saved to file system successfully
        • however, open does not work still.

        2. IE has a short length limit. The total length, including the temp directory path + encoded filename, cannot be longer than around 290 bytes. Considering UTF-8 URL encoding is used here, for example one Chinese character will be encoded using 9 bytes... So some calculation here...
        Default temp directory path = C:\Documents and Settings\<username>\Local Settings\Temporary Internet Files\, it my own env, it takes 80 bytes already.
        290-80/9 ~ 23 Chinese characters max
        To make this better, we may use the client side file system encoding to native encode the filename in header, for example, using windows-1252. However, there is no easy way to detect this.

        Show
        Kenneth tang added a comment - IE and Firefox demands different encoding behavior on filename in content-disposition header. IE : URL encoded using UTF-8 FF : RFC2047 (I tested it using UTF-8 and quoted-printable) As JSF and Trinidad does not depend on Javamail, we may need to add a local copy of MIME encode function into Trinidad. Please note on two known issues: 1. FF does not work well with open file Tested using FF 2.0.0.12. Using the proposed behavior above, it works well with "save as", the non-ascii filename can be saved to file system successfully however, open does not work still. 2. IE has a short length limit. The total length, including the temp directory path + encoded filename, cannot be longer than around 290 bytes. Considering UTF-8 URL encoding is used here, for example one Chinese character will be encoded using 9 bytes... So some calculation here... Default temp directory path = C:\Documents and Settings\<username>\Local Settings\Temporary Internet Files\, it my own env, it takes 80 bytes already. 290-80/9 ~ 23 Chinese characters max To make this better, we may use the client side file system encoding to native encode the filename in header, for example, using windows-1252. However, there is no easy way to detect this.
        Hide
        Matthias Weßendorf added a comment -

        what has this to do with Javamail?
        I don't get that reference

        Show
        Matthias Weßendorf added a comment - what has this to do with Javamail? I don't get that reference
        Hide
        Kenneth tang added a comment -

        MIMEUtility does not come with JRE, but only part of Javamail API.
        To mime encode file name for FF, we need a local copy of the required encodeWord() method.
        Thanks

        Show
        Kenneth tang added a comment - MIMEUtility does not come with JRE, but only part of Javamail API. To mime encode file name for FF, we need a local copy of the required encodeWord() method. Thanks
        Hide
        Kenneth tang added a comment -

        to workaround the content-disposition encoding issues with IE and FF, added a public static method encodeFileName() to RenderUtils.

        • when isIE=true, returns UTF-8 URL encoded filename
        • when isIE=false, returns RFC2047 (MIME) encoded filename, using UTF-8 and Quoted-printable.

        Also fixed fileDownloadActionListener at the same time.

        Show
        Kenneth tang added a comment - to workaround the content-disposition encoding issues with IE and FF, added a public static method encodeFileName() to RenderUtils. when isIE=true, returns UTF-8 URL encoded filename when isIE=false, returns RFC2047 (MIME) encoded filename, using UTF-8 and Quoted-printable. Also fixed fileDownloadActionListener at the same time.
        Hide
        Kenneth tang added a comment -

        updated patch file to follow Trinidad coding style/standards.

        Show
        Kenneth tang added a comment - updated patch file to follow Trinidad coding style/standards.
        Hide
        Kenneth tang added a comment -

        a new patch is available.
        Two public methods are added to RenderUtil

        1. public static String encodeFileName(String filename, boolean isIE)
        this is an utility method to fix the download file name problem

        2. public static final String encodeWord(String string, String charset, String tEncoding,
        boolean isWord, boolean bfold)
        this is a general rfc2047 encoder method, to be used in Firefox case. This can be used in future such as email related functionalities.

        Show
        Kenneth tang added a comment - a new patch is available. Two public methods are added to RenderUtil 1. public static String encodeFileName(String filename, boolean isIE) this is an utility method to fix the download file name problem 2. public static final String encodeWord(String string, String charset, String tEncoding, boolean isWord, boolean bfold) this is a general rfc2047 encoder method, to be used in Firefox case. This can be used in future such as email related functionalities.
        Hide
        Kenneth tang added a comment -

        new patch with based on trunk_1.2.x.
        confirmed to be working with IE7 and FF2.

        Show
        Kenneth tang added a comment - new patch with based on trunk_1.2.x. confirmed to be working with IE7 and FF2.
        Hide
        Kenneth tang added a comment -

        this is the Chinese testcase used for verification.

        Show
        Kenneth tang added a comment - this is the Chinese testcase used for verification.
        Hide
        Jeanne Waldman added a comment -

        This is after my review. Minor changes like comments and alignment of code. This is what I'm committing.

        Show
        Jeanne Waldman added a comment - This is after my review. Minor changes like comments and alignment of code. This is what I'm committing.
        Hide
        Jeanne Waldman added a comment -

        Completed: At revision: 647929
        on trunk_1.2.x branch

        Show
        Jeanne Waldman added a comment - Completed: At revision: 647929 on trunk_1.2.x branch
        Hide
        Jeanne Waldman added a comment -

        This works in Trinidad1.2 branch, but for some reason it doesn't work in trunk. But there is no JSF 1.2-specific code, so I don't know why. I'll consult with Kenneth before I check in to trunk.

        Show
        Jeanne Waldman added a comment - This works in Trinidad1.2 branch, but for some reason it doesn't work in trunk. But there is no JSF 1.2-specific code, so I don't know why. I'll consult with Kenneth before I check in to trunk.
        Hide
        Jeanne Waldman added a comment -

        I should note that in trinidad's 1.2.x branch, I use JDeveloper 11g. In trunk, I use JDeveloper 10.1.3. That's my best guess as to why there is a difference.

        Show
        Jeanne Waldman added a comment - I should note that in trinidad's 1.2.x branch, I use JDeveloper 11g. In trunk, I use JDeveloper 10.1.3. That's my best guess as to why there is a difference.
        Hide
        Jeanne Waldman added a comment -

        the demo I was trying in trunk had
        <?xml version="1.0" encoding="iso-8859-1"?>
        instead of
        <?xml version="1.0" encoding="utf-8"?>

        and that was the difference.
        It works with <?xml version="1.0" encoding="utf-8"?> as the first line in the .jspx demo file.

        Show
        Jeanne Waldman added a comment - the demo I was trying in trunk had <?xml version="1.0" encoding="iso-8859-1"?> instead of <?xml version="1.0" encoding="utf-8"?> and that was the difference. It works with <?xml version="1.0" encoding="utf-8"?> as the first line in the .jspx demo file.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jeanne Waldman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development