Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Как работает эта регулярка? [2]
Покинул форум
Сообщений всего: 166
Дата рег-ции: Сент. 2011
Помог: 0 раз(а)
Мелкий пишет:
Doox911 пишет:
\xd1\x82 - этo байты?
Это байты в распространённой hex записи.
Пользуясь какой-нибудь таблицей кодирования можно попробовать представить в виде символов.
Для utf8 это будет один символ т, для cp1251 - строка из двух символов: "С‚", строка "Ń‚" в cp1250 и так далее по куче разных кодировок с различным эффектом.
Doox911 пишет:
Не совсем понял что за d0 b0:
Тоже байты в hex виде. Без \x и с пробелами обычно читается легче человеком.
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Ничего не изменится, если файл скрипта сохранён как utf8.
"\xd1\x82" - это ровно 'т' и есть.
----- PostgreSQL DBA
Doox911
Отправлено: 07 Августа, 2018 - 08:27:17
Частый гость
Покинул форум
Сообщений всего: 166
Дата рег-ции: Сент. 2011
Помог: 0 раз(а)
Т.е. получается при добавлении модификатора u регулярка сама поймёт в какой кодировке сравнивать? Или будет сравнивать исходя из того что в скрипте предполагается, что символ пришел в кодировке utf8 и скрипт сохранён в той же кодировке?
Мелкий
Отправлено: 07 Августа, 2018 - 10:43:10
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Doox911 пишет:
сама поймёт в какой кодировке сравнивать
Это в принципе невозможно.
Если кодировка текста не известна заранее - то её можно пытаться только угадать. Потому что байты-то везде одни и те же, а кодировок - суть таблиц преобразования произвольного байта в представление на экране - огромное множество наплодили.
Флаг u подписан в мануале и маппится в коде в PCRE_UTF8, т.е. регулярка будет работать исходя из предположения, что и паттерн и текст переданы в utf8
----- PostgreSQL DBA
Doox911
Отправлено: 07 Августа, 2018 - 11:18:19
Частый гость
Покинул форум
Сообщений всего: 166
Дата рег-ции: Сент. 2011
Помог: 0 раз(а)
Мелкий пишет:
Doox911 пишет:
сама поймёт в какой кодировке сравнивать
Это в принципе невозможно.
Если кодировка текста не известна заранее - то её можно пытаться только угадать. Потому что байты-то везде одни и те же, а кодировок - суть таблиц преобразования произвольного байта в представление на экране - огромное множество наплодили.
Флаг u подписан в мануале и маппится в коде в PCRE_UTF8, т.е. регулярка будет работать исходя из предположения, что и паттерн и текст переданы в utf8
Т.е. корректно будет работать если html, скрипты и база в UTF-8? UTF-8 и utf-8_general_ci одно и тоже?
Мелкий
Отправлено: 07 Августа, 2018 - 15:22:56
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Ответ простой: да, чтобы не было граблей всё должно быть в utf8. utf8_general_ci - это collate в mysql для utf8
Ответ правильный:
Doox911 пишет:
Т.е. корректно будет работать если html, скрипты и база в UTF-8?
Для PCRE будет уже достаточно если поисковый паттерн и текст в котором ищем в UTF8, всё остальное может быть в других кодировках.
В рамках своего проекта чтобы не иметь головной боли с кодировками - да, использовать utf8. При необходимости в общении с внешними системами на каких-то других кодировках - перекодируйте данные через iconv или mb_convert_encoding сразу при приёме данных.
Doox911 пишет:
UTF-8 и utf-8_general_ci одно и тоже?
Скорей всего речь о mysql и тогда правильный ответ будет на настоящее время - лишь частично.
utf8_general_ci - это правила сравнения и сортировки для utf8, данные для этого соответственно лежат в utf8. А дальше исторический казус:
Изначально utf8 был от 1 до 6 байт на символ, но в mysql решили что им хватит 3 байт и тихо ломали не влезающие в 3 байта символы.
Потом utf8 стандарт урезали до 4 байт максимум.
Потом в Mysql 5.5.(что-то) сделали грубый костыль - кодировку названную utf8mb4, который в отличии от исторически дефектного в mysql utf8 умеет в 4 байт на символ и соответствует стандарту. В будущем в mysql алиас кодировки utf8 планируют переключить с utf8mb3 на utf8mb4. Но до тех пор - utf8 как стандарт и utf8 как кодировка в mysql совпадают только на 75%.
----- PostgreSQL DBA
Doox911
Отправлено: 08 Августа, 2018 - 07:49:16
Частый гость
Покинул форум
Сообщений всего: 166
Дата рег-ции: Сент. 2011
Помог: 0 раз(а)
Мелкий пишет:
Ответ простой: да, чтобы не было граблей всё должно быть в utf8. utf8_general_ci - это collate в mysql для utf8
Ответ правильный:
Doox911 пишет:
Т.е. корректно будет работать если html, скрипты и база в UTF-8?
Для PCRE будет уже достаточно если поисковый паттерн и текст в котором ищем в UTF8, всё остальное может быть в других кодировках.
В рамках своего проекта чтобы не иметь головной боли с кодировками - да, использовать utf8. При необходимости в общении с внешними системами на каких-то других кодировках - перекодируйте данные через iconv или mb_convert_encoding сразу при приёме данных.
Doox911 пишет:
UTF-8 и utf-8_general_ci одно и тоже?
Скорей всего речь о mysql и тогда правильный ответ будет на настоящее время - лишь частично.
utf8_general_ci - это правила сравнения и сортировки для utf8, данные для этого соответственно лежат в utf8. А дальше исторический казус:
Изначально utf8 был от 1 до 6 байт на символ, но в mysql решили что им хватит 3 байт и тихо ломали не влезающие в 3 байта символы.
Потом utf8 стандарт урезали до 4 байт максимум.
Потом в Mysql 5.5.(что-то) сделали грубый костыль - кодировку названную utf8mb4, который в отличии от исторически дефектного в mysql utf8 умеет в 4 байт на символ и соответствует стандарту. В будущем в mysql алиас кодировки utf8 планируют переключить с utf8mb3 на utf8mb4. Но до тех пор - utf8 как стандарт и utf8 как кодировка в mysql совпадают только на 75%.
Спасибо (уже и кликнул). Очень подробно и понятно. Теперь есть понимание. В целом в двух проектах я использую везде только utf8. Получается конвертировать мне необходимо только если я например использую стороннее api или работаю с пользовательским файлом?
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.