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]

 PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (2): « 1 [2]   

> Без описания
Doox911
Отправлено: 20 Июля, 2018 - 07:00:03
Post Id



Частый гость


Покинул форум
Сообщений всего: 166
Дата рег-ции: Сент. 2011  


Помог: 0 раз(а)




Мелкий пишет:
Doox911 пишет:
\xd1\x82 - этo байты?

Это байты в распространённой hex записи.
Пользуясь какой-нибудь таблицей кодирования можно попробовать представить в виде символов.
Для utf8 это будет один символ т, для cp1251 - строка из двух символов: "С‚", строка "Ń‚" в cp1250 и так далее по куче разных кодировок с различным эффектом.

Doox911 пишет:
Не совсем понял что за d0 b0:

Тоже байты в hex виде. Без \x и с пробелами обычно читается легче человеком.


Тогда, я так понимаю, из массив и предыдущей темы мне надо видо изменить.
http://forum.php.su/topic.php?fo...58715#1532058715
PHP:
скопировать код в буфер обмена
  1.  
  2. $alfavit = array (' ','А','а','Б','б','В','в','Г','г','Д','д','Е','е','Ё',
  3.                          'ё','Ж','ж','З','з','И','и','Й','й','К','к','Л','л','М','м',
  4.                          'Н','н','О','о','П','п','Р','р','С','с','Т','т','У','у','Ф',
  5.                          'ф','Х','х','Ц','ц','Ч','ч','Ш','ш','Щ','щ','Ъ','ъ','Ы','ы',
  6.                          'Ь','ь','Э','э','Ю','ю','Я','я','0','1','2','3','4','5','6','7','8','9');
  7.  

Заменить на символы коды символов:
https://www[dot]utf8-chartable[dot]de/un[dot][dot][dot]nicodeinhtml=hex
взяв коды символов и сними сравнивать?
 
 Top
Мелкий Супермодератор
Отправлено: 20 Июля, 2018 - 09:57:20
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




Ничего не изменится, если файл скрипта сохранён как utf8.
"\xd1\x82" - это ровно 'т' и есть.


-----
PostgreSQL DBA
 
 Top
Doox911
Отправлено: 07 Августа, 2018 - 08:27:17
Post Id



Частый гость


Покинул форум
Сообщений всего: 166
Дата рег-ции: Сент. 2011  


Помог: 0 раз(а)




Т.е. получается при добавлении модификатора u регулярка сама поймёт в какой кодировке сравнивать? Или будет сравнивать исходя из того что в скрипте предполагается, что символ пришел в кодировке utf8 и скрипт сохранён в той же кодировке?
 
 Top
Мелкий Супермодератор
Отправлено: 07 Августа, 2018 - 10:43:10
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




Doox911 пишет:
сама поймёт в какой кодировке сравнивать

Это в принципе невозможно.
Если кодировка текста не известна заранее - то её можно пытаться только угадать. Потому что байты-то везде одни и те же, а кодировок - суть таблиц преобразования произвольного байта в представление на экране - огромное множество наплодили.

Флаг u подписан в мануале и маппится в коде в PCRE_UTF8, т.е. регулярка будет работать исходя из предположения, что и паттерн и текст переданы в utf8


-----
PostgreSQL DBA
 
 Top
Doox911
Отправлено: 07 Августа, 2018 - 11:18:19
Post Id



Частый гость


Покинул форум
Сообщений всего: 166
Дата рег-ции: Сент. 2011  


Помог: 0 раз(а)




Мелкий пишет:
Doox911 пишет:
сама поймёт в какой кодировке сравнивать

Это в принципе невозможно.
Если кодировка текста не известна заранее - то её можно пытаться только угадать. Потому что байты-то везде одни и те же, а кодировок - суть таблиц преобразования произвольного байта в представление на экране - огромное множество наплодили.

Флаг u подписан в мануале и маппится в коде в PCRE_UTF8, т.е. регулярка будет работать исходя из предположения, что и паттерн и текст переданы в utf8

Т.е. корректно будет работать если html, скрипты и база в UTF-8? UTF-8 и utf-8_general_ci одно и тоже?
 
 Top
Мелкий Супермодератор
Отправлено: 07 Августа, 2018 - 15:22:56
Post Id



Активный участник


Покинул форум
Сообщений всего: 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
 
 Top
Doox911
Отправлено: 08 Августа, 2018 - 07:49:16
Post Id



Частый гость


Покинул форум
Сообщений всего: 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 или работаю с пользовательским файлом?
 
 Top
Страниц (2): « 1 [2]
Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)
« Вопросы новичков »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB