Jak za pomocą preg_replace zamienić tekst, w którym dany znak
powtarza się 2razy lub więcej np:
________test____tes__test_asd
zamienić na:
_test_tes_test_asd
Pozdrawiam
Maniek
(_){2,}
Pozdrawiam,
Arson
Sorki - powinno być tak:
(_{2,})
lub nawet tak:
_{2,}
...zależy jak będzie ci wygodniej podmieniać
Pozdrawiam,
Arson
1)
white (strpos($s, '__') !== false)
{
$s = str_replace('__', '_', $s);
}
2)
$temp = explode('_', $s);
foreach ($temp AS &$t)
{
$t = trim($t, '_');
}
$s = implode('_', $temp);
3)
$s2 = $s[0];
for ($i=1; $i<strlen($s); $i++)
{
if ($s[$i-1] == '_' and $s[$i] == '_') continue;
$s2 .= $s[$i];
}
--
A
$temp = explode('_', '!'.$s.'!');
foreach ($temp AS $i=>$t)
{
if ($t == '') unset($temp[$i]);
}
$s = substr(implode('_', $temp), 1, -1);
--
A
--
A
Podałem 4 dobre odpowiedzi na zadany problem. To, że ich nie rozumiesz to
nie znaczy, że to "śmieci".
Wyrażenia regularne do tak banalnych zadań to armata na muchy. W dodatku
wolna armata. Jeśli tego nie wiesz- marsz do książek...
--
A
> Mam propozycję, abyś nie śmiecił głupotami. Dziękuję.
Mam propozycję, abyś nie psuł wątkowania. Dziękuję.
--
Borys Pogoreło
borys(#)leszno,edu,pl
Pretensje do google. Uważasz, że pisałem ich oprogramowanie? I po co
wcinasz się, gdy koleś wypisuje pierdoły? Rozumiem, że Ty też uważasz,
że zastosowanie jakichś protez czy innych śmieci to super rozwiązanie,
kiedy starczy jeden regex.
Więcej się nie odezwę, bo widzę, że nie ma sensu z takim kimś
dysktuować.
1. Twój kod to śmieci.
2. Regeksy powstały do obsługi takich właśnie problemów.
3. Bzdury o wydajności załatwia prosty test: http://ideone.com/NvOQy -
w PHP 5.3 jest jeszcze lepiej
4. Przynajmniej dwie z Twoich funkcji (funkcji?) są błędne.
5. Jedynym poprawnym rozwiązaniem jest użycie preg_replace()
>> �Mam propozycj�, aby� nie psu� w�tkowania. Dzi�kuj�.
>
> Pretensje do google. Uwa�asz, �e pisa�em ich oprogramowanie?
Czyli jeste� �wiadom problemu, ale masz innych w d*.
> I po co
> wcinasz si�, gdy kole� wypisuje pierdo�y? Rozumiem, �e Ty te� uwa�asz,
> �e zastosowanie jakich� protez czy innych �mieci to super rozwi�zanie,
> kiedy starczy jeden regex.
Oczywi�cie, �e to dobre rozwi�zanie, cho� nie wiem czy akurat w tym
przypadku. Du�o si� nie zyska.
--
Borys Pogore�o
borys(#)leszno,edu,pl
> 5. Jedynym poprawnym rozwi�zaniem jest u�ycie preg_replace()
A �r�d�o takiej niezachwianej pewno�ci, to...?
Może akurat nie mam nic innego pod ręką?
>
> > I po co
> > wcinasz si , gdy kole wypisuje pierdo y? Rozumiem, e Ty te uwa asz,
> > e zastosowanie jakich protez czy innych mieci to super rozwi zanie,
> > kiedy starczy jeden regex.
>
> Oczywi cie, e to dobre rozwi zanie, cho nie wiem czy akurat w tym
> przypadku. Du o si nie zyska.
>
Mam nadzieję, że piszesz o regeksach.
>> �Czyli jeste wiadom problemu, ale masz innych w d*.
>
> Mo�e akurat nie mam nic innego pod r�k�?
Teraz psujesz polskie literki...
>> �Oczywi cie, e to dobre rozwi zanie, cho nie wiem czy akurat w tym
>> przypadku. Du o si nie zyska.
>
> Mam nadziej�, �e piszesz o regeksach.
O operacjach na stringach, naturalnie.
Tych str_replace() itp.? No to cóż.. straciłem nieco wiary w Twoje
umiejętności, a była ona spora.
A może wystarczy poczytać manuala, zanim się zacznie wygłaszać takie opinie?
http://pl.php.net/manual/pl/function.str-replace.php
"str_replace
If you don't need fancy replacing rules (like regular expressions), you
should always use this function instead of preg_replace()."
--
wojtas
http://jwmprojekt.pl
[...]
> A mo�e wystarczy poczyta� manuala, zanim si� zacznie wyg�asza� takie opinie?
> http://pl.php.net/manual/pl/function.str-replace.php
> "str_replace
> If you don't need fancy replacing rules (like regular expressions), you
> should always use this function instead of preg_replace()."
Wiesz, ale tak argumentuj�c, to _zawsze_ mo�na zast�pi� wyra�enia regularne,
konstrukcjami opartymi o inne funkcje, wi�c warunek "need" nie jest nigdy
spe�niony.
--
Wojciech Ba�cer
pro...@post.pl
Może trzeba pomyslec?
"If you don't need fancy replacing rules **(like regular
expressions)**"
Tu wystapil problem klasy, do rozwiazywania ktorej powstaly wyrazenia
regularne! Tak tez, **you need fancy replacing rules like regular
expressions**!
Zapewniam Cie, ze o ile manual PHP to niezle zrodlo wiedzy o PHP, to
nie oznacza, ze jest jakakolwiek wyrocznia dla dobrego programisty
(nawet osmiele sie stwierdzic, ze czesto jest na odwrot). Nie uwazasz
tez troche, ze to debilne - w obliczu testu, ktory napisalem - bronic
rozwiazan niepoprawnych? Ani one szybsze, ani trafniejsze. Z punktu
widzenia elegancji kodu - nie do przyjecia.
Tez masz racje :) Chlopaki pisza wlasna wersje wyrazen regularnych -
niezoptymalizowanych, nieeleganckich, malo ogolnych, blednych... ale
ciezko wytlumaczyc, ze po prostu ktos to juz napisal (pol wieku temu!)
i ten ktos byl wysokiej klasy inzynierem, a nie pseudo-koderem.
> "If you don't need fancy replacing rules **(like regular
> expressions)**"
Zwyk�e kryterium zdrowego rozs�dku. Niekt�rzy, co wida� te� po pytaniach
na grupie, pr�buj� stosowa� wyra�enia regularne do wszystkiego, ��cznie z
parsowaniem kilobajt�w HTML-a.
> tez troche, ze to debilne - w obliczu testu, ktory napisalem - bronic
> rozwiazan niepoprawnych? Ani one szybsze, ani trafniejsze. Z punktu
> widzenia elegancji kodu - nie do przyjecia.
Ale "elegancja" kodu nie jest priorytetem. IMO powinna to by� czysto��
(nie musi by� "elegancka"!) i wydajno��. Co do Twojego przyk�adu - je�li to
mia�oby by� jednorazowe u�ycie, to te� bym nie filozofowa� i u�y� regexpa.
Ale je�li to mia�by by� fragment jakiej� funkcji (np. metody do generowania
"czystych" URL-i) to bym si� zastanowi� nad czym� d�u�szym, ale
potencjalnie wydajniejszym. I tak przez 99.999% czasu bym tego nie ogl�da�,
a jedynie wywo�ywa�. Oczywi�cie, o ile tylko sk�rka jest warta wyprawki :)
> potencjalnie wydajniejszym. I tak przez 99.999% czasu bym tego nie ogl�da�,
> a jedynie wywo�ywa�. Oczywi�cie, o ile tylko sk�rka jest warta wyprawki :)
Z czystej ciekawo�ci sprawdzi�em jak te rozwi�zania si� skaluj� dla
wi�kszych danych, a nie kilkunastu bajt�w.
Wynik: http://i.imgur.com/u6dMf.png
Seria 1 - regexp
Seria 2 - str_replace na kilku '_' powt�rzonych razy pot�gi dw�jki
(przypadek szczeg�lny, wydajno�� znacznie spada dla wi�kszych N)
Seria 3 - str_replace w p�tli
Czyli optymalizacja tego nie ma wi�kszego sensu.
Bonusowo:
Poza tym test pokazal, ze REGEXP JEST WYDAJNIEJSZY w przypadku
wskazanym przez Autora watku. Dwukrotnie! Natomiast, gdyby Autor
zastosowal rozwiazanie 2) lub 4) niesmialego kolegi aaaaaaa, to bylby
w tarapatach, bo funkcja dzialalaby zle. Doszloby bezsensowne
sprawdzanie bledu, i rozgryzanie problemu rozgryzionego pol wieku
temu, jak juz pisalem.
Opcja 3) tez jest niepoprawna, bo zaklada uzycie jedynie niepustych
lancuchow znakow, ale to akurat da sie latwo poprawic przez dodanie
warunku przed cala akcja. To samo tyczy się braku obsługi unikodu - to
mozna załatwić zamieniając strlen() na mb_strlen() - ale zawsze trzeba
coś zrobić - rozwiązanie jest mało poprawne. (Co prawda w większości
przypadków zadziała dobrze, ale znajdzie się pewnie taka kombinacja
bajtów, dla której zadziała źle). Jedynie opcja 1) wydaje się możliwa
do zaakceptowania, ale również mam wątpliwości, czy pociągnie to
unikod. Funkcja strpos() na pewno nie powinna być użyta.