Кодировка и multipart/form-data в форме

kmv

Новичок
Доброго дня!

Как только использую в форме enctype="multipart/form-data" внезапно и совершенно неожиданно вылазит бок с кириллическим текстом. Например "тест" выглядит как тест

Скрипт и http-заголовки в utf-8;
PHP:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div style="border: 1px solid green">
<?php
if($_REQUEST['test']){
  echo $_REQUEST['test'];
  echo '<br>';
  $r = iconv("utf-8","ISO-8859-1",$_REQUEST['test']);
  var_dump($r);
}
?>
</div>
  <form name="aaa" action=""  method="post" enctype="multipart/form-data">
  <input type="text" name="test" value="тест">
  <input type="submit">
  </form>
</body>
</html>
При дебаггинге значение $_REQUEST['test'] выглядит как "тест" Т.е. уже в пхп оно приходит в козявках.

Заголовки запроса и ответа выглядят нормально:
HTML:
Запрос:
Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding	gzip, deflate
Accept-Language	ru,ru-ru;q=0.8,en;q=0.5,en-us;q=0.3
Connection	keep-alive
Cookie	sid=l4n54dhf7g8stst8asf6p1n577; DBGSESSID=1; DBGSESSID=1%3Bd%3D1%2Cp%3D0
DNT	1
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0

Ответ: (сокращенно)
Connection	Keep-Alive
Content-Length	158
Content-Type	text/html; charset=utf-8
Server	Apache/2.2.22 (Win32) PHP/5.4.8
X-Powered-By	PHP/5.4.8

POST данные:
Исходный код
-----------------------------24393354819629 
Content-Disposition: form-data; name="test"
тест
-----------------------------24393354819629--
В конфигах apache пробовал добавить
AddCharset utf-8
AddDefaultCharset utf-8

в php
default_charset utf-8

- эффекта не последовало.

Интересно, что если в скрипте сделать
PHP:
iconv('utf-8', 'ISO-8859-1', $_REQUEST['test'])
То результат как раз выводит правильно - 'тест' (8 байт). Но этого ведь быть не должно! Ведь если текст изначально в utf-8 то отображаться должен нормально, а показывает на странице тест

Операционная система : Windows x64 Rus, php: apache: 2.2.22 5.4.8;

В чем может быть проблема?
 

Фанат

oncle terrible
Команда форума
была такая ерунда 10000 мильёнов лет назад.
PHP:
CharsetRecodeMultipartForms
 

kmv

Новичок
Пробовал. с этой директивой апач просто не запускается. Насколько я понял, она работает только с "русским апачем" я свой брал с оф. сайта. На оф сайте апача ничего про нее не знают.
 

Фанат

oncle terrible
Команда форума
да я в курсе что не знают.

вообще, выглядит так, что страница у тебя не в утф-е, а в однобайтной кодировке.
 

Фанат

oncle terrible
Команда форума
по сути, тест - не "козявки". это и есть нормальный юникод, который смотрят через однобайтную скважину.
но в заголовке, вроде, утф. непонятно
 

kmv

Новичок
Cкрипт в utf-8 проверил.
Да и в скрипте после выполнения
PHP:
$r = iconv("utf-8","ISO-8859-1",$_REQUEST['test']);
  var_dump($r);
выдает string(8) "тест"

Т.е. по два байта и показывает как положено. Хотя опять же - не сходится - на выходе после такого iconv-a должна быть latin1
 

Фанат

oncle terrible
Команда форума
Т.е. по два байта и показывает как положено.
как раз наоборот.
если я не путаю порядок параметров у иконв, то из юникода оно тебе переводит в вестерн.
 

kmv

Новичок
Да, совершенно верно - должна быть однобайтная, а по факту покаывает по два байта - те. нормальный юникод.
Получается, апач при обработке post-данных мультипарта обрабатывает их в latin1
Но как это исправить или проверить?
 

Фанат

oncle terrible
Команда форума
ты сейчас какую-то ерунду написал.
"должна быть однобайтная" - с какого перепугу?
"апач при обработке post-данных мультипарта обрабатывает их в latin1" - где ты это увидел?
 

kmv

Новичок
"должна быть однобайтная" - с какого перепугу?
iconv("utf-8","ISO-8859-1",$_REQUEST['test'])
вторым аргументом выходная кодировка, она latin1 - значит должна быть однобайтная.
"апач при обработке post-данных мультипарта обрабатывает их в latin1" - где ты это увидел?
я этого не увидел, я пытаюсь понять как такое может быть
 

Фанат

oncle terrible
Команда форума
у тебя всё с ног на голову.
многобайтную кодировку перекодировали в однобайтную - значит, показывает ОДНОбайтную.
по факту тебе показывает ОДНОбайтную.
форма присылвает всё правильно.
значит, проблемы с отображением.

несмотря на отданный заголовок.
 

kmv

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

WMix

герр M:)ller
Партнер клуба
покажи полные заголовки плиз то что написанно это хвост запроса и без окончания...

и убери iconv вообще
 

kmv

Новичок
iconv пользовал для того что бы подобрать правильную кодировку когда разбирался. его присутствие не влияет на ситуацию

Результат + все заголовки в фаербаге
scr-0011.png

исходный код + данные post
scr-0021.png

Сейчас думаю может ли как-то влиять, что сейчас ос win7 64 rus.
 

WMix

герр M:)ller
Партнер клуба
1. первая картинка, заголовки запроса, есть кнопочка исходный текст... этот запрос
2. меня интересует ответ на этот запрос
и раз уж мы играемся, добавь в титлы вооот такой символ ♤...
 

kmv

Новичок
Добавил знак ♤ - везде - и в тайтле в теле страницы отображается нормально. Т.е. таки utf-8

Исходный код заголовков запроса и ответа
scr-0031.png

Ответ
scr-004.png

В википедии нашел, что такие иероглифы это результат ошибочной обработки текста utf-8 как windows-1252. Откуда тут всплывает windows-1252 пока не могу понять.
 

WMix

герр M:)ller
Партнер клуба
этот ответ по идеи правильный...
по сути, тест - не "козявки". это и есть нормальный юникод, который смотрят через однобайтную скважину.
но в заголовке, вроде, утф. непонятно
то что ты видишь это уникод в кодировке изо... то что трефы видны смущает...
 

Вурдалак

Продвинутый новичок
Вот почему ты $r догадался var_dump'ом вывести, а чистый $_REQUEST['test'] — нет? Есть подозрение, что он выведет что-то типа
Код:
string(16) ...
Если текст действительно отправляется в UTF-8 до сервера, как ты нас убеждаешь в первом посте, то причина явно в сервере: какой-то тупой модуль у Apache может стоит?
 

kmv

Новичок
Да, var_dump чистого $_REQUEST['test'] выводит string(16). Приходит утф-8.
Получается, что проблема где-то в апаче?
 
Сверху