perlunifaq - Perl Unicode FAQ
-=head1 DESCRIPTION
+=head1 Q and A
This is a list of questions and answers about Unicode in Perl, intended to be
read after L<perlunitut>.
No, and this isn't really a Unicode FAQ.
-Perl has an abstracted interface for all supported character encodings, so they
+Perl has an abstracted interface for all supported character encodings, so this
is actually a generic C<Encode> tutorial and C<Encode> FAQ. But many people
think that Unicode is special and magical, and I didn't want to disappoint
them, so I decided to call the document a Unicode tutorial.
+=head2 What character encodings does Perl support?
+
+To find out which character encodings your Perl supports, run:
+
+ perl -MEncode -le "print for Encode->encodings(':all')"
+
+=head2 Which version of perl should I use?
+
+Well, if you can, upgrade to the most recent, but certainly C<5.8.1> or newer.
+The tutorial and FAQ assume the latest release.
+
+You should also check your modules, and upgrade them if necessary. For example,
+HTML::Entities requires version >= 1.32 to function correctly, even though the
+changelog is silent about this.
+
=head2 What about binary data, like images?
Well, apart from a bare C<binmode $fh>, you shouldn't treat them specially.
appropriate encoding, then join them with binary strings. See also: "What if I
don't encode?".
-=head2 What about the UTF8 flag?
-
-Please, unless you're hacking the internals, or debugging weirdness, don't
-think about the UTF8 flag at all. That means that you very probably shouldn't
-use C<is_utf8>, C<_utf8_on> or C<_utf8_off> at all.
-
-Perl's internal format happens to be UTF-8. Unfortunately, Perl can't keep a
-secret, so everyone knows about this. That is the source of much confusion.
-It's better to pretend that the internal format is some unknown encoding,
-and that you always have to encode and decode explicitly.
-
=head2 When should I decode or encode?
-Whenever you're communicating with anything that is external to your perl
+Whenever you're communicating text with anything that is external to your perl
process, like a database, a text file, a socket, or another program. Even if
the thing you're communicating with is also written in Perl.
You can provide this layer when C<open>ing the file:
- open my $fh, '>:encoding(UTF-8)', $filename; # auto encoding on write
- open my $fh, '<:encoding(UTF-8)', $filename; # auto decoding on read
+ open my $fh, '>:encoding(UTF-8)', $filename; # auto encoding on write
+ open my $fh, '<:encoding(UTF-8)', $filename; # auto decoding on read
Or if you already have an open filehandle:
- binmode $fh, ':encoding(UTF-8)';
+ binmode $fh, ':encoding(UTF-8)';
Some database drivers for DBI can also automatically encode and decode, but
-that is typically limited to the UTF-8 encoding, because they cheat.
-
-=head2 Cheat?! Tell me, how can I cheat?
-
-Well, because Perl's internal format is UTF-8, you can just skip the encoding
-or decoding step, and manipulate the UTF8 flag directly.
-
-Instead of C<:encoding(UTF-8)>, you can simply use C<:utf8>. This is widely
-accepted as good behavior when you're writing, but it can be dangerous when
-reading, because it causes internal inconsistency when you have invalid byte
-sequences.
-
-Instead of C<decode> and C<encode>, you could use C<_utf8_on> and C<_utf8_off>,
-but this is considered bad style. Especially C<_utf8_on> can be dangerous, for
-the same reason that C<:utf8> can.
-
-There are some shortcuts for oneliners; see C<-C> in L<perlrun>.
+that is sometimes limited to the UTF-8 encoding.
=head2 What if I don't know which encoding was used?
If you properly encode your strings for output, none of this is of your
concern, and you can just C<eval> dumped data as always.
+=head2 Why do regex character classes sometimes match only in the ASCII range?
+
+=head2 Why do some characters not uppercase or lowercase correctly?
+
+It seemed like a good idea at the time, to keep the semantics the same for
+standard strings, when Perl got Unicode support. The plan is to fix this
+in the future, and the casing component has in fact mostly been fixed, but we
+have to deal with the fact that Perl treats equal strings differently,
+depending on the internal state.
+
+First the casing. Just put a C<use feature 'unicode_strings'> near the
+beginning of your program. Within its lexical scope, C<uc>, C<lc>, C<ucfirst>,
+C<lcfirst>, and the regular expression escapes C<\U>, C<\L>, C<\u>, C<\l> use
+Unicode semantics for changing case regardless of whether the UTF8 flag is on
+or not. However, if you pass strings to subroutines in modules outside the
+pragma's scope, they currently likely won't behave this way, and you have to
+try one of the solutions below. There is another exception as well: if you
+have furnished your own casing functions to override the default, these will
+not be called unless the UTF8 flag is on)
+
+This remains a problem for the regular expression constructs
+C<\d>, C<\s>, C<\w>, C<\D>, C<\S>, C<\W>, C</.../i>, C<(?i:...)>,
+and C</[[:posix:]]/>.
+
+To force Unicode semantics, you can upgrade the internal representation to
+by doing C<utf8::upgrade($string)>. This can be used
+safely on any string, as it checks and does not change strings that have
+already been upgraded.
+
+For a more detailed discussion, see L<Unicode::Semantics> on CPAN.
+
=head2 How can I determine if a string is a text string or a binary string?
You can't. Some use the UTF8 flag for this, but that's misuse, and makes well
open my $barfh, '>:encoding(BAR)', 'example.bar.txt';
print { $barfh } $_ while <$foofh>;
+=head2 What are C<decode_utf8> and C<encode_utf8>?
+
+These are alternate syntaxes for C<decode('utf8', ...)> and C<encode('utf8',
+...)>.
+
+=head2 What is a "wide character"?
+
+This is a term used both for characters with an ordinal value greater than 127,
+characters with an ordinal value greater than 255, or any character occupying
+more than one byte, depending on the context.
+
+The Perl warning "Wide character in ..." is caused by a character with an
+ordinal value greater than 255. With no specified encoding layer, Perl tries to
+fit things in ISO-8859-1 for backward compatibility reasons. When it can't, it
+emits this warning (if warnings are enabled), and outputs UTF-8 encoded data
+instead.
+
+To avoid this warning and to avoid having different output encodings in a single
+stream, always specify an encoding explicitly, for example with a PerlIO layer:
+
+ binmode STDOUT, ":encoding(UTF-8)";
+
+=head1 INTERNALS
+
+=head2 What is "the UTF8 flag"?
+
+Please, unless you're hacking the internals, or debugging weirdness, don't
+think about the UTF8 flag at all. That means that you very probably shouldn't
+use C<is_utf8>, C<_utf8_on> or C<_utf8_off> at all.
+
+The UTF8 flag, also called SvUTF8, is an internal flag that indicates that the
+current internal representation is UTF-8. Without the flag, it is assumed to be
+ISO-8859-1. Perl converts between these automatically. (Actually Perl usually
+assumes the representation is ASCII; see L</Why do regex character classes
+sometimes match only in the ASCII range?> above.)
+
+One of Perl's internal formats happens to be UTF-8. Unfortunately, Perl can't
+keep a secret, so everyone knows about this. That is the source of much
+confusion. It's better to pretend that the internal format is some unknown
+encoding, and that you always have to encode and decode explicitly.
+
=head2 What about the C<use bytes> pragma?
Don't use it. It makes no sense to deal with bytes in a text string, and it
C<use bytes> is usually a failed attempt to do something useful. Just forget
about it.
-=head2 What are C<decode_utf8> and C<encode_utf8>?
+=head2 What about the C<use encoding> pragma?
-These are alternate syntaxes for C<decode('utf8', ...)> and C<encode('utf8',
-...)>.
+Don't use it. Unfortunately, it assumes that the programmer's environment and
+that of the user will use the same encoding. It will use the same encoding for
+the source code and for STDIN and STDOUT. When a program is copied to another
+machine, the source code does not change, but the STDIO environment might.
+
+If you need non-ASCII characters in your source code, make it a UTF-8 encoded
+file and C<use utf8>.
+
+If you need to set the encoding for STDIN, STDOUT, and STDERR, for example
+based on the user's locale, C<use open>.
+
+=head2 What is the difference between C<:encoding> and C<:utf8>?
+
+Because UTF-8 is one of Perl's internal formats, you can often just skip the
+encoding or decoding step, and manipulate the UTF8 flag directly.
+
+Instead of C<:encoding(UTF-8)>, you can simply use C<:utf8>, which skips the
+encoding step if the data was already represented as UTF8 internally. This is
+widely accepted as good behavior when you're writing, but it can be dangerous
+when reading, because it causes internal inconsistency when you have invalid
+byte sequences. Using C<:utf8> for input can sometimes result in security
+breaches, so please use C<:encoding(UTF-8)> instead.
+
+Instead of C<decode> and C<encode>, you could use C<_utf8_on> and C<_utf8_off>,
+but this is considered bad style. Especially C<_utf8_on> can be dangerous, for
+the same reason that C<:utf8> can.
+
+There are some shortcuts for oneliners; see C<-C> in L<perlrun>.
=head2 What's the difference between C<UTF-8> and C<utf8>?
encoding for a certain string is, but instead just encode it into the encoding
that you want.
-=head2 What character encodings does Perl support?
-
-To find out which character encodings your Perl supports, run:
-
- perl -MEncode -le "print for Encode->encodings(':all')"
-
-=head2 Which version of perl should I use?
-
-Well, if you can, upgrade to the most recent, but certainly C<5.8.1> or newer.
-The tutorial and FAQ are based on the status quo as of C<5.8.8>.
-
-You should also check your modules, and upgrade them if necessary. For example,
-HTML::Entities requires version >= 1.32 to function correctly, even though the
-changelog is silent about this.
-
=head1 AUTHOR
-Juerd Waalboer <juerd@cpan.org>
+Juerd Waalboer <#####@juerd.nl>
=head1 SEE ALSO
https://perl5.git.perl.org / perl5.git / blobdiff