Fix the local directory listing, FTP directory listing and the local file handling (drag'n'drop and opening from the file list).

For the local file listing, use the OS file system encoding. 

For the FTP directory listing, use ICU's encoding detector.GetDirectoryListingEntry and GetDirectoryLisingHeader were changed to accept string16 for file/directory names. To the former, a new parameter (|raw_bytes|) was added. It can be used to make a FTP request to a file with a non-ASCII name encoded in a legacy encoding.

For the local file handling on Windows, get rid of the code for 'doubly converted' UTF-8 in FileURLToFilePath, which led to issue 4619 and add a few cases to NetUtil*.FileURLConversion* test.

In addition, add
CodepageToUTF16 and UTF16ToCodepage along with a new unittest (ConvertBetweenCodepageAndUTF16) that shares the same set of case as ConvertBetweenCodepageAndWide. The test cases were expanded and revised a bit. 


BUG=2939,13229,4619     
    http://crbug.com/2939  http://crbug.com/13229 http://crbug.com/4619

TEST=1. Pass URLRequest*.FTP* (net_unittests)
     2. Pass StringUtiltTest.ConvertBetweenCode*
     3. Pass NetUtil*.GetDirectoryLis* (net_unittests)     
     4. Open a local directory containing files with non-ASCII names and they're displayed correctly in the directory list. On Windows and Mac OS X, it should always work. On Linux, your locale encoding (as returned by nl_langinfo(CODESET)) should match the actual encoding used in your filename. 
     5a. Pass NetUtil*.FileURL* (net_unittests) with the default codepage set to 1252 and 932. 
     5b. Make a file named 'caf챕.txt' on Windows and see if it can be opened both by clicking in the directory listing page of Chrome and by drag'n'drop. Test this with the default OS code pages set to Windows-1252, Windows-1251 (Russian) and Windows-932 (Japanese). 
Review URL: http://codereview.chromium.org/151065

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20331 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 7 insertions, 27 deletions

diff --git a/net/base/net_util_win.cc b/net/base/net_util_win.cc
index effb212..244f4ad 100644
--- a/net/base/net_util_win.cc
+++ b/net/base/net_util_win.cc
@@ -57,33 +57,13 @@ bool FileURLToFilePath(const GURL& url, FilePath* file_path) {
   }
   file_path_str.assign(UTF8ToWide(path));
 
-  // Now we have an unescaped filename, but are still not sure about its
-  // encoding. For example, each character could be part of a UTF-8 string.
-  if (file_path_str.empty() || !IsString8Bit(file_path_str)) {
-    // assume our 16-bit encoding is correct if it won't fit into an 8-bit
-    // string
-    return true;
-  }
-
-  // Convert our narrow string into the native wide path.
-  std::string narrow;
-  if (!WideToLatin1(file_path_str, &narrow)) {
-    NOTREACHED() << "Should have filtered out non-8-bit strings above.";
-    return false;
-  }
-  if (IsStringUTF8(narrow)) {
-    // Our string actually looks like it could be UTF-8, convert to 8-bit
-    // UTF-8 and then to the corresponding wide string.
-    file_path_str = UTF8ToWide(narrow);
-  } else {
-    // Our wide string contains only 8-bit characters and it's not UTF-8, so
-    // we assume it's in the native codepage.
-    file_path_str = base::SysNativeMBToWide(narrow);
-  }
-
-  // Fail if 8-bit -> wide conversion failed and gave us an empty string back
-  // (we already filtered out empty strings above).
-  return !file_path_str.empty();
+  // We used to try too hard and see if |path| made up entirely of
+  // the 1st 256 characters in the Unicode was a zero-extended UTF-16.
+  // If so, we converted it to 'Latin-1' and checked if the result was UTF-8.
+  // If the check passed, we converted the result to UTF-8.
+  // Otherwise, we treated the result as the native OS encoding.
+  // However, that led to http://crbug.com/4619 and http://crbug.com/14153
+  return true;
 }
 
 }  // namespace net