これら 2 つの関数にはそれぞれの特徴があります。
1. iconv は高速で当然好まれますが、変換できない文字に遭遇すると、そこから切り捨てられるという欠点があります。これにより、トランスコーディング中のコンテンツが理由もなく切り詰められます。
2. mb_convert_encoding 関数は比較的効率が悪いですが、変換できないコンテンツは切り詰められないため、コンテンツの整合性はほぼ維持されます。しかし、コンテンツにスペースが含まれている場合、変換されたコンテンツにもスペースが含まれることがわかりました。このシンボルはまだ完璧ではありません。
これら 2 つの関数を組み合わせて文字をトランスコードするにはどうすればよいですか?
私のアイデアは次のとおりです:
iconv 関数は非常に効率的で組み込み関数であるため、必ず最初に使用してください。 discuz のトランスコーディング機能もこの機能を優先して使用しますが、トランスコーディングが不完全な場合は、mb_convert_encoding を調整して、そのトランスコーディングが不完全であることをどのように判断するかが問題になります。
mb_convert_encoding関数はphp_mbstring拡張子をロードする必要があります
、それがロードされていれば組み込み関数ではないとは言えません
認識できない文字については、iconv選択できる 2 つのスイッチがあり、切り捨てだけではありません
//TRANSLIT 類似の文字に置き換えます
//IGNORE 破棄して続行します
組み込み関数がロードされている場合
認識できない文字については、iconv が提供します 切り捨てだけでなく、選択できるスイッチが 2 つあります
//TRANSLIT 類似した文字に置き換えます
//IGNORE 破棄して続行します
IGNORE 機能も追加されましたが、一部のコンテンツのトランスコーディングはまだ理想的ではありません。
つまり、iconv は動作するが mb_convert_encoding が動作しない、mb_convert_encoding は動作するが iconv が動作しないという場合があります
ロードされている場合
認識できない文字については、iconv が提供します 切り捨てだけでなく、選択できるスイッチが 2 つあります
//TRANSLIT 類似の文字に置き換えます
//IGNORE 破棄して続行します
テスト後、IGNORE がバイパスされる可能性があります(以前許せない目に遭いました) と思ったのですが、一部の文字を変換すると文字が消えてしまいました。
たとえば、「?」記号を gb2312 に変換する場合、iconv は変換しませんでしたが、mb_convert_encoding は変換しました。したがって、どちらにもそれぞれ長所と短所があります。ここでは、それらをより完璧に併用する方法を考えたいと思います。