вторник, 4 апреля 2023 г.

Регулярные выражения в postgresql

Сегодня поразбираемся с тем, как в postgresql работать с регулярными выражениями.

Исходные данные: таблица users следующего вида:

id | first_name | full_name | last_name | email ------------------------------------------------------------------- 1 | Иван | Иван Дмитриев | - | ivan@mail.ru 2 | Ольга | Ольга Корнева | - | ko@ya.ru 3 | Вячеслав | Вячеслав Домашнев | - | domv@yandex.ru 4 | Игорь | Игорь Черников | - | ichern@gmail.com 5 | Галина | Галина Горных | - | Galina@Yandex.ru

Начнем с простейшего - выберем все записи, где поле email содержит подстроку ya.

пятница, 17 июня 2022 г.

Константы и пространства имен в php

Сегодня поисследуем использование пространств имен (они же неймспейсы) для объявления констант и обращения к ним.

Как сказано в мануале:

классы (включая абстрактные и трейты), интерфейсы, функции и константы зависят от пространства имен.

То есть, если зарегистрировать константы с одинаковыми именами в нескольких неймспейсах, в том числе и глобальном, то за это ничего не будет, и обращение к каждой из констант будет работать без ошибок.

Проверим:

namespace FirstNs {
    const SUPER_VALUE = 'NS-1';
}

namespace SecondNs {
    const SUPER_VALUE = 'NS-2';
}

namespace {
    const SUPER_VALUE = 'NS-GLOBAL';
    var_dump(
        SUPER_VALUE,
        FirstNs\SUPER_VALUE,
        SecondNs\SUPER_VALUE,
    );
}

// Вывод:
// string(9) "NS-GLOBAL"
// string(4) "NS-1"
// string(4) "NS-2"

Ровно то, что нужно.

Но что если мы хотим определить константы методом define.

Не проблема, пробуем написать так:

namespace FirstNs {
    define('SUPER_VALUE', 'NS-1');
}

namespace SecondNs {
    define('SUPER_VALUE', 'NS-2');
}

namespace {
    define('SUPER_VALUE', 'NS-GLOBAL');
    var_dump(
        SUPER_VALUE,
        FirstNs\SUPER_VALUE,
        SecondNs\SUPER_VALUE,
    );
}

Запускаем и видим:

Warning: Constant SUPER_VALUE already defined in ...
Warning: Constant SUPER_VALUE already defined in ...
Fatal error: Uncaught Error: Undefined constant "FirstNs\SUPER_VALUE" in ...

Судя по всему, мы пытаемся три раза определить одну и ту же константу в глобальном неймспейсе. Что же делать?

А просто указать нужный неймспейс при определении константы, благо php это позволяет:

namespace FirstNs {
    define('FirstNs\\SUPER_VALUE', 'NS-1');
    // или
    define(__NAMESPACE__ . '\\SUPER_VALUE', 'NS-1');
    
}

namespace SecondNs {
    define('SecondNs\\SUPER_VALUE', 'NS-2');
}

namespace {
    define('SUPER_VALUE', 'NS-GLOBAL');
    var_dump(
        SUPER_VALUE,
        FirstNs\SUPER_VALUE,
        SecondNs\SUPER_VALUE,
    );
}

// Вывод:
// string(9) "NS-GLOBAL"
// string(4) "NS-1"
// string(4) "NS-2"

Можно даже пойти дальше и в одном неймспейсе определить константу другого неймспейса:

namespace FirstNs {
    define('SecondNs\\SUPER_VALUE', 'NS-2-1');
}

namespace SecondNs {
    define('FirstNs\\SUPER_VALUE', 'NS-1-2');
}

Делать так в продакшене категорически не рекомендуется.

Итак, сегодня мы разобрались с тем, как определять константы с учетом неймспейсов, используя как ключевое слово const, так и функцию define.

вторник, 8 февраля 2022 г.

Длина строк в Go

Этот пост родился из-за странного поведения валидатора Length из пакета ozzo-validation.

Следуя руководству, можно зарегистрировать, например, такой валидатор для строк:

data := "Некоторая строка"
err := validation.Validate(data,
    validation.Required,
    validation.Length(10, 16),
)
fmt.Println(err)

И так как в строке у нас кириллические символы, и более того - кодировка строки utf-8, то валидация не пропускает строку, падая с ошибкой "the length must be between 10 and 16". Почему так происходит, ведь валидируемая строка содержит ровно 16 символов?

Для того, чтобы понять почему валидация выдает ошибку - придется сходить в исходный код валидатора. Поиски приводят к тому, что для определения длины валидируемой строки используется метод Len() из типа reflect#Value. Путешествие дальше приводит нас к тому, что свойство Len вычисляется с помощью встроенной функции len. А как сообщает мануал:

The len built-in function returns the length of v, according to its type:
String: the number of bytes in v.

Следовательно, валидация на основании длины строки в байтах нас не устраивает, так как в случае многобайтных кодировок (коей является utf-8) число символов в строке не равно числу байт в этой же строке.

Хотелось бы, чтобы был метод типа utfLen(). И он есть в пакете unicode/utf8, правда, с немного другим названием - RuneCountInString. И о чудо, данный метод даже используется в валидаторе, если установить дополнительный флаг rune. И это можно сделать применив валидатор RuneLength.

Обновленный код:

data := "Некоторая строка"
err := validation.Validate(data,
    validation.Required,
    validation.RuneLength(10, 16),
)
fmt.Println(err)

Валидация отрабатывает как и ожидается, выводя <nil>.

И не забудьте написать для этого случая тест (ну или хотя бы комментарий), чтобы пытливый программист, использующий код после вас, не смог бы заменить RuneLength на Length, думая, что "и так сойдёт".

P.S. Больше разъяснений про длины строк можно почитать в этом ответе на stackoverflow.

P.P.S. Отличное видео на Youtube, раскрывающее суть кодировок.

среда, 4 августа 2021 г.

Интерпретация переменных в строке

Сегодня еще один пост о всяких веселых способах написать код в php.

Всем известно (а если не известно, то читайте мануал), что в строках в двойных кавычках переменные и некоторые другие выражения обрабатываются и вместо этой переменной\выражения выводится результат. Простейший пример:

$number = 42;
echo "Number is $number";
// outputs "Number is 42"

Теперь зададимся вопросом - а можно ли как-то интерпретировать в строках какие-либо выражения? Например, сложение двух чисел. Естественно, написание в лоб приводит к ошибкам:

$a = 42;
$b = 24;
echo "Sum is {$a + $b}";

Что же делать? Понятно, что можно завести класс, объявить в нем метод суммирования, но это как-то много кода:

class Summator {
    public function sum($a, $b) {
        return $a + $b;
    }
}

$a = 42;
$b = 24;
$o = new Summator();
echo "Sum is {$o->sum($a, $b)}";
// outputs "Sum is 66"

Подумав еще немного можно прийти к следующему - создадим переменную, которая будет хранить анонимную функцию, и в строке вызовем эту переменную:

$a = 42;
$b = 24;
$sum = function($a, $b) { return $a + $b; };
echo "Sum is {$sum($a, $b)}";
// outputs "Sum is 66"

А с учетом стрелочных функций (с версии 7.4), которые имеют доступ к переменным родительской области видимости, код упрощается до такого:

$a = 42;
$b = 24;
$sum = fn() => $a + $b;
echo "Sum is {$sum()}";
// outputs "Sum is 66"

Ну и наконец самая безумная версия:

$a = 42;
$b = 24;
echo "Sum is ${0 * ${0}=$a+$b}";
// outputs "Sum is 66"

Что же здесь происходит?

Здесь мы пытаемся вывести переменную с названием, которое получается как результат умножения 0 на переменную ${0}. А значение ${0} является суммой значений $a и $b. Почему php выполняет присваивание значения переменной при парсинге строки - не знаю. Но тем не менее, мы получаем, что переменной ${0} присваивается 66. А так как результатом присваивания является присвоенное значение, то 0 * ${0}=$a+$b превращается в 0 * 66, и выражение ${0 * ${0}=$a+$b} сворачивается в ${0}. То есть мы хотим вывести переменную с названием 0, которую мы уже определили ранее, как сумму $a и $b. Вот и получаем в выводе 66.

Спасибо за внимание и никогда не пишите такой код)

пятница, 18 июня 2021 г.

Ликбез по подсчету количества частей sms

Еще один специфический пост - на сей раз расскажу вам как правильно подсчитывать количество sms-ок, необходимых для отправки того или иного текста.

Вводные данные: текст, который вы хотите отправить с помощью sms-сервиса, может быть достаточно большим, например, содержать 150-200 символов. Сотовый оператор (или другой sms-провайдер) не может отправить такой длинный текст как одну sms-ку, и потому разбивает ее на несколько частей. В зависимости от кодировки символов в тексте максимальная длина части разная. Отправка сообщения частями не значит, что получатель получит 2 разные sms-ки. В телефоне получателя части соединятся в одну sms-ку. Поэтому для получателя сообщение любой длины будет выглядеть как одна sms-ка.

А вот отправителю сложнее. Если вы используете какое-то стороннее API для отправки sms, то будьте уверены, что длинное сообщение будет отправлено частями. Таким образом, если вы снимаете со своего пользователя сколько-то денег за отправку сообщения, но при этом не учитываете факт отправки по частям, то баланс может не сойтись. Кстати, интересный факт - не все sms-провайдеры держат информацию о правилах деления на части в более-менее открытом доступе. У кого-то придется пошерстить мануал или FAQ, кому-то придется задать вопрос в саппорт. (Из личного опыта интеграции как минимум с 7-8 провайдерами, один из которых - заграничный).

В случае если в сообщении есть хотя бы один символ кириллицы - то максимальная длина одного сообщения составит 70 символов. Точнее даже не символов, а позиций (но об этом позже). То есть 70 и меньше символов будут отправлены как одна sms-ка. Если символов становится больше 70, то провайдер начнет разбивать сообщение на части. Обычно длина каждой части - 67 символов. 70 и 67 это общепринятые значения на данный момент, но лучше уточнить эти лимиты в документации оператора\провайдера.

То есть, если ваше сообщение состоит из 90 символов, то провайдер отправит его как две части: первая часть длиной 67 символов, вторая - 23 символа. Сообщение длиной 71 символ не удастся отправить как одно, тут тоже две части - 67 + 4. Так что либо укладывайтесь в 70, либо пишите еще больше текста, все равно за вторую часть придется платить

Переходим к сообщениям, написанным без использования кириллицы. Здесь лимит длины сообщения составляет уже 160 символов на одну смс и 153 символа на часть (хотя я встречал одного провайдера со 157 символами на часть). Расчет частей аналогичен: сообщение из 190 символов будет состоять из двух частей: 153 и 37 символов каждая.

Следующий важный момент: как определить какую из пар (70/67 или 160/153) использовать для расчета числа частей? Понятно, что если в тексте сообщения есть хотя бы один кириллический символ, то выбор очевиден - 70/67. В остальных случаях используем 160/153. Однако, копнем дальше - что делать, если у вас какой-нибудь многоязычный сервис и хочется корректно рассчитывать число частей для разных языков, даже с учетом национальных особенностей? Здесь на помощь приходит тот факт, что базовой кодировкой сообщений, отправляемых через sms, является GSM 03.38. Таблица символов данной кодировки содержит помимо некоторых ASCII-символов (цифры, латинский алфавит и некоторые знаки препинания) также символы, которые не относятся к ASCII. Пример: испанская ñ или немецкое ß хоть и не входят в ASCII-символы, но в смске займут один символ в отличие от кириллических символов.

Приглядевшись к таблице символов кодировки GSM 03.38 можно заметить, что в ней есть некоторые символы, которые занимают две позиции в смске. К таким символам относится, например, знак евро . Это значит, что если в тексте сообщения есть 69 кириллических символов и семидесятым символом идет знак евро, то формально в сообщении 71 символ, так как знак евро занимает две позиции. Тут тоже надо быть внимательным, чтобы правильно вычислять число частей и тарифицировать отправку.

Как следует из всего вышесказанного, для расчета числа частей надо написать собственный, не самый сложный код. Однако, можно использовать уже имеющиеся библиотеки. Для php можно использовать, например, мной же и написанную библиотеку sms-charset-detector, которая определяет кодировку сообщения. В зависимости от результата, вы можете выбрать какую пару чисел использовать. Для javascript можно использовать, например, sms-counter, здесь можно сразу увидеть число частей, на которое будет разбито сообшение.

Итак, в данном посте вы познакомились с ограничениями на отправку sms-сообщений и узнали основные факты, необходимые для корректного расчета количества частей sms-сообщения.

понедельник, 3 мая 2021 г.

Приведение переменной к массиву

Сегодня краткий пост о том, как привести переменную какого-то типа к типу массив (array).

Итак, первый вариант, сразу приходящий в голову:

$var = 42;
$varArray = [$var];

Он хорош до тех пор, пока $var не является массивом. В случае с массивом мы получаем двумерный массив. Естественно, это нас не устраивает. Поэтому улучшаем конструкцию:

$var = 42;
if (!is_array($var)) {
    $var = [$var];
}

Но тут многовато строк, можно ли попроще?

Вспоминаем, зачем мы здесь реально собрались, и используем приведение типов:

$var = 42;
$varArray = (array) $var;
print_r($varArray);
// Вывод: Array
// (
//   [0] => 42
// )

$var = [42, 42];
$varArray = (array) $var;
print_r($varArray);
// Вывод: Array
// (
//   [0] => 42
//   [1] => 42
// )

На этом всё.

четверг, 11 марта 2021 г.

Doctrine: ошибка парсинга запроса

На самом деле пост довольно специфический. Начну с описания проблемы, встреченной мной уже минимум два раза. Имеем обычный с виду код выполнения запроса:

$conn = $this->getEntityManager()->getConnection();
$conn->executeQuery($query, [
    'param1' => 42,
    'param2' => 'forty-two',
    'param3' => '%some_other_data%',
]);

При выполнении этого кода ловим ошибку типа такой:

SQLSTATE[08P01]: <<Unknown error>>: 7 ERROR:  bind message supplies 0 parameters, but prepared statement "pdo_stmt_000...." requires 3

Казалось бы, что может пойти не так? Мы взяли запрос с именованными параметрами, взяли данные для подстановки и передали всё это в Доктрину. Однако, практика показывает, что при неком специфичном тексте запроса Доктрина не справляется с парсингом текста запроса и считает, что в данном запросе нет именованных параметров. Исходя из моего опыта, такое случалось на запросах с огромным количеством :, так как именно двоеточие определяет начало именованного параметра.

В качестве запроса, ломающего Доктрину можно привести такой (использую postgresql, текст запроса очень приблизительный):

SELECT
    id,
    value::FLOAT,
    exec_date
FROM (
    VALUES
    (
        8095,
        41,
        '2020-01-02 10:48:17'
    ),
    --- Таких values тут сотни две
) as vs (id, value, exec_date)
JOIN
    some_table t ON vs.id = t.foreign_id::INT
WHERE
   t.created_at::TIMESTAMP + interval '3600 second' <= vs.executed_at::TIMESTAMP
   AND t.field_one = :param1
   AND t.field_two = :param2
   --- и еще что-нибудь

Найденное мной быстрое решение - это поменять именованные параметры (:param1) на позиционные (?), с такими данными Доктрина успешно справляется. Если есть желание - можете самостоятельно нырнуть в дебри и поковыряться в регулярках, а возможно где-то уже висит issue (но это не точно), или в третьей версии Доктрины это вообще уже исправлено.