Разное

По какому правилу происходит кодирование участка от заголовка запроса клиента до переменных окружения сервера?
(Если я не правильно стилистически и по форме задал вопрос, то я исправлю, как вы привыкли)

Ммм... давайте я просто опишу зачем нужны переменные окружения серверу, а вы зададите наводящие/корректирующие вопросы. Дело в том, что когда разрабатывается большой программный комплекс, будь то операционная система, сервер, да даже компьютерная игра или база данных, зачастую предусматривается возможность для запуска в рамках этого комплекса других программ. Например, Apache может подключить библиотеку, которая будет фильтровать документ и интерпретировать его в соответствии с правилами какого-нибудь языка программирования. Ну например, PHP. Или допустим завтра появится новый язык программирования, имеется возможность написать для него модуль, который будет работать в составе старого Web-сервера Apache (на момент создания которого такого языка программирования вообще не было).

В разных операционных системах это реализуется по-разному, такой модуль может запускаться в виде отдельного процесса, или в виде потока (параллельного участка в рамках процесса). Если речь идет о потоках, то все достаточно просто - они все выполняются в рамках единого адресного пространства, т.е. один поток может принять данные от клиента, сохранить их в память, а другой поток обратиться к этой памяти (ну понятное дело, нужно обеспечить синхронизацию, мьютексы, все дела). Однако, если вы имеете дело с процессами, то они изначально спроектированы так, чтобы их адресные пространства были раздельны. Т.е. нельзя просто взять из своей программы и залезть в память скажем Photoshop, так как ваша программа и Photoshop - это разные процессы (внутри их может быть сколько угодно потоков, которые могут обращаться к памяти процесса).

Все-таки процессы могут между собой обмениваться информацией. Все эти способы (а их довольно много) объединяются под термином "межпроцессорное взаимодействие". Особенно богато этих возможностей, если один процесс является дочерним другого процесса. Вот один из таких способов - поставить переменную окружения в родительском процессе, тогда она будет автоматически доступна дочернему процессу.

Теперь плавно переключаемся на то, почему нас старых виндузятников это все должно волновать. Все серверное ПО почти целиком пришло из UNIX, более того, даже Windows-сокеты были написаны почти с полной совместимостью с берклиевскими сокетами (даже Microsoft признает, что сеть - это поле UNIX, который там сидит также прочно, как Microsoft в области десктопов). В Windows очень мощная поддержка потоков (поэтому Apache имеет всего два процесса - потоками все сделать проще и быстрее), а вот в UNIX с ними не очень, зато в них очень просто порождаются дочерние процессы, поэтому в UNIX такая прорва процессов httpd. Ну и понятно, что им как-то нужно обмениваться данными между собой, вот они переменные окружения и ставят... а так как разработка идет в основном под UNIX, то все остальное ПО под эту архитектуру подстраивается. В Windows бы эти переменные окружения нафиг бы не упали, но не поддерживать же параллельную разработку, когда уже есть готовый и отлаженный UNIX-код, заточенный под переносимость на другие платформы.

Т.е. что происходит, когда приходит HTTP-заголовок от клиента, Apache, зная, что они нужны дочерним процессам просто ставит их в свои переменные окружения, далее он порождает дочерний процесс, который будет обрабатывать этот запрос, этот процесс знает, что вот де GET-данные тут лежат, POST-данные - тут, путь к файлу тут. Если ему нужно запустить какой-то другой процесс (скажем PHP), он в дополнение к существующим переменным может еще выставить несколько. Правда на практике стараются подсократить количество таких запусков, поэтому интерфейс CGI (когда запускался полноценный внешний процесс) практически не используется, стараются функциональность встроить модулем прямо в процесс, а механизм обмена через переменные окружения остался, под него заточены интерфейсы языков и синтаксис конфигурационных файлов. Если интересны подробности, нужно копать UNIX, CGI.

Вот я сейчас написал текст, на клавиатуре, который кодировался в скен коде
Далее он попал в форму браузера пройдя перекодировку для представления windows-1251.
Браузер по умолчанию(задано в метатеге HTML) настроен на windows-1251.
После этого я нажимаю кнопку формы - отправить.
----------- Вопрос ---------------------------------------------------------
Поисходит ли перекодирование после нажатия на кнопку и если да, то в какой спецификации протокола указано это. Я имею ввиду передачу данных по сети.
Если GET эти данные появляются в адресной строке браузера из заголовков протокола НТТР
Если POST должно также происходить, но адресной строке ничего не будет заголовок немного другой будет
---------------------------------------------------------------------------------
По-мойму это относится к стандартизации, может CGI или НТТР
Но стандарт должен быть иначе хаос будет.

Тут зачастую регулирование правил идет не протоколами, а RFC, которые не всегда дотягивают до протокола или официального стандарта, но часто становятся стандартом де-факто. GET-данные обязательно подвергаются кодированию, POST-данные отправляются как есть. Кодировка не меняется. Кодирование всех символов в GET осуществляется согласно RFC 3986, хотя могут прокатывать и менее зверские стандарты, например, оставляющие английский текст без изменений.

>POST-данные отправляются как есть
Где нибудь прописано? Я вам верю. Я спрашиваю ради того, что б знать требования технологической документации и степень исполняемости
> GET осуществляется согласно RFC 3986, хотя могут прокатывать и менее зверские стандарты
От чего(программа, система) зависит зверство?
Я нашел сейчас http://lib.ru/WEBMASTER/rfc2068/section-9.html#p3, но там ни слова о кодировании при передаче по сети.
Как бы уточнить.


А вот вид представления кода у браузера никак не передается наверное?
А можно как-то JavaScript или PHP получить вид представления кода у браузера получить?

>>POST-данные отправляются как есть
>Где нибудь прописано? Я вам верю. Я спрашиваю ради того, что б знать требования >технологической документации и степень исполняемости
Наверняка где-то прописано, но если бы было по другому, то просто все изображения и бинарные файлы при загрузке бились бы... все разработчики понимают, что должен быть способ безпроблемной доставки бинарных файлов, для этого используются POST-метод. Если нужно перекодировать, то его уже оформляют более сложно, как это принято в почтовых протоколах, где вводятся секции.

>> GET осуществляется согласно RFC 3986, хотя могут прокатывать и менее зверские стандарты
>От чего(программа, система) зависит зверство?
От программы большей частью и насколько она действует согласно букве RFC. Это же рекомендации, жизнь обычно вносит свои коррективы. Например создавали создавали 20 лет Unicode, а в результате получился UTF-8 (то что изначально задумывалось и сейчас называется UTF-16 в сети использоваться нереально, хотя Windows его и использует). Тут тоже самое, да можно вообще все кодировать, но английский алфавит - во всех кодировках кодируется одинаково, это алфавит живого и очень популярного языка и имеется большой соблазн использовать его как есть, тем более это все себе могут позволить. Поэтому английские символы передаются как есть, без перекодирования, а вот русские уже кодируются.

>Я нашел сейчас http://lib.ru/WEBMASTER/rfc2068/section-9.html#p3, но там ни слова о
>кодировании при передаче по сети.
>Как бы уточнить
Протокол HTTP не определяет правила формирования URI, он пользуется готовым, описанным в других RFC. В протоколе о том, что слать, о том куда слать, там действительно очень мало написано. А метод GET - это же пересылка данных через URI (то что мы разработчики называем URL).

А вот вид установка в параметрах представления кода (кодировки) у браузера никак не передается ?
А можно как-то JavaScript или PHP получить вид значения кодировки у браузера получить?

А как же, передается, при помощи HTTP-заголовоков... только не на уровне URL, там все жестко и никаких кодировок быть не должно, фактически вам нужно её либо знать заранее, либо угадать. Как правило, наоборот клиент знает, что вот этому приложению если и слать данные через URL или POST-данные, то в такой-то и такой-то кодировке.

Однако в HTTP имеется специальный заголовок Content-Type, через который вы можете сообщать в какой кодировке передается ваше сообщение.

Кроме того не следует принимать близко к сердцу все, что написано в RFC-ах :))) Это рекомендации и академические протоколы, в реальности все немного по другому... если еще использование метода HEAD в реальных приложениях вы найдете, то реализованные на практике методы PUT и DELETE можно днем с огнем искать, мало кто допускает саму возможность, чтобы клиенты там что-то с серверов удаляли или размещали в обход Web-приложения...

С реальностью все как бы понятно из материализма. На каждом шагу реальность скажем... зашумляется по разным причинам. Вместо реальности мы имеем всегда дело с копией, идеей реальности. Те же кто реалистичнее воспринимают эту реальность у них всегда больше шансов. Ну это так, философская теория.

У меня однозначно наглядная задача - знать кодировку средства отправки - например браузера

>У меня однозначно наглядная задача - знать кодировку средства отправки - например браузера
Там почти нет выбора - это в 95% случаев UTF-8 (под Windows по крайней мере так).

Это вы имеете ввиду то что данные из формы перекодируются?
А в брузере, в какой кодировке данные оказываются после ввода с клавы, например в форме для отправке на сервер. Этот вид кода определяет (кодирует) операционная система. В Win это установка в панели задач в языковой панели.
Кроме в браузере установлен вид кодировки
Как их определить клиентским языком или на серваке принимающем данные?

Нет, это если вы просто вобьете русские символы в строку запроса - они пойдут в UTF-8. Из формы данные пойдут в той кодировке, которая указана для данной HTML-страницы (или которую назначит браузер автоопределением, если сервер не прислал ни HTTP-заголовков, ни META-тэгов с кодировкой).

>А в брузере, в какой кодировке данные оказываются после ввода с клавы, например в форме для
>отправке на сервер.
Между клавой и браузером есть еще операционная система, она все данные гоняет строго в UTF-16 (говорим сейчас об Windows). Даже когда вы открываете и редактируете файл в Windows-1251, все сначала перегоняется в UTF-16, чтобы вам показать, вы вносите изменения, а потом они снова перекодируются в Windows-1251, чтобы их сохранить. С браузером тоже самое, когда вы набираете текст, когда он поступает от операционной системе к программе - он в UTF-16, из этой кодировки браузер перекодирует данные в нужную ему кодировку (для отправки или сохранения).

>В Win это установка в панели задач в языковой панели.
>Кроме в браузере установлен вид кодировки
Там есть магическая фраза "Выберите язык, соответствующих языку используемых программ, которые не поддерживает Юникод", т.е. если включить, то операционная система будет знать о такой кодировке и её можно будет использовать например в консоли. Все это барахло больше частью нужно для поддержки старых программ и файлов, которые упорно держаться за старые кодировки. Лет еще 10-20 на UTF-8 будет переходить.

Ну ладно, я первый вопрос задал не правильно.
-----------------------------------------------------------------
Можно ли узнать на сервере при получении данных от клиента:
1 В какой кодировке данные(процедура кодирования, а не сам код)
2. В какой кодировке ОС, т е таблица соответствия по которой сопоставляется данные ввода клавиатуры в данные в форме браузера
---------------------------------------------------------------
Прим. Я извиняюсь, но слово кодировка - отглагольное существительное. Таковых очень много: обработка, шифровка, игрушка, чистка, грабеж, накал, распад, зубрежка, варка... Еще в России они назывались канцелярщиной(Чехов, Писемский) и запутывали дела до предела и не только канцеярские.
Я так думаю.
Слово "Кодировка" может означать и процедуру и(или) результат кодирования в речи.
Понятие "Кодировка", наверное, обозначает таблицу соответствия, процесс перевода представления одних данных в другие...

>Можно ли узнать на сервере при получении данных от клиента:
> 1 В какой кодировке данные(процедура кодирования, а не сам код)
Можно, но проблема в том, что данные поступают по нескольким каналам, некоторые можно некторые нет. Адресная строка и метод GET - это ахилесова пята, у вас все может быть прописано, и сервер с браузером могут быть уверены, кто данные идут в такой-то кодировке, а в методе GET они будут в другой кодировке. Это кстати и со страницами может произойти, если вы напишите неправильный META-тэг или что чаще, сервер отошлет принудительно HTTP-заголовок с одной кодировкой, а у вас на странице кодировка другая - будет ошибка и неправильное отображение.

>2. В какой кодировке ОС, т е таблица соответствия по которой сопоставляется данные ввода
>клавиатуры в данные в форме браузера
В Linux за это отвечает локаль, там любую можно выбрать и программы знают, что сначала нужно посмотреть какая локаль выбрана по умолчанию, ну уж зато если она выбрана - такая кодировка и будет. В Windows, начиная с Windows 2000 кодировка одна - Unicode (UTF-16), разные программы, в том числе и браузеры могут использовать разные кодировки, но внутри и при обмене они используют Unicode. Внутри себя барузер может данные перекодировать как хочет, но от операционной системы он получит их в виде Unicode.

Кодировка - это да сленг, правильно "кодовая таблица" (но это долго произносить и писать). Сленг у компьютерщиков очень дикий (так как долгое время это была, и все еще остается очень молодежной группой)... и основан на заимствованиях, которые они адаптируют слепо без перевода. Одно время было модно использовать сленговое словечко "сакс", которое у нас используется когда нужно более утонченно передать смысл "отстой" (тоже сленг, но он сейчас в ходу, в отличие от сакс), а вообще в оригинале это довольно грубое и похабное "отсос" (так этот "сакс" уже и в литературе, и в речи профессоров и где только нет).

Так как КАК УЗНАТЬ информацию от клиента?
Можно ли без ахилесовой пяты, можно ли это сделать без Алисы в стране чудес?

Посмотреть, что он прислал в HTTP-заголовке Content-type. Однако, обычно это сервер диктует кодировку, а не клиент, поэтому клиент вполне может не отсылать этот HTTP-заголовок, надеясь, что сервер помнит в какой кодировке были отправленные им данные.

PS Дело в том, что очень редко клиенты сразу без затей начинают засыпать сервер запросами с какими-то данными. Как правило, они загружают с сервера страницы и лишь затем шлют повторные запросы. Кодировки этих полученных страниц и определяют кодировку дальнейшего обмена.

Точно.

Оказывается есть
1. document.charset
2. document.characterSet
Ни водном справочнике не могу найти
И тут нет, АЯС дал, http://www.softtime.ru/forum/read.php?id_forum=4&id_theme=69967#post409865
Меня то устраивает.

Это локальная кодировка в рамках документа на стороне клиента, к серверу она отношения не имеет, только если вы её в параметре ему не перешлете и на нем не будет кода, который учтет этот параметр в работе серверной части Web-приложения.

А зачем мне сервер.
Мне на сервере надо получить информацию о параметрах клиента и...
3 месяца я всех спрашивал, вопросы по разному конструировал.
Дурдом. Ответов много и польза от них

>1. По какому правилу происходит кодирование участка от заголовка запроса клиента до
>переменных окружения сервера?
>2. А зачем мне сервер.
Ну уж мы тут явно не причем, если сервер не нужен, наверное не нужно его в вопросе вообще упоминать.

Сленг у всех очень дикий. Еще три слепых мудреца пытались узнать что есть слон. Веревка, труба или столб. Без наглядности и атрибутивной логики, без анатомии и физиологии, без архитектуры и технологии можно вечно трендеть о чем угодно.
А еще история была с вавилонской башней. Тоже круто было