Re: WCAG 2.2 JISへの追加提案

濱田さん、こんにちは。

Unicode についての質問ですと、unicode@unicode.org というメーリングリスト (英語) 
に出した方がいいかと思います。

こちらでは Ruby でいろいろ実装しました。先ほど確認したところ、Ruby の each_grapheme_cluster 
メソッドで各々の grapheme cluster に長さの制限がなかったみたいです。

Unicode の別の処理 (正規化、https://unicode.org/reports/tr15/) には 
https://unicode.org/reports/tr15/#Stream_Safe_Text_Format で "Stream-Safe 
Text Format" と "Stream-Safe Text Process" 
が定義され、コードポイント数を30以下に制限しています。正規化の場合、実際にデータを変更することなのでそのような定義が追加されたかと思われますが、grapheme 
cluster 
の場合、単語、文、段落などと同様に、長さの制限の必要性が今までなかったのではないかと思われます。

ご参考まで。

よろしくお願いします。   Martin.

On 2026-02-19 10:03, youkidearitai wrote:
> こんにちは。はじめまして。
> 濱田 侑弥といいます。
> tekimenという名前で、プログラミング言語PHPのメンテナーをしています。
> PHPのUnicode周りの整備をしている関係で、ちょっと質問をさせていただいてもよろしいでしょうか。
> いわゆるスレ違いであればもうしわけありません。
> 
> 現在、PHPの書記素クラスター関数(grapheme_*)を整備しているところでして、
> 一つ悩んでいることがあります。
> 
> UAX #29などを参照すると、書記素クラスターのUnicodeコードポイントの上限が無いということらしく、
> 例えば、いわゆるZalgo textなどといった、結合文字を無限にくっつけられるなどの遊びができたりします。
> 一方で、プログラミング言語という立場に立つと、書記素クラスターのコードポイント数に上限がなければ、
> 数万コードポイントの1書記素クラスターも可能であるため、結果うん百Mバイトの1書記素クラスターを送り込むことができます。
> 
> そうなると表示やHTTPリクエストなどといった部分でDoSができてしまうため、
> このコードポイント数を制限したほうがいいのではと思っているのですが、
> 正当な根拠がみあたらなくてどうすればいいか悩んでいます。
> 
> 長くなってしまいましたが、単純に言うと
> 書記素クラスターはコードポイントの制限をかける仕組みをプログラミング言語サイドで作ったほうがいいか？
> になります。
> 
> いきなり長文を送りつけてしまい
> 失礼いたしました。
> 
> ご確認いただけますと幸いです。
> 
> 2026年2月17日(火) 10:07 MURATA <eb2mmrt@gmail.com>:
>>
>> 皆さん、
>>
>> WCAG 2.2 JISの制定が進んでいるのですが、以下の日本独自附属書を提案しています。
>>
>> 村田 真
>> ------------------------------------
>>
>> 附属書 X（規定）
>>
>> 日本語文字レパートリー適合性水準（J / JJ）
>>
>> X.1 目的
>>
>> 本附属書は、ウェブコンテンツに対する読み上げ及び点字変換の可能性を高めるため、日本語文字レパートリーを定義する。
>>
>> Webコンテンツがある日本語文字レパートリーに適合するとは、そのWebコンテンツに含まれるテキストデータのうち、視覚的またはプログラム的に利用者に提示されるものが、その日本語文字レパートリーに含まれることとする。
>>
>> 注記:  テキストデータには、テキストノード、代替テキスト、ARIAのラベル付け属性、および生成されたコンテンツを含む。
>>
>> 本附属書は達成基準A/AA/AAAを変更するものではなく、それに追加する日本語文字レパートリー適合性水準(JとJJ）を定めるものである。
>>
>> 注記: あるWebコンテンツがAAであってJJでもあることがある。Aも満たさないがJJは満たすこともあるし、AAAを満たすがJを満たさないこともある。
>>
>> X.2 適合性水準
>>
>> 本附属書は、文字レパートリーに関する二つの追加適合性水準を定める。
>>
>> JJ水準（公的義務水準）
>> J水準（一般公開水準）
>>
>> X.3 JJ 水準
>>
>> X.3.1 単一コード位置からなる文字
>>
>> JJ 水準では、次に示す ISO/IEC 10646（最新版）のcollection に属する文字のみを使用してよい。
>>
>> Collection 287: COMMON JAPANESE
>>
>> Collection 286: JAPANESE NON IDEOGRAPHICS EXTENSION
>>
>> Collection 371: JIS2004 IDEOGRAPHICS EXTENSION
>>
>> 加えて、次の制御文字を使用してよい。
>>
>> U+0009 CHARACTER TABULATION
>>
>> U+000A LINE FEED
>>
>> U+000D CARRIAGE RETURN
>>
>> X.3.2 IVS の取扱い
>>
>> 基底漢字が上記collectionに含まれる場合、IVD に登録された Variation Selectorを1個後続させる IVS（Ideographic Variation Sequence）を使用してよい。基底漢字とIVSからなるUnicode書記素クラスタ(grapheme cluster)である。
>>
>> X.3.3 絵文字
>>
>> JJ水準では、絵文字の使用は認めない。
>>
>> X.4 J 水準
>>
>> X.4.1 JJとの比較
>>
>> J水準はJJ水準で許すものはすべて許す。
>>
>> X.4.1 単体絵文字の使用
>>
>> J 水準では、単一コード位置からなる絵文字であって、UnicodeにおいてEmoji_Presentationプロパティが Yesと定義されるものを使用してよい。
>>
>> X.4.2 禁止される絵文字シーケンス
>>
>> J水準においても、複数コードポイントからなる絵文字シーケンスは認めない。
>>
>> X.5 適合性の判定単位
>>
>> 本附属書における文字の適合性判定は、Unicode書記素クラスタ（grapheme cluster）単位で行う。
>>
>> --
>>   --
>> 東日本国際大学客員教授
>> 村田 真
>

Received on Friday, 27 February 2026 08:07:38 UTC