スペシャル（Unicode ブロック）

スペシャル
スペシャル
範囲	U+FFF0..U+FFFF ; (16コードポイント)
飛行機	ＢＭＰ
スクリプト	一般
割り当て済み	5 つのコードポイント
未使用	9 つの予約コードポイント; 2 つの非文字
Unicode バージョン履歴
1.0.0 (1991)	1 (+1)
2.1 (1998)	2 (+1)
3.0 (1999)	5 (+3)
Unicodeドキュメント
	コードチャート ∣ Webページ
	注:

スペシャル文字は、基本多言語面の末尾のU+FFF0～FFFF に割り当てられた短いUnicode文字ブロックで、次のコードポイントが含まれます。

U+FFF9 INTERLINEAR ANNOTATION ANCHOR 、注釈テキストの開始を示す
U+FFFA 行間注釈区切り文字、注釈文字の開始を示す
U+FFFB 行間注釈終端文字、注釈ブロックの終了を示す
U+FFFC オブジェクト置換文字。複合文書内など、テキスト内の別の未指定オブジェクトのプレース
U+FFFD - 未知の、認識されない、または表現できない文字を置き換えるために使用される置換文字
U+FFFE <非文字-FFFE> キャラクターではありません。
U+FFFF <非文字-FFFF> キャラクターではありません。

U+FFFE <非文字-FFFE> およびU+FFFF <非文字-FFFF> は非文字であり、予約されているが、不正な Unicode テキストの原因にはならない。Unicode 標準のバージョン 3.1.0 から 6.3.0 では、これらの文字は交換されてはならないとされていたため、一部のアプリケーションでは、これらの文字のいずれかが存在するとテキストが Unicode でないことを示すものとして解釈し、テキストのエンコードを推測するために使用していた。しかし、Corrigendum #9 では後に非文字は不正ではないと規定されているため、このテキストエンコードのチェック方法は正しくない。^[3] U+FFFE の内部使用例としては、CLDR アルゴリズムがある。この拡張 Unicode アルゴリズムは、非文字を最小の一意のプライマリウェイトにマッピングする。^[4]

Unicode のU+FEFF ZERO WIDTH NO-BREAK SPACE文字を Unicode テキストの先頭に挿入して、そのエンディアンを通知することができます。このようなテキストを読み取り、0xFFFE に遭遇したプログラムは、後続のすべての文字のバイト順序を切り替える必要があることを認識します。

Unicode 1.0でのブロック名はSpecialであった。^[5]

置換文字

置換文字 �（多くの場合、白い疑問符が付いた黒い菱形として表示されます）は、 Unicode標準のSpecialsテーブルのコードポイントU+FFFDにある記号です。システムがデータストリームを正しい記号にレンダリングできない場合に問題を示すために使用されます。^[6]

たとえば、ISO 8859-1でエンコードされたドイツ語の単語für を含むテキストファイルには、バイトが含まれます。このファイルを、入力がUTF-8であると想定するテキストエディターで開くと、最初のバイトと 3 番目のバイトはASCIIの有効な UTF-8 エンコードですが、2 番目のバイト ( ) は UTF-8 では有効ではありません。テキストエディターは、このバイトを置換文字に置き換えて、表示用の有効な Unicode コードポイント文字列を生成することができるため、ユーザーには "f�r" が表示されます。 0x66 0xFC 0x720xFC

実装が不十分なテキストエディターでは、ユーザーがファイルを保存するときに置換文字が書き出されることがあります0x66 0xEF 0xBF 0xBD 0x72。その場合、ファイル内のデータはになります。ISO 8859-1 を使用してファイルを再度開くと、「fï¿½r」と表示されます (これはmojibakeと呼ばれます)。置換はすべてのエラーに対して同じであるため、元の文字を復元することは不可能です。より優れた設計 (ただし実装は困難) は、エラーを含む元のバイトを保持し、テキストを表示するときにのみ置換に変換することです。これにより、テキストエディターは元のバイトシーケンスを保存しながら、ユーザーにエラー表示を表示できます。

かつては、フォント置換のように、その文字のグリフがフォントにない場合に置換文字がよく使用されていました。しかし、ほとんどの現代のテキストレンダリングシステムでは、代わりにフォントの.notdef文字が使用されています。これはほとんどの場合、空のボックス、またはボックス内の「？」または「X」です^{[7] (このブラウザでは Տ�� が表示されます)。これは「}豆腐」と呼ばれることもあります。この記号には Unicode コードポイントはありません。

したがって、置換文字はエンコードエラーの場合にのみ表示されます。一部のソフトウェアプログラムは、無効な UTF-8 バイトをWindows-1252の一致する文字に変換します(これがこれらのエラーの最も一般的な原因であるため)。そのため、置換文字は表示されません。

ユニコードチャート

歴史

次の Unicode 関連のドキュメントには、Specials ブロックで特定の文字を定義する目的とプロセスが記録されています。

参照

Unicode制御文字

参考文献

^ 「Unicode 文字データベース」。Unicode標準。2023 年 7 月 26 日閲覧。
^ 「Unicode 標準の列挙バージョン」。Unicode標準。2023 年 7 月 26 日閲覧。
^ 「Corrigendum #9: Clarification About Noncharacters」。Unicode 標準。2023年6月10日時点のオリジナルよりアーカイブ。2023年6月7日閲覧。
^ 「Unicode Technical Standard #35」。Unicode Locale Data Markup Language (LDML) 。2024年8月27日閲覧。
^ 「3.8: ブロックごとのチャート」(PDF) 。Unicode 標準。バージョン 1.0。Unicodeコンソーシアム。2021 年 2 月 11 日時点のオリジナルからアーカイブ(PDF) 。2020年 9 月 30 日閲覧。
^ Wichary, Marcin (2020年9月29日). 「When fonts fall」. Figma. 2021年6月13日時点のオリジナルよりアーカイブ。 2021年6月6日閲覧。
^ 「OpenType フォントの推奨事項 (OpenType 1.7) - タイポグラフィ」。Microsoft Learn。2020年 10 月 19 日時点のオリジナルよりアーカイブ。2020 年10 月 18 日閲覧。

[1] 「Unicode 文字データベース」。Unicode標準。2023 年 7 月 26 日閲覧。

[2] 「Unicode 標準の列挙バージョン」。Unicode標準。2023 年 7 月 26 日閲覧。

[3] 「Corrigendum #9: Clarification About Noncharacters」。Unicode 標準。2023年6月10日時点のオリジナルよりアーカイブ。2023年6月7日閲覧。

[4] 「Unicode Technical Standard #35」。Unicode Locale Data Markup Language (LDML) 。2024年8月27日閲覧。

[5] 「3.8: ブロックごとのチャート」(PDF) 。Unicode 標準。バージョン 1.0。Unicodeコンソーシアム。2021 年 2 月 11 日時点のオリジナルからアーカイブ(PDF) 。2020年 9 月 30 日閲覧。

[Wichary_fallback-6] Wichary, Marcin (2020年9月29日). 「When fonts fall」. Figma. 2021年6月13日時点のオリジナルよりアーカイブ。 2021年6月6日閲覧。

[7] 「OpenType フォントの推奨事項 (OpenType 1.7) - タイポグラフィ」。Microsoft Learn。2020年 10 月 19 日時点のオリジナルよりアーカイブ。2020 年10 月 18 日閲覧。