UTF-8 データを扱うときは、パターンで常にu修飾子を使用します。
/\s/u
そうしないと、パターンが UTF-8 として解釈されないためです。
この場合のように、文字נ
(U+05E0) は UTF-8 で 0xD7A0 でエンコードされます。And\s
は任意の空白文字を表します ( PCREによる):
\s
文字は、HT (9)、LF (10)、FF (12)、CR (13)、およびスペース (32) です。
UTF-8 サポートが追加されたとき、PCRE_UCP と呼ばれる特別なオプションも追加され、\b
US -ASCII 文字だけでなく、Unicode プロパティによって他の Unicode 文字にも一致するようになりました。\d
\s
\w
デフォルトでは、UTF-8 モードでは、値が 128 より大きい文字は \d
、 \s
、または \w
とは一致せず、常に\D
、\S
、および と一致し\W
ます。[…] ただし、PCRE が Unicode プロパティをサポートしてコンパイルされ、PCRE_UCP オプションが設定されている場合、次のように、Unicode プロパティを使用して文字タイプを決定するように動作が変更されます。
\d
一致する任意の文字\p{Nd}
(10 進数)
\s
一致する任意の文字\p{Z}
と HT、LF、FF、CR
\w
\p{L}
または\p{N}
に一致 する任意の文字とアンダースコア
そして、その非改行スペース U+00A0 には区切り文字 ( \p{Z}
) のプロパティがあります。
したがって、パターンはUTF-8モードではありませんが\s
、 UTF-8コードワード0xD7A0の0xA0と一致し、その位置で文字列を分割し、に相当する配列を返すようarray("\xD7", "")
です.
パターンはUTF-8 モードではありませんが、0xA0が0x80 より大きいため、これは明らかにバグです(さらに、0xA0 は 0xC2A0 としてエンコードされます)。バグ #52971 PCRE -Meta-Characters not working with utf-8がこれに関連している可能性があります。