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

    • ava Мистер Хэнки 09.09.2012 11:58 # +5

      s/[^A-Za-z0-9\@\. ]//g
      Ответить

      • ava MAKAKA 28.08.2020 02:02 # 0

        а как с юникодом? русские буквы-то остануца

        Это вся Чеховская Кибальчеховская знает.
        Ответить

        • ava XYPO3BO3 28.08.2020 05:25 # 0

          Русские буквы останутся, только если у тебя дебильная кодировка вроде UTF-7.
          Ответить

          • ava MAKAKA 28.08.2020 15:28 # 0

            русские буквы очевидно не поподут в a-zA-Z
            Ответить

            • ava bormand 28.08.2020 15:31 # 0

              Ну да, и удалятся. Как и любые другие символы, не описанные в регулярке. Там же негативное множество.
              Ответить

          • ava bormand 28.08.2020 15:42 # 0

            Обычно регуляркам похуй на кодировки, они с юникодом работают. Гонять регулярки на байтовом представлении строки - ССЗБ.
            Ответить

            • ava MAKAKA 28.08.2020 15:46 # 0

              я бы сказал, что они работают со строками. С таким понятием, как "буква" или "код поинт".

              В перле есть охуительные штуки для ругляркок, например \p{IsCyrillic} ;)
              Ответить

            • ava XYPO3BO3 28.08.2020 22:13 # 0

              Нет, не похуй. Например, если в «PHP» я не укажу модификатор «u», то функции семейства preg не узнают, что им на вход подали «UTF-8». Они будут думать, что на входе локальная восьмибитная кодировка.
              Ответить

              • ava bormand 29.08.2020 10:53 # 0

                Есть реальная причина не указывать u в 2020?
                Ответить

                • ava XYPO3BO3 29.08.2020 12:13 # 0

                  Даже в 2010-м не было реальной причины. Я подозреваю, что даже «ВК», который отдаёт страницы в «charset=windows-1251», внутри всё хранит и обрабатывает в «Unicode» (он же без проблем выводит текст на грузинском и на армянском, хотя в HTML высирает в виде энтитис).

                  Зачем в «PHP» оставили возможность работы с однобайтовыми символами, я не знаю. Может быть, есть реальные примеры, где нужно жёстко экономить память?
                  Ответить

              • ava guest8 29.08.2020 15:50 # −999

                показать все, что скрытоvanished
                Ответить

                • ava Pyatachok 29.08.2020 16:00 # 0

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

    • ava Lure Of Chaos 09.09.2012 14:53 # +1

      > uncleanString
      на люстре
      Ответить

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