Keresés

Kérlek mutatsd meg a 10205-ben a print_r-t, vagy az array_dump-ot, vagy a kimeneti adatstruktúrát.

És egy újabb meglepetés:

<?php

        $adat = array( "Név" => "xyz" );
        $json = json_encode( $adat );
        echo $json . "\r\n";
        $obj = json_decode( $json );
        echo $obj->Név . "\r\n";

?>

kimenet:

{"N\u00e9v":"xyz"}

xyz

A php úgy látszik simán képes kezelni az ékezetes karaktereket az objektum vagy tömb indexében.

A print_r vagy az array_dump olvashatóvá teszi az ékezetes karaktereket, nem is azzal van a baj.

Hanem a kimenet egy adatstruktúra, ami viszont nem json-kompatibilis.

Sajnos erre nincs megoldás, a json-ban nem lehetnek ékezetes karakterek.

Ezért van a var_dump vagy a print_r, hogy olvashatóvá tegye, de a jelek szerint meg nem változtatja a json stringet.

Legalábbis ez a meglátásom.

Valamilyen programrészletet próbálj beidézni a probléma szemléltetésére, (csak persze előtte sed 's;\\;\\\\;g')
Pl:
Program:
#!/usr/local/bin/php
<?php
    $in1= "\"\\u00e1rv\\u00edzt\\u0171r\\u0151 t\\u00fck\\u00f6rf\\u00far\\u00f3g\\u00e9p\"";

    $out1= json_decode ($in1);

    printf ("LC_CTYPE=%s\nElotte: %s\nUtana: %s\n", getenv("LC_CTYPE"), $in1, $out1);
?>

Futás:
LC_CTYPE=hu_HU.UTF-8
Elotte: "\u00e1rv\u00edzt\u0171r\u0151 t\u00fck\u00f6rf\u00far\u00f3g\u00e9p"
Utana: árvíztűrő tükörfúrógép

Namost ha ugyanezt 8-bites terminálon nézed, akkor persze csúnya lesz:
LC_CTYPE=hu_HU.ISO-8859-2
Elotte: "\u00e1rv\u00edzt\u0171r\u0151 t\u00fck\u00f6rf\u00far\u00f3g\u00e9p"
Utana: ĂĄrvĂ­ztĹąrĹ tĂźkĂśrfĂşrĂłgĂŠp

Az a gond, hogy nem ismeri fel benne ezt a kódolást, egyszerűen ASCII-nak érzékeli, a visszaperjelet nem egy speciális karakter kezdetének gondolja, hanem visszapernek. Érdekes módon a \r\n-t ettől függetlenül új sornak veszi.

Az sem működik. Próbáltam előtte a setlocale-t is semmilyen kombinációban nem  konvertálja át.

Akkor egy konkrét kérdés:

hogy lesz a következő 5 karakterből: \u00e -ből é betű?

Talán azt próbálod kérdezni, hogy hogyan lehet utf8-ról latin2-re convertálni? Az iconv nevű eszközzel.

https://www.php.net/manual/en/function.iconv.php

Ha ilyen egyszerű lenne, akkor nem kérdeztem volna.

Ha kiíratom a json_decode eredményét, ugyanazt kapom. Csak a var_dump jelenít meg nekem unikód nélküli objektumot.

Var_dump nélkül ugyanúgy teli van unikódokkal a stringem.

Nekem egy unikód nélküli json string kell, de azt meg nem csinál a var_dump. Mi több, a var_dump nem is hagyományos értelemben vett függvény, hanem inkább a régi (Pascal-beli) eljáráshoz hasonlatos.

Úgy látszik, hogy kénytelen vagyok str_replace-el kicserélgetni az unkódolást.

Ha ez egy json input, akkor a json_decode szépen megcsinálja belőle az utf8-at, pl:

be:
{"\u00e1rv\u00edzt\u0171r\u0151": "t\u00fck\u00f6rf\u00far\u00f3g\u00e9p"}

ki (var_dump):
object(stdClass)#3 (1) {
  ["árvíztűrő"]=>
  string(17) "tükörfúrógép"
}

Ja és a json_decode sem teszi olvashatóvá.

Úgy látom, itt meg a backslashek maradnak le.

Szóval az adott string egy json-string, ahol a string-értékeknél az idézőjelek között vannak ezek az unikódos vagy tudomisén milyen kódolású karakterek, tehát pl. \u0123

Adott egy string, ahol az ékezetes karakterek helyett uNNN-ek vannak.

Nem tudom miféle kódolás ez, nyilván én is használom, pl. új sor esetén: rn. Vagy nem is kódolás?

De képtelen vagyok olvashatóvá tenni, próbáltam már mindenféle függvényt UTF8 encode, decode, html_entity encode, decode, iconv és egyéb kulcsszavakkal számtalan függvényt, amit csak találtam a témában és nem megyek semmire semelyikkel.

PHP-t konzol módban használom.

Mi a kulcsa?

Sziasztok!!!

A Hengersor nevű suliba mennék esti teljesen ingyenes programozó / szoftverfejlesztő OKJ -s képzésre, de nem vagyunk elegen, hogy induljon a képzés. Ha valaki szeretne ingyen tanulni, mint én, akkor hívja fel a sulit telefonon, vagy írjon nekik e-mail-t, hogy esti szoftverfejlesztő OKJ -ra szeretne járni. Teljesen ingyenes. Köszi a többiek nevében is ha csatlakozol, vagy ha szólsz az ismerőseidnek, akiket esetleg érdekelhet a képzés. Sose késő :)

Üdv!

'reggel! Teoretikus kérdés: a tárhelyem kezelője nem engedélyezi, hogy a MySQL adatbázisban tárolt eljárásokat használjak. Meg tudná mondani valaki, hogy miféle biztonsági kockázatot jelentene a szolgáltatónak, ha engedélyezné ezt? Szerintem ha ilyen eszközökkel biztonságosabbá teszem a saját oldalamat, az win - win helyzet.

Igen, olyan programozo kell, akinek van benne gyakorlata.

Szia,

https://www.espocrm.com/

Ha még aktuális a CRM kérdés, szabadon módosítható a kód is.

Üdv, RK.

Én ugyan nem tudom, hogy mi az a CRM, de először a google-t próbálnám meg, "php" és "free crm" kulcsszavakkal.

Tovabbitok egy kerdest, ha valaki szakember, akar uzleti ajanlat is lehet belole:

Keresunk olyan ingyenes CRM rendszert, ahol szabadon lehet a modulokat letrehozni, vagy olyan programozot, aki ilyet meg tudna csinalni. Regen volt sugarcrm community edition, amiben volt ilyen lehetoseg, bar korlatozott mertekben. 

Igen, a sorrend a probléma, az összes magyar települést listázom de asszem csak két település - Zubogy és Cún - rakoncátlankodik. Most ezt vagy hagyom a fenébe (a  két településen laknak összesen 860-an) vagy csinálok egy saját indexet. Nincs jelentősége csak érdekes volt erre rájönni, korábban még sosem állt semmi a ZS után :) 

Az ut8mb4_unicode_ci (illetve PHP-ben sima UTF-8) ma már problémamentes. Régen sokat szenvedtem a 8859-2-vel, ha többfélre forrásból származó adatokat kellett összehoznom egy adatbázisba vagy AJAX híváskor stb. 

az a gond, hogy a cudar a csaptelep után lesz, pedig előtte kellene legyen?

vannak olyan rendezések, amik figyelembe veszik a kétjegyű mássalhangzót. viszont azok meg a félreolvasható szavakkal buknak meg. pl a pácsóval. de ezek ritkábbak, kevesebb a gond belőle.

ennél precízebbnek csak szótárral lehet lenni, de tuti van olyan szó, ami még kétértelmű is, akkor meg csak szövegkörnyezettel együttl lehet precíznek lenni, de ez már az értelmetlenség kategória.

Vajk

Alapvetően az lenne a megoldás, hogy a szoftver ne akarjon "segíteni" mert akkor még az autórendszámokban is "felismeri" a kétjegyű betűket, és elrontja a sorrendet. Talán a latin2_general_ci vagy az utf8_general_ci lenne a legjobb.

Rájöttem, hogy nem tudom rendesen sorba rakni a magyar stringeket. A problémát főleg a ZS és a CS jelenti. 

Elvileg minden kétjegyű mássalhangzó jelenthet problémát, de szerencsére a magyarban véletlenül pont az ABC végén vannak a második betűk (SZ-nél a Z, GY-nél az Y, stb) így amúgy is a végére teszi a MySQL.

De ha ilyen szavaid vannak, hogy "cudar" vagy "zubog" akkor problem.

Milyen furcsa, hogy az angolok ezzel nem foglalkoznak, pedig ott is van th, ch stb. de nem számítanak külön betűnek.

Azt mi a kérdés? :)

Sziasztok én ezen dolgozom éppen, saját php motor, nézzétek meg, köszi:

https://www.storygo.net/

A MariaDB újraindítása után minden működik. A hiba oka ismeretlen, de megoldódott.

Ha beírom neki, hogy int, magától beírja a hosszhoz (a phpMyAdmin), hogy 10 (ami felesleges, hiszen a max. unsigned érték kb. 4Mrd = 10 számjegy). Ha kitörlöm - visszaírja. Ha megváltoztatom bármire, azt hagyja (de úgy se megy).

Nem biztos, hogy van neki ilyen adattipusa, hogy 'int(10)'. Írd ki csak úgy egyszerűen, hogy 'INT' vagy 'BIGINT'.

'napot!

Meg tudná mondani valaki, hogy ha a nem strict módban lévő MariaDB-ben egy mező unsigned int(10)-re van állítva, miért kapok Out of Range hibaüzenetet, ha le akarom tárolni a 18.692.200-at?Úgy viselkedik, mintha mediumint lenne beállítva, a hibaüzenet mellé letárol 16.777.215-öt (mert nincs strict módban).

Az értékeket, beállításokat 100× csekkoltam. Valamin átsiklottam?

Jaj, lemaradt az rn-nél a backslash, de backslash r backslash n van a programban.

Egyébként rájöttem, nagyon durva, a lezáró "?>" után második esetben volt 8 space, töröltem és azóta jó.