New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 903664 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 13
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Zip Archiver: Japanese file names appear garbled in ZIP created by macOS

Project Member Reported by yamaguchi@chromium.org, Nov 9

Issue description

Chrome Version: 72.0.3605.0
Chrome OS Version: not relevant
Chrome OS Platform: not relevant
Network info: not relevant

Steps To Reproduce:
(1) on macOS, create some files containing Japanese characters in its file name.
(2) compress the files using the "Compress" command in Finder. Copy created ZIP file to your Chrome OS device.
(3) on Chrome OS, open the file in the Files app.

Expected Result:
File names appear similar to the original.

Actual Result:
All Japanese file names and folder names appear garbled.
For example, "ÉVé╡éóâeâLâXâg âhâLâàâüâôâg.txt" instead of "新規テキスト ドキュメント.txt". Similar to  Issue 834544 .

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
Always

What is the impact to the user, and is there a workaround? If so, what is
it?
Users cannot read the file names.
Users can read contents of the files.
Note that unlike  Issue 834544 , user can still access subdirectories inside the ZIP.

I think this is happening since M68, when we introduced a fix to avoid that some type of ZIP files appear empty. See  Issue 834544 .
 
Cc: amistry@chromium.org
Components: Platform>Apps>FileManager
This happens because the archive contains UTF-8 file name but the language encoding flag is set to "CP437".
Zip 3.0 (Linux)
00000000  50 4b 03 04 0a 00 00 08  00 00 32 66 69 4d 0c 28  |PK........2fiM.(|
                            ^^^^^ (bit 11; language encoding flag "UTF-8")
Mac OS 10.13.6
00000000  50 4b 03 04 14 00 08 00  08 00 32 66 69 4d 00 00  |PK........2fiM..|
                            ^^^^^ (bit 3 is data descriptor type, not relevant)

Attached an example archive.
MacArchive.zip
649 bytes Download

Comment 3 Deleted

Thank you for keeping us in the loop.
Cc: soushi@chromium.org
Status: Started (was: Untriaged)
Can we just extend the encoding detection to include UTF-8?
Yes, I am going to fix this in that way.
https://chromium-review.googlesource.com/c/chromium/src/+/1328623
I think it worth doing because it also affects other languages than Japanese.
Project Member

Comment 9 by bugdroid1@chromium.org, Nov 12

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/38242dea8f2479b7d5f460b78bf5a11eab12949c

commit 38242dea8f2479b7d5f460b78bf5a11eab12949c
Author: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Date: Mon Nov 12 04:24:36 2018

Zip Archiver: Allow to auto-detect UTF-8 file name when EFS is 0.

We saw a ZIP file created on macOS stores file names in UTF-8 encoding
but the language encoding flag in the general purpose bit is not set.
This change will cover some of such cases when the encoding detector
detected that encoding.

Bug:  903664 
Test: browser_tests --gtest_filter=ZipFiles/FilesAppBrowserTest.Test/*
Test: manually verified using the ZIP attached to the bug
Change-Id: I5ef488cf5a0ba04feee9e8d2025054e16785f832
Reviewed-on: https://chromium-review.googlesource.com/c/1328623
Reviewed-by: Anand Mistry <amistry@chromium.org>
Commit-Queue: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607141}
[modify] https://crrev.com/38242dea8f2479b7d5f460b78bf5a11eab12949c/chrome/browser/chromeos/file_manager/file_manager_browsertest.cc
[modify] https://crrev.com/38242dea8f2479b7d5f460b78bf5a11eab12949c/chrome/browser/resources/chromeos/zip_archiver/js/volume.js
[add] https://crrev.com/38242dea8f2479b7d5f460b78bf5a11eab12949c/chrome/test/data/chromeos/file_manager/archive_macos.zip
[modify] https://crrev.com/38242dea8f2479b7d5f460b78bf5a11eab12949c/ui/file_manager/integration_tests/file_manager/zip_files.js
[modify] https://crrev.com/38242dea8f2479b7d5f460b78bf5a11eab12949c/ui/file_manager/integration_tests/test_util.js

Labels: Merge-Request-71
Project Member

Comment 11 by sheriffbot@chromium.org, Nov 13

Labels: -Merge-Request-71 Hotlist-Merge-Reject Merge-Reject-71
The bug is marked as P3 or Feature. It should not be merged as M71 is in beta. 
Please contact the approriate milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Pri-3 M-72 Pri-2
Status: Fixed (was: Started)
I think this should actually be P2, because this is an existing logical bug with an existing feature. Additinoally, the change is relatively simple.
However we can punt this to M72 considering the release schedule.

Sign in to add a comment