1. Perl / Говнокод #11730

    −154

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    sub makeCleanString {
            my ($self, $uncleanString) = @_;
            $uncleanString = lc($uncleanString);
            my @allowedChars = ("a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "@", ".", " ");     
                 
             my $cleanString = "";
                 
             # SPLIT THE uncleanString INTO AN ARRAY
             my @usernameAR = split(//, $uncleanString);
             my $usernameARcount = @usernameAR;
             my $run=0;
             for ($run=0;$run<$usernameARcount;$run++) {
                 if(grep $_ eq $usernameAR[$run], @allowedChars) {
                     $cleanString .= $usernameAR[$run];
                 }
             }
             return $cleanString;
        }

    Так же есть подобные методы только для букв и цифр

    Запостил: LiteError, 09 Сентября 2012

    Комментарии (14) RSS

    • s/[^A-Za-z0-9\@\. ]//g
      Ответить
      • а как с юникодом? русские буквы-то остануца

        Это вся Чеховская Кибальчеховская знает.
        Ответить
        • Русские буквы останутся, только если у тебя дебильная кодировка вроде UTF-7.
          Ответить
          • русские буквы очевидно не поподут в a-zA-Z
            Ответить
            • Ну да, и удалятся. Как и любые другие символы, не описанные в регулярке. Там же негативное множество.
              Ответить
          • Обычно регуляркам похуй на кодировки, они с юникодом работают. Гонять регулярки на байтовом представлении строки - ССЗБ.
            Ответить
            • я бы сказал, что они работают со строками. С таким понятием, как "буква" или "код поинт".

              В перле есть охуительные штуки для ругляркок, например \p{IsCyrillic} ;)
              Ответить
            • Нет, не похуй. Например, если в «PHP» я не укажу модификатор «u», то функции семейства preg не узнают, что им на вход подали «UTF-8». Они будут думать, что на входе локальная восьмибитная кодировка.
              Ответить
              • Есть реальная причина не указывать u в 2020?
                Ответить
                • Даже в 2010-м не было реальной причины. Я подозреваю, что даже «ВК», который отдаёт страницы в «charset=windows-1251», внутри всё хранит и обрабатывает в «Unicode» (он же без проблем выводит текст на грузинском и на армянском, хотя в HTML высирает в виде энтитис).

                  Зачем в «PHP» оставили возможность работы с однобайтовыми символами, я не знаю. Может быть, есть реальные примеры, где нужно жёстко экономить память?
                  Ответить
              • показать все, что скрытоvanished
                Ответить
                • Прикинь, уже в «PHP4» (т. е. где-то 20 лет назад) появились функции для полноценной работы с юникодными строками (правда, с поддержкой юникодных имён файлов была беда, её допилили только в «PHP7»), но зачем-то оставили старое говно, прибитое к однобайтовым кодировкам, и пыхомакаки продолжили пользоваться им.
                  Ответить
    • > uncleanString
      на люстре
      Ответить

    Добавить комментарий