Jump to content
BulForum.com

PHP уеб платформи


Recommended Posts

Ами като начало защото географски най-близката точка до всички участници в спора се пада някъде в Лондон или Париж :)

Link to comment
Share on other sites

  • Replies 119
  • Created
  • Last Reply
Ами като начало защото географски най-близката точка до всички участници в спора се пада някъде в Лондон или Париж :)

Е-е-е ти сега - хем сърби, хем боли. Толкова приказва за тия кебапчета, пък сега бягаш от идеята.

Link to comment
Share on other sites

Ами като начало защото географски най-близката точка до всички участници в спора се пада някъде в Лондон или Париж :)

 

Виж сега, идеята е хубава, ама предложените места не са много подходящи за мероприятието. Според скромното ми мнение местата са две: или Белгия, където може да се опита най-невероятната бира на тази планета или Лазурния бряг (по-специално Кан, Антиб или Монте-Карло), където обстановката е особено предразполагаща за дълго философстване. В краен случай резервен вариант се явява Прага. Аз лично това лято съм много зает, ама догодина смятам да отскоча натам. ;) :)

Link to comment
Share on other sites

Е-е-е ти сега - хем сърби, хем боли. Толкова приказва за тия кебапчета, пък сега бягаш от идеята.

 

Аааа никакви проблеми, казвай кога и отиваме. Днес половината ден отнесох в спане но по-късно евентуално мисля да се завъртя към картинга малко да си направя кефа...

 

Виж сега, идеята е хубава, ама предложените места не са много подходящи за мероприятието. Според скромното ми мнение местата са две: или Белгия, където може да се опита най-невероятната бира на тази планета или Лазурния бряг (по-специално Кан, Антиб или Монте-Карло), където обстановката е особено предразполагаща за дълго философстване. В краен случай резервен вариант се явява Прага. Аз лично това лято съм много зает, ама догодина смятам да отскоча натам. ;) :)

 

В Белгия не съм бил но жената и без това ме дърпа да ходим някъде в тази посока. Обаче горещо препоръчвам Пражката бира - невероятна е!

Link to comment
Share on other sites

Аааа никакви проблеми, казвай кога и отиваме. Днес половината ден отнесох в спане но по-късно евентуално мисля да се завъртя към картинга малко да си направя кефа...

В Белгия не съм бил но жената и без това ме дърпа да ходим някъде в тази посока. Обаче горещо препоръчвам Пражката бира - невероятна е!

Ми от аз съм на 10 минути пеша от картинга - в другия край на парка, но трябва да дойдат Карман и Теди, защото вие сте основните фигури в спора. Кръсника много далеч, но може да направим протокол на спора и да му го дадем :) за да се изкаже и той по него :). Аз може да съм рефер ;), макар да съм малко пристрастен към някои от идеите в спора.

Link to comment
Share on other sites

Не твърдя ,че съм голям програмист ,нито ,че познавам 10+ езика , имам опит с PHP от около 4-5 месеца (почти изцяло практически задачи ) . Относно този език мога да кажа едно :

Тъй като езика е прекалено лесен за научаване и използване , мързелите ( като включвам 95% от българите ) го пишат по възможно най-грозен начин и ,ако искаш да прочетеш кода ще трябва да хвърлиш бая нерви за да разбереш какво иска да направи самия скрипт. Повечето уроци които виждам из интернет са без почти никаква умисъл за повторно използване както и много слаби възможности за разширяването им. И тук на помощ идва обектно-ориентираното програмиране , е да ама не . Като видиш цяла таблица написана в самия клас с безброини echo-та по едно време ти писва.

Независимо от това ,че PHP ми е любимият език той има още много път да извърви докато стигне Java като започнем от типизирането до обектния модел и никой не може да ми докаже обратното .

 

Смятам ,че програмист който поне познава MVC и пише според този модел ( дори и да не е с класове ) стига до много по-висока продуктивност и ниво на повторно използване на кода много лесно.

 

djadomraz, като човек с по-голям опит в сферата постни един клас (функция ,ако искаш ) от някой примерен модул да видим програмиране на малко по-високо ниво , за да сравним със скриптовете които се роят из интернет , за да могат всички да си направят сметката как някои немърливци пишат глупави неща ,нищо ,че работят.

 

Edit: Искам да попитам някой знае ли дали има книги или някакви статии които показват начин по който трябва да се изгради една обектно-ориентирана апликация с PHP ? Имат ли стандарт по който се водят добрите програмисти ?

Link to comment
Share on other sites

Самият факт че си стигнал до извода че MVC или DAL/BLL/UI е верния избор говори че имаш нещо повече от страница която показва "нещо", евентуално и записва друго "нещо" някъде - вероятно в база данни mySQL... A щом се е стигнало до нещо по-сериозно почваш да усещаш недостатъците на скриптовете - като начало това че не се компилират, липсата на строги типове и т.н. Отделно че мен лично ме дразни писането на $ пред всяка променлива.

 

Примерен модул няма как да ти дам, мога да ти дам примерен проект (VS solution) с няколко layer-a в него - DAL, BLL и UI като UI има за web има и за PDA. Само че това не е на PHP а на C# (.net). Tedy може да ти покаже нещо по-добро написано на PHP, но пак стигаме до това което казах по-горе а караман уточни че всичко зависи от програмистите... и все пак след като с даден език могат набързо да се сглобят нещата (колкото и некадърно да бъде, но все пак работи) почва да се изгражда една такава народопсихология като при VB. Не че VB е толкова лош като език, просто се натрупаха прекалено много кофти примери и всички новобранци като захванат да ползват гугъл намират главно кофти написаните неща и ако няма някой който да преглежда буквално всеки ред код който са написали работата почва да отива в киреча.

 

Работил съм върху доста обемисти проекти и мога най-отговорно да заявя че е доста по-различна ситуацията дали си работил по 1 голям проект в продължение на 2 години или си опукал 20 малки за същото време. От 20те я научиш нещо я не, най-вероятно ако си малко по-умен ще си направиш някакви функцийки и ще си ги ползваш, докато при големия проект след като промениш 2-3 екрана поне едно 20тина пъти и добавяш нови и нови неща в един момент ще се научиш какво е важно когато програмираш (и определено не е дали кода се изпълнява за 0.2мс или 0.8мс освен ако не пишеш търсачка или нещо друго което ще се вика стотици пъти в секунда най-малко). Защото ако имаш някаква цапаница ако ще и да работи ултра бързо следващия път когато ти се наложи да промениш нещо дребно вместо за минути ще трябва да го правиш дни (включвам и дебъгването) освен ако не изкараш късмет и да е наистина много ама много дребно.

 

И въпреки че на C# и Java са по-удобни билиотеките и за новобранци е по-практично да програмират на тях а не на С++ където като нищо ще се оплетат с поинтерите и кода ще е пълен с memory leaks и null pointer references, определено на С++ за сериозен код е по-удобен най-малкото защото се компилира native а и няма шантави garbage collectors които да правят каквото и когато им скимне а обект като излезе out of scope се унищожава моментално а не да чака на въпросния garbage collector да му дойде кефа...

Link to comment
Share on other sites

Прав си. Донякъде (Визирам ShitHappen, защото Djadomraz е писал междувременно).

Това че е лесен е някаква спекулация за мен. Че то аз основите на C# ги научих за не повече време отколкото основите на PHP, ако е за въпрос.

ColdFusion се води по-лесен, но повечето нови програмисти на пхп дори не са чували за него.

Леснотата е само в началото :bgrin: . Изкарването на таблица от БД на екрана и обновяването на запис чрез интерфейс е практическа задача, достатъчно лесна за всеки начинаещ дори. Но начинът, по който е реализирана може да се различава драстично :) Тук идват разликите. И на по-сериозен език могат да се направят грозни изпълнения :) . PHP просто ги прави по-лесни за изпълнение хехе.

 

Та в PHP липсата на строги типове като че ли е най-често изтъкваната причина за леснотата му. Уж. Е, заедно може би с това, че е близък с C, и други C-базирани езици и че е взел туй онуй от доста от тях.

'Релаксирането' на езика откъм строгост само по себе си предполага че ползващите го няма да спазват нивото, присъщо на по-'нормалните' езици така да го кажем.

 

И следва да отбележим, че дали е лесен или не, не е много показателно. Той си е нормален скриптов език, с него и десктоп програми могат да се правят, това си е език като език, не бих казал че се учи трудно или лесно, по-важното е какво правиш след това с неговите средства. Всеки език си има трудни аспекти. PHP има повече от ония елементарни бих ги нарекъл глупости, с които трябва да си запознат, в какви ситуации какви типове кога се използват или преобразуват, и всякакви подводни камъни от елементарно естество. Повечето свързани именно с 'предимствата му за начинаещи'. Тук и Дядо ви Мраз неведнъж се е изказвал :) .

Тия неща се научават естествено.

 

PHP не е изграден като някакъв фреймуърк както .NET, затова @ShitHappen, трябва да отчитаме това, че на един или друг етап ще имаме или echo на хтмл код, или най-малкото някакви темплейт файлове, в които или отново някак наслагваме с код някакъв хтмл, или правим нещо като str_replace на placeholders. Smarty naprimer. Тук вече е въпрос как ще си структурираш изхода, дали ще ползваш темплейт система, или собствена по-проста разработка с темплейти.

И аз имам един голям табличен модул, пълен с echo-та на таблица/и или конструкции, излизащи от php mode, но това не е толкова важно в случая. Важното е че тази таблица е параметризирана максимално, и с темплейт сложността би била същата, ако не и по-голяма. Аз лично не срещам трудности да си го усъвършенствам модула.

Как ще output-неш таблица, в която по сложен начин се определя къде какви колони ще има, какви редове, алтерниране на класове на редовете, имам и доста callbacks функции, които определят изхода, и т.н.? Все на някакъв етап ще има echo или някакъв код, бил той пхп или псевдокод, какъвто има Smarty (от който нуждата според мен е не много голяма - доста от конструкциите му са си чисти аналози на същите от PHP, само че написани едва ли не с нов език?! ). Както и да е.

 

Ако ползваш някоя голяма и тромава framework, в нея са скрити повечето от тия неща, така че за теб остава повечето от бизнеслогиката само.

 

Не отричам, че доскоро и аз пишех доста грозно :) . Но вече си имам някаква база, която надграждам, доста идеи взимам и от .NET. Наистина най-важното е модулирането на кода, и въпреки, че ОО в ПХП се води бавно работещо, аз лично всичко каквото се сетя го вкарвам в класове и наследявания (вече).

ОО-то в ПХП5 е от доста по-голяма полза да се избегне ужасяващото смесване на пхп и хтмл. Но тотално избяване няма така или иначе. В .NET има, но от определен момент и там се налагат подобни изпълнения, но там те могат да се постигнат с по-добрите средства на езика (тук Дядомраз е по-навътре).

IPB например немалка част от хтмл/цсс го държи в базата! :) Така са сметнали за по-ефективно.

 

За уроците по интернет, тях никой не ги гледа сериозно, те са за човек който тепърва чува за php и изобщо не се е занимавал с програмиране или с уеб-такова.

 

Доста роман се получи, просто малко размисли на глас, възможно е да бъркам някъде или пак да имам недомислие, но тази тема е почти като вечния спор за win vs lin, и колкото и да си говорим тук, ситуацията с PHP е такава каквато е, и всеки ще си продължи да си го ползва както си знае или да се развива както намери за добре или както му поднесе живота. Аз лично усещам, че да си се занимавал все пак с повече от един език (PHP) винаги е от полза. А в ПХП определено използването на похвати и добри практики от други езици може да подобри нещата значително.

 

 

Един-два примера (с които аз лично съм си много доволен как се получиха).

Възможностите на PHP за работа с времена и дати. Безсмислено е да описвам колко 'грозно' се работи с тях в PHP. И ограниченията, вкл. с т.нар. Unix Epoch. Да не говорим ако се опиташ да сметнеш някаква разлика между две дати, да вадиш две unix epoch стойности, да делиш, умножаваш.., да се чудиш как да представиш и смяташ дати, по-малки от някъде 1903-та година. Или по-големи от 2037-ма (или там където свършваше максималното 32-битово число със знак). Да не говорим, че преди ПХП5 беше ДОСТА рисково да работиш с дати < 1970-та.

.NET в това отношение е доста напред (разбира се). Има няколко класа за целта, направени много добре, и с тях си смяташ всякакви неща с дати. Да не говорим за полезния Timespan, който в PHP аз лично разширих да работи И с месеци и години, което в C# го няма :) .

Подобни класове си написах за PHP и вече датите не са проблем никакъв, даже автоматично се взима таймзоната на юзъра на сайта и всички времена той ги вижда в неговата зона, също и парсването на времена става спрямо неговата зона. Вътрешно всичко се пази UTC.

 

Стринговете. Тук мизерията е пълна. Осоебно с имената на ф-иите. Отново, един (е, малко големичък) клас за всякакви операции със стрингове, utf8-aware.

Дори за не-утф8, аз вече не ползвам strlen(), а примерно Strings::Length(). Какво е това strcmp()... , нека да е Strings::Compare(), както е в .NET :) (или нещо подобно).

 

ПХП не е лош, стига да си повържеш гащурите :bgrin:

Link to comment
Share on other sites

Абе то ако си вържеш гащурите всеки език може да се каже, че е хубав. Въпроса е първоначално колко са ти развързани и колко неща ще се омажат преди да си ги вържеш качествено. ;)

Link to comment
Share on other sites

Аха. То на теория С# може да се разглежда просто като език за програмиране и е въпрос на компилатор да се подкара на VAC машини с някоя антична UNIX отдолу. Само че на практика няма достатъчно луди с прекалено много излишно време за да го направят. Пък и след като има java за какво им е... отделно не мога да не отрека че некадърниците от Oracle допринесоха доста за лошата слава на java-та и че всичко писано на java работи страшно тромаво...

 

И между другото тъй и тъй пак минахме offtopic - имах едно време тестови програмки на C++ и на Pascal и интересно тези на Pascal-a работеха по-бързо не заради компилатора ами защото библиотеките на Borland за Pascal бяха разписани основно на асемблер и ако не съчиниш безумно сложен алгоритъм за да се усети оптимизацията на компилатора на C++ повече обикновено на Turbo Pascal 5.5 програмите работеха по-добре от подобни писани на Watcom C++, като пак уточнявам че не става дума за изчисляване на матрици а нещо с повече потребителски интерфейс или ползване на разните библиотеки.

 

Преди 15тина години бяхме писали с един приятел програма за генериране на кръстословици.. Borland Pascal 7... или може би е по-точно да се каже на асемблер защото като прехвърля какво сме писали май май повече сме писали на асемблер отколкото на паскал или са горе-долу на кантар като обем... Помня гледахме няколко конкурентни програми които работеха не в пъти по-бавно ами в дни. Като една-две евристики оптимизираха алгоритъма доста, останалото асемблера го правеше. Двете заедно на 386 DX генерираха кръстословица за минута-две ако е много голяма до 10, а конкурентните програми работеха така: пускаш днес, става утре-другиден евентуално и то ако не го бараш компютъра много много междувременно. Не знам още ли я ползват въпросната програмка но 24часа, Стандарт, Демокрация (само в Дума не пробихме) и още една голяма маса списания за кръстословици я ползваха, включително няколко от авторите които правеха на ръка като те пишеха една част (все пак е по-лесно да се трие на компютър отколкото на лист с молив и гума) и оставяха малка част от думите да ги напасне компютъра.

 

Та пак да си дойдем на думата - лош език няма, има кофти написани програми и некадърни програмисти. Обаче както има една приказка - ако направиш уред който може да се ползва от идиоти, гаранция че главно идиоти ще го ползват - ето и примера с VB.

 

Друго нещо е че на някои хора (главно живеещи в Индия) буквално трябва да им се забрани да дават акъл как се правят нещата - най-фрапантния пример беше идеята "как се прави dataset paging със MSSQL Server 2000" (при който имаш select top x, не и LIMIT p,s като при mySQL), което според човека се прави така - генерираш временна таблица (tmp# с 1 поле "DisplayNum" или нещо такова което е identity или иначе казано autoincrement), копираш данните вътре после правиш select от тази таблица само на данните които те вълнуват... велика идея, а? А ако имаме 2,000,000 записа какво правим? Защото ако имаме 50 записа тъй или иначе ще ни е все тая. Отделно че да разглеждаш 2 милиона записа страница по страница по начало е тъпа идея и освен някакъв data harvester да ги обиколи всичките нормален човек най-много да погледне първите 5-10 преди да му писне. Другата брилянтна идея беше с 3 вложени select-а което така мощно ще натовари сървъра при големи обеми че не ми се мисли (по-добре от това с временната таблица но не особено). И мани другото ами разни новобранци като почнат да се чудят - питат гугъл, гледат първите 10 отговора и измежду тях главно подобни бисери...

Link to comment
Share on other sites

Като заговори за SQL (май темата пак ще се преименува на +/- на програмните езици и среди за разработка), надявам се не си от тези, които тотално отричат използването на индекси в базата данни. Че съм спорил и по такава тема. Аз съм за.

Link to comment
Share on other sites

Като заговори за SQL (май темата пак ще се преименува на +/- на програмните езици и среди за разработка), надявам се не си от тези, които тотално отричат използването на индекси в базата данни. Че съм спорил и по такава тема. Аз съм за.

 

Хахахаха има идиоти които смятат че индексите са вредни??? Хахахаха не мога да повярвам че има такива индивиди. Преди време като поех един проект от подобен серсем гледам че едно запитване работи към 40 секунди и понеже ми бяха дали негов email за да го питам ако имам въпроси му пиша дали има спомени колко бързо е работело защото да не би последните ми промени нещо да са прецакали нещата (а бяхма импортнали още 2-3 милиона записа) и човека ми отговаря че видиш ли той бил оптимизирал базата данни като създал 2 индекса (буквално 2 даже ми даде скриптовете за създаването им). След което ми светна лампата какво изобщо са правили, запретнах ръкави пооправих структурата на таблиците, създадох малко индекси (не много малко - едно 30-40 индекса имаше поне) и въпросното търсене вместо за 40 секунди почна да работи за 0.14 сек. По-интересното е че след като импортнахме още 12 милиона записа справката продължи да работи за горе-долу същото време (0.18 - 0.22 сек).

 

Да, не трябва да се прекалява с индексите особено пък ако са излишни и особено ако е система в която главно ще се вкарват данни и то автоматизирано (т.е. ако има огромна разлика дапи ще могат да се запишат 10 или 100 записа в секунда) но ако данните ще се вкарват от хора и справките са по-важни тогава се правят възможно най-много индекси - говоря за смислени а не буквално за всяко поле от таблицата да се направи индекс - виждал съм и такива тъпотии... изобщо трябва да се разбират нещата а не да се стреля на сляпо.

Link to comment
Share on other sites

Ами щом те питам, значи ги има :). На мен ми е попадала база данни където за primary key се използва char/varchar(10), и то като казвам primary key става въпрос, че просто полета бяха набедени за това, не ще имаха нещо като индекси или външни ключове. :) Иначе за използването на индекси е имало спорове колко глупави били и как тяхното използване било абсолютна ерес едва ли не.

Докато аз съм имал подобни примери като твоя заявка с и без ключ - разлика в пъти в скоростта и в хиляди пъти броя четения по таблиците.

Като говоря за бази данни имам предвид в Interbase/Firebird. С MySQL съм се сблъсквал малко, просто защото не ми се е налагало да работя с него. Фирмата където работя просто използват това СУБД.

Link to comment
Share on other sites

ключовете забавят вкарванията на mnogo данни, но и затова има лек pone na mysql

 

disable keys;

insert...;

...

...

...

insert...;

enable keys;

 

все пак enable/disable keys работят само за non-unique keys

 

Иначе е много важно да имаш правилни ключове за търсене.

MySQL се сеща за точния ключ по заявката.

 

Най-добрия съвет е да правите EXPLAIN SELECT;

Ако забележите using temporary table някъде където може да ползвате индекс, не се помайвайте

Link to comment
Share on other sites

Прав си за скоростта на вкарване. Във Firebird се създават автоматично индекси за всеки primary key, foreign key и unique. Та да ти кажа когато таблиците набъбнат - броя индекси става огромен. И пробваш ли да налееш наведнъж повечко неща....

И за съжаление тая екстра с изключването на индекси автоматично не съм разбрал да има. Виж на ръка, с някоя stored процедура, на която да подадеш за кои таблици да спре индексите по-може.

Link to comment
Share on other sites

Идеята при MySQL е, че генерирането на много индекси наведнъж е много по-бързо от всеки път след Insert

 

Колко си сигурен в това?

 

Всичко зависи от обема данни които ще вкарваш. Ако имаш таблица с 50,000,000 (петдесет милиона) записа вкарването на нови 1,000 (хиляда) моде да се окаже по-бързо от rebuild-ването на индексите за въпросната таблица, защото няма как да направиш "enable keys" и то магически да ги включи без да преиндексира всички данни в таблицата.

 

Всичко е според зависи и ако не си се олял с индексите вкарването дори на много данни няма да натовари особено базата данни... отделно че база данни която не е особено голяма влиза изцяло в паметта а напоследък паметта е евтина :) И не, не говоря за некадърните хостинг фирми дето на някакви антики хостват по 1000 сайта за по 5лв на месец там работата е за колкото плащаш толкова получаваш

Link to comment
Share on other sites

дам, не се изразих правилно, имах предвид доволно количество Inserts.

 

Зависи много от паметта и от настройките в my.cnf. Не съм си играл да benchmark-вам.

 

В много от случаите ми се налага да генерирам цели таблици от нулата с по 10-20 милиона записа и там използвам този трик.

Link to comment
Share on other sites

В този случай се прави структурата с минимално излишни неща, т.е. само необходимите индекси и foreign keys за да не вкарваме все пак произволни глупости или ако не са подредени както трябва данните и без тях даже. После след като вкараш данните правиш и индексите. Това си важи не само за mySQL само ами и за MSSQL, Oracle, Interbase/Firebird и т.н. и т.н. (Access и Paradox не ги броя за бази данни изобщо, Excel пък още по-малко.. не че няма идиоти да го ползват и него)

Link to comment
Share on other sites

понеже виждам че сте доста навътре в материала , някой може ли да ми реши следния проблем

имам

<input type="text" name="title">

.....

$Stext = mysql_real_escape_string($_POST['text']);

$sqlquery = "INSERT INTO lyric (title)

VALUES ('$Stitle')";

$queryresult = mysql_query ($sqlquery);

---------------------------

$query = mysql_query("SELECT * FROM lyric");

while($row = mysql_fetch_array($query)){

echo htmlspecialchars(stripslashes($row['title']));

---------------------

 

Проблме е , че ако в input-a ваведа a\aa\\aaa\\\aaaa

след това echo-то изкарва a\aa\aaa\aaaa

Link to comment
Share on other sites

Ами май трябва и да вкараш данните през фукнкцията, която добавя '\' към специалните сомволи. Как се казва не помня. А ти само махаш тези символи от резултата и затов ти ги реже. Поне аз така мисля.

 

Ако съм писал глупости, свиркайте да ги махам, че после да не ме броите сред ония в първите 10 страници от гугъл с глупавите идеи. :)

Link to comment
Share on other sites

Като начало Винаги ънескейпвай входящите параметри от $_POST/$_GET.

А дали да го направиш това се проверява с get_magic_quotes_gpc(). Това е една адски тъпа опция на php.ini, която много дразни. Защо по дяволите за всеки реяукест енджина трябва да предполага, че ще искам да вкарвам в БД, при това с addslashes() ?! Че и на доста хостове е включено тва.

Понеже по default ПХП е настроен (май последните версии не беше така..) автоматично да изпълнява addslashes() върху входните данни. И ти с mysql_real_escape_string() му правиш допълнителен ескейпинг. Познай на 3 наклонени черти двойното ескейпване до колко черти води в крайна сметка :) .

 

Още в началото ако get_magic_quotes_gpc() върне Труе, тогава правиш stripslashes() на $_POST променливата. После я мъсялреалесцапестринг-ваш и т.н.

 

	private static function _remove_magic_quotes($s) {
	if (get_magic_quotes_gpc()) return stripslashes($s);
	return $s;
}

public static function getString($p, $d=false) {
	if (isset($_REQUEST[$p])) {
		$ret = self::_remove_magic_quotes($_REQUEST[$p]);
		if (APP_IS_UTF8 && !Strings::isASCII($ret) && !Strings::utf8IsValid($ret)) $ret = $d;
	} else {
		$ret = $d;
	}
	return $ret;
}

Аз ползвам нещо такова в един клас. Редът с APP_IS_UTF8 за мен е legacy, понеже приложението може и да не е utf8, за някакви стари неща, игнорирай го.

 

Така получавам 'неопетнен' параметъра и нататък нормално си го escape-вам (ако ще влиза в БД).

Link to comment
Share on other sites

мисля че не си задодох правилно въпроса.

значи имам вавеждане от потребителя на a\a\\aa\\\aaa\\\\aaaa

то се ескеипва на a\\a\\\\aa\\\\\\aaa\\\\\\\\aaaa

и се въвежда в sql

 

и тук идва проблема,защото sql не ми връща a\\a\\\\aa\\\\\\aaa\\\\\\\\aaaa , а връща a\a\\aa\\\aaa\\\\aaaa

 

което като го stip-на и губя някои \ и става aa\aa\aaa\\aaaa а не това което е ваведено a\a\\aa\\\aaa\\\\aaaa

 

ето кода с който тествам

Link to comment
Share on other sites

не си разбрал правилно, ти правиш strip_slashes на изхода от mysql, а не трябва. При включен magic GPC (Get/Post/Cookie) strip_slashes се прави на входа на PHP скрипта, а после се прави mysql_real_escape_string на данните, които записвате в SQL

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...