PHP

[Прим Палвер]

Текст хранится в ячейке в 64 кб. MySQL.

[Makhno]

А то что тесты немного больше весят так это не проблема - каналы сейчас уже не модемные.

Если протокол поддерживает сжатие данных (а http поддерживает) перед передачей, то разница не небольшая... Ее вообще почти нет. Любой латинский символ, цифра или знак препинания по-прежнему занимают байт (причем тот же байт, что и определен в ACII), русский, например, - два. Но первый байт у большинства русских символов будет одним и тем же, следовательно энтропия растет, а компрессия становится эффективнее. Интересная диаграммка по тенденции перехода на utf-8:

[Lazer_beam]

Makhno я же говорил что мне плевать на разницу и много лет уже ипользую юникод, чего и вам желаю - хотя некоторые приводят свои "весомые" аргументы.

[Makhno]

Makhno я же говорил что мне плевать на разницу

Не знаю, правильно ли Вы меня поняли, но мое сообщение сводится к тому, что разницы в размере передаваемой информации по http как таковой нет.

чего и вам желаю

Я данной сферой не занимаюсь. Хотя использую utf-8, где это только возможно.

[Прим Палвер]

Ну объясни мне, мил человек, как перевести сайт из цп1251 на утф8 с уже разбитой структурой по 64 кб. Можно привеодить не только веские аргументы. Если тема каким-то образом ущемляет по какому-то признаку, разрешается её игнорировать

[Syon]

Если протокол поддерживает сжатие данных (а http поддерживает) перед передачей, то разница не небольшая...

Баннерорезалки, html вирусосканеры и все к ним приравненные отшибают gzip в большинстве случаев.

PS. Это не было "голосом против unicode".

Ну объясни мне, мил человек, как перевести сайт из цп1251 на утф8 с уже разбитой структурой по 64 кб.

Сменить размер в mysql. и вообще - что за самоограничения то ?

[Прим Палвер]

Сменить размер в mysql. и вообще - что за самоограничения то ?

Тип "text".
Вы используете для всех текстовых данных "longtext"?

Кстати, если посмотрите сюда, увидите, что вин1251 ничем меня не ограничивает в выборе дополнительных языков. Разумеется, если делать сайт в равной доле на нескольких языках, такая политика себя не оправдывает.

PS. Это не было "голосом против unicode"

[Makhno]

Баннерорезалки, html вирусосканеры и все к ним приравненные отшибают gzip в большинстве случаев.

Нужно выбирать тогда из меньшенства. Adblock Plus, например, под Firefox.

[Syon]

Тип "text".
Вы используете для всех текстовых данных "longtext"?

Кстати, если посмотрите сюда, увидите, что вин1251 ничем меня не ограничивает в выборе дополнительных языков. Разумеется, если делать сайт в равной доле на нескольких языках, такая политика себя не оправдывает.

PS. Это не было "голосом против unicode"

Дык. &# конечно никто не отменял. Если он спорадический. Разговор про utf обычно ведут тогда, когда процент не 1251 превышает некий "порог терпения". Тогда прямая дорога в UTF. Ну, или когда создается новый сайт с заранее неизвестным содержимым (кодировки имеются ввиду).

PS. И все-же технических проблем в переводе 1251 сайта на UTF я не вижу.

[Прим Палвер]

Такой вот вопрос.

Файл .htaccess на одном из сайтов выглядит так:

RewriteEngine on
Options +FollowSymlinks
RewriteBase /

RewriteRule ^(.*)/$ /$1 [R=301,L]

RewriteRule ^(ru|en)$ /index.php?l=$1 [L]
RewriteRule ^([-A-Za-z0-9]+)$ /index.php?article=$1 [L]
RewriteRule ^(ru|en)/([-A-Za-z0-9]+)$ /index.php?l=$1&article=$2 [L] 

По отдельности параметры "язык" и "статья" передаются нормально.
Если вместе - перестают показываться стили и картинки на странице, т.к. прописаны они относительно и их адреса начинают выглядеть так:
httр://site.ua/en/img/picture.png,
а должны так:
httр://site.ua/img/picture.png

Как бороться?
Метод перепрописывания относительных путей в абсолютные не предлагать.

[CrazySquirrel]

Если у Вас адресация к изображению происходит через httр://site.ua/en/img/picture.png, то это как раз путь абсолютный, а относительный выглядит так /img/picture.png

[Прим Палвер]

и?

масло масляное, а хлеб хлебный

что дальше?

[CrazySquirrel]

/img/picture.png Такое обращение показывает сайту что поиск файла идёт от корня сайта, и в таком случае виртуальная дериктория en пропускаеться

[Прим Палвер]

Теоретически ты молодец.
А практически пробовал?

Разжёвываю: прописано 'img/picture.png', а ищет и выдаёт 'httр://site.ua/en/img/picture.png' при адресах типа 'httр://site.ua/en/article1'

[GH]

httр://site.ua/en/img/picture.png,
а должны так:
httр://site.ua/img/picture.png

Как бороться?
Метод перепрописывания относительных путей в абсолютные не предлагать.

Обращайтесь к изображению начиная от корня сайта т.е. /img/picture.png. Это и есть относительный адрес, в данном случаи он относительно корня. Вы же обращаетсь так, что браузер считает это относительно текущей дериктории.

[CrazySquirrel]

Теоретически ты молодец.
А практически пробовал?

Разжёвываю: прописано 'img/picture.png', а ищет и выдаёт 'httр://site.ua/en/img/picture.png' при адресах типа 'httр://site.ua/en/article1'

Пробовал! Чесное слово.

Давайте я попробую объяснить. Бывают следующие сигнатуры относительных путей:

img/img.png - поиск файла происходит из текущего каталога, тоесть из http://site.com/fold получим http://site.com/fold/img/img.png

./img/img.png - тоже самое

../img/img.png - переход в надкаталог, тоесть из http://site.com/fold получим http://site.com/img/img.png

/img/img.png - относительно корня, тоесть из http://site.com/fold получим http://site.com/img/img.png

ВАЖНО! В PHP и HTML/JS понятие корня отличаеться. Большинство провайдеров, хранит данные на серваках в виде /var/www/site.com/public_html/, тоесть при обращении из PHP корнем будет /var. HTML "видит" корень, от имени сайта, тоесть для http://site.com/fold корень будет http://site.com/. Для компинсации серверного корня, есть константа, $_SERVER['DOCUMENT_ROOT'].

Вроде всё, будут вопросы, пишите, попробую ответить.

[GH]

По поводу, что /var будет корнем не соглашусь.
Корнем будет именно /var/www/site.com/public_html/, или то, что указано в качестве DocumentRoot в конфигурации сервера/виртуального хоста.

[CrazySquirrel]

По поводу, что /var будет корнем не соглашусь.
Корнем будет именно /var/www/site.com/public_html/, или то, что указано в качестве DocumentRoot в конфигурации сервера/виртуального хоста.

Наверное я немного не правильно выразился.
Корнем будет именно /, а /var будет первым уровнем относительно корня

[GH]

Давайте определимся, есть корень системы (это в всех *nix подобных) и это действительно /, а есть корень сайта (DocumentRoot), а он уже может быть как и:
/var/www/site.com/public_html/,
/var/www/site.com/,
/var/www/,
/home/site.com/www.

Это уже как угодно администратору сервера и на наш поиск изображений никак не влияет. Ибо мы же танцуем относительно корня сайта (doc_root).

[CrazySquirrel]

Я говорю про обращение к файловой структуре непосредственно из PHP, показываю простой пример того, о чём я говорю:

<?
$a=scandir($_SERVER['DOCUMENT_ROOT']);

$b=scandir('/');

echo "<pre>";

print_r($a);
print_r($_SERVER);

echo "</pre>";
?>

получаем:
Массив $a

Array
(
[0] => .
[1] => ..
[2] => cache
[3] => config
[4] => include
[5] => index.php
[6] => templ
[7] => templ_c
)

массив $b

Warning: scandir() [function.scandir]: open_basedir restriction in effect. File(/) is not within the allowed path(s):

Что уверяет нас в том что / и $_SERVER['DOCUMENT_ROOT'] ссылаються в разные места, тоесть фактически HTML при поиске файла, будет отталкиваться от $_SERVER['DOCUMENT_ROOT'], а PHP от /.


Часть массива $_SERVER

[SERVER_SOFTWARE] => Apache
[SERVER_NAME] => Не скажу
[SERVER_ADDR] => **.**.**.**
[SERVER_PORT] => 80
[REMOTE_ADDR] => **.**.**.**
[DOCUMENT_ROOT] => /var/www/МОЙ ЛОГИН/МОЙ ДОМЕН
[SERVER_ADMIN] => [email protected]
[SCRIPT_FILENAME] => /var/www/МОЙ ЛОГИН/МОЙ ДОМЕН/index.php