وظائف PHP متعدد البايت سلسلة

Question

واليوم أنا واجهت مشكلة مع strpos() وظيفة فب لأنه عاد كاذبة حتى لو كانت النتيجة الصحيحة الواضح 0. وكان هذا لأنه تم ترميز معلمة واحدة في UTF-8، ولكن الآخرين (الأصل هو معلمة HTTP GET) من الواضح أن لا.

والآن وقد لاحظت أن استخدام وظيفة mb_strpos حل مشكلتي.

وسؤالي الآن هو: هل بحكمة لاستخدام وظائف سلسلة متعدد البايت PHP عموما لتجنب المشاكل أطروحات في المستقبل؟ يجب أن تجنب strpos التقليدية، strlen، ereg، الخ، الخ وظائف في كل شيء؟

ملاحظة: أنا لا ترغب في تعيين mbstring.func_overload العالمية في ملف php.ini، لأن هذا يؤدي إلى مشاكل أخرى عند استخدام مكتبة الكمثرى. أنا أستخدم PHP4.

Answer 1

وذلك يعتمد على الترميز الحرف الذي تستخدمه. في ترميزات حرف بايت واحد، أو UTF-8 (حيث بايت واحد داخل شخصية لا يمكن أبدا أن يكون مخطئا لحرف آخر)، ثم طالما أن سلسلة كنت تبحث في والسلسلة التي تستخدم للبحث في نفس ترميز ثم يمكنك الاستمرار في استخدام وظائف البحث السلسلة العادية.

إذا كنت تستخدم ترميز متعددة البايت غير UTF-8، والذي لا يمنع بايت واحد في حرف من الظهور مثل شخصيات أخرى، ثم انها ليست ابدا آمنة لإجراء بحث سلسلة باستخدام وظائف البحث السلسلة العادية. قد تجد ايجابيات كاذبة. وذلك لأن المقارنة سلسلة PHP في وظائف مثل strpos هي لكل بايت، وباستثناء UTF-8 الذي تم تصميمه خصيصا لمنع حدوث هذه المشكلة، ترميزات متعددة البايت تعاني من مشكلة أن أي بايت اللاحقة في حرف تتكون من قد تتطابق أكثر من بايت واحد جزءا من شخصية مختلفة.

إذا السلسلة كنت تبحث عن في وسلسلة كنت تبحث عن لهي من المحارف المختلفة، ثم تحويل سيكون من الضروري دائما. وإلا ستجد أن لأي سلسلة من شأنها أن تكون ممثلة بشكل مختلف في الترميز الأخرى، فإنه سيعود دائما كاذبة. يتعين عليك أن تفعل هذا التحويل على المدخلات: اتخاذ قرار بشأن ترميز الأحرف التطبيق الخاص بك وسوف تستخدم، وتكون متسقة ضمن التطبيق. أي وقت تتلقى الإدخال في ترميز مختلفة، لتحويل على الطريقة.

Answer 2

وكانت هناك بعض المشاكل مع وظائف * mb_ في إصدارات PHP قبل 5.2. حتى إذا التعليمات البرمجية يجري على منصات متعددة مع الإصدارات المختلفة من PHP، يمكن أن يحدث السلوك الغريب. وعلاوة على ذلك وظيفة strpos mb_ بطيئة نوعا ما، لها لتخطي عدد الأحرف التي تحددها المعلمة تعويض للحصول على موضع البايت الحقيقي استخدامها داخليا. في الحلقات اعتمادا على وظيفة strpos / mb_strpos هذا يمكن أن تصبح عقبة رئيسية.

Answer 3

إذا كنت تستخدم نفس الترميز في كل مكان أنها ليست مشكلة بصفة عامة. يمكنني استخدام UTF-8 لجميع صفحاتي، ولم اجه فعلا هذه المشكلة. في النهاية يتعلق الأمر في الواقع إلى تحديد نفس الترميز للصفحات وقاعدة البيانات.

وعلى سبيل المثال:

header('Content-type: text/html;charset=utf-8');
mysql_query('SET NAMES utf8');

في معظم الحالات وهذا يعني أن جميع مصادر البيانات لتطبيق سيلقي البيانات في نفس الترميز، وبالتالي عليك تجنب هذا النوع من المشاكل.

وهذا سوف يكون كل أفضل بكثير مع ظهور PHP 6، راجع للشغل، لأنه سيتضمن الكامل يونيكود الدعم.

Answer 4

وليس لديك بالضرورة لاستخدام mb_strpos، ولكنك بحاجة للتأكد من أن جميع البيانات في التطبيق الخاص بك هو نفسه: إما mb_string، أو سلسلة عادي في ترميز واحد بعينه. (وعادة ما UTF-8).

إذا عليك التأكد من صفحاتك هي UTF-8، ويتم تفسير الطلبات النموذج الخاص بك كما UTF-8، وقاعدة بيانات UTF-8 مخازن الخاص بك، فإنك سوف تكون عموما موافق. عمليات سلسلة فهرستها (في truncations معينة) يمكن كسر سلسلة UTF-8، وهو أمر مزعج ولكن ليس كارثيا بشكل عام. إذا كنت بحاجة إلى هذا المستوى من الدعم، mb_strings هي الخيار الوحيد الخاص بك (ولكن بالطبع لديك للتأكد من أن جميع أجزاء من التطبيق الخاص بك والمكتبات وPHP نسخة يمكن التعامل معها بشكل صحيح).

وتطوير مواقع التي تتعامل مع يونيكود بشكل صحيح في PHP ليس الكثير من المرح في الوقت الراهن: دعم Unicode الخاص به ضعيف جدا بالمقارنة مع اللغات مثل بيثون و. NET. ومن المؤمل أن PHP6 تحسين الأمور.

Answer 5

وأوصي باستخدام PHP التالية UTF-8 مكتبة:

http://sourceforge.net/projects/phputf8

وتجميع ذلك مع التطبيق الخاص بك يرخي متطلبات التطبيق الخاص بك عن طريق لا تتطلب تمديد المقاطع متعددة البايتات، ولكن لا يزال الحصول على وظائف UTF-8 السلسلة.