Неоднозначность названий… Где-то надо win-1251, где-то cp1251, где-то windows-1251, а еще где-то win1251… Даже UTF-8 можно (или даже нужно) иногда писать как UTF8…
По-моему правильно — это CP1251 и UTF8|UTF16|UCS2BE и т.д. и никаких тире или пробелов, ну почему хоть это-то никак не могут стандартизовать…
Я вчера весь мозг сломал, вспоминая как правильно — UCS-2BE или UCS2-BE…
Пожалуй, бОльшая в разы скорость работы все же поважнее совместимости, хотя из-за этого старый проект на UTF будет проблемно переставлять, если много где используются регулярные выражения. Но что-то мне подсказывает, что там, где в однобайтном использовалось \w, кириллица и прочее должны match'иться, т.к. иначе бы использовалось [a-z0-9]…
Я подразумевал, что логичнее было бы в режиме /u рассматривать \w как любой символ буквы или цифры, по аналогии с не-юникодным режимом.
Иными словами [\w] рассматривать как [\p{L}\p{Nd}], тогда, по сути, большинство паттернов стали бы юникодными после простого добавления ключа /u. Это с точки зрения совместимости при переходе с однобайтной кодировки на UTF-8.
Но раз этого нет, то скорее всего на это есть объективные причины. Если знаете — поделитесь, в документации про ключ /u ничего не нашел (смотрел в разделе «PASSING MODIFIERS TO THE REGULAR EXPRESSION ENGINE» и просто поиском по документу).
Да пробовал я, уже писал в комментарии. Сайт автора не понимает ссылку в таком формате: пройдите по www.sprymedia.co.uk/article/Visual%20Event и увидите пустую страницу с меню.
Неоднозначность названий… Где-то надо win-1251, где-то cp1251, где-то windows-1251, а еще где-то win1251… Даже UTF-8 можно (или даже нужно) иногда писать как UTF8…
По-моему правильно — это CP1251 и UTF8|UTF16|UCS2BE и т.д. и никаких тире или пробелов, ну почему хоть это-то никак не могут стандартизовать…
Я вчера весь мозг сломал, вспоминая как правильно — UCS-2BE или UCS2-BE…
Пожалуй, бОльшая в разы скорость работы все же поважнее совместимости, хотя из-за этого старый проект на UTF будет проблемно переставлять, если много где используются регулярные выражения. Но что-то мне подсказывает, что там, где в однобайтном использовалось \w, кириллица и прочее должны match'иться, т.к. иначе бы использовалось [a-z0-9]…
Иными словами [\w] рассматривать как [\p{L}\p{Nd}], тогда, по сути, большинство паттернов стали бы юникодными после простого добавления ключа /u. Это с точки зрения совместимости при переходе с однобайтной кодировки на UTF-8.
Но раз этого нет, то скорее всего на это есть объективные причины. Если знаете — поделитесь, в документации про ключ /u ничего не нашел (смотрел в разделе «PASSING MODIFIERS TO THE REGULAR EXPRESSION ENGINE» и просто поиском по документу).
И чем этот сервис отличается от www.tinyurl.com, кроме чуть более короткого URL'а — clck.ru/1ui против tinyurl.com/68hc6m (видимо следствие того, что сервис «помоложе»)?
То, что хабр бы скушал «%20» я и так знаю.
«+» и «%20» не одно и то же, хотя оба при URL кодировании означают пробел.
Как пример приведу 2 функции РНР:
rawurlencode — URL-encode according to RFC 1738
urlencode — URL-encodes string
Первая из пробелов сделает «%20», вторая — «+»…