GDPR и маскиране на текст.

Статус
Not open for further replies.
Аз разбрах, че искаш да подобриш кода, просто след това се промениха и проблемите, които в много случаи могат да се решат с други решения.
Въпроса е, че ние не знаем това, което ти знаеш. Моите предложения са базирани на best case scenario и изведнъж се разбира, че данните са пръснати из много таблици.

Това, което ти каза и което предполагам всички останали, които четат темата са разбрали е, че вадиш един текст, който вероятно няма да надхъврли 1000 думи и имаш проблем със забавяне в маскирането.
След поста на @anonimen сподели, че има странициране и вадиш много резултати, където получаваш забавянето.
След моя пост сподели, че всъщност данните идват от много таблици.
 
Revelation каза:
Аз разбрах, че искаш да подобриш кода, просто след това се промениха и проблемите, които в много случаи могат да се решат с други решения.
Въпроса е, че ние не знаем това, което ти знаеш. Моите предложения са базирани на best case scenario и изведнъж се разбира, че данните са пръснати из много таблици.

Това, което ти каза и което предполагам всички останали, които четат темата са разбрали е, че вадиш един текст, който вероятно няма да надхъврли 1000 думи и имаш проблем със забавяне в маскирането.
След поста на @anonimen сподели, че има странициране и вадиш много резултати, където получаваш забавянето.
След моя пост сподели, че всъщност данните идват от много таблици.
Увеличете...
Ама пак казвам, че не търся нова концепция, а просто оптимизация, с която да ускоря работата на първичният клас и да повиша процента на маскирана чувствителна информация. Какво общо има структурата на базата с данни или това, че на места ще го ползвам в пагинация при визуализиране? Попитахте ме за за максимален брой символи и отговорих, че са 1000. Дали ще го ползвам в странициране или не няма отношение към темата, защото вече съм споделил кода, който търся да оптимизирам.
Дадох и нова вариация, с която повиших броя на маскираното съдържание и успях да ускоря нещата, обаче продължавам да търся начин да хващам по-голям набор от чувствителна информация, като се опитвам да не го правя с 10 цикъла в метода и да бавя излишно....
 
anonimen каза:
При такъв малък вход виждаш performance проблем? Да бяха големи данни, да пробваш с in-place замяна (чета че substr_replace прави копие на стринга, демек ако го правиш много пъти, може да товари), но за хиляда символа ми се струва странно.
Увеличете...
dakata__92 каза:
На места имам странициране, което при примерно 100 резултата ще забави с някакво време.
Увеличете...
Аз не си ги мисля. Виж ти какво отговаряш. Според това ти какво пишеш ти се отговаря.

Ако един програмист е като кон с капаци и си гледа само неговото, то от него само проблеми ще се очакват и никакъв прогрес.

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

Аз не ти казвам да имплементираш моите решения или че моите решения ще са по-добри, но бъди поне малко отворен откъм идеи и не стреляй по тези, които се опитват да ти помогнат, защото твоите питания са винаги такива и честно казано не си заслужава да ти се отговаря.
 
В ей това парче, за всяко срещане на всеки шаблон правиш ново копие (str_replace и preg_replace) на стринга:
PHP: 
foreach ($patterns as $pattern => $patternOptions) {
    $group = $patternOptions['group'] ?? 0;
    $string = preg_replace_callback(
        $pattern,
        function ($matches) use ($character, $encoding, $group) {
            $subject = $matches[0] ?? '';
            $search = $matches[$group] ?? '';
            $replace = str_repeat($character, mb_strlen($search, $encoding));
            return str_replace($search, $replace, $subject);
        },
        $string
    );
}
Предвид естеството на проблема не ми се вярва тук да е гърлото на бутилката, но ако има твърде много срещания, може копията да натежат, и вариант е да си записваш позициите на намерените срещания, които после с едно минаване да ги замениш със звездички in-place - $str[$pos] = '*'.
 
И да повторя:
anonimen каза:
Три пъти мери, един път режи! :)
Увеличете...
Та според мен пусни един бенчмарк, сложи едни логове и измери кое отнема толкова време. Дали търсенето, замяната, или нещо, за което изобщо не си се сетил досега.
 
Аз така и не получих ориентир за перформънс. Дори и да искам да помогна как да знам какво време се опитвам да бия. Според мен той въобще не ги мери тези неща.
 
Приятели, задълбахте много надалече от нещата. Темата е за маскиране на текст и оптимизацията, чрез подобряване на този процес. В момента използвам този код и се опитвам да подобря regex-ите да хващат по-голям набор информация. Опитвам се да мачна по-голям набор от видове пароли ($fnRegex('(?=\w*\d)\w{6,}', 'i')), но за момента не мога да съставя коректен регулярен израз, който да ми свърши работа.
PHP: 
/**
     * Replace patterns.
     *
     * @param string $string
     * @param string $character
     * @param string $encoding
     * @return string
     */
    private function replacePatterns(
        string $string,
        string $character = '*',
        string $encoding = 'UTF-8'
    ): string
    {
        //Add default search for space or : (before|after).
        $fnRegex = fn(
            string $regex,
            string $flags = '',
            string $lookAfter = '(?<=[\s:]|^)',
            string $lookBefore = '(?=[\s:.,]|$)',
        ) => "/$lookAfter($regex)$lookBefore/$flags";
        $patterns = [
            //Replace digits between 3 and 10 (Match and EGN: (\d{2})(0[1-9]|1[0-2])(0[1-9]|[1-2]\d|3[0-1])(\d{4})).
            $fnRegex('\d{3,10}') => [
                'group' => 1,
            ],
            //Replace any word with at least one digit (AXZK5W, kZK5vW).
            $fnRegex('(?=\w*\d)\w{6,}', 'i') => [
                'group' => 1,
            ],
            //Replace IBAN
            $fnRegex('[a-z]{2}\d{2}[a-z\d]{1,30}', 'i') => [
                'group' => 1,
            ],
        ];
        foreach ($patterns as $pattern => $patternOptions) {
            $group = $patternOptions['group'] ?? 0;
            $string = preg_replace_callback(
                $pattern,
                function ($matches) use ($character, $encoding, $group) {
                    $subject = $matches[0] ?? '';
                    $search = $matches[$group] ?? '';
                    $replace = str_repeat($character, mb_strlen($search, $encoding));
                    return str_replace($search, $replace, $subject);
                },
                $string
            );
        }

        return $string;
    }

1682016637266.png
 
dakata__92 каза:
В момента използвам този код и се опитвам да подобря regex-ите да хващат по-голям набор информация
Увеличете...
А тук вече и аз се обърках :D

Досега мислех, че питаш, как да си ускориш кода, понеже ти върви твърде бавно. Именно затова предлагах да замениш копията с in-place модификации и писах да измериш коя част бави, за да знаем къде да предлагаме оптимизации.

А ти всъщност питаш как функционално да обогатиш решението да работи за повече случаи? Ако това е въпросът, на първо време ми изглежда най-смислено да си извадиш от истинските данни 5,10,20 (колкото ти стигнат нервите) конкретни примера, да изведеш правила за всеки от тях, и вече оттам нататък да огледаш кое е общото и евентуално да намалиш случаите, ако са ти много.
 
Ако погледнете от първата страница тези постове (едно, две) ще видите, че още на нея съм сменил изцяло логиката за хващане и замяна на стринговете със звездички. Тоест вече съм подобрил и ускорил нещата. Последният ми коментар в който споделям код е на тази страница (тук) и на практика показвам до къде съм стигнал. Не мога да стоя и да се обяснявам, като ученик и да чакам друг да ми свърши работата. Приключвам с обяснителните отговори.

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

И аз, и @anonimen ти предложихме да следваш определен шаблон според информацията, която ТИ имаш.
 
Да, съгласен съм, че тук няма дискусия по кода, който съм споделил и променям.

За жалост, Туриста не е това, което беше преди.
Заключвам темата.
 
Статус
Not open for further replies.

Back
Горе