2009-11-19 11 views
24

PHP में कोई मल्टीबाइट 'प्रीग' फ़ंक्शन उपलब्ध नहीं है, तो क्या इसका मतलब है कि डिफ़ॉल्ट preg_functions सभी एमबी सुरक्षित हैं? PHP दस्तावेज में कोई उल्लेख नहीं मिला।क्या PHP preg_functions multibyte सुरक्षित हैं?

+2

मैं 90% सुनिश्चित करता हूं कि अंडरलिंग सी फ़ंक्शंस हैं, लेकिन इसका मतलब यह नहीं है कि PHP संस्करण मुझे लगता है ... –

उत्तर

23

PCRE उपयोग करने के लिए UTF-8 और अन्य यूनिकोड एनकोडिंग का समर्थन कर सकते की जरूरत है, लेकिन यह संकलन समय पर निर्दिष्ट किया जाना है। man page for PCRE 8.0 से:

PCRE की वर्तमान कार्यान्वयन Perl 5.10 के साथ लगभग बराबर है और यूनिकोड सामान्य श्रेणी गुण UTF-8 एन्कोडेड तार के लिए समर्थन सहित। हालांकि, यूटीएफ -8 और यूनिकोड समर्थन को स्पष्ट रूप से सक्षम किया जाना चाहिए; यह डिफ़ॉल्ट नहीं है। यूनिकोड टेबल यूनिकोड रिलीज 5.1 के अनुरूप है।

PHP वर्तमान में PCRE 7.9 का उपयोग करता है; आपके सिस्टम में पुराना संस्करण हो सकता है।

PCRE lib पर एक नज़र डालें जो PHP 5.2 के साथ आता है, ऐसा लगता है कि यह यूनिकोड गुणों और यूटीएफ -8 का समर्थन करने के लिए कॉन्फ़िगर किया गया है। 5.3 branch के लिए वही।

+1

की तुलना में किसी भी अन्य एन्कोडिंग का समर्थन नहीं करता है, मैं PHP 5.3.0 का उपयोग कर रहा हूं जिसमें पीसीआरई संस्करण 7.9 शामिल है, मैंने पीसीआरई कॉन्फ़िगरेशन फ़ाइल की जांच की है जिसमें यूटीएफ 8 परिभाषा शामिल है, ऐसा लगता है कि preg_funcs सुरक्षित। जानकारी के लिए बहुत बहुत धन्यवाद! – Spoonface

+0

क्या यह निर्धारित करने का एक त्वरित तरीका है कि पीसीआरई का कौन सा संस्करण मौजूदा PHP इंस्टॉलेशन का उपयोग कर रहा है? उदाहरण के लिए मेरा सर्वर PHP 5.5 चला रहा है, लेकिन मैं कैसे बता सकता हूं कि पीसीआरई लाइब्रेरी को किसके साथ संकलित किया गया था? – thatidiotguy

1

नहीं, वे नहीं हैं। उदाहरण के लिए preg_match and UTF-8 in PHP प्रश्न देखें।

+0

स्पष्टीकरण के लिए, 'PREG_OFFSET_CAPTURE' वर्ण ऑफ़सेट के बजाए बाइट ऑफ़सेट उत्पन्न करता है। यह PHP में स्ट्रिंग हैंडलिंग के साथ सुसंगत है लेकिन यह बहुत भ्रमित हो सकता है। –

1

नहीं, आप multibyte string functionsmb_ereg तरह

+3

वे पॉज़िक्स 'ईरेग' फ़ंक्शंस के बहु-बाइट संस्करण हैं, हालांकि, जो पीसीआरई 'प्रीग' फ़ंक्शंस के समान नहीं हैं। – mercator

+0

बेन एस आप मेरे नायक हैं :) मैं बस ग्रंथों को शुद्ध करना चाहता था और पाठ के भीतर äöüß छोड़ना चाहता था। preg_replace ने इसे ठीक से कभी नहीं किया, लेकिन mb_ereg करता है! – Nibbels

+1

जब तक आप/u संशोधक का उपयोग करते हैं, वे मल्टीबाइट सुरक्षित हैं, जब तक कि मल्टीबाइट एन्कोडिंग यूटीएफ -8 है।/u इंजन यूटीएफ -8 – hanshenrik

24

पिक्चर बॉक्स के बाहर utf8 का समर्थन करता है, 'यू' संशोधक के लिए दस्तावेज़ देखें।

चित्रण

echo preg_replace('~\w~', '@', "a\xC3\xA4b"); 

इस गूँज "@@ ¤ @" क्योंकि "\ xC3" और "\ xA4" के रूप में इलाज किया गया (\ xC3 \ xA4 जर्मन पत्र 'ए' के ​​लिए UTF8 एन्कोडिंग है) अलग प्रतीकों

echo preg_replace('~\w~u', '@', "a\xC3\xA4b"); 

(ध्यान दें 'यू') प्रिंट "@@@" क्योंकि "\ xC3 \ xA4" एक ही पत्र के रूप में इलाज किया गया।

+0

वास्तव में? हम्म, मैं रेगेक्स स्ट्रिंग्स के साथ अत्यधिक कुशल नहीं हूं, अगर आपको कोई फर्क नहीं पड़ता कि मैं अपने कुछ preg_ कोड को पोस्ट कर सकता हूं ताकि आप क्या सोच सकें? – Spoonface

+0

आपके संशोधक के लिए बहुत अच्छा, मुझे यह पता नहीं था कि –

1

मेरी और अधिक जटिल preg कार्यों में से कुछ:

(1 क) अक्षरांकीय + अंडरस्कोर उपयोगकर्ता नाम मान्य:

preg_match('/^[A-Za-z][A-Za-z0-9]*(?:_[A-Za-z0-9]+)*$/',$username) 

(1b) संभव UTF विकल्प:

preg_match('/^[A-Za-z][A-Za-z0-9]*(?:_[A-Za-z0-9]+)*$/u',$username) 

(2 ए) ईमेल सत्यापित करें:

preg_match("/^([a-z0-9\+_\-]+)(\.[a-z0-9\+_\-]+)*@([a-z0-9\-]+\.)+[a-z]{2,6}$/ix",$email)) 
,210

(2 बी) संभव UTF विकल्प:

preg_match("/^([a-z0-9\+_\-]+)(\.[a-z0-9\+_\-]+)*@([a-z0-9\-]+\.)+[a-z]{2,6}$/ixu",$email)) 

(3a) को सामान्य नई पंक्तियां:

preg_replace("/(\n){2,}/","\n\n",$str); 

(3 बी) संभव UTF विकल्प:

preg_replace("/(\n){2,}/u","\n\n",$str); 

thse परिवर्तन ठीक दिखते हैं?

+0

ठीक है, तो – Spoonface

+0

जानकारी के लिए चीयर्स मेरा मानना ​​है कि आपकी ईमेल नियमित अभिव्यक्ति ईमेल पते में कहीं भी '..' की अनुमति देगी, जो कुछ है जिसे आपको रोकने के लिए दावों की आवश्यकता है। –

संबंधित मुद्दे