Jarkko Hietaniemi > perl-5.7.3 > perlunicode

Download:
perl-5.7.3.tar.gz

Annotate this POD

Source   Latest Release: perl-5.21.6

NAME ^

perlunicode - Unicode support in Perl

DESCRIPTION ^

Important Caveats

Unicode support is an extensive requirement. While perl does not implement the Unicode standard or the accompanying technical reports from cover to cover, Perl does support many Unicode features.

Input and Output Disciplines

A filehandle can be marked as containing perl's internal Unicode encoding (UTF-8 or UTF-EBCDIC) by opening it with the ":utf8" layer. Other encodings can be converted to perl's encoding on input, or from perl's encoding on output by use of the ":encoding(...)" layer. See open.

To mark the Perl source itself as being in a particular encoding, see encoding.

Regular Expressions

The regular expression compiler produces polymorphic opcodes. That is, the pattern adapts to the data and automatically switch to the Unicode character scheme when presented with Unicode data, or a traditional byte scheme when presented with byte data.

use utf8 still needed to enable UTF-8/UTF-EBCDIC in scripts

As a compatibility measure, this pragma must be explicitly used to enable recognition of UTF-8 in the Perl scripts themselves on ASCII based machines, or to recognize UTF-EBCDIC on EBCDIC based machines. NOTE: this should be the only place where an explicit use utf8 is needed.

You can also use the encoding pragma to change the default encoding of the data in your script; see encoding.

Byte and Character semantics

Beginning with version 5.6, Perl uses logically wide characters to represent strings internally.

In future, Perl-level operations can be expected to work with characters rather than bytes, in general.

However, as strictly an interim compatibility measure, Perl aims to provide a safe migration path from byte semantics to character semantics for programs. For operations where Perl can unambiguously decide that the input data is characters, Perl now switches to character semantics. For operations where this determination cannot be made without additional information from the user, Perl decides in favor of compatibility, and chooses to use byte semantics.

This behavior preserves compatibility with earlier versions of Perl, which allowed byte semantics in Perl operations, but only as long as none of the program's inputs are marked as being as source of Unicode character data. Such data may come from filehandles, from calls to external programs, from information provided by the system (such as %ENV), or from literals and constants in the source text.

On Windows platforms, if the -C command line switch is used, (or the ${^WIDE_SYSTEM_CALLS} global flag is set to 1), all system calls will use the corresponding wide character APIs. Note that this is currently only implemented on Windows since other platforms lack an API standard on this area.

Regardless of the above, the bytes pragma can always be used to force byte semantics in a particular lexical scope. See bytes.

The utf8 pragma is primarily a compatibility device that enables recognition of UTF-(8|EBCDIC) in literals encountered by the parser. Note that this pragma is only required until a future version of Perl in which character semantics will become the default. This pragma may then become a no-op. See utf8.

Unless mentioned otherwise, Perl operators will use character semantics when they are dealing with Unicode data, and byte semantics otherwise. Thus, character semantics for these operations apply transparently; if the input data came from a Unicode source (for example, by adding a character encoding discipline to the filehandle whence it came, or a literal Unicode string constant in the program), character semantics apply; otherwise, byte semantics are in effect. To force byte semantics on Unicode data, the bytes pragma should be used.

Notice that if you concatenate strings with byte semantics and strings with Unicode character data, the bytes will by default be upgraded as if they were ISO 8859-1 (Latin-1) (or if in EBCDIC, after a translation to ISO 8859-1). This is done without regard to the system's native 8-bit encoding, so to change this for systems with non-Latin-1 (or non-EBCDIC) native encodings, use the encoding pragma, see encoding.

Under character semantics, many operations that formerly operated on bytes change to operating on characters. A character in Perl is logically just a number ranging from 0 to 2**31 or so. Larger characters may encode to longer sequences of bytes internally, but this is just an internal detail which is hidden at the Perl level. See perluniintro for more on this.

Effects of character semantics

Character semantics have the following effects:

Scripts

The scripts available via \p{...} and \P{...}, for example \p{Latin} or \p{Cyrillic>, are as follows:

    Arabic
    Armenian
    Bengali
    Bopomofo
    CanadianAboriginal
    Cherokee
    Cyrillic
    Deseret
    Devanagari
    Ethiopic
    Georgian
    Gothic
    Greek
    Gujarati
    Gurmukhi
    Han
    Hangul
    Hebrew
    Hiragana
    Inherited
    Kannada
    Katakana
    Khmer
    Lao
    Latin
    Malayalam
    Mongolian
    Myanmar
    Ogham
    OldItalic
    Oriya
    Runic
    Sinhala
    Syriac
    Tamil
    Telugu
    Thaana
    Thai
    Tibetan
    Yi

There are also extended property classes that supplement the basic properties, defined by the PropList Unicode database:

    ASCII_Hex_Digit
    BidiControl
    Dash
    Diacritic
    Extender
    HexDigit
    Hyphen
    Ideographic
    JoinControl
    NoncharacterCodePoint
    OtherAlphabetic
    OtherLowercase
    OtherMath
    OtherUppercase
    QuotationMark
    WhiteSpace

and further derived properties:

    Alphabetic      Lu + Ll + Lt + Lm + Lo + OtherAlphabetic
    Lowercase       Ll + OtherLowercase
    Uppercase       Lu + OtherUppercase
    Math            Sm + OtherMath

    ID_Start        Lu + Ll + Lt + Lm + Lo + Nl
    ID_Continue     ID_Start + Mn + Mc + Nd + Pc

    Any             Any character
    Assigned        Any non-Cn character (i.e. synonym for C<\P{Cn}>)
    Unassigned      Synonym for C<\p{Cn}>
    Common          Any character (or unassigned code point)
                    not explicitly assigned to a script

For backward compatability, all properties mentioned so far may have Is prepended to their name (e.g. \P{IsLu} is equal to \P{Lu}).

Blocks

In addition to scripts, Unicode also defines blocks of characters. The difference between scripts and blocks is that the scripts concept is closer to natural languages, while the blocks concept is more an artificial grouping based on groups of mostly 256 Unicode characters. For example, the Latin script contains letters from many blocks. On the other hand, the Latin script does not contain all the characters from those blocks. It does not, for example, contain digits because digits are shared across many scripts. Digits and other similar groups, like punctuation, are in a category called Common.

For more about scripts, see the UTR #24:

   http://www.unicode.org/unicode/reports/tr24/

For more about blocks, see:

   http://www.unicode.org/Public/UNIDATA/Blocks.txt

Blocks names are given with the In prefix. For example, the Katakana block is referenced via \p{InKatakana}. The In prefix may be omitted if there is no nameing conflict with a script or any other property, but it is recommended that In always be used to avoid confusion.

These block names are supported:

   InAlphabeticPresentationForms
   InArabicBlock
   InArabicPresentationFormsA
   InArabicPresentationFormsB
   InArmenianBlock
   InArrows
   InBasicLatin
   InBengaliBlock
   InBlockElements
   InBopomofoBlock
   InBopomofoExtended
   InBoxDrawing
   InBraillePatterns
   InByzantineMusicalSymbols
   InCJKCompatibility
   InCJKCompatibilityForms
   InCJKCompatibilityIdeographs
   InCJKCompatibilityIdeographsSupplement
   InCJKRadicalsSupplement
   InCJKSymbolsAndPunctuation
   InCJKUnifiedIdeographs
   InCJKUnifiedIdeographsExtensionA
   InCJKUnifiedIdeographsExtensionB
   InCherokeeBlock
   InCombiningDiacriticalMarks
   InCombiningHalfMarks
   InCombiningMarksForSymbols
   InControlPictures
   InCurrencySymbols
   InCyrillicBlock
   InDeseretBlock
   InDevanagariBlock
   InDingbats
   InEnclosedAlphanumerics
   InEnclosedCJKLettersAndMonths
   InEthiopicBlock
   InGeneralPunctuation
   InGeometricShapes
   InGeorgianBlock
   InGothicBlock
   InGreekBlock
   InGreekExtended
   InGujaratiBlock
   InGurmukhiBlock
   InHalfwidthAndFullwidthForms
   InHangulCompatibilityJamo
   InHangulJamo
   InHangulSyllables
   InHebrewBlock
   InHighPrivateUseSurrogates
   InHighSurrogates
   InHiraganaBlock
   InIPAExtensions
   InIdeographicDescriptionCharacters
   InKanbun
   InKangxiRadicals
   InKannadaBlock
   InKatakanaBlock
   InKhmerBlock
   InLaoBlock
   InLatin1Supplement
   InLatinExtendedAdditional
   InLatinExtended-A
   InLatinExtended-B
   InLetterlikeSymbols
   InLowSurrogates
   InMalayalamBlock
   InMathematicalAlphanumericSymbols
   InMathematicalOperators
   InMiscellaneousSymbols
   InMiscellaneousTechnical
   InMongolianBlock
   InMusicalSymbols
   InMyanmarBlock
   InNumberForms
   InOghamBlock
   InOldItalicBlock
   InOpticalCharacterRecognition
   InOriyaBlock
   InPrivateUse
   InRunicBlock
   InSinhalaBlock
   InSmallFormVariants
   InSpacingModifierLetters
   InSpecials
   InSuperscriptsAndSubscripts
   InSyriacBlock
   InTags
   InTamilBlock
   InTeluguBlock
   InThaanaBlock
   InThaiBlock
   InTibetanBlock
   InUnifiedCanadianAboriginalSyllabics
   InYiRadicals
   InYiSyllables

Character encodings for input and output

See Encode.

CAVEATS ^

Whether an arbitrary piece of data will be treated as "characters" or "bytes" by internal operations cannot be divined at the current time.

Use of locales with Unicode data may lead to odd results. Currently there is some attempt to apply 8-bit locale info to characters in the range 0..255, but this is demonstrably incorrect for locales that use characters above that range when mapped into Unicode. It will also tend to run slower. Avoidance of locales is strongly encouraged.

UNICODE REGULAR EXPRESSION SUPPORT LEVEL ^

The following list of Unicode regular expression support describes feature by feature the Unicode support implemented in Perl as of Perl 5.8.0. The "Level N" and the section numbers refer to the Unicode Technical Report 18, "Unicode Regular Expression Guidelines".

Unicode Encodings

Unicode characters are assigned to code points which are abstract numbers. To use these numbers various encodings are needed.

Security Implications of Malformed UTF-8

Unfortunately, the specification of UTF-8 leaves some room for interpretation of how many bytes of encoded output one should generate from one input Unicode character. Strictly speaking, one is supposed to always generate the shortest possible sequence of UTF-8 bytes, because otherwise there is potential for input buffer overflow at the receiving end of a UTF-8 connection. Perl always generates the shortest length UTF-8, and with warnings on (-w or use warnings;) Perl will warn about non-shortest length UTF-8 (and other malformations, too, such as the surrogates, which are not real Unicode code points.)

Unicode in Perl on EBCDIC

The way Unicode is handled on EBCDIC platforms is still rather experimental. On such a platform, references to UTF-8 encoding in this document and elsewhere should be read as meaning UTF-EBCDIC as specified in Unicode Technical Report 16 unless ASCII vs EBCDIC issues are specifically discussed. There is no utfebcdic pragma or ":utfebcdic" layer, rather, "utf8" and ":utf8" are re-used to mean the platform's "natural" 8-bit encoding of Unicode. See perlebcdic for more discussion of the issues.

Using Unicode in XS

If you want to handle Perl Unicode in XS extensions, you may find the following C APIs useful (see perlapi for details):

For more information, see perlapi, and utf8.c and utf8.h in the Perl source code distribution.

SEE ALSO ^

perluniintro, encoding, Encode, open, utf8, bytes, perlretut, "${^WIDE_SYSTEM_CALLS}" in perlvar

syntax highlighting: