preg_split vs mb_split

Question

In base allo PHP manual, il modificatore u delle espressioni regolari PCRE consente il supporto UTF-8 per il modello e la stringa soggetto.

Considerato ciò, c'è qualche differenza tra l'uso di espressioni PCRE con il modificatore u e le corrispondenti funzioni di stringa multibyte mb_*? (. Supponendo che tutte le stringhe sono UTF-8 codificati)

---

Come esempio, si consideri preg_split vs mb_split: Entrambi

preg_split('/' . $pattern . '/u', $string); 

e

mb_split($pattern, $string); 

sembrano restituire risultati identici. Quindi, quale dovrebbe essere preferito? Ha importanza?

Answer 1

La differenza principale è che preg_ funzioni utilizzano il pcre library, quando i mb_ereg_ funzioni (tra cui mb_split) utilizzare il oniguruma library (usato in Ruby prima della versione 2.0).

La ragione principale è che oniguruma può fare con molteplici codifiche (ASCII, UTF-8, UTF-16 BE UTF-16, UTF-32BE, UTF-32LE, EUC-JP, EUC-TW, EUC-KR , EUC-CN, Shift_JIS, Big5, GB18030, KOI8-R, CP1251, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859 -6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15 , ISO-8859-16) quando pcre non può.

Nota che un sacco di codifiche disponibili per mb_ funzioni come mb_detect_encoding non sono in questa lista (UTF-7, ArmSCII-8, CP866 per esempio) che limita la rilevanza di mb_ereg_ funzioni. (Dal momento che è necessario convertire la stringa in un codifica supportato prima di lavorare su di esso, e di convertire indietro dopo.)

La quota due motori regex più o meno le stesse caratteristiche, tuttavia, è possibile trovare alcune differenze (non esaustiva, in quanto si tratta):

Oniguruma non supporta:

• una lettera classi di personaggi stenografia unicode da scrivere senza parentesi graffe.
  Esempio: \pN è visto come pN, è necessario scrivere: \p{N}
• le classi di caratteri Unicode: Xan, XPS, xSP, XWD
• non sfuggito parentesi quadre in una classe di caratteri: Oniguruma vedere [][] come due carattere vuoto classi, quando pcre vedono una classe di caratteri che contiene ] e [
• la funzione \K
• l'alias \R per ritorno a capo sequenze
• gruppi denominati che utilizzano la sintassi di Python (?P<name>...). Sono consentiti solo (?<name>...) o (?'name'...).
• riferimenti di gruppo con qualcos'altro rispetto alla sintassi Oniguruma: \g<name> (sintassi Perl (?&name) e (?1) o (?R) non sono consentiti).
• backtracking verbi di controllo

PCRE non supporta:

• duplicati gruppi denominati (di default). È necessario utilizzare il modificatore (?J) per attivare questa funzione.
• riferimenti numerati con sintassi \k<...>. È possibile scrivere \k<name> ma non \k<1> o \k<-1>.
• riferimenti indietro a un livello nido specifico. Oniguruma è in grado di farlo utilizzando \k<name+n> dove n è il livello nidificato.

per abbinare nuove righe con il puntino, Oniguruma utilizza il modificatore m, quando PCRE utilizza il modificatore s. Nelle funzioni mb_ereg_, il punto corrisponde alle nuove linee per impostazione predefinita. (Quindi il modificatore m è attivato per impostazione predefinita).

PCRE utilizza il modificatore s per corrispondere a newline con il punto. Il modificatore m si comporta diversamente con PCRE, cambia il significato di ^ e $ da "inizio" e "fine" della stringa a "inizio" e "fine" della linea.

Con Oniguruma, il significato di questi ancoraggi non cambia, corrispondono sempre all'inizio e alla fine della linea. Per abbinare il limite della stringa, utilizza \A e \z disponibile anche con PCRE.

Nota che Oniguruma è stato biforcato per dare a Onigmo (usato nelle attuali versioni di Ruby) che implementa più caratteristiche Perl e elementi sintattici, e che è più simile a PCRE.

Answer 2

Fintanto che si sta lavorando rigorosamente con UTF-8 si andrà bene con entrambi. Se si stava utilizzando un altro charset, si consiglia di utilizzare mb_split() poiché il modificatore u con PCRE non consente di specificare lo charset, trattando invece le stringhe come UTF-8.

Per quanto riguarda il ridimensionamento e la redditività a lungo termine, suggerirei di utilizzare mb_split() dall'inizio in modo da essere coperto nel caso in cui venga utilizzato o richiesto qualcosa di diverso da UTF-8 lungo la strada.