søk script i php / database

[eliminaaator]

hei

 

noen som kan hjelpe med søke script som søker fra ein database og må kunde søke på tittel og innhold

[Wackamole]

hvilket database oppsett har du?

[eliminaaator]

CREATE TABLE IF NOT EXISTS `nyheter` (

`id` int(11) NOT NULL auto_increment,

`tittel` text NOT NULL,

`innhold` varchar(500) NOT NULL,

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=698 ;

[TeisL]

CREATE TABLE IF NOT EXISTS `nyheter` (

`id` int(11) NOT NULL auto_increment,

`tittel` text NOT NULL,

`innhold` varchar(500) NOT NULL,

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=698 ;

Hei,

 

Sjekk du denne linken: http://www.designplace.org/scripts.php?page=1&c_id=25

[eliminaaator]

virker ikke får bare error

[MikkelRev]

hva mener du med "virker ikke", skrev du rett av det som stod i den linken til TeisL?

 

For å lage et script så at brukeren skal kunne søke gjennom databasen din, må du sette opp HTML (grensesnitt hvor brukeren taster inn søkestreng), database og PHP. Hva er det du sliter med?

[TeisL]

virker ikke får bare error

Kom med feilmeldinegene du får, så kanskje du kan få noen tips...

[kbot]

hei

 

noen som kan hjelpe med søke script som søker fra ein database og må kunde søke på tittel og innhold

 

Hvilken database er det du bruker MySql etter hva?

[kbot]

CREATE TABLE IF NOT EXISTS `nyheter` (

`id` int(11) NOT NULL auto_increment,

`tittel` text NOT NULL,

`innhold` varchar(500) NOT NULL,

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=698 ;

 

Denne databasen er ufornuftig og ikke bra. Du bør ikke bruke et "text" felt til "tittel", tittel må du stte opp som en varchar. Innhold kan du sette opp som "text". Dette for at "text" er mye støtte en en varchar kan bli. Du angir ikke hvor stor en text er fordi den er nesten ubegrenset. Den her heller ikke beregnet til å søke i.

[eliminaaator]

hei

 

noen som kan hjelpe med søke script som søker fra ein database og må kunde søke på tittel og innhold

 

Hvilken database er det du bruker MySql etter hva?

 

Bruker MySQL

[TheClown]

Hele koden, samt feilmelding plx

[Jonas]

Du bør ikke bruke et "text" felt til "tittel", tittel må du stte opp som en varchar.

Vennligst utdyp den påstanden.

 

Hvor size er lengden på selve teksten, så vil en text-felt har en størrelse lik 256 + size + (2000 – (size – 256) % 2000 bytes. Med andre ord, overheaden som følger av at man velger text fremover varchar er tilnærmet lik null, med mindre man har seriøs plassmangel. Så, men mindre du har en svært god grunn til å begrense lengde på tittel, så påstår jeg at man ikke skal gjøre det.

 

http://dev.mysql.com/doc/refman/5.0/en/sto...quirements.html

[TheClown]

Jeg har alltid brukt varchar til slike felter. Av vane. Text har jeg kun brukt på ting som jeg veit kan være lengre enn 255. Ingen titler er over 255 uansett.

[Jonas]

Da antar jeg du bruker varchar til brukernavn og email også? Filnavn ved opplastning kanskje til og med? Hva skjer dermed når en tekst faktisk overgår denne fullstendig meningsløse begrensningen og du alltid har antatt at det aldri kom til å skje?

 

Edit: Spørsmål er for øvrig retorisk, jeg er ikke egentlig ute etter å vite hva som da skjer. Man kan trygt si at da går ting skeis.

Endret 29. november 2009 av Jonas

[kbot]

Hei

 

Ser vi på entiteten innhold så er dette en varchar (500) detter er langt over det Mysql støtter, den kan bare være 255. Derfor kan ikke varchar brukse her. Skal databasen fungere må dette endres. En text er standard 1024 tegn men kan som du sier settes til 2000 tegn. Det jeg sier er også et text er et felt som ikke er så godt egnet til søk. Det kan ikke brukes til idex, det er for stort til det. Og må brukes når en skal skrive mer en 255 tegn. Problemet til at han får error, kan altså være dette faktum at han har laget en varchar som er for stor.

Endret 30. november 2009 av kbot

[TheClown]

Da antar jeg du bruker varchar til brukernavn og email også? Filnavn ved opplastning kanskje til og med? Hva skjer dermed når en tekst faktisk overgår denne fullstendig meningsløse begrensningen og du alltid har antatt at det aldri kom til å skje?

 

Edit: Spørsmål er for øvrig retorisk, jeg er ikke egentlig ute etter å vite hva som da skjer. Man kan trygt si at da går ting skeis.

Maxlengde på inputs? Hvis du tenker helt logisk er det INGEN som har mail eller navn på over 255 karakter. Det skjer bare ikke. Trenger ikke å bekymre seg for alt mulig rart, det er heller andre ting man kan fokusere på når man koder

[Jonas]

Si meg, hva annet enn «alt mulig rart» er det bedre å bekymre seg om? Regel nummer 1 innenfor seriøs/semi-seriøs webutvikling er å alltid forvente det unormale, aldri stole på brukere og ikke bare håpe på happy day scenarios. Hva i huleste er liksom argumentet for å begrense slike teite ting? Hvorfor ikke bare bruker text-felter? Det er faktisk da man slipper å bekymre seg over noe, fordi da vil tekst aldri overgå begrensningen.

 

Og hvordan i all verden kan du si at det er logisk at brukernavn/email aldri overgår 255 tegn? Jeg sitter å ser på en brukertabell nå og jeg kom med en gang over i hvert fall et tilfelle der det hadde forekommet. En eller annen gjøk forsøkte å bruke bbkoder for å style sitt eget brukernavn. Vedkommende lyktes i å logge inn og alt, men brukernavnet så rimelig stygt ut. Og flere av filene lastet opp har genererte filnavn som lett overgikk 255 tegn. Så nei, det er langt ifra logisk. Du kan kanskje påstå at det ikke er veldig sannsynlig, men ikke logisk.

Endret 30. november 2009 av Jonas

[Ernie]

Hei

 

Ser vi på entiteten innhold så er dette en varchar (500) detter er langt over det Mysql støtter, den kan bare være 255. Derfor kan ikke varchar brukse her. Skal databasen fungere må dette endres. En text er standard 1024 tegn men kan som du sier settes til 2000 tegn. Det jeg sier er også et text er et felt som ikke er så godt egnet til søk. Det kan ikke brukes til idex, det er for stort til det. Og må brukes når en skal skrive mer en 255 tegn. Problemet til at han får error, kan altså være dette faktum at han har laget en varchar som er for stor.

Langt over hva MySQL støtter? Forsåvidt rett hvis man kjører 4.x eller eldre, men i MySQL 5.0 og seinere kan lengden være større enn 255 tegn (eller mer korrekt bytes), faktisk opptil 65.535 bytes (antall tegn er avhengig av tegnsett og ev. enkoding). Dog, radstørrelsen kan ikke være over 65.535 bytes, så varchar blir begrenset straks du har andre kolonner i tabellen.

 

For det andre er Text ikke standard 1024 tegn, men 65.535 bytes (igjen, antall tegn er avhengig av tegnsett osv.). Text teller ikke direkte inn på radstørrelsen.

 

Jonas: Brukernavn og epost over 255 tegn er i bestefall sjeldent. Dette er 255 tegn:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Jeg tror jeg trygt kan påstå at ingen gidder å seriøst registrere seg med et så langt brukernavn som de faktisk har tenkt å bruke.

 

Forøvrig kan epost-adresser være maks 320 tegn. 64 tegn med lokal del (delen foran @) og 255 tegn med domene. Mao. en begrensning på 255 tegn på epost-adresser er uproblematisk. For å bryte grensen trenger man et domene på over 191 tegn. Det er så langt:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaa

Jeg tror det er trygt å anta at svært, svært, svært få har et domene som er så langt. Nevnte jeg forresten at lengste domene du kan registere er 63 tegn (+tld)? For å bryte grensen på 255 tegn må man da ha et subdomene på over 128 tegn (- lengden av tld). Det er så langt:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Dvs. det subdomenet må faktisk brytes opp i 3 deler, for subdomenene er også begrenset til 63 tegn. Altså, det du forsøker å si er at det er sannsynlig at noen ønsker å legge til et tegn til i subsubdomenet i denne adressen eller legge til flere nivåer i domenet:

dette.er.en.laaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaang.epost-adresse@laaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaangt-subsubdomene.laaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaangt-subdomene.laaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaangt-domene.com

Endret 30. november 2009 av Ernie

[TheClown]

Takk, Ernie. Poenget er at man ikke skal gjøre databasen tilgjengelig for å lagre slik informasjon, men skal heller nekte brukeren i å sende det. Dersom et input-felt har 255 som limit FÅR ikke brukeren skrevet inn et brukernavn lengre enn de 255 karakterene. Mail over 255 tror jeg Ernie har dekket allerede. Selvfølgelig er det noe annet når det kommer til filnavn osv, men også her kan og burde man endre filnavnet til noe enklere enn noe superlangt.

 

Kom med et brukernavn som er på over 255 karakterer på et forum, eller liknende, så skal jeg si meg enig. Men jeg kan til dags dato si at jeg ALDRI har sett det. Enkelt og greit fordi 255 karakterer er jævla mye.

[Jonas]

Dersom et input-felt har 255 som limit FÅR ikke brukeren skrevet inn et brukernavn lengre enn de 255 karakterene.

En klientsidebegrensning på lengde av input er ikke nok hvis det er det du tror. Her er vi igjen inne på å stole på brukere. Det er superlett å forge et POST-request som poster et brukernavn bestående av en million tegn, uavhengig av hva slags size-attribute du har satt på input-feltene dine.

 

Selvfølgelig er det noe annet når det kommer til filnavn osv, men også her kan og burde man endre filnavnet til noe enklere enn noe superlangt.

Dersom man f.eks. laster opp et bilde, hvor ingen brukere utsettes for filnavnet, hvorfor burde man da endre på det?

 

Kom med et brukernavn som er på over 255 karakterer på et forum, eller liknende, så skal jeg si meg enig.

[size="7"][color="red"]3[/color][/size][size="1"][color="green"]x[/color][/size][size="5"][color="blue"]p[/color][/size][size="3"][color="grey"]3[/color][/size][size="6"][color="purple"]r[/color][/size][size="3"][color="black"]1[/color][/size][size="6"][color="brown"]3[/color][/size][size="5"][color="red"]n[/color][/size][size="3"][color="yellow"]c[/color][/size][size="4"][color="blue"]3[/color][/size]

Jupp, det stemmer. 405 tegn. Er vi enige, da?

 

For the record, så trodde vel stakkaren at det kom til å se ut som noe lignende.

 

3xp3r13nc3

 

Slik formatering skal man ikke nødvendigvis se alt for langt bort ifra at noen kanskje vil ha i en blogtittel, signatur eller lignende, og da er det noe herk dersom utvikleren tenkte «Det skjer sikkert ikke...».

 

Poenget mitt bygger rett og slett på når i prosessen man skal fikse på brukerdata. Ved input (inntasting) eller output (visning av den). Svaret er egentlig definitivt ved output og grunnen er enkel: Dersom en bruker med htmlentities i navnet sitt skal f.eks. logge inn, så må vedkommende skrive >aiwja, med mindre du escaper det ved sammenlikning også, men det vil isåfall være utrolig mer unødvendig enn det trenger å være.

 

IPB som driver dette forumet er jo på en måte et prakteksemplar på hvordan det ikke skal gjøres. Så vidt jeg vet, så er brukernavnene lagret som varchar(255), men dette sjekkes ikke ved registrering, så brukernavnet kortes ned uten at det blir gitt noen feedback. Når man så skal logge inn, så er for det første brukernavnet kortet ned til 255 tegn uten at man vet om det, i tillegg så er det faktisk ved logg-inn lagt til lengdebegrensning, som gjør at man ikke kan taste inn 255 tegn likevel.

 

Og til slutt; dersom dere er så innmari skråsikre på at ingen noen sinne vil taste inn et brukernavn lengre enn 255 tegn, hvor i huleste velger dere da å begrense det til akkurat det? En begrensning er bare meningsfull dersom den faktisk har noe å begrense.

Endret 30. november 2009 av Jonas