[Bug 1199239] Re: unzip list utf-8 (non-ascii) filenames as ??

[Ma Xiaojun]

** Description changed:

- Despite notorious LP #580961 , the biggest issue of current unzip is
- that it always list non-ASCII file name character as question mark (?) .
+ [Impact]
+ Despite notorious LP #580961 , the biggest issue of current unzip is that it always list non-ASCII file name character as question mark (?) .
  
  Even though handling Zip archives with non-standard encoding (neither
  CP437 nor UTF-8) can be tricky, we should support UTF-8 Zip archives out
  of the box as it's become more and more popular now.
  
  Newer version of unzip in Debian and Ubuntu (13.10+) fixed the issue by
- change build configuration already. The fix is visible to File Roller
- and Ark also. The issue remains in 12.04 - 13.04 currently.
+ changing build configuration already. The fix is visible to File Roller
+ and Ark also.
  
- Note that Ark is the better frontend software for testing, as it seems
- to use unzip backend exclusively. File roller, on the other hand, will
- use 7z backend when 7z exists, so the issue can magically disappear some
- time.
+ The issue remains in 12.04 - 13.04 currently. We need to apply the same
+ fix for them.
+ 
+ [Test Case]
+ cat naïve.txt
+ touch naïve.txt
+ touch 天真.txt
+ zip test.zip naïve.txt 天真.txt 
+ zipinfo test.zip 
+ ark test.zip 
+ file-roller test.zip
+ 
+ [Regression Potential] 
+ Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive same effect).
+ 
+ [Other Info]
+ Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly).

** Summary changed:

- unzip list utf-8 (non-ascii) filenames as ??
+ [SRU] unzip list utf-8 (non-ascii) filenames as ??

** Description changed:

  [Impact]
  Despite notorious LP #580961 , the biggest issue of current unzip is that it always list non-ASCII file name character as question mark (?) .
  
  Even though handling Zip archives with non-standard encoding (neither
  CP437 nor UTF-8) can be tricky, we should support UTF-8 Zip archives out
  of the box as it's become more and more popular now.
  
  Newer version of unzip in Debian and Ubuntu (13.10+) fixed the issue by
  changing build configuration already. The fix is visible to File Roller
  and Ark also.
  
  The issue remains in 12.04 - 13.04 currently. We need to apply the same
  fix for them.
  
  [Test Case]
  cat naïve.txt
  touch naïve.txt
  touch 天真.txt
- zip test.zip naïve.txt 天真.txt 
- zipinfo test.zip 
- ark test.zip 
- file-roller test.zip
+ zip test.zip naïve.txt 天真.txt
+ zipinfo test.zip
+ ark test.zip
+ file-roller test.zip # the result may be different see notes below
  
- [Regression Potential] 
- Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive same effect).
+ [Regression Potential]
+ Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive exactly same effect).
  
  [Other Info]
- Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly).
+ Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly). 7z isn't included on the ISO, though.

** Description changed:

  [Impact]
  Despite notorious LP #580961 , the biggest issue of current unzip is that it always list non-ASCII file name character as question mark (?) .
  
  Even though handling Zip archives with non-standard encoding (neither
  CP437 nor UTF-8) can be tricky, we should support UTF-8 Zip archives out
- of the box as it's become more and more popular now.
+ of the box as it's the standard and it become more and more popular now.
  
  Newer version of unzip in Debian and Ubuntu (13.10+) fixed the issue by
  changing build configuration already. The fix is visible to File Roller
  and Ark also.
  
  The issue remains in 12.04 - 13.04 currently. We need to apply the same
  fix for them.
  
  [Test Case]
  cat naïve.txt
  touch naïve.txt
  touch 天真.txt
  zip test.zip naïve.txt 天真.txt
  zipinfo test.zip
  ark test.zip
  file-roller test.zip # the result may be different see notes below
  
  [Regression Potential]
  Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive exactly same effect).
  
  [Other Info]
  Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly). 7z isn't included on the ISO, though.

** Tags removed: patch

** Description changed:

  [Impact]
  Despite notorious LP #580961 , the biggest issue of current unzip is that it always list non-ASCII file name character as question mark (?) .
  
  Even though handling Zip archives with non-standard encoding (neither
  CP437 nor UTF-8) can be tricky, we should support UTF-8 Zip archives out
  of the box as it's the standard and it become more and more popular now.
  
  Newer version of unzip in Debian and Ubuntu (13.10+) fixed the issue by
  changing build configuration already. The fix is visible to File Roller
  and Ark also.
  
  The issue remains in 12.04 - 13.04 currently. We need to apply the same
  fix for them.
  
  [Test Case]
- cat naïve.txt
  touch naïve.txt
  touch 天真.txt
  zip test.zip naïve.txt 天真.txt
  zipinfo test.zip
  ark test.zip
  file-roller test.zip # the result may be different see notes below
  
  [Regression Potential]
  Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive exactly same effect).
  
  [Other Info]
  Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly). 7z isn't included on the ISO, though.

** Description changed:

  [Impact]
  Despite notorious LP #580961 , the biggest issue of current unzip is that it always list non-ASCII file name character as question mark (?) .
  
  Even though handling Zip archives with non-standard encoding (neither
  CP437 nor UTF-8) can be tricky, we should support UTF-8 Zip archives out
  of the box as it's the standard and it become more and more popular now.
  
  Newer version of unzip in Debian and Ubuntu (13.10+) fixed the issue by
  changing build configuration already. The fix is visible to File Roller
  and Ark also.
  
  The issue remains in 12.04 - 13.04 currently. We need to apply the same
  fix for them.
  
  [Test Case]
  touch naïve.txt
  touch 天真.txt
  zip test.zip naïve.txt 天真.txt
- zipinfo test.zip
+ unzip -l test.zip
  ark test.zip
  file-roller test.zip # the result may be different see notes below
  
  [Regression Potential]
  Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive exactly same effect).
  
  [Other Info]
  Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly). 7z isn't included on the ISO, though.

** Description changed:

  [Impact]
  Despite notorious LP #580961 , the biggest issue of current unzip is that it always list non-ASCII file name character as question mark (?) .
  
  Even though handling Zip archives with non-standard encoding (neither
  CP437 nor UTF-8) can be tricky, we should support UTF-8 Zip archives out
  of the box as it's the standard and it become more and more popular now.
  
  Newer version of unzip in Debian and Ubuntu (13.10+) fixed the issue by
  changing build configuration already. The fix is visible to File Roller
  and Ark also.
  
  The issue remains in 12.04 - 13.04 currently. We need to apply the same
  fix for them.
  
  [Test Case]
  touch naïve.txt
  touch 天真.txt
  zip test.zip naïve.txt 天真.txt
  unzip -l test.zip
  ark test.zip
  file-roller test.zip # the result may be different see notes below
  
  [Regression Potential]
- Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive exactly same effect).
+ Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive exactly same effect) already.
  
  [Other Info]
  Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly). 7z isn't included on the ISO, though.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to unzip in Ubuntu.
https://bugs.launchpad.net/bugs/1199239

Title:
  [SRU] unzip list utf-8 (non-ascii) filenames as ??

Status in “unzip” package in Ubuntu:
  Confirmed

Bug description:
  [Impact]
  Despite notorious LP #580961 , the biggest issue of current unzip is that it always list non-ASCII file name character as question mark (?) .

  Even though handling Zip archives with non-standard encoding (neither
  CP437 nor UTF-8) can be tricky, we should support UTF-8 Zip archives
  out of the box as it's the standard and it become more and more
  popular now.

  Newer version of unzip in Debian and Ubuntu (13.10+) fixed the issue
  by changing build configuration already. The fix is visible to File
  Roller and Ark also.

  The issue remains in 12.04 - 13.04 currently. We need to apply the
  same fix for them.

  [Test Case]
  touch naïve.txt
  touch 天真.txt
  zip test.zip naïve.txt 天真.txt
  unzip -l test.zip
  ark test.zip
  file-roller test.zip # the result may be different see notes below

  [Regression Potential]
  Little, if any, as the proposed fix is used by Debian, Ubuntu 13.10+ and openSUSE (using a different approach to archive exactly same effect) already.

  [Other Info]
  Note that Ark is the better frontend software for testing, as it seems to use unzip backend exclusively. File roller, on the other hand, will use 7z backend when 7z exists, so the issue can magically disappear some time (7z support utf8 filenames correctly). 7z isn't included on the ISO, though.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/1199239/+subscriptions