Sākumlapa › Forumi › Mājas lapu izstrāde › Servera puse (php, java, ruby, perl, python) › Kāpēc pēc nl2br() paliek n zīmes?
čaļi mierīgāk
P.S. No tēmas nejēdzu neko, bet izklausās svarīgi, piedāvāju strīdu atrisināt ringā, kā ieročus drīkst izmantot klavieres un peles. Noteikumi vienkārši: katrs sitiens ar klvau/peli pa pretinieka viepli – 1 punkts, ja izdodas ar peli iegāzt pretiniekam pa degunu tā lai būtu dubultklikšķis – 2 punkti. Uzvar tas kurš pēdējais stāv kājās. 😀
Klients maģiski teleportējies ārā no servera skopes, nd/nnd vairs maģiski vērtības neapstrādā un ļauj tik barot iekšās visu, kas ienāk prātā un problēmas pārcelšana no punkta A uz punktu B pēkšņi maģiskā kārtā atrisina visas problēmas. Wow, esi atklājis pirmo universālo un vienmēr korekto atbildi uz senu programmēšanas jautājumu.
Protams, ka bināru datu saturu nekāds draiveris nepārbauda, jo tas nemaz nezin kam tur jābūt un ko pārbaudīt. Bināriem datiem pārraidē ir jāzin tikai izmērs baitos. Jau n-to reizi atkārtoju, ka, lai kaut ko sāktu saprast, Tev vajadzētu teleportēties ārā no savas līko web risinājumu aprobežotās pasaulītes! Tagad līkākā datu bāze MySQL par piemēru viņam… Speciāli sameklēju informāciju “dļa osobo tupih”, kuriem lietas būtība bez praktiskiem piemēriem nemaz nepielec!
Izrādās, ka MySQL izstrādātāji tiešām ir TIK lieli auni, ka kopš iznākšanas 1995. gadā client/server protokolā visi datu tipi ir tikuši pārraidīti tekstā. Astoņu gadu laikā gan ir sapratuši, ka kantaini kluči TOMĒR neripo uz priekšu, un 2003. gadā izlaiduši 4.1 versiju, kurā izgudrojuši riteni – bināru datu pārraidi. Jauki – tagad arī MySQL brauc ar apaļiem riteņiem! 😀
“New faster client/server protocol that supports prepared statements, bound parameters, and bound result columns, binary transfer of data, warnings.”
Marš lasīt mysqlnd un mysqld sources.
Sources te nav jālasa, pietiek ar klienta/servera protokola dokumentāciju:
Par piemēru varam paskatīties normālā protokolā – Tabular Data Stream, ko izstrādā un izmanto savos produktos Sybase un Microsoft:
291. lpp. – bināri, optimāli, vienkārši un eleganti.
Bez augstāk minētā stringu protokola idiotisma, vēl pāris MySQL izstrādātāju “līmeni” norādoši sviesti:
* PDO, kas ar PHP 5 beidzot tika ieviests tikai 2004. gadā, pat vēl šodien neatbalsta viena pieprasījuma tiešu izpildi (netaisot prepare/execute) kopā ar parametru bindošanu. Piemēram, ODBC tas tikai ieviests ar 2.0 versiju 1994. gadā! Tur ir gan SQLExecDirect, gan SQLPrepare+SQLExecute, bet abas izpildes strādā ar SQLBindParameter.
* Tāpat kā PHP – slikta dokumentācija. Tam pašam 2003. gadā izlaistajam binārajam protokolam vēl stāv rakstīts klāt “(Tentative Description)”, un arī visa pārējā dokumentācija ir nožēlojama.
* Caurs kā Holandes siers. Tāpat kā PDO, uz ko pats vēl devi linku!
* Licence – stulbais juridiskais trojānis GPL.
Nu, nu, nebāz galvu smiltīs, kad sākas pats interesantākais – tas kā Tu pierādīsi, ka kantains ritenis ripo labāk!
Nu, nu, nebāz galvu smiltīs, kad sākas pats interesantākais – tas kā Tu pierādīsi, ka kantains ritenis ripo labāk!
[img]
* Pilnīga transportlīdzekļu nelietojamība ārpus šiem speciālajiem ceļiem.
* Pilnīga transportlīdzekļu nelietojamība sniega, ledus, dubļu un tamlīdzīgos laikapstākļos.
* Lielāki ceļu, transportlīdzekļu un ceļu būves tehnikas izstrādes un uzturēšanas resursi.
Ideāli atbilstošs piemērs stringu konkatenācijai – samazināta lietojamība un lielāks resursu parētiņš jeb “Lose-Lose” situācija.
Ikdienā 90% gadījumu dati nāk un iet uz datu bāzi, kas ir bināra. Ja klients ne-teksta datus apstrādā, tad tas tāpat notiek bināri. Vienīgais gadījums, kad nepieciešama šādu datu pārvēršana teksta formā, ir lai tekstu renderētu un attēlotu cilvēkam. Attiecīgi parsēšana arī ir nepieciešama tikai lai ielasītu cilvēkam lasāmo formātu, vai arī datus masveida idiotisma XML un tā līdzinieku paskatā dēļ tā, ka daudz citu sistēmu rada tādi paši nejēgas kā Tu.
Bez vecām līkā MySQL versijām un vispārējās tukšās gvelšanas būs kāds objektīvs arguments kādēļ normālā sistēmā būtu jāveic lieka bināru datu muļļāšana uz tekstu un atpakaļ?
Ikdienā 90% gadījumu dati nāk un iet uz datu bāzi, starp sistēmām kas ir bināra binārā formā. Ja klients ne-teksta datus apstrādā, tad tas tāpat notiek bināri. Vienīgais gadījums, kad nepieciešama šādu datu pārvēršana teksta formāizvade, ir lai tekstu renderētu un attēlotu cilvēkam.
Nu tad beidzot arī šo izpīpeji. Gandrīz. Pasēdi, padomā kādu stundu vai divas un varbūt pieleks, ko es tev te pēdējās dienas mēģinu ieskaidrot.
P.S Vispirms bija ceļš – un tad ritenis. Padomā par to.
root
Sāc saprast arī to, ka ir dažādas situācijas kur ir dažādi risinājumi, un kā jau viens cilvēks te augstāk minēja – nav tāda ideālā risinājuma!
Jā, es esmu jauns, man vēl daudz jāmācās, WEB programmēšanas(tik tiešām programmēšanas jomā, neesmu nekāds WPists vai Joomlists u.t.t.) jomā strādāju nedaudz vairāk par gadu, bet nu to, ka nav ideāla risinājuma – sapratu pēc pirmā nostrādātā mēneša(tikai nevajag pārprast)!
Īsumā – cieni citus un citi cienīs Tevi. Pateikt ka otrs ir idiots padara Tevi pašu par tādu.
root
Š eit runa bija par SQL un parametru bindošanu – tātad jebkurā gadījumā par datu bāzēm, nevis citām sistēmām. Un tajā kontekstā es arī teicu to “nāk un iet uz datu bāzi” – t.i. sistēmā ar datu bāzi 90% datu ceļo starp klienta programmu un datu bāzi, nevis, piemēram, tiek importēti klienta programmā no faila cietajā diskā vai kādas iekārtas (un tāpat arī tie pēc tam ceļo uz datu bāzi).
Un pričom te interpretējamās valodas? Runa ir par datu pārraidi! Tu atšķir KODU no DATIEM? To, ka tās ir divas pilnīgi neatkarīgas lietas, ko NEDRĪKST salaist kopā, spēj saprast? Es Tev augšā jau parādīju reālus DB klienta/servera protokolus. Visos normālajos protokolos SQL jeb kodu pārraida tekstā, bet parametrus jeb datus atsevišķi bināri. Kas Tev nepielec? Beidz vienreiz izvairīties no pamata jautājuma un atbildi – kādēļ šādā sistēmā dati ir jāmuļļā uz tekstu un otrā galā atpakaļ?
Preses relīzes