[5] ある[[文字]]が[[開始子]]との関係で[DFN[[RUBYB[妨害されている]@en[blocked]]]]とは、 両者の間に他の[[基底文字]]やより[[結合クラス]]の小さな[[結合文字]]が挟まっているために、 両者を[[正準結合]]できないことをいいます。 * 定義 [1] > [[開始子]] [VAR[S]] で始まる文字列において、 [VAR[S]] と文字 [VAR[C]] の間に文字 [VAR[B]] があって、 [VAR[B]] が開始子であるか、 または [VAR[B]] が [VAR[C]] と[DEL[同じ]][INS[[[以上]]の]][[結合クラス]]を有するとき、 この場合に限って、 [VAR[C]] は [VAR[S]] から[DFN[[RUBYB[妨害されている] [blocked]]]]。 () * 訂正 #5 [3] [[Unicode]] 3.0.0 から [[Unicode]] 4.0.1 までは >>1 の定義において 「[VAR[B]] が [VAR[C]] と''同じ''[[結合クラス]]を有する」とされていましたが、これでは問題があることが分かり、 [DFN[[RUBYB[訂正]@en[Corrigendum]] #5]] で「[VAR[B]] が [VAR[C]] ''[[以上]]''の[[結合クラス]]を有する [SRC[>>6]]」 に改められています。 [[Unicode]] 4.1.0 以後これが反映されています。 - [6] [CITE@en-us[Corrigendum #5: Normalization Idempotency]] ([TIME[2011-04-01 06:49:32 +09:00]] 版) - [8] [CITE[Normalization Issue]] ([TIME[2004-10-28 06:57:26 +09:00]] 版) - [9] [CITE@en-us[UAX #15: Unicode Normalization Forms]] ([TIME[2010-09-18 09:52:06 +09:00]] 版) [10] この定義の誤りにより、[[正規化形]] ([[NFC]] など) は何度適用しても結果が変わらないはずでしたが、 実際には2度適用すると結果が変わってしまうことがありました。 [[Unicode Consortium]] はごくごく例外的なケースであって、現実的には存在しない文字列 [SRC[>>8、>>9 11.2]] でのみ発生していたとしています。 [11] [[Unicode]] 4.1 以降は[[強い正規化安定性]]が保証されることになっていますが、 4.1 に先立って行われたこの修正の前後では[[強い正規化安定性]]は成立していません。 また、それ以前から保証される[[弱い正規化安定性]]も結果的に成立していないと言えるかもしれません。 (もっとも、非互換変更が原因ではなく、 同じ版であっても[[正規化]]済みの[[文字列]]を更に[[正規化]]できてしまうという不具合なのですが。) [12] この訂正以前の実装においては、 [[UAX #15]] に厳密に従っていて同様に問題を孕んでいるものと、 (偶然か必然か) 訂正後の仕様と同等の動作をするもののどちらもあったようです [SRC[>>9 11.3]]。 [13] この訂正の影響を受ける[[文字列]]については >>9 に示されています。 * メモ [2] [VAR[B]] が [VAR[C]] を妨害している場合には、 そのままなら[[正準結合]]できても、 [VAR[B]] と [VAR[C]] の順序を入れ替えると正準結合できなくなることがあります。 結合文字列が正準順序で並んでいるときには、 ある文字が妨害されているかどうかの検査は直前の文字を見るだけで行えます。