NAME

perlunicode - Perl における Unicode サポート

DESCRIPTION

重要な警告

Uncode サポートは大規模な要求です。 Perl は標準 Unicode や付随する技術的なレポートを一つ残らず 実装しているわけではありませんが、多くの Unicode 機能を サポートしています。

Perl で Unicode を使うことを学びたい人は、多分このリファレンスを読む前に the Perl Unicode tutorial, perlunitut を 読んだ方がよいでしょう。

入出力層

Perl は、ファイルハンドルが ":utf8" 層を指定してオープンされると、 ファイルハンドルが Perl の内部 Unicode エンコーディング (UTF-8, または EBCDIC の時は UTF-EBCDIC) を使うことが分かります。 その他のエンコーディングは、":encoding(...)" 層を使うことで、 入力時の Perl のエンコーディングへの変換や出力時の Perl の エンコーディングからの変換を行えます。 open を参照してください。

Perl のソース自身が UTF-8 であることを示すには、use utf8; を 使ってください。

正規表現

正規表現コンパイラは多態的なオペコードを生成します。 つまり、パターンはデータに対して適用され、データが内部で UTF-8 で エンコードされている場合には Unicode 文字スキームに自動的に 切り替わります; さもなければ、バイトデータで表されている場合には 伝統的なバイトスキームが使われます。

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

互換性のために、ASCII ベースのマシンにおいて Perl スクリプトそれ自身の 中の UTF-8 を(文字列や正規表現リテラル、あるいは変数名で) 認識可能に するためや、EBCDIC ベースのマシンで UTF-EBCDIC を認識させるために use utf8 プラグマを明示的に含めなければなりません。 これらは明示的に use utf8 が必要な唯一の場合です。 utf8 を参照してください。

BOM-marked scripts and UTF-16 scripts autodetected

Unicode BOM (UTF-16LE, UTF16-BE, またはUTF-8)で Perl スクリプトが 始まっていたり、スクリプトが BOM がついていない UTF-16(BE か LE のいずれか) であった場合、Perl はそのスクリプトを Unicode であるとして正しく読み込みます。 (BOM がない UTF-8 は、効率的に ISO 8859-1 などの 8 ビットエンコーディングと 区別したり認識することができません。)

use encoding needed to upgrade non-Latin-1 byte strings

デフォルトでは、Perl の Unicode モデルにおける基本的な非対称があります: バイト文字列から Unicode 文字列への暗黙の昇格はその文字列が ISO 8859-1 (Latin-1) でエンコードされているものと仮定しますが、 Unicode 文字列からのダウングレードは UTF-8 エンコーディングへと行われます。 これは Unicode の最初の 256 文字が Latin-1 と共通であるからです。

詳細は "Byte and Character Semantics" を参照してください。

バイトと文字のセマンティクス

バージョン 5.6 から、Perl は論理的なワイド文字を内部的な文字列の 表現のために使っています。

将来は、Perl レベルの操作はバイトではなく文字に対して働くことになるでしょう。

しかしながら、一時的な互換性の措置として、Perl は プログラムに対するバイトセマンティクスから文字セマンティクスへの 安全な移行パスを提供することを目指します。 入力データが文字であると Perl が曖昧さなく決定できる操作については、 Perl は文字セマンティクスに切り替えます。 ユーザーからの付加的な情報抜きに決定することができない操作については Perl は互換性の観点からバイトセマンティクスを選択します。

バイトセマンティクスでは、use locale が有効の場合、Perl は 現在のロケールに関連づけられたセマンティクスを使います。 use locale がなく、use feature 'unicode_strings' もない場合、 Perl は現在のところ US-ASCII (または Unicode の用語では Basic Latin) バイト セマンティクスを使います; つまり番号 128 - 255 の範囲の文字は、 その番号以外では未定義です。 つまり、大文字小文字はなく、[:alpha:] や \w のような、 どの文字クラスにも含まれません。 (しかし \W クラスや Perl の正規表現拡張 [:^alpha:] には属します。)

この動作は Perl の以前のバージョンとの互換性を維持し、プログラムの 入力が Unicode の文字データのソースであるとマークされていない場合にのみ Perl の操作でバイトセマンティクスを許可します。 そのようなデータは、ファイルハンドル、外部プログラムの呼び出し、 システムから提供される情報(%ENV のような)、ソーステキスト中のリテラルや 定数といったものからくるものです。

bytes プラグマは常に、プラットフォームとは無関係に、特定の レキシカルスコープにおいてバイトセマンティクスを強制します。 bytes を参照してください。

use feature 'unicode_strings' プラグマは、プラットフォームに関わらず常に 特定のレキシカルスコープで Unicode セマンティクスを強制することを 意図しています。 リリース 5.12 では、これは部分的に実装されていて、大文字小文字変更にのみ 適用されます。 後述する "The "Unicode Bug"" を参照してください。

utf8 プラグマは主としてパーサが遭遇するリテラル中の UTF-(8|EBCDIC) の 認識を有効にする互換デバイス(compatibility device)です。 このプラグマは Perl のデフォルトがバイトセマンティクスであるときにのみ 必要であることに注意してください; 文字セマンティクスが デフォルトである場合には、このプラグマは何もしません。 utf8 を参照してください。

明示的に指定されない限り、Perl の演算子は Unicode データに対しては 文字セマンティクスを用い、非 Unicode データに対しては バイトセマンティクスを用います。 文字セマンティクスの使用の決定はトランスペアレントに行われます。 もし入力データが Unicode ソースから来たもの -- たとえば、 文字エンコーディング層がファイルハンドルに附加されているか リテラルの Unicode 文字列定数がプログラムの中にある -- のであれば 文字セマンティクスが適用されます。 そうでなければ、バイトセマンティクスが有効になります。 bytes プラグマは Unicode データに対してバイトセマンティクスを 強制するときに使って、use feature 'unicode_strings' プラグマを バイトデータで Unicode セマンティクスを強制するために使えます (しかし 5.12 ではこれは完全には実装されていません)。

バイトセマンティクスの元での文字列の操作で、Unicode 文字データが 連結された文字列であった場合、新たな文字列は文字セマンティックスを 保ちます。 これは驚きを引き起こすかもしれません: 後述する "BUGS" を 参照してください。 これが起きたときに警告されるようにすることを選択できます。 encoding::warnings を参照してください。

文字セマンティクスの元では、伝統的にバイトに対して働いていた操作の多くが 文字に対して働きます。 Perl における文字は論理的には 0 から 2**31 までの範囲の数値です。 大きな文字は内部的にはより長いシーケンスにエンコードされる可能性が ありますが、この内部の詳細は Perl プログラムからほとんど隠されています。 詳細は perluniintro を参照してください。

文字セマンティクスの効果

文字セマンティクスは以下の効果を持っています:

Unicode 文字特性

ほとんどの Unicode 文字特性は正規表現を使ってアクセス可能です。 それらは \p{} "matches property" 構造やその否定形の \P{} "doesn't match property" を使った文字クラスで使うことができます。

たとえば、\p{Uppercase} は Unicode の "Uppercase" 特性を持つ任意の 文字にマッチし、\p{L} は一般カテゴリ "L" (letter) 特性を持つ任意の 文字にマッチします。 ブラケットは一文字の特性では省略することができるので、\p{L} は \pL と等価です。

More formally, \p{Uppercase} matches any character whose Unicode Uppercase property value is True, and \P{Uppercase} matches any character whose Uppercase property value is False, and they could have been written as \p{Uppercase=True} and \p{Uppercase=False}, respectively (TBT)

This formality is needed when properties are not binary, that is if they can take on more values than just True and False. For example, the Bidi_Class (see "Bidirectional Character Types" below), can take on a number of different values, such as Left, Right, Whitespace, and others. To match these, one needs to specify the property name (Bidi_Class), and the value being matched against (Left, Right, etc.). This is done, as in the examples above, by having the two components separated by an equal sign (or interchangeably, a colon), like \p{Bidi_Class: Left}. (TBT)

All Unicode-defined character properties may be written in these compound forms of \p{property=value} or \p{property:value}, but Perl provides some additional properties that are written only in the single form, as well as single-form short-cuts for all binary properties and certain others described below, in which you may omit the property name and the equals or colon separator. (TBT)

Most Unicode character properties have at least two synonyms (or aliases if you prefer), a short one that is easier to type, and a longer one which is more descriptive and hence it is easier to understand what it means. Thus the "L" and "Letter" above are equivalent and can be used interchangeably. Likewise, "Upper" is a synonym for "Uppercase", and we could have written \p{Uppercase} equivalently as \p{Upper}. Also, there are typically various synonyms for the values the property can be. For binary properties, "True" has 3 synonyms: "T", "Yes", and "Y"; and "False has correspondingly "F", "No", and "N". But be careful. A short form of a value for one property may not mean the same thing as the same short form for another. Thus, for the General_Category property, "L" means "Letter", but for the Bidi_Class property, "L" means "Left". A complete list of properties and synonyms is in perluniprops. (TBT)

Upper/lower case differences in the property names and values are irrelevant, thus \p{Upper} means the same thing as \p{upper} or even \p{UpPeR}. Similarly, you can add or subtract underscores anywhere in the middle of a word, so that these are also equivalent to \p{U_p_p_e_r}. And white space is irrelevant adjacent to non-word characters, such as the braces and the equals or colon separators so \p{ Upper } and \p{ Upper_case : Y } are equivalent to these as well. In fact, in most cases, white space and even hyphens can be added or deleted anywhere. So even \p{ Up-per case = Yes} is equivalent. All this is called "loose-matching" by Unicode. The few places where stricter matching is employed is in the middle of numbers, and the Perl extension properties that begin or end with an underscore. Stricter matching cares about white space (except adjacent to the non-word characters) and hyphens, and non-interior underscores. (TBT)

\p{} と \P{} の両方で、キャレット(^) を最初のブレースと 特性名の間に置くことによって意味を反転することができます: \p{^Tamil} は \P{Tamil} と等価です。

General_Category

全ての Unicode 文字は一つの一般カテゴリに割り当てられています; これは「その文字の最も普通のカテゴライズ」 (http://www.unicode.org/reports/tr44 より)です。

これらを書く複合的な方法は \p{General_Category=Number} (短縮形は \p{gc:n}) のようなものです。 Perl は等号またはコロンの区切り文字までの全てを省略できる機能を 提供しています。 従って、代わりに単に \pN と書けます。

以下は、Unicode の一般カテゴリ特性(General Category properties) の 短形式と長形式です:

    Short       Long

    L           Letter
    LC, L&      Cased_Letter (that is: [\p{Ll}\p{Lu}\p{Lt}])
    Lu          Uppercase_Letter
    Ll          Lowercase_Letter
    Lt          Titlecase_Letter
    Lm          Modifier_Letter
    Lo          Other_Letter

    M           Mark
    Mn          Nonspacing_Mark
    Mc          Spacing_Mark
    Me          Enclosing_Mark

    N           Number
    Nd          Decimal_Number (also Digit)
    Nl          Letter_Number
    No          Other_Number

    P           Punctuation (also Punct)
    Pc          Connector_Punctuation
    Pd          Dash_Punctuation
    Ps          Open_Punctuation
    Pe          Close_Punctuation
    Pi          Initial_Punctuation
                (may behave like Ps or Pe depending on usage)
    Pf          Final_Punctuation
                (may behave like Ps or Pe depending on usage)
    Po          Other_Punctuation

    S           Symbol
    Sm          Math_Symbol
    Sc          Currency_Symbol
    Sk          Modifier_Symbol
    So          Other_Symbol

    Z           Separator
    Zs          Space_Separator
    Zl          Line_Separator
    Zp          Paragraph_Separator

    C           Other
    Cc          Control (also Cntrl)
    Cf          Format
    Cs          Surrogate   (not usable)
    Co          Private_Use
    Cn          Unassigned

単一文字の特性は同じ文字で始まる二文字の任意のサブ特性に含まれる すべての文字にマッチします。 LC と L& は特別なケースで、これは Ll, Lu, Lt の別名です。

Perl はユーザーが Unicode 文字の内部表現について理解する必要が ないようにしているので、サロゲートの面倒なコンセプトについて 実装する必要はありません。 従って、Cs はサポートされていません。

双方向文字型

用字はその方向性で異なるので--たとえばヘブライ語は右から左に書きます -- Unicode は以下の特性を Bidi_Class クラスで提供しています:

    Property    Meaning

    L           Left-to-Right
    LRE         Left-to-Right Embedding
    LRO         Left-to-Right Override
    R           Right-to-Left
    AL          Arabic Letter
    RLE         Right-to-Left Embedding
    RLO         Right-to-Left Override
    PDF         Pop Directional Format
    EN          European Number
    ES          European Separator
    ET          European Terminator
    AN          Arabic Number
    CS          Common Separator
    NSM         Non-Spacing Mark
    BN          Boundary Neutral
    B           Paragraph Separator
    S           Segment Separator
    WS          Whitespace
    ON          Other Neutrals

この特性は常に複合形式で書かれます。 たとえば、\p{Bidi_Class:R} は通常右から左に書く文字にマッチします。

用字

The world's languages are written in a number of scripts. This sentence (unless you're reading it in translation) is written in Latin, while Russian is written in Cyrllic, and Greek is written in, well, Greek; Japanese mainly in Hiragana or Katakana. There are many more. (TBT)

The Unicode Script property gives what script a given character is in, and can be matched with the compound form like \p{Script=Hebrew} (short: \p{sc=hebr}). Perl furnishes shortcuts for all script names. You can omit everything up through the equals (or colon), and simply write \p{Latin} or \P{Cyrillic}. (TBT)

用字とその省略形の完全な一覧は perluniprops にあります。

"Is" 接頭辞の使用

(Perl 5.6 との)後方互換性のため、すべての特性はその名前の前に Is または Is_ を置くことができます; したがって、\P{Is_Lu} は \P{Lu} と 等価で、\p{IsScript:Arabic} は \p{Arabic} と等価です。

ブロック

用字 に加え、Unicode では文字の ブロック を定義しています。 用字とブロックの違いは、用字のコンセプトが自然言語に 密着したものであるのに対して、ブロックのコンセプトは連続した番号を持つ Unicode 文字のグループに基づいたより人工的なグループ分けであることです。 たとえば、"Basic Latin" ブロックは番号 0 から 127 までの全ての文字、 言い換えると ASCII 文字です。 "Latin" 用字は、このブロックの文字と、"Latin-1 Supplement", "Latin Extended-A" など のいくつかのブロックの文字を含んでいますが、 それらのブロックのすべての文字を含んではいません。 例を挙げると、数字は多くの用字を越えて共有されているので、 (Latin 用字は)数字を含みません。 数字と、句読点のような同様のグループは Common と呼ばれる用字にあります。 他の文字を修正して、制御文字の用字の値を継承する文字のための Inherited と 呼ばれる用字もあります。

用字とブロックに違いに関する詳細については、 UAX#24 "Unicode Script Property" http://www.unicode.org/reports/tr24 を参照してください。

用字特性は自然言語を処理するときにおそらく使いたいと思うようなものです; ブロック特性は Unicode の基本的な部分で動作させるのに有用です。

ブロック名は \p{Block: Arrows} や \p{Blk=Hebrew} のような 復号形式でマッチングします。 その他のほとんどの特性と違って、いくつかのブロック名だけが Unicode が 定義した短い名前を持ちます。 しかし Perl は(多少の)ショートカットを提供します: 例えば \p{In_Arrows} や \p{In_Hebrew} のように書けます。 後方互換性のために、In 接頭辞は用字や他のプロパティと衝突しなければ 省略することも可能ですし、このような場合で Is 接頭辞を使うこともできます。 しかしそうするのはいい考えではありません; いくつかの理由があります:

  1. 混乱します。 多くの名前の衝突があり、一部を忘れているかもしれません。 例えば、\p{Hebrew} はヘブライ 用字 を意味し、 ヘブライ ブロック ではありません。 しかし 6 ヶ月後まで覚えていられますか?

  2. 不安定です。 新しいバージョンの Unicode は、同じ名前の特性を作ることで現在の意味を 変えることがあります。 とても初期の Unicode リリースでは \p{Hebrew} がヘブライ ブロック にマッチングしていた時期がありました; 今はマッチングしません。

一部の人々は、明確化のため、および 'In' と 'Is' の違いを覚えていられない (あるいは最終的にコードを読む人々が知っているか自信がない)という理由で、 ショートカットではなく常に \p{Block: foo} や \p{Script: bar} を 使うのを好みます。

ブロックとその省略形の完全な一覧は perluniprops にあります。

その他の特性

ここで記述したとても基本的なものよりもとても多くの特性があります。 完全な一覧は perluniprops です。

Unicode defines all its properties in the compound form, so all single-form properties are Perl extensions. A number of these are just synonyms for the Unicode ones, but some are genunine extensions, including a couple that are in the compound form. And quite a few of these are actually recommended by Unicode (in http://www.unicode.org/reports/tr18). (TBT)

This section gives some details on all the extensions that aren't synonyms for compound-form Unicode properties (for those, you'll have to refer to the Unicode Standard. (TBT)

\p{All}

これは任意の 1_114_112 Unicode 符号位置にマッチングします。 これは \p{Any} の同義語です。

\p{Alnum}

これは任意の \p{Alphabetic} または \p{Decimal_Number} 文字に マッチングします。

\p{Any}

これは任意の 1_114_112 Unicode 符号位置にマッチングします。 これは \p{All} の同義語です。

\p{Assigned}

これは任意の割り当てられた符号位置にマッチングします; つまり、一般カテゴリが Unassigned ではない(または同等に Cn ではない) 符号位置です。

\p{Blank}

これは \h および \p{HorizSpace} と同じです: スペースを垂直に変更する 文字です。

\p{Decomposition_Type: Non_Canonical} (Short: \p{Dt=NonCanon})

非正準分解文字にマッチングします。

このめったに使われない property=value の組の使い方を理解するために、 分解に関するいくつかの基本を知る必要があります。 一つの文字、例えば H について考えてみます。 It could appear with various marks around it, such as an acute accent, or a circumflex, or various hooks, circles, arrows, etc., above, below, to one side and/or the other, etc. 世界中のの言語の中では多くの可能性があります。 組み合わせの数は天文学的で、 and if there were a character for each combination, it would soon exhaust Unicode's more than a million possible characters. それで Unicode は異なる手法を取りました: there is a character for the base H, and a character for each of the possible marks, and they can be combined variously to get a final logical character. それで一つの論理文字--単一の文字として現れるもの--は 複数の独立した文字の並びになることがあります。 これは「拡張書記素クラスタ」("extended grapheme cluster")と呼ばれます。 (Perl はこのような並びにマッチングする \X 構文を用意しています。) (TBT)

But Unicode's intent is to unify the existing character set standards and practices, and a number of pre-existing standards have single characters that mean the same thing as some of these combinations. An example is ISO-8859-1, which has quite a few of these in the Latin-1 range, an example being "LATIN CAPITAL LETTER E WITH ACUTE". Because this character was in this pre-existing standard, Unicode added it to its repertoire. But this character is considered by Unicode to be equivalent to the sequence consisting of first the character "LATIN CAPITAL LETTER E", then the character "COMBINING ACUTE ACCENT". (TBT)

"LATIN CAPITAL LETTER E WITH ACUTE" is called a "pre-composed" character, and the equivalence with the sequence is called canonical equivalence. All pre-composed characters are said to have a decomposition (into the equivalent sequence) and the decomposition type is also called canonical. (TBT)

However, many more characters have a different type of decomposition, a "compatible" or "non-canonical" decomposition. The sequences that form these decompositions are not considered canonically equivalent to the pre-composed character. An example, again in the Latin-1 range, is the "SUPERSCRIPT ONE". It is kind of like a regular digit 1, but not exactly; its decomposition into the digit 1 is called a "compatible" decomposition, specifically a "super" decomposition. There are several such compatibility decompositions (see http://www.unicode.org/reports/tr44), including one called "compat" which means some miscellaneous type of decomposition that doesn't fit into the decomposition categories that Unicode has chosen. (TBT)

ほとんどの Unicode 文字は分解を持たないので、それらの分解型は "None" です。

Perl は便利なように Non_Canonical 型を追加しています; これは任意の互換分解を意味します。

\p{Graph}

任意の図形文字にマッチングします。 理論的には、これはプリンタがインクを使うことになる文字を意味します。

\p{HorizSpace}

これは \h や \p{Blank} と同じです: スペースを垂直に変更するものです。

\p{In=*}

これは \p{Present_In=*} の同義語です。

\p{PerlSpace}

これは \s と同じで、ASCII に制限されます; つまり [ \f\n\r\t] です。

記憶法: Perl の (元々の) スペース

\p{PerlWord}

これは \w と同じで ASCII に制限されます; つまり [A-Za-z0-9_] です。

記憶法: Perl の (元々の) 単語。

\p{PosixAlnum}

これは ASCII の範囲の任意の英数字にマッチングします; つまり [A-Za-z0-9] です。

\p{PosixAlpha}

これは ASCII の範囲の任意の英字にマッチングします; つまり [A-Za-z] です。

\p{PosixBlank}

これは ASCII の範囲の任意の空白文字にマッチングします; つまり [ \t] です。

\p{PosixCntrl}

これは ASCII の範囲の任意の制御文字にマッチングします; つまり [\x00-\x1F\x7F] です。

\p{PosixDigit}

これは ASCII の範囲の任意の数字にマッチングします; つまり [0-9] です。

\p{PosixGraph}

これは ASCII の範囲の任意の図形文字にマッチングします; つまり [\x21-\x7E] です。

\p{PosixLower}

これは ASCII の範囲の任意の小文字にマッチングします; つまり [a-z] です。

\p{PosixPrint}

これは ASCII の範囲の任意の表示文字にマッチングします; つまり [\x20-\x7E] です。 これは図形文字に SPACE を加えたものです。

\p{PosixPunct}

これは ASCII の範囲の任意の句読点文字にマッチングします; つまり [\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E] です。 これらは単語文字でない図形文字です。 Posix 標準は句読点の定義を含んでいて、Unicode はこれらの文字を 「シンボル」と呼んでいることに注意してください。

\p{PosixSpace}

これは ASCII の範囲の任意の空白文字にマッチングします; つまり [ \f\n\r\t\x0B] です (最後のものは垂直タブです)。

\p{PosixUpper}

これは ASCII の範囲の任意の大文字にマッチングします; つまり [A-Z] です。

\p{Present_In: *} (Short: \p{In=*})

この特性は、この文字の Unicode バージョンを知る必要があるときに使われます。

前述の "*" は、1.1 や 4.0 のような 2 桁の Unicode バージョン番号です; あるいは "*" は Unassigned も取ります。 This property will match the code points whose final disposition has been settled as of the Unicode release given by the version number; \p{Present_In: Unassigned} will match those code points whose meaning has yet to be assigned. (TBT)

For example, U+0041 "LATIN CAPITAL LETTER A" was present in the very first Unicode release available, which is 1.1, so this property is true for all valid "*" versions. On the other hand, U+1EFF was not assigned until version 5.1 when it became "LATIN SMALL LETTER Y WITH LOOP", so the only "*" that would match it are 5.1, 5.2, and later. (TBT)

Unicode furnishes the Age property from which this is derived. The problem with Age is that a strict interpretation of it (which Perl takes) has it matching the precise release a code point's meaning is introduced in. Thus U+0041 would match only 1.1; and U+1EFF only 5.1. This is not usually what you want. (TBT)

Some non-Perl implementations of the Age property may change its meaning to be the same as the Perl Present_In property; just be aware of that. (TBT)

Another confusion with both these properties is that the definition is not that the code point has been assigned, but that the meaning of the code point has been determined. This is because 66 code points will always be unassigned, and, so the Age for them is the Unicode version the decision to make them so was made in. For example, U+FDD0 is to be permanently unassigned to a character, and the decision to do that was made in version 3.1, so \p{Age=3.1} matches this character and \p{Present_In: 3.1} and up matches as well. (TBT)

\p{Print}

制御文字を除く、任意の図形文字か空白にマッチングします。

\p{SpacePerl}

これは \s は同様で、ASCII の範囲外を含みます。

記憶法: スペース、Perl によって修正。 (これは、Posix 標準と Unicode の両方が空白と考える垂直タブを含みません。)

\p{VertSpace}

これは \v と同じです: 垂直の空白を変更する文字です。

\p{Word}

これは \w と同じで、ASCII 範囲外を含みます。

ユーザ定義文字特性

あなた自身のバイナリ文字特性を、"In" または "Is" で始まる名前のサブルーチンを 定義することによって持つことができます。 そのサブルーチンは任意のパッケージで定義することができます。 ユーザー定義特性は正規表現の \p 構造や \P 構造で使うことができます; もしユーザー定義特性をそれがあるパッケージ以外で使いたいのであれば、 パッケージ名を \p (もしくは \P)のために指定する必要があります。

    # assuming property Is_Foreign defined in Lang::
    package main;  # property package name required
    if ($txt =~ /\p{Lang::IsForeign}+/) { ... }

    package Lang;  # property package name not required
    if ($txt =~ /\p{IsForeign}+/) { ... }

この効果はコンパイル時のもので、一度定義してしまったら 変更できないことに注意してください。

サブルーチンは、ひとつ以上の改行で区切られた特定の形式の文字列を 返さなければなりません。 各行は以下のいずれかの形式でなければなりません:

例えば、両方の日本語の音節(ひらがなとカタカナ)を対象とする特性を 定義するには、以下のように定義します

    sub InKana {
        return <<END;
    3040\t309F
    30A0\t30FF
    END
    }

ヒアドキュメントの終端マーカーは行の先頭に置かれることを思い出してください。 これで、\p{InKana} や \P{InKana} を使うことができます。

すでに存在しているブロック特性名を使うこともできます:

    sub InKana {
        return <<'END';
    +utf8::InHiragana
    +utf8::InKatakana
    END
    }

生のブロック範囲ではなく、割り当てられた文字のみにマッチさせたいと 考えているとしましょう: 言い換えれば、文字以外のものを 取り除きたいということです:

    sub InKana {
        return <<'END';
    +utf8::InHiragana
    +utf8::InKatakana
    -utf8::IsCn
    END
    }

否定は否定クラスを定義するのに便利です。

    sub InNotKana {
        return <<'END';
    !utf8::InHiragana
    -utf8::InKatakana
    +utf8::IsCn
    END
    }

共通集合(intersection)は二つ以上のクラスにマッチする共通の文字を得るのに 便利です。

    sub InFooAndBar {
        return <<'END';
    +main::Foo
    &main::Bar
    END
    }

最初の集合に "&" を使わないということを忘れないでください; そうしてしまうと空との共通集合を取ってしまいます(結果は空集合です)。

ユーザ定義の大文字・小文字の対応関係

同様に、lc()、lcfirst()、uc()、ucfirst() (あるいはその文字列組み込み版)で あなた自身の対応関係を定義することもできます。 原則は ユーザー定義文字特性の場合と似ています: ToLower (lc() と lcfirst()用), ToTitle (ucfirst() の最初の文字用), ToUpper (uc() 用と ucfirst() の 残りの文字用) のような名前のサブルーチンを定義します。

サブルーチンから返される文字列は二つのタブで区切られた二つの 16 進数を 必要とします: 二つの数値はそれぞれ、ソースの符号位置と デスティネーションの符号位置です。 例を挙げましょう:

    sub ToUpper {
        return <<END;
    0061\t\t0041
    END
    }

これは、"a" の文字のみを "A" にマッピングして その他のすべての文字は変更しないという uc() のマッピングを定義しています。

(真剣なハッカー専用) 上述したことは、完全なマッピングを提供する必要があるということです; 一部の文字を上書きして、残りを変更せずに残しておくことは出来ません。 $Config{privlib}/unicore/To/ というディレクトリに全てのマッピングが あります。 マッピングデータはヒアドキュメントとして返され、utf8::ToSpecFoo は $Config{privlib}/unicore/SpecialCasing.txt から派生した特殊な 例外マッピングです。 そのディレクトリで見つけることのできる "Digit" と "Fold" のマッピングは ユーザーがダイレクトにアクセスできず、Unicode::UCD モジュールを使うか 大小文字を無視してマッピングします("Fold" マッピングが使われているとき)。

対応関係は、例えば utf8::upgrade() を使って、スカラが Unicode 文字を 保持しているとしてマークされているときにのみ効果があります。 古いバイト形式の文字列には影響を及ぼしません。

マッピングは定義したパッケージに対して有効です。

入出力のための文字エンコーディング

Encode を参照してください。

Unicode 正規表現対応レベル

以下に挙げるリストは、現在対応している全ての機能を記述する、 正規表現のための Unicode 対応のリストです。 "Level N" に対する参照とセクション番号は Unicode Technical Standard #18, "Unicode Regular Expressions", version 11, in May 2005 を参照しています。

Unicode のエンコーディング

Unicode 文字は抽象的な数値である 符号位置 にアサインされています。 これらの数値を使うために、さまざまなエンコーディングが必要となります。

Unicode のセキュリティへの影響

Unicode Security Considerations を 呼んでください。 また、以下のことに注意してください:

EBCDIC 上の Perl での Unicode

EBCDIC プラットフォームでの Unicode の扱い方は未だ実験的です。 このようなプラットフォームでは、この文書やその他での UTF-8 エンコーディングへの言及は、特に ASCII 対 EBCDIC 問題について 議論されている場合でない限りは、Unicode Technical Report 16 で 定義されている UTF-EBCDIC を意味するものとして読むべきです。 utfebcdic プラグマや ":utfebcdic" 層はありません; 代わりに、"utf8" と ":utf8" が、そのプラットフォームの「自然な」 Unicode の 8 ビットエンコーディングを意味するように再利用されています。 この問題に関する更なる議論については perlebcdic を参照してください。

ロケール

通常ロケールの設定と Unicode は互いに影響を及ぼすことはありませんが、 いくつかの例外があります:

Unicode ではない場合

Perl には入出力を Unicode で行うための多数の方法があり、 @ARGV のように Unicode (UTF-8) として解釈できるようなその他の 「エントリポイント」はほとんどない一方、(何らかのエンコーディングで) Unicode が引数として与えられたり結果として返されるべきにも関わらず、 そうなっていない場所も未だ多くあります。

以下に挙げるのはそのようなインターフェースです。 また、"The "Unicode Bug"" を参照してください。 これらすべてが現在の Perl(5.8.3) では単純に引数と戻り値の両方が バイト文字列か、encoding プラグマが使われていれば UTF-8 文字列で あると仮定しています。

このようなケースにおいて、Perl がなぜ Unicode による解決を しないのかの理由の一つは、答えがオペレーティングシステムや ファイルシステムに強く依存しているからです。 たとえば、ファイル名が Unicode で記述できてエンコーディングが 合っていたとしてもそれは移植性のあるコンセプトではないのです。 同様なことが qx や system にも言えます: 「コマンドラインインターフェース」は Unicode をどのように 扱うのでしょうか?

「Unicode バグ」

「Unicode バグ」("Unicode bug")という用語は、番号が Latin-1 Supplement ブロック、つまり 128 から 255 にある Unicode 文字の 非一貫性に対して使われます。 ロケール指定がない場合、その他の文字や符号位置とは異なり、これらの文字は バイトセマンティクスと文字セマンティクスでとても異なったセマンティクスです。

文字セマンティクスでは Unicode 符号位置として解釈され、Latin-1 (ISO-8859-1) と同じセマンティクスを持ちます。

バイトセマンティクスでは、未定義文字として扱われ、保持している セマンティクスはその番号だけで、様々な文字クラスのメンバにはならないことを 意味します。 例えばどれも \w にはマッチングしませんが、全て \W にマッチングします。 (EBCDIC プラットフォームでは、振る舞いはこれとは異なり、基礎となる C 言語ライブラリ関数に依存します。)

この振る舞いは以下のような領域で影響があることが分かっています:

これの振る舞いにより、符号位置 255 を超える文字が追加されたり 削除されたりすると、文字列のセマンティックスがバイトから文字へ(または その逆へ)突然変更されるという予想外の結果を引き起こすことがあります。 例えば、以下のようなプログラムとその出力を考えます:

 $ perl -le'
     $s1 = "\xC2";
     $s2 = "\x{2660}";
     for ($s1, $s2, $s1.$s2) {
         print /\w/ || 0;
     }
 '
 0
 0
 1

s1 や s2 に \w がなければ、なぜこれらの結合は一つになるのでしょう?

This anomaly stems from Perl's attempt to not disturb older programs that didn't use Unicode, and hence had no semantics for characters outside of the ASCII range (except in a locale), along with Perl's desire to add Unicode support seamlessly. The result wasn't seamless: these characters were orphaned. (TBT)

Work is being done to correct this, but only some of it was complete in time for the 5.12 release. What has been finished is the important part of the case changing component. Due to concerns, and some evidence, that older code might have come to rely on the existing behavior, the new behavior must be explicitly enabled by the feature unicode_strings in the feature pragma, even though no new syntax is involved. (TBT)

See "lc" in perlfunc for details on how this pragma works in combination with various others for casing. Even though the pragma only affects casing operations in the 5.12 release, it is planned to have it affect all the problematic behaviors in later releases: you can't have one without them all. (TBT)

今のところの回避方法は 常に utf8::upgrade($string) を呼び出すか標準モジュール Encode を 使うことです。 また、基数が 0x100 以上の文字を持つスカラや、 Also, a scalar that has any characters whose ordinal is above 0x100, or which were specified using either of the \N{...} notations will automatically have character semantics. (TBT)

Unicode を Perl に強制する (あるいは Unicode でないことを Perl に強制する)

ときとして("When Unicode Does Not Happen" を参照)、バイト列を UTF-8 であるように強制したりその逆を行う場合があるかもしれません。 低レベルの呼び出し utf8::upgrade($bytestring) と utf8::downgrade($utf8string[, FAIL_OK]) がその回答です。

utf8::downgrade() は、バイトに収まらない文字を含む文字列の場合は 失敗することがあることに注意してください。

既に望み通りの状態になっている文字列に対してこれらの関数を呼び出しても、 何も起こりません。

XS で Unicode を使う

Perl の Unicode を XS 拡張で取り扱いたいと思うのなら、以下に挙げる API 群が便利かも知れません。 XS レベルでの Unicode に関しての説明は "Unicode Support" in perlguts を、 API の詳細については perlapi を参照してください。

もっと詳しい情報は、perlapi と、Perl のソースコード配布の utf8.c と utf8.h を参照してください。

以前の Unicode のバージョンで動作させるように Perl をハックする (とても真剣なハッカー専用)

Perl はデフォルトでは最新の Unicode バージョンが組み込まれていますが、 より古いものに変更することができます。

Download the files in the version of Unicode that you want from the Unicode web site http://www.unicode.org). These should replace the existing files in \$Config{privlib}/unicore. (\%Config is available from the Config module.) Follow the instructions in README.perl in that directory to change some of their names, and then run make. (TBT)

It is even possible to download them to a different directory, and then change utf8_heavy.pl in the directory \$Config{privlib} to point to the new directory, or maybe make a copy of that directory before making the change, and using @INC or the -I run-time flag to switch between versions at will (but because of caching, not in the middle of a process), but all this is beyond the scope of these instructions. (TBT)

BUGS

ロケールとの相互作用

Unicode データと共にロケールを使うことはおかしな結果を もたらすことになりやすいです。 現在のところ、Perl は文字に 0..255 の範囲の 8 ビットロケールを 割り当てようとしていますが、このテクニックは Unicode に マップしようとしたときに先の範囲の文字を使用するロケールに対して 明らかに正しくありません。 Perl の Unicode サポートはまた、遅くなりがちです。 Unicode といっしょにロケールを使うことはお勧めできません。

Latin-1 Supplement の範囲の文字の問題

"The "Unicode Bug"" を参照してください。

大文字小文字を無視した正規表現マッチングでの問題

大文字小文字を無視したマッチングには問題があります; (大かっこで囲まれた) 文字クラスに関するもの、 畳み込まれる文字が複数の文字になるもの (単一の文字 LATIN SMALL LIGATURE FFL が 3 文字の文字列 ffl に大文字小文字を無視してマッチングするようなもの) Latin-1 Supplement にある文字に関するものなどです。

エクステンションとの相互作用

Perl がエクステンションとデータをやり取りするとき、そのエクステンションは UTF8 フラグを理解し、また、それに従った振る舞いをすべきです。 エクステンションがこのフラグについて何も知らなければ、そのエクステンションは 正しくないフラグがついたデータを返す可能性があります。

そのため、もし Unicode データを扱おうというのであれば、 Unicode データの 交換に関して何らかの記述があるのなら使うモジュールすべてのドキュメントを 調べてください。 ドキュメントが Unicode に関して何の言及もしていないのなら、最悪のケースを 考慮し、そしてそのモジュールがどのように実装されているかを知るために ソースを見ることになるかもしれません。 完全に Perl で書かれたモジュールは問題を引き起こしません。 他のプログラミング言語で書かれている直接または間接にアクセスするコードに リスクがあるのです。

影響を受けた関数のための、データの劣化(data corruption)を防ぐ単純な 戦略とは、交換するデータのエンコーディングを常に明確にするということです。 エクステンションが取り扱うことができると知っているエンコーディングを 選択してください。 エクステンションに渡す引数を選択したエンコーディングに変換し、 エクステンションから返ってきた結果をそのエンコーディングから 逆方向に変換します。 変換を行ってくれるラッパ関数を書いておいて、 エクステンションが追いついた時に関数を変更できるようにしておきます。

例として、まだ Unicode データを取り扱うようにはできていない、 有名な Foo::Bar::escape_html について述べましょう。 ラッパ関数は引数を生の UTF-8 に変換し、結果を Perl の内部表現に 逆変換します:

    sub my_escape_html ($) {
      my($what) = shift;
      return unless defined $what;
      Encode::decode_utf8(Foo::Bar::escape_html(Encode::encode_utf8($what)));
    }

エクステンションがデータを変換しないけれども格納したり取り出したりするときに、 ときとして危険な Encode::_utf8_on() 関数以外のものを 使うことがあるかもしれません。 C で書かれていて、データを以下のプロトタイプに従って格納したり 取り出したりする param メソッドを持っている 有名な Foo::Bar エクステンションについて述べてみましょう:

    $self->param($name, $value);            # set a scalar
    $value = $self->param($name);           # retrieve a scalar

どのエンコーディングもまだサポートしていないのなら、 以下のような param メソッドを持った派生クラスを 記述することができるでしょう:

    sub param {
      my($self,$name,$value) = @_;
      utf8::upgrade($name);     # make sure it is UTF-8 encoded
      if (defined $value) {
        utf8::upgrade($value);  # make sure it is UTF-8 encoded
        return $self->SUPER::param($name,$value);
      } else {
        my $ret = $self->SUPER::param($name);
        Encode::_utf8_on($ret); # we know, it is UTF-8 encoded
        return $ret;
      }
    }

一部のエクステンションはデータのエントリ/脱出ポイントでフィルターを 提供しています; たとえば DB_File::filter_store_keyとその仲間です。 あなた使うエクステンションのドキュメントにあるそのようなフィルターに 注意してください; それらは Unicode データの変化をより容易にします。

速度

一部の関数は UTF-8 でエンコードされた文字列に対して適用したときにバイト エンコードされた文字列に対するときよりも遅くなります。 文字に対して働く必要のある length()、substr()、index()のような関数のすべてと 正規表現マッチングは、データが バイトエンコードされているときには かなり 早く動作できます。

Perl 5.8.0 ではこの遅さはしばしば目立つものでした; Perl 5.8.1 では 少なくとも一部の操作については、遅さを改善することを期待する キャッシングスキーム(caching scheme)が導入されました。 一般的には、UTF-8 エンコードされた文字列に対する操作はまだ遅いものです。 たとえば、\p{Nd} のような Unicode の特性(文字クラス)は対応する \d のような単純なものよりも目立って遅い(5 倍から10 倍)ことが 知られています(繰り返しますが、d は 10 の ASCII 文字に対して マッチするのに対して Nd は 268 の Unicode 文字にマッチします)。

EBCDIC プラットフォームでの問題

EBCDIC プラットフォームの Perl には多くの既知の問題があります。 そのような環境で Perl を使いたいなら、perlbug@perl.org にメールを 送ってください。

以前のバージョンでは、バイトデータと文字データを連結すると、 古い Unicode 文字列が EBCDIC を使っていたとしても、新しい文字列は バイト文字列を ISO 8859-1 (Latin-1) としてデコードして 作成されることがありました。

これらのどれかを発見したら、どうかバグとして報告してください。

perl 5.6.X からコードを移植する

Perl 5.8 は 5.6 とは異なる Unicode モデルを持っています。 5.6 ではプログラマは、ある与えられたスコープが Unicode データを 取り扱うのと Unicode データだけがそのスコープにあることを宣言するのに utf8 プラグマの使用を要求されていました。 5.6 で動いていたプログラムを持っているのなら、以下に挙げる微調整を施す 必要があるでしょう。 例は 5.6 でも動くように書かれているので、安心して試すことができます。

SEE ALSO

perlunitut, perluniintro, perluniprops, Encode, open, utf8, bytes, perlretut, "${^UNICODE}" in perlvar http://www.unicode.org/reports/tr44).