Indy er en ganske kraftig pakke med komponenter som lar deg utvikle ulike nettverksapplikasjoner. I denne opplæringen vil jeg fortelle deg hvordan du kan lage klient-serverapplikasjoner ved å bruke TIdTCPClient- og TIdTCPServer-komponentene.

Først av alt vil jeg merke meg to viktige fordeler med disse komponentene. Den viktigste av dem er multithreading, som betyr at serveren lager en egen tråd for hver klient, og dette påvirker absolutt ytelsen til serverprogrammet på datamaskiner med flerkjerneprosessor. Den andre fordelen er brukervennlighet. 10-20 linjer med kode er nok til å skrive en enkel klient-server-applikasjon. Denne pakken med komponenter finnes i standard Delphi-sammenstillinger.

La oss skrive et enkelt program, som lar deg overføre en tekstmelding fra en klient til en server. La oss begynne å lage serveren.
La oss plassere IdTCPServer-komponenten fra "Indy Servers"-fanen på skjemaet. Vi vil gjøre alle innstillingene for denne komponenten under kjøring i OnCreate-hendelsen i skjemaet:
IdTCPServer1.DefaultPort:= 12345;
IdTCPServer1.Active:= sant;
Alt er enkelt her - vi angir porten som serveren skal fungere på, og aktiverer selve serveren.

For å motta data på serveren fra klienten, er det en spesiell hendelse "OnExecute". Denne hendelsen ser slik ut:

begynne
slutt;

La oss redigere hendelsesinnholdet som følger:
prosedyre TForm3.IdTCPServer1Execute(AContext: TIdContext);
var
l:streng; // strengvariabel som vi vil motta
begynne
l:= AContext.Connection.IOHandler.ReadLn();
Memo1.Lines.Add(l);
slutt;

Nå, så snart en melding kommer på serveren, vil vi skrive den til strengvariabelen l og sende den ut til et tekstfelt med flere linjer.

Dette avslutter ikke overraskende opprettelsen av serveren. Indy vil gjøre resten for oss. La oss starte med klientprogrammet. Den vil koble til serveren, sende en melding til den og koble fra serveren.

La oss skape nytt prosjekt, plasser IdTCPClient-komponenten på skjemaet, som du finner på "Indy Clients"-fanen. Vi vil også plassere en enkel redigering og en knapp. La oss lage en OnClick hendelsesbehandler for knappen, der vi vil skrive:
IdTCPClient1.Port:= 12345;
IdTCPClient1.Host:= '127.0.0.1';
IdTCPClient1.Connect;
IdTCPClient1.IOHandler.WriteLn(Edit1.Text);
IdTCPClient1.Koble fra;

Denne koden trenger ikke å plasseres i OnCreate-hendelsen. Du kan plassere denne koden hvor som helst hvis du ønsker det.
I den første linjen tildeler vi en port, og det er nødvendig å spesifisere den samme porten som vi spesifiserte i serverprogrammet, ellers vil klienten ganske enkelt ikke finne serveren. Deretter angir vi IP-adressen til serveren. Selve serveren kan være plassert enten i lokalt nettverk, og eksternt. I sistnevnte tilfelle vil tilkoblingen gjøres via Internett, og du må spesifisere en IP-adresse på Internett.

Jeg spesifiserte adressen "127.0.0.1", som betyr at serveren er datamaskinen som klienten kjører på. Denne metoden er veldig praktisk for å teste nettverksapplikasjoner.
Deretter oppretter vi en kobling, sender en melding og kobler fra. Akkurat som selve meldingen kan du også ta IP-adressen fra Edit eller fra en hvilken som helst strengvariabel.

Arbeidet med klientprogrammet er også avsluttet. Som du kan se, gjør Indy en enorm jobb for oss, som gjør det mulig for selv en uerfaren programmerer å lage sin egen nettverksapplikasjon.

UDP-protokollen er ganske god for overføring tekstmeldinger, det vil si at du kan organisere lokale chatter og lignende. Jeg bestemte meg for å gi et eksempel på det enkleste arbeidet med UDP i Delphi.

Trinn-for-steg instruksjon:

Jeg ga et eksempel, men tilgi meg, jeg skrev ikke ned hver linje, fordi... Jeg ser ikke noe komplisert, og alle kan finne ut av det.

Faktisk, hvis noe er uklart, kan du stille meg et spørsmål. Og her er den faktiske koden:

bruker
Windows, meldinger, SysUtils, varianter, klasser, grafikk, kontroller, skjemaer,
Dialoger, StdCtrls, IdUDPServer, IdBaseComponent, IdComponent, IdUDPBase,
IdUDPClient, IdSocketHandle;

type
TForm1 = klasse(TForm)
IdUDPClient1: TIdUDPClient;
IdUDPServer1: TIdUDPServer;
Knapp1: TBknapp;
Etikett1: TLabel;
prosedyre FormCreate(Sender: TObject);
prosedyre FormClose(Avsender: TObject; var Handling: TCloseAction);
prosedyre Button1Click(Sender: TObject);
prosedyre IdUDPServer1UDPRead(ATråd: TIdUDPListenerThread; AData: TBytes;
ABinding: TIdSocketHandle);
privat
(Private erklæringer)
offentlig
(Offentlige erklæringer)
slutt;

var
Form1: TForm1;

($R *.dfm)
[b]//Prosedyre for å sende en melding
prosedyre TForm1.Button1Click(Sender: TObject);
begynne
prøve
IdUDPClient1.Active:= Sant;
IdUDPClient1.Host:= "localhost";
IdUDPClient1.Connect;
hvis IdUDPClient1.Connected da
begynne
IdUDPClient1.Send(TimeToStr(Time));
Label1.Caption:= "ok";
slutt;
IdUDPClient1.Active:= False;
Pip;Pip;Pip;
unntatt
MessageDlg("Noe gikk galt =(", mtError, , 0);
slutt;
slutt;
[b]
//På av. UDP-server ved oppstart og lukking av skjemaet
prosedyre TForm1.FormClose(Sender: TObject; var Handling: TCloseAction);
begynne
IdUDPServer1.Active:= False;
slutt;

prosedyre TForm1.FormCreate(Sender: TObject);
begynne
IdUDPServer1.Active:= Sant;
slutt;

[b]// Serverreaksjonsprosedyre ved mottak av data
prosedyre TForm1.IdUDPServer1UDPRead(ATråd: TIdUDPListenerThread;
AData: TBytes; ABinding: TIdSocketHandle);
Var
i: Heltall;
s:streng;
begynne
s:= "";
prøve
i:= 0;
mens (AData[i] 0) gjør
begynne
s:= s + chr(AData[i]);
i:= i + 1;
slutt;
endelig
Label1.Caption:= s;
slutt;
slutt;

Serge Dosyukov Mike Pham

Denne artikkelen viser deg hvordan du oppretter en frittstående webtjeneste ved å bruke Indy-settet og Delphi 7, og hvordan du bruker Indy-settet til å støtte Delphi 7 SOAP-baserte webtjenester. Bak tilleggsinformasjon For informasjon om å lage webtjenester, se Nick Hodges' utmerkede artikkel på Borland-fellesskapets nettsted: Shakespeare on the Web.

Før eller siden må du kanskje opprette en server som er en frittstående HTTP-server og støtter webtjenester. For eksempel vil du kanskje lage en SOAP-basert applikasjonsserver for en n-tier applikasjon bygget ved hjelp av Delphi.

Introduksjon

Delphis online hjelp gir utmerket sekvensiell instruksjon om hvordan du oppretter en webtjeneste, MIDAS-server (COM, DCOM-modell), men det er praktisk talt ingen informasjon om å lage en frittstående n-tier MIDAS-applikasjon basert på SOAP-protokollen.

Tidligere utgitt av Dave Nottage. Denne artikkelen beskrev ideen om hvordan du oppretter en webtjeneste i Delphi 6 med SOAP-støtte og muligheten til å publisere SOAP-grensesnitt til Datamodulen, det vil si at denne artikkelen tillot deg å lære hvordan du lager din egen n-tier MIDAS-systemer.

Borlands Delphi 7 og det nye Indy-settet har innebygd støtte for denne funksjonaliteten.

Til tross for innebygd støtte er denne funksjonen imidlertid ikke dokumentert.

Nylige innlegg på Borland-nettverkskonferansen og søk på nettet ved hjelp av en Google-server har gjort det mulig for forfatterne å utvikle en måte å konvertere eksisterende kode fra Delphi 6 til Delphi 7. Men alt har sin tid.

hovedide

Denne artikkelen er første del av en tredelt serie. Den beskriver hovedbestemmelsene. Den andre og tredje delen vil bli viet til noen problemer og måter å løse dem på. La oss begynne å beskrive hovedideen.

• være en frittstående HTTP-server;
• bruk Indy som plattform;
• støtte publisering via SOAP-protokoll;
• være i stand til å publisere SOAP DataModules, som vil tillate deg å lage din egen n-tier server basert på SOAP/HTML.

HTTP-server og SOAP

Mange kjenner Indy og har brukt THTTPServer-komponenter før. Det er enkelt å sette denne komponenten på et søknadsskjema, men hvordan får du den til å støtte SOAP? I katalogen "C:Program FilesBorlandDelphi7SourceIndy" kan du finne filen IdHTTPWebBrokerBridge.pas. Dette er akkurat det du trenger.

Denne filen er ikke en del av den kjørbare Indy-filen, så du må inkludere den i ditt nåværende prosjekt som en standard prosjektfil. (For å kompilere prosjektet trenger du også filen IdCompilerDefines.inc.) Disse filene må kopieres til gjeldende prosjektkatalog. Kodeendringer kan være nødvendig for å øke hastigheten, så det er best å holde disse filene atskilt fra Indy-distribusjonen.

Det følgende beskriver implementeringen av en erstatningskomponent fra THTTPServer, utvidet til å støtte SOAP-pakker, kalt TIdHTTPWebBrokerBridge. Denne konstruksjonen er en klasse som arver fra TCustomHTTPServer og støtter grunnleggende forespørselsbinding.

Fordi denne klassen ikke er tilgjengelig fra paletten, må du definere den som et vanlig objekt når du kjører koden.

Dette objektet kan brukes på nøyaktig samme måte som en vanlig THTTPServer, med unntak av de tilleggsegenskapene som muliggjør drift med SOAP.
La oss imidlertid først se på å forberede den nødvendige koden.

WebBroker og Indy

For de som har laget webtjenester før, vet du at du bruker WebBroker. Delphi 7, som Delphi 6, bruker WebBroker-arkitekturen for å støtte SOAP.

Derfor må du lage en modul TWebModule og plasser følgende tre komponenter i den: THTTPSoapDispatcher, THTTPSoapPascalInvoker og TWSDLHTMLPublish. Alle er tilgjengelige fra WebServices-fanen i komponentpaletten. Etter å ha koblet SOAPDispatcher med SOAPPascalInvoker, er søknadsskjemaet klart. Sluttresultatet skal være omtrent som det som vises i følgende figur:

(modul uWebModule.pas)

Det er best å la alt være som det er, siden det ikke er nødvendig å endre eller kjøre noen egendefinert kode for dette skjemaet.

WebModule og Indy

La oss gå videre til den andre delen av koden som trengs for å implementere HTTP-serveren.

Som du kan se, har TIdHTTPWebBrokerBridge en RegisterWebModuleClass-metode, som lar deg registrere din egen WebModule og gjøre den tilgjengelig for serveren.

Derfor, etter å ha opprettet fServer-serverobjektet, trenger du bare å kalle klassen fServer.RegisterWebModuleClass (TwmSOAPIndy).

Merk. I en normal implementering av TIdHTTPWebBrokerBridge vil et TwmSOAPIndy-objekt bli opprettet hver gang en forespørsel mottas. Dette er åpenbart ikke nødvendig. Derfor kan klassen endres for å gi permanent opprettelse av dette objektet så lenge Server-objektet eksisterer. Det anbefales at du refererer til klasfor mer informasjon.

Er serveren klar?

Indy-komponenter brukt i Delphi 6.

I tillegg til grunnleggende Internett-tjenester og protokoller, er det et bredt spekter av tilleggstjenester, som ofte brukes av Internett-utviklere. I tillegg er muligheten til å vise informasjon ved hjelp av en nettleser ikke alltid en akseptabel løsning for Internett-applikasjoner. I dette tilfellet er det rimelig å bruke Internett-infrastrukturen for datautveksling, og gi informasjonsvisning gjennom mer komplekse klientapplikasjoner utviklet for eksempel i Delphi.

La oss si at du må implementere spesialisert serverlogikk som ikke er inkludert i standard webservere. For å løse denne klassen av problemer inkluderer Delphi Internet Direct (Indy)-biblioteket fra Nevrona Designs (http://www.nevrona.com/Indy/). Dette biblioteket, utviklet spesielt for Borland Delphi, har allerede åtte versjoner, hvorav den siste er inkludert i ny verson Delphi. Settet med komponenter er delt inn i tre grupper: klient (Indy Client), server (Indy Servers) og auxiliary (Indy Misc).

Indy-klienter og Indy-servere

Flertall Indy komponenter Klient- og Indy-servere er par som tilsvarer klient- og serverdelene av protokoller og tjenester (med unntak av individuelle, hovedsakelig serverbaserte komponenter som TunnelMaster og TunnelSlave), og tillater bruk av protokoller som TCP/IP, UDP, NNTP, SMTP, FTP, HTTP, samt ECHO, FINGER, WHOIS, etc. tjenester.

Indy-klientkomponenter er skrevet ved hjelp av sockets. Klientsidekontakten krever en tilkobling til serveren. Hvis tilkoblingen er opprettet, kan klienten og serveren begynne å utveksle meldinger. Disse meldingene er av en annen karakter, men vanligvis skjer utvekslingen ved hjelp av en bestemt protokoll (for eksempel HTTP)

TIdTCPClient og TIdTCPServer

Disse komponentene brukes til å støtte en av hovednettverksprotokollene - TCP (Transmission Control Protocol), og er også basisklassene for TIdSMTP- og TIdFTP-komponentene. TIdTCPServer-klassen har en ThreadMgr-egenskap som som standard er null. Hvis ThreadMgr er null når TIdTCPServer er aktivert, vil TIdThreadMgrDeafault-klassen bli opprettet implisitt. Ellers brukes den installerte prosessbehandleren.

TIdUDPClient og TIdUDPServer

Disse komponentene brukes til å støtte nettverksprotokoll UDP (User Datagram Protocol) og er også basisklassene for en rekke andre Indy-komponenter.

TIdChargenServer

Komponenten brukes til å generere tilfeldige symboler, vanligvis for testformål.

TIdDayTime og TIdDayTimeServer

Komponentene brukes til å gi tidsservice. Klienten ber om, og serveren rapporterer gjeldende dato og klokkeslett.

TIdDNSResolver

Dette er en klientkomponent som betjener forespørsler fra en DNS-server (Domain Name Service). DNS-serverspørringer er laget for å erstatte en datamaskins navn med IP-adressen. TIdDNSResolver er en etterkommer av TIdUDPClient-klassen.

TIDDICTServer

En serverkomponent som støtter Dictionary Server Protocol (DICT), en serversideordbok basert på TCP-protokollen som lar en klient få tilgang til en naturlig språkordbok.

TIdDISCARDServer

Serverkomponenten som støtter postserveren. Opptakene kan brukes som et feilsøkings- og måleverktøy. Journaltjenesten overlater ganske enkelt alle data til den som er villig til å motta den.

TI dEcho og TI deCHOServer

Komponentene er designet for å gi en responstjeneste, vanligvis brukt til å sjekke helsen til nettverket. Klienten sender en tekstmelding til serveren, serveren returnerer meldingen til klienten. Hvis meldingen er forvansket, fungerer nettverket feil.

TIdFinger og TIdFingerServer

Komponentene er designet for å gi en protokoll som lar en bruker spørre etter data angående tilstedeværelsen av andre brukere på systemet. Noen servere håndterer slike klientforespørsler. Ved å bruke dette komponentparet kan du betjene klientforespørsler som bestemmer tilstedeværelsen av andre brukere på systemet.

Komponenten inkluderer full støtte for filoverføringsprotokollen - FTP (File Transfer Protocol). Passiv og aktiv dataoverføring støttes, samt operasjoner som GET og PUT, sletting av kataloger, innhenting av kvoter, fil- og katalogstørrelser. TI dFTP bruker TIdSimpleServer-klassen for å operere. Når en FTP-filoverføring pågår, åpnes en sekundær TCP-tilkobling for dataoverføring og lukkes når dataene er overført. Denne forbindelsen kalles en "datalink", unik for hver fil som overføres.

TIdGopher og TIdGopherServer

Disse komponentene er designet for å gi en nettverksprotokoll som er erstattet I det siste fra WWW ( Verdensomspennende Web) HTTP-protokoll. Serveren som implementerer denne protokollen gir et hierarkisk distribuert dokumentflytstøttesystem. Et eksempel på bruk av dette komponentparet, som ligger i katalogen demosindyGopherClient og demosindy GopherServer, viser hvordan du ved å bruke denne protokollen kan gi informasjon om filer på datamaskinen din, inkludert lukkede, på et lokalt nettverk.

TIdHostNameServer

En serverkomponent designet for å sende det lokale servernavnet til klienter.

TIdHTTP og TIdHTTPServer

Komponentene brukes til å gi HTTP-nettverksprotokollen (versjoner 1.0 og 1.1 støttes, inkludert GET-, POST- og HEAD-operasjoner). I tillegg gis det støtte for autentisering og bruk av proxy-servere. Serverkomponenten brukes til å levere tjenester til en annen webserver som støtter en gitt protokoll. TIdHTTPServer forenkler implementeringen av funksjoner som informasjonskapsler, tilstandsadministrasjon, etc.

TIdIcmpClient

En klientkomponent designet for å gi Internet Control Message Protocol (ICMP), som brukes til å utføre ping-operasjoner og nettverkssporing.

En klientkomponent designet for å gi Post Office Protocol (POP), inkludert støtte for MIME-koding og dekoding, og multibyte-tegnoverføring.

TIdIMAP4Server

En serverkomponent designet for å støtte IMAP-operasjoner (Internet Message Access Protocol) på serveren. Protokollen lar deg søke etter meldinger E-post på server. Forskjellen mellom IMAP- og POP-protokollene er at POP-protokollen krever ekstra minne for å lagre data, og IMAP-protokollen får tilgang til serveren i stedet for klientmaskinen. IMAP4 ble opprettet for å erstatte POP3, men POP3 er fortsatt en mye brukt standard den dag i dag.

TIdIRCServer

En serverkomponent designet for å støtte de mest brukte tjenesteoperasjonene på Internett, ofte kalt chat. Komponenten gir grunnleggende byggeklosser for IRC (Internet Relay Chat) server.

TIdMappedPortTCP

En serverkomponent designet for å lage kartlagte porter, som ofte brukes i proxy-servere. Metodene til denne komponenten lar deg kartlegge en port til en annen. For eksempel kan port 80 tilordnes port 3000, og alle forespørsler til den første porten (port 80) vil bli videresendt til den andre porten (port 3000).

TIdNNTP og TIdNNTPServer

Disse komponentene er nødvendige for å støtte Network News Transfer Protocol (NNTP) som brukes i nyhetstjenester. Klientkomponenten inkluderer støtte for MIME-koding og -dekoding, samt støtte for multibyte-tegn og alternative kodinger. Serverkomponenten lar deg lage nyhetsservere. Det er viktig å merke seg at TIdNNTPServer ikke er en fullverdig nyhetsserver, men en komponent som gir den grunnleggende funksjonaliteten for en slik server.

TIdQOTD og TIdQOTDServer

Komponentene brukes til å tilby tjenesten Dagens tilbud. Klientkomponenten kobles til serverkomponentforekomsten for å få det daglige tilbudet. Hver serverforekomst inneholder en unik sitasjonsdatabase.

En klientkomponent designet for bruk i SMTP-applikasjoner (Simple Mail Transfer Protocol), som gir støtte for autentisering, MIME-koding og -dekoding og støtte for flere byte-tegn.

En klientkomponent designet for å gi SNTP (Simple Network Time Protocol) - en tidstjeneste. Kan brukes til å koble til når som helst tjeneste for å bestemme gjeldende datoer og tid.

TIdSimpleServer

Serverkomponent som gir en lett TCP-server. Lar deg organisere en punkt-til-punkt-tilkobling. Den brukes til å lage servere med en enkelt bruker, det vil si at den kun kan betjene én tilkobling om gangen. I motsetning til TIdTCPServer-komponenten, skaper den ikke sekundære prosesser når man venter på forespørsler fra klienter og når disse forespørslene behandles. Med andre ord, hvis serveren betjener en forespørsel fra en klient, og på det tidspunktet en annen klient kontakter den for å koble til, vil den bli blokkert til slutten av behandlingen av den første forespørselen.

TIdTelnet og TIdTelnetServer

Klientkomponenten brukes til å organisere eksterne økter på en annen datamaskin, inkludert konsollforhandlinger og autentisering. Kommunikasjonsprotokollen forutsetter tilstedeværelsen av en person som interagerer interaktivt med serveren. Klientkomponenten har ikke skjermstøtte eller terminalemulering, men gir rett og slett en tilkobling til serverdelen. Vanligvis brukes TIdTelnetServer-serverprotokollen til å organisere eksterne databaser med et tekstgrensesnitt for interaktiv interaksjon med klienter.

TIdTime og TIdTimeServer

Klientkomponenten er et alternativ til TIdSNTP-komponenten for tidsbestemmelse. Det er viktig å merke seg at formatene til de to protokollene er forskjellige. TIdTime er basert på RFC 868-formatet (returnerer tiden i den interne UNIX OS-standarden, og utfører alle nødvendige konverteringer). Serverkomponenten fungerer på samme måte som DayTime-serveren. Kan brukes til å implementere en tidstjeneste på lokal datamaskin. Ingen tilleggskode er nødvendig, bare opprett en forekomst av TIdTimeServer som vil returnere klokkeslettet til serverdatamaskinens interne klokke.

TIdTrivialFTP og TIdTrivialFTPServer

Disse komponentene er nødvendige for å organisere en enkel filoverføringsprotokoll. Klientkomponenten til denne protokollen brukes til å koble til en forekomst av den tilsvarende serverkomponenten. Protokollen er beregnet på private, lette, lokale tilfeller av filoverføring, for eksempel i lokale nettverk eller for å laste (opplasting) rutingtabeller til rutere. På grunn av de svekkede egenskapene til denne protokollen, anbefales ikke bruken av den ved bruk av autentiseringsalgoritmer eller andre sikkerhetsmekanismer. Hovedformålet med denne protokollen er å overføre filer til en maskinvareenhet med det formål å endre den.

TIdTunnelMaster og TIdTunnelSlave

Servertunnelkomponenter brukes i proxy-servere for å organisere flere logiske forbindelser over en fysisk (tunnel). Disse klassene kan brukes til ulike formål, for eksempel for å organisere en hemmelig forbindelse over ikke-hemmelige kanaler.

TIdWhois og TIdWhoIsServer

Denne klientkomponenten kobles til en hvilken som helst standard Whois-server, slik at du kan få informasjon om domener. Serverkomponenten gir den grunnleggende funksjonaliteten til en NIC-server.

Indy Diverse

Indy Diverse Components-palettsiden inkluderer BASE64, UUE, Quoted Printable og andre vanlige e-postkommunikasjonsformater, kodere (MD2, MD4 og MD5) for kryptografistandarder som brukes til å lagre passord og elektroniske signaturer i en irreversibel (vanskelig å tyde) form, samt mange andre nyttige komponenter og verktøy som ofte brukes i utviklingen av Internett-applikasjoner.

TIdAntiFreeze

På grunn av de blokkbaserte algoritmene til Indy-komponenter, ser det ofte ut til at applikasjonen sitter fast mens tilkoblingen fungerer. For å eliminere bruken av sekundære prosesser (tråder) når du organiserer kommunikasjon for å forhindre at applikasjonen fryser, er det nok å plassere den angitte komponenten på skjemaet.

Komponenten fungerer ved å analysere forespørsler fra TCP/IP-protokollstakken og sende meldinger til applikasjonen under forsinkelsen når eksterne tilkoblinger er blokkert, noe som skaper en illusjon av kjørende kode. Siden komponenten kun påvirker blokkerte tilkoblinger for hovedprosessen, er det ikke nødvendig å bruke TIdAntiFreeze i sekundære prosesser av applikasjonen. Vær oppmerksom på at TIdAntiFreeze-komponenten bremser tilkoblingene fordi hovedprosessen med jevne mellomrom avbrytes for å behandle meldinger. Det følger av dette at man må passe på at applikasjonen som utvikles ikke bruker for mye tid på å behandle meldinger, inkludert OnClick, OnPaint, OnResize osv. Til en viss grad kan dette kontrolleres gjennom egenskapene til TIdAntiFreeze-klassen. Bruken av denne komponenten er ikke obligatorisk, men den lar deg løse problemet med å synkronisere tilkoblinger med det visuelle grensesnittet til applikasjonen.

TIdDateTimeStamp

En klasse for å utføre matematikk for dato og klokkeslett knyttet til det faktum at Internett-protokoller bruker forskjellige dato- og klokkeslettformater; i tillegg kan klienter og servere være plassert i forskjellige tidssoner.

TIdIPWatch

Det er en timerbasert komponent som hele tiden overvåker endringer i datamaskinens IP-adresse. Komponenthendelser oppstår når en endring oppdages. Denne komponenten brukes vanligvis til å oppdage om en datamaskin er koblet til Internett eller et annet nettverk. Endringen i IP-adressen i denne situasjonen kan oppstå på grunn av at IP-adressen blir tildelt av DHCP-serveren (Dynamic Host Configuration Protocol) når den kobles til det nye nettverket.

TIdLogDebug

Hensikten med denne komponenten er å avskjære hendelser for enhver klient- eller serverkomponent og plassere en registrering av hendelsen i spesifisert fil. Denne komponenten er veldig nyttig for feilsøking av Indy-komponenter.

TIdMessage

Komponenten brukes i kombinasjon med andre komponenter for å riktig dekryptere eller kode meldinger. Disse kan være POP-, SMTP- og NNTP-komponenter. Klassen støtter MIME-kryptering og dekryptering, multibyte-tegn og ISO-koding.

TIdNetwork Calculator

En av få Indy-komponenter som kan brukes når du bygger applikasjoner. Nettverkskalkulatoren kan brukes til å utføre beregninger på IP-adresser, inkludert nettverksmasker, subnett, nettverksklasser osv.

TIdThreadMgrDefault

Komponenten gir kontroll over sekundære prosesser som standard. Opprettet når en Indy-komponent som støtter prosessbehandling ikke har en forekomst av TIdThreadManager-klassen definert. Komponenten gir bare grunnleggende funksjoner for å administrere sekundære prosesser: opprette og ødelegge dem på forespørsel.

TIdThreadMgrPool

En mer avansert prosessstyringskomponent enn TIdThreadMgrDefault fordi den slår sammen prosesser i stedet for å opprette eller ødelegge dem på forespørsel.

TIdVCard

VCard er den elektroniske ekvivalenten til et visittkort og kan inneholde eierens personlige opplysninger og grafiske data.

TIdIMFDecoder

Designet for å dekode Internett-meldinger. Den er en etterkommer av TIdCoder-klassen, akkurat som alle andre kodekomponenter. TIdCoder-klassen dekoder i henhold til ARPA Internett-tekstmeldingsformatstandard RFS-822, foreslått i august 1982, og USENET meldingsstandard RFC 1036, foreslått i desember 1987.

Komponenten utvider TIdCoder-klassen for å tillate gjenkjenning av RFS-822-format etter header-kontekst, og gir dekryptering-ved-mottak-modus og MIME-kryptering og dekryptering. TIdIMFDecoder-komponenten brukes i TIdMessageClient-klassen for å dekode mottatte og overførte meldinger.

TIdQuotedPrintableEncoder

QuotedPrintableEncoder lar deg dekryptere tekst i det angitte formatet. Kan fungere som en frittstående komponent med en spesifisert kodingstype, slik at meldinger som inneholder en ny kodingstype kan overføres.

TIdBase64 Encoder

Implementerer en annen krypteringsalgoritme som gjør det mulig å overføre tegn som ikke kan skrives ut.

TIdUUEncoder

Implementerer en av de første krypteringsalgoritmene, UU-koding. Noen ganger brukt når du sender artikler til en nyhetstjeneste.

TIdXXEncoder

Denne krypteringsmetoden vil neppe noen gang bli brukt. I hovedsak er dette den samme UU-kodingen, men med en annen krypteringstabell.

TIdCoderMD2

Komponenter med forskjellige typer MD (Message Digest) krypteringsalgoritme. De er alle shuffle-baserte, enveis, og har ingen dekrypteringsalgoritmer.

Komponenter av protokollklienter og servere kan brukes til å utvikle server- og klientinternettapplikasjoner, sammen med eller i stedet for grunnleggende (ClientSocket, ServerSocket) og andre komponenter fra Internett- og Fastnet-paletten. Indy-komponenter bruker ikke WebBroker-arkitekturen, og implementerer lavnivåstøtte for Internett-protokoller og tjenester direkte i kildekoden ( kildekoder er vedlagt).

TIdConnectionInterceptOpenSSL og TIdServerInterceptOpenSSL

SSL-protokollen - Secure Sockets Layer, som sikrer hemmelighold og pålitelighet av kommunikasjon mellom to applikasjoner, har to lag. På det lave nivået av en flerlags transportprotokoll (som TCP), er SSL en opptaksprotokoll og brukes til å innkapsle forskjellige protokoller på høyere nivå. Fordelen med SSL er at det er en uavhengig applikasjonsprotokoll, men en protokoll på høyere nivå kan brukes på toppen av SSL.

SSL gir kommunikasjonssikkerhet, som har tre hovedfunksjoner: å tilby en konfidensiell tilkobling; kryptering med offentlig nøkkel(brukes for å bekrefte autentisiteten til adressaten); støtte for pålitelighet av dataoverføring.

• Symmetrisk kryptografi brukes til å kryptere data (f.eks. DES, RC4 osv.).
• Digital signatur leveres ved bruk av asymmetrisk offentlig nøkkelkryptering (for eksempel RSA, DSS, etc.).
• Pålitelighet av kommunikasjon, meldingstransport inkluderer å sjekke integriteten til meldingen gjennom MAC-korreksjonskoder, sikre hash-funksjoner (f.eks. SHA, MD5, etc.) ved hjelp av MAC-beregninger.

Kombinert med HTTP og serverautentisering gir SSL nødvendige funksjoner kryptering og videre opprettholder den etablerte forbindelsen, dobbeltsjekker ektheten til webserveren, etc. Det er viktig å forstå at SSL kun beskytter kommunikasjon under dataoverføring og ikke erstatter andre sikkerhetsmekanismer.

TIdConnectionInterceptOpenSSL- og TIdServerInterceptOpenSSL-komponentene gir både klient- og server-side tilkoblinger ved hjelp av SSL-protokollen. Det skal bemerkes at TIdConnectionInterceptOpenSSL- og TIdServerInterceptOpenSSL-komponentene kun er tilgjengelige i Delphi 6, og ikke i Kylix. Dette skyldes kompleksiteten til protokollen, som i tilfelle av en Windows-implementering er basert på operativsystemfunksjoner.

Eksempler på bruk av Indy-komponenter finnes i /Delphi6/Demos/Indy-katalogene. Totalt inneholder Indy-biblioteket i versjon 8.0 69 komponenter. Det er oppgitt at i versjon 9.0 vil det angitte biblioteket inneholde 86 komponenter. Alle komponentene er forent og inkludert i både Delphi 6 og Kylix, noe som gjør at de kan brukes til å utvikle tverrplattformapplikasjoner. Alle Indy-komponenter støtter multithreading.

Indy-komponentene implementerer nesten all funksjonaliteten som finnes i Internett- og Fastnet-komponentene, som tydelig vises i tabellen.

	Fastn et komponenter	Indy komponenter	Formål med komponenter
1	TserverSocket, TClientSocket	TIdTCPserverSocket, TIdTCPClientSocket	Interaksjon mellom to datamaskiner (klient og server) ved hjelp av TCP/IP-protokollen
2	TNMDayTime	TIdDayTime, TIdDayTimeServer	Spør serveren for gjeldende tidspunkt
3	TNMEcho	TIdEcho, TIdEchoServer	Brukes til å kommunisere med responsserveren
4	TNMFinger	TIdFinger, TIdFingerServer	Brukes til å hente informasjon om brukeren fra en Internett-søkeserver
5	TNMFTP	TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer	Gi filoverføring ved hjelp av FTP-protokoll
6	TNMHTTP	TIdHTTP, TIdHTTPServer	Bruk HTTP-protokoll for datautveksling
7	TNMMsgServ, TNMMsg		Brukes til å overføre enkle tekstmeldinger fra klient til server
8	TNMNNTP	TIdNNTP, TIdNNTPServer	Støtter datautveksling med nyhetsserver
9	TNMPOP3	TIdPOP3	Brukes til å motta e-post fra en e-postserver som bruker POP3-protokollen
10	TNMSMTP	TIdSMTP	Brukes til å sende e-post via Internett-postserver
11	TNMSrm, TNMSrmServ		Sender binære data skrevet til en strøm ved hjelp av TCP/IP-protokollen
12	TNMUDP	TIdUDP, TIdUDPServer	Overfør data ved hjelp av UDP-protokollen
13	TpowerSock, TNMGeneralServer		Komponentinnkapslede klasser som er grunnlaget for å skrive dine egne klienter (Powersock) og servere (NMGeneralServer)
14	TNMUUprosessor	TIdUUEncoder, TIdUUDekoder	Utfør omkoding binære filer til MIME- eller UUENCODE-format
15	TNMURL		Konverterer strenger til HTML-format og utfører omvendt omkoding

Unntakene er klasser som TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, som enten implementerer foreldede protokoller eller har funksjonalitet implementert i en stor gruppe alternative klasser.

Men i motsetning til forgjengerne - Internett- og Fastnet-komponentene, inneholder Indy rikere serverkomponenter og komponenter for datatranskoding og kryptering, samt autentiseringsstøtte (Indy Misc-palett). Som det fremgår av tabellen ovenfor, leveres hovedprotokollene og tjenestene ikke bare av klienten, men også av serverkomponenter. Dette er tidstjenester, responstjenester, innhenting av brukerinformasjon, samt HTTP, NNTP, UDP-protokoller og til og med den enkleste versjonen av FTP.

Noen eksempler på bruk av Indy-komponenter

I Indy-komponenter i Delphi er IP-adressen definert i Host-egenskapen, vanligvis bare i klientapplikasjoner. Server-vertsbaserte komponenter har metoder som lar deg starte eller stoppe polling av den korresponderende porten - for eksempel endring av Active-egenskapen til IdTCPServer-komponenten starter eller stopper polling av den tilsvarende porten. Når forbindelsen mellom klienten og serveren er etablert, kan dataoverføringen begynne.

Indy-komponenter legger stor vekt på sikkerhet og pålitelighet når du arbeider med data. For eksempel har IdTCPClient-komponenten Connect- og Disconnect-metoder. Ved å bruke en programmeringsteknikk som koden nedenfor fra klientsiden:

Start Connect med TCPClient; prøv lstMain.Items.Add(ReadLn); til slutt Koble fra; slutt; slutt;

og bruk av Connection-egenskapen som sendes som en parameter til AThread-forekomsten av TIdPeerThread-klassen fra serversiden:

Med AThread.Connection begynner WriteLn("Hei fra Basic Indy Server-server."); Koble fra; slutt;

du kan stole på enten normal utførelse av tilkoblingen eller riktig feilhåndtering.

Legg merke til ReadLn- og WriteLn-metodene til de tilsvarende klassene - de ligner standard Pascal I/O-setninger. Dette er en hyllest til UNIX-programmeringsteknikken, hvor de fleste systemoperasjoner utføres ved å lese og skrive til de tilsvarende filene.

Akkurat som Fastnet-komponenter, har Indy-komponentklasser hendelser som kan brukes til å gi hendelsesadministrasjon. Du kan for eksempel sørge for at en melding vises på et skjema når du kobler til en klient:

Prosedyre TForm1.IdECHOServer1Connect(ATråd: TIdPeerThread); begin lblStatus.caption:= "[ Betjener klient ]"; slutt;

Indy leverer komponenter som implementerer protokoller med klient- og serverdeler som er unike for dette biblioteket. TIdGopherServer- og TIdGopher-komponentene, takket være metodene GetExtendedMenu, GetFile, GetMenu, GetTextFile på klientsiden og ReturnGopherItem, SendDirectoryEntry på serversiden, hjelper til med å vise filer forskjellige typer, inkludert de som er merket som skjulte, samt kataloger på ekstern datamaskin(ligner på hva dir *.*-kommandoen gjør i operativsystem MS-DOS).

Ved å bruke IdSMTP- og IdMessage-komponentene kan du enkelt lage din egen webapplikasjon som kan sende e-post ved hjelp av SMTP-protokollen.

I dette tilfellet er IdMessage-klassen (en av 23 komponenter fra Indy Misc-siden) ansvarlig for å generere meldingen, som følger av navnet, og IdSMTP er for å organisere forbindelsen med e-postserveren.

Teknologien som brukes i Indy bruker låsende lese- og skriveoperasjoner. Enhver Connect-operasjon som brukes i Indy venter på at tilkoblingen skal fullføres. Når du arbeider med Indy-klientkomponenter, må du vanligvis gjøre følgende:

• be om en tilkobling til serveren;
• foreta lese- og skriveforespørsler til serveren (avhengig av typen server utføres trinnet én gang eller gjentas mange ganger);
• avslutte tilkoblingen til serveren og koble fra.

Indy-komponenter er designet for å gi et ultrahøyt abstraksjonsnivå. Forviklingene og detaljene i TCP/IP-stabelen er skjult for programmereren slik at han kan fokusere på oppgaven som skal utføres.

Følgende lille eksempel viser en typisk klientbønneøkt:

Med IndyClient begynner Host:= "zip.pbe.com"; // Vert for å ringe Port:= 6000; // Port for å ringe serveren på Connect; prøv // Koden din går her til slutt Koble fra; slutt; slutt;

I eksemplet, selv om tilkoblingen til serveren ikke er etablert, vil tilkoblingen bli avsluttet på grunn av bruken av try-finally-setningen.

Indys serverkomponenter beskriver en rekke servermodeller som kan brukes avhengig av dine behov og protokollen du bruker.

TIdTCPServer er den mest brukte serverkomponenten, som skaper en sekundær prosess uavhengig av hovedapplikasjonsprosessen. Den opprettede prosessen venter på innkommende forespørsler fra potensielle kunder. En individuell sekundær prosess opprettes for hver klient hvis forespørsel den svarer på. Hendelser som oppstår under vedlikeholdsprosessen er relatert til konteksten til de tilsvarende prosessene.

Med andre ord, for hver klienttilkobling bruker TIdTCPServer-klassen en unik sekundær tråd ved å kalle den trådens OnExecute-hendelsesbehandler. Den formelle parameteren til OnExecute-metoden er en referanse til en forekomst av Athread-klassen som tilsvarer den opprettede tråden. Connection-egenskapen til denne klassen er en referanse til TIdTCPConnection-klassen, en forekomst av denne er opprettet for å behandle klientforespørselen. TIdTCPConnection støtter lesing og skriving over forbindelsen, i tillegg til å etablere og avslutte en kommunikasjonsøkt.

UDP-protokollen fungerer uten først å etablere en forbindelse med serveren (hver sendte pakke er et uavhengig sett med data, og ikke en del av en større økt eller tilkobling). Mens TIdTCPServer skaper separate tråder for hver tilkobling, bruker TIdUDPServer enten en hovedtråd eller en enkelt sekundær tråd som håndterer alle UDP-protokollforespørsler. Når TIdUDPServer er aktiv, opprettes en tråd for å lytte etter innkommende UDP-pakker. For hver pakke som mottas, heves en OnUDPRead-hendelse enten på hovedtråden eller i konteksten til lyttetråden, avhengig av verdien til ThreadedEvent-egenskapen. Når ThreadedEvent evalueres til False, skjer hendelsen på hovedtråden, ellers skjer den på lyttetråden. Mens hendelsen behandles, blokkeres andre serveroperasjoner. Derfor er det viktig å sikre at OnUDPRead-prosedyrene kjører så raskt som mulig.

Hvis du trenger å opprette en ny klientapplikasjon for en eksisterende server ved å bruke en eksisterende protokoll, er jobben din utelukkende å utvikle og feilsøke klientapplikasjonen. Men når du skal utvikle både klient og serverapplikasjon Enten vi bruker en eksisterende eller en ny protokoll, står vi overfor det klassiske "kylling og egg"-problemet. Hvor skal jeg begynne å programmere - fra klienten eller fra serveren?

Det er klart at både klienten og serveren må opprettes til slutt. For mange applikasjoner, spesielt de som bruker en tekstbasert protokoll (som HTTP), er det lettere å begynne å bygge applikasjonen ved å designe serveren. Og for feilsøking er det en praktisk klient som allerede eksisterer. Dette er en Telnet-konsollapplikasjon som er tilgjengelig på både Windows og UNIX.

Hvis du skriver konsollen telnet kommando 127.0.0.1 80 med IP-adressen til den lokale datamaskinen og portnummer 80, som brukes som standard av webservere, vil applikasjonen svare med teksten vist i fig. 6, for Windows 2000 OS og IIS 5.0.

For å lage den enkleste serveren med Indy-komponenter trenger du:

Hvis du trenger å designe en server som ikke bare vil informere klientene sine riktig når forbindelsen er tapt, men også gi dem informasjon om feilsituasjoner som har oppstått, bruk try-except-setningen i stedet for try-finally - for eksempel som vist i følgende eksempel:

Prosedyre TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: streng; begynn med AThread.Connection prøv prøv s:= ReadLn; // Utfør oppgaven til serveren her // hvis ingen unntak oppstår, // skriv ut serverens svar WriteLn(s); bortsett fra på e: Unntak begynner WriteLn(e.Message); end; //on end; //prøve bortsett fra til slutt Koble fra; slutt; slutt;

Dette lille eksemplet viser fremgangsmåten for å lage en enkel tekstserver, samt hvordan du feilsøker den.

Serveren beskrevet ovenfor er et typisk eksempel på organisering av moderne distribuert databehandling.

Funksjoner for å lage flerlagsapplikasjoner

Nylig har flere servere i økende grad blitt brukt for å tilfredsstille klientforespørsler. En server av denne typen, etter å ha mottatt en klientforespørsel og delvis forberedt den for videre behandling, kontakter en annen server og sender den transformerte forespørselen eller forespørslene. Second-tier serveren kan i sin tur kommunisere med andre servere. Dermed kan vi snakke om en flerlags serverarkitektur.

Deretter vil vi lage en datatilgangsserver hvis formål er å returnere data fra databasen. Denne serveren leser eller skriver ikke direkte til databasefilene. I stedet kommuniserer den med databaseserveren på jakt etter dataene som kreves av klienten.

Så vi begynner å utvikle en applikasjon med en trelagsarkitektur. For å lage en databaseserver med Indy-komponenter trenger du:

1. Opprett et nytt prosjekt.
2. Plassere på hovedform prosjektforekomst av TIdTCPServer-komponenten fra Indy Servers-paletten.
3. Sett DefaultPort-egenskapen til TIdTCPServer1-klasseforekomsten til 6001 (det anbefales å tilordne store verdier for å unngå duplisering av portnumre på tvers av forskjellige applikasjoner), og sett Active-egenskapen til true.
4. Legg til en ny modul til prosjektet ved å velge Fil | Ny | Data Module, og plasser forekomster av SQLConnection- og SQLDataSet-komponentene på den fra dbExpress-fanen på komponentpaletten.
5. Sett ConnectionName-egenskapen til SQLConnection-klassen til IBLocal og LoginPrompt til False. Hvis du ikke har konfigurert IBLocal i databasen medarbeider.gdb, fullfør denne prosedyren først.

Hei alle sammen!

Ved utviklingen av det neste webprosjektet oppsto oppgaven - å implementere klientprogramvare i Delphi, som skulle overføre data til serveren ved hjelp av POST-metoden. Applikasjonen må overføre tekst og laste opp filer til webserveren.

Implementering av slik datasending ved bruk av serversidespråk webutvikling(for eksempel PHP) er ganske enkelt, men hvis du trenger å skrive applikasjonsbasert flerbrukerprogramvare som samhandler med serveren, er det litt mer komplisert. Metoden for å koble direkte til databasen og via FTP til serveren fra Delphi er ikke lenger nødvendig pga det er ikke trygt, ikke pålitelig (endre passord, tilkoblingsdata, etc.) og skaper ekstra. propå klientsiden. For å løse problemet bestemte jeg meg for å skrive skript (serverdel) i PHP som vil behandle innkommende POST-forespørsler og returner resultatet til klienten (Delphi-applikasjonen). Fordelene med denne tilnærmingen er at alle tilkoblinger og databehandling skjer på serveren, noe som er mye tryggere enn en direkte "tilkobling".

Da jeg begynte å google ble mye spredt informasjon gitt opp, mest på forum, men det hele var i stykker. En ting var sikkert at Indy ville bli brukt, nemlig IdHTTP-komponenten med POST-metoden implementert. Faktisk er alt enkelt, denne metoden tar to parametere Url for en ressurs og DataStream (datastrøm), og returnerer resultatet i tekstform (det kan også være HTML-koden til siden). Hovedsaken var riktig dannelse av DataStream (strøm av overførte data), men underveis dukket det opp flere fallgruver, nemlig den russiske kodingen (hvis den ikke var god). Det var her moroa begynte for flere timers vandring rundt på Internett. Generelt, nok skravling, la oss gå videre til praksis og implementering av programvaren.

Så programmet er enkelt. Hun må sende data til serveren ved å bruke POST-metoden, dataene inneholder " Overskrift " (linje), " Beskrivelse » ( flerlinjetekst) Og grafisk fil(jpg, png, gif-binære data). Serveren må godta disse dataene, behandle dem, lagre grafikkfilen på serveren og returnere et svar. Som et svar vil vi returnere Delphi til applikasjonen, den samme teksten bare med lagt til etiketter og en lenke til den nedlastede filen. Ingenting annet.

La oss starte med implementeringen av serverdelen (ligner på nettstedets API). Åpne hvilken som helst tekstredigerer(notisblokk) og skriv følgende kode i den:

"; ) else ( ekko "Tittel: Mangler"."
"; ) //Sjekk de innkommende dataene for tilstedeværelsen av "content"-feltdataene hvis (!empty($_POST["content"]))( echo "Content: ".$_POST["content"]."
"; ) else ( ekko "Innhold: Mangler"."
"; ) //Sjekk de innkommende dataene for tilstedeværelsen av en vedlagt fil "fil" hvis (!empty($_FILES["fil"])) ( $finfo = pathinfo($_FILES["file"]["name" ]); / /få informasjon om filen (navn, filtype osv.) //Sjekk filtypen i listen over tillatte typer (IMPROVISASJON:)) if (stripos("jpgpnggif",$finfo["extension"] )==0)( echo ">>>>>>>Ugyldig filtype<<<<<<<<"; exit; //Если не допустим тип, полностью останавливаем скрипт } $fname = "files/" . "testimgfile." . $finfo["extension"]; //формируем путь и новое имя файла move_uploaded_file($_FILES["file"]["tmp_name"],$fname);//сохраняем временный файл "tmp_name" в файл $fname echo "http://".$_SERVER["HTTP_HOST"]."/".$fname; //возвращаем полный путь к файлу } ?>

Merk! Når du lagrer (via notisblokk), må du spesifisere kodingen "UTF-8", ellers vil det være problemer med å vise det kyrilliske alfabetet!

Manuset prøvde å gi detaljerte kommentarer. Kopier dette skriptet til webserveren din, hvis du ikke har et, kan du bruke skriptet mitt til testen, det ligger på: http://api..php

Layouten bruker følgende komponenter: Label, Button (2 stk.), Edit (2 stk.), Memo (2 stk.), CheckBox, OpenDialog, IdHTTP. Gi følgende komponenter navn (egenskap " Navn”):

1. Rediger (tittel) – Navn=tittel;
2. Rediger (bane til fil) – Navn = imgfile;
3. Memo (innhold) – Navn = innhold;
4. Memo(resultat) – Navn = svar;
5. Knapp (…) – Navn = chkfile;
6. Knapp (POST) – Navn = PostBut;
7. OpenDialog (dialogboks for filvalg) – Navn = PictDialog;

La oss la IdHTTP1 og CheckBox1 være uendret (trøtt! :)))).

For ikke å være tilfeldig " redigere» sti til Rediger( imgfile), sett dens ReadOnly-egenskap til True. Likeledes kl imgfile Og chkfile Sett egenskapen Enabled til false. Vi vil aktivere dem ved hjelp av CheckBox, dvs. Vi gir deg muligheten til å velge om du vil laste opp et bilde eller ikke.

For OpenDialog( PictDialog) må du angi filteret (Filter-egenskap) som følger:

Selve visuelle forberedelsen er over! La oss begynne å kode!

I prosjektet vil vi generere en dataflyt ved å bruke typen som følger med Indy - TidMultiPartFormDataStream. Selv om vi kom over implementeringsalternativer ved å bruke TSream, jobber vi med TidMultiPartFormDataStream – lettere!

For å gjøre denne typen tilgjengelig for prosjektet vårt, må vi legge til følgende bibliotek i Uses: IdMultipartFormData.

For CheckBox1 oppretter du en OnClick-hendelse (ved å dobbeltklikke med musen på objektet) og legger til følgende kode til denne hendelsen:

Prosedyre TForm1.CheckBox1Click(Sender: TObject); start //gjør aktive eller inaktive filbaneelementene og dialogknappene imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; slutt;

Her aktiverer vi objektene imgfile Ogchkfile avhengig av tilstedeværelsen av et hakemerke (hvis avmerkingsboksen er merket av, blir objektene aktive).

La oss nå organisere bildeutvalget. For å gjøre dette, opprette en OnClick-hendelse på knappen chkfile(også ved å dobbeltklikke på objektet) og skriv følgende:

Prosedyre TForm1.chkfileClick(Sender: TObject); start //åpne dialogen og skriv inn hele banen til filen i imgfile(TEdit) hvis PictDialog.Execute deretter imgfile.Text:= PictDialog.FileName; slutt;

Denne hendelsen vil utløse en dialogboks for valg av bilder og hvis brukeren klikker " Åpen", vil banen til denne filen bli lagt til imgfile.

Og nå kommer vi til den siste "POST"-knappen. Opprett en OnClick-hendelse for denne knappen og legg til følgende kode:

Prosedyre TForm1.PostButClick(Sender: TObject); var dataPost:TIdMultiPartFormDataStream; begin dataPost:=TIdMultiPartFormDataStream.Create; dataPost.AddFormField("title",title.Text,"utf-8").ContentTransfer:= "8bit"; dataPost.AddFormField("content",content.Text,"utf-8").ContentTransfer:= "8bit"; hvis CheckBox1.Checked og (trim(imgfile.Text)="") deretter //kontrollerer om filen er valgt eller ikke begynner ShowMessage("Du må velge en grafisk fil!"); exit; slutt; if CheckBox1.Checked then dataPost.AddFile("file",imgfile.Text,""); //legg til et felt med filen response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Free; end;

Så, i rekkefølge (selv om det er kommentarer):

Datapost – type objekt TIdMultiPartFormDataStream. Lar deg lage en POST-forespørselsstruktur som består av felt av forskjellige typer.

dataPost . AddFormField (" tittel ", tittel . Tekst ," utf -8 "). Innholdsoverføring := " 8 bit "; – legger til et felt kalt "tittel" til DataPost, en verdi fra "title.Text", setter kodingen av de overførte dataene til "utf-8" (parameteren er valgfri, men uten eksplisitt indikasjon, kyrillisk overføres med spørsmålstegn "?") og en veldig viktig metode "Content Transfer". Uten denne metoden sendes data til serveren " abrakadabra" Vær oppmerksom på at feltnavnet ("tittel") på avsendersiden må samsvare med navnet spesifisert i skriptet: $_POST["tittel"].

Data overføres på samme måte som "innhold"-feltet.

dataPost . Legg til fil (" fil ", imgfile . Tekst ,"") – med denne linjen lager vi en strøm med data fra filen.

Det er det, dataene genereres, alt som gjenstår er å overføre det til skriptet på serveren og motta et svar:

response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,);

fordi TMemo forstår ikke linjeskift-taggen "
", vil vi bruke " "-funksjonen for å erstatte den med forståelige linjeskift "#13#10".

Når alt er fullført, fjern minnet fra DataPost-objektet med linjen:

datapost.Gratis;

Selv om dette i vårt eksempel vil skje automatisk på slutten av prosedyren, men likevel...

Det faktiske resultatet av programmet på skjermen:

Dermed kan vi sende så mye data eller filer til serveren vi vil, behandle disse dataene på serveren og rapportere tilbake til applikasjonen resultatet av scriptet. Det kan til og med bare være 0 eller 1, som vil signalisere at applikasjonen skal reagere videre.

Alle. Lykke til alle sammen. Jeg håper informasjonen var nyttig, og at du vil finne bruk for den.

Du kan laste ned det ferdige eksemplet og skriptet.

Full modulkode:

Unit PostUnit; grensesnittet bruker Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, IdBaseComponent, IdComponent, IdTCPConnection, Id IdHTTP, IdMultipartFormData, Vcl.ExtDlgs; type TForm1 = klasse(TForm) IdHTTP1: TIdHTTP; tittel: TEdit; innhold: TMemo; PostBut: TButton; svar: TMemo; Etikett1: TLabel; Etikett2: TLabel; Etikett3: TLabel; imgfile:TEdit; chkfile: TButton; Etikett4: TLabel; CheckBox1: TCheckBox; PictDialog:TOpenDialog; prosedyre PostButClick(Sender: TObject); prosedyre chkfileClick(Sender: TObject); prosedyre CheckBox1Click(Sender: TObject); private ( Private erklæringer ) offentlige ( Offentlige erklæringer ) slutt; var Form1: TForm1; implementering ($R *.dfm) prosedyre TForm1.CheckBox1Click(Sender: TObject); start //gjør aktive eller inaktive filbaneelementene og dialogknappene imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; slutt; prosedyre TForm1.chkfileClick(Sender: TObject); start //åpne dialogen og skriv inn hele banen til filen i imgfile(TEdit) hvis PictDialog.Execute deretter imgfile.Text:= PictDialog.FileName; slutt; prosedyre TForm1.PostButClick(Sender: TObject); var dataPost:TIdMultiPartFormDataStream; begin dataPost:=TIdMultiPartFormDataStream.Create; dataPost.AddFormField("title",title.Text,"utf-8").ContentTransfer:= "8bit"; dataPost.AddFormField("content",content.Text,"utf-8").ContentTransfer:= "8bit"; hvis CheckBox1.Checked og (trim(imgfile.Text)="") deretter //kontrollerer om filen er valgt eller ikke begynner ShowMessage("Du må velge en grafisk fil!"); exit; slutt; if CheckBox1.Checked then dataPost.AddFile("file",imgfile.Text,""); //legg til et felt med filen response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Gratis; slutt; slutt.