Внезапно возник вопрос

← →
Ega23 © (2013-02-07 21:48) [0]

Если что-то не понимаю, то не пинайте сразу.
Вот есть HTTP-сервер. Вот послали ему запрос. Вот получили некий ответ, фактически - стрим данных. А как теперь узнать, в какой кодировке эти данные пришли? В заголовке может стоять, а может и нет. В meta может стоять, а может и нет. Так как это дело понять, каким образом разбирать этот стрим: как ansi, как utf-8 или как utf-16?
Смотрел в rfc (не помню уже какие номера), но с наскока ничего не нашёл.

← →
Rouse_ © (2013-02-07 21:51) [1]

Вопрос абстрактен. Чейто отправили, чейто получили, а как читать хз :)
Ты уж определись, что именно ты отправляешь и что ожидаешь в ответ :)

← →
Rouse_ © (2013-02-07 21:53) [2]

ну и в догонку: стрим данных читается как есть, экзешнику очень не понравится если его в UTF будют конвертить :)

← →
Дмитрий С © (2013-02-07 21:58) [3]

Кодировка определяется в заголовке Content-type.
Если она там не указана, браузер берет ее из мета-тега или из заголовка XML файла. Если там не указана - то кодировка выбирается на усмотрение браузера.

← →
O'ShinW © (2013-02-07 22:06) [4]

> В заголовке может стоять, а может и нет.

т.е. аля, "charset=windows-1251" может отсутствовать?

← →
Ega23 © (2013-02-07 22:10) [5]

> Кодировка определяется в заголовке Content-type.

Прекрасно. Как сам заголовок прочитать? Сказано ли где-нибудь, что сам заголовок читается строго как ansichar, а дальше, после двух crlf - в зависимости от того, что в Content-type заголовка прописано?

← →
Ega23 © (2013-02-07 22:11) [6]

Т.е. так: заголовок http-пакета - это текст, или это какая-то структура с конкретными типами данных?

← →
брат Птибурдукова (2013-02-07 22:15) [7]

> O"ShinW © (07.02.13 22:06) [4]
лёгко...

> заголовок http-пакета - это текст, или это какая-то структура
> с конкретными типами данных?
Это текст. Подтверждение сейчас попытаюсь найти, но не гарантирую.

По исходному вопросу — я бы читал как анси, а затем статистически определял кодировку. Способа 100%-рабочего нету.

← →
Kerk © (2013-02-07 22:19) [8]

> Ega23 © (07.02.13 22:11) [6]
>
> Т.е. так: заголовок http-пакета - это текст, или это какая-
> то структура с конкретными типами данных?

Ты точно RFC смотрел?

The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set
is defined by ANSI X3.4-1986 [21].

OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>

http://tools.ietf.org/html/rfc2616#section-3

← →
Rouse_ © (2013-02-07 22:20) [9]

Канонизация и текст по умолчанию Типы среды Интернет регистрируются каноническим образом. Вообще, тело объекта, передаваемого с помощью HTTP сообщений, должно быть представлено соответствующим каноническим способом, прежде чем будет послано; исключение составляет тип text, как это описано в следующем параграфе. В случае канонической формы субтип среды text использует CRLF для завершения строки текста. HTTP ослабляет это требование и позволяет передавать текст, используя просто CR или LF, представляющие разрыв строки. HTTP приложения должны воспринимать CRLF, "голое" CR и LF как завершение строки для текстовой среды полученной через HTTP. Кроме того, если текст представлен в символьном наборе, где нет октетов 13 и 10 для CR и LF соответственно, как это имеет место в случае мультибайтных символьных наборов, HTTP позволяет использовать соответствующие символьные представления для CR и LF. Эта гибкость в отношении разрыва строк относится только к текстовой среде в теле объекта; CR или LF не должны подставляться вместо CRLF в любые управляющие структуры HTTP (такие, как поля заголовка). Если тело объекта закодировано с помощью Content-Encoding, исходные данные, прежде чем подвергнуться кодированию, должны были иметь форму, указанную выше. Параметр charset используется с некоторыми типами среды, чтобы определить символьный набор. Когда параметр charset не задан отправителем явно, субтип среды text определяется так, что применяется символьный набор ISO-88591 по умолчанию. Данные с набором символов, отличным от ISO88591 или его субнабора, должны помечаться соответствующим значением charset. Некоторые программы HTTP/1.0 интерпретируют заголовок Content-Type без параметра charset, неправильно предполагая, что "получатель должен решить сам, какой это набор". Отправители, желающие заблокировать такое поведение, могут включать параметр charset, даже когда charset равен ISO-88591, и должны делать так, когда известно, что это не запутает получателя. К сожалению, некоторые старые HTTP/1.0 клиенты не обрабатывают корректно параметр charset. HTTP/1.1 получатели должны учитывать метку charset, присланную отправителем, и те агенты пользователя, которые умеют делать предположение относительно символьного набора, должны использовать символьный набор из поля contenttype, если они поддерживают этот набор, а не набор, предпочитаемый получателем.

← →
Ega23 © (2013-02-07 22:21) [10]

> По исходному вопросу — я бы читал как анси, а затем статистически
> определял кодировку. Способа 100%-рабочего нету.

Я, в принципе, так и думаю. Но поскольку ненулевая вероятность есть, то и прошу в rfc носом ткнуть (если оно там вообще написано).

← →
брат Птибурдукова (2013-02-07 22:22) [11]

Не, неправ я.

РФЦ-2068 гласит:
message-header = field-name ":" [ field-value ] CRLF

field-name = token
field-value = *( field-content | LWS )

field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
OCTET = <any 8-bit sequence of data>

← →
Ega23 © (2013-02-07 22:23) [12]

> Ты точно RFC смотрел?

Твою дивизию! Ведь видел же, смотрел прямо на текст. Но, зараза, не сообразил.
Спасибо!

← →
bems © (2013-02-07 22:23) [13]

ну в rfc2616 сказано что field-name = token
и что token = 1*<any CHAR except CTLs or separators>
и что CHAR = <any US-ASCII character (octets 0 - 127)>
и что OCTET = <any 8-bit sequence of data>

← →
bems © (2013-02-07 22:24) [14]

простите, стормозил

← →
Pavia © (2013-02-07 22:30) [15]

> Ega23 © (07.02.13 22:11) [6]
> Т.е. так: заголовок http-пакета - это текст, или это какая-
> то структура с конкретными типами данных?

Нито ни сё.
1) http-пакета не существу. Http инкапсулируется в TCP. А TCP это поток.
2) http использует различные схемы для кодирования структуры. Но основным является текстовый формат. ANSI

http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2

← →
O'ShinW © (2013-02-07 22:32) [16]

> лёгко...

не замечал :)

т.е. вопрос - в какой кодировке договаривается сервер с клиентом о кодировке их общения?
Ну, по-логике, если клиент инициирует общение, он может передать сам что он хочет увидеть.
т.е. самому указать Accept-charset=XXXXX

Тогда меньше думать в какой будет ответ

← →
брат Птибурдукова (2013-02-07 22:44) [17]

> Ну, по-логике, если клиент инициирует общение, он может
> передать сам что он хочет увидеть. т.е. самому указать Accept-
> charset=XXXXX
Ну так и есть. Может передать, может не передать. А сервер может послушаться, а может и 406 статус вернуть.

Многие браузеры используют статистические методы для определения кодировки. Если не указано иначе. Аналогично тип контента определяется зачастую по сигнатурам а не по заголовкам.

> Аналогично тип контента определяется зачастую по сигнатурам
> а не по заголовкам.

обычно по месту использования. Вставишь, например, адрес текстовой страницы в тег IMG, браузер попробует воспринять эту страницу как изображение. ну та же тема с CSS, Javascript

HTTP основан на сообщениях или посылках(Messages).
Формат протокола хотя и напоминает смесь текстового и бинарного. Правильнее считать бинарным.
Бинарный протокол состоит из серии октетов.
Октет это 8-бит.

HTTP инкапсулируется в TCP. TCP является потоковым протоколом. Поэтому длина сообщения(посылки) может быть бесконечной или конечной. О определение длин поговорим позже.

Теперь поговорим о протоколе.
Протокол основан на отправки сообщения и получения ответного сообщения.

Структура сообщения запроса и сообщения ответа похожи. Каждый из них состоит из заголовка и тела имеет заголовок(head), тело(body).

Для описания заголовка в основном используется текстовый формат с кодировкой ANSI.
Описанный в:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
Основное ограничение это CR LF.

Также часть заголовка кодируется октетами.
А тело передаются как есть октетами. При этом тело наполняется содержимом в формате закодированным согласно заголовку.

entity-body := Content-Encoding( Content-Type( data ) )

Content-Encoding- определяет сжатие которое добавлено в HTTP протокол.

При этом если в заголовки не определён Content-Type, то клиент(браузер) пробует определить его самостоятельно.

RFC нам даёт следующие рекомендации
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1
Пробовать определить через строку запроса URI. По сути по расширению к примеру "*.jpg"
Но зачастую этого не достаточно. И клиенты пробуют определить это эвристический или статистически. Проверяют магические слова в заголовке.

Раскодирование Content-Type осуществляется согласно правилам MIEM.
К примеру jpeg должны отсутствовать определенные символы при передачи.
А в TEXT есть ограничение на передачу CRLF

Когда тип контента определён, то происходит его раскодированные в файловый поток.

Т.е на выходе http по сути мы получаем файловый поток (или файл)
*.html, *.jpeg

Далее этот файловый поток тоже надо раскодировать если это html то надо определить кодировку.
По умолчанию кодировка определяется заголовком http. Но внутри она может быть переопределена.
Поэтому тут браузер начинает проверять HTML согласно документации на HTML.
http://www.w3.org/TR/REC-html40/charset.html

Если это XML то в первой строчке должен быть указана кодировка файла.
Если это html то должен быть тег <meta>. Причём обычно браузеры ищут его в первых 1000 символах.

> Если это html то должен быть тег <meta>.

Ошибся не должен а может быть а может и не быть.

← →
Pit (2013-02-08 00:06) [22]

Настоящие программисты уже не могут остановиться, продолжая объяснять )

В сообщение [20] не упомянул что HTTP может передавать данные потоком, а может разбить на части. По сути мы имеем вот такую вот цепочку.

Части(Content-Encoding(MIEM(текстовая_кодировка(HTML(Информация)))));
где
Информация=MIEM(информация)
А ещё параллельно есть URI, в котором может также содержаться MIEM.

Внезапно возник вопрос Найти похожие ветки