On Sat, Dec 4, 2010 at 6:40 AM, Bjoern Hoehrmann <derhoe...@gmx.net> wrote:
>
> No, as you can tell from the results there is no one way supported by
> all major browsers. The IETF HTTPbis Working Group is currently revising
> the specification for it, and the recommended way to do this will be the
> through the RFC 5987 style notation, where you can also specify a fall-
> back value by using both the filename* and filename parameters. But no
> silver bullet there.
>
Thanks very much for the pointers.
Oh, that RFC says 8859-1 is supported, not just ASCII. So, I suppose I
could encode to 8859-1 and have encode() use an underscore for the
substitution character. But, then do I have to be concerned with removing
any characters that might not be appropriate for their (the client's) file
system? That is, remove slashes?
Maybe I should just stick to something basic like:
$filename = substr( $title, 0, 50 ); # But 78 is allowed
$filename =~ s/[^A-Za-z0-9]/_/g; # Replace
$filename = 'document' unless $filename =~ /[^_]/;
$filename =~ s/^_{2,}/_/; # trim to make less ugly?
$filename =~ s/_{2,}$/_/;
$filename = encode( 'US-ASCII', $filename );
$filename .= '.pdf'; # for example
> As I understand it, Google is currently investigating switching to RFC
> 5987 style encoding in some of their applications.
>
That would require some kind of browser detection, right?
Hopefully, that might all get abstracted out into a HTTP::Headers
method/subclass in the future.
Thanks,
--
Bill Moseley
mose...@hank.org
