- Ezért jött hardveres sugárkövetés nélkül a Hellblade II
- Milyen videókártyát?
- Kormányok / autós szimulátorok topicja
- ASUS ROG Ally
- Megfizethető és viszonylag kompakt ház született a Lian Li-DAN Cases frigyből
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- iPad topik
- AMD Navi Radeon™ RX 7xxx sorozat
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Galax GeForce RTX kártyák jönnek a szűkösebb házakba
Hirdetés
-
Bivalyerős lett a Poco F6 és F6 Pro
ma Kínában más néven már startoltak, az európai árak magasabbak, de elviselhetők.
-
Fellebbezett az EU-ban az Apple, amelyet kongói botrány fenyeget
it Miközben az EU-ban 1,84 milliárd eurós, trösztellenes bírság ellen fellebbezett az Apple, addig a Kongói Demokratikus Köztársaság ügyvédei új bizonyítékokkal szolgáltak arra vonatkozóan, hogy az almás cég konfliktuszónákból szerzi az ellátási láncnak a nyersanyagokat.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz fordfairlane #15398 üzenetére
Vigyázz, mert mindjárt megkapod, hogy a Singleton qrva gáz.
"Majdnem olyan, mint egy Singleton"
Hogy érted azt, hogy majdnem olyan? Jelen formájában ez konkrétan Singleton-minta.Sk8erPeter
-
fordfairlane
veterán
válasz Sk8erPeter #15401 üzenetére
Talán rosszul tudom, de a singleton egy olyan objektum, ami önmagát állítja elő, futásidőben egyszer. Ez nem saját magát állítja elő, hanem a PDO-t.
x gon' give it to ya
-
DNReNTi
őstag
válasz Sk8erPeter #15401 üzenetére
Mért lenne gáz? Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás.
but without you, my life is incomplete, my days are absolutely gray
-
csabyka666
addikt
Biztos úgy van, ahogy mondjátok, de nekem ez már tényleg haladó szint.
Az biztos, hogy működik az oldal így is, ahogy most van, szóval akkora butaságot talán nem csináltam...
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
mallee
tag
válasz mallee #15405 üzenetére
A legjobb az egészben, hogy több egymásnak ellentmondó infót is találtam
Limitations
Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.Forrás: http://phpunit.de/manual/3.7/en/test-doubles.html
Úgy tűnik, hogy 3.5 alatt támogatott volt: http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html
[ Szerkesztve ]
-
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.but without you, my life is incomplete, my days are absolutely gray
-
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.
x gon' give it to ya
-
Sk8erPeter
nagyúr
válasz fordfairlane #15402 üzenetére
Ebben igazad van, de tulajdonképpen ez ilyen Singleton+Factory minta egyvelege.
(#15403) DNReNTi :
"Mért lenne gáz? Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás."
Egyrészt szerintem az ironikus hangvételből kiderült, hogy nem feltétlenül tükrözi a véleményemet a dolog, még ha bőven van is igazsága az azt ellenzőknek, tehát nincs szükség a szemforgatásra (arra amúgy sincs, ha szakmai vitát akarunk nyitni), másrészt meg javaslom, keress rá a topicban (pl. Athlon64+ kolléga itt kardoskodik ellene: [link]), illetve Stack Overflow-n és más forrásokban is, hogy mik is az érvek a Singleton-minta ellen; az "Adatbázis kapcsolat kezelésére szvsz nem igen van jobb megoldás" mondatra meg az a válasz, hogy van, akik meg tudják oldani nélküle, tehát lehet jobb megoldás. Most is előkapható a sablon-érv, hogy "nincs legjobb megoldás".[ Szerkesztve ]
Sk8erPeter
-
fordfairlane
veterán
válasz Sk8erPeter #15409 üzenetére
Ebben igazad van, de tulajdonképpen ez ilyen Singleton+Factory minta egyvelege.
Nem tudom, minek az egyvelege. Külön osztály végzi a példányosítást, és a példány felügyeletét futásidőben, ennyi. A Singletonnal szemben a leggyakoribb kifogás, hogy keveredik az objektum hagyományos szerepköre, a domain-funkció, és a példányosítási-futásidejű implementálási technika, és ezért nehezen tesztelhető.
Itt nem keveredik, szét van választva. Persze lehet tovább alakítani, hogy automatikus tesztekre alkalmasabb legyen, dependency konténerrel és társaival, de ez már végképp olyan szint, amivel semmiképp nem terhelnék egy kezdőt. Már ez is sok volt neki.
[ Szerkesztve ]
x gon' give it to ya
-
DNReNTi
őstag
válasz Sk8erPeter #15409 üzenetére
Az irónia lejött. Rosszul tettem fel a kérdést.
Nem úgy értettem hogy szerinted miért gáz, hanem általánosságban.
Mi szól a minta használata ellen, ilyen alapfeladat ellátása esetén mint az adatbázis kapcsolat kezelése?but without you, my life is incomplete, my days are absolutely gray
-
DNReNTi
őstag
Ha már úgyis témánál vagyunk, feldobom egy korábbi kérdésem. Tehát készült a kezem alatt egy lekérdezéseket kezelő osztály, ami jelen formájában nagyon jól működik, de a kérdés az hogy jó is e?
A kapcsolatot kezelő osztály szkriptje.
A lekérdezéseket kezelő osztály szkriptje.
A használata:
$DB = new Database();
$SQL_command = 'SELECT user_name FORM users WHERE id = ? AND active = ?';
$SQL_parameters = array(23,1);
try {
$DB->executeSQL($SQL_command, $SQL_parameters);
} catch (Exception $e) {
echo 'ERROR : ' . $e->getMessage() . '<br>';
}Én még nem tudtam megfektetni, eddig bármilyen (select, insert, update) lekérdezést jól lekezelt, vagy hibával (jól) elszállt. Tehát a kérdés: oké hogy működik, de jó e?
[ Szerkesztve ]
but without you, my life is incomplete, my days are absolutely gray
-
csabyka666
addikt
Köszi segítséget mindenkinek!
Az én "projektem" nem túl komoly, persze ettől még jogos, hogy OOP kézenfekvő, nem is ezzel van a probléma.
Esetemben egyetlen adatbázis van, egyetlen névvel/jelszóval, és vélhetően ennyi is marad, szóval úgy érzem, nem szükséges az init.php, de mindegy is, a kérdés igazából az lenne továbbra is, hogy a PHP fájlok elején elegendő-e a csatlakozást megejteni (include-dal vagy anélkül, az most mindegy, a hangsúly a csatlakozáson van), vagy pedig minden egyes query előtt includeoljam a csatlakozós php-t?Vagy pedig a harmadik út: hagyjam úgy, ahogy van most, mert ha csak az elején csatlakozok, vagy ha csak közben, az eredmény ugyanaz lesz?
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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.
but without you, my life is incomplete, my days are absolutely gray
-
mallee
tag
válasz DNReNTi #15412 üzenetére
Gondolatébresztők:
Database_Connection
private static $DB_Host = ........: Ennek a helye egy config fájlban lenne és valamilyen okosság mentén kéne beadni az osztályodnak.
error_reporting(0);: Miért kezel az adatbázis osztályod error reportolást? Mi köze van a kettőnek egymáshoz? (azon túl, hogy az adatbázis-kapcsolat felépítése esetén is jöhet hiba). Ennek inkább egy inicializáló, környezetet beállító, stb php-ben kellene lennie
echo 'Database connection failed. Code : ' . $DB_Connect->....; Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább, noha ő arra számított, hogy lesz adatbázis-hozzáférése. Ehelyett használj exception-t
Mi volt ezzel az osztállyal a célod? Hány helyen és hol hívod meg?
Database
Hát ez így nagyon nem jó. Több kisebb osztályba kéne szétvágni az executeSQL-t az SQL parancs típusok alapján, pl Database_Select_SQL valósítaná meg a selectes logikákat, Database_Insert_SQL az inserteset, stb. Ezzel elkerülhetnéd azt a csúnya és nehezen értelmezhető switch-case szerkezetet. Egyébként bár látom, hogy mi akar az osztály célja lenni, mégis nagyon rosszul olvasható a kód. A sok egymásba ágyazott if-else throw exception megoldás helyett inkább azt kéne vizsgálnod a feltételben, hogy sikertelen volt-e a végrehajtás: ha így van, akkor exception, egyébként fusson tovább a kód, pl:
$stmt = $this->_DB_Connect->prepare($SQL_command);
if ($stmt === false) { throw new Exception("blablabla"); }
$parameter_type_list = '';
foreach($SQL_parameters as $parameter) {
és nincs utána else!Ez sem tökéletes megoldás, de átláthatóbb a kevesebb egymásba ágyazott szerkezet miatt.
[ Szerkesztve ]
-
csabyka666
addikt
Sőt, közben eszembe jutott még valami.
Nálam úgy áll össze az oldal szerkezete, hogy van egy index.php fájlom, és ebben a fájlban vizsgálom, hogy éppen melyik menüpontot választotta ki a felhasználó. Érzésem szerint az index.php minden újratöltéskor lefut.
Szóval elegendő lenne csak ennek az elejére tenni a csatlakozást, és kihagyhatom az összes többi fájlból? Mármint, ami az index.php-n belül hívódik meg...? Mennyire jó megoldás ez?Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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.
-
csabyka666
addikt
-
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.
[ Szerkesztve ]
x gon' give it to ya
-
csabyka666
addikt
válasz fordfairlane #15420 üzenetére
Ez biztosan így van, de ahogy mondtam, nekem most az a lényeg, hogy működjön a dolog.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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.
[ Szerkesztve ]
x gon' give it to ya
-
mallee
tag
válasz fordfairlane #15420 üzenetére
Helyesen az ilyen kreátor objektumoknak az általad felvázolt módon sem lenne szabadna létezniük, helyette minden objektum kívülről várná a függőségeinek "kielégítését": bővebben.
-
csabyka666
addikt
válasz fordfairlane #15422 üzenetére
Azért "akadékoskodok" itt, mert annyira mélységeiben nem látom át, ezért kérdezlek benneteket. Nyilván, ha az index.php hívja be a többit, akkor annak az elején is jó a kapcsolódás, de hogy biztos legyek a dolgomban, inkább kérdezek.
Hátha van a PHP-nak valami sajátossága, hogy pl. fájlok behúzásakor is ki kell adni a kapcsolódást (persze nincs ilyen, csak példának írom)...szóval ha vannak rejtett dolgok, akkor azt ti tudjátok, én viszont nem.Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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.
x gon' give it to ya
-
csabyka666
addikt
válasz fordfairlane #15425 üzenetére
Okés, így már bátrabban teszem csak az elejére. Köszi!
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
DNReNTi
őstag
válasz mallee #15416 üzenetére
Szia,
Köszi az észrevételeket!
"Ennek a helye egy config fájlban lenne és valamilyen okosság mentén kéne beadni az osztályodnak."
Igen, így is volt, de ha ez az osztály nem a root-ban hanem egy almappában kerül meghívásra akkor sajnos elhasalt, mivel nem találta a config file-t a megadott helyen. Abszolút hivatkozással működik de azt csúnyának ítéltem meg, így egyelőre maradt ez a megoldás.
Erre mi lenne a legszebb, legjobb eljárás?"Miért kezel az adatbázis osztályod error reportolást?"
Nem kezel. Az adatbázis kapcsolat létrehozása előtt ki aztán pedig bekapcsolja az error_reporting-ot, hogy hiba esetén egy szépen megformázott hiba oldalra tudja dobni a felhasználót (header()). Ha nem kapcsolnám ki, akkor maga a php dobna hibát, ami után nem menne a header, ezért van benne. Ez ebből hiányzik, mivel: 1: nincs hibaoldal, 2: teszt."Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább"
Az előzőben benne a válasz. Élesben egy hibaoldalra dob."Mi volt ezzel az osztállyal a célod? Hány helyen és hol hívod meg?"
Ez az osztály, pontosabban ennek az egy szem statikus metódosa egy mysqli objektumot ad vissza. Meghívásra egyszer kerül, a Database osztály konstruktora példányosítja saját maga számára."Több kisebb osztályba kéne szétvágni az executeSQL-t az SQL parancs típusok alapján"
Ebben teljesen egyet értek, és így is lesz. Illetve majdnem. Úgy gondoltam egy osztály marad a lekérdezések kezelésére, csak több metódus lesz. Lesz egy private, ami ellenőrzi a lekérdezés helyességét, a paramétereket, stb, valamint query típusonként 1-1 metódus.Összességében jól értem, hogy főleg szépséghibák vannak, de a működés, és az elképzelés életképes?
Ha lesz időm ma update-elem, és jövök megint.but without you, my life is incomplete, my days are absolutely gray
-
TomyLeeBoy
tag
Üdv!
Átköltöztettem egyik munkámat wamp-ról iis-re, és a karakterkódolással akadt egy kis problémám. A mysql-ből nyert adatok széthullanak. iso-8859-2 volt beállítva eddig. Ha átállítom utf8-ra, akkor megfordul a helyzet, a mysql adatok lesznek jók és az összes többi nem. próbáltam mysql_set_charset-al az adatbázis hívásokat utf8-ra állítani de nem lett semmi változás. Valaki tudna ebben segíteni?
Az idő sebessége: 1s/s
-
DNReNTi
őstag
válasz TomyLeeBoy #15430 üzenetére
Csekkold le egészen biztosan mindenhol utf-8 e a karakterkódolás:
- adatbázis (táblák és mezők is !)
- a kapcsolat
- az oldalHa minden utf-8, akkor nem kéne gondnak lennie. Továbbá nézd meg azt is, hogy az adatbázisban helyesen vannak e tárolva az adatok, az is lehet a korábbi rossz kódolás miatt, eleve rosszul vannak tárolva az adatok, és az oldal maga jól írja ki.
but without you, my life is incomplete, my days are absolutely gray
-
DNReNTi
őstag
válasz TomyLeeBoy #15432 üzenetére
Az adatbázis és a táblák Szerkezet / Structure tabján.
but without you, my life is incomplete, my days are absolutely gray
-
DNReNTi
őstag
válasz TomyLeeBoy #15434 üzenetére
Dede. Az lesz. Bocs én írtam rosszul.
but without you, my life is incomplete, my days are absolutely gray
-
TomyLeeBoy
tag
válasz DNReNTi #15435 üzenetére
Na hát az itt latin1_swedish_ci, de akkor jelenik meg jól ha az oldalt utf8-ra állítom, csak akkor meg az oldal esik szét :/
Szerk: Azt még csak megértem hogy az adatbázisból olvasott adatoknak nem mindegy, de egy akármilyen áéőöüó utf8-ra kódolt php lapon generálvi miért ??-eket jelenít meg? Mert így az adatbázisból olvasott adatok jók, csak a kézzel az oldalba írtak helyén van kérdőjel.
[ Szerkesztve ]
Az idő sebessége: 1s/s
-
Sk8erPeter
nagyúr
válasz DNReNTi #15427 üzenetére
"Nem kezel. Az adatbázis kapcsolat létrehozása előtt ki aztán pedig bekapcsolja az error_reporting-ot, hogy hiba esetén egy szépen megformázott hiba oldalra tudja dobni a felhasználót (header()). Ha nem kapcsolnám ki, akkor maga a php dobna hibát, ami után nem menne a header, ezért van benne. Ez ebből hiányzik, mivel: 1: nincs hibaoldal, 2: teszt."
Te ezt írtad:error_reporting(0);
$DB_Connect = new mysqli(self::$DB_Host, self::$DB_User, self::$DB_Pass, self::$DB_Name);
if ($DB_Connect->connect_error) {
echo 'Database connection failed. Code : ' . $DB_Connect->connect_errno;
}
$DB_Connect->set_charset(self::$DB_Char);
error_reporting(1);Tehát fogod, és 0-ra, majd 1-esre állítod az error_reportingot.
Egyrészt eleve milyen alapon nyúlkál az osztályod az error_reporting értékéhez, minek? Az ilyesmit felejtsd el gyorsan. A kód ne csináljon többet az elvártnál.
Másrészt sztem te az error_reporting()-ot a display_errors értékével kevered.
Harmadrészt miért állítod be az error_reporting szintjét pont az E_ERROR-ra? Az error_reporting(1); ugyanis ekvivalens azzal, ha azt írod, hogy error_reporting(E_ERROR); Mi van, ha korábban az error_reporting értéke szándékosan E_ALL-ra volt állítva, ami 32767? (Itt láthatod az értékeket.)"»»"Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább"
Az előzőben benne a válasz. Élesben egy hibaoldalra dob."
Hát ez eleve rossz megközelítés. Most akkor itt echo-zol, de aztán majd élesben átírod normális hibakezelésre? Ez így nem lesz jó. Az ilyenből tuti, hogy az lesz, hogy tesztelésnél nem jelentkezik semmilyen hiba, tök jól működnek a dolgaid, aztán majd élesben jöhet a gebasz, és akkor szépen kiírtad a képernyőre a hibaüzenetet, ahelyett, hogy eleve normálisan kezelted volna a hibákat, már amikor megírtad a kódot.
Jótanácsként mondom, ne szopasd magad azzal, hogy "hát ezt majd átírom", mert úgyis elfelejted, vagy pedig később csak macerás lesz megcsinálni.
Szóval az echo-zás helyett dobj szépen egy exceptiont, hiszen komoly hiba, ha nem tudtál csatlakozni az adatbázishoz.A többit asszem mallee már leírta, például hogy tök értelmetlenek az if-else-be rakott exception-dobásaid.
Pont azért jó, hogy tudsz dobálni exceptionöket, mert elkerülheted az ilyen ocsmány if-else szerkezeteket.Sk8erPeter
-
DNReNTi
őstag
válasz Sk8erPeter #15437 üzenetére
Köszke neked is, jövök majd a v1.2-vel, ezek figyelembevételével.
but without you, my life is incomplete, my days are absolutely gray
-
mallee
tag
válasz DNReNTi #15427 üzenetére
de ha ez az osztály nem a root-ban hanem egy almappában kerül meghívásra
Hirtelen ezek a megoldások jutottak eszembe erre:
1. Használj autoload-ot és a konfigurációs beállításokat egy osztályba tedd, pl Config_Database. Ez még mindig nem szép megoldás, de a problémát feloldja.
2. Biztos van valamilyen inicializáló, közös része az alkalmazásodnak, ahol be tudod olvasni a konfigurációt és be tudod állítani a Database_Connection statikus mezőit. Ehhez azonban a láthatóságot át kell állítanod. Ez már egy egészen jópofa megoldás kezd lenni, viszont ebben az esetben koncepcionálisan rossz a Database_Connection osztályod.
3. Van egy osztályod, ami a konfigurációt kezeli (beolvassa a megfelelő helyről) és tőle lekérdezi a Database_Connection osztály a megfelelő értékeket. Ez már szép megoldás is lehet, megvalósítástól függ.
4. Van valamilyen osztályod, amely a függőségeket kezeli, pl eltárolja a Database objektum referenciáját és ahol adatbázissal akarsz foglalkozni, ott ettől az osztálytól kérdezed le a Database objektum referenciáját. Ennek egy nagy hibája, hogy eléggé központosított lesz a kód, túlzottan erős lesz a szerepe ennek az osztálynak, minden tőle fog függeni.Úgy gondoltam egy osztály marad a lekérdezések kezelésére, csak több metódus lesz. Lesz egy private, ami ellenőrzi a lekérdezés helyességét, a paramétereket, stb, valamint query típusonként 1-1 metódus.
Ez elég szép megoldásnak hangzikA többit már elmondták előttem, várjuk az új verziót
-
csabyka666
addikt
válasz TomyLeeBoy #15436 üzenetére
Nekem is volt hasonló problémám az adatbázissal. Vagy az adatbázisban voltak értelmezhetetlen karakterek, de az oldalon jól szerepelt, vagy fordítva. 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'");Nekem ez megoldotta, most mindenhol jó a kódolás.
A head-ben nekem ez szerepel:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />, az adatbázis illesztése pedig "utf8_general_ci".Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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!
[ Szerkesztve ]
Az idő sebessége: 1s/s
-
csabyka666
addikt
válasz TomyLeeBoy #15441 üzenetére
Igazán nincs mit!
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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,
)
);Sk8erPeter
-
PumpkinSeed
addikt
Hülye kérdés, de nem találom a megfelelő kulcsszavakat se hozzá.
A POST-al átküldött adat mennyire biztonságos, illetve hogyan lehet biztonságosabbá tenni azt?
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
mallee
tag
válasz PumpkinSeed #15444 üzenetére
Mit értesz biztonságos alatt? Amúgy bármilyen webről jövő adatot nem biztonságosnak kell tekinteni.
-
PumpkinSeed
addikt
válasz mallee #15445 üzenetére
Hát biztonság alatt a titkosítást értem. Gondolom, a internetről jön akkor valami csomagszűrővel biztosan el lehet kapni, csak az érdekel, hogy ha el is kapják akkor mire kell számítani, mennyi eséllyel látják meg a ténylegesen átküldött adatot vele?
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
trisztan94
őstag
válasz PumpkinSeed #15446 üzenetére
Titkosításhoz menjen HTTPS protokoll alatt.
https://heureka-kreativ.hu
-
csabyka666
addikt
válasz Sk8erPeter #15443 üzenetére
Mindegy is, legalább sikerült segítséget adnom, ez nekem nagy szó.
Amúgy nyilván igazatok van...
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
csabyka666
addikt
SQL topicban már feltettem ezt a kérdést, de itt lehet, hogy jobb helye van. Szóval.
SQL injection ellen mi (vagy mik) a legjobb PHP függvények? Ezt találtam: mysql_real_escape_string(), és kérdeznélek benneteket, hogy ez elegendő, vagy küldjek rá még másik függvényeket is?
(Nem OOP a projekt, hanem az alap mysql_* függvényeket használom.)Más: eddig ha ' (aposztróf) karakter szerepelt a beszúrt mezőben, akkor mindig hibát dobott az SQL. Most, hogy lekezeltem minden beviteli mezőt mysql_real_escape_string() függvénnyel, már bekerülnek az '-os stringek is az adatbázisba. Ez így rendben van, vagy ezzel nyitottam egy biztonsági rést?
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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.
Sk8erPeter
Új hozzászólás Aktív témák
- Mobil flották
- LEGO klub
- Ezért jött hardveres sugárkövetés nélkül a Hellblade II
- Milyen videókártyát?
- Kormányok / autós szimulátorok topicja
- Kerékpárosok, bringások ide!
- ASUS ROG Ally
- Kínai, és egyéb olcsó órák topikja
- Megfizethető és viszonylag kompakt ház született a Lian Li-DAN Cases frigyből
- Politika
- További aktív témák...
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen