8.4 String型 / The String Type / Standard ECMA-262 5.1 Edition
8.4 String型 / The String Type / Standard ECMA-262 5.1 Edition
ECMAScript言語仕様 / ECMA-262 5.1 Edition
訳の正確性を保証するものではありませんので必要に応じて原文であるEcma InternationalのECMA-262にある ECMA-262.pdf ( ECMA-262 5.1 Edition )を参照下さい。
訳:2012年04月 webzoit.net
8 タイプ・型
8.4 String型
String(文字列)型は、その全てがゼロ以上の16ビット符号付き整数値から成る序数並びで終わる集合("elements"／エレメント・要素)です。 String型は、コードユニット値(第6項参照)として扱われるStringの中でも各要素ごとにECMAScriptプログラム実行時にテキストのデータを表現する為に使用されるのが一般的です。 各要素は、その並びの中である位置を占有するものとしてみなされます。 これらの位置は非負の整数を伴って索引付け(インデックス)されます。 (もしあれば)最初の要素は、位置が0、(もしあれば)次の要素の位置は1。。。等々といった感じです。 Stringの長さは、その中にある要素(例えば16ビット値の)数です。 空のStringは、長さゼロであり、それゆえに要素は1つも含みません。 Stringが実際のテキストデータを含む場合、各要素は、単独のUTF-16コードユニットとして認識されます。 これは、Stringの実際の保存形式がどうであったとしてもString内の文字並びは、UTF-16を使って表現されたものであるかのように要素位置にそれらの初期コードユニットによって番号付けされます。 (他の状態にある場合を除き)Strings上の全ての演算子は、未分化状態の16ビット符号なし整数としてそれらを扱います。 それらは、結果となるStringが言語依存の結果を確保するか否かに関わらず、正規形であるということを保証しません。 [注釈] この設計の背景にある論理的根拠は、同じように単純かつ高速処理可能であるStringsの実装を保持するという事です。 その意図は、外部からの実行環境によるテキストデータ(例えば、ユーザー入力やファイルから読み込んだテキスト、ネットワーク越しに受け取ったテキスト等々)は、実行中プログラムがそれと遭遇する前に"Unicode Normalised Form C"に変換されているということです。
[追記]
"Unicode Normalised Form C"とは、Unicodeによる[ Unicode Normalization Forms ]で定められた書式であり、
[ http://unicode.org/reports/tr15/#Norm_Forms ]
内の
[ http://unicode.org/reports/tr15/#Normalization_Forms_Table ]
にある下記4つの正規化の内の1つ。 ------------------------------------------------------------------ Normalization Form D (NFD) ：正規の名詞 Normalization Form C (NFC) ：正規の構成に続く正規の名詞 Normalization Form KD (NFKD) ：互換性のある名詞 Normalization Form KC (NFKC) ：正規の構成に続く互換性のある名詞 ------------------------------------------------------------------
Table 1. Normalization Forms / 正規化の形式
| 形式 | 説明 |
|---|---|
| Normalization Form D (NFD) | Canonical Decomposition 正規分解 |
| Normalization Form C (NFC) | Canonical Decomposition, followed by Canonical Composition 正規構成が続く正規分解 |
| Normalization Form KD (NFKD) | Compatibility Decomposition 互換分解 |
| Normalization Form KC (NFKC) | Compatibility Decomposition, followed by Canonical Composition 正規構成が続く互換分解 |
通常、これは、Unicodeにその元の文字符号化方式から変換され(、追加のオーバーヘッドなく課され)ると同時に入ってくるテキストに現れます。 ECMAScriptのソースコードが"Normalised Form C"の中にあることが推奨されていることから文字列リテラルは、(もし、ソーステキストが正規形であると保証される場合には、)いかなるUnicodeエスケープシーケンスをも含まないのと同じ長さに正規化されることが保証されます。
