[Delphi] URL ontleden

[jvdmeer]

Ik hoopte dat er al een standaard functie voor zou zijn, maar nee. Dus zelf maar aan de slag gegaan, om een standaard url te ontleden in alle afzonderlijke delen.

protocol://user:password@host:port/dit/is/het/pad/bestand?query=lijst

hiervoor gebruik ik de volgende snel-snel-code:

Delphi:

Type
  TURL=class
    protocol:string;
    user:string;
    pass:string;
    host:string;
    port:string;
    path:string;
    bestand:string;
    query:string;
    procedure Split(URL:string);
  end;

code:

procedure TURL.Split(URL:string);
var
  Restant,
  UserPassHostPort,
  PathFile:string;
  VorigeSlash:integer;
begin
// Pak indien aanwezig het protocol uit de string
  if pos('://',URL)>0 then
   begin
    protocol:=copy(URL,1,pos('://',URL)-1);
    Restant:=copy(URL,pos('://',URL)+3,1000);
   end
   else
    protocol:='';


// Het gehele gedeelte UserPassHostport vormt op uit de string
  if pos('/',Restant)>0 then
  begin
    UserPassHostPort:=copy(Restant,1,pos('/',Restant)-1);
    Restant:=copy(Restant,pos('/',Restant),1000);
  end
  else
  begin
    UserPassHostPort:=copy(Restant,1,pos('/',Restant)-1);
    Restant:='/';
  end;


//Splits indien aanwezig Username en wachtwoord uit voorgaande resultaat
  if pos('@',UserPassHostPort)>0 then
  begin
    host:=copy(UserPassHostPort,pos('@',UserPassHostPort)+1,1000);
    UserPassHostPort:= copy(UserPassHostPort,1,pos('@',UserPassHostPort)-1);
    if pos(':',UserPassHostPort)>0 then
    begin
      pass:=copy(UserPassHostPort,pos(':',UserPassHostPort)+1,1000);
      user:=copy(UserPassHostPort,1,pos(':',UserPassHostPort)-1);
    end
    else
    begin
      user:=UserPassHostPort;
      pass:='';
    end;
  end
  else
  begin
    host:=UserPassHostPort;
    user:='';
    pass:='';
  end;


//Splits indien nodig host op in port en host
  if pos(':',host)>0 then
  begin
    port:=copy(host,pos(':',host)+1,1000);
    host:=copy(host,1,pos(':',host)-1);
  end;


//Splits het restant op in query en bestand+path
  if pos('?',Restant)>0 then
  begin
    PathFile:=copy(Restant,1,pos('?',Restant)-1);
    query:=copy(Restant,pos('?',Restant)+1,1000);
  end
  else
  begin
    PathFile:=Restant;
    query:='';
  end;


//splits bestand en pad op bij de achterste slash
  VorigeSlash:=1;
  repeat
    Bestand:=copy(PathFile,VorigeSlash+1,1000);
    Path:=copy(PathFile,1,VorigeSlash);
    VorigeSlash:=PosEx('/', PathFile, VorigeSlash+1);
  until Vorige=0;
end;

Protocol t/m Query worden nog wel netjes geGET en gePUT en de query-lijst wordt nog wel een TStringlist, maar het ging mij even om het idee.

Als het goed is behandeld deze functie de volgende gevallen:

code:

[1]        [2]           [3]      [4]             [5]     [6]
protocol://user:password@host:port/dit/is/het/pad/bestand?query=lijst

[1] mag er staan, hoeft niet
[2] mag er staan als user@ en user:password@, maar hoeft niet
[3] moet er staan als host of als host:port
[4] pad mag er staan, hoeft niet. Indien niet, dan geld / als pad
[5] bestand mag er staan, maar hoeft niet.
[6] mag er staan maar hoeft niet.

Mijn vraag is nu eigenlijk tweeledig:
• Heb ik hiermee alle mogelijkheden gehad?
• Moet ik URLDecode gebruiken voordat ik deze split actie uitvoer, of pas achteraf?

[ Voor 18% gewijzigd door jvdmeer op 11-12-2003 23:19 . Reden: Commentaar toegevoegd in code ]

[Grijze Vos]

misschien wil je nog anchors apart afvangen?

www.bla.nl/#blaaaat

[Verwijderd]

Ik zou van URL een property maken, die ontleed wordt bij het assignen setURL en samengesteld wordt bij het opvragen getURL.

ff snel, de basis layout:

Delphi:

 TURL=class
  private
    Fhost: string;
    Fbestand: string;
    Fanchor: string;
    Fquery: string;
    Fprotocol: string;
    Fuser: string;
    Fport: string;
    Fpass: string;
    Fpath: string;
    Furl: string;
    procedure Split(URL:string);
    procedure Seturl(const Value: string);

  public
    property protocol:string read Fprotocol;
    property user:string read Fuser;
    property pass:string read Fpass;
    property host:string read Fhost;
    property port:string read Fport ;
    property path:string read Fpath ;
    property anchor:string read Fanchor;
    property bestand:string read Fbestand;
    property query:string read Fquery ;
    property url:string read Furl write Seturl;
  end;

  procedure TURL.Seturl(const Value: string);
  begin
   if value  <> furl then
   begin
     Furl := Value;
     SplitUrl(Value)
   end;
 end;

  

[ Voor 106% gewijzigd door Verwijderd op 12-12-2003 01:07 ]

[LordLarry]

Of je pakt Indy's TIdURI uit de IdURI unit. Indy is een gratis opensource tcp/ip package voor Delphi, mocht je het nog niet kennen. http://www.indyproject.org/

[curry684]

Er is wel een standaard functie voor, in de WinINet API van Windows, en hij heet InternetCrackUrl.

* curry684 doet z'n ondertitel weer even eer aan

[jvdmeer]

Verwijderd schreef op 12 december 2003 @ 01:01:
Ik zou van URL een property maken, die ontleed wordt bij het assignen setURL en samengesteld wordt bij het opvragen getURL.

ja, dat weet ik. Daarom had ik onder de code al de regel toegevoegd:
Protocol t/m Query worden nog wel netjes geGET en gePUT en de query-lijst wordt nog wel een TStringlist, maar het ging mij even om het idee.

Ik doe altijd eerst even het concept, om daarna pas netjes te maken.

LordLarry schreef op 12 december 2003 @ 09:27:
Of je pakt Indy's TIdURI uit de IdURI unit. Indy is een gratis opensource tcp/ip package voor Delphi, mocht je het nog niet kennen. http://www.indyproject.org/

Ga ik vanavond naar kijken. En ik wist dat er zoiets was, maar kon er niets over vinden. Zoeken naar 'Delphi split URL' levert 1001 resultaten alleen geen nuttige. Maar deze is het bekijken waard, want de code zelf is redelijk compact en lijkt te doen wat ik zocht.

curry684 schreef op 12 december 2003 @ 09:40:
Er is wel een standaard functie voor, in de WinINet API van Windows, en hij heet InternetCrackUrl.

Als die TIdURI niets is, zal ik die ook even bekijken, maar TIdURI heeft het voordeel van de twijfel omdat de source wordt bijgeleverd. Kan ik van InternetCrackUrl niet zeggen.

[curry684]

jvdmeer schreef op 12 december 2003 @ 15:12:
Als die TIdURI niets is, zal ik die ook even bekijken, maar TIdURI heeft het voordeel van de twijfel omdat de source wordt bijgeleverd. Kan ik van InternetCrackUrl niet zeggen.

Uhm nee alleen heeft InternetCrackUrl het voordeel dat ie door enkele honderden miljoenen mensen al een jaar of 7-8 dagelijks enkele honderden keren wordt gebruikt. Hij splitst namelijk sinds IE3 al de URL's voor Internet Explorer.

Heb je uberhaupt wel op die link geklikt die ik gaf?

[jvdmeer]

curry684 schreef op 12 december 2003 @ 15:18:
[...]

Uhm nee alleen heeft InternetCrackUrl het voordeel dat ie door enkele honderden miljoenen mensen al een jaar of 7-8 dagelijks enkele honderden keren wordt gebruikt. Hij splitst namelijk sinds IE3 al de URL's voor Internet Explorer.

Heb je uberhaupt wel op die link geklikt die ik gaf?

Ja, tuurlijk heb ik 'm aangeklikt en gelezen. En (fout van mij) ik heb iets tegen API calls als er een alternatief beschikbaar is.

Dus geef ik de voorkeur aan componenten/methoden waarvan de source beschikbaar is.

Daarnaast lijkt TIdURI de URL meer op te splitsen dan InternetCrackURL. Laat ik de lengte van elk component weg, dan kom ik op:

INTERNET_SCHEME nScheme;
LPTSTR lpszHostName;
INTERNET_PORT nPort;
LPTSTR lpszUserName;
LPTSTR lpszPassword;
LPTSTR lpszUrlPath;
LPTSTR lpszExtraInfo;

tegenover:

FDocument: string;
FProtocol: string;
FURI: String;
FPort: string;
Fpath: string;
FHost: string;
FBookmark: string;
FUserName: string;
FPassword: string;
FParams: string;

Daarnaast moet ik bij het gebruik van InternetURLcrack de class er nog omheen schrijven terwijl TIdURI al redelijk compleet lijkt. Dus daarom kijk ik eerst naar TIdURI. Verbaast me trouwens dat Indy geen gebruik maakt van InternetCrackURL, maar dat wel zijn wegens compatibiliteit met Kylix.

[ Voor 4% gewijzigd door jvdmeer op 12-12-2003 16:05 ]

[curry684]

jvdmeer schreef op 12 december 2003 @ 16:04:
[...]
Ja, tuurlijk heb ik 'm aangeklikt en gelezen. En (fout van mij) ik heb iets tegen API calls als er een alternatief beschikbaar is.

Nee hoor is geen fout van jou hoor

Daarnaast lijkt TIdURI de URL meer op te splitsen dan InternetCrackURL.

Heb je al wel gekeken wat ie meer produceert?

Daarnaast moet ik bij het gebruik van InternetURLcrack de class er nog omheen schrijven terwijl TIdURI al redelijk compleet lijkt.

Een class? Tis 1 functiecall?

[whoami]

jvdmeer schreef op 12 december 2003 @ 16:04:
[...]
Ja, tuurlijk heb ik 'm aangeklikt en gelezen. En (fout van mij) ik heb iets tegen API calls als er een alternatief beschikbaar is.

Het wiel iedere keer opnieuw uitvinden is ook leuk natuurlijk.

[curry684]

whoami schreef op 12 december 2003 @ 16:20:
[...]

Het wiel iedere keer opnieuw uitvinden is ook leuk natuurlijk.

Vooral als het wiel reeds gestandaardiseerd en uitgeevolueerd is, en onderdeel van de specificaties van het platform waarvoor je ontwikkeld, en zelfs automatisch een nieuwe vorm krijgt als er nieuwe eisen aan het concept 'wiel' gesteld worden.

[bigben04]

]Ik hoopte dat er al een standaard functie voor zou zijn, maar nee.

En (fout van mij) ik heb iets tegen API calls als er een alternatief beschikbaar is.

Het zal wel aan mij ons liggen maar ik vat dit ook niet helemaal hoor.

[ Voor 3% gewijzigd door bigben04 op 12-12-2003 16:35 ]

[Exirion]

Je hebt blijkbaar niet gedacht aan IPv6 adressen die dubbele punten bevatten en in het algemeen in URLs tussen brackets staan

[jvdmeer]

curry684 schreef op 12 december 2003 @ 16:13:
Heb je al wel gekeken wat ie meer produceert?

Volgens mij heb ik dat net in de posting erboven vermeld.

curry684 schreef op 12 december 2003 @ 16:13:
Een class? Tis 1 functiecall?

Sorrie, klopt. Zat net even met de hele class van TURL in mijn hoofd.

curry684 schreef op 12 december 2003 @ 16:27:
Vooral als het wiel reeds gestandaardiseerd en uitgeevolueerd is, en onderdeel van de specificaties van het platform waarvoor je ontwikkeld, en zelfs automatisch een nieuwe vorm krijgt als er nieuwe eisen aan het concept 'wiel' gesteld worden.

Maar de API-call is niet bruikbaar zodra ik de CLX-componenten ga gebruiken om richting Linux te compilen. Dat is de reden dat (indien beschikbaar) ik liever geen API-calls gebruik.

[b]bigben04 schreef op 12 december 2003 @ 16:35:Het zal wel aan mij ons liggen maar ik vat dit ook niet helemaal hoor.

Ik bedoel dat ik graag standaard componenten gebruik, zolang 't maar geen windows API is, want die zijn zo moeilijk herbruikbaar tussen VCL/Windows/Delphi en CLX/Linux/Kylix.

[curry684]

jvdmeer schreef op 15 december 2003 @ 00:07:
[...]
Volgens mij heb ik dat net in de posting erboven vermeld.

Je hebt het vermeld ja, maar er niet naar gekeken Het zijn namelijk gewoon duplicates die samen veelgebruikte combinaties vormen zoals de URI: hij splitst niet verder op maar biedt alvast wat standaard combinaties aan.

Maar de API-call is niet bruikbaar zodra ik de CLX-componenten ga gebruiken om richting Linux te compilen. Dat is de reden dat (indien beschikbaar) ik liever geen API-calls gebruik.

2 words: conditional compiling.

[jvdmeer]

curry684 schreef op 15 december 2003 @ 10:55:
2 words: conditional compiling.

2 woorden, 2x werk...

code:

{$IFDEF MSWINDOWS}
  API-CALL aanroepen
{$ELSE}
  Andere code die altijd bruikbaar is.
{$ENDIF}

Gebruik ik liever "Andere code die altijd bruikbaar is"

[curry684]

Delphi:

{$IFDEF MSWINDOWS}
  Platform-specific code aanroepen die altijd up-to-date is
{$IFDEF LINUX}
  Platform-specific code aanroepen die altijd up-to-date is
{$ELSE}
  Ongeoptimaliseerde algemene implementatie aanroepen voor andere platforms
{$ENDIF}

Maar wat jij wil hoor, jouw feestje

[jvdmeer]

curry684 schreef op 16 december 2003 @ 09:05:

Delphi:

{$IFDEF MSWINDOWS}
  Platform-specific code aanroepen die altijd up-to-date is
{$IFDEF LINUX}
  Platform-specific code aanroepen die altijd up-to-date is
{$ELSE}
  Ongeoptimaliseerde algemene implementatie aanroepen voor andere platforms
{$ENDIF}

Maar wat jij wil hoor, jouw feestje

Klinkt toch wel goed... waar vind ik de linux-versie van InternetCrackURL?

[curry684]

jvdmeer schreef op 16 december 2003 @ 12:02:
[...]
Klinkt toch wel goed... waar vind ik de linux-versie van InternetCrackURL?

Geen idee of die er is, * curry684 windowshippie remember

Maar de essentie van het verhaal is: als er een inherente platform-optimized en auto-updating functionaliteit is gebruik je die. Als je cross-platform aan het developen bent kun en moet je vanzelfsprekend een algemene implementatie aanleveren, maar niets houdt je tegen waar mogelijk jezelf een groot plezier te doen door het gebruiken van API-calls: daar zijn ze tenslotte voor.