--- Junio C Hamano <junkio@xxxxxxx> wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>
> > Junio C Hamano wrote:
> >
> >> Luben Tuikov <ltuikov@xxxxxxxxx> writes:
> >>
> >>>>> +# Convert a string (e.g. a filename) into qtext as defined
> >>>>> +# in RFC 822, from RFC 2183. To be used by Content-Disposition.
> >>>>> +sub to_qtext {
> >>>>> + my $str = shift;
> >>>>> + $str =~ s/\\/\\\\/g;
> >>>>> + $str =~ s/\"/\\\"/g;
> >
> > Here probably it could be
> > $str =~ s/"/\\"/g;
> >
> >>>>> + $str =~ s/\r/\\r/g;
> >>>>
> >>>> \r? Not \n?
> >>>
> >>> Yes, \r, not \n.
> >>
> >> \r to \\r? Not to \\\r?
> >
> > We want "\r" in suggested filename, not "\
> > " I think, so it is "\\r".
>
> Is that what you guys are attempting to achieve?
I think so.
> If we are trying to suggest a filename that is safe by avoiding
> certain characters, I suspect leaving a backslash and dq as-is
> is just as bad as leaving a CR in. So if that is the goal here,
> I think it might be better and a lot simpler to just replace
> each run of bytes not in Portable Filename Character Set with an
> underscore '_'.
I think that if I were to download a file which had those chars
in it, I'd like to at least be able to see the _intention_ of what
chars the actual file name had.
So if I download a filename which looks like this:
This is a \" test \" file \\.\r
Then I know that the intention had been:
This is a " test " file \.<CR>
It becomes an intention, since it needs to be carried over
a qtext.
Luben
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html