Új hozzászólás Aktív témák
-
#15481
trisztan94
őstag
csabyka666
#15473
trisztan94
őstag
válasz
csabyka666
#15473
üzenetére
-
#15480
DNReNTi
őstag
csabyka666
#15479
DNReNTi
őstag
válasz
csabyka666
#15479
üzenetére
Az dicséretes hogy küzdesz mint disznó a jégen, no meg mindenki kezdte valahogy, de ez nem elfogadható hozzáállás: "elsődleges cél, hogy működjön a projekt, még ha tákolással is". Pont néhány napja írtam: attól mert valami működik még nem biztos hogy jó. 5 perc alatt írok neked egy bejelentkezős form-ot, ami működik, és kell még 5 óra, hogy jó is legyen. Ha ezzel akarsz foglalkozni, mármint komolyan, mondjuk pénzt szeretnél keresni azzal hogy webalkalmazásokat készítesz, akkor ezt az "elsődleges célt" gyorsan felejtsd el.
Én úgy látom - ismét, no offense - hogy sokszor nálad alapjaiban szétcsúsznak a dolgok, úgy gondolom ennek elsősorban a kapkodás, netről összeollózás, és főleg a mindegymáncsakműködjön hozzáállás az oka. Gyakran tök alap problémákat önmagad sz*patása céljából nagyítasz fel, és ész nélkül próbálsz megoldást találni a problémára, aminek a vége: még több probléma, lásd: sütikben mysql_real_escape_string().
Attól mert nem 10 éve foglalkozol ezzel, még senki nem fog hülyének nézni, vagy leköpni mert felteszel egy kérdést, de érthető a felháborodás, mikor már a sokadik kérdés-válasz után nem fogadod el a segítséget, és ahelyett, hogy a javasolt jó úton próbálnád megoldani a feladatot, elvárod, hogy inkább rossz/hibás/elavult kód megírásában segítsenek neked.
Jó hasznát pedig akkor veszed a topiknak ha megfogadod a tanácsokat.
Ismét: no offense. -
#15477
Sk8erPeter
nagyúr
csabyka666
#15470
Sk8erPeter
nagyúr
válasz
csabyka666
#15470
üzenetére
Milyen jó lett volna, ha megfogadod a tanácsunkat, és PDO-t használsz exception-kezeléssel.
(#15473) csabyka666 :
Könyörgöm, fejezd már be ezt a mentalitást! Bocs, de minek jössz ide kérdezgetni, ha tákolni akarsz, és ragaszkodsz a saját elképzeléseidhez? Azért nem érdemes használni a mail()-t, mert egyszerűen túl sok a problémalehetőség, formázási problémák vannak vele, olyan gondjaid fognak előfordulni, amit épp a javasolt SwiftMailerben vagy a PHPMailerben már régesrégen megoldottak. Korrekt kimenetet kaphatnál, és fordíthatnád az idődet HASZNOS tevékenységekre, HASZNOS önfejlesztésre, ahelyett, hogy ilyen baromságokkal szopatnád magadat.
Megint én vagyok a beszólogatós köcsög, de vállalom, valakinek meg kell mondania időben, hogy hülyeséget csinálsz.
(#15476) Soak :
Notórius önszopató, mondhatjuk neki mi a magunkét, egyszerűen szarik rá, "jó lesz az"-alapon. Mindjárt jön a hosszú kifejtése annak, hogy "de hát én így meg úgy, ti meg úgy meg amúgy", szóval fűrészelhetjük majd vele a fingot keményen megint, ahelyett, hogy valami érdemi dologról lenne szó végre ebben a topicban.
-
#15476
Soak
veterán
csabyka666
#15473
Soak
veterán
válasz
csabyka666
#15473
üzenetére
Persze, vegulis minek hallgatnal azokra akik mar vegig szoptak ugyanugy ahogy te.
-
#15475
DNReNTi
őstag
csabyka666
#15471
DNReNTi
őstag
válasz
csabyka666
#15471
üzenetére
Mivel charset=utf-8 van a tartalomban és charset=iso-8859-1 a headerben. Nem is csoda hogy nem jól jelenik meg.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
moltam88
tag
válasz
csabyka666
#15471
üzenetére
Nem használtam még mail() -t, de nem lehetm, hogy mindkét helyen utf-8 kódolást kellene megadnod? ($headers-ben iso-8859-1 -et írtál)
-
#15472
trisztan94
őstag
csabyka666
#15471
trisztan94
őstag
válasz
csabyka666
#15471
üzenetére
-
#15468
DNReNTi
őstag
csabyka666
#15466
DNReNTi
őstag
válasz
csabyka666
#15466
üzenetére
Több észrevétel:
1. Hibakereséshez, írasd ki a generált sql lekérdezést, és ellenőrizd! Valszeg azért nem fut le, mert hibás lekérdezés generálódik.
2. A törléshez semmiképp sem használnék get változókat. Ügyesebb megoldás lenne a session használata, DE!!! még akkor is mindenképp ellenőrizned KELL, hogy adott elem törléséhez van e jogosultsága a felhasználónak. Ha az ellenőrzés kimarad és ráadásul url-ben átadott paraméterekkel dolgozol, annak az az eredménye, hogy minimális hozzáértéssel törölhető minden kosár tartalma. -
#15465
DNReNTi
őstag
csabyka666
#15463
DNReNTi
őstag
válasz
csabyka666
#15463
üzenetére
No offense, de én itt már egy alapjaiban rossz koncepciót látok.
Ha egy termék vonalkódja módosul, egyáltalán miért sütibe kerül? Miért nem az adatbázisba egyből? Közben felmerült, hogy mi van ha később adatbázisba mented? Ismét megkérdezem: miért nem egyből? Nem látom a dolog egészét, de most ha végiggondoljuk, nem célszerűbb lenne e egyből elmenteni?
Teszem azt, megváltoztatom egy termék vonalkódját, majd törlöm a sütiket. Akkor mi van?
A legfontosabb kérdés:
Mi a cél? -
#15464
fordfairlane
veterán
csabyka666
#15463
fordfairlane
veterán
válasz
csabyka666
#15463
üzenetére
Légyszi ne rakd offba a hszeket, csak ha nem PHP témájú. A cookie állítgatás lehetőleg mindenféle kiíratást, html kódot előzzön meg. Az ob_start ugyan segíthet, de jobb, ha arra sincs szükség.
-
#15462
Speeedfire
félisten
csabyka666
#15460
Speeedfire
félisten
válasz
csabyka666
#15460
üzenetére
Inkább addslashes.
-
#15461
fordfairlane
veterán
csabyka666
#15460
fordfairlane
veterán
válasz
csabyka666
#15460
üzenetére
A mysql escape-t mysql műveleteknél kell használni.
-
#15459
DNReNTi
őstag
csabyka666
#15458
DNReNTi
őstag
válasz
csabyka666
#15458
üzenetére
A kérdés szerintem arra irányul hogy minek mysql_real_escape_string() mikor nem adatbázisba mentesz?
-
#15457
Sk8erPeter
nagyúr
csabyka666
#15456
Sk8erPeter
nagyúr
válasz
csabyka666
#15456
üzenetére
A cookie beállításához miért használsz mysql_real_escape_string()-et?
-
#15456
csabyka666
veterán
csabyka666
#15455
válasz
csabyka666
#15455
üzenetére
ob_start(); részben megoldotta a problémát, de még mindig van pár eset, amikor nem készül el a cookie.
-
#15454
Sk8erPeter
nagyúr
csabyka666
#15453
Sk8erPeter
nagyúr
válasz
csabyka666
#15453
üzenetére
Pont azért lenne érdemes időben átállnod a manapság is jól használható eszközökre, mert minél tovább húzod a dolgot, annál nehezebb lesz később átírni a projektet. Csak rá kell érezned, és nem lesz akkora katasztrófa átírni a mostani, kerülendő mysql_*-es megoldást.
Természetesen próbálgasd előbb localhoston, egy tök másik projekten, hogy hogy is működik a dolog, és meg fogod szokni. -
#15452
fordfairlane
veterán
csabyka666
#15449
fordfairlane
veterán
válasz
csabyka666
#15449
üzenetére
Injection ellen vagy escapeled a bejövő paramétereket, vagy prepared statementet használsz. Utóbbira a mysqli vagy a pdo interfész ad eszközöket. Ne használd a mysql_* kezdetű függvényeket. 2011 óta "deprecated" státuszúak, és valószínűleg ki lesznek szedve a PHP.ból a jövőben.
-
#15451
DNReNTi
őstag
csabyka666
#15449
DNReNTi
őstag
válasz
csabyka666
#15449
üzenetére
Vagy használj mysqli-t ha a PDO túl idegen elsőre.
Itt egy rövid leírás alap példákkal (englishül). -
#15450
Sk8erPeter
nagyúr
csabyka666
#15449
Sk8erPeter
nagyúr
válasz
csabyka666
#15449
üzenetére
Még mindig (addig fogod kapni ezt a választ, amíg nem váltasz a mysql_ kezdetű függvényekről): használj PDO-t prepared statementekkel, és akkor elkerülöd az ilyen szerencsétlenkedéseket.
-
#15443
Sk8erPeter
nagyúr
csabyka666
#15440
Sk8erPeter
nagyúr
válasz
csabyka666
#15440
üzenetére
"Itt kaptam egy tanácsot a PH-n, hogy írjam oda minden adatbázis-kapcsolódás után, hogy:
mysql_query("SET NAMES SET 'utf8'");
mysql_query("SET CHARACTER SET 'utf8'");
"
Ilyen tanácsot sztem nem adtunk.
A mysql_* kezdetű függvényeket már nem használjuk, deprecated ahogy ezerszer ki lett tárgyalva a topicban.
Ilyesmi inkább elképzelhető:$db = new PDO(
"mysql:host=localhost;dbname=test",
"root",
"root",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
); -
TomyLeeBoy
tag
válasz
csabyka666
#15440
üzenetére
Sehogy sem tudok olyat elérni hogy mindkettő jó legyen. Azt csináltam amit tanácsoltál, így az adatbázisból olvasott adatok helyesen jelennek meg, viszont az összes többi nem... Azokkal a direktbe beírt karakterekkel mit tudok csinálni?!Úgy néz ki meg lett a megoldás. Adatbázis lekérés a javaslatod alapján, illetve az összes fájlom kódolásának átállítása ANSI-ról UTF8-ra. Köszönöm a segit!
-
#15425
fordfairlane
veterán
csabyka666
#15424
fordfairlane
veterán
válasz
csabyka666
#15424
üzenetére
Nincsenek rejtett dolgok. Felépítesz egy adatbázis kapcsolatot, az addig él, amíg a PHP fut az adott végrehajtási szálon, akárhány fájlból is tevődik össze. Amint véget ér a futás, a kapcsolat lezárul magától.
-
#15422
fordfairlane
veterán
csabyka666
#15421
fordfairlane
veterán
válasz
csabyka666
#15421
üzenetére
Jó, de ha egyszer te tudod, hogy melyik fájlod milyen sorrendben hívódik meg, akkor még milyen plusz infó kell? Én adtam egy olyan megoldást, ami sorrend-független, minden másra ott a közös programfájl, ami mindig végrehajtódik. Azt behúzod az összes php fájlod elejére. Ha az index.php csinál mindent, akkor annak az elejébe teszed.
-
#15420
fordfairlane
veterán
csabyka666
#15419
fordfairlane
veterán
válasz
csabyka666
#15419
üzenetére
Ez az előnye a "kreátor" objektumnak. Csak meghívod a megfelelő metódusát, az pedig visszaad neked egy adatbáziskapcsolati objektumot. Az objektum életciklusával nem kell foglalkoznod. Sem azzal, hogy mikor hívod meg, hányszor hívod meg, hol hívod meg, hogy az index.php jön először, vagy azután, vagy soha.
Egyszer létrehozza, és utána már ugyanazt adja vissza az összes olyan programrésznek, amelyiknek adatbázis műveleteket kell végrehajtania.
-
#15418
mallee
tag
csabyka666
#15417
mallee
tag
válasz
csabyka666
#15417
üzenetére
Érzésem szerint az index.php minden újratöltéskor lefut.
Ha mindig lefut, akkor elég ennek az egy fájlnak a tetején létrehozni a kapcsolatot.
-
#15414
DNReNTi
őstag
csabyka666
#15413
DNReNTi
őstag
válasz
csabyka666
#15413
üzenetére
Felre ertetted az inicializalos mondanivalom.
Egy adatbazissal is hasznos egy init fajlba osszegyujteni a behuzando dolgokat. Fuggvenyek, adatbazis kezeles stb. De hogy valaszt adjak konkret kerdesre: eleg egyszer a file elejen adatbazis kapcsolatot nyitni. -
#15408
fordfairlane
veterán
csabyka666
#15404
fordfairlane
veterán
válasz
csabyka666
#15404
üzenetére
Működik, csak nehezen módosítható, nehezen karbantartható (nem tesztelhető automatikus testscriptekkel, nem testreszabható attól függően, hogy fejlesztői vagy éles környezetben fut stb, stb...). Ezért vannak ezek a technikák, amikkel nem csak működni fog a rendszered, de modulárisabb, ezáltal kezelhetőbb is lesz.
-
#15407
DNReNTi
őstag
csabyka666
#15404
DNReNTi
őstag
válasz
csabyka666
#15404
üzenetére
Erre mondaná a volt programozás tanárom az egyetemen: működik de nem jó.
Ez egyben az is jelentette hogy meg vagy bukva, csak viccesen szeretett fogalmazni. A lényeg: amit csináltál valóban működik DE:
1. A mysql_ parancsok nyugdíjazva vannak, tehát várhatóan ki is fognak kerülni a frissebb php verziókból, ami azt jelenti, hogy ez belátható időn belül nem fog működni.
2. fordfairlane is írta, hogy az, hogy minden file elején inicializáló parancsokat raksz be nem jó. Persze működik, de önmagad szívatod vele. Ugyan az mint amit css-re írtam, egyszerűbb ha ezek egy helyen vannak és később nem 500 helyen kell módosítani. Minden inicializációval kapcsolatos include és parancs mehet egy init.php-ba, és csak az egyet include-olod.
3. Kapcsolódik az elsőhöz, kezdj el ismerkedni az OOP-vel, elsőre bár bonyolultnak tűnik, de egy mysqli vagy PDO osztály használata meghálálja magát. -
#15400
fordfairlane
veterán
csabyka666
#15399
fordfairlane
veterán
válasz
csabyka666
#15399
üzenetére
Egyrészt mysql-* kezdetű függvényeket nem használunk, ott van a PDO.
Másrészt ne ez legyen a scriptjeid elején. Mi van, ha megváltozik az inicializálás, minden oldalon egyesével átírod? Csinálj mondjuk egy bootstrap.php fájlt, és abba tedd bele azokat a programrészeket, amiket minden script lefutásánál használni akarsz. A scriptjeid elején így csak a bootstrap.php-t kell behúznod.
Harmadrészt meg lehetőleg használj osztálybetöltőt, hogy többet ne kelljen foglalkoznod fájlok include-olásával, de ez már haladó szint.
-
#15397
fordfairlane
veterán
csabyka666
#15395
fordfairlane
veterán
válasz
csabyka666
#15395
üzenetére
Bőven elég egyszer az elején megnyitni, a script lefutásakor a kapcsolat úgyis lezáródik magától. Nagyon nem ajánlott minden query előtt új kapcsolatot létrehozni, sőt, kifejezetten hibákat is tud produkálni.
-
#15396
PumpkinSeed
addikt
csabyka666
#15395
PumpkinSeed
addikt
válasz
csabyka666
#15395
üzenetére
Attól függ szerintem, bár lehet biztonságosabb ha minden query előtt meghívod azután pedig lezárod, hogy ne legyen folyamatosan nyitva.
-
#15388
Sk8erPeter
nagyúr
csabyka666
#15386
Sk8erPeter
nagyúr
válasz
csabyka666
#15386
üzenetére
Ja, hogy így! Valóban, az jogos.
(#15387) DNReNTi :
Azért olyan jellegű kérdéseket nem láttam tőled, mint amilyeneket ez a blog kifiguráz. Egyébként meg meglehetősen érdekes felfogás, hogy akkor van _létjogosultsága_ ezeknek a SZAKMAI (!!!4444NÉGYNÉGYNÉGY) topicoknak, ha tele van olyan kérdésekkel, amikről messzire bűzlik, hogy a kérdező még csak meg sem próbált energiát beleölni, utánanézni, tanulni. Mindenki kérdezhet hülyeségeket, ha még csak most kezdte, de azért nem mindegy, hogy az jön le, hogy az illető alapból félhülye, vagy simán lusta, és szarik bele, vagy látszik, hogy valamit erőlködött, de nem jött össze, meg is osztja, mire jutott, és a továbbhaladásban kéri a segítséget. Nyilván az utóbbi a jó/jobb eset.
Érted te ezt. -
#15383
wis
tag
csabyka666
#15382
wis
tag
válasz
csabyka666
#15382
üzenetére
mb_* függvények használata előtt használd ezt:
mb_internal_encoding('UTF-8');
-
#15381
DeltaPower
addikt
csabyka666
#15378
DeltaPower
addikt
válasz
csabyka666
#15378
üzenetére
fordfairlane jól írta, nem kell ezt jobban bonyolítani:
$str = mb_substr($str,0,10)."*"; -
#15379
fordfairlane
veterán
csabyka666
#15378
fordfairlane
veterán
válasz
csabyka666
#15378
üzenetére
Ha a fv. kimenetét ugyanabba a változóba rakod, miért ne? De ha ragaszkodsz az str_replace-hez, bizonyára annak is van mb_ (mb -> multibyte, azaz unicode stringekhez való) változata.
-
#15377
fordfairlane
veterán
csabyka666
#15375
fordfairlane
veterán
válasz
csabyka666
#15375
üzenetére
Így konvertálni sem kell.
-
#15376
csabyka666
veterán
csabyka666
#15375
válasz
csabyka666
#15375
üzenetére
No, egyelőre úgy néz ki, sikerül ezzel:
function utf8_substr_replace($str, $repl, $start , $length = NULL ) {
preg_match_all('/./us', $str, $ar);
preg_match_all('/./us', $repl, $rar);
if( $length === NULL ) {
$length = strlen(utf8_decode($str));
}
array_splice( $ar[0], $start, $length, $rar[0] );
return join('',$ar[0]);
}
-
#15367
Sk8erPeter
nagyúr
csabyka666
#15366
Sk8erPeter
nagyúr
válasz
csabyka666
#15366
üzenetére
$testString = 'valami blabla';
if(preg_match('/.*? .*?/i', $testString) {
echo 'A stringben van egymás után 2 vagy több szóköz.';
}Tesztelheted:
http://www.functions-online.com/preg_match.html -
#15284
fordfairlane
veterán
csabyka666
#15283
fordfairlane
veterán
válasz
csabyka666
#15283
üzenetére
Nem tudom, mennyi adatról van szó, de megelőlegezem, teljesen fölösleges hülyeségen folyik a rugózás.
-
#15282
fordfairlane
veterán
csabyka666
#15280
fordfairlane
veterán
válasz
csabyka666
#15280
üzenetére
Egzakt precizitásra a decimal való (tipikusan "monetary" értékre lett kitalálva), de ha a vonalkódszámokkal nem végzel matematikai műveleteket, akkor a varchar is jó. Integert nem ajánlom ilyen esetekre, úgy is stringként kell használnod alkalmazásszinten, hogy meglegyen a 13 karakter hossz.
-
#15281
Phvhun
őstag
csabyka666
#15280
Phvhun
őstag
válasz
csabyka666
#15280
üzenetére
Ezt elég lett volna csak logikusan átgondolnod.
13db számot ha tárolsz, akkor az 10 féle dolog mehet a 13 helyre.
Namost varcharként ez 13 karakter, amiből meg sokkal több féle van pl összes betü stb..., és a számokat alapból több biten tárolja le mivel lehet hogy unicode karakterként van a kezelésük beállítva.
Az meg több helyet foglal.Szoval számként tárold.
-
#15279
fordfairlane
veterán
csabyka666
#15276
fordfairlane
veterán
válasz
csabyka666
#15276
üzenetére
decimal(13) unsigned zerofill
-
#15277
CSorBA
őstag
csabyka666
#15276
CSorBA
őstag
válasz
csabyka666
#15276
üzenetére
Ez SQL topikos kérdés lenne, válasz: [link]
-
#15189
csabyka666
veterán
csabyka666
#15188
válasz
csabyka666
#15188
üzenetére
No, azt hiszem, megtaláltam.
-
#15184
fordfairlane
veterán
csabyka666
#15182
fordfairlane
veterán
válasz
csabyka666
#15182
üzenetére
Inkább így:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
A "charset" a content része.
-
#15183
DNReNTi
őstag
csabyka666
#15182
DNReNTi
őstag
válasz
csabyka666
#15182
üzenetére
Mivel a doctype html 4.01 igy mindenkepp igy a jo.
-
#15173
DNReNTi
őstag
csabyka666
#15171
DNReNTi
őstag
válasz
csabyka666
#15171
üzenetére
Csak tippként: bármikor amikor új projekthez kezdesz, az elsők között legyen a helyes karakterkódolás és adatbáziskapcsolat kialakítása. Ha ezzel nem foglalkozol és később ilyen gondokba ütközöl, mint most is, akkor csak önmagadat szivatod.
(#15172) trisztan94
Hát a céges intranetekről a végtelenig lehetne beszélgetni Szerintem mindenkinek volt már egy-két álmatlan éjszakája ezek miatt. Csak hogy én is megosszak egyet: Egy (inkább meg sem nevezem) multinál kiderült hogy az egyik gépen nem tudják használni az általam intranetre készített programot. A gép egy 90-es évekből visszamaradt Windows 3.1-et futtató csoda. Asszem IE3 volt hozzá. És nem ment... És nem értették miért. -
#15170
DNReNTi
őstag
csabyka666
#15169
DNReNTi
őstag
válasz
csabyka666
#15169
üzenetére
Angol nem árt hozzá: fő különbségek.
Egyébként a tiéd a doctype alapján : HTML 4.01.De ennek az off sorozatnak inkább itt a helye.
-
#15168
DNReNTi
őstag
csabyka666
#15167
DNReNTi
őstag
válasz
csabyka666
#15167
üzenetére
De jó, ha HTML 4-et használsz. Amit én írtam az HTML 5. Többnyire szerintem már ezt használjuk.
-
#15166
DNReNTi
őstag
csabyka666
#15165
DNReNTi
őstag
válasz
csabyka666
#15165
üzenetére
A <head>-ben ez szerepel <meta charset="utf-8"> ?
Most meg lehet az a baj hogy már az adatbázis és az adatbáziskapcsolat rendben van, de a dokumentum karakterkódolása nem utf-8Ja, és természetesen meg lehet változtatni a mezők illesztését is. Vagy kattintgatva a Szerkezet/Structure fülön, vagy az ALTER TABLE paranccsal.
-
#15162
don_peter
senior tag
csabyka666
#15159
don_peter
senior tag
válasz
csabyka666
#15159
üzenetére
Én is használom ezt a programot.
Nekem az adatbázisban a karakterkészlet: "latin2_hungarian_ci"-ra van állítva.
Index header:
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-2" />
Nekem jól működik így. -
#15161
DNReNTi
őstag
csabyka666
#15159
DNReNTi
őstag
válasz
csabyka666
#15159
üzenetére
Az adatbázis kapcsolat megnyitása után érdemes futtatni:
Hagyományos mysql_ fügvényekkel:
mysql_query("SET NAMES SET 'utf8');
mysql_query("SET CHARACTER SET 'utf8');mysqli osztállyal:
$DB_peldany->set_charset('utf8');Ezután már jónak kell lennie.
UPDATE:
Ja meg "utf8_hungarian_ci" helyett mindenhol inkább "utf8_general_ci"-t használj, így legyen beállítva az adatbázis és a táblák alapértelmezett kódolása is. Ha minden UTF8 akkor nem szokik gond lenni.
-
#15156
biker
nagyúr
csabyka666
#15153
biker
nagyúr
válasz
csabyka666
#15153
üzenetére
nem, le is írtam, mi a különbség
-
#15149
biker
nagyúr
csabyka666
#15142
biker
nagyúr
válasz
csabyka666
#15142
üzenetére
neked a MATCH AGAINST páros kell, nem a LIKE különböző variánsai, szerintem...
És ez rendezhető relevancia(score) szerint -
#15148
DNReNTi
őstag
csabyka666
#15145
DNReNTi
őstag
válasz
csabyka666
#15145
üzenetére
Az egész az SQL lekérdezéseden fog múlni.
Arra hogy ez jó legyen kettő módszer van, ezeket most két kereső szóval mutatom meg, legyen pl: "Elment a görög aludni" a keresett content mező tartalma.
Keresőkifejezés: "aludni mentem"
Ebből ugye csak az "aludni" illeszkedik.1. A lassabb és bonyolultabb:
SELECT * FROM table WHERE content LIKE '%aludni%' OR content LIKE '%mentem%';2. A szebb és gyorsabb:
SELECT * FROM table WHERE content REGEXP 'aludni|mentem';Mind a két lekérdezés hozni fogja az "Elment a görög aludni" rekordot, továbbá minden egyes másik rekordot, amiben az "aludni" vagy a "mentem" vagy ezek töredéke szerepel.
PHP-ban szerintem az utóbbit a legegyszerűbb implementálni.
str_replace függvénnyel a szóközöket | jelre cseréled és már mehet is a lekérdezésbe.
Done. -
#15144
Speeedfire
félisten
csabyka666
#15140
Speeedfire
félisten
válasz
csabyka666
#15140
üzenetére
Nem biztos, hogy a legjobb megoldás, de én így indulnék neki.
$criteria = 'ezt akarom keresni';
$where = '(';
$c = explode(' ', $criteria);
for($i=0; $i<count($c); $i++) {
if($i > 0) $where .= ' or ';
$where .= ' first_name like "%'.$c[$i].'%"';
}
$where .= ')';
$where .= ' and 1=1'; //ide még jöhet más
$sqlStatement = 'select * from employees where ' . $where; -
#15143
#68216320
törölt tag
csabyka666
#15142
#68216320
törölt tag
válasz
csabyka666
#15142
üzenetére
Tobb like vagy kapcsolattal?
-
#15141
#68216320
törölt tag
csabyka666
#15140
#68216320
törölt tag
válasz
csabyka666
#15140
üzenetére
Mysql LIKE? Ez jo lehet.
-
#15055
Peter Kiss
őstag
csabyka666
#15053
Peter Kiss
őstag
válasz
csabyka666
#15053
üzenetére
Mi magas a jelenlegi context-ben a json-ban? Setcookie előtt kell egy json_encode, használat előtt meg egy json_decode, ha fogalmad sincs arról, mi a json, akkor sem kell pánikolni miatta.
-
#15051
Peter Kiss
őstag
csabyka666
#15050
Peter Kiss
őstag
válasz
csabyka666
#15050
üzenetére
http://php.net/manual/en/function.setcookie.php example #3, másik lehetőség, hogy egy kulcsot használsz, és kézzel serialize-lod a tömbödet json_encode()-dal, majd json_decode()-al vissza.
-
#15041
#68216320
törölt tag
csabyka666
#15038
#68216320
törölt tag
válasz
csabyka666
#15038
üzenetére
Én csak nagyon amatőr vagyok, de az alábbi megoldást használnám:
account.php - a belépéshez és tartalom megjelenítéshez. bár én magam a tényleges belépést is egy login.php-ban intézném el.
logout.php - a kilépéshezErről jut eszembe, a session_destroy() csak kinyírja a session-t és megmaradnak még a $_SESSION globális tartalmak vagy törli is azokat? Mert esetleg felesleges a logout.php-ban külön foglalkozni velük.
-
#15040
biker
nagyúr
csabyka666
#15038
biker
nagyúr
válasz
csabyka666
#15038
üzenetére
teljesen rossz a kód, az if ágban rosszul vannak egymásba ágyazva a dolgok
<?php
session_start();
if(isset($_POST["belep"])){
$_SESSION["belepve"] = 1;
$_SESSION["username"] = $_POST["username"];
}
if(!isset($_SESSION["belepve"]))
{
echo "Az oldal megtekintéséhez be kell jelentkezned!";
echo '
<form method="post">
Felhasználói név: <input type="text" name=username /></br>
<input type="submit" name="belep" value="Belépés" />
</form>';
}
else{
echo "Üdvözöllek ".$_SESSION["username"];
echo "Az oldal tartalma: blablabla...";
//itt nem volt lezárva az else ág!
}
?> -
#15039
#68216320
törölt tag
csabyka666
#15038
#68216320
törölt tag
válasz
csabyka666
#15038
üzenetére
...
-
#14962
Sk8erPeter
nagyúr
csabyka666
#14955
Sk8erPeter
nagyúr
válasz
csabyka666
#14955
üzenetére
$sql = "SELECT * FROM tabla WHERE id=$value"; //ez így persze nem fut le, de a lényeget értitek...
hogyan lehetséges az, hogy a mai napig látni összefűzött query-ket (NAGY HIBA!!), amik a potenciális veszélyforrásokat szépen magukba foglalják? Úgy értem, régen sokkal inkább tele volt a net akkora szar tutorialokkal, amikből az ember kezdőként sem győzött kukázni, szelektálni, hogy na most melyikben bízzak - de ma már van Google által nagyon jól indexelt Stack Overflow, ahol szerencsére legtöbbször a fejére koppintanak annak, aki ilyen csúfságokat akar elkövetni, meg van számtalan tutorial, ahol elsők között hívják fel a figyelmet arra, hogy sose bízz a felhasználótól érkező vagy általa bármilyen módon módosítható inputban, amikor adatbázis-lekéréssel foglalkozol.
Nézz utána az SQL Injection fogalmának, aztán pedig a PDO-nak és a prepared statementeknek. Így nem kell tartanod SQL Injectiontől.
Normális esetben ez valahogy így nézne ki csatlakozás után:// csatlakozás
$db = new PDO(
'mysql:host=localhost;dbname=test_db', // test_db-t módosítsd a megfelelő adatbázisnévre
'root', // módosítsd
'1234', // módosítsd
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;', // egyből UTF-8-ra fogja állítani kapcsolódás után a karakterkódolást
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // kivételeket fog dobálni probléma esetén
)
);
$query = 'SELECT ez, az, amaz FROM tabla WHERE id=:id'; // inkább sorold fel a valóban szükséges mezőket, ne mindig a *-ot használd!!
$stmt = $db->prepare ( $query );
$stmt->bindValue( ":id", $value, PDO::PARAM_INT );
$stmt->execute();
foreach ($stmt as $row) {
echo 'ez: '.$row['ez'].', az: '.$row['az'].', amaz: '. $row['ez'];
}Itt láthatsz még bőven példát PDO használatára:
http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers#Executing_prepared_statements_in_a_loopItt bindParam()-ot használ:
$values = array('bob', 'alice', 'lisa', 'john');
$name = '';
$stmt = $db->prepare("INSERT INTO table(`name`) VALUES(:name)");
$stmt->bindParam(':name', $name, PDO::PARAM_STR);
foreach($values as $name) {
$stmt->execute();
}Itt egy példa tranzakciók használatára:
try {
$db->beginTransaction(); // note that calling beginTransaction() turns off auto commit automatically
$db->exec("SOME QUERY");
$stmt = $db->prepare("SOME OTHER QUERY?");
$stmt->execute(array($value));
$stmt = $db->prepare("YET ANOTHER QUERY??");
$stmt->execute(array($value2, $value3));
$db->commit();
} catch(PDOException $ex) {
//Something went wrong rollback!
$db->rollBack();
echo $ex->getMessage();
} -
#14958
trisztan94
őstag
csabyka666
#14957
trisztan94
őstag
válasz
csabyka666
#14957
üzenetére
Akkor félreértettem.
Tehát nem az a baj, hogy nem fut le az SQL fetch minden id-re?
Azt írtad, hogy a $value értéke az jó a foreach-ben, mert kiírva rendesen írta ki. Akkor itt az egyedüli dolog ami kell az, ohgy a foreach cikluson belül minden egyes ciklusba lépéskor fetch-eled.
Nem tudsz kódot mutatni? Így elég nehéz a sötét szénakazalban megtalálni azt az egy szénaszálat, ami neked kell.
-
#14956
trisztan94
őstag
csabyka666
#14955
trisztan94
őstag
válasz
csabyka666
#14955
üzenetére
Berakod a PDO (vagy MySQLi) query-t futtató kódot a foreach-be.
-
#14791
fordfairlane
veterán
csabyka666
#14789
fordfairlane
veterán
válasz
csabyka666
#14789
üzenetére
Mivel a feltöltés külön entitás, ezért a feltöltés ideje a feltöltéshez kapcsolódik. Tehát a feltöltés ideje a kapcsolótáblába kerül.
További kérdés, hogy a MySQL-lel hogy tudom megértetni ezeket a táblákat? Konkrétan a kapcsolótáblára gondolok, hogy azt miként állítom be, hogy 2 kulcsból jön az elsődleges kulcs, ami csak a kapcsolótáblában elsődleges, mert amúgy idegen kulcs...plusz ugye ott van a feltöltés ideje is.
Most nincs sok időm részletesen elmagyarázni, érdemes utána nézni a neten a "mysql set foreign key constraints" szavakkal, hogy hogyan kell foreign key referenciákat beállítani. Röviden annyi, hogy innodb táblaformátumot kell használni, emlékeim szerint indexelni kell az idegen kulcs mezőket is:
A szintaktika le van írva a CREATE TABLE - ALTER TABLE oldalakon, de guglival gyorsan találsz példakódokat.
A kapcsolótáblában az elsődleges kulcs attól függően, hogy egy termék-felhasználó pároshoz egy- vagy több rekord tartozhat, ettől függően vagy a két idegen kulcs PRIMARY KEY ( felhasználóinév , vonalkód ) vagy pedig a PRIMARY KEY (felhasználóinév , vonalkód, időpont )
Utolsó kérdés: amikor például PHP-ből feltöltöm a táblákat adatokkal, akkor a kapcsolótáblával nekem kell foglalkoznom, vagy ezt majd megoldja a MySQL?
Nem értem a kérdést.
-
#14790
sztanozs
veterán
csabyka666
#14789
sztanozs
veterán
válasz
csabyka666
#14789
üzenetére
Táblákat összekapcsolni adatbázis szinten FOREIGN KEY Constraint-el tudsz.
Lekérdezés szinten pedig JOIN-nal tudsz összekapcsolni táblákat.A MySQL semmit nem old meg helyetted. Mind a táblákat, mind a lekérdezéseket neked kell elkészíteni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Teszem azt, megváltoztatom egy termék vonalkódját, majd törlöm a sütiket. Akkor mi van? 
Új hozzászólás Aktív témák
Hirdetés
- SanDisk Extreme Portable 8TB (SDSSDE61-8T00-G25)
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
- 129 - Lenovo Legion Pro 7 (16ARX8H) - AMD Ryzen 9 7945HX, RTX 4080
- Samsung Galaxy S23 Ultra 256GB, Kártyafüggetlen, 1 Év Garanciával
- LG 42C3 - 42" OLED EVO - 4K 120Hz 0.1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest