[PHP] Tag Parser

[Verwijderd]

Een tijdje geleden stond er op het forum een post van een persoon (weet niet meer wie) die had een parser geschreven (url: http://achelois.tweakers.net/~acm/parse/). Kan die persoon mij misschien de achterliggende techniek uitleggen. Ik hoef geen stukken code, ben alleen geinstereseerd in achterliggende techniek.

Alvast bedankt

[ Voor 7% gewijzigd door ACM op 09-10-2007 22:38 . Reden: vulcanus.its.tudelft.nl is niet meer ]

[ACM]

Die persoon is ik
Even een grote reply tikken, maar antwoord komt eraan

[edit]
Het principe is vrij simpel, je zoekt de eerste tag op, kijkt wat ie is (of ie wel mag, of ie wel goed is etc) en dumpt hem op een stack (soort array). De tussenliggende tekst dump ik ook op die stack (maar geef wel aan dat het tekst is)
Zo ga je door tot het einde van de tekst.

Die stack die ik dan heb, bouw ik weer langzaam (relatief ) af, door een voor een te kijken wat er met de tags "ansich" en de tussenliggende tekst moet gebeuren.
Parameters ([img=bla w=7 h=5]) worden goed geparsed etc.

En aan het eind rolt er bijv een mooi lapje html uit.

Is het zo uitgebreid genoeg?

[Verwijderd]

array_push() en array_pop() zat het toch.

Maar word er nog een speciale techniek gebruikt om die eerste tag op te zoeken, of gewoon standaard

[CyberSnooP]

Gaat de persoon hem nou open source maken? Is ie nog actief bezig met opschonen?

Het zou me niet verbazen als je hem niet open source maakt, maar je kunt wel heeel veel UBB-vraag-topics sluiten door alleen de URL van de source te geven )

Ik ben benieuwd!

[Gerco]

Op dinsdag 05 juni 2001 22:47 schreef CyberSnooP het volgende:
Gaat de persoon hem nou open source maken? Is ie nog actief bezig met opschonen?

[gemene-off-topic-mode]
Misschien de persoon niet, maar ik kan de source ook wel 'open' maken hoor.
[/gemene-off-topic-mode]

[ACM]

Op dinsdag 05 juni 2001 22:33 schreef M4TR1X het volgende:
array_push() en array_pop() zat het toch.

Maar word er nog een speciale techniek gebruikt om die eerste tag op te zoeken, of gewoon standaard

Ik gebruik idd array_push/array_pop
Mja, niet echt een speciale manier, gewoon kijken waar ie begint en eindigt en dat dan checken. (met een regexp, das net iets flexibeler dan eigen code en scheelt een hoop werk)

Op dinsdag 05 juni 2001 22:47 schreef CyberSnooP het volgende:
Gaat de persoon hem nou open source maken? Is ie nog actief bezig met opschonen?

De persoon is er nog niet over uit.
Actief opschonen moet binnenkort ook maar weer es

Het zou me niet verbazen als je hem niet open source maakt, maar je kunt wel heeel veel UBB-vraag-topics sluiten door alleen de URL van de source te geven )

Right, niemand die die code snapt, behalve de genen die het zelf al kunnen proggen

Ik ben benieuwd!

Ik ook

[ACM]

Op dinsdag 05 juni 2001 22:49 schreef Gerco het volgende:
[gemene-off-topic-mode]
Misschien de persoon niet, maar ik kan de source ook wel 'open' maken hoor.
[/gemene-off-topic-mode]

Och, dan is het alsnog licentie schenden van jouw hand...
Dan komt de schade claim wel bij je terecht?

(okee, als jij gemeen doet, doe ik dat ook)

[brammetje]

ik zou het ook wel eens willen zien..

zo ver als ik het zie is het een stuk beter dan veel van de regexp scrippies..

alleen langzamer..

[Gerco]

Op dinsdag 05 juni 2001 22:52 schreef ACM het volgende:
Och, dan is het alsnog licentie schenden van jouw hand...

licentie? waar?

[ACM]

Op dinsdag 05 juni 2001 22:53 schreef PlayR het volgende:
alleen langzamer..

Klopt, daarvoor wil ik nog es de code opschonen.
Het parsen "ansich" (stack aflopen) duurt net zo lang als een regexp parser (niet al te goede, gewoon simpel)
Alleen die eerste "split" run duurt zo lang

[CyberSnooP]

Maar als Gerco hem nou stiekem aan mij geeft/verkoopt, zonder dat de persoon daar niks van weet? --> Geen schadevergoeding, ik een universele ubb-tag-parser, en Gerco een paar centjes rijker?

Ach.. wat is illegaal doen toch handig

[Gerco]

Op dinsdag 05 juni 2001 22:56 schreef CyberSnooP het volgende:
Maar als Gerco hem nou stiekem aan mij geeft/verkoopt, zonder dat de persoon daar niks van weet? --> Geen schadevergoeding, ik een universele ubb-tag-parser, en Gerco een paar centjes rijker?

Als jij die vrouw van je icon voor mij in levende lijve regelt (om te houden dan), hebben we een deal.
Maar dan kun je het ook wel met de auteur bespreken hoor

Maar goed, genoeg off-topic geblaat anders sluit de persoon de topic.

[ACM]

* ACM zet de source wel even ergens anders neer...
En nu weer ontopic

Owja, in ruil voor die vrouw, krijg je de source ook gewoon van mij, met rechten

[brammetje]

Op dinsdag 05 juni 2001 22:55 schreef ACM het volgende:

[..]

Klopt, daarvoor wil ik nog es de code opschonen.
Het parsen "ansich" (stack aflopen) duurt net zo lang als een regexp parser (niet al te goede, gewoon simpel)
Alleen die eerste "split" run duurt zo lang

opschieten dan

[CyberSnooP]

Dit moet toch alvast een beetje helpen :

[oh,when?]

kweet nog dat in het originele topic ook een uitleg stond over "First in First Out" FIFO en "Last in First Out". Kan er iemand nog een keer een uitleg hierover geven, dat vond ik namelijk wel interresant.

[CyberSnooP]

FIFO:
Ik zet eerst 1, dan 2, dan 3 en dan 4 op een stapeltje (stack)
Ik haal er eerste 1, dan 2, dan 3 en dan 4 vanaf.

LIFO:
Ik zet eerst 1, dan 2, dan 3 en dan 4 op een stapeltje (stack)
Ik haal er eerste 4, dan 3, dan 2 en dan 1 vanaf.

[marcusk]

Op dinsdag 05 juni 2001 22:53 schreef PlayR het volgende:
ik zou het ook wel eens willen zien..

zo ver als ik het zie is het een stuk beter dan veel van de regexp scrippies..

alleen langzamer..

Ik ben bezig met het schrijven van een parser in C++ (wil al aardig lukken). Het is mijn bedoeling om er een php-extensie van te maken als ie af is. Dan is ie iig een stuk sneller dan regexps.

[CyberSnooP]

Op woensdag 06 juni 2001 03:42 schreef marcusk het volgende:
Ik ben bezig met het schrijven van een parser in C++ (wil al aardig lukken).

Erg goed idee! Wordt de extensie open-source? Of wordt ie alleen downloadbaar? Of hou je hem helemaal voor jezelf?

Het is mijn bedoeling om er een php-extensie van te maken als ie af is. Dan is ie iig een stuk sneller dan regexps.

Is die php-extensie dan gewoon in php te laden met
dl("marcuskparser.so"); onder linux ofzo? Of moet je dan een hercompilatie van PHP hebben.

Als dat laatste het geval is, wordt het lastiger.

[dusty]

Op dinsdag 05 juni 2001 22:55 schreef ACM het volgende:
Alleen die eerste "split" run duurt zo lang

Mijn parser is sneller

Maarja men moet wel weer correcte code invoeren (geen aanames zoals in ACM's parser)

( nog wat bugjes fixen deze weekend, en dan zet ik ook wel de link publiekelijk neer. (naar het testen.. niet de source )

[ACM]

Jouw parser is veel te grappig
Kan je al:
[ b]
[ code][ b] [/b][/code]
[ /b]


Gebruiken?

[Verwijderd]

Hej ACM,

Je hebt ook ooit eens het hele parse algoritme lopen uitleggen, maar die post is helaas verloren gegaan. (het cheetah gebeuren)

Zou je dat nog eens willen posten?

[brammetje]

Op woensdag 06 juni 2001 12:40 schreef Titanic het volgende:
Hej ACM,

Je hebt ook ooit eens het hele parse algoritme lopen uitleggen, maar die post is helaas verloren gegaan. (het cheetah gebeuren)

Zou je dat nog eens willen posten?

2e post staat het al (in het kort)

[dusty]

Op woensdag 06 juni 2001 12:01 schreef ACM het volgende:
Jouw parser is veel te grappig
Kan je al:

[code] [/code]


Gebruiken?

Dat is die ene bug die ik moet fixen hey je kan niet alles willen van iets wat in een 3 uur ofzo is gemaakt

[ACM]

Op woensdag 06 juni 2001 12:55 schreef PlayR het volgende:
2e post staat het al (in het kort)

Tsja, ik kan daar lang en kort over zijn, maar het is hetzelfde verhaal

[brammetje]

Op woensdag 06 juni 2001 13:05 schreef ACM het volgende:

[..]

Tsja, ik kan daar lang en kort over zijn, maar het is hetzelfde verhaal

ok in de 2e post staat het (in het lang)


zo goed?

[marcusk]

Op woensdag 06 juni 2001 11:12 schreef CyberSnooP het volgende:
Erg goed idee! Wordt de extensie open-source? Of wordt ie alleen downloadbaar? Of hou je hem helemaal voor jezelf?

Ik denk gewoon open-source.

Is die php-extensie dan gewoon in php te laden met
dl("marcuskparser.so"); onder linux ofzo? Of moet je dan een hercompilatie van PHP hebben.

Als dat laatste het geval is, wordt het lastiger.

Volgens mij moet het wel kunnen met dynamisch laden.

[Tuinhark]

Op dinsdag 05 juni 2001 22:47 schreef CyberSnooP het volgende:
Gaat de persoon hem nou open source maken? Is ie nog actief bezig met opschonen?

Het zou me niet verbazen als je hem niet open source maakt, maar je kunt wel heeel veel UBB-vraag-topics sluiten door alleen de URL van de source te geven )

Ik ben benieuwd!

In de trend van on-topic reclame , volgt hier mijn eigen UBB-achtige parser: http://yapbb.sf.net/YBBtags/

Owkee, ik geef toe, het is niet echt een parser, maar werkt met een hele bos regexps.

[Verwijderd]

Gek idee misschien, maarreh ....
stap 1: zet UBB in XML om
stap 2: gebruik een XML parser

Of nog beter: gebruik XML compliant opmaak tags ipv UBB, plak er een header boven en een footer onder, en voila!

Vervolgens kun je op de losse stukjes nog evt. wat regexps loslaten om smiles te vervangen ofzo.

[ACM]

MrX: mijn code/parser kan jouw punt1 in principe ook
En heel summier punt2 ook wel

Maar er zijn nog niet zoveel websites die op XML draaien geloof ik (tenzij ze word/excell als html-editor gebruiken)

[dusty]

Op woensdag 06 juni 2001 13:52 schreef MrX het volgende:
Of nog beter: gebruik XML compliant opmaak tags ipv UBB

Helaas heb je met gebruikers te maken en die zijn gewend aan de UBB tags. Je zal ze ontzettend moeilijk overgeschakeld krijgen op XML tags ipv. UBB tags.

[marcusk]

Ik geloof dat mijn parser nu wel perfect is. Weet iemand een aantal 'struikelblokken' zodat ik het kan testen?

[CyberSnooP]

* Niet bestaande tags
* niet afgesloten tags
* verkeerd geneste tags ([b]

code:

[/b]

)
* alleen afsluiten, niet openen.
* [bla[nogwaxy] (<-- deze gebruiker doet heel gek )
* [¡$&?¿€] (kortom.. vreemde tekens)
* gebruik van [ en van ] teken midden in de tekst.

Als ie dat allemaal perfect doet, en ook nog suggesties geeft als mensen een tag zijn vergeten af te sluiten ofzo dan is ie (behoorlijk) perfect.

[ACM]

* Niet bestaande tags <- Die parsed ie helaas niet, klopt dat?

* niet afgesloten tags <- Die parsed ie wel maar worden achteraf wel afgesloten

* verkeerd geneste tags <- verkeerde nesting wordt dmv aannames "netjes" (xhtml compliant) afgesloten

* alleen afsluiten, niet openen. <- worden niet geparsed

* [bla[nogwaxy] <- dan zou de tag nogwaxy moeten zijn, de tag wordt niet als bla geaccepteerd zo

* [¡$&?¿€] (kortom.. vreemde tekens) <- mja, geeft geen enkel probleem, behalve dat ik er gewoon geen tags mee heb

* gebruik van [ en van ] teken midden in de tekst. <- en? niks aan de hand

Als ie dat allemaal perfect doet, en ook nog suggesties geeft als mensen een tag zijn vergeten af te sluiten ofzo dan is ie (behoorlijk) perfect.

De suggesties moeten er nog bij. Alhoewel ie wel aan kan geven dat er een tag niet afgesloten was en dus alsnog gesloten wordt.

Overigens worden ook een tags als:
[img=src w=60 h=70 blaa=blaa]
en
[img=src h=70 w=60]
goed geparsed... (aardigheidje )

[CyberSnooP]

Op woensdag 06 juni 2001 23:43 schreef ACM het volgende:
Overigens worden ook een tags als:
[img=src w=60 h=70 blaa=blaa]
en
[img=src h=70 w=60]
goed geparsed... (aardigheidje )

Ah... Lief . Maar doet ie dan ook:
[img=src h=w=50]
voor een vierkantje?

[ACM]

Op woensdag 06 juni 2001 23:49 schreef CyberSnooP het volgende:
Ah... Lief . Maar doet ie dan ook:
[img=src h=w=50]
voor een vierkantje?

Hee, das een leuk idee.
Nee, doet ie nog niet. Kan wel

Maar is imho wel een beetje overdreven

[marcusk]

* Niet bestaande tags
ik heb een AI ingebouwd die probeert te achterhalen wat de gebruiker wil als de tag niet bestaat
* niet afgesloten tags
worden gewoon als tekst weergegeven
[b]* verkeerd geneste tags ([ b][ code][ /b][ /code])
binnen code-tags worden de tags genegeerd
echter, iets als

code:

[code][/code]

doet ie wel verkeerd ben ik net achtergekomen (dankzij ACM ), dus daar moet ik nog mee bezig.

edit:
hij maakt precies dezelfde fout als topix

* alleen afsluiten, niet openen.
wordt ook als gewone tekst weergegeven
* [bla[nogwaxy] (<-- deze gebruiker doet heel gek )
de tag is niet geldig (er mag geen [ in de naam voorkomen, alleen alfanummeriek), dus word als gewone tekst weergegeven.
* [¡$&?¿€] (kortom.. vreemde tekens)
ik ondersteun alleen alfanummerieke characters als tags, dus dit zal ook letterlijk weergegeven worden.
* gebruik van [ en van ] teken midden in de tekst.
geen probleem, wordt gewoon weergegeven.

Als ie dat allemaal perfect doet, en ook nog suggesties geeft als mensen een tag zijn vergeten af te sluiten ofzo dan is ie (behoorlijk) perfect.

suggesties geven is wel een idee ja

[marcusk]

Op woensdag 06 juni 2001 23:43 schreef ACM het volgende:Overigens worden ook een tags als:
[img=src w=60 h=70 blaa=blaa]
en
[img=src h=70 w=60]
goed geparsed... (aardigheidje )

Hmmm... ik ondersteun alleen argumenten (nouja... één per tag) in de vorm van [img="bla.gif"], dus het MOET tussen aanhalingstekens staan. Kan ik opzich wel aanpassen.

[dusty]

marcusk: wanneer zet je je parser online zodat we hem kunnen testen ?

[Verwijderd]

Dit is cool.
Maar hoe moeilijk is het nou om zo'n UBB parser te schrijven. Volgens mij is het alleen moeilijk om een goeie te schrijven.
Zoals in en snelle etc.

[ACM]

Op donderdag 07 juni 2001 11:52 schreef daniel_hoenderdos het volgende:
Dit is cool.
Maar hoe moeilijk is het nou om zo'n UBB parser te schrijven. Volgens mij is het alleen moeilijk om een goeie te schrijven.
Zoals in en snelle etc.

Och, er een schrijven is niet moeilijk...
Een goede wel.
En die dan ook nog snel is? Dan helemaal...

[Grum]

Op donderdag 07 juni 2001 00:03 schreef marcusk het volgende:
* niet afgesloten tags
worden gewoon als tekst weergegeven

Sommige moeten toch echt werken ... /me,
,
• bv

* [bla[nogwaxy] (<-- deze gebruiker doet heel gek )
de tag is niet geldig (er mag geen [ in de naam voorkomen, alleen alfanummeriek), dus word als gewone tekst weergegeven.

en [edit:Text] dan ????? dat mag niet fout gaan

* [¡$&?¿€] (kortom.. vreemde tekens)
ik ondersteun alleen alfanummerieke characters als tags, dus dit zal ook letterlijk weergegeven worden.

en als je dat nou gebruikt in een [ url=¡$&?¿€]bladiebla[/url ] dan moet het ook werken


nu jij weer

[Verwijderd]

Op donderdag 07 juni 2001 12:00 schreef Grum_ het volgende:


en als je dat nou gebruikt in een [ url=¡$&?¿€]bladiebla[/url ] dan moet het ook werken

nu jij weer

Wat is je punt?

Dat kan toch? je schrijft gewoon een parser die [ url= ] omzet. Dan boeit het toch niet welke tekens erin zitten?

[ACM]

Op donderdag 07 juni 2001 12:13 schreef daniel_hoenderdos het volgende:
Wat is je punt?

Die reactie was dan ook niet op jou...
Je zou de rest van de thread es kunnen bekijken?

[Grum]

ik moet hier geen woorden aan vuil maken eigelijk ... maareuh ... je bent blond

[Verwijderd]

Oh was die niet voor mij...

DOH! Dat weet ik toch ook wel. Ik vroeg me alleen maar af wat zijn punt nou is.


ACM:
Ja dat zou ik kunnen doen, en dat heb ik net gedaan.
Laat anders maar.
Weet je wat? Laat het hele topic maar.

[Verwijderd]

Hej ACM,

Het principe is vrij simpel, je zoekt de eerste tag op,...

Hoe doe je dit? Ga je elke letter bij langs om te kijken of het niet toevallig "[" is?

Ik heb namelijk ook even geprobeerd zo'n parser te schrijven, maar die doet er 2 keer langer over dan die van jou. Ik denk dus dat het probleem zit bij het letter voor letter door de tekst gaan op zoek naar een "[" of "]".

[tom kuipers]

Owkay, ik vind dattie dit wel goed moet doen.

[ img src="bla.gif" alt="Dit doe je door [ img] te doen, [ b] en wil quotjes\"kunnen gebruiken\" dotie dat al????" w=10]

[ACM]

Op donderdag 07 juni 2001 12:47 schreef Titanic het volgende:
Hoe doe je dit? Ga je elke letter bij langs om te kijken of het niet toevallig "[" is?

Neuh, strpos doet dat voor mij
Maar, dat hoeft niet perse een [ te zijn hoor, mag wat anders

Op donderdag 07 juni 2001 12:52 schreef tom kuipers het volgende:
[ img src="bla.gif" alt="Dit doe je door [ img] te doen, [ b] en wil quotjes\"kunnen gebruiken\" dotie dat al????" w=10]

Tekst binnen quotjes moet idd nog wel
Maar het is geen volwaardige sgml-parser, dus je moet niet _te_ hoge eisen stellen

Het nadeel van dat " \" gedoe, is dat je dus nog een extra "parse" niveau erbij maakt...
't Kan wel, maar voor die ene keer dat het gebruikt wordt, zou het weer vreselijk traag worden.

Daarnaast is bij mijn weten dit:
alt="blaat\"blabla\"blaat" geen correct html?
En ga ik echt niet allerlei code zitten tikken om dat (die ene keer dat zoiets gebruikt wordt) wel goed te doen

[marcusk]

Op donderdag 07 juni 2001 09:16 schreef dusty het volgende:
marcusk: wanneer zet je je parser online zodat we hem kunnen testen ?

hij is geschreven in c++, dus ik moet er eerst een extensie van maken voordat ik em online zet. hoewel ik opzich de exe ook wel online kan zetten natuurlijk.

Op donderdag 07 juni 2001 11:52 schreef daniel_hoenderdos het volgende:
Dit is cool.
Maar hoe moeilijk is het nou om zo'n UBB parser te schrijven. Volgens mij is het alleen moeilijk om een goeie te schrijven.
Zoals in en snelle etc.

Ik dacht voordat ik begon ook dat het heel erg makkelijk was, maar ondertussen heb ik wel het algoritme 3x herschreven (verdeeld over 3 dagen), en is ie nog niet helemaal goed. Dus inderdaad: moeilijk is om een goede te schrijven. Aangezien het C++ is zal snel geen probleem zijn, vergeleken met php-parsers en reg-exps althans.

Op donderdag 07 juni 2001 12:00 schreef Grum_ het volgende:
Sommige moeten toch echt werken ... /me,
, • bv

Ja, je hebt gelijk vrees ik Dat ondersteunt ie dus nog niet.

en [edit:Text] dan ????? dat mag niet fout gaan

Nee, ok... als er een tag is met de naam "nogwaxy" zal hij die wel parsen, en in dit geval [ b]Text[b ] dus ook wel.

en als je dat nou gebruikt in een [ url=¡$&?¿€]bladiebla[/url ] dan moet het ook werken

alleen in de naam van een tag mogen geen vreemde tekens voorkomen. in het argument is geen probleem.

[marcusk]

ik heb een zip met de exe-file gezet op http://members.home.nl/klimstra/ubb_parse.zip

[Verwijderd]

Op donderdag 07 juni 2001 16:27 schreef marcusk het volgende:
ik heb een zip met de exe-file gezet op http://members.home.nl/klimstra/ubb_parse.zip

Nu nog een perl of php versie zodat je er ook echt wat aan hebt

[marcusk]

Op donderdag 07 juni 2001 16:45 schreef Zef het volgende:

[..]

Nu nog een perl of php versie zodat je er ook echt wat aan hebt

ben er mee bezig.

[Gerco]

Als je dat ding gewoon een file kan laten inlezen en ook weer uitspugen (stdout/file) kun je het gewoon gebruiken hoor, ook met php.

[ACM]

Hij wilde er een php-extentie van maken...
Dus dan heb je er ook wat aan hoor...

[TiG]

Ik ben ook met een parser bezig. Dit heb ik tot nu toe, kan iemand mij vertellen of ik op de juiste weg zit?

PHP:

<?
php

#########COPYRIGHT NOTICE#########
# Deze parse is gemaakt door     #
# Kris Hoogendoorn voor          #
# dediepvries.com                #
#                                #
# (c)2001 De Diepvries           #
##################################

// De invoer variable is $invoer

$invoer = preg_replace(array("!<!","!>!"), array("&amp;lt;","&amp;gt;"), $invoer); // haal de < en >'s eruit, deze worden gebruikt voor de pointers

$opentags = array(); // de array waar alle open tag's inkomen
$allowedtags = array('b','u','i','s'); // de array met toegestane tags
$badinput = array(); // de array waar alle error's in de input die het script tegenkomt inkomen

function find_in_array($array, $value) { // de functie om snel te vinden waar iets in de array staat
 $ptr = -1; // default staat de value niet in de array
 for($i = count($array); $i >= 0; $i--) { // ga de array langs
  if($array[$i] == $value) // als de value gevonden is
   return $i; // geef de pointer terug
 }
 return $ptr;
}

# We gaan nu de hele invoer langslopen
while(preg_match("!\\[.+\]!Us", $invoer, $results)) { // zolang er nog tag's gevonden worden
 $tag = substr($results[0], 1, strlen($results[0]) - 2); // haal de result op die we willen hebben

 if(substr($tag, 0, 1) == '/') { // als het eerste teken van de tag een / is, is het een sluit tag
  $tag = substr($tag, 1, strlen($tag)); // dit is de echte tag
  $count = count($opentags) - 1; // het aantal items in opentags, omgezet zodat we het kunnen gebruiken in de array
  if($opentags[$count] == $tag) { // als de user juiste invoer heeft
   array_pop($opentags); // haal de tag eruit
   $invoer = preg_replace("!>$count!", "<$tag>", $invoer); // vervang de open tag
   $invoer = preg_replace("!\\[.+\]!Us", "</$tag>", $invoer, 1); // vervang de close tag
  }
  else { // ga zoeken naar een juiste eind tag
   $ptr = find_in_array($opentags, $tag); // kijk of de gesloten tag wel open is
   if($ptr < 0) // als geen opentag is gevonden
    $invoer = preg_replace("!\\[(.+)\]!Us", "<<\\1<", $invoer, 1); // vervang de tag door een tijdelijke <<TAG<
                                                                  // word later weer terug vervangen naar [TAG]
   else { // anders sluit eerst alle andere open-tags
    $addtags = ''; // de addtag variable, hierin komen alle tags die gesloten gaan worden
    for($i = count($opentags) - 1; $tag != $opentags[count($opentags)-1]; $i--) { // zolang we nog niet bij de juiste opentag zijn beland
     $current_opentag = array_pop($opentags);
     $addtags .= "</$current_opentag>"; // voeg de tag toe
     $invoer = preg_replace("!>$i!", "<$current_opentag>", $invoer);
    }
    array_pop($opentags); // haal de tag eruit
    $invoer = preg_replace("!>$i!", "<$tag>", $invoer); // vervang de open tag
    $invoer = preg_replace("!\\[.+\]!Us", "$addtags</$tag>", $invoer, 1); // vervang de ubb code
    array_push($badinput, "Er waren nog ander tags open voor $tag, andere eerst gesloten"); // voeg een error toe
   }
  }
 }
 else { // anders is het een open tag
  if(find_in_array($allowedtags, $tag) > -1) { // als de tag is toegestaan
   $ptr_in_opentags = count($opentags);
   array_push($opentags, $tag); // voeg de tag toe aan de open tags
   $invoer = preg_replace("!\\[.+\]!Us", ">$ptr_in_opentags", $invoer, 1);
  }
  else { // als de tag niet is toegestaan
   $invoer = preg_replace("!\\[(.+)\]!Us", "<<\\1<", $invoer, 1);
  }
 }
}

if(count($opentags) != 0) { // als er nog tags zijn zonder afsluitende tag
 for($i = 0; count($opentags) != 0; $i++) { // zolang er nog zielige tags zijn
  $tag = array_shift($opentags);
  $invoer = preg_replace("!>$i!", "<<$tag<", $invoer, 1); // vervang de pointer
  array_push($badinput, "Voor [$tag] heb ik geen close tag gevonden, genegeerd..."); // zeg dat de user een loser is
 }
}

$invoer = preg_replace("!<<(.+)<!Us", "[\\1]", $invoer);

print "<PRE>$invoer</PRE>";
?>

[marcusk]

Op donderdag 07 juni 2001 16:50 schreef Gerco het volgende:
Als je dat ding gewoon een file kan laten inlezen en ook weer uitspugen (stdout/file) kun je het gewoon gebruiken hoor, ook met php.

op het moment leest ie bla.txt in, en de uitvoer gaat idd naar stdout.
maar nu is het gewoon nog voor testen, dus ik hoef er nog niet zo veel aan te hebben

[ACM]

Als ie:
Een van deze twee:
http://vulcanus.its.tudelft.nl/acm/parse/acm-ubbtext.txt
http://vulcanus.its.tudelft.nl/acm/parse/ubbtext.txt

Minstens 1 goed parsed, dan is ie redelijk goed

Daarna komen nog een paar andere punten aan bod, waar Dusty de mijne (en ik de zijne ) aan bloot gesteld heeft


[edit]
IE laat het niet als tekst zien???
Vaag, gewoon viewsource ervan, en je hebt iig de goede tekst

[TiG]

Op donderdag 07 juni 2001 17:13 schreef ACM het volgende:

Tja die test kan ik nog niet uitvoeren want ik ben nog maar net begonnen. Hij snapt alleen maar [b] [i] [u] en [s] tags. Maar daar komt verandering in!

[dusty]

Op donderdag 07 juni 2001 16:57 schreef marcusk het volgende:
op het moment leest ie bla.txt in, en de uitvoer gaat idd naar stdout.
maar nu is het gewoon nog voor testen, dus ik hoef er nog niet zo veel aan te hebben

code:

[b]test[i]ja[/i]o[u]h[/u][/b]

waarom geeft ie bij het parsen een spatie tussen de /u en de /b ?

[marcusk]

Op vrijdag 08 juni 2001 07:58 schreef dusty het volgende:

[..]

code:

[b]test[i]ja[/i]o[u]h[/u][/b]

waarom geeft ie bij het parsen een spatie tussen de /u en de /b ?

goede vraag... ik kan de fout nergens vinden.
vreemdgenoeg werkt dit wel goed:

code:

[b]test[i]ja[/i]o[u]h[/u]bla[/b]

edit:
ik heb het al opgelost

ik heb nu trouwens het probleem met geneste-tags-met-dezelfde-naam opgelost (mede dankzij ACM , bedankt !)

edit:

nu alleen nog ondersteuning voor tags zonder eindtag toevoegen

[dusty]

En *eindelijk* had ik tijd om die ene bug te fixen.

Dust*Parser

Parser is opgelost op de recursieve manier.

[Verwijderd]

Op maandag 11 juni 2001 22:50 schreef dusty het volgende:
Parser is opgelost op de recursieve manier.

als ik dit doe

code:

[sub][b]Hello[/sub][/b]

krijg ik iets heel vreemds
maar oké is ook niet helemaal 100% fair, maar toch

[dusty]

Op maandag 11 juni 2001 22:55 schreef woeitje het volgende:
als ik dit doe

code:

[sub][b]Hello[/sub][/b]

krijg ik iets heel vreemds
maar oké is ook niet helemaal 100% fair, maar toch

zonder te kijken: hij zet [ b ]Hello in sub letters. en daarachter in normale letters [ /b ]

prima volgens de specificaties. wat je eerst opent moet je ook eerst sluiten

[CyberSnooP]

Op maandag 11 juni 2001 23:13 schreef dusty het volgende:
prima volgens de specificaties. wat je eerst opent moet je ook eerst sluiten

Yep! Het ziet er allemaal goed uit hoor. En het gaat ook razendsnel. In ieder geval snel genoeg als je tekst eenmalig parsed bij editen/posten en in de db opslaat!

Complimenten

[marcusk]

Het is me ondertussen gelukt om een php-extensie van mijn parser te maken. http://213.51.149.28/test/test.php is een testpagina.
Voor het geval ik eens een keer niet m'n computer aan heb, kun je hier een zip downloaden met de dll en een test-php: http://members.home.nl/klimstra

[dusty]

Op maandag 11 juni 2001 23:19 schreef CyberSnooP het volgende:
Yep! Het ziet er allemaal goed uit hoor. En het gaat ook razendsnel. In ieder geval snel genoeg als je tekst eenmalig parsed bij editen/posten en in de db opslaat!

Complimenten

Voor het parsen is het makkelijker als je het gewoon parsed "on the fly" maar wel netjes gebruik maakt van een "dynamische cache" waardoor veel "opgevraagden" threads opgebouwd kan worden uit de componenten vanuit de cache. blijft de database ook iets sneller van.

[CyberSnooP]

Op maandag 11 juni 2001 23:36 schreef marcusk het volgende:

Nu nog een test.so! Ik vind het een goed idee, maar wil het ook eerst zelf in PHP-proberen.

[Verwijderd]

Op maandag 11 juni 2001 23:13 schreef dusty het volgende:
prima volgens de specificaties. wat je eerst opent moet je ook eerst sluiten

owkay dust, dan heb je mij niet horen klagen

[marcusk]

Op maandag 11 juni 2001 23:44 schreef CyberSnooP het volgende:
Nu nog een test.so

Ik zal binnenkort de source wel vrijgeven. Ik wil eerst nog ff wat dingen verbeteren en toevoegen, zoals een ubb_add_custum_tag-functie, zodat vanuit php tags toegevoegd en afgehandeld kunnen worden.

[CyberSnooP]

Hierboven schreef marcusk het volgende:
...zoals een ubb_add_custum_tag-functie, zodat vanuit php tags toegevoegd en afgehandeld kunnen worden.

Zou je het dan ook zo kunnen maken dat je data-elementen in een tag door een eigen php-functie kunt laten verwerken? Ik bedoel dan net zoiets als de [img w=123 h=456]-dingen. Het zou grappig zijn als je dan een array kreeg in je functie die vervolgens de HTML-code returned.

En zorg je dan ook nog dat je zowel block-tags ([ b] en [ /b]) als single-tags (
[ *]) ondersteund? Enuhh. kan ik ook nog condities opgeven of er iets niet moet worden geparsed tussen bepaalde tags? ([html][/html] of
[ code][/ code]
).

Ik heb wensen zat, en profiteer van jou programmeer-tijd

[marcusk]

Op dinsdag 12 juni 2001 14:02 schreef CyberSnooP het volgende:
Zou je het dan ook zo kunnen maken dat je data-elementen in een tag door een eigen php-functie kunt laten verwerken?

De hele tag wordt dan door een eigen php-functie afgewerkt. Zo ongeveer:

code:

ubb_add_custom_tag("img", "taghandler", (iets met welke tags binnen img zijn toegestaan, geen dus));

function taghandler(tagname, innertext, argument)
{
  if (tagname == "img")
  {
    // doe allemaal dingen
  }
}

En zorg je dan ook nog dat je zowel block-tags ([ b] en [ /b]) als single-tags (
[ *]) ondersteund?

block-tags ondersteun in zowiezo, maar eenzame tags als [ *] lijkt me niet echt nuttig om te ondersteunen als custom tags (lees: is heel moeilijk te doen ). [ *] is al gedefinieerd in de parser zelf.

Enuhh. kan ik ook nog condities opgeven of er iets niet moet worden geparsed tussen bepaalde tags? ([html][/html] of
[ code][/ code]).

Je kunt inderdaad opgeven welke tags je wel en niet toestaat tussen een tag.

Ik heb wensen zat, en profiteer van jou programmeer-tijd

hehe

[marcusk]

Op maandag 11 juni 2001 22:50 schreef dusty het volgende:
En *eindelijk* had ik tijd om die ene bug te fixen.

Dust*Parser

Parser is opgelost op de recursieve manier.

code:

[u][b][i][s][sup][sub]
(heeeeel lang stuk tekst)
[/sub][/sup][/s][/i][/b][/u]

hoe komt het dat jouw parser hierbij zoveel sneller is dan de mijne (die ook recursief werkt) (5.4 ms t.o.v. 82.1 ms) en zelfs sneller dan die van ACM (11.4 ms), terwijl mij lijkt dat stack-based in dit geval veeeel sneller zou moeten zijn ?
Ik heb mijn parser nog niet echt goed geoptimaliseert, maar dit is toch wel erg extreem

[dusty]

Op dinsdag 12 juni 2001 15:27 schreef marcusk het volgende:

code:

[u][b][i][s][sup][sub]
(heeeeel lang stuk tekst)
[/sub][/sup][/s][/i][/b][/u]

hoe komt het dat jouw parser hierbij zoveel sneller is dan de mijne (die ook recursief werkt) (5.4 ms t.o.v. 82.1 ms) en zelfs sneller dan die van ACM (11.4 ms), terwijl mij lijkt dat stack-based in dit geval veeeel sneller zou moeten zijn ?
Ik heb mijn parser nog niet echt goed geoptimaliseert, maar dit is toch wel erg extreem

Omdat ik mijn code wel geoptimaliseerd heb ?

De reden waarom ACM's trager is is waarschijnlijk door zijn "Flexibiliteit" dat je nog wel tags verkeerd mag zetten en dat de parser het "probeert" op te lossen.

Waarom de jouwe zo extreem trager is kan jij alleen weten immers ben jij de enige die de code ervan weet.

[marcusk]

Op woensdag 13 juni 2001 00:15 schreef dusty het volgende:
Waarom de jouwe zo extreem trager is kan jij alleen weten immers ben jij de enige die de code ervan weet.

Mijn parser is meestal sneller dan die van jou, alleen in dit geval bijvoorbeeld niet. De reden dat hij hier zo traag is, is omdat ie de tekst op deze manier afwerkt : (iets ingekort)

code:

tag="u" innertext="[b][i][s]...[/s][/i][/b]"
tag="b" innertext="[i][s]...[/s][/i]"
tag="i" innertext="[s]...[/s]"
tag="s" innertext="..."

wat dus veel minder efficient is dan ACM's parser, omdat die de tekst maar 1 keer hoeft af te werken. Ik ging er van uit dat jouw parser net als de mijne werkt, en dus met dit voorbeeld iig trager zou moeten zijn dan die van ACM. Maar blijkbaar werkt jouw parser anders ofzo?

[CyberSnooP]

Op woensdag 13 juni 2001 00:47 schreef marcusk het volgende:

Gelukkig komen overdreven veel geneste tags niet zo vaak voor... Alleen als iem. [b][u][i]heel duidelijk

[dusty]

Op woensdag 13 juni 2001 00:47 schreef marcusk het volgende:
wat dus veel minder efficient is dan ACM's parser, omdat die de tekst maar 1 keer hoeft af te werken. Ik ging er van uit dat jouw parser net als de mijne werkt, en dus met dit voorbeeld iig trager zou moeten zijn dan die van ACM. Maar blijkbaar werkt jouw parser anders ofzo?

De mijne werkt in principe ook op hetzelfde manier.

Dat de jouwe sneller is, is wel te hopen (Aangezien de jouwe in C is gemaakt en de mijne in php.)

Echter hoort hij ook in ALLE gevallen sneller te zijn. Dus zit er ergens iets in waardoor je het sneller zou moeten kunnen maken

[marcusk]

Op woensdag 13 juni 2001 11:17 schreef dusty het volgende:

[..]

De mijne werkt in principe ook op hetzelfde manier.

Dat de jouwe sneller is, is wel te hopen (Aangezien de jouwe in C is gemaakt en de mijne in php.)

Echter hoort hij ook in ALLE gevallen sneller te zijn. Dus zit er ergens iets in waardoor je het sneller zou moeten kunnen maken

Mijn nieuwe parser (mix tussen list-based en recursief) doet het in 2.1 ms, dus dat zit wel goed