mbstring関数を使用するために私のすべてのフレームワークをリファクタリングする必要がありますか?

現在、UTF-8文字セットで作業するには mbstring.func_overload = 7 を使用します。

私は mb _ * 関数を使うためにすべてのfunc呼び出しをリファクタリングすることを考えています。

これが必然だと思いますか、PHP 6以降では、マルチバイトの問題は別の方法で解決されますか?

1
それはあなたが何をするかによって異なります。作業している文字列がすべて平易なASCII文字であれば問題ありません。あなたが mb _ をリファクタリングすることを考えているのは正確です。
追加された 著者 deceze,

2 答え

他の人が作成したライブラリを使用している場合はお勧めしません。ここには3つの理由があります。

  1. オーバーロードすると、オーバーロードが予想されないライブラリの動作が壊れる可能性があります。
  2. 過負荷のない環境でフレームワークが壊れる可能性があります。
  3. オーバーロードに応じて、2つの理由により、フレームワークの将来のユーザーが減少します。

1.の良い例は strlen を使用してHTTPの Content-Length フィールドのバイトサイズを誤って計算したものです。原因は、オーバーロードされた strlen 関数がバイトの数ではなく文字の数を返すことです。実際の世界の問題は CakePHP PHP 5.5 or 5.6 (from mbstring maintainer's mail in 2012 April). So now you should avoid mbstring.func_overload.

さまざまなプラットフォームでmutibyte文字を処理するための推奨ポリシーは、mbstringまたはintlまたはiconv directllyを使用することです。マルチバイト文字を処理するための代替機能が本当に必要な場合は、 function_exists()を使用します。

ケースは Wordpress MediaWiki で確認できます。

  1. WordPress: wp-includes/compact.php
  2. MediaWiki: Fallback Class

Drupal ユニコード.inc )では、mutibyte抽象レイヤーを導入しています。

私は抽象レイヤーが良い考えではないと思う。 その理由は、多くの場合に必要なマルチバイト関数の処理数が10以下であり、マルチバイト関数が使いやすく、これらのモジュールがインストールされていれば、mbstringまたはintlまたはiconvにハンドリングを切り替えるための性能が低下するからです。

マルチバイト文字を処理するための最小要件は mb_substr()で、無効なバイトシーケンスを処理します。 上記のCMSの mb_substr()のフォールバック機能のケースを確認できます。
無効なUTF-8文字を疑問符で置き換えると、mbstring.substitute_characterが表示される

4
追加された
確かに、私はフレームワークをリファクタリングして、必要に応じてmb_ *を使用します
追加された 著者 dynamic,

文字列はutf-8です(もちろん)

はい、もちろんです。あなたが文字列で行うことができる多くのことがあります。 UTF-8はASCIIと下位互換性があります。文字列のASCII文字だけを操作したい場合は、違いがあるかもしれません。それはあなたがする必要があるものに依存します。

いいえという直接的な答えが必要な場合は、すべての関数を過剰な可能性があるので mb _ 関数にリファクタリングするべきではありません。マルチバイトのUTF-8文字列が結果とリファクタにそれに応じて影響を与えるかどうか、ユースケースをチェックする必要がありますか?はい。

1
追加された
PHP - 日本のコミュニティ [ja]
PHP - 日本のコミュニティ [ja]
4 参加者の

このグループではPHPについて話します。 パートナー:kotaeta.com