Update the Mac OS X situation.
[p5sagit/p5-mst-13.2.git] / pod / perluniintro.pod
index a55dbe5..d6eae60 100644 (file)
@@ -128,10 +128,9 @@ This model was found to be wrong, or at least clumsy: the Unicodeness
 is now carried with the data, not attached to the operations.  (There
 is one remaining case where an explicit C<use utf8> is needed: if your
 Perl script itself is encoded in UTF-8, you can use UTF-8 in your
-variable and subroutine names, and in your string and regular
-expression literals, by saying C<use utf8>.  This is not the default
-because that would break existing scripts having legacy 8-bit data in
-them.)
+identifier names, and in your string and regular expression literals,
+by saying C<use utf8>.  This is not the default because that would
+break existing scripts having legacy 8-bit data in them.)
 
 =head2 Perl's Unicode Model
 
@@ -147,17 +146,17 @@ Unicode strings. Specifically, if all code points in the string are
 0xFF or less, Perl uses the native eight-bit character set.
 Otherwise, it uses UTF-8.
 
-A user of Perl does not normally need to know nor care how Perl happens
-to encodes its internal strings, but it becomes relevant when outputting
-Unicode strings to a stream without a discipline (one with the "default
-default").  In such a case, the raw bytes used internally (the native
-character set or UTF-8, as appropriate for each string) will be used,
-and if warnings are turned on, a "Wide character" warning will be issued
-if those strings contain a character beyond 0x00FF.
+A user of Perl does not normally need to know nor care how Perl
+happens to encode its internal strings, but it becomes relevant when
+outputting Unicode strings to a stream without a discipline (one with
+the "default default").  In such a case, the raw bytes used internally
+(the native character set or UTF-8, as appropriate for each string)
+will be used, and a "Wide character" warning will be issued if those
+strings contain a character beyond 0x00FF.
 
 For example,
 
-      perl -w -e 'print "\x{DF}\n", "\x{0100}\x{DF}\n"'              
+      perl -e 'print "\x{DF}\n", "\x{0100}\x{DF}\n"'              
 
 produces a fairly useless mixture of native bytes and UTF-8, as well
 as a warning.
@@ -169,15 +168,27 @@ To output UTF-8 always, use the ":utf8" output discipline.  Prepending
 to this sample program ensures the output is completely UTF-8, and      
 of course, removes the warning.
 
-Perl 5.8.0 also supports Unicode on EBCDIC platforms.  There, the
-support is somewhat harder to implement since additional conversions
-are needed at every step.  Because of these difficulties, the Unicode
-support isn't quite as full as in other, mainly ASCII-based, platforms
-(the Unicode support is better than in the 5.6 series, which didn't
-work much at all for EBCDIC platform).  On EBCDIC platforms, the
-internal Unicode encoding form is UTF-EBCDIC instead of UTF-8 (the
-difference is that as UTF-8 is "ASCII-safe" in that ASCII characters
-encode to UTF-8 as-is, UTF-EBCDIC is "EBCDIC-safe").
+If your locale environment variables (LANGUAGE, LC_ALL, LC_CTYPE, LANG)
+contain the strings 'UTF-8' or 'UTF8' (case-insensitive matching),
+the default encoding of your STDIN, STDOUT, and STDERR, and of
+B<any subsequent file open>, is UTF-8.  Note that this means
+that Perl expects other software to work, too: if STDIN coming
+in from another command is not UTF-8, Perl will complain about
+malformed UTF-8.
+
+=head2 Unicode and EBCDIC
+
+Perl 5.8.0 also supports Unicode on EBCDIC platforms.  There,
+the Unicode support is somewhat more complex to implement since
+additional conversions are needed at every step.  Some problems
+remain, see L<perlebcdic> for details.
+
+In any case, the Unicode support on EBCDIC platforms is better than
+in the 5.6 series, which didn't work much at all for EBCDIC platform.
+On EBCDIC platforms, the internal Unicode encoding form is UTF-EBCDIC
+instead of UTF-8 (the difference is that as UTF-8 is "ASCII-safe" in
+that ASCII characters encode to UTF-8 as-is, UTF-EBCDIC is
+"EBCDIC-safe").
 
 =head2 Creating Unicode
 
@@ -221,6 +232,17 @@ Note that both C<\x{...}> and C<\N{...}> are compile-time string
 constants: you cannot use variables in them.  if you want similar
 run-time functionality, use C<chr()> and C<charnames::vianame()>.
 
+Also note that if all the code points for pack "U" are below 0x100,
+bytes will be generated, just like if you were using C<chr()>.
+
+   my $bytes = pack("U*", 0x80, 0xFF);
+
+If you want to force the result to Unicode characters, use the special
+C<"U0"> prefix.  It consumes no arguments but forces the result to be
+in Unicode characters, instead of bytes.
+
+   my $chars = pack("U0U*", 0x80, 0xFF);
+
 =head2 Handling Unicode
 
 Handling Unicode is for the most part transparent: just use the
@@ -257,8 +279,8 @@ C<Latin 2>, or C<iso8859-2>, and so forth.  With just
 
     use encoding;
 
-first the environment variable C<PERL_ENCODING> will be consulted,
-and if that doesn't exist, ISO 8859-1 (Latin 1) will be assumed.
+the environment variable C<PERL_ENCODING> will be consulted,
+but if that doesn't exist, the encoding pragma fails.
 
 The C<Encode> module knows about many encodings and it has interfaces
 for doing conversions between those encodings:
@@ -275,10 +297,10 @@ Normally, writing out Unicode data
 produces raw bytes that Perl happens to use to internally encode the
 Unicode string (which depends on the system, as well as what
 characters happen to be in the string at the time). If any of the
-characters are at code points 0x100 or above, you will get a warning
-if you use C<-w> or C<use warnings>. To ensure that the output is
-explicitly rendered in the encoding you desire (and to avoid the
-warning), open the stream with the desired encoding. Some examples:
+characters are at code points 0x100 or above, you will get a warning.
+To ensure that the output is explicitly rendered in the encoding you
+desire (and to avoid the warning), open the stream with the desired
+encoding. Some examples:
 
     open FH, ">:ucs2",      "file"
     open FH, ">:utf8",      "file";
@@ -426,13 +448,13 @@ returns:
 
 Bit Complement Operator ~ And vec()
 
-The bit complement operator C<~> may produce surprising results if
-used on strings containing Unicode characters.  The results are
-consistent with the internal encoding of the characters, but not with
-much else.  So don't do that.  Similarly for vec(): you will be
-operating on the internally encoded bit patterns of the Unicode
-characters, not on the code point values, which is very probably not
-what you want.
+The bit complement operator C<~> may produce surprising results if used on
+strings containing characters with ordinal values above 255. In such a
+case, the results are consistent with the internal encoding of the
+characters, but not with much else. So don't do that. Similarly for vec():
+you will be operating on the internally encoded bit patterns of the Unicode
+characters, not on the code point values, which is very probably not what
+you want.
 
 =item *
 
@@ -518,19 +540,20 @@ http://www.unicode.org/unicode/reports/tr10/
 
 =item *
 
-Character Ranges
+Character Ranges and Classes
 
 Character ranges in regular expression character classes (C</[a-z]/>)
 and in the C<tr///> (also known as C<y///>) operator are not magically
 Unicode-aware.  What this means that C<[A-Za-z]> will not magically start
 to mean "all alphabetic letters" (not that it does mean that even for
-8-bit characters, you should be using C</[[:alpha]]/> for that).
+8-bit characters, you should be using C</[[:alpha:]]/> for that).
 
 For specifying things like that in regular expressions, you can use
 the various Unicode properties, C<\pL> or perhaps C<\p{Alphabetic}>,
 in this particular case.  You can use Unicode code points as the end
 points of character ranges, but that means that particular code point
-range, nothing more.  For further information, see L<perlunicode>.
+range, nothing more.  For further information (there are dozens
+of Unicode character classes), see L<perlunicode>.
 
 =item *
 
@@ -547,7 +570,9 @@ than ASCII 0 to 9 (and ASCII a to f for hexadecimal).
 
 =over 4
 
-=item Will My Old Scripts Break?
+=item 
+
+Will My Old Scripts Break?
 
 Very probably not.  Unless you are generating Unicode characters
 somehow, any old behaviour should be preserved.  About the only
@@ -556,13 +581,17 @@ is the old behaviour of C<chr()> where supplying an argument more
 than 255 produced a character modulo 255 (for example, C<chr(300)>
 was equal to C<chr(45)>).
 
-=item How Do I Make My Scripts Work With Unicode?
+=item 
+
+How Do I Make My Scripts Work With Unicode?
 
 Very little work should be needed since nothing changes until you
 somehow generate Unicode data.  The greatest trick will be getting
 input as Unicode, and for that see the earlier I/O discussion.
 
-=item How Do I Know Whether My String Is In Unicode?
+=item 
+
+How Do I Know Whether My String Is In Unicode?
 
 You shouldn't care.  No, you really shouldn't.  If you have
 to care (beyond the cases described above), it means that we
@@ -578,20 +607,37 @@ string are necessary UTF-8 encoded, or that any of the characters have
 code points greater than 0xFF (255) or even 0x80 (128), or that the
 string has any characters at all.  All the C<is_utf8()> does is to
 return the value of the internal "utf8ness" flag attached to the
-$string.  If the flag is on, characters added to that string will be
-automatically upgraded to UTF-8 (and even then only if they really
-need to be upgraded, that is, if their code point is greater than 0xFF).
+$string.  If the flag is off, the bytes in the scalar are interpreted
+as a single byte encoding.  If the flag is on, the bytes in the scalar
+are interpreted as the (multibyte, variable-length) UTF-8 encoded code
+points of the characters.  Bytes added to an UTF-8 encoded string are
+automatically upgraded to UTF-8.  If mixed non-UTF8 and UTF-8 scalars
+are merged (doublequoted interpolation, explicit concatenation, and
+printf/sprintf parameter substitution), the result will be UTF-8 encoded
+as if copies of the byte strings were upgraded to UTF-8: for example,
+
+    $a = "ab\x80c";
+    $b = "\x{100}";
+    print "$a = $b\n";
+
+the output string will be UTF-8-encoded "ab\x80c\x{100}\n", but note
+that C<$a> will stay single byte encoded.
 
 Sometimes you might really need to know the byte length of a string
-instead of the character length.  For that use the C<bytes> pragma
-and its only defined function C<length()>:
+instead of the character length. For that use either the
+C<Encode::encode_utf8()> function or the C<bytes> pragma and its only
+defined function C<length()>:
 
     my $unicode = chr(0x100);
     print length($unicode), "\n"; # will print 1
+    require Encode;
+    print length(Encode::encode_utf8($unicode)), "\n"; # will print 2
     use bytes;
-    print length($unicode), "\n"; # will print 2 (the 0xC4 0x80 of the UTF-8)
+    print length($unicode), "\n"; # will also print 2 (the 0xC4 0x80 of the UTF-8)
+
+=item 
 
-=item How Do I Detect Data That's Not Valid In a Particular Encoding
+How Do I Detect Data That's Not Valid In a Particular Encoding?
 
 Use the C<Encode> package to try converting it.
 For example,
@@ -610,10 +656,13 @@ For UTF-8 only, you can use:
 
 If invalid, a C<Malformed UTF-8 character (byte 0x##) in
 unpack> is produced. The "U0" means "expect strictly UTF-8
-encoded Unicode". Without that the C<unpack("U*", ...)>
-would accept also data like C<chr(0xFF>).
+encoded Unicode".  Without that the C<unpack("U*", ...)>
+would accept also data like C<chr(0xFF>), similarly to the
+C<pack> as we saw earlier.
 
-=item How Do I Convert Binary Data Into a Particular Encoding, Or Vice Versa?
+=item 
+
+How Do I Convert Binary Data Into a Particular Encoding, Or Vice Versa?
 
 This probably isn't as useful as you might think.
 Normally, you shouldn't need to.
@@ -666,12 +715,16 @@ Any random collection of bytes isn't well-formed UTF-8.  You can
 use C<unpack("C*", $string)> for the former, and you can create
 well-formed Unicode data by C<pack("U*", 0xff, ...)>.
 
-=item How Do I Display Unicode?  How Do I Input Unicode?
+=item 
+
+How Do I Display Unicode?  How Do I Input Unicode?
 
 See http://www.hclrss.demon.co.uk/unicode/ and
 http://www.cl.cam.ac.uk/~mgk25/unicode.html
 
-=item How Does Unicode Work With Traditional Locales?
+=item 
+
+How Does Unicode Work With Traditional Locales?
 
 In Perl, not very well.  Avoid using locales through the C<locale>
 pragma.  Use only one or the other.
@@ -767,7 +820,7 @@ in Perl 5.8.0 or newer, and
 
 in the Perl 5.6 series.  (The renaming to F<lib/unicore> was done to
 avoid naming conflicts with lib/Unicode in case-insensitive filesystems.)
-The main Unicode data file is F<Unicode.txt> (or F<Unicode.301> in
+The main Unicode data file is F<UnicodeData.txt> (or F<Unicode.301> in
 Perl 5.6.1.)  You can find the C<$Config{installprivlib}> by
 
     perl "-V:installprivlib"
@@ -790,6 +843,15 @@ C<Unicode::Map8>, and C<Unicode::Map>, available from CPAN.
 If you have the GNU recode installed, you can also use the
 Perl frontend C<Convert::Recode> for character conversions.
 
+The following are fast conversions from ISO 8859-1 (Latin-1) bytes
+to UTF-8 bytes, the code works even with older Perl 5 versions.
+
+    # ISO 8859-1 to UTF-8
+    s/([\x80-\xFF])/chr(0xC0|ord($1)>>6).chr(0x80|ord($1)&0x3F)/eg;
+
+    # UTF-8 to ISO 8859-1
+    s/([\xC2\xC3])([\x80-\xBF])/chr(ord($1)<<6&0xC0|ord($2)&0x3F)/eg;
+
 =head1 SEE ALSO
 
 L<perlunicode>, L<Encode>, L<encoding>, L<open>, L<utf8>, L<bytes>,
@@ -803,6 +865,6 @@ mailing lists for their valuable feedback.
 
 =head1 AUTHOR, COPYRIGHT, AND LICENSE
 
-Copyright 2001 Jarkko Hietaniemi <jhi@iki.fi>
+Copyright 2001-2002 Jarkko Hietaniemi <jhi@iki.fi>
 
 This document may be distributed under the same terms as Perl itself.