nukaa

Atbildi rakstot iedomājos, ka varbūt to visu valodas padarīšanu varētu ar bitmasku veidot, tad ietilptu mysql\a viss vienā laukā- "val", kur katram stāvoklim atbilstu, piemēram $irMULTI = (1 << 0); $irEN = (1 << 1); $irLV = (1 << 2); un veidotu mysql vaicājumu pret šo lauku, kur bitwise pārbaudītu ((lietotaprasitavaloda & mysqllauksval) == $irMULTI) //ir multi utt. Kārtējais jau zem vinčika esošais edits. Tā kā ar mysql nestrādā, tad tie atklājumi nāk palēnām:). Pašlaik ir projid valmulti vallv valen txtlv txten ... kur es no datubāzes pieprasu laukus konkrētai valodai pēc principa "val".$val, $"txt".$val, "blabla".$val - tiek iedota šūna no rindas, kura ir ar lietotāja pieprasīto $val kā sufiksu Laikam jau pareizais variants(?) ir nodalīt atsevišķās tabulas rindās katrai valodai priekš resursa. projid val txt kur vienkārši pieprasīt pēc val lauka vērtības. $query = "SELECT * FROM tabula WHERE (projid='".$projid."' AND val='".$val."')"; Tikai tad, lai noteiktu, vai konkrētais projid ir bilingvāls jājautā pēc $query = "SELECT * FROM tabula WHERE projid='".$projid."'"; if(mysql_num_rows($result)==2) //ir bilingvāls else if (mysql_num_rows($result)) //nav bilingvāls, bet ieraksts eksistē, jānoskaidro vai pieprasītai valodai else // uups Priekā.

Paliku tātad tikai pie mysql_real_escape_string(). Paldies. Nemāku atbildēt uz šo jautājumu :) Tā ir viena no lietām ar ko cīnos, un šķiet, ka pašlaik ir arī izcīnīta. Maza daļa no mājaslapas ir bilinguāla. Mana vēlme ir pie konkrēta resursa pieprasījuma caur mysql noskaidrot, vai šis resurs ir bilinguāls, un ja nē, tad kura no valodām en vai lv ir pieejama. Attiecīgi notiek tūlītējs redirekts uz pieejamo valodu, ja pieprasītā nav peejama. Nu un tur vēl lapā tālāk, protams, tiek izdrukāts links, piem., "šī lapa pieejama arī latviski", ja pieprasīts en bet lv arī pieejams (nu tas "parastais variants"). (Piezīme - JavaScript lapā neizmantoju un neizmantošu; jā, ar to varētu arī servet bilinguālu kontentu, turklāt pie svičošanās nebūtu jāpārladē lapa. Bet tomēr palieku pie PHP, MySQL, XHTML 1.0 Strict, CSS3. Piedodiet, ja skan spītīgi.) Tabulā ir lauki valmulti, vallv un valen, kuri ir int tipa, kalpo kā boolen (0||1) iespējamās vērtības tad nu būtu projid valmulti vallv valen dummy 0 1 0 dummy 0 0 1 dummy 1 1 1 Lietotājs prasa $_GET['val'] un $_GET['projid'] un tas mysql vaicājums, par ko tev jautājums ir: $query = "SELECT val".$val." FROM tabula WHERE projid='".$projid."'"; // piemēram "SELECT vallv FROM tabula WHERE projid='dummy'"; $result = mysql_query($query, $mysql_link) or die (mysql_error()); if(mysql_num_rows($result)) { $hasVal = (int)mysql_result($result,0,"val".$val); // dabūnam 0 vai 1 if(!$hasVal) { // tiekot šitik tālu ir skaidrs ka konkrētais resurs eksistē bet valodas nav, momentāli headero'jam uz otru valodu (ja resurs eksistē, tad garantēts, ka 1 valoda būs) // šis kods ir pašā lapas sākumā, attiecīgi pieņēmu, ka saukt location šeit ir pieņemami no lietotāja viedokļa, jo tas redirekts notiek momentāli } else { // Tiekot šeit ir skaidrs, ka resurs pieejams un arī prasītā valoda. BINGO. sākam lasīt ārā visus tekstus utt. } else { // projid pieprasīts neeksistē (jo tas, ka $val būs "lv" vai "en" pirms $query ir garantēts- php kods pirms tam jau tiek galā ar šo mainīgo un izsijā, ja lietotājs cenšas uz savu roku ķibināties ap uri } Es jau atkal par tiem "resursiem". Ja es prasītu $query = "SELECT * FROM tabula WHERE projid='".$projid."'"; tas tak patērētu vairāk laika, lai ielādētu resursu? Man tas šķiet vienalga vai tas ir 1ms vai 10 ms ieguvums, esmu centies kopt šādas lietas rakstot kodu, nedomāju, ka to vajadzētu pazaudēt. Cita lieta ir, ka tavs pārmetums ir kaut kādā veidā MySQL specifisks. Ja tā, tad lūdzu komentē :) Varbūt ir iespējams labāks veids, kā risināt šo situāciju, kur, piemēram, mysql glabājas X resursi (sauksim tos par projektiem), kuram katram ir identifikators projid, un katrs resurs var būt vai nu lv, vai nu en, vai abās val. Lietotājs prasa (tas gan ies caur mod_rewritu vēlāk) ?val=lv&projid=projekts01

Ar regex Tu domā preg_xxx funkcijas, t.i., izmanto salikumu no mysql_real_escape_string(),$sliktieVardi un pre preg_replace($sliktieVardi,...)? (Cik noprotu POSIX regex sākot ar PHP 5 nav vairs lietojams). Pēc manām zināšanām citās valodās un environmentos regex funkciju kopumi vērtējami kā ļoti lēns stringu apstrādes veids (vai arī php regex ātrums ir pielīdzināms, piemēram, Perl'am?). Vai arī GET variabļu, kuri, protams, ir maz skaitā, apstrādē Tu to vērtē kā maznozīmīgs apstākli?

Labdien. Pārrakstu mājaslapu no nulles. Nekādu CMSu vairs, vai precīzāk- paša veidots "lapeles menedžments" konkrētai vajadzībai. Vēlos smuki un solīdi. Nav problēmu lasīt lietoto valodu un API dokumentācijas. Tomēr ir lietas, ko neatrast dokumentācijā, bet gan forumos, grāmatās un pieredzē- it sevišķi mysql+php+drošība jautājumi. Apzinos, ka tas, ko domāju šeit mest iekšā, ir n-tās reizes apspriesti citur un tādēļ velk uz RTFM un spamu. Bet tomēr, tagad, liekot ķieģelīšus no nulles, vēlētos priekšdienām iekalt uz palikšanu koncentrētas zināšanas, lai šis topiks kļūtu par stickie vismaz man. Ceru uz atbildēm. Pirmais jautājums. Kas ir saprātīgā robeža, lai apstrādātu $_GET variabļus, kas tiek izmantoti mysql vaicājumos. $mama = $_GET['mama']; $blabla = $_GET['blabla']; $query = "SELECT ".$blabla." FROM tabula WHERE mama='".$mama."'"; Pašlaik lietoju THE MUST $mama = mysql_real_escape_string($_GET['mama']); Vai tas ir pietiekami? Esmu redzējis visādus paņēmienus. Turklāt, tā kā esmu "C puika", man vienmēr ir interesējusi koda optimizācija un izpildes laiks. $sliktieVardi = array("/delete/i", "/update/i","/union/i","/insert/i","/drop/i","/--/i"); $mama = preg_replace($sliktieVardi, "", strip_tags(stripslashes(mysql_real_escape_string($_GET['mama'])))); Vai tie, kas iesaka augstāk rakstītās papildus apstrādēs bez mysql_real_escape_string(), ir paranoiķi, vai tomēr tas ir pamatots apstrādes veids GET mainīgajiem pirms to likšanas mysql query'os? Lapa tiek veidota uz PHP 5.3.1, MySQL 5.0.51a Liels paldies liels jau iepriekš. Pirmā atbilde: mysql_real_escape_string() ir pietiekami.