pa3k napsal/a:
-------------------------------------------------------
> Práve naopak, chyba je ak tam nie je mb_ pretože
> inak by jeden znak vo viacbytovom kódovaní mohol
> byť rozdelený po bajtoch a nie po znakoch.


Já do toho nevidím, nicméně úprava, kterou popisuje Lonanek, můj problém vyřešila.

Použití na začátku smyčky je nešťastné, protože opravdu dojde ke zkrácení celého řetězce o "nadbytečné" bajty diakritiky.
Pře FOR smyčkou určitě projít délku celého řetězce - včetně diakritiky ve vícebajtovém kódování a teprve při porovnávání maximální délky slova použít mb_strlen

Ono se tam vlastně "tlučou" dvě věci:
1. kontrola KAŽDÉHO bajtu na platnost odkazu
2. kontrola na maximální délku slova.

Touto rutinou OPRAVDU dojde ke zkrácení řetězce...

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Skôr by som tipoval na nesprávne nastavenie [http://www.php.net/manual/en/function.mb-internal-encoding.php]

pa3k vím co máš na mysli.

Tohle tam potřebuje dostat pouze počet znaků (včetně započítání vícebajtového jako jeden znak)

if(!in_array($str{$i}, $wordEndChars)){
                $count++;
                if($count==$maxLength){
                    $newStr .= $char;
                    $count = 0;
                }
            }else{
                $count = 0;
            }

ale při procházení a kontrolou na odkaz musí projít všechny znaky.
Jinak je for-next zkrácen právě na počet znaků - počet dvojbajtových znaků. Výsledek je pak nechtěné zkrácení celého stringu.

Samozřejmě touto rychlou úpravou je pak zase ohrožena maximální délka slova (pokud obsahuje diakrititku)

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Celkem upraveno 2×. Poslední úprava Lonanek v 13.05.2013 16:36.

Takzže pozerám do kódu - toto je verzia,ktorá je NESPRÁVNA - nemám čťas to testovať, no spôsob použitia $str{$i} je pre multibyte stringy nevhodný.

// nahrada za wordwrap, ktory rozsekava dlhe URL, cim znefunkcni odkazy
function breakLongWords($str, $maxLength, $char){
    $wordEndChars = array(" ", "\n", "\r", "\f", "\v", "\0");
    $count = 0;
    $newStr = "";
    $openTag = false;
    for($i=0; $i<mb_strlen($str); $i++){
        $newStr .= $str{$i};
        if($str{$i} == "<"){
            $openTag = true;
            continue;
        }
        if(($openTag) && ($str{$i} == ">")){
            $openTag = false;
            continue;
        }
        if(!$openTag){
            if(!in_array($str{$i}, $wordEndChars)){
                $count++;
                if($count==$maxLength){
                    $newStr .= $char;
                    $count = 0;
                }
            }else{
                $count = 0;
            }
        }
    }//End for
    return $newStr;
}

funckcia by mala vyzerať takto:

// nahrada za wordwrap, ktory rozsekava dlhe URL, cim znefunkcni odkazy
function breakLongWords($str, $maxLength, $char){
    $wordEndChars = array(" ", "\n", "\r", "\f", "\v", "\0");
    $count = 0;
    $newStr = "";
    $openTag = false;
    for($i=0; $i<mb_strlen($str); $i++){
        $curLtr = mb_substr($str, $i, 1);
        $newStr .= $curLtr;
        if($curLtr == "<"){
            $openTag = true;
            continue;
        }
        if(($openTag) && ($curLtr == ">")){
            $openTag = false;
            continue;
        }
        if(!$openTag){
            if(!in_array($curLtr, $wordEndChars)){
                $count++;
                if($count==$maxLength){
                    $newStr .= $char;
                    $count = 0;
                }
            }else{
                $count = 0;
            }
        }
    }//End for
    return $newStr;
}

mb_ funckie zabezpečia správny prechod po znakoch, nie po bajtoch.

Tohle si myslím že je již správně.
Jsou vyhodnocovány znaky, nikoliv bajty (jak bylo moje rychlé řešení problému) a tím by nemělo dojít ke zkrácení celého příspěvku.

OTESTUJI a dám vědět...

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Niekde nesmie byť použitá indexácia spôsobom: $str{$i} , pretože tá nefunguje multibajtovo ale zoberie jeden Byte. V tom bol asi problém.

Ak môžeš, ukáž mi nesprávne fungovanie tu: [http://www.kvalitne.sk/koncepty/282/comment.php?akce=fullview&cisloclanku=2012030002]



Celkem upraveno 1×. Poslední úprava pa3k v 13.05.2013 16:41.

Ano přesně tak.

načtením znaku do $curLtr pomocí mb_substr je řešeno načtení znaku, nikoli byte.


EDIT:
Super a velice rychlá reakce. Díky za všechny pa3k.

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Celkem upraveno 1×. Poslední úprava Lonanek v 13.05.2013 16:56.

Lonanek napísal/a:
-------------------------------------------------------
> Tohle si myslím že je již správně.
> Jsou vyhodnocovány znaky, nikoliv bajty (jak bylo
> moje rychlé řešení problému) a tím by nemělo dojít
> ke zkrácení celého příspěvku.

Obávam, sa, že pri tvojej oprave môže nastať nesprávne vyhodnotenie v prípade ak dodatočné bajty niektorého multibyte znaku budú obsahovať niečo, čo je zhodné s riadiacim znakom, napríklad ] alebo <> také znaky pravdepodobne existujú, takže je predpoklad, že by to niekde blblo.

nemám čas to štutdotať, no k celelému stringu by sa malo pristupovať multibytovo, nikde nesmie byť indexácia pomocou {} - inak hrozia problémy.

ano proto jsem psal dočasná....
budu kontaktovat žadatele s opravou a zašlu mu opravený astdlib_comment.php včetně této úpravy mb_subst() - to je správné řešení. Prostě jseš profík, mne to hned takto netrklo a asi by mi chvíli trvalo než by se k tomu dopracoval... byť cesta byla správným směrem uvažování...

Samozřejmě se nesmí vyhodnocovat jednotlivé bajty, to by bylo opravdu hrozbou...

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Tá chybná verzia asi nie je opravená v RC7, tých opráv je tam viac, takže to musím skompletizovať.

Ne v RC7 je to co jsi uváděl jako první - tedy bez mb_substr().
Tedy # phpRS Admin Standard Comment library 1.0.6

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Lonanek napsal/a:
-------------------------------------------------------
> EDIT:
> Standardně je kódování pro UTF-8 upřednostňováno,
> doporučil bych vše překódovat do tohoto kódování.
>
Zdravím vespolek.
A prosím o radu.

Pokud vím tak autor původně vydával phpRS ve třech druzích kódování. Použil jsem tuším 2.5 iso-8859-2.
Nyní jsem si řekl, že aktualizuji na "vámi" zhotovenou verzi. Velké díky všem.
Udělal jsem si již v dubnu export. ("Dnes" jsem zjistil, že ve v. 2.8.1 jsem to neošéfoval nebo to nedělalo, co má.)
"Dnes" jsem to poupravoval ručně.
Překódoval jsem do UTF8, smáznul databázi, znovu vytvořil s nastavením utf8 a nalil zpět.
Web chodí, ale tomu nerozumím. Na stránce je nastaveno Latin2, v databázi je určitě v kódování utf8 a přesto se stránky zobrazují korektně. No to samozřejmě nevadí. To je konec konců super.
Rád bych to dotáhl do konce dle doporučení "vše překódovat". Ale nevím jak.
Aktualizace dává na výběr (jsem ještě nespouštěl ani nenahrál nové soubory). Ale mám adresáře plné původních souborů.
Jak to tedy překódovat, prosím? Diskuzi jsem pročetl celou.



Celkem upraveno 2×. Poslední úprava franta v 11.12.2013 19:40.

V config.php je nastavenie, ktoré zapezpečí, že aj keď je databáza interne v UTF-8, komunikuje v požadovanom kódovaní, ktoré môže byť odlišné. Toto zabezpečuje samotná databáza. Po upgrade na 2.8.2 (momentálne je najnovšia 282_rc8), sa použijú súbory v UTF-8, ak sa prekóduje databáza do UTF-8 a aj layout bude v UTF-8, databáza nebude musieť pri komunikácii transformovať kódovanie.

Odporúčam otestovať migráciu na kópii systému a databázy niekde na subdoméne alebo na lokále a otestovať prechod na prípadné problémy.

Děkuji. Tohle jsem zatím nezkusil. Před obědem jsem se rozhodl pro novou instalaci. Třeba to už bude konečné.
Ale do adminu jsem se dostal až po několikátém výmazu všeho.
Na jaké znaky je nyní omezeno heslo?
Chtěl jsem použít:
S+]Gl+^O=L;fz_v-']KP+24
ale to neprojde, to už nyní vím jistě.

franta napísal/a:
-------------------------------------------------------

> Na jaké znaky je nyní omezeno heslo?
> Chtěl jsem použít:
> S+]Gl+^O=L;fz_v-']KP+24
> ale to neprojde, to už nyní vím jistě.

V 282 nie je žiadne obmedzenie znakov, do čistej inštalácie mi tvoje heslo vpohode išlo zmeniť. neberie ti ho administrácia alebo inštalátor?

Aha, tak som skúsil aj login a ten neprešiel. Problém robí asi apostrof, mrknem do kódu.

Takže ešte sa našla chyba v autor.php nesprávny postup "ošetrenia" je v tom, že najprv sa escapuje a potom sa počíta hash. Tým pádom do výpočtu hashu ide heslo, ktoré za predpokladu, že obsahuje uvodzovky alebo apostrof, nezodpovedá tomu, čo užívateľ zadal na vstupe. Chyba je to dosť blbá, ale nie kritická. Narýchlo opravený súbor je tu: [https://www.kvalitne.sk/koncepty/282/autor.rar] Keď to pozriem dôkladnejšie, opravu zverejním v 282.

Mně to nešlo ani tam, ani tam.
Jedu na Linuxu a Firefoxu.