Swift : Unicode Standard Annex #29

[ ユニコード] 技術報告書

ユニコード標準付属書#29

ユニコードテキスト分割

バージョン Unicode 13.0.0
編集者 Mark Davis (markdavis@google.com)、Christopher Chapman (cchapman@adobe.com)
日付 2020-02-19
このバージョン http://www.unicode.org/reports/tr29/tr29-37.html
前バージョン http://www.unicode.org/reports/tr29/tr29-35.html
最新版 http://www.unicode.org/reports/tr29/
最新の更新提案 http://www.unicode.org/reports/tr29/proposed.html
改訂37
概要

この付属文書では、特定の重要なテキスト要素である書記素クラスタ(「ユーザーが認識した文字」)、単語、および文の間のデフォルトのセグメンテーション境界を決定するためのガイドラインを記述しています。行の境界については、[UAX14]を参照のこと。

ステータス

この文書は、Unicodeメンバー及びその他の利害関係者によってレビューされ、Unicodeコンソーシアムによって出版が承認されています。これは安定した文書であり、参照資料として使用したり、他の仕様による規範的参照として引用したりすることができます。

Unicode標準付属文書（UAX）は、Unicode標準の不可欠な部分を形成していますが、別の文書としてオンラインで公開されています。Unicode標準は、Unicode標準のそのバージョンのConformanceの章で指定されている場合には、Unicode標準附属書の中の規範的内容への適合を要求することがあります。UAX文書のバージョン番号は、その一部を構成するUnicode標準のバージョンに対応する。

コリジェンダやその他のコメントは、オンライン報告フォーム[Feedback]で提出してください。この附属書を理解する上で有用な関連情報は、Unicode標準附属書#41「Unicode標準附属書の共通参照」にあります。Unicode標準の最新版については、[Unicode]を参照してください。最新のUnicode技術報告書の一覧については、[報告書]を参照してください。Unicode標準のバージョンについては、[Versions]を参照してください。この附属書に適用される可能性のある正誤表については、[正誤表]を参照してください。

目次

1 はじめに
1.1 記法
1.2 ルール制約
2 適合性
3 グラフェンクラスターの境界
3.1 デフォルトのグラフェンクラスター境界仕様
3.1.1 グラフェンクラスターの境界規則
4つの言葉の境界線
4.1 デフォルトのワードバウンダリ仕様
4.1.1 単語の境界規則
4.2 名前の検証
5 文章の境界線
5.1 デフォルトのセンテンスバウンダリ仕様
5.1.1 文章境界規則
6 実装上の注意事項
6.1 正規化
6.2 無視するルールの置き換え
6.3 ステートマシン
6.4 ランダムアクセス
6.5 テーラリング
7 テスト
8 ハングル音節境界の決定
8.1 標準的な韓国語の音節
8.2 標準的な韓国語の音節に変換する
謝辞
参考文献
変更点
1 はじめに

この付属文書では、特定の重要なテキスト要素（ユーザーが認識した文字、単語、文）の間のデフォルトの境界を決定するためのガイドラインを説明します。境界を決定するプロセスはセグメンテーションとも呼ばれます。

ユニコードでエンコードされたテキストの文字列は、しばしばプログラムでテキスト要素に分割する必要があります。テキスト要素の一般的な例としては、ユーザーが文字、単語、行（より正確には改行が許可されているところ）、文などと考えているものがあります。テキスト要素の正確な決定は、与えられたスクリプトや言語の正書法の規則によって異なる場合があります。テキストだけでは、境界を明確に決定するのに十分な情報を常に含んでいるとは限らないため、ユーザーの認識を一致させるという目標は必ずしも正確に達成されない。例えば、ピリオド(U+002E FULL STOP)は曖昧に使われ、時には文末の目的で、時には略語で、時には数字で使われる。しかし、ほとんどの場合、プログラム的なテキストの境界線は、ユーザーの認識と非常に密接に一致することができます。

アルゴリズム的にテキスト要素（しばしばセグメントと呼ばれる）を探すことに集中するのではなく、より単純で有用な計算では、それらのテキスト要素間の境界（または区切り）を検出します。これらの境界線の決定は、しばしばパフォーマンスにとって非常に重要であるため、そのような決定を可能な限り迅速に行えることが重要です。(テキスト要素の一般的な議論については、[Unicode] の第 2 章 「一般構造」 を参照してください)。

こ の付属文書で指定 さ れてい る デフ ォ ル ト の境界決定機構は、 テ キ ス ト 内で最も重要な境界のい く つかを決定す る ための簡単で効率的な方法を提供 し ます ： ユーザーが認識す る キ ャ ラ ク タ ・ 単語 ・ 文章です。改行（単語の折り返しとも呼ばれる）で使用される境界は、[UAX14]で定義されている。

Unicode 規格の中の膨大な数のキ ャ ラ ク タ と その表現力は、 テ キ ス ト 要素境界の仕様 と その基礎と な る実装の両方に要件を与えます。仕様では、同じ特性を共有する文字の大集合（例えば大文字）の指定を可能にする必要があり、実装ではそれらの大集合への迅速なアクセスと一致を提供しなければなりません。こ の機構はまた、 ノンスペーシングマークや結合ジャモのような Unicode 規格の特別な機能も扱う必要があります。

デフ ォ ル ト の境界決定は、 Unicode 規格の統一文字表現に基づいて構築されていますが、大量のキ ャ ラ ク タ と 、 ノンスペーシングマークや結合ジャモなどの特殊機能を効果的な方法で扱う必要があります。このメカニズムは完全にデータ駆動型の実装に適しているため、再コードせずに特定の正書法規則やユーザーの好みに合わせて調整することができます。

他の Unicode アルゴリズムと同様に、これらの仕様はプロセスの論理的な説明を提供します。特に、多くのプロダクショングレードの実装では、状態表アプローチを使用します。その場合、パフォーマンスはルールの複雑さや数に依存しません。むしろ、パフォーマンスは、適用されるルールの境界位置の後にマッチする可能性のある文字数によってのみ影響を受けます。

1.1 記法

境界仕様は、その仕様で使用される境界プロパティ値を要約し、それらのプロパティ値に基づいて境界を決定するためのルールをリストアップします。この要約はリストとして提供され、リストの各要素は以下のいずれかになります。

リテラル文字
リテラル文字の範囲
Unicode Character Database [UCD] で定義されているプロパティを用いて、与えられた条件を満たすすべての文字。
非ブール値のプ ロ パテ ィ 値は、 <property> = <property value> と し て与え ら れ、 例 ： General_Category = Titlecase_Letter。
ブールプロパティは、<property> = Yes、例えばUppercase = Yesのように与えられる。
その他の条件は、UCDプロパティでテキスト的に指定されます。
上記のブール値の組み合わせ
2 つの特別な識別子である sot と eot は、それぞれテキストの開始と終了を表しています。
例えば、次のようなリストです。

General_Category = Line_Separator、または
General_Category = Paragraph_Separator、または
General_Category = 制御、または
一般_カテゴリー = フォーマット
ではなく、U+000D CARRIAGE RETURN (CR)である。
U+000Aラインフィード(LF)ではありません。
ではなく、U+200Cゼロ幅ノンジョイナー(ZWNJ)
U+200D ZERO WIDTH JOINER (ZWJ)ではなく、U+200D ZERO WIDTH JOINERである。

境界プロパティ値を割り当てるテーブルでは、特別な値 Any を除いて、すべての値が不連続であることが意図されています。競合が発生した場合、プロパティ値を文字に代入する際には、テーブルの上位の行が優先されます。プロパティ値の明示的な代入を含むデータファイルは、[Props]にあります。

境界の決定は、境界位置の状態を示す規則の順序付きリストで指定されます。ルールは参照のために番号が付けられており、任意のオフセットに境界があるかどうかを判断するために順番に適用されます。すなわち、各規則の先頭には、最初の規則に続く暗黙の「そうでなければ」があります。ルールは上から下へと処理されます。ルールが一致し、そのオフセットの境界の状態（境界があるかないか）が出るとすぐに、処理は終了します。

各規則は、 左辺、 境界記号 （表 1 参照）、 右辺から構成されています。いずれかの辺は空にすることができます。左辺と右辺は、正規表現の境界プロパティ値を使用します。使用される正規表現構文は、Unicode Technical Standard #18, Unicode Regular Expressions [UTS18] で提供されている形式を簡略化したものです。

表 1. 境界記号

÷バウンダリー（ここで休憩を入れる
× 境界なし（ここでのブレークを許さない
→ 左側にあるものを右側にあるものと同じように扱う
オープンボックス記号("&#9251;")は、例ではスペースを示すために使用されます。

1.2 ルール制約

これらの規則は、実装を大幅に単純化し、より効率的にするために、3つの方法で制約されています。これらの制約は、自然言語を使用する上での制限であることは発見されていない。特に、規則は、少数のプロパティ値に基づく決定論的有限状態機械のように、効率的に実装できるように定式化されている。

単一の境界。各ルールは、境界位置を正確に1つにします。複数の境界を持つルールは、代わりに複数のルールとして表現することができるので、この制限はむしろ指定方法の制限です。例えば、以下のようになります。
"a b ÷ c d ÷ e f "は、"a b ÷ c d ÷ e f "と "a b c d ÷ e f "の2つのルールに分割することができます。
"a b × c d × e f "は、"a b × c d × e f "と "a b c d × e f "の2つのルールに分けることができます。
限定的な否定。式の否定は、"&#172;(OLetter | Upper | Lower | Sep) "のように、単一文字に対するマッチに解決するインスタンスに限定されます。
degeneratesを無視します。Aの後にIndicの合体マークが続くような、実際には決して発生しないような退化したケースに対して、わずかに良い動作を得るための特別な規定はありません。
スクリプト境界。この規則では、文字列の境界は縮退ケースとして扱われるので、文字列 "quaφοβ&#943;α" は単一の単語として扱われ、シーケンス 'a' + '&#2367;' は単一の書記素クラスタとして扱われます。しかし、実装はスクリプトの境界でブレークするための境界テストを自由にカスタマイズすることができます。これが行われる場合、Common/Inherited値は適切に処理される必要があり、ScriptプロパティだけではなくScript_Extensionsプロパティを使用する必要があります。
2 コンフォーマンス

ユーザーが認識したキ ャ ラ ク タ ・ 単語 ・ 文に対応す る テ キ ス ト 要素を分割す る 方法は さ ま ざ ま な方法があ り 、 Unicode 規格は、 実装が こ れ ら の分割を生成で き る 方法を制限 し てい ません。

こ の仕様はデフ ォル ト 機構を定義 し てお り 、 よ り 洗練 さ れた実装では、 特定の ロ ケールや環境に合わせてそれを調整す る こ と がで き ます。た と えば、 タイ語・ラオス語・中国語・日本語などの言語で単語の境界を確実に検出するには、英語のハイフネーションに類似した辞書検索を使用する必要があります。したがって、実装は、この附属書で説明されているデフォルトのメカニズムをオーバーライドまたはサブクラス化する手段を提供する必要があるかもしれません。テーラリングは、ここで指定されたデフォルトと比較して、境界位置を追加したり、境界位置を削除したりすることができることに注意してください。

備考

境界抑制を含む局所的な境界指定は、LDML [UTS35]で表現することができます。調整は Common Locale Data Repository [CLDR] で利用可能です。
追加の絵文字 zwj シーケンスの最適なセグメンテーション動作を実現するためには、ルールとデータにいくつかの変更が必要である [UTS51]。実装では、CLDRの最新バージョンの拡張テキストセグメンテーションルールを使用することが強く推奨されます。
正準等価性を維持するために、以下のすべての仕様は、Unicode標準付属書#15「Unicode正規化形式」[UAX15]で定義されているように、NFD形式で正規化されたテキスト上で定義されています。境界は、形式 NFD で正規化されていないテキストの中に、それが NFD テキス ト内の対応する位置で発生する場合にのみ存在します。しかし、デフォルト規則は、非NFDテキストに対して同等の結果を提供するように書かれており、直接適用することができる。テーラードルールの場合でも、NFDを使用することの要件は論理的な仕様にすぎない；実際には、実装は正規化を避けて同じ結果を得ることができる。詳細については、セクション6「実装上の注意」を参照のこと。

3 グラフェンクラスターの境界

ユーザーが「文字」と考えているもの、つまり言語のための筆記体系の基本単位は、単なる単一の Unicode コードポイントではないことを認識することが重要です。むしろ、その基本単位は複数の Unicode コード点から成り立っている可能性があります。コンピュータによる「文字」という用語の使用とのあいまいさを避けるために、これはユーザーが認識した文字と呼ばれています。た と えば、 「G」 + グレイブアクセントはユーザーが認識しているキ ャ ラ ク タ です。このようなユーザーが認識する文字は、プログラムで決定することができる書記素クラスタと呼ばれるもので近似されています。

グレープフィーム・クラスターの境界は、照合、正規表現、UI インタラクション、縦書きテキストのセグメンテーション、頭文字スタイリングの境界の識別、テキスト内の「文字」位置のカウントなどに重要です。単語の境界、線の境界、および文の境界は、グレープフィーム・クラスタ内では発生してはならない：言い換えれば、グレープフィーム・クラスタは、これらの他の境界を決定するプロセスに関して、原子的な単位であるべきである。

ユーザーが関心を持つ限り、テキストの基礎となる表現は重要ではありませんが、編集インターフェースがユーザーが文字として考えるものの統一された実装を提示することは重要です。グレープフェムクラスタは、デフォルトでは、ドロップキャップの書式設定、テキストの選択、矢印キーの移動やテキストのバックスペースの実装などの処理のために、単位として扱うことができます。例えば、書記素クラスタがベース文字＋アクセントからなる文字列で内部的に表現されている場合、右矢印キーを使用すると、ベース文字の先頭から最後のアクセントの最後までスキップされます。

このドキュメントでは、書記素クラスタのデフォルト仕様を定義しています。特定の言語、操作、またはその他の状況に合わせてカスタマイズすることができます。例えば、矢印キーの動きを言語によって調整したり、個々のコンポーネントを編集することが有用な状況では、特定のフォントに固有の知識を使用して、より細かい方法で動くようにすることができます。これは、例えば、タイ北部のタイ文字タイタム（Lanna）の複雑な編集要件に適用できます。同様に、状況によっては、要素ごとに書記素クラスタ要素を編集することが好ましい場合があります。例えば、あるシステムでは、バックスペースキーはコードポイントごとに削除し、deleteキーはクラスタ全体を削除することができます。

さらに、書記素クラスタとキーボード上のキーとの間には、一対一の関係は存在しない。キーボード上の単一のキーは、書記素クラスタ全体、書記素クラスタの一部、または複数の書記素クラスタのシーケンスに対応している場合があります。

グレープフィーム・クラスターは、カーソルを配置する場所のおおよその目安を提供するだけです。カーソルの詳細な配置は、テキスト編集フレームワークに依存します。テキスト編集フレームワークは、低レベルのテキストレンダリングエンジンとフォントから提供される情報に基づいて、グリフのエッジがどこにあるか、そしてそれらがどのように基礎となる文字に対応しているかを決定します。例えば、テキスト編集フレームワークは、ディグラフがフォント内で単一のグリフとして表現されているかどうかを知っていなければならず、そのため、カーソルをその2つの構成要素を分離する適切な位置に配置することができないかもしれません。このフレームワークはまた、2つのグリフが重なっている場合の表示表現を決定することもできなければなりません。これは、一般的には文字が後続のノンスペーシングマークとともに表示される場合に当てはまりますが、複雑なスクリプトレンダリングの場合には詳細に決定する必要があります。カーソル配置に関しては、スクリプトの最小公約分母フォントを用いたカーソル配置のおおよそのガイドを提供できるのは、書記素クラスタの境界だけです。

プログラマーがエンドユーザーにユーザーが感じる文字数を提供する必要がある比較的まれな状況では、その文字数は、グレープフェムクラスタの境界で区切られたセグメントの数に対応しなければなりません。詳細については、 Unicode Technical Standard #10 「Unicode Collation Algorithm」 [UTS10] や Unicode Technical Standard #18 「Unicode 正規表現」 [UTS18] を参照してください。

Unicode 規格では、書記素クラスタの境界を決定するためのデフォルトのアルゴリズムを提供しており、2 つのバリエーションがあります：レガシー書記素クラスタと拡張書記素クラスタです。最も適切なバリアントは、関係する言語と操作に依存します。しかし、拡張された書記素クラスタ境界は一般的な処理のために推奨され、一方、レガシー書記素クラスタ境界は、主にこの仕様の以前のバージョンとの後方互換性のために維持されています。

これらのアルゴリズムは、特定のロケールのために、または照合仕立て表で使用される縮約のような他のカスタマイズのために調整された書記素クラスタを生成するために適応させることができる。表1aに、これらの概念間の相違点のいくつかの例を示す。これらの例は説明のためのものであり、グレープフィーム・クラスターを構成するものは、問題の特定のテーラーリングで使用されるカスタマイズに依存します。

表 1a. グレープフィーム・クラスターの例

元キャラコメント
グレープフェムクラスタ（レガシーとエクステンデッドの両方
g&#776; 0067 ( g ) LATIN SMALL LETTER G
0308 (&#9676;&#776; ) COMBINING DIAERESIS コンビネーション文字列

&#3585; 0E01（&#3585; ）タイキャラクターコーカイ タイコウ
拡張された書記素クラスタ

&#3585;&#3635; 0E01（&#3585; ）タイキャラクターコーカイ
0E33 (&#3635;) タイキャラクターサラアム タイカム
&#2359;&#2367; 0937（&#2359;） デバナガリレターSSA

レガシー grapheme クラスター

&#2359; 0937（&#2359;） デヴァナガリ・レター・エスエスエー デヴァナガリ・エスエスエー

テーラードされた書記素クラスタ
CH 0063 ( C ) LATIN SMALL LETTER C
0068 ( h ) LATIN SMALL LETTER H スロバキア語のディグラフ
k&#695; 006B ( k ) LATIN SMALL LETTER K

&#2325;&#2381;&#2359;&#2367; 0915（&#2325;&#2381;&#2359;&#2367; 0915） デバナガリレターカ

0937（ &#2359;） デバナガリレターSSA

こちらも参照してください。私の文字はどこにありますか？」およびUCDファイルNamedSequences.txt [Data34]も参照してください。

レガシー grapheme クラスタは、基底部（A やカなど）の後にゼロ文字以上の継続文字が続くものとして定義されます。これを「スタック」を形成する文字のシーケンスと考えるのも一つの方法です。

ベースは、単一の文字であってもよいし、Unicode標準のD133で定義されているように、ハングル音節を形成するハングル文字のシーケンスであってもよいし、一対のRegional_Indicator (RI)文字であってもよい。RI文字の詳細については、[UTS51]を参照してください。

継続するキ ャ ラ ク タ には、 非間隔記号、 印字系言語で使われる Join_Controls （U+200C ZERO WIDTH NON-JOINER と U+200D ZERO WIDTH JOINER）、および正準等価性を確保するためのいくつかの間隔結合記号が含まれています。バングラ、クメール、マラヤーラム、オディヤでは、子音の後に、ビラマや他の結合記号の前に ZWNJ が出現する場合があります。これらのケースでは、書記素のクラスターブレイクの機会を提供することはできません。そのため、ZWNJ は Extend クラスに含まれています。どのような文字列のテキストであっても、一連の書記素クラスタに分割することができるように、完全性を保つために追加のケースを追加する必要があります。これらの中には、制御コードや分離された結合マークのような退化したケースがあるかもしれません。

拡張された書記素クラスタは、レガシー書記素クラスタと同じであり、いくつかの他の文字が追加されている。継続する文字は、インディック文字の母音記号の間隔（ただし依存）など、すべての間隔結合記号を含むように拡張されます。例えば、これには、U+093F (&#2367; ) DEVANAGARI VOWEL SIGN Iが含まれます。拡張された書記素クラスタは、レガシー書記素クラスタよりも優先して実装で使用されるべきです。タイ語、ラオス語、およびその他の東南アジアの特定の文字では、視覚単位による編集が一般的に好まれるため、これらの文字では、拡張された書記素クラスタの動作は、従来の書記素クラスタの動作に似ています（ただし、同一ではありません）。

グレープフィーム・クラスターの境界を定義する規則については、第3.1節を参照してください。ハングル音節の構成については、[Unicode]の第3章「適合性」を参照してください。

註：デフォルトのUnicode書記素クラスタ間の境界は、隣接する2つの文字だけで決定することができます。キ ャ ラ ク タ の対の相互作用を示す図については、 第 7 節 「テ ス ト 」 を参照 し て く だ さ い。

デフ ォ ル ト Unicode 書式群 （レガシーと拡張の両方） の主な特徴は、 基になるテ キ ス ト のすべての正準的に等価な形式にわた っ て、 それが変更 さ れない こ と です。したがって、テキストがNFCであろうとNFDであろうと境界線は変更されません。マッチングの基本単位として書記素クラスタを使用することで、正準的に等価なマッチングのための非常に明確で簡単に説明された基礎を提供します。これは検索から正規表現までのアプリケーションにとって重要です。

もう一つの重要な特徴は、デフォルトのUnicode書記素クラスタは、Unicodeのデフォルトの単語や文の境界を決定するプロセスに関しては、原子的な単位であるということです。それらは通常、行の境界に関しては原子単位ですが、常にではありません。詳細については、[UAX14]のセクション9.2 スペース文字のレガシーサポートをマークを結合するためのベースとして使用することを参照してください。

Graphemeクラスターは、さらなる要件を満たすように調整することができる。そのようなテーラーリングは許可されているが、可能な規則はこの文書の範囲外である。そのような仕立ての一例として、多くのインド文字で使用されているアクサラス(aksaras)や正書法の音節が挙げられる。アクサラスは通常、子音で構成されていますが、時には固有の母音を持つ場合もあれば、明示的な従属母音が続く場合もあり、その場合は子音の文字ベースのどの側でもレンダリングが終わる可能性があります。拡張書記素群には、このような単純な組み合わせが含まれます。

しかし、アクサラには、1つ以上の付加的な接頭子音が含まれている場合もあります。このような子音クラスターのアクサラは、拡張書記素クラスターのデフォルトルールには組み込まれていません。インディックスクリプトでは、このようなアクサーラのレンダリングの扱い方にかなりの違いがあります。典型的な液体の子音（または「中音」）であるya, ra, la, la, waは、アクサーラの組み合わせで表示するためにどのように扱われているかは、さらに多様性があります。そのため、アクサラのための調整は、有用なものにするためには、スクリプト、言語、フォント、文脈に特化したものでなければならないかもしれません。

注：フォントベースの情報は、最初の文字段落のスタイリングの境界の特定など、UIの目的で使用する適切な単位を決定するために必要とされるかもしれません。た と えば、 こ の よ う な単位は、 &#1604;&#1575; （ア ラ ビ ア語の lam + alef） の よ う に、 2 つの書記素群で形成 さ れた合字であ る 可能性があ り ます。

Unicode の書記素群の定義はデフ ォル ト であ り 、 適切な場合にはそれに合わせた書記素群のより洗練された定義の使用を排除することを意図したものではありません。そのような定義は、与えられたプロセスに対する個々の言語内のユーザーの期待に、より正確にマッチするかもしれません。たとえば、照合などのプロセスでは、スロバキア語では "ch "が書記素群とみなされるかもしれません。し か し 、 デフ ォ ル ト 定義は、 個々の Unicode コ ー ド 点に よ っ て提供 さ れ る も の よ り も 、 ユーザーがキ ャ ラ ク タ と し て認識す る も のに対するユーザーの期待に対 し て、 全体的に よ り も 正確に一致す る よ う に設計 さ れています。

注記：デフォルトのUnicode書記素クラスタは、以前は "ロケールに依存しない書記素 "と呼ばれていました。クラスタという用語は、言語学では grapheme という用語が異なって使われていることを強調するために使われています。用語を簡単にし、Unicode技術標準#10 "Unicode Collation Algorithm" [UTS10] と整合させるために、default および tailored という用語は、それぞれ local-independent および local-dependent よりも好まれています。

Grapheme Clusters の表示 Grapheme Clusters は表示されません。グレープフィーム・クラスタは合字と同じではありません。たとえば、スロバキア語の grapheme クラスタ "ch" は通常、合字ではありませんし、逆に、合字 "fi" は合字ではありません。デフォルトの書記素クラスタは、必ずしもテキスト表示を反映しているわけではありません。例えば、シーケンス <f, i> は、画面上では単一のグリフとして表示されているかもしれませんが、それでも 2 つの書記素クラスタになります。

正規表現と書記素クラスタのマッチングについての情報は、Unicode Technical Standard #18, "Unicode Regular Expressions" [UTS18]を参照してください。

退化した場合。デフォルトの仕様は、実装が簡単なように設計されていて、書記素クラスタのアルゴリズム決定を提供しています。しかし、実際には発生しないであろうエッジケースをカバーする必要はない。セグメンテーションの目的のために、それらはまた、分離された制御文字や結合マークのような書記素クラスタとして考えられていない退化したケースを含んでもよい。この点では、[Unicode]で定義されている結合文字列や拡張結合文字列とは異なる。また、Unassigned（Cn）コードポイントとPrivate_Use（Co）文字には、潜在的な使用を予測したプロパティ値が与えられています。

文字列とグラ フ ァ イ ム群の組み合わせ。比較のために、表 1b は、正規表現表記を使用して、文字列と書記素クラスタの組み合わせの関係を示しています。交互に与えられた(X|Y)は、最初にマッチしたものが使われることに注意してください。小文字で始まる単純な識別子は、表1cで定義されている変数であり、大文字で始まるものは、表2で定義されているGrapheme_Cluster_Breakプロパティ値である。

表1b. 文字列とグラフェンクラスターの組み合わせ

項レジェックスの注意事項
結合文字列 ccs-base? ccs-extend+ 単一の基底文字は結合文字列ではありません。しかし、単一の合体マークは（退化した）合体文字列である。
拡張結合文字列 extended_base? ccs-extend+ extended_baseにはハングル音節が含まれています。
レガシーグラフフレーズクラスターcrlf
| コントロール
| legacy-core legacy-postcore* 1つの基底文字は1つの書記素クラスタです。退化したケースには、孤立した非ベース文字やコントロールのような非ベース文字が含まれます。
拡張された書記素クラスタ crlf
| コントロール
| 拡張された書記素クラスタは、プリペンディングとスペーシングマークを追加しています。
表1bでは、表1cで定義されているいくつかの記号を使用しています。角括弧と\p{...}は、通常のUnicodeSetの概念を使用して、文字の集合を示すために使用されます。

表 1c. 正規表現の定義

ccs-base := [p\{L}\p{N}\p{P}\p{S}p{Zs}]
ccs-extend := [\p{M}p{Join_Control}]
拡張ベース := ccsベース
| ハングル音節
crlf := CR LF
レガシーコア := ハングル音節
| リ系列
| xpicto-sequence
| 制御CR｜[制御CR LF]
legacy-postcore := [Extend ZWJ]
コア := ハングル音節
| リ系列
| xpicto-sequence
| 制御CR｜[制御CR LF]
postcore := [Extend ZWJ SpacingMark]
プリコア := プリペンド
RI-Sequence := RI RI
ハングル音節 := L* (V+ | LV V* | LVT) T*
| L+
| T+
xpicto-sequence := p{Extended_Pictographic}. (Extend* ZWJ p{Extended_Pictographic})*.

3.1 デフォルトのグラフェンクラスター境界仕様

以下は、グレープヒューム・クラスター境界の一般的な仕様です。

Grapheme_Cluster_Breakプロパティ値の割り当ては、[Props]の対応するデータファイルに明示的に記載されています。そのファイル内の値は、標準的なプロパティ値です。

説明のために、プロパティ値を表2にまとめていますが、文字のリストは例示的なものです。

表 2. Grapheme_Cluster_Break プロパティ値

値のまとめ 文字一覧
CR U+000D キャリッジリターン（CR
LF U+000A LINE FEED (LF)
コントロール General_Category = Line_Separator、または
General_Category = Paragraph_Separator、または
General_Category = 制御、または
General_Category = 未割り当てでDefault_Ignorable_Code_Point、または
一般_カテゴリー = フォーマット
U+000Dキャリーリターンではなく
ではなく、U+000A LINE FEED
ではなく、U+200Cゼロ幅ノンジョイナー(ZWNJ)
U+200D ZERO WIDTH JOINER (ZWJ)ではなく、U+200D ZERO WIDTH JOINERである。
で、Prepended_Concatenation_Mark = Yesではありません。
拡張 Grapheme_Extend = Yes、または
Emoji_Modifier=はい
これには、以下のものが含まれます。
一般_カテゴリー=ノンスペーシング_マーク
一般_カテゴリー=囲い込み_マーク
U+200C ゼロ幅ノンジョイナー
正準等価に必要ないくつかの General_Category = Spacing_Mark を加えたものです。
ZWJ U+200D ZERO WIDTH JOINER
地域別指標（RI） 地域別指標 = Yes

範囲で構成されています。
U+1F1E6 REGIONAL INDICATOR SYMBOL LETTER A
...U+1F1FF 地域指標記号文字Z
Indic_Syllabic_Categoryを前置する = Consonant_Preceding_Repha、または
Indic_Syllabic_Category = 子音_接頭辞、または
Prepended_Concatenation_Mark = Yes
SpacingMark Grapheme_Cluster_Break≠Extend、および
一般的なカテゴリ = スペーシングマーク、または
以下のいずれか（General_Category = Other_Letterを持つ）。
U+0E33 (&#3635; ) タイ文字サラアム
U+0EB3 (&#3763; ) LAO VOWEL SIGN AM

例外。以下のもの（General_Category = Spacing_Mark であり、そうでなければ含まれるもの）は特に除外される。
U+102B (&#4139; ) MYANMAR VOWEL SIGN TALL AA
U+102C (&#4140; ) ミヤンマー母音記号AA

...U+1064 (&#4196; ) ミヤンマルトーンマークスガウカレンケポ

...U+108C (&#4236; ) ミヤンマーサインシャンカウンシルトーン-3

...U+109C (&#4252; ) ミヤンマー母音記号アイトンA

U+1A63 ( ) TAI THAM VOWEL SIGN AA

L ハングル_Syllable_Type=Lなど。
U+1100 (&#4352; ) HANGUL CHOSEONG KIYEOK
U+115F ( ) ハングルチョソンフィラー

V ハングル_音節_タイプ=Vなど。
U+1160 ( ) ハングル・ジュンソンフィラー
U+11A2 (&#4514; ) ハングル・ジュンソンSSANGARAEA

U+D7C6 (&#55238; ) ハングル・ジュンソン・アラエ・イー
T ハングル_Syllable_Type=Tなど。
U+11A8 (&#4520; ) HANGUL JONGSEONG KIYEOK

LV ハングル_シラブル_タイプ=LVでござる。

U+AC38 (&#44088; ) ハングル・シラブル・ギャー
...
LVT ハングル_シラブル_タイプ=LVTでござる。

U+AC02 (&#44034; ) HANGUL SYLLABLE GAGG
U+AC03 (&#44035; ) HANGUL SYLLABLE GAGS
U+AC04 (&#44036; ) HANGUL SYLLABLE GAN
...
E_Base この値は時代遅れで未使用です。
E_Modifier この値は廃止され、未使用です。
Glue_After_Zwj この値は廃止され、未使用です。
E_Base_GAZ (EBG) この値は廃止されており、使用されていません。
Any これはプロパティ値ではありません。

3.1.1 グラフェンクラスター境界規則

規則GB9aとGB9b以外の2つの亜種の書記素クラスタには、同じ規則が使用されています。以下の表に相違点を示しますが、これはルール自体にも記されています。特定の環境でレガシーバリアントが必要な場合を除き、拡張ルールを推奨します。

グレープヘム クラスタ バリアント インクルード エクスクルード
LG: レガシー・グレープヒューム・クラスタGB9a、GB9b
EG: 拡張書記素クラスタGB9a, GB9b
Unicode の書記素クラスタの定義を引用する際には、拡張とレガシーの 2 つの選択肢のどちらを指定しているのかを明確にしなければなりません。

テキストが空でない限り、テキストの最初と最後で改行してください。
GB1 sot ÷ Any
GB2 Any ÷ eot
CRとLFの間でブレークしないでください。それ以外の場合は制御の前後でブレークします。
GB3 CR×LF
GB4(制御｜CR｜LF)÷GB4(制御｜CR｜LF)
GB5 ÷ (制御｜CR｜LF)
ハングルの音節列を崩さないでください。
GB6 L × (L | V | LV | LVT)
GB7 (LV | V) × (V | T)
GB8（LVT｜T）×T
拡張文字やZWJの前にはブレークしないでください。
GB9 × (拡張｜ZWJ)
GB9a と GB9b の規則は、拡張された書記素クラスタにのみ適用されます。
スペーシングマークの前やプリペンド文字の後では改行しないでください。
GB9a × スペーシングマーク
GB9bプリペンド×××××××。
絵文字修飾配列や絵文字 zwj 配列の中で改行しないでください。
GB11 \p{Extended_Pictographic} Extend* ZWJ × ﾟдﾟ{Extended_Pictographic}.
絵文字フラグの列の中で改行しない。すなわち、地域指標（RI）記号の間では、改行点の前に奇数のRI文字がある場合には改行しない。
GB12 sot (RI RI RI)* RI × RI
GB13 [^RI] (RI RI)* RI × RI
そうでなければ、どこでも壊れます。
GB999 任意 ÷ 任意
注意事項。

グレープフェムクラスタ境界は、単純な正規表現に変換することができます。詳細については、項6.3 ステートマシンを参照してください。
Grapheme_BaseおよびGrapheme_Extendプロパティは、Grapheme_Cluster_Breakプロパティの開発よりも前のものです。Grapheme_Extend=Yesの文字の集合は、Grapheme_Cluster_Break=Extendの文字の集合を導出するために使用されます。しかし、Grapheme_Baseプロパティは、グレープヒームクラスターの境界を決定するのに不十分であることが判明した。Grapheme_Baseはこの仕様では使用されなくなりました。
4 単語の境界

単語の境界線は多くの異なる文脈で使われています。最もよく知られているのは、選択（マウスのダブルクリックによる選択、または「次の単語に移動」コントロールの矢印キー）と、検索と置換のためのダイアログオプション「単語全体の検索」です。これらはまた、データベースのクエリでも使用され、要素が互いに一定の単語数以内にあるかどうかを判断するために使用されます。検索では、一致する項目を決定する際に単語境界を用いることもあります。単語の境界線は、空白や句読点に限定されません。実際、いくつかの言語では空白を全く使用しないものもあります。

図1は、サンプルテキストに縦棒でマークされた単語境界の例を示しています。以下の議論では、わかりやすくするために、検索語を角括弧で囲んで示しています。スペースはオープンボックス記号「&#9251;」で示し、検索語と対象テキストの一致部分を色で強調している。

図1. 単語の境界

速い（「茶色い」）キツネは32.3フィートを跳ぶことはできません。
図 1 の単語に隣接する境界線のような境界線は、例えば、全単語検索モードを使用してターゲットテキスト内の用語を検索するときに、ユーザーが期待する境界線です。このモードでは、一致する文字列に加えて、検索語の両側にターゲット テキスト内の単語の境界があれば一致します。図 1 のサンプルターゲットテキストでは、単語全体検索では以下のような結果が得られます。

検索語 [brown] は、両側に単語の境界があるため、一致します。
検索語 [brow] は、ターゲットテキストに 'w' と次の文字 'n' の間に単語の境界がないため、一致しません。
検索用語["茶色"]は、引用符とそれを囲む括弧の間に単語の境界があるため、一致します。
また、[("茶色")]という用語も、括弧とそれを囲むスペース文字の間に語句の境界があるので一致する。
最後に、スペースを含む「&#9251;("brown")&#9251;」も、対象文中のスペース文字とその前後の文字との間に単語の境界があるため、一致する。
ユーザーが期待するこのような一致を可能にするために、句読点やスペースなど、通常は単語の一部とはみなされないほとんどの文字の間には、デフォルトで単語の区切りがあります。

単語の境界線は、インテリジェントカットアンドペーストでも使用できます。この機能では、ユーザーが単語境界線上でテキストの選択部分をカットすると、隣接するスペースが1つのスペースに折りたたまれます。例えば、「&#9251;quick&#9251;fox」から「quick」をカットすると、「&#9251;&#9251; fox」が残る。インテリジェントカット＆ペーストでは、このテキストを「&#9251;&#9251; 狐」に折りたたむ。ただし、スペースは個別に扱う必要があり、中央のスペースを「&#9251;&#9251;&#9251; fox」からカットしても、残りの 2 つのスペースは 1 つにはならないはずである。

検索における近接テストでは、例えば "quick "が "fox "の3語以内にあるかどうかを判定する。これは、図 2 のように、空白、句読点、類似文字しか含まない単語は無視して、上記の境界線で行う。このように、近接については、"fox "は "quick "の３語以内である。この同じ手法は、「次の単語/前の単語を取得する」コマンドやキーボードの矢印キーにも使用できる。文字は、「重要な」単語を決定するために使用することができる唯一の文字ではなく、異なる実施形態では、数字などの他のタイプの文字を含むか、または文字の他の分析を行うことができる。

図2. 抽出された単語

褐色の狐は右32.3フィートをジャンプすることはできません
単語の境界線は線の境界線と関連していますが、区別されています：線の境界線ではない単語の境界線もあれば、その逆もあります。線の境界は通常は単語の境界ですが、SHY（ソフトハイフン）を含む単語のような例外もあります。

他のデフォルト仕様と同様に、実装は、異なる環境や特定の言語の要件を満たすために結果をオーバーライド（調整）することができます。いくつかの言語では、選択と全単語検索のために、異なる独自の改行ルールが必要になるかもしれません。

特に、Contingent_Break（CB）、Complex_Context（SA/東南アジア）、Unknown（XX）のLine_Breakプロパティ値を持つ文字には、本附属書の範囲外の基準に基づいてWord_Breakプロパティ値が割り当てられている。つまり、中国語やタイ語のような言語を満足に扱うためには、特別な処理が必要です。

4.1 デフォルトの単語境界指定

以下は、単語の境界に関する一般的な仕様です。

Word_Breakプロパティ値の割り当ては、[Props]内の対応するデータファイルに明示的に記載されています。このファイルの値は、標準的なプロパティ値です。

説明のために、プロパティ値を表 3 にまとめていますが、文字のリストは例示的なものです。

表 3. Word_Breakプロパティ値

値のまとめ 文字一覧
CR U+000D キャリッジリターン（CR
LF U+000A LINE FEED (LF)
ニューライン U+000B LINE TABULATION
U+000C フォームフィード（FF
U+0085 ネクストライン（NEL
U+2028 ラインセパレータ
U+2029 パラグラフセパレータ
拡張 Grapheme_Extend = Yes、または
一般的なカテゴリ = スペーシングマーク、または
Emoji_Modifier=はい
U+200D ZERO WIDTH JOINER (ZWJ)ではなく、U+200D ZERO WIDTH JOINERである。
ZWJ U+200D ゼロ幅ジョイナー
地域別指標（RI） 地域別指標 = Yes

範囲で構成されています。
U+1F1E6 REGIONAL INDICATOR SYMBOL LETTER A
...U+1F1FF 地域指標記号文字Z
フォーマット一般_カテゴリー = フォーマット
ではなく、U+200B ZERO WIDTH SPACE (ZWSP)である。
ではなく、U+200Cゼロ幅ノンジョイナー(ZWNJ)
U+200D ZERO WIDTH JOINER (ZWJ)ではなく、U+200D ZERO WIDTH JOINERである。
カタカナ文字＝カタカナ、または
のいずれかを選択してください。

U+3032 (&#12338; ) 音声付きのバーティカルカナリピート

U+3034 (&#12340; ) バーティカルカナ・リピート・ウィズ・ヴォイスド・サウンド・マーク上半身
U+3035 (&#12341; ) バーティカルカナ リピートマーク下半分

U+30A0 (&#12448; ) カタカナ・ヒラガナ・ダブルハイフン
U+30FC ( ー ) 片仮名・平仮名プロロングサウンドマーク
U+FF70 ( ー ) 半幅片仮名平仮名長音マーク
ヘブライ語の文字スクリプト = ヘブライ語
と一般的なカテゴリ=その他の文字
アルファベット＝はい、または
のいずれかの文字を使用してください。

...U+02C5 (&#709; ) MODIFIER LETTER DOWN ARROWHEAD
U+02D2 (&#722; ) MODIFIER LETTER CENTRED RIGHT HALF RING
...U+02D7 (&#727; ) MODIFIER LETTER MINUS SIGN

U+02E5 (&#741; ) MODIFIER LETTER EXTRA-HIGH TONE BAR
...U+02EB (&#747; ) MODIFIER LETTER YANG DEPARTING TONE MARK

U+055B (&#1371; ) アルメニアのエンファシスマーク
U+055C (&#1372; ) ARMENIAN EXCLAMATION MARK

U+A708 (&#42760; ) MODIFIER LETTER EXTRA-HIGH DOTTED TONE BAR
...U+A716 (&#42774; ) MODIFIER LETTER EXTRA-LOW LEFT-STEM TONE BAR
U+A720 (&#42784; ) 変調器文字ストレス・高音
U+A721 (&#42785; ) MODIFIER LETTER STRESS AND LOW TONE
U+A789 (&#42889; ) MODIFIER LETTER COLON

U+AB5B (&#43867; ) MODIFIER BREVE WITH INVERTED BREVE
とイデオロギー＝なし
とワードブレイク≠カタカナ
と改行≠コンプレックスコンテクスト（SA
とスクリプト≠ひらがな
とワードブレーク≠エクステンド
とWord_Break≠ヘブライ語の文字
Single_Quote U+0027 ( ' ) APOSTROPHE
Double_Quote U+0022 ( " ) QUOTATION MARK
MidNumLet U+002E ( . ) FULL STOP
U+2018 ( ' ) LEFT SINGLE QUOTATION MARK
U+2019 ( ' ) RIGHT SINGLE QUOTATION MARK

U+FF0E ( ． ) FULLWIDTH FULL STOP
ミッドレター U+003A ( : ) COLON (スウェーデン語で使用)
U+00B7 ( - ) ミドルドット
U+0387 ( - ) GREEK ANO TELEIA
U+055F (&#1375; ) ARMENIAN ABBREVIATION MARK

U+FE13 (&#65043; ) PRESENTATION FORM FOR VERTICAL COLONON

U+FF1A ( ： ) FULLWIDTH COLON
MidNum Line_Break = Infix_Numeric、または
のいずれかを選択してください。

U+FF0C ( , ) FULLWIDTH COMMA
U+FF1B ( ; ) FULLWIDTH SEMICOLON
ではなく、U+003A ( : ) COLON
ではなく、U+FE13 (&#65043; ) PRESENTATION FORM FOR VERTICAL COLONON
ではなく、U+002E ( . ) FULL STOP
数値的な改行 = 数値的な改行
または以下のいずれかを選択してください。
U+FF10 (0) FULLWIDTH DIGIT ZERO
U+FF19 (9) FULLWIDTH DIGIT NINE
U+066C (&#1644; ) ARABIC THOUSANDS SEPARATORではなく、U+066C (&#1644; ) ARABIC THOUSANDS SEPARATOR
ExtendNumLet General_Category = Connector_Punctuation、または
U+202F NARROW NO-BREAK SPACE (NNBSP)
E_Base この値は時代遅れで未使用です。
E_Modifier この値は使用されていません。
Glue_After_Zwj この値は廃止され、未使用です。
E_Base_GAZ (EBG) この値は廃止され、未使用です。
WSegSpace General_Category = Zs
とかではなく、ラインブレイク＝接着剤ではない
Any これはプロパティ値ではなく、任意のコードポイントを表すためにルールの中で使用されます。

4.1.1 単語の境界規則

単語境界規則の表は、表 3a に挙げたマクロ値を使用しています。各マクロは、基本的なWord_Breakプロパティ値の繰り返し結合を表し、基本的なプロパティ値と区別するために太字で示されています。

表 3a. 単語境界規則マクロ

マクロを表す
AHLetter (ALetter | ヘブライ語Letter)
MidNumLetQ (MidNumLet | Single_Quote)

テキストが空でない限り、テキストの最初と最後でブレークします。
WB1 sot ÷ 任意
WB2 Any ÷ eot
CRLF内で折れないようにしてください。
WB3 CR×LF
それ以外の場合はニューラインの前後で休憩（CR、LFを含む
WB3a(改行｜CR｜LF)÷WB3a(改行｜CR｜LF)
WB3b ÷ (改行｜CR｜LF)
絵文字ZWJ配列の中でブレークしないでください。
WB3c ZWJ × \p{Extended_Pictographic}.
水平方向のホワイトスペースをまとめておく
WB3d WSegSpace × WSegSpace
sot, CR, LF, 改行の後を除いて、書式と拡張文字を無視します。(6.2項 「無視ルールの置き換え」を参照) これは次のような効果もあります。Any × (Format | Extend | ZWJ)
WB4 X (拡張｜フォーマット｜ZWJ)* →X
ほとんどの文字と文字の間には区切りを入れないでください。
WB5 アルフレッタ×アルフレッタ
特定の句読点をまたいで文字を改行しないでください。
WB6 AHLetter × (MidLetter | MidNumLetQ) AHLetter
WB7 AHLetter（MidLetter｜MidNumLetQ）×AHLetter
WB7a ヘブライ文字×シングルクオート
WB7b ヘブライ文字×ダブルクオートヘブライ文字
WB7c ヘブライ文字ダブルクオート×ヘブライ文字
連続した桁や、文字に隣接した桁（"3a"、"A3"）の中で改行しないでください。
WB8 数値×数値
WB9 アルフレッタ×数字
WB10 数値×アルフレッタ
3.2 "や "3,456.789 "のように、シーケンス内で改行しないでください。
WB11 Numeric (MidNum | MidNumLetQ) × Numeric
WB12 Numeric × (MidNum | MidNumLetQ) Numeric
カタカナの間でブレイクしてはいけません。
WB13 カタカナ×カタカナ
エクステンダーから折れないようにしましょう。
WB13a (AHLetter｜Numeric｜カタカナ｜ExtendNumLet) × ExtendNumLet
WB13b ExtendNumLet × (AHLetter | Numeric | カタカナ)
絵文字フラグの列の中で改行しない。すなわち、地域指標（RI）記号の間では、改行点の前に奇数のRI文字がある場合には改行しないでください。
WB15 sot (RI RI)* RI × RI
WB16 [^RI] (RI RI)* RI × RI
それ以外の場合は、（表意文字の周りも含めて）あらゆるところで折れる。
WB999 Any ÷ Any
注意事項。

言語間ですべての問題を解決したり、与えられた言語内ですべての曖昧な状況を処理したりする、統一されたルールのセットを提供することは不可能です。この付属文書で提示する仕様の目標は、実行可能なデフォルトを提供することであり、カスタマイズされた実装はより洗練されたものになる可能性があります。

タイ語、ラオス語、クメール語、ミャンマー語、および単語間にスペースを使用しない他のスクリプトのために、良い実装は、デフォルトの単語境界仕様に依存すべきではありません。改行にも必要なように、より洗練されたメカニズムを使用すべきです。日本語や中国語などの表意文字はさらに複雑です。ハングルテキストがスペースなしで書かれている場合も同様です。しかし、より洗練されたメカニズムがない場合には、この付属書で規定されているルールは、十分に定義されたデフォルトを提供しています。

単語境界の文脈でのハイフンの正しい解釈は難しいものです。別々の単語がハイフンで接続されることはよくあることです。また、"Smith-Hawkins" のようなハイフン付きの名前もかなりの数があります。単語全体の検索やクエリを実行するとき、ユーザーはこれらのハイフンの中から単語を見つけることを期待します。ハイフンが別々の単語になっている場合もありますが（通常は "resort "ではなく "re-sort "のような曖昧さを解消するため）、全体的にはハイフンをデフォルトの定義から外しておく方が良いでしょう。ハイフンには、U+002D HYPHEN-MINUS、U+2010 HYPHEN、おそらくU+058A ARMENIAN HYPHEN、U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHENが含まれる。

実装は、単語境界によって提供される情報に基づいて構築されてもよい。例えば、スペルチェッカーは、まず、各単語が上記の定義に従って有効であることをチェックし、"out-of-the-box "の４つの単語をチェックする。いずれかの単語が失敗した場合には、複合語を構築し、"reiterate "のように、複合語が辞書に載っているかどうかを（たとえすべての構成要素が辞書に載っていなくても）チェックすることができた。もちろん、高度に屈折した言語や膠着した言語のためのスペルチェッカーには、より洗練されたアルゴリズムが必要になるでしょう。

アポストロフィの使用は曖昧です。通常、アポストロフィは 1 つの単語の一部とみなされますが（「can't」や「aujourd'hui」）、2 つの単語の一部とみなされることもあります（「l'objectif」）。さらに複雑なのは、同じ文字をアポストロフィと引用符として使用することです。したがって、先頭または末尾のアポストロフィは、単語のデフォルトの定義から除外するのがベストです。フランス語やイタリア語などのいくつかの言語では、アポストロフィの後の文字が母音である場合に単語を区切るように調整すると、より多くのケースでより良い結果が得られるかもしれません。これは、ルールWB5aを追加することで行うことができます。

アポストロフィと母音の間の区切り（フランス語、イタリア語）。
WB5a アポストロフィー÷母音
と、アポストロフィーと母音の適切なプロパティ値を定義します。アポストロフィーには、U+0027 ( ' ) APOSTROPHE と U+2019 ( ' ) RIGHT SINGLE QUOTATION MARK (curly apostrophe) が含まれます。最後に、いくつかの音訳スキームでは、アポストロフィは単語の先頭で使用され、特別な仕立てを必要とします。

単語内のコロン(c:a)のような特定のケースは、比較的小さなユーザーコミュニティ(スウェーデン語)に特有のものかもしれませんが、デフォルトでは含まれています。

これは、MidLetterにダブルクォーテーションマークを追加することで実現できます。

書式文字はイニシャルでない場合は含まれます。したがって、<LRM><ALetter>は<letter>の前でブレークしますが、<ALetter><LRM><ALetter>や<ALetter><LRM>にはブレークはありません。

ハイフン、アポストロフ、引用符、コロンなどの文字は、1つ以上の自然言語の単語を表すことを意図した識別子を使用する際に考慮すべきです。UAX31]の第2.4節「特定の文字の調整」を参照のこと。識別子を処理する場合、特にハイフンの扱いは、全単語検索やクエリのために単語分割解析を使用する場合とは異なる場合があります。

通常、単語の分割は、異なるスクリプト間の分割を必要としません。しかし、この機能を追加することは、単語分割の他の拡張機能との組み合わせで有用であるかもしれません。例えば、韓国語では「I live in Chicago."」という文はスペースで区切られた3つのセグメントで書かれています。

&#45208;&#45716; Chicago&#50640; &#49328;&#45796;.
韓国語の基準では、「中」を意味する「&#50640;」のような接尾語は別の単語とみなされます。したがって、上の文は次の5つの単語に分割されます。

&#45208;、&#45716;、シカゴ、&#50640;、&#49328;&#45796;.
最初の2つの単語を分離するには辞書検索が必要ですが、ラテン語のテキスト("Chicago")の場合、文字の境界線に基づいて分離するのは些細なことです。

修飾文字 (General_Category = Lm) は、Alphabetic プロパティの値によって、ほとんどすべて ALetter クラスに含まれています。したがって、デフォルトでは、修飾文字は単語の区切りを発生させず、単語の選択に含まれるべきです。修飾記号 (General_Category = Sk) は ALetter クラスに含まれていないので、デフォルトでは単語の改行が発生します。

以下の文字の一部または全部は、環境によってはMidLetterになるように調整されることがあります。
U+002D ( - ) HYPHEN-MINUS

U+2010 ( - ) HYPHEN
U+2011 ( - ) ノンブレーキングハイフン

U+30A0 (&#12448; ) カタカナ・ヒラガナ・ダブルハイフン
U+30FB ( ・ )カタカナミドルドット
U+FE63 ( - ) SMALL HYPHEN-MINUS
U+FF0D ( - ) FULLWIDTH HYPHEN-MINUS
UnicodeSetの表記では、これ。[\u002D\uFF0D\uFE63\u058A\u1806\u2010\u2011\u30A0\u30FB\u201B\u055A\u0F0B]
例えば、いくつかの書き方では、単語内の音節間にハイフン文字を使用しています。例としては、タイ語の文字で書かれた Iu Mien 言語があります。そのような単語は、選択（「ダブルクリック」）や索引付けなどの目的のためには単一の単語として振る舞うべきであり、ハイフンの上で単語を区切るべきではないことを意味しています。
次の文字の一部または全部がMidNumになるように、環境によっては、&#8364;1 234,56のようにスペースを千の区切り文字として使用する言語に対応できるように調整されるかもしれません。
U+0020 スペース
U+00A0 ノーブレークスペース
U+2007 FIGURE SPACE
U+2008 パンクテーションスペース
U+2009 シンスペース
U+202F NARROW NO-BREAK SPACE
ユニコードセット表記では これ。[\u0020\u00A0\u2007\u2008\u2009\u202F]
4.2 名前の検証

単語の決定に関連して、個人名の検証の問題があります。実装では、個人名が入力されるフィールドを検証する必要があることがあります。目的は、"James Smith-Faley, Jr. "のような文字と"!#@&#9829;≠"のような文字を区別することです。ユーザーは、名前にスペースなどの文字が含まれていても、"di Silva "のような正当な名前を追加できる必要があるからです。一般的に、これらの個人名の検証は言語固有のものであってはなりません。例えば、名前が別の言語であるのに、ある言語でウェブサイトを使用している人がいるかもしれません。名前検証用の基本的な文字セットは、上記の定義に従って単語で許可されている文字と、いくつかの例外的な文字で構成されています。

基本的な名前検証文字

[\p{name=/COMMA/}\p{name=/FULL STOP/}&\p{p}
\♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪
\epp{alpha}
♪\p{wb=Katakana}\p{wb=Extend}\p{wb=ALetter}\p{wb=MidLetter}\p{wb=MidNumLet}P{wb=MidNumLet}P{wb=MidNumLet
[\u002D\u055A\u058A\u0F0B\u1806\u2010\u2011\u201B\u2E17\u30A0\u30FB\uFE63\uFF0D] ]
こ れは基本的な検証用キ ャ ラ ク タ の集合に過ぎないので、 特に以下の点に留意すべきである。

これは甘く、言語に特化したものではないので、許可されている言語が限られている場合や他の環境に合わせて調整することができます。例えば、名前フィールドが分離されている場合は、セットを狭くすることができます。タイトルが許可されていない場合は、"," と "." は必要ないかもしれません。
識別子としては不適切な文字や、単語の一部にはならないような文字も含まれています。また、スウェーデン語の "c:a "のように、広義の単語の一部であっても名前の一部ではない文字や、辞書の単語で使われるハイフネーションポイントなども許可しています。
セキュリティに問題がある場合には、追加のテストが必要になるかもしれません。特に、名前は、それらをNFC 形式に変換し、変換結果の文字が NFKC の下で変化しないことを確実にするための試験を行うことによって検証されるかもしれません。第二のテストは表 5 の情報を使用することです。の情報を使用します。名前に表5にない明示的なスクリプト値を持つ1つ以上の文字がある場合は、その名前を拒否する。
5 文の境界

文の境界線は、しばしばトリプルクリックや、単一の単語よりも大きいテキストのブロックを選択したり、反復したりするために使用されます。また、データベースのクエリで同じ文の中に単語が存在するかどうかを判断するためにも使用されます。

プレーンテキストでは、適切な文の境界を判断するのに十分な情報が得られません。ピリオドは、文の終わりを示したり、省略形を示したり、小数点以下を示すために使われたりします。よほど洗練された分析をしない限り、<? 最初の例では、これらは文の終わりを示していますが、2番目の例ではそうではありません。

彼は「行くのか？ ジョンは首を振った。

"Are you going?" とジョンは尋ねた。
文章を意味論的に分析しない限り、これらの用法のどちらが意図されているのかを確かめることは不可能です（ときには曖昧さが残ることもあります）。しかし、ほとんどの場合、簡単なメカニズムがうまく機能します。

注意：他のデフォルト仕様と同様に、実装は異なる環境や特定の言語の要件を満たすために結果を自由にオーバーライド（調整）することができます。例えば、ロケールに依存する境界抑制の仕様は、LDML [UTS35]で表現することができます。特定の文の境界抑制は、Common Locale Data Repository [CLDR]で利用でき、境界分析の品質を向上させるために使用することができます。

5.1 デフォルトの文境界仕様

以下に、文の境界に関する一般的な仕様を示します。

文区切りプロパティの値の割り当ては、[Props]内の対応するデータファイルに明示的に記載されています。このファイルの値は、標準的なプロパティ値です。

説明のために、プロパティ値を表4にまとめていますが、文字のリストは例示的なものです。

表 4. センテンスブレークのプロパティ値

値のまとめ 文字一覧
CR U+000D キャリッジリターン（CR
LF U+000A LINE FEED (LF)
拡張 Grapheme_Extend = Yes、または
U+200D ZERO WIDTH JOINER (ZWJ)、または
一般_カテゴリー = スペーシング_マーク
9月 U+0085 ネクストライン（NEL
U+2028 ラインセパレータ
U+2029 パラグラフセパレータ
フォーマット一般_カテゴリー = フォーマット
ではなく、U+200Cゼロ幅ノンジョイナー(ZWNJ)
U+200D ZERO WIDTH JOINER (ZWJ)ではなく、U+200D ZERO WIDTH JOINERである。
Sp White_Space = はい
とSentence_Break≠9月
とセンテンスブレーク≠ＣＲ
とセンテンスブレイク≠LF
小文字小文字 = はい
と Grapheme_Extend = No であり、範囲内ではない (Mkhedruli Georgian の場合)
U+10D0 (&#4304;) GEORGIAN LETTER AN
...U+10FA (&#4346;) GEORGIAN LETTER AINと
U+10FD (&#4349;) GEORGIAN LETTER AEN
...U+10FF (&#4351;) GEORGIAN LETTER LABIAL SIGN
上位一般_カテゴリー＝タイトルケース_レター、または
大文字＝はい、範囲外（Mtavruliグルジア語の場合
U+1C90 (&#7312;) GEORGIAN MTAVRULI CAPITAL LETTER AN
...U+1CBA (&#7354;) GEORGIAN MTAVRULI CAPITAL LETTER AINと
U+1CBD (&#7357;) GEORGIAN MTAVRULI CAPITAL LETTER AEN
...U+1CBF (&#7359;) GEORGIAN LETTER MTAVRULI CAPITAL LABIAL SIGN
OLetter Alphabetic = Yes、または
U+00A0 NO-BREAK SPACE (NBSP)、または

と下＝なし
と上段＝なし
とセンテンスブレーク≠エクステンド
数値的な改行 = 数値的な改行
または以下のいずれかを選択してください。
U+FF10 (0) FULLWIDTH DIGIT ZERO
U+FF19 (9) FULLWIDTH DIGIT NINE
ATerm U+002E ( . ) FULL STOP

U+FF0E ( ． ) FULLWIDTH FULL STOP
SContinue U+002C ( , ) COMMA
U+002D ( - ) HYPHEN-MINUS
U+003A ( : ) COLON

U+2013 ( - ) EN DASH
U+2014 ( - ) EM DASH
U+3001 ( 、 ) IDEOGRAPHIC COMMA
U+FE10 (&#65040; ) バーティカルコンマの表現形式
U+FE11 (&#65041; ) 立体視幾何学的コンマの表現形式
U+FE13 (&#65043; ) PRESENTATION FORM FOR VERTICAL COLONON
U+FE31 (&#65073;) 立体EMダッシュ用プレゼンテーションフォーム
U+FE32（ &#65074; ）縦型エンダッシュの表示形式

U+FE58 ( - ) SMALL EM DASH
U+FE63 ( - ) SMALL HYPHEN-MINUS
U+FF0C ( , ) FULLWIDTH COMMA
U+FF0D ( - ) FULLWIDTH HYPHEN-MINUS
U+FF1A ( ： ) FULLWIDTH COLON
U+FF64 ( 、 ) HALFWIDTH IDEOGRAPHIC COMMA
STerm センテンス_ターミナル = はい
閉じる General_Category = Open_Punctuation、または
一般_カテゴリー = Close_Punctuation、または
改行＝引用

とATerm＝なし
とSTerm＝なし
Any これはプロパティ値ではありません。規則では、任意のコードポイントを表すために使用されます。

5.1.1 文の境界規則

文境界規則の表は、表4aに列挙されているマクロ値を使用します。各マクロは、基本的なSentence_Breakプロパティ値の繰り返し結合を表し、基本的なプロパティ値と区別するために太字で示されています。

表 4a. 文区切りルールのマクロ

マクロを表す
パラセプ (9月｜CR｜LF)
SATerm (STerm | ATerm)

テキストが空でない限り、テキストの最初と最後でブレークする。
SB1 sot ÷ 任意
SB2 Any ÷ eot
CRLF内で折れないようにしてください。
SB3 CR×LF
段落区切りの後にブレイク
SB4 パラセプ ÷ ÷ ÷ ÷ ÷ ÷ SB4 パラセプ
sot、ParaSep、CRLF内を除き、FormatとExtendの文字を無視する。(セクション6.2「無視ルールの置き換え」を参照) これは次のような効果もあります。Any × (Format | Extend)
SB5 X (拡張｜フォーマット)* →X
特定の文脈ではフルストップの後にブレークしないでください。以下の注意事項を参照のこと。
SB6 ATerm × 数値
SB7（上｜下）ATerm×上
SB8 ATerm Close* Sp* × (&#172;(OLetter | 上段 | 下段 | ParaSep | SATerm) )* 下段
SB8a SATerm Close* Sp* × (SContinue | SATerm)
文のターミネーターの後で区切りますが、区切りの句読点、末尾のスペース、およびすべての段落区切りを含みます。以下の注意事項を参照のこと。
SB9 SATerm Close* × (Close | Sp | ParaSep)
SB10 SATerm Close* Sp* × (Sp | ParaSep)
SB11 SATerm Close* Sp* ParaSep? ÷
それ以外は壊れないようにしてください。
SB998 Any × Any
注意事項。

ルールSB6-SB8は、図3に示すような文字列の中で、曖昧なターミネータ(主にU+002E FULL STOP)の後の改行を禁止するように設計されています。改行が禁止される文脈としては、数字の直前、大文字と大文字の間、小文字の後に(オプションで特定の句読点の後に)小文字が続く場合、コンマ、コロン、セミコロンなどの特定の継続句読点が続く場合などがあります。これらの規則は、図4に示すような文字列の改行を許可します。これらのルールは、"...Mr. Jones...." のようなケースを検出することはできません; このようなケースを検出するには、より洗練されたテーラーリングが必要です。
ルールSB9-SB11は、以下の形式のシーケンスの後での改行を許可するように設計されていますが、その中での改行は許可しません。
(STerm | ATerm) Close* Sp* (Sep | CR | LF)?
異常なケースでは、(第4節の単語境界に従って決定された)単語セグメントが(第5節の文境界に従って)文の改行にまたがることがあることに注意してください。単語境界と文境界の間の不整合は、通常は単語と単語の間にスペースを必要としないスクリプトの文字にピリオドが続くかどうかを考慮に入れるようにSB11をカスタマイズすることで減らすことができます。
ユーザーは、インタラクティブなオンラインデモで実験を実行して、与えられたテキストのデフォルトの単語と文の境界を観察することができます。
図3. "." の禁断の改行

C. D
3. 4
U. S.
... resp. リーダーは...
...等）' '(the ...
図4. "上の許可されたブレーク"

彼女は "See spot run. "と言った。 ジョンは頭を振った。...
它&#20204;指......etc. 它&#20204;指...
...理数字。 它&#20204;指...

6 実装上の注意事項

6.1 正規化

境界指定は、正規化フォーム NFD に従って正規化されたテキストの観点から述べられている（Unicode 標準付属書#15 "Unicode 正規化フォーム" [UAX15] を参照）。実際には，入力の正規化は必要ない。正準的に等価なテキストに対して同じ結果が返されることを確実にするために（つまり、同じ境界位置が見つかることになるが、それらは異なるオフセットによって表されるかもしれない）、書記素クラスタ境界指定は次の特徴を持っている。

一連の非間隔マークの中には決して切れ目がありません。
基底文字とそれに続くノンスペーシングマークの間には決して区切りがありません。
また、この仕様では、特定の構成に対応するために、U+09BE ( ) BENGALI VOWEL SIGN AA のような特定の文字に明示的に Extend プロパティ値を割り当てることで、特定の問題を回避しています。

他のデフォルトの境界指定は、書記素クラスタ内では破断することはなく、各書記素クラスタ全体に対して常に一貫したプロパティ値を使用します。

6.2 無視ルールの置き換え

デフォルトの単語と文の仕様のための重要なルールは、ExtendとFormatの文字を無視します。この規則の主な目的は、ある書記素クラスタを常に1つの文字として、つまりクラスタの最初の文字であるかのように扱うことです。単語指定も文指定も、L, V, T, LV, および LVT を区別するものではありません。さらに、CRLF内でのブレークを禁止するための特定のルールがある。そのため、Extend を無視するだけで、書記素クラスタ内での改行を許可しないようにするには十分です。フォーマット文字もデフォルトでは無視されます。

無視」ルールは、ルールに次のような変更を加えることと等価です。

Ignore" ルールを以下のように置き換えて、シーケンス内での改行を許可しないようにします (CRLF と関連する文字の後を除く)。
元の変更点
X (Extend | フォーマット)*→X ⇒ (&#172;Sep) × (Extend | フォーマット)
それ以降のすべての規則では、否定（&#172;(OLetter | Upper ...）のような場合を除き、すべての境界プロパティ値の後に (Extend | Format)*を挿入します。(最終プロパティの後、ブレークシンボルの右側にあるプロパティの後にこれを行う必要はありません)。例えば、以下のようになります。
オリジナル 修正済み
X Y × Z W ⇒ X (拡張｜フォーマット)* Y (拡張｜フォーマット)* × Z (拡張｜フォーマット)* W
X Y × ⇒ X (拡張｜フォーマット)* Y (拡張｜フォーマット)* × × × ⇒ X (拡張｜フォーマット)* Y (拡張｜フォーマット)
1 つの文字に解決する代替式は、全体として扱われます。例えば、以下のようになります。
オリジナル 変更された
(STerm｜ATerm) ⇒ (STerm｜ATerm) (Extend｜Format)*.
とは解釈されません。
&#8655; (STerm (Extend | Format)* | ATerm (Extend | Format)*)と解釈されません。
注意: "無視" ルールが (Extend | Format) の代わりに (Extend | Format | ZWJ) のように異なるセットを使用している場合、対応する変更は上記の置き換えで行われます。

無視」ルールは、Format 文字の一部を他のクラスにリマップすることを除いて、テーラーリングによって上書きされるべきではありません。

6.3 ステートマシン

表1b「文字列とグレープフェムクラスタの結合」のように、グレープフェムクラスタの規則は、正規表現に簡単に変換することができます。これは、既知の境界（テキストの開始位置など）から始まって評価されなければならず、次の境界位置を決定する。結果として得られる正規表現は、規則が行うのと同じ境界をすべて認識する高速で決定論的な有限状態マシンを生成するために使用することもできます。

正規表現への変換は、書記素クラスタ境界については非常に簡単です。単語や文の境界や、より複雑な行の境界を変換するのはそれほど簡単ではありません[UAX14]。しかし、それらの規則を、規則が行うのと同じ境界をすべて認識する高速で決定論的な有限状態マシンに変換することも可能である。ICUライブラリにおけるテキストセグメンテーションの実装は、その戦略に従っています。

Unicode正規表現の詳細については、Unicode技術標準#18「Unicode正規表現」[UTS18]を参照してください。

6.4 ランダムアクセス

ランダムアクセスは、さらなる複雑さをもたらします。文字列を最初から最後まで繰り返し処理する場合、正規表現やステートマシンがうまく機能します。各境界から次の境界を見つけるのは非常に高速です。ルールの同じ仕様から逆方向の状態表を構築することで、逆反復が可能になります。

しかし、テキスト中のランダムな点から開始して反復処理を行いたい、テキスト中のランダムな点が境界かどうかを検出したいとします。開始点が、正しいルールのセットを適用するのに十分なコンテキストを提供していない場合、有効な境界点を見つけることができない可能性があります。例えば、「&#9251;&#9251;you&#9251;there?&#9251;&#9251;&#9251;No,&#9251;I'm&#9251;not」のクエスチョンマークの後の最初のスペースをクリックしたとする。文の境界を探索する前方反復では、「?」がまだ見えていないため、「N」の前の境界を見つけることができない。

安全な」出発点を決定するための第二の規則が解決策を提供する。安全な出発点が見つかるまで、この2番目のルールを使って後方に反復処理を行い、そこから前方に反復処理を行います。安全な出発点と出発点の間にある境界を見つけるために、前方に反復処理を行います。希望する境界は、始点よりも小さくない最初の境界である。安全規則は、出発点が何であっても正しく機能するように設計されていなければならないので、境界を見つけるという点では保守的でなければならず、小さなコンテキスト（数個の隣接する文字）によって決定できる境界のみを見つけなければなりません。

図5. ランダムアクセス

ランダムアクセス図

この処理は、検索のたびに実行しなければならない場合、かなりのパフォーマンスコストがかかります。しかし、この機能はイテレータオブジェクトにまとめることができ、イテレータオブジェクトは現在有効な境界点にあるかどうかの情報を保持します。テキスト内の任意の場所にリセットされた場合にのみ、この余分なバックアップ処理が実行されます。イテレータは、すでにトラバースしたローカル値をキャッシュすることもあります。

6.5 テーラリング

ルールベースの実装は、コードベースまたはテーブルベースのテーラーリング機構と組み合わせることもできます。典型的なステートマシンの実装では、例えば、ユニコード文字は、典型的には、文字を境界プロパティ値にマッピングするマッピングテーブルに渡されます。このマッピングは、トリのような効率的なメカニズムを使用することができます。境界プロパティ値が生成されると、それはステートマシンに渡されます。

最も簡単なカスタマイズは、文字マッピングテーブルから出てくる値を調整することです。例えば、与えられた言語の適切な引用符を、文の境界プロパティ値Closeを持つものとしてマークするために、異なる引用符に対して人工的なプロパティ値を導入することができる。これらの人工的な文字プロパティ値を実際のプロパティ値にマッピングするために、メインマッピングテーブルの後にテーブルを適用することができます。言語を変更するには、別の小さなテーブルが代用されます。実際のコストは、配列のルックアップが余分に発生するだけです。

コードベースのテーラーリングのために、プロパティ値の別の特別な範囲を追加することができます。どのような特別なプロパティ値でも、ステートマシンが停止して特定の例外値を返すように、ステートマシンが設定されています。この例外値が検出されると、上位プロセスは、例外値が何であれ、それに応じて特殊なコードを呼び出すことができます。これはすべて、呼び出し側に透過的になるようにカプセル化することができます。

例えば、タイ文字を特殊なプロパティ値にマッピングすることができます。ステートマシンがこれらの値のいずれかで停止すると、タイ語の単語区切りの実装が内部的に呼び出され、それに続くタイ文字の文字列内に境界線が生成されます。これらの境界線はキャッシュされ、次の境界線または前の境界線を呼び出すと、単にキャッシュされた値を返すだけで済むようになります。同様に、ラオス文字を別の特殊なプロパティ値にマッピングして、別の実装を呼び出すこともできます。

7 テスト

ユニコードに準拠した実装は、これらのデフォルト境界を実装する必要はありません。他のデフォルト仕様と同様に、実装は、異なる環境や特定の言語の要件を満たすために、結果を自由に上書き（調整）することができます。この附属書で指定されているようにデフォルトの境界を実装していて、その実装がその仕様と一致していることを確認したい人のために、3つのテストファイルが[Tests29]で利用できるようになっています。

これらのテストは、可能な組み合わせの数が多いため、網羅的なものではありませんが、各値に代表的な文字を用いて、プロパティ値のすべてのペアをテストするサンプルを提供しています。

Charts29]にあるチャート形式で様々な組み合わせを示すサンプルHTMLファイルも、それぞれについて利用可能です。チャートのヘッダー・セルは、プロパティ値と、それに続く代表的なコード・ポイント番号で構成されています。チャートのボディセルは、行のプロパティ値と列のプロパティ値の間にブレークが発生しているかどうか、ブレークの状態を示します。ブラウザがツールチップをサポートしている場合は、コードポイント番号の上にマウスを置くと、文字名、General_Category、Line_Break、Scriptのプロパティ値が表示されます。改行ステータスにマウスを合わせると、そのステータスを担当するルールの番号が表示されます。

注意: デフォルトの書記素クラスタの場合を除いて、隣接する2つの文字をテストしても、境界を決定するには不十分です。

このチャートの後には、いくつかのテストケースが続くかもしれません。これらのテストケースは様々な文字列で構成されており、各文字のペア間の改行の状態は、改行の場合は青線で、改行以外の場合は空白で示されています。各文字の上にカーソルを置くと（ツールチップを有効にして）、文字名とプロパティ値が表示され、ブレークステータスの上にカーソルを置くと、そのステータスを担当するルールの番号が表示されます。

生成のために機械的に処理された方法のため、テスト規則はこの附属書の規則と正確には一致しません。特に。

ルールは、より多くの正規表現スタイルにキャストされています。
規則 "sot ÷"，"÷ eot"，"÷ Any "は，機械的に追加され，人工的な数字を持つ。
ルールは接頭辞なしで10進数を与えられますので、WB13aのようなルールは13.1のように10進数を使った数字を与えられます。
ルールが複数の部分（行）を持つ場合、それぞれの部分には、次のように 100 分の 1 を使用して番号が付けられます。
21.01) × Ｘ＄ＢＡ
21.02) × $HY
...
treat as" や "ignore" ルールは、この附属書で議論されているように処理され、テストでは見えないルールの変換に反映されます。
この附属書のルールのナンバリングからテストルールのナンバリングへのマッピングは、表5にまとめられています。

表 5. ルールのナンバリング

本附属書のルール テストルール コメント
xx1 0.2 sot (本文開始)
xx2 0.3 eot (本文終了)
SB8a 8.1 レタースタイル
WB13a 13.1
WB13b 13.2
GB999 999.0 任意
ウエブ９９９９
注：規則番号は、この附属書のバージョン間で変更されることがあります。

8 ハングル音節境界の決定

レンダリングでは、JAMOS のシーケンスは一連の音節ブロックとして表示されます。以下のルールでは、任意のジャモスのシーケンス（非標準シーケンスを含む）をこれらの音節ブロックに分割する方法を指定しています。記号L、V、T、LV、LVTは、対応するHangul_Syllable_Typeプロパティ値を表します。

事前に合成されたハングル音節には、2 つのタイプがあります。LVまたはLVTである。音節の境界を決定する際には、LVはハモL Vのシーケンスであるかのように振る舞い、LVTはハモL V Tのシーケンスであるかのように振る舞う。

どのような文字列の中でも、表６に示すような文字の組の間に音節区切りが発生することはない。表6に示した文字以外のすべてのケースでは、ハングルの音節の前後に音節の切れ目が発生する。他の文字については、2つの結合したジャモの間に結合マークがあると、ジャモが音節ブロックを形成するのを防ぐことができます。

表6. ハングル音節のノーブレーク規則

例の間で中断しないでください
Ｌ Ｌ、Ｖ、ＬＶまたはＬＶＴ Ｌ×Ｌ
Ｌ×Ｖ
Ｌ×ＬＶ
Ｌ×ＬＶＴ
V または LV V または T V × V
Ｖ×Ｔ
ＬＶ×Ｖ
ＬＶ×Ｔ
T または LVT T T × T
LVT × T
ジャモ、LVまたはLVT コンビネーションマークL×M
Ｖ×Ｍ
Ｔ×Ｍ
ＬＶ×Ｍ
LVT × M
正規化形NFCにおいても、音節ブロックは、途中に前処理されたハングル音節を含む場合があります。しかし、各よく形成された現代ハングル音節は、L V T? の形で表現することができ、NFC では単一の符号化された文字で構成されます。

音節におけるハングル互換性ジャモの動作については、セクション18.6「[Unicode]のハングル」を参照してください。

8.1 標準韓国語の音節

韓国語の標準音節ブロック。
LVまたはLVTの形をした前置詞のハングル音節はすべて、標準的な韓国語の音節ブロックです。
あるいは、標準的な韓国語の音節ブロックは、チョイソンとチョンソンのシーケンスとして表現されてもよく、オプションでチョンソンが続く。
チョイソンは、欠落している先行子音の代わりになり、チョンソンは欠落している母音の代わりになります。
正規表現表記を使用すると、正規表現で分解された標準韓国語の音節ブロックは次の形式になります。

L+ V+ T*

任意の標準的な韓国語の音節ブロックは、正統的に等価な任意のシーケンスを含むため、やや複雑な形をしており、したがって、プレコンポーズされた韓国語の音節を含む。それらの正規表現は次のような形をしています。

(L+ V+ T*) | (L* LV V* T*) | (L* LVT T*)

現代韓国語で使用されているすべての標準音節ブロックは、<L V T>または<L V>の形をしており、それに相当する1文字の前置詞の形をしています。

古い韓国語の文字は、一連の結合したjamosによって表現されます。Unicode標準では音節の一部として2つのL, V, T文字を許容していますが、KS X 1026-1では単一のインスタンスのみを許容しています。KS X 1026-1に準拠する必要がある実装は、第3.1節「既定のグレープフェムクラスタ境界仕様」のデフォルト規則を適宜調整することができる。

8.2 韓国語の標準音節への変換

標準韓国語の音節ブロックの正規表現にすべて一致しないジャムの列は、チョーソンフィラー (Lf ) とジュンソンフィラー (Vf ) を正しく挿入することで、標準韓国語の音節ブロックの列に変換することができます。テキストの文字列を韓国語の標準音節に変換するには、前述のサブセクション「ハングル音節の境界」で説明したように音節の区切りを決定してから、必要に応じて 1 つまたは 2 つのフィラーを挿入して、図 6 に示すように、各音節を韓国語の標準音節に変換します。

図6. フィラーの挿入

L [^V] → L Vf [^V]
V → [^L] Lf V
Ｔ → [^V] Ｌｆ Ｖｆ Ｔ
図６において、[^X]は、X以外の文字、または文字が存在しないことを示している。

表７において、１行目は標準配列の音節切れを示し、２行目は非標準配列の音節切れを示し、３行目は２行目の配列を各音節にフィラーを挿入して標準形に変換する方法を示している。音節の区切りは、真ん中のドット"-"で示されている。

表7. 韓国語のシラブルブレークの例

シラブルブレイクがマークされたシーケンスシーケンス
1 LVTLVLVLVf Lf VLf Vf T → LVT - LV - LV - LVf - Lf V - Lf Vf T
2 LLTTVVTTVVLLVV → LL - TT - VVTT - VV - LLVVV
3 LLTTVVTTVVLLVV → LLVf - Lf Vf TT - Lf VVTT - Lf VVV - LLVVV
謝辞

Mark Davis は初期バージョンの作成者であり、本附属書の本文に追加および保守を行った。Laureniu Iancu は、バージョン 7.0 から 10.0 への更新を支援した。

Julie Allen、Asmus Freytag、Manish Goregaokar、Andy Heninger、Ted Hopp、伊藤 剛、Martin Hosken、Michael Kaplan、Johan Curcio Lindstr&#246;m、Eric Mader、Otto Stolz、Steve Tolkin、Ken Whistler、および Karl Williamson に感謝します。

参考文献

この附属書の参照については、Unicode標準附属書#41「Unicode標準附属書の共通参照」を参照してください。

変更点

本附属書の前回公開版からの修正点をまとめたものです。

改訂版 37

Unicode 13.0.0用に再発行しました。
一般的な
編集者に Christopher Chapman を追加。
謝辞に Johan Curcio Lindstr&#246;m を追加。
絵文字のプロパティはバージョン13.0のUCDにあるため、不要な[UTS51]への参照を削除しました。
第3節 グラフェンクラスターの境界
ZWNJがグレープフレーズクラスタをブレークしない理由を明確にするためにテキストを追加しました。
表 2, Grapheme_Cluster_Break プロパティ値
コントロールから前置連結マークを除外しました。
第4節 単語の境界
表3、ワードブレークプロパティ値
ALetterにU+02E5...U+02EB、U+055A、U+058A、U+A708...U+A716を追加しました。
ALetterにレビューノートを追加。
MidLetterにU+055Fを追加。
MidLetterにレビューノートを追加。
MidNumにレビューノートを追加。
以前のバージョンの変更点は、それぞれのバージョンに記載されています。

&#169; 2020 Unicode, Inc. All Rights Reserved. Unicode コンソーシアムは、いかなる種類の明示的または黙示的な保証も行わず、誤りや不作為についての責任を負わないものとします。この技術報告書に含まれている、または添付されている情報やプログラムの使用に関連して、またはそれに起因して発生した偶発的および結果的な損害については、一切の責任を負いません。Unicodeの使用条件が適用されます。

UnicodeおよびUnicodeロゴは、Unicode, Inc.の商標であり、いくつかの法域で登録されています。