Yeah, fixing the module to allow a file handle to be given instead of just a file name is quite in line with the trivial work that I noted might be required.

Though, I suspect that Perl provides a way for declaring a default encoding for all file handles, perhaps related to "locale" settings. So I'm not even convinced that your objection is even technically correct. (Though, if Perl does not provide such a feature, perhaps you should look into providing one, IMHO. :)

I'm actually a bit surprised that open does not already support (according to my recent scanning of the documentation):

    open my $fh, '<:encoding(UTF-8) foo.csv'
[download]

which would have also been a route that would have worked with the unchanged Text::xSV.

but he did have to think about proving a means of providing decoded input

No, the author didn't have to think about that. The author just needed to allow a file handle to be given, even if the reason for allowing such had nothing to do with the author thinking about decoded input. I very often support taking a filehandle not just a filename, and very rarely is that due to me having thought about encodings.

Though, I suspect that Perl provides a way for declaring a default encoding for all file handles,

There's use open, but it's lexically scoped.

perlrun seems to indicate that -Ci makes your original nit technically incorrect. Though, the phrase "in the current file scope" (which is not present in my copy) calls into question this implication that seems to be clearly made more than once away from that phrase (and indicates the possibility of a rather bizarre effect for that command-line switch).

I don't find evidence of support for globally imposing a default non-UTF-8 encoding on streams. I find that a surprising lack and have seen others express similar surprise more forcefully.

- tye