Új hozzászólás Aktív témák
-
nevemfel
senior tag
Több oka is lehet. Nem írtad, milyen webszervert használsz, az is elcseszheti. Ezen kívül a PHP 7.3.1 elég régi, a 7.3 vonalon a legfrissebb verzió a 7.3.27 . Amint láthatod, a 7.3.1 óta igen hosszú a javított bugok listája.
Aztán az sem mindegy, hogy állítod be az utf8 charsetet. A dokumentumba belerakott meta charset tagot ugyanis a webszerver vagy a php által kiküldött content-type ....; charset=.... felülbírálja.
Rally against apathy draws small crowd
-
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 ]
-
nevemfel
senior tag
Nem tudom, mi ez a desktopwebszerver, de a honlapjuk nem valami bizalomgerjesztő. Sehol nem találom, hogy mégis milyen komponensekből áll, azt meg pláne nem, hogy melyik verzió. Én a helyedben XAMPP-ot használnék.
Ami a tartalomlehúzás problémát illeti, talán jobb lenne, ha curlt használnál, nem a php url wrapperjeit. Jobban paraméterezhető, és talán loggolni is egyszerűbb, ha elemezni kell a hálózati forgalmat.
[ Szerkesztve ]
Rally against apathy draws small crowd
-
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?
-
nevemfel
senior tag
-
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öld
sztring, 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öld
Aztá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_decode
segí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! -
Mike
veterán
kicsit off
próbálom működésre bírni a firefox developert remote usb debugging végett, de egyszerűen nem jelenik meg semmi a csatlakoztatott eszközök listáján.firefox developer 88, windows 8.1, android 9
elvileg mindent engedtem/bekapcsoltam amit kellett és a leírásban benne volt.vmi ötlet?
-
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?
-
coco2
őstag
Redisnek nincs saját topic-ja, de talán itt tudni fogja valaki.
Redis alatt van(nak) kulcsok. Ki szeretném íratni, milyen tartalom tartozik hozzájuk, de csak (nil) jön vissza "mget *"-ra. Apache/php redis alatt tárolja a session-öket, nagy halom anyagnak kell a kulcshoz tartoznia, ki van csukva, hogy semmi se legyen benne. Redis doksi olyan barátságtalan, hogy nem találom az okát, mit néztem el.
Ha bármit számít a háttér, session hibám van, és nyomozom az okát. Elvileg session változókra kiadott unset()-ek után azoknak nem kellene létezniük, és mégis léteznek. Hogy miért, még nem tudom. Valami nagyon alapvető dolgot elnéztem a redis-re bízott session kezelést illetően. Ha véletlenül valaki csípőből tudja, szóljon rám!
Köszönöm.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
polymorphin
csendes tag
Gondolom * key nem letezik MGET – Redis
-
coco2
őstag
válasz polymorphin #20519 üzenetére
Be-copy-paste-eltem a kulcsot is "get <kulcs>" és ugyan úgy (nil) visszaírást kaptam.
Halom sok logot hegesztettem végül a php scriptbe orvosolni a problémát.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
válasz polymorphin #20521 üzenetére
Azok a kulcsok session id-k egy php alkalmazásban, és a session-ben remekül megvan minden adat. Php scriptbe logokat pakoltam adatot kinyerni, és azok visszaadták az adatot. Azokra a kulcsokra adtam én get-et, és azokra a kulcsokra írt vissza (nil)-t a redis-cli.
Mostanra eleresztettem. Bárki is kínálgatta anno nekem itt a redis-t, üzenem neki, hogy egy marketing-felfújt bughalmaz. Session-tárolónak felesben elmegy, de szerintem a jövőben inkább visszatérek a memory disk-re, és file alapú session tárolóra. Az legalább kiforrott, és bugmentes. A redis nem az.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
Taci
addikt
SELECT * FROM table1 WHERE category LIKE '%category1%'
UNION ALL
SELECT * FROM table2 WHERE category LIKE '%category1%'
UNION ALL
SELECT * FROM table3 WHERE category LIKE '%category1%'
ORDER BY date DESC
LIMIT 4
Ezt 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. -
sztanozs
veterán
vsz logolásnál hibára fut, amit a környezet benyel és megszakad a lekérdezés.
próbáld meg a logolást berakni egy try-catch-be és megnézni tényleg hibára fut-e...JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
coco2
őstag
Időnként van ám a php-ban, amit utálok.
var_dump(json_encode(array_diff(array(0,1), array(1))));
A kimenete
[0]
var_dump(json_encode(array_diff(array(0,1), array(0))));
A kimenete
{"1":1}
(nem tömb, hanem objektum, hogy a fene vinné el)កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
pelyib
tag
array_values megoldja
-
coco2
őstag
Facebook Login, user_photos permission
Aki fejlesztőként már futott vele köröket, egy jelzést had kérjek tőle. Itt kissé off, szóval inkább privátban a többit.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
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 ]
-
sztanozs
veterán
Vsz rossz collate van beállítva a mezőre és keresésnél nem különbözteti meg az ékezetes és a nem ékezetes karaktereket.
[link][ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
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_bin
Viszont 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 table1
WHERE
((title LIKE '%alma%' COLLATE utf8mb4_bin)
OR
(desc LIKE '%alma%' COLLATE utf8mb4_bin))
UNION ALL
SELECT * FROM table2
WHERE
((title LIKE '%alma%' COLLATE utf8mb4_bin)
OR
(desc LIKE '%alma%' COLLATE utf8mb4_bin))
UNION ALL
SELECT * FROM table3
WHERE
((title LIKE '%alma%' COLLATE utf8mb4_bin)
OR
(desc LIKE '%alma%' COLLATE utf8mb4_bin))
ORDER BY time DESC
LIMIT 4
Rá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_ci
utf8mb4_hungarian_ci
De 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_ci
Itt 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_bin
hogyan 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
htmlspecialchars
fü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
htmlspecialchars
kezelé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
htmlspecialchars
fü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 ]
-
Mike
veterán
hm... kicsit belenéztem miket használok
sima POST-os mentésnél nem csinálok a szöveggel semmi ilyesmit
ugyanakkor ajaxnál, amikor objektumtömböt adok átAdatok.push({id:obj.id, ertek:obj.innerText});
majdJSON.stringify
és ezt így dolgozza fel a fogadó oldal$adat = json_decode(html_entity_decode(stripslashes($_POST['adat'])),true);
pár éve változott a POST, van amit duplán escape-pel.
és találtam egy ilyet is//html átalakítása javascriptnek
function HtmlSzovegForJS($str)
{
$str = trim(preg_replace('/\s\s+/', ' ', $str));
$str = htmlentities($str, ENT_COMPAT,'UTF-8', true);
return $str;
}
de fogalmam sincs mire használtam[ Szerkesztve ]
-
nevemfel
senior tag
Viszont ha már eleve
"
-tal kerül be, akkor"
-ot is ír ki a böngésző.Hát ne kerüljön bele eleve "-tal. htmlescapeelni akkor kell, amikor html-be ágyazod bele a tartalmat. Ha például logfile akarnád kiírni, már akkor sem így kell escapelni. Ha egy javasscipt változóba kerül bele a tartalom, vagy CSS-be, ott is másképp kell escapelni a tartalmat.
Rally against apathy draws small crowd
-
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.
-
pelyib
tag
Mivel en se tudtam a valaszt, viszont erdekelt, ezert kicsit olvasgattam es ezeket talaltam:
For nonbinary collation names that do not specify accent sensitivity, it is determined by case sensitivity. If a collation name does not contain_ai
or_as
,_ci
in the name implies_ai
and_cs
in the name implies_as
. For example,latin1_general_ci
is explicitly case-insensitive and implicitly accent-insensitive, andlatin1_general_cs
is explicitly case-sensitive and implicitly accent-sensitive.
[LINK]Illetve ezt a kerdest S0-n
If you need "beyoncé" and "beyonce" to be considered different, then ideally you would use a case-sensitive (and either explicitly-stated or implied accent-sensitive) collation. However, it looks like this is not available in MySQL 5.6 (or even 5.7), while MySQL 8.0 does haveutf8mb4_0900_as_cs
, or evenutf8mb4_0900_as_ci
if you only want the accent to distinguish between the values while allowing "beyonce" and "Beyonce" to match.Bar ez nem kisokos, de legalabb valasz az eredeti kerdesre
UPD: csak lehet ezt:
percona x@y:z> show create table char_collection;
+-----------------+-------------------------------------------------------------+
| Table | Create Table |
+-----------------+-------------------------------------------------------------+
| char_collection | CREATE TABLE `char_collection` ( |
| | `name` varchar(255) CHARACTER SET utf8mb4 DEFAULT NULL |
| | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+-----------------+-------------------------------------------------------------+
1 row in set
Time: 0.039s
percona x@y:z> select * from char_collection where name like 'ár%' collate utf8mb4_bin;
+------------------------+
| name |
+------------------------+
| árvíztűrő tükörfúrógép |
+------------------------+
1 row in set
Time: 0.237s
percona x@y:z> select * from char_collection where name like 'ar%' collate utf8mb4_bin;
+------+
| name |
+------+
0 rows in set
Time: 1.997s
percona x@y:z> select * from char_collection;
+------------------------+
| name |
+------------------------+
| árvíztűrő tükörfúrógép |
+------------------------+
1 row in set
Time: 0.067s[ Szerkesztve ]
-
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_ci
collation-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 ]
-
sztanozs
veterán
1) The difference between utf8 and utf8mb4 is that the former can only store 3 byte characters, while the latter can store 4 byte characters. In Unicode terms, utf8 can only store characters in the Basic Multilingual Plane, while utf8mb4 can store any Unicode character.
Ez alapján a kiterjesztett karakterkészletbe tartozó unicode karakterek (vsz emoji, extended chinese meg más távolkeleti nyelvek) támogatottak pluszban.2) karakterszám nem változik, a tábla mérete fog nőni (bájtban), de jelentősen csak akkor, ha ki is használod.
A SO-s probléma pedig ez volt:Mistery solved! There was a bad installation/upgrade/config with mysql and utf8mb4 was not properly installed.
...
Sorry for the delay, I was enjoying my holidays MySQL (in my case MariaDB) was lacking the neccesary files so the encoding didn't exist. The files need to be compiled (I think recompiling with necessary flags) or reinstall a recent version. This happened on an old cent os 5 server, so in more recent versions this shouldn't happen, in fact I installed cent os 6.7 and utf8mb4 was detected without problems.3) ez jó, de ha _as keresést akarsz, akkor kénytelen leszel mégiscsak a _bin-t használni, ha az általad használt verzió még nem támogatja az _as_ci-t, és a _bin meg ugye nem _ci. Szóval azt kell eldöntened melyik fáj kevésbé.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
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.
Új hozzászólás Aktív témák
- Ukrajnai háború
- Óra topik
- Épített vízhűtés (nem kompakt) topic
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy A54 - türelemjáték
- Soundbar, soundplate, hangprojektor
- Programozásról_szubjektíven
- Tippmix
- Kerékpárosok, bringások ide!
- Xbox tulajok OFF topicja
- További aktív témák...
- Gigabyte GA-H81M-DS2 rev:2.1 LGA 1150 alaplap
- IPhone SE2 2020 64GB megkímélt akku 86%
- Asus P8H67 LGA 1155 alaplap
- Bomba ár! Fujitsu LifeBook E754 - i7-4712MQ I 8GB I 128SSD I 15,6" I HDMI I Cam I W10 I Garancia!
- Bomba ár! Fujitsu LifeBook E754 - i5-4GEN I 8GB I 128SSD I 15,6" FHD I HDMI I Cam I W10 I Garancia!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen