- Csatába küldte Magyarországon idei csúcs hangprojektoros szettjét a Samsung
- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
Hirdetés
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
-
Saját Redmi Note 13 Pro+ a világbajnok focicsapatnak (és indiai rajongóiknak)
ma Argentína nemzeti válogatottjának mezével díszítik az új Redmi különkiadást.
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
Új hozzászólás Aktív témák
-
Taci
addikt
Sziasztok!
Remélem, tudtok ebben segíteni:
Adott egy időbélyegző, pl.:
$date = "Fri, 22 Jan 2021 17:36:10 +0100";Hiába a 17:36 a pontos idő, az időzóna (+0100) miatt valamiért "elszámolja" magát, és 1 órával kevesebbet ír ki, pl.:
echo date('H:i', strtotime($date));
azt írja ki, hogy 16:36.Wordpress alatti Phpmyadmin amúgy, de Wordpress-ben is jó időzóna van beállítva (UTC+1), illetve Phpmyadmin is a pontos időt adja vissza a
SELECT NOW()lekérdezésre.Oké, nyilván tudnám korrigálni úgy, hogy hozzáadok egy órát, de tudni szeretném vajon hol és miért megy félre a dolog, miért vonja le azt az 1 órát.
A forrás adott, tehát nem megoldás, hogy kiveszem belőle a " +0100" részt.
Köszi előre is.
-
Taci
addikt
válasz
pelyib
#20296
üzenetére
Szia!
Köszönöm a választ!
Egyelőre az időzóna beállítása a leggyorsabb megoldás, amit a kódban írtál is, és szépen működik is (ahogy a példádban is):
date_default_timezone_set('Europe/Budapest');Tesztelem, ha esetleg valami nem jól működne vele, akkor már megírtam a kód módosítását a
DateTimeImmutablehasználatával is.Köszönöm!
-
Taci
addikt
Sziasztok!
Adott egy adatbázis, aminek a tartalmát eredetileg csak 1 db JS-függvénnyel elérve írattam ki (PHP használatával).
Ott bőven elég volt awhile($row = $result->fetch_assoc()), mert ugye egyesével kiszedett minden sort belőle addig, amíg el nem fogyott. Tökéletesen megfelelt a célnak.Viszont kénytelen voltam módosítani úgy, hogy az első (eredeti) JS-függvény már csak az első pár sort írja ki (jelenleg 4-et), aztán a második (új) JS-függvény feladata pedig az lenne, hogy ahol az első függvény abbahagyta (a példánál maradva ugye az 5. jönne), onnan folytassa a kiírást (szintén 4-esével).
(Infinity scroll-t akarok használni, és ahhoz az kell, hogy előbb legyen annyi elem a képernyőn, hogy lehessen scrollozni (túlnyuljon a kijelzőn - erre állítottam be 4-et, mert az bőven kitölti majdnem 2szer is), aztán jön a 2. szkript, ami pedig a scrollozás mértékében fűzi hozzá a további tartalmat.)Így kétszer is megvan hívva ugyanaz a PHP fájl/kód, ezért jelenleg természetesen előröl kezdi a számozást, tehát a 0. elemtől, kiírja az első 4-et az első függvény miatt, aztán jön az infinity scrollozós szkript, és az is az első 4 elemet írja ki. Aztán scrollozok tovább, és újra az első 4-et.
Nem tudom, hogyan lehetne megoldani, hogy ahol az 1. függvény abbahagyta, onnan folytass a 2. Semmi tapasztalatom nincs ebben.
Keresgéltem, amit találtam, és talán ezt megoldaná az a PHP Session, viszont még a példakódban a példaoldalon sem működik (pedig egy nagyon jó és megbízható oldal, de ez már korábban sem működött nálam), így nem is implementáltam.
Gondoltam rá, hogy esetleg cookie-t kellene használni, de egyrészt sosem használtam még (ez nem gond, megtanulom), másrészt biztosan van egy egyszerűbb megoldás is erre.Remélem, nem túl bonyolultam írtam le, és főleg azt, hogy tudtok segíteni.
Biztos nagyon egyszerű a dolog, csak én nem látom már azt sem, ami a szemem előtt van.Köszönöm!
Még talán az
Include-ra nézek rá.[ Szerkesztve ]
-
Taci
addikt
válasz
pelyib
#20318
üzenetére
Igen, néztem, de sajnos nem járható út. Kb. úgy képzeld el az oldalt, mint a Facebook-feed-et, egymás alatt "ömlesztve" a tartalom (nyilván szűrve és rendezve). Ezt sajnos nem tudom oldalakba szedni.
@sztanozs:
Köszönöm, már nézem is. Most hirtelen legjobb leírásnak példákkal ezt az oldalt találtam:
https://www.sqltutorial.org/sql-limit/
Ha elakadnék, és nem bánjátok, még kérdeznék.Köszönöm!
Illetve máris kérdeznék:
"csak kell egy prepare persze még bele"
Ez a rész pontosan mi és mire kell? Ez lenne az?
https://www.w3schools.com/php/php_mysql_prepared_statements.asp[ Szerkesztve ]
-
Taci
addikt
válasz
sztanozs
#20319
üzenetére
kell egy prepare persze még bele
Ahh, annyit szenvedtem vele, hogy végig hibaüzenetet dobott (Call to a member function bind_param() on bool), mert nem tetszik neki a lekérdezés. De nem tudtam rájönni, mi a baja, mert adatbázisban futtatva (és a "?" paramétereket átírva persze) tökéletesen futott.
Aztán így 2 óra szenvedés után végül arra jutottam, hogy teljesen lecsupaszítom és visszakövetem a kódot, és végül rájöttem, hogy táblát nem lehet paraméterezni, azon halt el végig...
"SELECT * FROM ? ORDER BY ? DESC LIMIT ? OFFSET ?"Ott FROM utáni paraméternél csúszott el. De így végre megvan.
De így összerakva már működik az infinity scroll-szerű megoldásom is. Így már ezt el tudom tenni, hogy oké, van egy működőképes változatom (erre a kérdéskörre), így nézhetem a pagination-t, és ha azzal nem menne (valamiért), akkor erre vissza tudok állni.
Milliószor akartam írni, segítséget kérni (ebben a prepare-es elakadásban is), de örülök, hogy végül nem tettem, és magamtól találtam rá a megoldásra, így sokkal jobb tapasztalat.
Köszönöm az iránymutatásotokat!
-
Taci
addikt
Lenne ismét egy kérdésem, ami a tapasztalatlanságomból ered.
Nyilván mind a pagination-nek és az infinite scroll-nak is át kell adnom, hogy mennyi elemmel fog dolgozni, hogy feleslegesen már ne próbáljon meg sorokat betölteni, ha egyszer elfogytak.
Jelenleg a php kódban csak annyi van, hogy
if ($result->num_rows > 0) {// a tartalom megjelenítése} else {echo "Elfogytak az elemek."; // random szöveg csak magamnak}A JS függvény pedig újra és újra visszatér, hogy (jelenleg négyesével) betöltse az új sorokat. Egy idő után viszont elfogynak, viszont a JS függvény ilyenkor is kapcsolatot létesít, megtörténik az SQL lekérdezés is - szóval ez már csak forráspazarlás. (Még ha szemmel ez nem is látszódik, ha remarkolom az "Elfogytak az elemek" echo-t.)
Így hát arra gondoltam, hogy ha már a JS pont ezt a PHP kódot hívja meg, amiben az SQL lekérdezés is van, így át tudom adni neki, hogy a lekérdezésben mennyi sor szerepel, így a JS-ben be tudom állítani, hogy ha a végére ért, akkor ne kérdezzen többször.
Na igen ám, viszont a lekérdezésbe ugye belekerült a LIMIT is (jelenleg "LIMIT 4"), így a sorok számára mindig 4-et ad vissza (kivéve, amikor már nincs annyi benne vagy teljesen elfogytak belőle).
$sql = "SELECT * FROM table ORDER BY order_by DESC LIMIT x OFFSET y";(csak a példa kedvéért így írva most, mert amúgy prepare-rel van)Szóval ezt hogyan lehet szépen és hatékonyan megoldani?
"Tudja" ez a lekérdezés, hogy eredetileg milyen sorokat tartalmazott, mielőtt alkalmazta volna a LIMIT-et és a többit?
Ki lehet belőle szedni valahogy csak aSELECT * FROM tableértékét?Vagy mindenképp kell egy külön lekérdezés?
Már erre esetre is megvan a tervem, csak hátha van erre valami egyszerűbb, jobban bevált módszer. Mert ha máshogy nem, akkor megcsinálom a külön lekérdezést, és csak akkor újra futtatom le újra (ezt a külön lekérdezést az eredeti, "szűretlen" méretről), ha a "table" értéke változik. A többi nem fog változni, a table viszont elég gyakran.Köszi!
[ Szerkesztve ]
-
#20327
Taci
addikt
instantwater
#20326
Taci
addikt
válasz
instantwater
#20326
üzenetére
Köszönöm a gyors és hasznos választ!
Kialszom magam, és holnap munka után újra nekiülök, átnézek minden lehetőséget. -
Taci
addikt
Sikerült megoldani, köszönöm!
Viszont lesz még egy kérdésem ezzel kapcsolatban, de azt egy külön kommentben tenném majd fel, mert egy picit hosszabb.
Itt viszont még megkérdezném ezt:
Van több elem a lapon (0-tól végtelenig), és mindegyik bejegyzésnek van egy időpontja, amivel számolnom kell. Szeretném mindegyiknél pontosan kijelezni, hogy mennyi ideje lett bejegyezve. Ez a számolás már nagyon szépen megvan PHP-ben végig vezetve. Viszont fix időponttal számol, amikor betöltődik az oldal, azt veszi "most"-nak, azzal számol, azt jelzi ki.
Viszont szeretném az aktuális időhöz igazítani (elég a kliens ideje, nem kell time server).
Így arra gondoltam, hogy miután kijelzi az időpontot a PHP kóddal, utána simán csak futtatok egy JS szkriptet, és másodpercenként emelem az időpontot 1 mp-cel. És így úgy-ahogy meg is vagyok, az ebben lévő pontatlanság bőven megfelel a célnak. (De időközben rájöttem, hogy az egész formázós PHP kódot kell hogy futtassam külön újra és újra...)Találtam is egy egyszerű példát ehhez, amivel tudok dolgozni:
https://www.w3schools.com/js/tryit.asp?filename=tryjs_setinterval2Szépen is működik, csak előjött egyből az a gond, hogy csak az első elemnél csinálja meg ezt a frissítést (és a saját kódomban csak a következő 4 elem betöltése után indul el, első betöltésre nem - de ez majd kifilózom logokkal, hogy miért) , az összes többinél már nem.
Tehát ha a példakódban pl. még pár sorba beszúrom hogy<p id="demo"></p>, akkor is csak az elsőnél történik meg a frissítés, ott fut le a szkript.
Pedig azt szeretném, hogy több helyen is lefusson, bárhol, bármikor.Rátaláltam az infóra, hogy HTML-ben az ID-knak egyedinek kell lenniük, így a fenti példakódnál csak az első "demo" ID-t használja, utána már nem valid. A getElementById így nem jó. Esetleg valami más getElementBy?
Hogyan tudom ezt megcsinálni, hogy az összes bejegyzésnél fusson a szkript, ugyanaz a szkript, de persze mindegyiknél a saját adatokkal?Köszönöm!
-
Taci
addikt
Azt mondjátok meg, kérlek, hogyan lehet PHP-ből adatot átadni JS-nek?
Adott egy JS, amiben egy XMLHttpRequest-tel adatot küld a szervernek, és válaszként (this.responseText) megkapja a megjelenítendő HTML kódot.
Ugyanebben a PHP fájlban generálódik a tegnap tanácsolt módon a lekérdezett adat sorainak mennyisége is.
$number_of_query_items = $result_count->num_rows;
Ezzel az adattal kellene az említett JS-ben számolni, átadni a JS-ben szereplő változó értékének:var numberOfQueryItems;Viszont nem tudom, hogyan kell átvinnem PHP-ből JS-be. Az XMLHttpRequest miatt átmegy sok adat, de nem tudom, hogy abból kellene-e valahogy kihalásznom ennek a változónak az értékét, vagy arra egy külön XMLHttpRequest-et indítani?
Nagyon nem találom a helyes választ rá, és ez megakasztott.
PHP-ben a változó, amit át kellene adni JS-nek:
$number_of_query_items = $result_count->num_rows;JS-ben a PHP kóddal kommunikáló rész (leegyszerűsítve):
var numberOfQueryItems = 0;if (window.XMLHttpRequest) {// code for IE7+, Firefox, Chrome, Opera, Safarixmlhttp=new XMLHttpRequest();} else { // code for IE6, IE5xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");}xmlhttp.onreadystatechange=function() {if (this.readyState==4 && this.status==200) {document.getElementById("output").innerHTML=this.responseText;}}xmlhttp.open("GET","frontend.php?q=" + valtozo,true);xmlhttp.send();Ezen a kódon keresztül kellene? Vagy más módja van ennek?
Az kellene, hogy a PHP kódban szereplő
$number_of_query_itemsértékét megkapja a JSvar numberOfQueryItemsváltozója.Hogyan tudom ezt elérni?
Köszönöm!
-
Taci
addikt
@coco2, pelyib, instantwater: Köszönöm szépen a tanácsokat!
Van minek utána néznem... Igazából 0-ról kezdtem már egyből ezzel az ötlettel, amit próbálok megvalósítani, és a w3schools oldaláról kezdtem tanulni. Ha valami probléma jött fel, elsőnek ott kerestem választ, aztán Stackoverflow, aztán Google, aztán itt.
De elég sok mindent át kell írnom akkor ezek szerint.
Ez a Moment.js nagyon hasznosnak tűnik, ugyanezt programoztam le PHP-ben, csak ott azzal bajlódtam a végén, hogy folyamatosan frissítse az adott elemen az időt (ahogy írtam is lejjebb). De ezzel egyszerűbb lesz sokkal, úgy látom.Az axios alatt gondolom, ezt értitek: https://github.com/axios/axios Még csak soha nem is hallottam róla (ami nem meglepő, kb. 2 hónapja írtam először HTML kódot is...
). Remélem, hamar rájövök, hogyan tudom a mostani kódot átírni úgy, hogy ezzel működjön.
Ha jól értem, akkor ehelyett:var numberOfQueryItems = 0;if (window.XMLHttpRequest) {// code for IE7+, Firefox, Chrome, Opera, Safarixmlhttp=new XMLHttpRequest();} else { // code for IE6, IE5xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");}xmlhttp.onreadystatechange=function() {if (this.readyState==4 && this.status==200) {document.getElementById("output").innerHTML=this.responseText;}}xmlhttp.open("GET","frontend.php?q=" + valtozo,true);xmlhttp.send();kell valami ilyesmire átírnom:
const axios = require('axios');// Make a request for a user with a given IDaxios.get('/user?ID=12345').then(function (response) {// handle successconsole.log(response);}).catch(function (error) {// handle errorconsole.log(error);}).then(function () {// always executed});Aztán akkor még át kell írnom azt is, hogy a szerver asszociatív tömbben küldje át a megjelenítendő weblaprész adatait, plusz az egyéb változókat, amire szükség van.
https://www.w3schools.com/php/func_json_encode.asp
https://www.w3schools.com/php/func_json_decode.asp
Mondjuk még nem igazán látom át, a mostani kódból hogyan kell a kívánt eredményt létrehozni, de remélem, rájövök. (Ha esetleg mégsem, kérdezek majd. Bár nem szeretek, csak ha nagyon muszáj.)Nem egy pár órás munka (nekem), de remélem, boldogulni fogok.
Köszönöm a tanácsokat még egyszer!
[ Szerkesztve ]
-
Taci
addikt
Akár egész weblapot is leküldhetsz. Azzal az a trükk, hogy fogod az egész weblap stringet, és base64 encode-olod.
Ebben kérnék most segítséget.Adott egy PHP kód, amiben megtörténik a lekérdezés az adatbázisból. Ez a PHP kód require-rel behúz egy külső HTML fájlt (
require 'feed_item.html';) , amiben vannak PHP kódrészletek, oda tölti be a lekérdezésből származó adatokat. Aztán ez az egész megy (jelenleg) a kliensnek megjelenítésére.Hogyan tudom ezt a lerkédezésből származó kóddal feltöltött, külső fájlból behúzott HTML kódot asszociatív tömbbe rakni?
Maga a tömb:
$website_data = array();$number_of_query_items = $result_count->num_rows;$website_data['numberOfQueryItems'] = $number_of_query_items;//$website_data['content'] = ide jönne az adatbázisból feltöltött html kód$website_data_json = json_encode($website_data);Köszönöm!
-
Taci
addikt
Nem örököltem meg semmit.
Volt egy ötletem (weboldalra), elkezdtem hát nulláról tanulni, mit-hogyan kell megcsinálni, így jutottam ide. Szóval igazából amiket írtok, az nekem teljesen ismeretlen, úgy olvasok utána mindennek. Ez a betöltött fájl amúgy eredetileg php volt (az is még eredetileg a "fő php" kód része, de gondoltam, "szebb" külön szedve, ezért jött a required), viszont minden sort
echo '-val kezdtem (és';-vel zártam) aztán később olvastam, hogy az úgy nem "szép", szóval maradt a html kód, és ahova adatbázisból kellett érték, oda került csak bele a html kódok közé a php kód (<?phpés?>közé). Aztán mivel így már igazából html kód lett, átneveztem .php-ről .html-re.
Itt a leírásod alapján akkor nem jó a file_get_contents(), hiszen van benne szerver oldali (php) szkript.Na de próbálok utánaolvasni mindennek, amit írtál, és megnézni, ezt én hogyan tudom megoldani "nálam".
Köszönöm.
-
#20352
Taci
addikt
instantwater
#20351
Taci
addikt
válasz
instantwater
#20351
üzenetére
Hmm, most hogy így mondod, az is bőven jó lenne akkor, ha a szerver csak a bejegyzésekhez kapcsolódó adatokat küldené át (aktuális bejegyzés képének linkje, bejegyzés szövege, bejegyzés időpontja stb.) (és ezeket az adatokat sokkal egyszerűbben is lehetne átadni asszociatív tömbbel), aztán ezt a kliens rakná össze egy JS-tel lokálban generált HTML kóddal? Teljesen felesleges ugyanazt a fix html kódot utaztatni szerver és kliens között, az mindig ugyanaz, nem változik, csak az a pár bejegyzésenként módosuló változó.
Ez esetben pedig akkor vagy a JS-be kell "beleégetni" a html kódot, vagy itt is lehet külső fájlból, gondolom. Na ezeknek mind utána nézek most, hogyan lehet, hogy a jobb. Köszi a rávilágítást, erre nem is gondoltam még eddig! (És ha most is rosszul, kérnék egy kijavítást. 
) -
#20354
Taci
addikt
instantwater
#20353
Taci
addikt
válasz
instantwater
#20353
üzenetére
Nem, ez egy teljesen saját, 0-ról kezdve, üres lapról (plusz egy HTML template-ről). Egyelőre csak egyetlen egy oldal, két oldalon és felül fix "kerettel" (opciók, menük, kereső stb.), középen pedig egy "feed", ahova folyamatosan tölti be (görgetéssel) a bejegyzéseket.
Igazából nem értek semmihez sem, de programozni szeretek, és ebben a "projektben" is kellett rengeteget HTML-lel, CSS-sel, PHP-vel és JS-tel foglalatoskodnom, amit amúgy élvezek is.
A korábban ajánlott Moments.js helyett is inkább megírtam magamnak az időbélyegző formázó kódját - addig is gyakorolok. Úgyhogy megpróbálom ezt is. Köszönöm! -
#20356
Taci
addikt
instantwater
#20355
Taci
addikt
válasz
instantwater
#20355
üzenetére
Nem, dehogy.
Úgy értettem, hogy keretbe foglalják a tartalmat (a feed-et). -
Taci
addikt
Tegnap este (vagy ma hajnalban, már nem emlékszem, összefolynak az órák) a PHP egyszer csak "elfelejtett magyarul", nem kezeli az ékezetes betűket.
Korábban tökéletesen működött, de mostanra megkergült. Adatbázisba is rosszul (csúnyán, ékezetek nélkül) ír be, és a logot is teljesen elrontja.
Nem változtattam semmit a kódnak ezen a részén. Ami pl. eddig fixen bele volt égetve a kódba, hogy írja a logba azt, hogyKiválasztott elem, az mostKiválasztott elem.
Kategória --> KategĂłria
kép --> kĂ©pPHP version 7.3.1
A gyakorló teszt szerveren ez van. Lehet ez a régebbi verzió az oka? Bár nem tudom, akkor eddig miért működött, és most miért nem.
Óraátállítás? Más nem jut eszembe.Hátha nektek van ötletetek.
Köszi. -
-
Taci
addikt
válasz
nevemfel
#20501
üzenetére
DesktopServer-t használok a tesztek és a fejlesztés időszakára.
Azt vettem észre, hogy talán onnantól ment félre a dolog, hogy beletúrok egy-egy link forrásfájljába, hogy kiszedjek pár infót belőle.
$all_lines = file($feed_item_link);foreach ($all_lines as $line_num => $line) {$keywords = '"keywords" content="';if (!empty(strpos($line, $keywords))) {$keywords_strstr = strstr($line, $keywords);$keywords_strstr_substr = substr($keywords_strstr, 20); //ennek a hossza: "keywords" content="$keywords_closing_stripos = stripos($keywords_strstr_substr, '"');$keywords_result = substr($keywords_strstr_substr, 0, $keywords_closing_stripos);$return_keywords_link = $keywords_result;$return_keywords_link = str_replace(", ", ",", $return_keywords_link);}}Ha ékezet nélküli adatot szedek ki (pl. linket), akkor nincs gond, ez a fenti kód tökéletesen működik. (nem pont ugyanez a kód, de a lényege ugyanez, csak más string-re keres, és nincs a végén replace)
Viszont azt vettem észre, ha van benne ékezet, akkor az egész kuka, a logtól az adatbázisig minden.Fura ami itt történik, mert pár bejegyzésre a PHP error.log-ja ezt dobja:
PHP Warning: file(https://index.hu/techtud/2021/03/27/allatok-oroszorszag-leopard-nagymacska/): failed to open stream: HTTP request failed!
A link srting-ként van átadva, szóval ez a valóságban file("link")-ként néz ki, de így logolja valamiért. Egyik csatornán működik mindre, másik csatornán mindig csak az első 21-re. Már a hajam tépem, nem értem.
------------
Szóval igazából ez 2 probléma:
1) Ha ékezetes tartalmat szedek ki, az hazavágja a logot és az adatbázis ezen részét is. De ez sem mindig, mert láttam már ékezetes tartalommal a logot és az adatbázist is. De valamiért valahol néha hibázik, csúnyán.2) Az
$all_lines = file($feed_item_link);nem mindig ad vissza eredményt. Lehívom 60 linkre, abból 21 jó lesz, a többi nem. Lehívom a rosszul sikerült 49-re, abból 21 megint jó lesz.
De ugyanez egy másik csatornával (Index.hu helyett Origo.hu) meg csont nélkül viszi az összeset elsőre.[ Szerkesztve ]
-
Taci
addikt
válasz
nevemfel
#20504
üzenetére
Na visszamentem szinte nullára, teljesen más irányból közelítettem, de a vége így is ugyanaz:
az Index-től csak 21 link tartalmát tudom leszedni egyszerre. Az Origo-tól az összeset.Egy kicsit részletesebben:
Az Index RSS feed-je 60 elemet tartalmaz, az Origoé 50-et. Ezeken én egyesével végigmegyek, a file() funkcióval pedig mindegyiknek a tartalmán.
Na az Origo az hagyja mind az 50 link megnyitását és szétszedését, de az Index 21 után "letilt".Bele raktam ezért 20-hoz egy 60 mp-es várakozást (sleep(60)), és utána hagytam folytatni. Ekkor már 26-ig ment el az Indexnél.
Aztán ezt a várakozást átállítottam 120 mp-re, és így végig ment az összes Indexes elemen is.Szóval a legtöbb problémát ez okozta, 1 teljes napom ráment ezt az Indexes "limitet" felderíteni.
Ezt hogyan lehet a legjobban kezelni? Van rá mód megállapítani, hogy hol van ez az Indexes "határ", hogy ki tudjam centizni?
-
Taci
addikt
válasz
nevemfel
#20506
üzenetére
Igen, ilyesmi lehet. Most még 20mp / 20 lekérdezésen hagytam, de megnézem úgy is, ahogy mondod, hogy minden lekérdezés között 500-1000 ms, hátha annyi is elég.
Még egy korábbi témában viszont muszáj vagyok segítséget/tanácsot kérni:
Újra elő jött a össze-vissza karakterezés (az ékezeteseken).
Jelenleg 2 típusú sorból szedem össze a szükséges adatokat:1)
<meta name="keywords" content="mexikó, repülőgép, baleset, külföld" />2)
<script>window.exclusionTags=['hamisítás', 'konténerhajó', 'hamis termék', 'Szellemi Tulajdon Nemzeti Hivatala'];</script>Az első eredménye a
mexikó,repülőgép,baleset,külföldsztring, a második pedig ahamisítás,konténerhajó,hamis termék,Szellemi Tulajdon Nemzeti Hivatala.Ahogy ezek bekerülnek a logba (és az adatbázisba), máris borul minden, a log korábban helyes ékezetes betűi is össze-vissza lesznek.
Hogyan tudom ezeket úgy átadni, hogy ne zavarjanak be? Valószínűleg a karakterkészlettek kell bűvészkedni, de nem tudom, hogyan, mert azt sem értem, egy korábban jól működőt hogyan ronthat ez el.
Köszi.
-
Taci
addikt
Azt látom, hogy a log fájl UTF-8 kódolásról indul, aztán amikor ezek a sorok belekerülnek, már ANSI-ra vált.
Átírtam mindkét sztringes részt arra, hogy
utf8_encode-dal adja vissza az eredményét.Pl.:
$return_keywords = utf8_encode($return_keywords);A visszaadott sztring még most sem jó
rendÅrség,pénzmosás,csalás,pest megye,bűncselekmény,eljárás,belföld
viszont a log fájl már UTF-8-as, és legalább a "belevésett" szöveget nem rontja már el.De hogy ezekkel a nem is tudom milyen karakteres sztringekkel mit lehet kezdeni...
ausztria,tirol,koronavÃrus,covid-19,teszt,külföldAztán kerestem, hogy mik lehetnek ezek a karakterek, és azt találtam, hogy pont hogy ezek az UTF-8-karakterek, így ezeket kell visszaalakítani. Így hát fogtam, és
utf8_decodesegítségével megnéztem, mire is megyek.Pl.:
$return_keywords = utf8_decode($return_keywords);Amennyit javított (a sztringek már egy fokkal szebbek, de még mindig nem jók teljesen, pl. az "ő" betű helyett "?" van:
mindeközben,percr?l percre,világmindenség,univerzum), annyit rontott is, mert a log fájl megint ANSI. Vagy már nem is tudom, mi-mi.
(kép -->kĂ©p, töltve -->töltve)Na ebben a karakterkészletes dologban most vagyok a teljes tanácstalanságnál.
-
Taci
addikt
válasz
SUPREME7
#20509
üzenetére
Ah, ez volt a megoldás, igazad van.
$return_keywords = mb_convert_encoding($return_keywords, "UTF-8");De nem is értem, mert az összes forrásfájl headerjében ott van, hogy
<meta charset="utf-8">Szóval így ez a kód UTF-8-ról UTF-8-ra alakít, nem?
Vagy jelen esetben lehet, hogy "elrontott UTF-8-ról" "jó UTF-8-ra". Bármit is jelentsen ez.Köszönöm a türelmeteket és a segítségeteket, és elnézést a sok-sok bejegyzésért.
Köszönöm! -
Taci
addikt
válasz
SUPREME7
#20511
üzenetére
Közben találtam más kódolással is forrásfájlt, a logban egyből szemet szúrt a sok kérdőjel:
ISO-8859-2
Kell még számítanom másféle kódolásra is? Mert akkor úgy készítem fel a szkriptet.Amit találtam róla:
Megszületett az ISO-8859-1 (más néven Latin-1) karakterkészlet, amely a magyar nyelvből az ő és ű betűket nem tartalmazza, így alkalmatlan magyar szöveg ábrázolására. Megszületett az ISO-8859-2 (Latin-2), amely az összes magyar ékezetet tartalmazza, tehát lényegesen jobb, de a magyar tipográfiának megfelelő nagykötőjel és idézőjelek, valamint sok egyéb fontos szimbólum ebből is hiányzik. Születtek egyéb ISO-8859 kódlapok, a DOS által használt kódlapok (cp437, cp850, cp852 stb.), a Windows karakterkészletei (Windows-1250, Windows-1252 stb.) és sok-sok egyéb is.Ez alapján számítanom kell rá, hogy más is fel fog még bukkanni.
Az angolszász, majd az európai országokból kiindulva az ASCII után először az úgynevezett Latin-1 kódolás terjedt el, ami tartalmazza az összes angol nyelvhez szükséges betűt, illetve számos európai nyelv betűit, de például a magyar „ő” és „ű” betűket nem (ezek helyett – helytelenül – gyakran használják a hullámos illetve a kalapos betűket: û ô vagy õ). Magyarhoz lehet azonban a Latin-2 (közép-európai) kódolást is használni, ami ismeri az ő és ű betűinket, de nem ismer más fontos betűket, például a cirill, görög, vagy például az örmény, indiai, arab és héber betűket, a kínai írásjegyeket és a japán kanákat. A Unicode és az UTF-8 kódolás egyszerre támogatja mindezen karakterek megjelenítését, és így minden nyelv egységes kódolást tud használni, megelőzve a betűk nem tervezett „átalakulását”.
Ezek alapján akkor talán az
UTF-8és azISO-8859-2. Vagy van olyan "bátor" magyar oldal, aki bepróbálkozik a Latin-1-gyel?ISO-8859-1(gyakran használják a hullámos illetve a kalapos betűket: û ô vagy õ --> Láttam már ilyeneket.)Még valami más esetleg? (Notepad pl. UTF-16-ba is enged menteni.)
Inkább leprogramozom most, mintsem később (újra) meglepjen.@Mike: Köszönöm, ezt nem is néztem, de UTF-8-on van, most ellenőriztem gyorsan.
Köszi!
-
Taci
addikt
Azt vettem észre, hogy ha fut az adatbázist feltöltő szkript (PHP) (főleg most, hogy van benne párszor meghívva 20mp-es sleep), akkor hiába mutatja a log, hogy már x db bejegyzést létrehozott, az adatbázis még üres, akárhogy frissítem. Egyedül akkor lesz csak (látható?) bejegyzés, ha végig futott a szkript.
Ez minden környezetben így van, vagy csak az én "teszt szerverem" (DesktopServer) működik így?
Vagy amíg nincs zárva az SQL-kapcsolat, addig a bejegyzéseket sem menti, csak "előkészíti", és maga az adatbázisba írás a kapcsolat zárásával realizálódna?
Tehát bármi ami a
$conn = new mysqli($servername, $username, $password, $dbname);
és a$conn->close();
között történik
(pl.$stmt = $conn->prepare($sql);$stmt->bind_param(...$stmt->execute()),az csak akkor íródik az adatbázisba, ha megvolt a kapcsolat zárása?
-
Taci
addikt
SELECT * FROM table1 WHERE category LIKE '%category1%'UNION ALLSELECT * FROM table2 WHERE category LIKE '%category1%'UNION ALLSELECT * FROM table3 WHERE category LIKE '%category1%'ORDER BY date DESCLIMIT 4Ezt a lekérdezést szeretném futtatni. A PHP logja ezt a sztringet adja vissza, ez a lekérdezés. Átmásolom phpMyAdmin-ba, tökéletesen lefut. Szkripből viszont nem.
Esetleg az idézőjellel van baja? Mert annyi került bele pluszban (a WHERE category LIKE miatt), és előtte szkriptből is tökéletesen ment. Próbáltam amúgy a normál idézőjellel is, az is megy kézzel, de szkriptből nem.Mintha valami ilyesmi rémlene, hogy korábban volt már ilyen problémám, hogy PHP-ből nem így kell szringet átadni.
Így generálom a kategóriás részt:
$categories_to_insert = "'%" . $categories_exploded[0] . "%'";Tudjátok esetleg, mi a hiba itt, és mi a megoldás?
Köszi.
-
Taci
addikt
Fura, nagyon fura, de úgy látom, az volt pont a baja, hogy logoltam...
Át van irányítva a php error logja egy saját log fájlba, tehát a visszaadott eredményhez semmi köze, mégis, most hogy remark-oltam a logokat, hiba nélkül lefut...
És ezt amúgy már korábban is észrevettem több php szkriptnél is - viszont nem mindegyiknél... Fura.
A lényeg, hogy ez volt a baja, nem a lekérdezés vagy a változó átadásának módja. -
Taci
addikt
válasz
sztanozs
#20525
üzenetére
Most jutottam csak oda, hogy rá tudjak nézni, de valóban ott volt a hiba, megtaláltam, javítottam, működik. Köszi.
Most csinálom a keresést az oldalon.
Azt vettem észre, hogy alapból átkonvertál mindent ékezet nélkülire, oda-vissza.
Tehát ha arra keresek, hogy "alma", akkor dob olyan találatokat, amikben olyan szavak szerepelnek, mint pl.: "álmaink", "álmából" stb.
Mondjuk azt is kidobja, hogy "fájdalmak", de max akkor úgy keresek, hogy első karaktertől kezdve, vagy pedig szóköz legyen előtte, vagy vessző.
Hogyan tudom úgy indítani a keresést, hogy ha ékezettel írom be a keresőszót, akkor csak az ékezeteseket mutassa, ha pedig ékezet nélkül, akkor úgy?
Pl. beírom, hogy "édes", és kidobja, hogy "ezredes", vagy "verekedés".
Ez így nem jó.
Bár néha meg pont kapóra jön, mert pl. most rákerestem, hogy "kocsma", és kidobta azt is, hogy "kocsmáját", ami így pont szerencsés találat volt, de talán ez a ritkább.
Van valami bevált módszer a pontos(abb) keresésre?
De gyorsan ránéztem a példa kedvéért a Telex keresőjére, ott is inkább csak az ékezetekre figyelnek (ha "alma" a keresett szó, nem dobja azt, hogy "álma"), illetve néztem azt is, hogy ha "alma" a keresés, a "hatalma" nincs a találatok között, szóval gondolom úgy lesz, ahogy írtam, első karaktertől vagy szóköz után (vagy lehet még vessző, pont és pontosvessző is, hátha el van gépelve).
Köszi.
[ Szerkesztve ]
-
Taci
addikt
SQL topikba tartozna így, off-ba is raktam, de annyira rossz a szemnek, hogy alig tudtam visszaolvasni, úgyhogy inkább kiszedtem off-ból.
Ez egyelőre csak egy lokál desktop server, és ami "vele együtt jött":
Kiszolgáló típusa: MariaDB
Kiszolgáló verziója: 10.1.37-MariaDB
A kiszolgáló karakterkódolása: UTF-8 Unicode (utf8)Hozzáadva a lekérdezéshez a collate-részt, phpMyAdmin konzolon belül a várt eredményeket adja.
COLLATE utf8mb4_binViszont amikor az oldalon keresztül hívom meg (már ha jól használom egyáltalán), akkor hibára fut.
Ezt hívom meg:
SELECT * FROM table1WHERE((title LIKE '%alma%' COLLATE utf8mb4_bin)OR(desc LIKE '%alma%' COLLATE utf8mb4_bin))UNION ALLSELECT * FROM table2WHERE((title LIKE '%alma%' COLLATE utf8mb4_bin)OR(desc LIKE '%alma%' COLLATE utf8mb4_bin))UNION ALLSELECT * FROM table3WHERE((title LIKE '%alma%' COLLATE utf8mb4_bin)OR(desc LIKE '%alma%' COLLATE utf8mb4_bin))ORDER BY time DESCLIMIT 4Ránézésre találtok esetleg valami hibát?
Megnéztem egy online SQL code checker-ben, azt írta, rendben van, csak nem optimalizált.Köszi.
[ Szerkesztve ]
-
Taci
addikt
válasz
sztanozs
#20530
üzenetére
Ezzel a collation-dologgal most bekavarodtam.
Nézegetem, hogy mit kellene használni, és ezt a linket találtam:
http://mysql.rjweb.org/utf8mb4_collations.htmlItt kapásból néztem a két magyart:
utf8mb4_hu_0900_ai_ciutf8mb4_hungarian_ciDe már az első karaktereknél látszik, hogy pl. A-betűnek kezeli az á-t is, és kb. minden hasonlót:
A=a=ª=À=Á=Â=Ã=Ä=Å=à=á=â=ã=ä=å=Ā=ā=Ă=ă=Ą=ąPlusz ugye mert _ci, case insensitive, tehát nem különbözteti meg a kis- és nagybetűket.
Tehát nekem a magyar-specifikus collation-ök nem jók. Ahogy nézem, ez lehet jó, hogy külön kezelje az ékezetes betűket:
latin1_general_ciItt külön van kezelve az "A" az "Á"-tól, bár jobban örülnék, ha ezeket együtt kezelné:
À=à Á=á
Mert simán kinézem, hogy néhány helyen még rosszul szerepelnek az ékezetek, így ezt sajnos külön kezeli, és ha a cikkben "àlom" van, a keresés az "álomra" (fordítva áll az ékezet) nem hoz majd eredményt. De ez legyen a legkisebb probléma, ezzel még együtt tudok élni.Jól látom, hogy a
latin1_general_ci-t kell használnom, ha meg akarom különböztetni a keresést ékezetes karakterek alapján?Azt nem igazán találom, hogy az
utf8mb4_binhogyan működik ezekhez képest.----------
Ez a COLLATE parancsot amúgy jól használom? Vagy az adatbázis létrehozásakor kellett volna?
Mert ilyet is találtam:CREATE DATABASE Jira CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;Én igazából "csak" keresni szeretnék, az ékezetes betűket külön kezelve.
De most ezzel eléggé bekavarodtam.Tereljetek irányba, kérlek.
Köszi.
-
Taci
addikt
Értetlenül állok a következő előtt:
A
htmlspecialcharsfüggvény az egyik szövegnél fura végeredményt adott, amit most vettem csak észre:Ez a bemeneti szöveg:
"Szöveg!"
(A felkiáltójelet csak azért hagytam ott, hátha szerepe van - bár szerintem nincs.)És ez került be az adatbázisba, miután a
htmlspecialcharskezelésbe vette:&quot;Szöveg!&quot;Mivel ezek a sztringek HTML-ben lesznek megjelenítve, ezért kell a
htmlspecialchars, hogy a HTML által is használt karaktereket (ilyen az idézőjel) átalakítsa (az idézőjelet pont"-ra), mert amúgy elrontja a HTML kódot.Viszont itt eleve a már "jó változatot" kapja meg a
htmlspecialcharsfüggvény, olvasatomban ezt nem kellene piszkálnia, az output is ugyanaz kellene legyen, mint az input.
De itt valamiért belerakja azamp;karaktereket (ami ugye az "és-jel" (&) lenne, legalábbis az&), ezzel elrontva az egészet. Nem is értem, hogyan és miért rakja oda, és miért nem az egészet, és miért a"első karaktere után...És fura módon ezután a HTML által kijelzett kódban ez szerepel:
"Szöveg!"
Nem jelzi ki a belerakottamp;karakteret, viszont nem is alakítja idézőjellé.Én rontok el valamit a használatánál?
$description = htmlspecialchars($feed[$x]['description']);Van esetleg valami ötletetek?
-
Taci
addikt
válasz
nevemfel
#20535
üzenetére
Aha, értem mire gondolsz, tehát amikor a kliens kéri a tartalmat (JS), és a PHP lekérdi az adatbázisból, amit megkap, arra hívjam meg a htmlspecialchars-t, és azt adjam vissza a kliensnek.
Amúgy ahogy nézegetem, azt is írják talán megoldásnak, hogy előbb a _decode függvényét kell meghívni, és így rendben lesz:
[link]$text = 'Your text with &s from the database';// Decode and re-encode the special characters.$text = htmlspecialchars(htmlspecialchars_decode($text));Kipróbálom mindkettőt.
Köszi szépen a gyors választ!
[ Szerkesztve ]
-
Taci
addikt
válasz
nevemfel
#20535
üzenetére
Megcsináltam így, a
htmlspecialchars-t csak megjelenítésnél használom, és ha idézőjellel"kerül be az adatbázisba a szöveg, akkor a kliensnek már"-tal adja át, amit aztán a böngésző szépen megjelenít újra idézőjelként".Viszont ha már eleve
"-tal kerül be, akkor"-ot is ír ki a böngésző. (Megnéztem, most már nem rakja bele az "amp"-ot, tehát normálisan"van a kliensnek visszaadott értékben.)Ez nem a böngésző dolga lenne, hogy visszaalakítsa?
Vagy nekem kell valamit még csinálnom?
@Mike:
Esetleg a collation-ös dolgot? Mert ott ahogy pár hozzászólással lejjebb is írtam (túl bőven, tudom), nagyon nem érzem ezt a collation-témát, a keresésem azóta is kuka. (De ez most más téma.)Próbáltam így is:
htmlspecialchars($row["feed_description"], ENT_QUOTES, 'UTF-8');
De ugyanaz a végeredmény. (Az ENT_QUOTES itt most nem játszik szerepet, tudom.)[ Szerkesztve ]
-
Taci
addikt
válasz
nevemfel
#20540
üzenetére
A forrássztringeket kapom, nem én készítem, és van, ami idézőjellel jön, van, ami "-tal, változó, nincs rá hatásom. Sajnos kezelnem kell tudni minden helyzetet. És ezek szerint most rosszul kezelem.
Hát ne kerüljön bele eleve "-tal.
Akkor megpróbálkozom azzal, hogy htmlspecialchars_decode-dal rakom adatbázisba, így minden ugyanúgy fog bekerülni. És akkor ezeket adom a kliensnek htmlspecialchars használatával, a többi meg a böngésző dolga.@Mike: Ahogy utánaolvastam, pár kommentben láttam, hogy pár speciális karakterrel "rosszul bánik" a htmlentities, míg a htmlspecialchars szépen kezeli. Köszi azért, hogy bemásoltad.
Just ran into a problem due to using htmlentities rather than htmlspecialchars! If your site is UTF8 encoded, special symbols like ¡™£¢∞§¶ get turned into little black diamonds with question marks in them because htmlentities doesn't know how to handle them, but htmlspecialchars does.
-
Taci
addikt
Úgy tűnik, ez a módszer (egyelőre) így már jó. Tehát adatbázisba (az idézőjelnél maradva) mindenképp a normál idézőjellel kerül, onnan amikor HTML-be kerül, már htmlspecialchars-szal megy.
--------------------
Viszont a kutakodás közben azt találtam, hogy utf8 helyett utf8mb4-et kellene már használni mindenütt.
Nekem minden php kódomban ez van jelenleg:
$conn->set_charset("utf8");Úgyhogy ezt akkor át kellene írnom
$conn->set_charset("utf8mb4");-re, gondolom.Viszont ezt az egész utf8 collation-témát nem értem.
Ott jött fel a téma, hogy keresésnél szeretném, ha meg lennének különböztetve az ékezetes karakterek a nem ékezetesektől, tehát csak arra keressen, amit beírnak a keresőmezőbe, ne hagyja le az ékezeteket ("Máté" vs "Mate").
Aztán jött a tipp sztanozs fórumtárstól, hogy talán rossz collate van beállítva a mezőre. De minél többet olvastam utána, annál jobban elvesztem.
Kéznél van esetleg egy átlátható magyarázat elmentve valaki kisokosába, hogy hol és hogyan kell ezt használni, beállítani?
Eleve a táblákat is már ezek használatával kell létrehozni? (Ilyen találatokat is kaptam.)
Vagy csak simán a lekérdezésnél? (Ezt próbáltam is, phpMyAdmin konzolban szépen lefutott, a kódból hívva már nem.)
Nem baj, ha újra kell építenem az adatbázist, inkább most nullázom le, amíg még csak teszt fázisban van az egész. De jó stabil, megbízható alapot akarok építeni.Szívesen átnézek és megtanulok én minden ide tartozó dolgot, de egyszerűen annyi féle válasz volt már előttem, hogy teljesen elvesztem köztük, és félek, ez egy olyan téma, amit ha most nem rakok össze rendesen, később vissza fog ütni.
Köszönöm az eddigi segítséget is.
-
Taci
addikt
válasz
pelyib
#20545
üzenetére
Köszönöm a részletes választ!
Így már sokkal jobban rálátok erre az egész collation-dologra, ez az _ai _as, _ci _cs magyarázat különösen hasznos volt.
És így, hogy jobban rálátok, még több kérdés merült fel...
Megtaláltam én is végül ezt a választ, amiből idéztél, és én is azt találtam, hogy ha úgy akarok keresni, hogy meg tudjam különböztetni az ékezetes betűket a nem ékezetesektől (_as), de nem számít, hogy kis- vagy nagybetű-e (_ci), akkor
utf8mb4_0900_as_ci-t kellene használnom, ami viszont 8.0-tól elérhető csak.utf8mb4_bin-nel igazából többet vesztenék a keresésen, mint nyernék, mert ez ugye binárisan hasonlít, tehát a kis- és nagybetűk meg lesznek különböztetve, ami egy keresésben nem szerencsés.Így a következő kérdéseim lennének:
1)
PHPMyAdmin-ban azt látom, hogy ami táblákat én csináltam, az mindutf8_unicode_cicollation-nel készült, amit pedig a WordPress csinált, az mindutf8mb4_unicode_ci.Így, hogy igazából a fentiek (és az egész dolog túlontúl bonyolult mivolta) miatt inkább lemondok arról, hogy megkülönböztessem a keresésben az ékezetes betűket az ékezet nélküliektől, van bármi értelme
utf8-ról átállnomutf8mb4-re?
Azon kívül, hogy emoji-téren future proof lennék.2)
Vagy inkább azt szeretném tudni, hogy elronthatok vele valamit? Ami kód működik, az most szépen működik. Elromolhat valami ezzel az átállással?
Pl. már nem is emlékszem hol olvastam, de azt írták, hogy ennél a típusú váltásnál vigyázni kell rá, hogy a mező karakterszáma mondjuk 255-re volt beállítva utf8-nál, akkor ez valójában kevesebb lesz utf8mb4-nél a 3 vs 4 byte miatt.Illetve itt írnak pár lehetőséget, hogy mi sülhet (és a témaindítónak sült is el) rosszul:
[link]3)
Ha jól látom, akkor ahhoz, hogy megfelelően hozzam létre a táblákat, ezeket kell csinálnom PHP-ben, ami intézi az SQL-es műveleteket:
-$conn->set_charset("utf8mb4");(most utf8 van)
- a mezőre vonatkozó részekhez (VARCHAR):CHARACTER SET utf8mb4
- táblára vonatkozó részekhez:CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci(a _bin helyett ez jobb lesz a keresés miatt)Jól látom, hogy ezekre kell figyelnem? Vagy van még valami?
Köszi!
[ Szerkesztve ]
-
Taci
addikt
válasz
sztanozs
#20549
üzenetére
Köszönöm szépen a segítséget mindenkinek, sikerült "átállnom" utf8mb4-re.
Mivel még csak teszt adatbázis, ezért csináltam backup-ot minden táblából, módosítottam minden PHP kódot, amivel létrehozom a táblákat, és rendben létrejött minden a megfelelő formában, tartalommal feltöltve. Persze még tesztelnem kell alaposan mindent, de remélem, rendben lesz.
A keresésnél úgy döntöttem, nem kell az _as, mert ha valaki pl. angol billentyűzetkiosztással keres (vagy akárcsak mobilon is), nem fogja az ékezetes betűket beírogatni (mobilról én sem tenném).
---------------------------
Egy másik kérdés PHP-hoz kapcsolódóan:
Valószínűleg sokszor ki lett már tárgyalva, és a saját kutatásom (aka. Google-keresés) szerint nincs különösebb jelentősége, de:
Kell foglalkozni az egyszeres (fél-) idézőjel'és a dupla idézőjel"közti különbséggel?Az összes PHP kódomat a "normállal" írtam
"- kivéve persze ahol pont mondjuk sztringbe akartam dupla idézőjelet írni.Azt tudom, hogy a dupla idézőjelesbe írt változók kiértékelődnek:
$s = "dollars";echo 'This costs a lot of $s.'; // This costs a lot of $s.echo "This costs a lot of $s."; // This costs a lot of dollars.És biztos van még ilyen különbség. De a kódjaimat már megírtam, szóval már minden működik, úgyhogy ezzel a részével már nem kell foglalkoznom.
Szóval engem inkább az érdekelne, vagy van-e (nagy) jelentősége teljesítményben, ha a duplát
"használom az egyes (fél)'helyett?
Régebben biztosan számított, de a mai (és tegnapi) gépek és rendszerek teljesítményénél talán ez már egyáltalán nem fontos.
De azért inkább rákérdezek.Köszönöm.
-
Taci
addikt
Elvileg az str_split erre tökéletesen használható:
https://www.php.net/manual/en/function.str-split.php$str = "Hello Friend";$arr1 = str_split($str);print_r($arr1);Array([0] => H[1] => e[2] => l[3] => l[4] => o[5] =>[6] => F[7] => r[8] => i[9] => e[10] => n[11] => d) -
Taci
addikt
ha UTF-8-at használsz akkor a multibyte extension legyen a php-ra felrakva, és strlen helyett mb_strlen-t kell használnii
SQL mezőben a
VARCHAR(255)-ben a 255 ugye karakterszámot jelöl? Ezek szerint ha azt akarom vizsgálni, hogy egy beadott sztring ne lehessen hosszabb ennél, akkor eddig rosszul használtam?if (strlen($title) > 254){$title = substr_replace($title, "[...]",249);}Mert akkor ezek szerint az strlen a karakterek által elfoglalt byte-okat számolja, míg az mb_strlen magát a karakterek számát?
Tehát akkor ezek szerint nekem így kellene használnom:
if (mb_strlen($title) > 254){$title = substr_replace($title, "[...]",249);}Köszi.
-
Taci
addikt
Köszönöm, már át is írtam, és valóban volt különbség.
VARCHAR(300)-ra van beállítva az egyik mező, és az egyik bejegyzésnél a korábbi "sima" strlen-es módszerrel szólt, hogy túl hosszú (~330), ezért levágta a túlcsorduló részt.
Azonban most megnéztem a forrássztringet, és valójában csak 298 karakter hosszú.
Átírtam a kódot mb_strlen-re, és így már nem bántotta, egyben volt kijelezve, hisz' elfért.Köszönöm.
-
Taci
addikt
Ezt találtam, de "csak" stackoverflow-ról így hirtelen:
"Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions."Amúgy nekem gond nélkül kiírja amit eddig kellett, a 300-as határt csak azért húztam, mert utána egyszerűen már túl sok, rengeteg helyet elfoglal a szöveg.
Illetve ezt találtam még:
VARCHAR(65535)
However, note that the limit is lower if you use a multi-byte character set:
VARCHAR(21844) CHARACTER SET utf8For CHARSET=utf8mb4 use VARCHAR(16383)
[ Szerkesztve ]
-
Taci
addikt
Amíg tesztfázisban vagyok, néha el kell indítanom kézzel is egy szkriptemet (ami az adatbázist tölti fel), de amúgy Cron Job-ként fut (jelenleg csak óránként).
Már többször kiszúrtam magammal, mert akkor indítottam el, amikor pont futott amúgy is, így az aktuális bejegyzések duplán kerültek az adatbázisba, aztán mire felkutattam, hogy mi is történt, rengeteg időt elpazaroltam.Arra gondoltam, hogy futás elején ellenőrzöm a logfájl (amibe minden bejegyzés részlete bekerül) időbélyegzőjét és fájlméretét, aztán várakoztatom a szkript futását 5 mp-re, újra ellenőrzöm, és ha eltérés van, akkor a másodjára elindított példányt exit()-tel leállítom, hogy ne legyen "duplázás".
$log_file_filesize_check_start = filesize($log_file_custom_path);$log_file_filemtime_check_start = filemtime($log_file_custom_path);sleep(5);$log_file_filesize_check_end = filesize($log_file_custom_path);$log_file_filemtime_check_end = filemtime($log_file_custom_path);De akárhogy csinálom, hiába altatom 10 mp-ig is akár, a _start és _end értékek mindig megegyeznek, pedig direkt nézem a fájlt, folyamatosan ír bele az első példány, így kell, hogy változzon a fájlméret és az időbélyegzője is.
Lehetséges esetleg, hogy ezek az értékek (filesize, filemtime) csak akkor realizálódnak majd magán a fájlon, ha a szkript már "elengedte" (tehát ha a bele logoló szkript már befejezte a futását)?
Ki szeretném védeni a duplikált bejegyzéseket (amik azért jönnek létre, mert duplán fut a szkript, mert a második példány akkor indul el, amikor az első még fut).
Ha esetleg a logfájl adatainak elemzésével nem érhetek célt, akkor keresek mást, de most már érdekelne ez a dolog.
Köszi.
-
Taci
addikt
Nagyon nyakatekert módon, de végül így oldottam meg:
0) Az ellenörző funkcióval kezdődik a szkript (lejjebb részletesebben, a 3. ponttól)
1) Logolás kezdetekor beszúr egy szöveget (pl. "Logolás kezdete")
2) Logolás végén ismét egy szöveg (pl. "Logolás vége")
3) Megvizsgálja a log fájlban a "Logolás kezdete" és "Logolás vége" sztringet ismétlődéseit
4) Ha megegyeznek (pl. 2 - 2 db), akkor az azt jelenti, hogy el lett kezdve, és le is lett zárva (azaz már nem fut), tehát indulhat újra a kód futása a szükséges feladatokkal.
5) Ha különböznek, akkor összehasonlítom a log fájl időbélyegzőjét, illetve a jelenlegi időbélyegzőt.
6) Ha kevesebb, mint a beállított limit (10 perc), akkor a php error.log fájljába ír, hogy ne módosítsa a szkript log fálját, de mégis legyen infóm arról, hogy megállt, nem fut tovább, és lássam az okát.
7) Amint 10 perc fölött van a különbség, attól függően, hogy a "kezdete" vagy "vége" sztringekből van kevesebb, beszúrja a logba a megfelelő sztringet a megfelelő mennyiségben, kvázi helyre állítva a logot.
Aztán fut tovább a szkript a normál módon, a kezdete és vége sztringek úrja párban vannak, megtörtént az esetleges szükséges "karbantartás" (ha mondjuk nem futott volna végig a szkript, és a "vége" bejegyzést nem tette volna meg).Egyszerűbb ötletem nem volt, és ezt most egyelőre bolondbiztosnak látom.
5 percenként fut a szkript, ha esetleg nem végezne a következő futtatásig, akkor nem indul, majd csak az azutáni 5. percnél.
Ha pedig valamiért nem futna végig (pl. szerverhiba), és elrontaná a log fájlt (és ezzel az ellenőrzést), max 10 perc múlva helyrehozza az ellenőrzéses szükséges sztringeket.Remélem, jó lesz.
)
Valami régi programozási órai dolog lehet, már nem is emlékszem rá igazán, honnan jött. 
Új hozzászólás Aktív témák
- ASUS routerek
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- EAFC 24
- Napelem
- Raspberry Pi
- Futás, futópályák
- Kertészet, mezőgazdaság topik
- Az USA nem akarja visszafogni Kína növekedését
- Békéscsaba és környéke adok-veszek-beszélgetek
- Huawei Mate 10 Pro - mestersége az intelligencia
- További aktív témák...
