仕様書

意味

[72] 非文字ひもじNoncharacterは、 符号点型の1つです。 >>71 D10a

[13] 非文字は、 内部用に恒久的に予約されている符号点です。 >>71 D14, >>38 字義通り単に「文字ではない」という意味ではなく、 非文字という1つの独立した分類であって、 noncharacter と1語で表記します。 文字ではありませんが、 Unicode符号位置ではあります。 抽象文字は割当済ではありませんが、 未割当符号点とは違う割当済符号点とされます。

[44] アプリケーションは、 内部用に自由に非文字符号点を使えます。 >>38, >>75 C2 ただ非文字のうち U+FFFE は想定用途が設定されています (>>7)。 U+FFFF, U+10FFFF にも利用例が示されています (>>14)。

[15] 非文字がアプリケーションの内部用途以外の情報交換で出現したとしても、 The Unicode Standard はそれに対して標準的な解釈は無い (意味を定義しない) としています。 >>38

[49] 非文字は、 アプリケーション内部用の私用文字的なものです。 真の私用文字は (私的な同意のもと) 開放型情報交換での利用が想定される割り当てられた文字であるのに対し、 非文字はアプリケーション外部での解釈を持たない恒久的に予約された未割当の符号位置である点が違います。 >>38

[11]

C7

When a process purports not to modify the interpretation of a valid coded character sequence, it shall make no change to that coded character sequence other than the possible replacement of character sequences by their canonical-equivalent sequences or the deletion of noncharacter code points.

• (中略)
• If a noncharacter that does not have a specific internal use is unexpectedly encountered in processing, an implementation may signal an error or delete or ignore the noncharacter. If these options are not taken, the noncharacter should be treated as an unassigned code point. For example, an API that returned a character property value for a noncharacter would return the same value as the default value for an unassigned code point.
• (後略)

[12]

D15 Reserved code point

Any code point of the Unicode Standard that is reserved for future assignment. Also known as an unassigned code point.

• Surrogate code points and noncharacters are considered assigned code points, but not assigned characters.
• (後略)

[9]

These codes are intended for process-internal uses, but are not permitted for interchange.

符号点

[32] 非文字の符号位置は、66個あります。 >>38, >>71 D14

• [40] 16進下4桁が 0xFFFE, 0xFFFF の 2 × 17 = 34 個の符号位置
• [41] U+FDD0 - U+FDEF の32個の符号位置

特性

[51] 私用文字は特性値を UCD に示されたままではなく、 割り当てた文字に合わせて変更することを認めています。 私用文字 一方非文字に対しては同様の規定はありません。

[52] アプリケーションは任意の目的で内部的に非文字を取り扱うことを認められているのですから、 特性値を任意の値に読み替えたとしても、 ただちに仕様違反とはならないはずです。 非文字はあくまでアプリケーション内でのみ使うことが想定されたものですから、 どう処理しようとも相互運用性には影響しないはずです。

[53] 逆にそれが相互運用性に悪影響を及ぼす形で観測され得るとしたら、 それは非文字の用法として不適切であるとも考えられます。

[77] 非文字の General Category は Cn です >>10。 Cn には他に未割当符号点も含まれます。 Cn

安定性

[73] 非文字符号点は、 恒久的に非文字として予約されています。 >>71 D14

[45] The Unicode Standard は、 非文字の意味を定めていません。 The Unicode Standard は、 自身が非文字に情報交換可能な意味を割り当てることを、 恒久的に禁止しています。 >>38

[74] つまり既に非文字として定義された符号点が、 非文字でなくなることはありません。

[50] 現在の非文字は、過去の The Unicode Standard で段階的に追加されたものでした。 ここ数年新規追加はされておらず、 近い将来に追加されそうな見込みもありませんが、 今後どうなるかは不明です。

文脈

[59] Unicode文字列は、 一般的には Unicode符号位置の列で、 非文字が含まれる可能性もあります。

[46] The Unicode Standard は、 Unicode文字列には、 たとえそれが情報交換されるものだとしても、 非文字が含まれることを禁止はしないとしています。 ゆえに、 API やプロセス間通信や蓄積のような内部的な 「情報交換」 で非文字を正しく保持できるのであると説明されています。 >>38 つまり非文字が利用を認められる「内部処理」 とは、 必ずしも動作中のプロセスが保持するメモリー上の文字列表現のような狭い範囲に限定されていないということです。

[39] Unicode テキストデータの開放型交換では、 非文字の利用は推奨recommendedされていません。 >>38 公開の情報交換では使うべきではありませんshould not >>75 C2。

[60] ところでこの開放型、非開放型という区別は、 ライブラリー、 IPC、 Web API など多様な手法で作者の異なる多数のソフトウェア部品を組み合わせて構築する現代的なアプリケーション開発技法のもとでは、 不鮮明かもしれません。 各部分で非文字がどう扱われるか、 正確に把握しながら開発する人は、そう多くはないでしょう。 いつどこでどのように扱われるかわからないとすると、 ごく限られた小さな関数内部でのみ使うような極めて限定的な用法以外は安全とはいえません。

[4] HTML では、 著者は文書に非文字を含めてはなりません。 直接の記述も文字参照としての記述もできません。 HTML Standard

[6] XML では、 U+FFFE、U+FFFF を文書に含めると整形式ではなくなります。 それ以外の非文字を含めることはできますが、 仕様書の Note で非推奨discouragedとされています。 >>62, >>63 XMLにおける文字

[65] JavaScript では非文字を扱うことができます。 DOM に非文字を含めることもできます。 (DOM としてメモリー上で非文字を保持することは可能ですが、 HTML文書やXML文書として直列化すると、 不適合になります。)

処理

[33] 非文字は処理系依存の意味を割り当てても良いことになっています。 従って内部でどのように処理されるかはまったく不明です。

[76] ただし処理は、 非文字符号点を抽象文字と解釈してはなりません。 >>75 C2

[67] そして、 非文字が含まれる文字列を受信したとき、 その挙動はまったく不明です。 ある実装では正しく扱える文字列が他の実装では意図せぬ動作を招くおそれがあります。

[47] The Unicode Standard として、 アプリケーションが開放型情報交換で非文字を受信した時に、 非文字をどう解釈しなければならないといった定めはありません。 しかし非文字を U+FFFD に置き換えるなど適切な措置をとるのよい慣習good practiceとされます。 ただし削除するだけだとセキュリティーの問題を起こすおそれがあります。 >>38

[34] とはいえ多くの実装は非文字に特別な意味を与えておらず、 プロトコルによっては誤りとして扱われたり、 U+FFFD に置き換えられたりする他は、 普通の未割り当ての符号位置と同じように扱われることが多いようです。

[68] アプリケーションが非文字に特別な意味を与えている場合は、 外部から与えられた非文字の意味がそれと一致している保証が無い限り、 U+FFFD に置き換えるか受け入れを拒絶するなど適切な措置を採らないと、 誤動作してしまいます。 ときにはセキュリティー問題となるかもしれません。

[69] アプリケーションやソフトウェア部品の中には、 非文字が与えられた時、 致死的エラーとして扱うものがあります。 開発者が意図せずそのような挙動のライブラリーを組み込んでいる場合もあります。 利用者がその挙動を完全に把握できているならいいですが (そんなことはほぼ無い)、 悪意ある第三者が非文字の入ったデータを混入させる DoS攻撃に使うおそれがあります。

[61] HTML構文解析器は、 非文字を構文解析誤りとし、 U+FFFD に置き換えなければなりません HTML Standard。 文字参照も U+FFFD に置き換えられます。

[64] 従って構文解析直後の HTML DOM には非文字は含まれません。 ただしスクリプトで DOM を操作して非文字を挿入することはできます。 従って JavaScript のコードは非文字が含まれないことを前提にはできません。

[66] XML構文解析器は U+FFFE, U+FFFF に遭遇したとき、 これを非整形式として扱わなければなりません。 そこで構文解析を停止し、 致死的エラーとして扱っても構いません (そのような実装が多いです) が、 処理を継続することも認められています。 ただしその場合どのように処理されるかは定められていません。 それ以外の非文字は、 通常の文字と同じように扱わなければなりません。

[70] 正当な利用者が意図せずに、 または悪意ある攻撃者により、 データに U+FFFE や U+FFFF が混入させられ、 XML文書である RSSフィードが非整形式化される事案がままあります。 (いけてないフィードリーダーはそのようなフィードを扱えないのです。)

関連

[21] 制御文字や U+FEFF ZWNBSP は文字であり、非文字ではありません。

[84] Unicodeの符号空間

歴史