Khimenko Victor wrote:
> In <38C4CE60.506079B7@cronyx.ru> Kurakin Roman (rik@cronyx.ru) wrote:
>
> KR> Khimenko Victor wrote:
>
> >> In <38C3ECA2.BCA3A91@cronyx.ru> Kurakin Roman (rik@cronyx.ru) wrote:
> >> KR> Добрый день,
> >>
> >> KR> Прошу прощения если пишу не в тот список.
> >>
> >> А почему не в тот ?
>
> KR> Просто я не знаю в какой правильно :)
>
> Обсуждение RA -- в apache-rus, все что не касается mod_charset -- в apache-talk.
Тогда скоре всего я попал куда надо, как и предполагал.
> >> KR> Вопрос таков: когда оканчательно решается вопрос о кодировки до
> >> KR> выполнения скрипта (будь то CGI или PHP) или после.
> >>
> >> А если ЧУТЬ-ЧУТЬ (ну самую малость) подумать ? Ваши скрипты получают параметры
> >> в QUERY_STRING ? Получают. Перекодированные в случае надобности ? Канечна.
> >> Еще вопросы будут ?
>
> KR> Ну мог я надеяться что сперва перекодируется то что для меня, а потом то что от
> KR> меня независимо. Насколько я понимаю эти действия действительно почти "независмы",
> KR> так как определяется все в одном месте. Вот если бы совсем независимы, ведь
> KR> совсем не трудно (на сколько я себе это представляю) перед перекодированием того
> KR> что от меня проверить переменные окружения.
>
> ??? Твои переменные окружения для сервера -- тайна за самью печатями (перадача
> данных от сервера к CGI через переменные окружения может идти только в одну
> сторону). Что касается ответа, который ты посылаешь серверу, то в нем опять-таки
> могут встретиться строки, которые нужно перекодировать раньше, чем Content-Type.
Собственно про CGI это я ляпнул не подумав.
> Думаю, что к mod_php можно доделать interface к RA и оттуда сменить кодировку,
Я как раз и расчитывал что php это тот же процесс, а следовательно я могу выставить через
него FORCE_CHARSET
> но для CGI это -- гиблый номер...
>
> >> KR> Или иначе можно скриптом сбить apache-rus с пути истенного и заставить
> >> KR> его думать что у клиента другая кодировка. (Location не годится).
> >>
> >> См. выше. Если вы хотите такими извращениями заниматься, то отключите RA и
> >> делайте все, что нужно руками...
>
> KR> Это неинтерестно. Мне нужна вся сила RA, и умение ею управлять в нужном мне
> KR> направлении.
>
> ЗАЧЕМ ? Неужели RA так частно не угадывает кодировку ? Или это -- задача ради
> самой задачи.
Возможно я действительно слишком придераюсь, но с точки зрения той идеи
которую я приследую, лучше строго следовать тому что хочет клиент, если
он выбрал кодировку то именно ее в следующий раз ему и суну.
> KR> Вообще говоря задача у меня такова: Запомнить предпочтения в кодировке для клиента
> KR> и
> KR> на основе этого подкручивать кодировку. При этом сокрыть всю возню с кодировкой от
> KR> клиента, т.е. не должно быть нескольких хостов, портов, и виртуальных каталогов
> KR> (покрайней мере для клиента).
>
> А также не должно быть кеширования документов (как естественное следствие).
> Оно вам точно надо ?
Над этим я еще сильно не думал, но скорее всего если я об этом позабочусь потом
проблем быть не должно. Вообще говоря все это будет делать инклуднутый php,
а в нем вроде заголовки можно подкрутить.
Что касается доработки, то скорее всего ее надо делать не столько в PHP, сколько в
RA. Пока на данный момент могут только сказать что в PHP есть функция setenv,
и при установленной ею FORCE_CHARSET PHP пишет что это переменная окружения
а не APACHE, по этому PHP скорее всего тоже надо править на наличие setapcheenv.
А может только его и надо править ? Вообще я очень смутно представляюю как могут
быть отдельно переменные окружения и переменные окружения Apache.
Куракин Роман
=============================================================================
= Apache-Rus@lists.lexa.ru mailing list =
Mail "unsubscribe apache-rus" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at http://www.lexa.ru/mail-archive =
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/) See
Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.