Why should I assume that my console is using UTF-8?
Sure, that's a valid point. But then again, if someone is going to be writing Unicode data to the console in the first place, what encoding should they use? If this is a tool in a UNIX command pipeline, UTF-8 seems fine to me, it can be piped to iconv, or one can add a command-line option to change the output encoding if desired. What the best way is depends on the situation; my point was just a response to your apparent complaint about the warning from Perl.
But most importantly, if you automatically open all files in UTF-8, then you'll have serious limitations.
You can override the default by explicitly specifying an encoding in open.
What if you do want to check for UTF-8 encoding errors?
use warnings FATAL => 'utf8'; - people also add this to their boilerplate for that reason. (Update: I've added it to my boilerplate above.)
What if your file mixes binary and UTF-8?
In that case you'd have to fiddle with binmode or a manual decode anyway, no matter what the default encoding is.
File::Spec is a disaster.
It does have its faults, but in general, I disagree - in my experience it's much more common for people to put bugs in their code* via their reinvented wheel filename handling. But anyway, its canonpath removes a trailing slash. Of course, if you're certain your script will only run on POSIX systems, you can just use a regex to strip the trailing slash.
* Update 2: Or at least make their code less portable. Also, note the module's canonpath does collapse "/a///b/" to "/a/b".
In reply to Re^5: substr on UTF-8 strings
by haukex
in thread substr on UTF-8 strings
by rdiez
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |