bubu

bmp fails nesastāv vien no pikseļiem ar krāsām. Sākumā ir headeris, kuru tev vajag izlaist pirms ģenerēt pikseļus. No headera tu vari izvilkt informāciju par to, kāds ir bildes izmērs, vai cik bitus aizņems katrs pikselis (32, 24, 16, ... ) Palasi šo: http://en.wikipedia.org/wiki/BMP_file_format#BMP_file_header Šis ir otrais topiks, kuram ar php5 fičām nav nekāda sakara (OOP, exceptioni, ..). Izvēlies pareizāku sadaļu. Drīz laikam būs jāpārsauc php5 sadaļa par php6, lai būtu up to date. Un kāpēc tu lasi "pa 2 baiti"? Tev tie visi bmp vienā formātā vai? Un tas, ko tu te uzrakstīji, vairāk izskatās pēc RLE kodēta bmp lasīšanas. Sākumā gan tev dīvains cikls - kur tu $height daudzumā $offset masīvā salasi 2-baitīgus integerus. Kam tas? Vēl arī - tev nebūtu vienkāršāk ar kādu bilžu apstrādes programmu nokonvertēt visus bilžu failus uz png/jpg/whatever kādu citu formātu un tad tos lietot?

Tas būtu visai slimi, ja array_key_exists skrietu visam masīvam cauri, t.i. darbotos O(n) laikā. Jēga no tādas funkcijas nekāda nebūtu. Un tā kā tas ir labi zināms, ka php masīvi īstenībā ir heštabulas, tad parbaudīt to, vai masīvā eksistē elements ar dotu atslēgu, ir visai dabiski, ka O(1). Nu labi, īstenībā sliktākā situācijā var gadīties O(n), bet nu praktiski tu diez vai tādu gadījumu piedzīvosi (kad vairums masīva atslēgu heši sakrīt). isset gadījumā tā vai tā pašam php ir jāmēģina dabūt elements ar doto atslēgu no asociatīvā masīva - respektīvi tieši tāda pat situācija array_key_exists gadījumam. Elements ar doto masīvu arī ir jāmeklē, gribi vai negribi. Tā ka tas ir stila jautājums, nevis ātrdarbības. Iespējams, ka php ir kautkā hakaini iehakots, lai isset būtu ātrāks, jo tas kā nekā ir keywords, nevis funkcija, kuram atšķirībā no pēdējā nevajag aiztikt steku, taču otram nav nekāda pamatojuma būt lēnākam (ja nu vienīgi php developeru slikums to kārtīgi implementēt). Atšķirībai katrā ziņā jābūt minimālai.

Vai tad tas nav normāli, ka uz production servera diseibloti error'u rādīšanās? Un vai sava skripta sākumā error_reporting(E_ALL) un ini_set("display_errors", 1") nelīdz? Var jau arī custom error handleri uzlikt un rādīt kļūdas kādā vien tik izskatā gribās: http://php.net/set_error_handler

Masīvus ir jālieto: <?php $arr = array( 1 => "teksts1", 2 => "teksts2", 3 => "teksts3", ...); $x = 2; echo $arr[$x]; ?>

Var jau arī extract() fju pielietot, bet nu tā diez vai skaitīsies salabošana.

Manas atbildes - Nē (par manu darba vietu) / Nē.

Kas tev "pat tur nav"? Iekopē skriņšotu vai tekstā nokopētas komandas un to rezultātus - DROP TABLE tava_tabula; un SHOW TABLES;

Tie 12 baiti tev jāuztver kā 3 integeri (4-baitu skaitļi): function convertToInteger($s) { return ord($s[0]) + (ord($s[1])<<8) + (ord($s[2])<<16) + (ord($s[3])<<24); } $lookup = convertToInteger(fread($handle, 4)); $size = convertToInteger(fread($handle, 4)); $unknown = convertToInteger(fread($handle, 4)); echo $lookup, " ", $size, " ", $unknown; Un kāpēc tu to sauc par "nepazīstama faila struktūras izvadīšanu"? Struktūra failam tev ir pazīstama - tavā skrīnšotā fragments no faila struktūras visai skaidri uzrakstīts.

Vai tad IE supportēja ne-ASCII burtus URLī? Vai tik nebija tie jākonvertē ar Punycode: http://en.wikipedia.org/wiki/Punycode offt: hehe, wikipēdijā punycode piemērā izmantots latviešu http://tūdaliņ.lv

Muļķības. PHP katram mainīgajam piemīt konkrēts tips. http://php.net/gettype Tas tev nav nekāds visual basic ar Variant tipu. Cita runa, ka php daudzas konvertācijas starp tipiem ir implicitas, (string->bool, int->string), t.i. notiek automātiski, neko īpaši nedarot. "" nav tas pats, kas false. Tas, ka tas ir vienāds salīdzinot to ar false, ir cita runa. Ekvivalents tas nav.

Ļoti vienkārši - salabo tā skripta kodu, kuram vajag register_globals=1, tā, lai tas strādātu arī uz register_globals=0.

marcis, pievērs uzmanību šim: $var = nevērtība $var == 'vērtība': false !$var == 'vērtība': false $var != 'vērtība': true Un arī arī Endija teiktajam.

Stulbākajā veidā izveido masīvu ar tiem grupu numuriem tik, cik tev viņu tur vajag. Piemēram, ja ir 3 grupas, tad izveido masīvu array(1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3); Un tad attiecīgi ar array_rand fju izvēlies un izmet no masīva skaitli visām grupām pēc kārtas.

Ja $var ir booleans un 'vērtība' ir true vai false, tad abi varianti ir vienmēr vienādi. Citos gadījumos tev var gadīties visādi "brīnumi".

Tu kaut kādus slimīgus tekstus raksti... Vienā vietā saki, ka paredzēts taisīt šitā. Un nākamajā postā saki, ka tur tač var uztaisīt arī pēc savas sistēmas! Ko tad tavuprāt v3rb0 vai Endijs rakstīja augstāk? Varbūt iedziļinies arī citu teiktajā, nevis kaut ko stāsti muļķības beztēmā. Viņš to arī teica, ka urļus veidot var pēc savas sistēmas, neviens tev neliek to "ZendFramework urlis paredzēts" veidā veidot tos urļus.

To dara ar if konstrukciju. if (nosacījums) { darbība1; } else { darbība2; } Ja nosacījums būs patiess, tiks izpildīta darbība1. Bet ja aplams - tad darbība2. Piemēram: $x = 10; if ($x > 5) { echo "Skaitlis x ir lielāks par 5"; } else { echo "Skaitlis x ir mazāks vai vienāds par 5"; } Saraksti savus nosacījums kādus vien tev vajag, un iekšā saliec vajadzīgās darbības.

Visai loģiski, ka izpildot divas INSERT komandas: mysql_query("INSERT INTO lietotaji VALUES ('$niks', '$pass', $epasts))"; mysql_query("INSERT INTO vestule VALUES (vēstuļu dati...))";

Nu ja tas tavs JS kods būs smuki un universāli uzrakstīts, tad tā būtību var jau mēģināt saprast no tā, kā tu to lieto saistībā ar HTML. Tb kādas funkcijas kādiem elementiem izsauc. Kas tad notiek uz ekrāna. Vai uz kādiem eventiem to sauc. Bet ja tas JS kods būs nekārtīgāks, lai grūtāk to saprast, tad kuram gan tas būs vajadzīgs (ar domu - nekārtīgs un nelabs kods). Diezgan salīdzināmi ar bildēm - būs smuka un aizraujoša bilde, kāds ļoti pacentīsies to izdabūt, lai vai kā to "aizsargātu". Būs nesmuka un nevajadzīga bilde - neviens pat PrintScreen nepacentīsies nospiest.

Ko tad tu gribi īsti panākt? Nu nevar JS kodu aizsargāt. Tas nav acīmredzami? Ja browserim jāmāk tas lasīt, tad arī jebkurš cilvēks to varēs lasīt. Var, protams, muhļīt kodu, lai tas grūti lasās vai ir grūti rediģējams. Bet vienmēr to varēs relatīvi viegli dabūt plainā (izņemot mainīgo nosaukumus). Varbūt nākamais jautājums būs par css vai html markupa "aizsardzību"? Ja nu skriptkidijs nozog tavu <div> tagu?

Tas nekodē tikai ar base64. Tas laiž kautkādu kompresiju pa virsu. Tādējādi vēl vairāk iembremzējot klienta pusi. Jēga no tāda? Vienkāršāk webserverim ir uzslēgt gzip kompresiju uz noteiktiem failiem. Gan performance būs lielāka, gan arī trafiks mazāks, nekā ar kautkādu JS kompresētāju. Tīru base64 vari pamēģināt, piemēram, šeit: http://rumkin.com/tools/compression/base64.php. Un andrisp saka pareizi - ar to tev teksts būs vidēji par 33% lielāks.

Par ko tu runā? Es labi zinu, ka kodu obfuskē (tavs shrink variables), lai "nespertu". Tas, ko es teicu - ir, ka nesaprotu jēgu base64 vai tml kodējumiem. Tas neko nepasargā. Tikai lieki noslogo klienta browseri pie lapas ielādes. Un to "atšifrēt" ir tik vien kā vienu standartfunkciju izsaukt kādā valodā, ja tāds bija tavs jautājums.

Protams, ka var atspiest. Kāpēc lai nevarētu? Ja jau browseris nevarētu to atspeist, tad kāda jēga no tāda javaskripta, kuru nevar izpildīt? Cits jautājums ir - cik daudz laika un pūļu vajadzēs veltīt, lai saprastu ko visi x, a, b, utt mainīgie nozīmē. Varbūt šo laiku var veltīt funkcionalitātes uzrakstīšanai no jauna. Un vispār - kur prāts kodēt JS ar base64? Tas tak tikai lieks trafiks un lieks darbs (lasīt aizture/bremze) klienta browserim atspiest to.

Aleksej: magic quotes jau enterus neaiztiek, ne? Devils666: padebugo kodu - ieliec vairākās vietās (pirms/pēc eskeipošanas) echo/print_r/var_dump un paskaties mainīgā vērtību.

hm.. mysql_escape_string nevajadzētu to ietekmēt. Jā, tas pārvērš enteru par \n, bet to tas dara tāpēc, lai tu ievietojamo stringu varētu likt pēdiņās, kad to liec kverijā. Reāli datubāzē saglabāsies enters. Esi pārliecināts, ka neizsaci divreiz escape_string? Varbūt pēc tam vēl izsauci addslashes? mysql_escape_string nevajadzētu ņem nost vispār. Tas padarīs tavus kverijus ievainojamus, un zinošs cilvēks varēs izčakarēt tavu datubāzi.

Bah.. jāsāk atkārtoties. Ja tev datubāzē uzrāda \n simbolu (vienu čarakteru), tad tev teksta izvadīšanai html'ā jālieto nl2br fja. Izvadīšanai textareā nav nekas jālieto - viss izvadīsies pareizi. \n kā viens čaraketers nozīmē endlainu (enteru). Ja tev datubāzē glabājas divi simboli - \ un n pēc kārtas, tad tu esi: 1) vai nu ielicis tur divus simbolus \ un n (nevis enteru), 2) vai arī tev skriptā, kas atbild par teksta ievietošanu datubāzē, kautkur ir manis augstāk uzrakstītais str_replace (varbūt ereg_replace vai preg_replace). Izmet to ārā un tad lasi iepriekšējo rindkopu. Var protams mudīties un manuāli pie outputa konvertēt "\\n" uz "\n", bet nu tas ir pilnīgi garām.