php regex

Matchar hur många tecken som helst innan . ! (mellanslag)
https://regex101.com/r/hZJwOS/1
Matchar 4-15 tecken som innan . ! (mellanslag)
https://regex101.com/r/paN8sq/1

Jag har lagt på /g för att jag skulle kunna visa exempel på flera rader.

Denna gör samma sak, eftersom skiljetecken inte ingår i word characters. Ganska ny till regex och har mest arbetat i .Net, så det kanske är någonting som man borde göra annorlunda i PHP

@BrutalSwede: Den är 6 steg långsammare, annars är det ingen skillnad.

EDIT: Missade att du hade en capture group. Därför 6 steg extra. Annars ingen skillnad.

Den här tar a-ö. Och hoppar över @.

/@([a-ö0-9_-]{4,15})/i

Lade till en group eftersom jag tänkte att han vill ha ut användarnamnet utan @

Sen beror det väl också på hur man vill att den ska hantera andra skiljetecken som kan dyka upp i en sträng, t.ex om det kommer flera @.

Om jag tolkar det korrekt så borde du bara behöva lägga till 'u' som ett alternativ för din regex matchning för att använda unicode. Reserverar mig för att ha fel om det

preg_replace() <3, men regex på HTML?

Beroende på vad slutändamålet är skulle jag rekommendera att kika på DOMXPath nästa gång. Regex är förstås smidigt att implementera men XPath är sannolikt "rätt" verktyg för jobbet och skalar bättre.

@jreklund: Vill inflika att anledningen till att punkter och andra skiljetecken inte inkluderas i namnen är att tolken behöver kunna avgöra var de slutar när de används i vanlig text (precis som att kolonet efter ditt namn utelämnas), och jag har valt att lägga gränsen så här. Man skulle t.ex. kunna fortsätta läsa om tecknet efter punkten är en ny bokstav, men det skulle inte bli perfekt det heller, och det är inget vanligt format på forumet. Det finns dock en del äldre konton som har sådana här specialtecken i sina namn, och för att notififera dessa om svar kan man citera namnet: @"fornamn.efternamn" => @fornamn.efternamn. Skulle namnet innehålla citat-tecken så får man escapa dessa som entities istället... Det görs även automatiskt av svara-knappen.

/@([a-ö0-9_-]{4,15})/i

Det här är också lite farligt. Det kommer i grund och botten från samma problem som inlägget ovan (#17076879), och att en range inte har någon uppfattning om hur just vårat alfabet råkar se ut. Så även om a-ö ser rimligt ut för oss så kommer det tolkas som vilket tecken som helst som råkar ligga mellan hur a (troligen {61}) och ö råkar representeras i din källfilskodning, är den UTF-8 så troligen {C3,B6}), och rangen blir då [\x61-\xC3\xB6], vilket innebär att t.ex. preg_match("/[a-ö]/", "¾") === 1. Observera att det inte hjälper att bara lägga till modifieraren "u" i det här fallet, den kommer fortfarande inkludera allt mellan positionerna för "a" och "ö", fast i UTF-8 istället.

Anledningen till att det (oftast) fungerar med just 0-9, a-z och A-Z är att ASCII designats med dessa i följd, och många teckenkodningar är kompatibla med det:
https://en.wikipedia.org/wiki/ASCII#Character_set

#17076879: Fungerar lika bra med "/@([\w]{4,15})/u", för åäö är inkluderat inuti utf-8.
#17076898: Självklart måste man hitta sin standard. Jag kör bara med punkter som skiljetecken (och - _ förstås), för att efterlikna vanliga e-postkombinationer/AD-konton.
#17076975: Tack för tipset, alltid lär man sig något nytt. Inte tänkt på att det ligger fler tecken emellan a-ö än a-zåäö. Jag kör dock alltid a-z. Lever lite i den gamla skolan att endast de tecknen "finns" på nätet. Speciellt när man ska använda dem i URLer.

Det är bra att ha för vana att lägga bindestreck som inte ska indikera en range sist i klassen, annars är det lättare att göra ett misstag och skapa en range som tillåter allt mellan 9 och _. Tror att det där bör göra vad du avsett eftersom att det föregående tecknet nu avslutar en annan range, men man får fundera både en och två gånger extra.

Exempel:
https://regex101.com/r/LZpzof/1

@jreklund: Indeed. Livet är mycket trevligare när man kommer undan med ASCII. Ogillar till och med \w eftersom att vilka tecken som inkluderas påverkas av globala inställningar. Ett annat alternativ om man inte vill specifiera alla tillåtna tecken är unicode character properties, men here be dragons.