bugGNU Wget - Bugs: bug #21793, --restrict-file-names needs more...

 
 

bug #21793: --restrict-file-names needs more flexibility

Submitter:  Micah Cowan <micahcowan>
Submitted:  Thu 13 Dec 2007 06:21:54 PM UTC
   
 
Category:  User Interface Severity:  3 - Normal
Priority:  7 - High Status:  Fixed
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  None Operating System:  None
Reproducibility:  None Fixed Release:  1.12
Planned Release:  1.12 Regression:  None
Work Required:  0 - Hours Patch Included:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 28 Jul 2009 07:24:50 AM UTC, comment #4: 

Fixed in fbdc1f03eb76.

Just added an "ascii" specifier, to force escaping of high-value bytes. "nocontrol" should work in the meantime for when you want the full set of UTF-8 characters in filenames.

Now that we have some locale-awareness, we should work on transcoding names specifically for the locale.

Micah Cowan <micahcowan>
Fri 14 Mar 2008 03:22:04 PM UTC, comment #3: 

Thank you for this patch; however, it's not quite what we're looking for. It's not generally safe to assume UTF-8 characters (or high-bytes in general) are okay; there are still plenty of people who are not using it on their systems. I don't want to break backwards-compatibility, just provide the option for folks.

Also, generally speaking, it's a really good idea if you provide a name and contact info when submitting a patch. If the patch is significant, I can't accept it without a signed copyright disclaimer at the FSF.

Micah Cowan <micahcowan>
Fri 14 Mar 2008 06:34:10 AM UTC, comment #2: 

I made a simple work around patch to assume unicode characters(greater then 0x7F) as safe, afterwards wget doesn't quote them.

(file #15263)

Anonymous
Thu 13 Dec 2007 06:25:28 PM UTC, comment #1: 

I suppose one could also include a --restrict-file-names=utf-8, so that it will allow proper UTF-8 sequences, not escaping values in the 80-9B range, as it currently does. That solves the opposite problem, where the locale is UTF-8 and Wget is escaping for ISO-8859-*; but nocontrol may already suffice for that situation.

Micah Cowan <micahcowan>
Thu 13 Dec 2007 06:21:54 PM UTC, original submission:  

Until more intelligent support is in place for locale-aware filenames, --restrict-file-names needs some better options. There is currently no way to get it to treat UTF-8 URLs properly, when saving to disk, if the user's locale/filesystem doesn't support UTF-8.

--restrict-file-names=ascii would be a handy way to prevent the high bytes from being decoded (it should also still leave certain ASCII-range characters encoded, and should perhaps combine with the "windows" or "unix" options to DTRT).

Alternatively, one could specify a regex-style character group, to specify the allowed and disallowed characters (bytes, rather, until proper i18n support is in place). For instance, you could have --allowed-chars='[:ascii:]', and --disallowed-chars='[:unix:]' (where "unix" means just the Unix path/shell special characters), or --allowed-chars=A-Za-z0-9_.

Micah Cowan <micahcowan>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #15263:  wget.utf8.patch added by None (478B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by micahcowan (Submitted the item)
  •  

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-28 micahcowan StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 1.12
    2008-03-14 None Attached File- Added wget.utf8.patch, #15263
    2007-12-13 micahcowan Priority5 - Normal 7 - High

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code