MyTetra Share
Делитесь знаниями!
Документация по веб-серверу Apache версии PL18 - настройка кодировки (перевод на русский)
Время создания: 28.10.2022 11:09
Текстовые метки: apache, web, веб, сервер, настройка, кодировка, charset
Раздел: Компьютер - Linux - Сеть в Linux - Apache
Запись: xintrea/mytetra_syncro/master/base/1666944578vuw9as7n8q/text.html на raw.github.com

Здесь перечислены опции, которые помогают настроить кодировку текстов, отдаваемых из Apache в веб-браузер. Данные опции актуальны для 8-ми битных кодировок, и не имеют смысла для кодировки Unicode. Данная документация имеет больше историческое значение, так как перечисленные здесь опции на практике давно не используются.


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


Некоторые замечания

  • Все директивы, кроме CharsetDecl , CharsetRecodeTable и CharsetWideRecodeTable могут быть записаны где угодно - в конфигурации сервера, виртуального сервера, в <Directory>, <Location>, .htaccess. Директивы CharsetDecl и CharsetRecodeTable могут быть указаны только в конфигурации сервера или виртуального сервера.
  • При использовании директив в <Directory>, <Location> или .htaccess действует следущее правило - если определена какая-то из директив (скажем, CharsetAgent ), то все "вышележащие" директивы с этим именем не действуют. Это отличается от стандартного поведения Apache (когда содержимое директив "дописывается" (merge) т.е. определение в .htaccess работает абсолютно так же, как если бы эта директива стояла сразу после директивы с тем же именем в httpd.conf). Отклонение от стандарта объясняется очень просто - имея "перезаписывание" сделать эмуляцию "дописывания" очень просто (нужно просто скопировать нужные строчки из вышележащего .htaccess или из httpd.conf), тогда как обратное неверно.



Все директивы

Объявление таблиц перекодировки:

CharsetDecl CharsetRecodeTable CharsetWideRecodeTable CharsetAlias

Определение клиентской кодировки:

CharsetPriority CharsetDefault CharsetByPort CharsetAgent CharsetStrictURIMatch переменная FORCE_CHARSET

Определение кодировки на сервере:

CharsetSourceEnc CharsetByExtension переменная FORCE_SOURCE_CHARSET

Автоматический редирект:

CharsetAutoRedirect CharsetNormalizeToURL CharsetNormalizeTypes CharsetRedirectFromOriginalURL CharsetNoAutoRedirectForDefaultCharset

Разное:

CharsetProcessType CharsetBrokenAccept CharsetBadAgent CharsetErrReject CharsetUseMultiViews CharsetRecodeHeaders CharsetDisable CharsetRecodeFilenames CharsetSoftRedirect CharsetSoftRedirectPermanent CharsetSoftRedirectTemp CharsetOverrideExpires CharsetDisableForcedExpires CharsetRecodeMethodsIn/Out CharsetRecodeMultipartForms CharsetDisableAcceptCharset



Директивы, используемые для конфигурации


Объявления Charsets (кодировок) и таблиц перекодировки



CharsetDecl


Служит для объявления character set (charset, в русском языке утвердился термин "кодировка") и указания соответствующего ему Language. В дальнейших директивах в качестве имени charset можно указывать только одно из объявленных ранее имен.

Context: сервер, виртуальный сервер.

Default: никаких умолчаний нет

Синтаксис:

CharsetDecl CharsetName Language [Flags]


CharsetName

Официальное название кодировки (например windows-1251, koi8-r, ibm866, iso8859-5 и.т.д.). Используется в остальных директивах при ссылках на данную кодировку и при выдаче документа клиенту в заголовке Content-type: text/html; charset=CharsetName

Language

Название языка, к которому принадлежит данная кодировка. Это название должно быть определено в conf/srm.conf в директивах AddLanguage и LanguagePriority.

Flags

Поддерживается начиная с PL22. Необязательное поле, описывающее параметры данного charset. Возможные значения:

  1. S - (от Suppress) - подавить выдачу charset=... для данного Charset.

Примеры

CharsetDecl iso-8859-5 ru

CharsetDecl ibm866 ru

CharsetDecl windows-1251 ru

CharsetDecl koi8-r ru

CharsetDecl koi7 ru S


Каждая директива описывает только один charset. Если существует несколько виртуальных серверов то каждый виртуальный сервер "наследует" описания Charset от основного сервера только если в директиве <VirtualServer> не описано ни одного CharsetDecl и нет ни одной директивы CharsetRecodeTable .

Директивы CharsetDecl должны находиться в конфигурационном файле раньше всех прочих директив модуля.



CharsetRecodeTable


Служит для описания правил перекодировки из одной кодировки в другую.

Context: сервер, виртуальный сервер.

Default: никаких умолчаний нет

Синтаксис:

CharsetRecodeTable Charset1 Charset2 table_from [table_to]


Charset1, Charset2

Два названия Charset (описанных ранее директивой Charset), перекодировка между которыми описывается.

table_from

Имя файла с таблицей, описывающей перекодировку из Charset1 в Charset2. Имя файла указывается относительно корневой директории сервера ($SERVERROOT).

table_to

Имя файла с таблицей, описывающей перекодировку из Charset2 в Charset1. Может отсутствовать, тогда сервер сгенерирует таблицу, обратную table_from автоматически.

Для каждой пары Charset возможно два описания CharsetRecodeTable, которые являются эквивалентными. Две нижеприведенные директивы полностью одинаковы по своему эффекту:

CharsetRecodeTable koi8-r windows-1251 koi-win.tab win-koi.tab

CharsetRecodeTable windows-1251 koi8-r win-koi.tab koi-win.tab


Какую из них использовать - дело вкуса.

Если в конфигурации сервера указано несколько эквивалентных директив, то в работе будет использована последняя из них.

Если в конфигурации виртуального сервера есть хотя бы одна директива CharsetDecl или CharsetRecodeTable, то описания CharsetDecl/CharsetRecodeTable не наследуются от основного сервера.



CharsetWideRecodeTable


Служит для описания правил перекодировки в формате символ -> строка (например для поддержки транслитерации).

Context: сервер, виртуальный сервер.

Default: никаких умолчаний нет

Синтаксис:

CharsetWideRecodeTable CharsetFrom CharsetTo table


CharsetFrom, CharsetTo

Два названия Charset (описанных ранее директивой Charset), перекодировка между которыми описывается.

table

Имя файла с таблицей, описывающей перекодировку из Charset1 в Charset2. Имя файла указывается относительно корневой директории сервера ($SERVERROOT). Формат файла очень простой - на каждой строке записывается перекодируемая буква и через пробел соответствующая ей строка

Например:

CharsetWideRecodeTable koi8-r koi7 conf/koi-tran.tab


Если в конфигурации сервера указано несколько эквивалентных директив, то в работе будет использована последняя из них.

В отличия от директивы CharsetRecodeTable, таблица обратной перекодировки (из CharsetTo в CharsetFrom) не строится автоматически.



CharsetAlias


Служит для описания имен псевдонимов указанных charset.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: никаких умолчаний нет

Синтаксис:

CharsetAlias Oficial_Name Alias1 Alias2 Alias3 ...


Oficial_Name

Официальное имя описываемого charset. Должно быть определено до данной директивы директивой CharsetDecl .

Alias1 Alias2 ...

Имена псевдонимов для данного charset.

Примеры:

CharsetAlias iso_8859-5:1988 iso-ir-144 iso_8859-5 cyrillic iso-8859-5

CharsetAlias iso_8859-5:1988 iso8859-5 iso-8859.5 iso8859.5 iso

CharsetAlias ibm866 csibm866 866 cp866 x-cp866 x-ibm866 cp-866 alt

CharsetAlias windows-1251 win x-cp1251 cp1251 cp-1251


Псевдонимы используются при определении кодировки клиента по заголовкам Accept:, Accept-Charset:, по server-hostname prefix и по URI prefix (см. директиву CharsetSelectionOrder ).



Директивы, отвечающие за определение клиентской кодировки


CharsetSelectionOrder


Директива определяет порядок применения правил определения charset, в котором документ будет отдан клиенту.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:CharsetSelectionOrder Portnumber Hostname URIHostname EnvVariable Dirprefix Useragent

Синтаксис:

CharsetSelectionOrder Rule1 Rule2 Rule3 ...


Rule1, Rule2, Rule3

строка, определяющая порядок анализа различных параметров запроса на предмет определения клиентских предпочтений. В качестве имени Rule могут быть использованы:

  • Portnumber - определять charset по номеру порта к которому обратились. Соответствие кодировки и номера порта описывается директивой CharsetByPort . Возможность связать номер порта с кодировкой появилась начиная с версии PL20.2.
  • Hostname - определять charset по подстроке в hostname сервера. Т.е. если hostname (до первой точки) сервера начинается с имени charset или его alias, то в качестве клиентского charset будет выбран именно он (т.е. при обращении к хосту win-www.domain будет выбрана кодировка с именем/алиасом win).
  • URIHostname - аналогично Hostname, но с именами charset сравнивается не каноническое имя сервера, а имя, полученное в заголовке Host: от клиента примеры использования можно посмотреть в разделе рекомендации . Это правило поддерживается начиная с PL26.0.
  • EnvVariable - предназначена для взаимодействия со внешними модулями определения кодировки. Такие модули должны присвоить переменной окружения FORCE_CHARSET значение имени необходимого charset. Примеры использования совместно с mod_rewrite есть в разделе рекомендации . Это правило поддерживается начиная с PL26.0.
  • Dirprefix - определять charset по Directory prefix. Т.е. если первая часть URI (между 1-м и 2-м '/' или между /~username/ и 3-м slash) совпадает с именем или алиасом какого-то charset, то в качестве клиентского charset будет выбран именно этот charset.
  • Useragent - определять charset по HTTP-заголовку User-Agent (см директиву CharsetAgent ).

Замечания по использованию

При определении charset, в котором документ будет отдан пользователю сначала анализируются HTTP-заголовки Accept-Charset и Accept (второй - если эта возможность включена при компиляции сервера, см рекомендации по установке ). Если эти заголовки присутствуют и запрошенный charset известен (виртуальному) серверу, то документ будет отдан в соответствии с просьбой клиента. Если запрошенный charset серверу неизвестен и не запрашивается "любой" charset (Accept-Charset: *), то поведение сервера зависит от наличия флага CharsetErrReject - если он установлен, то сервер вернет пользователю ошибку.

Если charset не может быть определен по Accept-Charset, то сервер делает попытку определить его в соответствии с директивой CharsetSelectionOrder в порядке, описанном этой директивой.

Для определения (установки) по Hostname, первые символы hostname сервера (виртуального сервера) должны соответствовать имени или алиасу какого-то из известных серверу charset.

Для установки по Directory prefix, название или алиас какого-то из charset должны совпасть с первым элементом path в URL (для запроса вида /~username/path/to/file.html - совпасть с первым элементом пути после ~username).

Для определения клиентского charset по HTTP-заголовку User-Agent (т.е. по WWW-броузеру у пользователя) сервер ищет в заголовке User-Agent: одну из подстрок, указанных в директиве CharsetAgent .



CharsetPriority


Служит для определения приоритетов сконфигурированных charsets. Может иметь значение если в запросе клиента указаны равные весовые коэффициенты для различных charsets.

Старший из описанных этой директивой charset будет использован как "charset по-умолчанию" в том случае, когда такой charset не задан директивой CharsetDefault .

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет

Синтаксис:

CharsetPriority Charset1 Charset2 Charset3 ...


Charset1 Charset2 ..

Имена charset в порядке убывания приоритета (самый левый имеет высший приоритет). Все имена Charset должны быть определены до этой директивы с помощью директивы CharsetDecl .

Пример:

CharsetPriority windows-1251 koi8-r ibm866

В именах charset должны использоваться только официальные имена, а не псевдонимы.



CharsetDefault


Определяет имя charset по-умолчанию для данного сервера.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:Если CharsetDefault не определен, но определен CharsetPriotity, то будет использоваться charset с наибольшим приоритетом из CharsetPriority

Синтаксис:

CharsetDefault Charset_Name


Charset_Name

Официальное имя charset по-умолчанию для данного сервера, определенное директивой CharsetDecl .

Пример:

CharsetDefault koi8-r


Это тот charset, который будет выдаваться клиенту, если все другие способы определения не сработают.



CharsetByPort (работает начиная с PL20.2)


Директива позволяет связать номер TCP-порта с кодировкой.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: никакого

Синтаксис:

CharsetByPort Charset_Name port_number


Charset_Name

Имя charset, описанного директивой CharsetDecl

port_number

Номер порта

Пример:

CharsetByPort koi8-r 8101


- при обращении к порту 8101 использовать кодировку koi8-r.

Эта директива тесно коррелирует с директивой CharsetSelectionOrder , будте внимательны. Например, если у вас написано CharsetSelectionOrder Hostname, то директива CharsetPort не оказывает никакого воздействия на поведение сервера (равно как и CharsetAgent и т.п.).



CharsetAgent


Определяет charset, который может быть использован при нахождении в запросе клиента подстроки, идентифицирующей данного клиента. Эта подстрока ищется в запросе клиента в поле User-Agent.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет

Синтаксис:

CharsetAgent Charset_Name Pattern1 Pattern2 Pattern3 ...


Charset_Name

Официальное имя charset

Pattern1 Pattern2 ...

Шаблоны для поиска в запросе клиента в поле User-Agent.

Примеры:

CharsetAgent windows-1251 AIR_Mosaic IWENG/1 MSIE WinMosaic (Windows (WinNT;

CharsetAgent windows-1251 (Win16; (Win95; (16-bit)

CharsetAgent koi8-r Arena Ariadna Macintosh OmniWeb Sextant PRD (X11

CharsetAgent ibm866 DosLynx


Все Pattern являются подстроками, а не regexp выражениями. Если в заголовке User-Agent: содержится несколько подстрок, объявленных директивой CharsetAgent, то "сработает" самое длинное совпадение.



CharsetStrictURIMatch (работает начиная с Pl21.3)


Определяет "строгость" правил, по которым hostname/directory name будут сравниваться с именами известных кодировок при выборе Charset по Hostname/Dirprefix.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:CharsetStrictURIMatch Off

Синтаксис:

CharsetStrictURIMatch On|Off


Off

В режиме Off, кодировка по Hostname/Directory name будет выбрана, если первые символы Hostname/dirname совпадают с именем/алиасом какой-либо кодировки. Например, если серверу известна кодировка "win", то при обращении к директории /winnuke/ будет выбрана именно эта кодировка (естественно, в соответствии с директивой CharsetSelectionOrder

On

В этом режиме поведение сервера более строгое. Он будет проверять соответствие имени кодировки и полной host part в имени сервера/ полное название директории. Т.е. при известной кодировке "win" и обращении к http://winnuke.somewhere.domain кодировка по hostname выбираться не будет. С именами директорий - аналогично.


Правила обработки локальных файлов


CharsetSourceEnc


Определяет charset, в котором документы хранятся на диске.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет

Синтаксис:

CharsetSourceEnc Charsetname


Charsetname

Имя charset, описанное ранее директивой CharsetDecl

Эта директива позволяет указать в какой кодировке находятся HTML/CGI/SSI файлы на диске. Она может быть определена в том числе и в .htaccess, что позволяет хранить дерево документов в произвольной смеси кодировок. См. также директиву CharsetByExtension и описание переменной окружения FORCE_SOURCE_CHARSET . Если кодировку хранения файла определить не удается (т.е. директивы CharsetSourceEnc и CharsetByExtension для данного расширения не указаны), то сервер вернет клиенту сообщение об ошибке и отругается в error_log.



CharsetByExtension


Позволяет переопределить charset хранения для файлов с каким-либо расширением.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет

Синтаксис:

CharsetByExtension Charsetname .ext1 .ext2 ....


Charsetname

Имя charset, описанное ранее директивой CharsetDecl

ext1,ext2,...

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

Эта директива позволяет указать в какой кодировке находятся файлы с определенным расширением. Директива имеет больший приоритет, чем CharsetSourceEnc. Если для данной директории она не определена, то используется (с тем же более высоким приоритетом) "вышележащее" определение (из .htaccess директории более высокого уровня или из httpd.conf). Чтобы отключить вышележащее определение нужно задать пустую директиву CharsetByExtension. Расширение файла может содержать в себе любые символы, включая точку. Использование символа '/' как части расширения лишено смысла т.к. Apache считает, что '/' не может быть частью имени файла.



CharsetProcessType (работает начиная с PL21.2)


Позволяет указать серверу, что перекодировке следует подвергать какие-то добавочные MIME-types, отличные от text/*.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет, но сервер всегда будет перекодировать тип text/*

Синтаксис:

CharsetProcessType mime-type


mime-type

MIME-type в виде type/ или type/subtype, который тоже нужно перекодировать.

В редких случаях перекодировать нужно не только файлы с mime-type text/*, но и что-то еще. В таком случае нужно перечислить mime-type таких файлов этой директивой. В директиве можно указать как конкретный тип (например, image/jpeg), так и целый класс (image/). Отрицание (тип, который не нужно обрабатывать) задается символом ! ( !type/). Параметры обрабатываются слева направо, поэтому все исключения из общего правила должны быть левее общего правила (как в примере ниже)

Пример:

CharsetProcessType image/jpeg application/ application/php !application/ !text/plain text/




CharsetBrokenAccept (работает начиная с PL21.2)


Позволяет указать серверу комбинацию User-Agent/Accept-Charset, которую следует игнорировать при определении клиентской кодировки.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет

Синтаксис:

CharsetBrokenAccept Agent-Substring accept_charset_string


Agent-Substring

Подстрока в заголовке User-Agent (т.е. типе клиентского software).

accept_chaeset_string

Полная строка из заголовка Accept-Charset от данного клиентского software.

В случае когда в заголовке User-Agent находится подстрока Agent-Substring и заголовок Accept-Charset, полученный от клиента полностью совпадает с accept_charset_string, сервер будет игнорировать заголовок Accept-Charset полученный от клиента и будет определять кодировку по прочим признакам.

Эта директива стала необходимой с появлением Netscape Communicator 4.x - по умолчанию эта программа посылает в заголовке Accept-Charset строку "iso-8859-1,*,utf-8". В случае, когда один из сконфигурированных Charset имеет имя iso-8859-1, сервер всегда будет показывать клиенту эту кодировку, что не всегда правильно.

Пример:

CharsetBrokenAccept "Mozilla/4." "iso-8859-1,*,utf-8"




AddHandler strip-meta-http


Директива позволяет включить режим удаления тега <META HTTP-EQUIV=..> из HTML-файлов при передаче их клиенту.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет

Синтаксис:

AddHandler strip-meta-http .ext1 .ext2 .....


AddHandler strip-meta-http

"магические слова". На самом деле AddHandler - это директива mime_module, а strip-meta-http - название обработчика.

ext1, ext2

Список расширений файлов из которых нужно выкусывать <META HTTP-EQUIV...> Эти файлы будут обрабатываться как обычный plain HTML (т.е. не как CGI и не как .shtml, вне зависимости от расширений).

Директива предназначена для того, чтобы включить режим удаления тегов <META HTTP-EQUIV...> из документов, показываемых клиентам. Эти теги вставляет, например, Microsoft FrontPage. Рассуждениям на тему почему эти теги нужно выкусывать посвящен отдельный документ ). Если для одного расширения указано несколько AddHandler обработчиков, то какой из них сработает - зависит от конфигурации сервера.


Разное


CharsetBadAgent


Некоторые клиентские программы не могут адекватно реагировать на MIME, например при получении заголовка

Content-type: text/html; charset=koi8-r; level=3


Чтобы сервер не выдавал таким клиентским программам charset=... этих клиентов нужно описать директивой CharsetBadAgent.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: умолчаний нет

Синтаксис:

CharsetBadAgent Pattern1 Pattern2 Pattern3 ...


Pattern1 Pattern2 ...

Подстрока в поле User-agent запроса клиента, при нахождении которой сервер будет воздерживаться от выдачи charset=...

Пример:

BadAgent lynx/2.1 arena

Все Pattern являются подстроками, а не regexp выражениями.

Как справедливо заметил Andrey Chernov , указывать в этой директиве только название броузера, не указывая конкретной версии - значит нарываться на неприятности в будущем. К сожалению, до версии PL14 включительно, вместе с Apache-RUS распространялся "дистрибутивный" конфигурационный файл, в котором было сделано именно так (в BadAgent указаны lynx и MSIE). Начиная с версии PL15 это упущение исправлено. Правильная (на день написания этого текста) строка выглядит так:

CharsetBadAgent arena Lynx/2.0 Lynx/2.1 Lynx/2.2 Lynx/2.3 Lynx/2.4 "MSIE 2.0;"




CharsetErrReject


Директива служит для определения сервером действий при получении в запросе клиента неизвестного charset.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:CharestErrReject Off

Синтаксис:

CharsetErrReject On|Off


При установке этого параметра в On сервер не будет выдавать документ клиенту в случае невозможности удовлетворить запрос, полученный в заголовках Accept/Accept-Charset, а будет сообщать клиенту об ошибке в запросе. При установке в Off - попытается определить charset по другим параметрам (см директиву CharsetSelectionOrder ) и выдаст документ как сможет.



CharsetUseMultiViews (старое название - CharsetMatchLanguage, переименована в PL25.6)


Директива определяет случаи, в которых сервер будет выдавать charset=xxx в заголовке Content-Type:.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: CharsetUseMultiViews Off (в версиях младше PL25.6 - On)

Синтаксис:

CharsetUseMultiViews On|Off


При установке этого параметра в On (значение по умолчанию) сервер выдает charset=... в заголовке Content-Type при соблюдении всех трех условий:

  1. Броузер клиента не является "bad agent"
  2. Включена опция MultiViews
  3. Language, описанный для данного типа документа директивой AddLanguage совпадает с language, описанным для выдаваемого charset директивой CharsetDecl

При установке флага в Off сервер проверяет только первое условие (соответствие User-Agent/bad-agent list).



CharsetRecodeHeaders (работает начиная с PL20)


Директива включает перекодировку заголовков выдаваемых в HTTP-response.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: CharsetRecodeHeaders Off

Синтаксис:

CharsetRecodeHeaders On|Off


При установке этого параметра в On будут перекодироваться выдаваемые сервером заголовки. По-умолчанию такой перекодировки не производится т.к. старые версии не перекодировали и возникают серьезные проблемы с совместимостью. Директиву нужно использовать, если в заголовках может быть русский текст (скажем, Location: /some.cgi?Вася)



CharsetDisable (старое название - CharsetTurnOff, переименована в PL25.0) (работает начиная с PL20)


Директива выключает весь charset-processing module. Т.е. никакая перекодировка для данной <Directory>, <Location> и т.п. производиться не будет.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: CharsetDisable Off

Синтаксис:

CharsetDisable On|Off


Эта директива выключает перекодировки и AutoRedirect. При этом продолжают работать директивы CharsetSoftRedirect* и установка переменных CHARSET_HTTP_METHOD,CHARSET_SERVER_PORT, CHARSET_SERVER_NAME.



CharsetRecodeFilenames (работает начиная с PL21)


Директива включает перекодировку имен файлов в HTTP-запросе.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: CharsetRecodeFilenames On (для совместимости с прошлыми версиями)

Синтаксис:

CharsetRecodeFilenames On|Off


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

Использование перекодировки имен файлов не рекомендуется. См. также некоторые замечания на эту тему .



CharsetSoftRedirect (работает начиная с PL21.1)


Директива предназначена для замены директивы Redirect (из mod_alias) в случае работы с "перекодировкой по портам".

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: никакого

Синтаксис:

CharsetSoftRedirect [status] old-url new-url


Параметры:

status

(необязательный параметр) - описывает HTTP status code, который будет передан клиенту. Возможные значения:

  • permanent - Redirect возвращает статус 301 (permanent redirect)
  • temp - Redirect вернет статус 302 (temporary redirect) - это умолчание
  • seeother - статус 303 (See Other)
  • gone - статус 410 (Document removed) - указывает, что документа больше нет. В этом случае третий аргумент (new_url) должен отсутствовать.

old-url

"старый" URL - который должен быть перенаправлен. Указывается относительно Server-Root

new-url

"новый" URL - тот, который должен быть указан вместо старого.

Эта директива предназначена для замены стандартной директивы Redirect в случае использования "перекодировки по портам". Проблема стандартного Redirect заключается в том, что в качестве new-url нужно указывать URL полностью - с указанием протокола, имени сервера и порта. В то же время, при редиректах "в пределах текущего сервера" ни протокол, ни имя сервера, ни порт обычно не меняются для одного клиента, но могут быть разными для разных. CharsetSoftRedirect подставляет при редиректе текущие порт и hostname сервера.

Пример:

CharsetSoftRedirect temp /index.html /new-index.html




CharsetSoftRedirectPermanent (работает начиная с PL21.1)


Директива предназначена для замены директивы RedirectPermanent (из mod_alias) в случае работы с "перекодировкой по портам".

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: никакого

Синтаксис:

CharsetSoftRedirectPermanent old-url new-url


Параметры:

old-url

"старый" URL - который должен быть заредиректен. Указывается относительно Server-Root

new-url

"новый" URL - тот, который должен быть указан вместо старого.

Директива аналогична CharsetSoftRedirect permanent old-url new-url

Пример:

CharsetSoftRedirectPermanent /index.html /new-index.html




CharsetSoftRedirectTemp (работает начиная с PL21.1)


Директива предназначена для замены директивы RedirectTemp (из mod_alias) в случае работы с "перекодировкой по портам".

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default: никакого

Синтаксис:

CharsetSoftRedirectTemp old-url new-url


Параметры:

old-url

"старый" URL - который должен быть заредиректен. Указывается относительно Server-Root

new-url

"новый" URL - тот, который должен быть указан вместо старого.

Директива аналогична CharsetSoftRedirect temp old-url new-url

Пример:

CharsetSoftRedirectTemp /index.html /new-index.html




CharsetOverrideExpires (работает начиная с PL21.2)


Директива определяет поведение сервера в случае, когда документ должен быть сделать некэшируемым с помощью выдачи заголовка Expires:, но этот заголовок уже поставлен каким-то другим модулем.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:On

Синтаксис:

CharsetOverrideExpires On|Off


В режиме On сервер будет заменять значение заголовка Expires своим (обычно, 01 Jan 1970) в том случае, когда выдаваемый документ нужно сделать некэшируемым. В режиме Off будет оставаться значение, поставленное другими модулями или CGI-скриптом. Если никакого заголовка Expires другими модулями не поставлено и не включена директива CharsetDisableForcedExpires On, то сервер выдаст заголовок Expires:



CharsetDisableForcedExpires (работает начиная с PL24.0)


Директива запрещает выдачу заголовка Expires: 1 Jan 1970 модулем русификации.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:Off

Синтаксис:

CharsetDisableForcedExpires On|Off


В режиме Off (умолчание) сервер будет выдавать заголовок Expires: 1 Jan 1970 для всех документов, которые должны быть сделаны некэшируемыми (т.е. тех, в определении кодировки которых принимали участие данные, полученные от клиента - User-Agent или Accept-Charset не совпадающий с кодировкой, определенной по URL). Это - нормальное поведение сервера, если оно не устраивает для сервера в целом, то разумное решение проблемы описано в FAQ .

Однако Expires: бывает нужно запретить для отдельных документов, к ним относятся формы и framesets (в противном случае при reload или back пользователю будет показан начальный frameset или пустая форма). Только для этого режима работы и предназначена данная директива - если она включена для данного File/Location/etc, то Expires не выдается. Использование CharsetDisableForcedExpires для сервера/директории в целом потенциально весьма разрушительно.



CharsetRecodeMethodsIn & CharsetRecodeMethodsOut (работает начиная с PL23)


Директивы включает/выключает перекодировку для индивидуальных типов запросов (GET, POST, PUT) соответственно в направлении клиент->сервер и обратно.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:CharsetRecodeMethods* ALL

Синтаксис:

CharsetRecodeMethodsIn method1 [method2 [method3 [..]]]

CharsetRecodeMethodsOut method1 [method2 [method3 [..]]]


methodN - одно из ключевых слов GET, POST, PUT, ALL, NONE.

Вне зависимости от того, производятся ли реальные перекодировки или нет, в запросе (CGI-скрипте) доступны переменные CHARSET - кодировка клиента и SOURCE_CHARSET - "кодировка сервера"



CharsetRecodeMultipartForms (работает начиная с PL23)


Директива включает/выключает перекодировку для запросов типа POST с Content-Type: multipart/form-data. К таким запросам относится FileUpload, который нельзя перекодировать, если клиент передает двоичные данные.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:On

Синтаксис:

CharsetRecodeMultipartForms On|Off


В режиме On сервер будет перекодировать все запросы, в режиме Off - только запросы, Content-Type которых отличается от multipart/form-data.



CharsetDisableAcceptCharset (работает начиная с PL27.0)


Директива запрещает обработку заголовка Accept-Charset и выдачу заголовка Vary: accept-charset

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:Off

Синтаксис:

CharsetDisableAcceptCharset On|Off


В режиме Off (умолчание) сервер будет обрабатывать получаемый от пользователя заголовок Accept-Charset и выдавать документы в соответствии с ним. Одновременно выдается заголовок Vary: accept-charset, что отвечает стандарту HTTP/1.1.

В режиме On заголовок Accept-Charset не обрабатывается, Vary не выдается.

Назначение. Директива предназначена для обхода ошибки в Microsoft Internet Explorer 4.0x. Этот броузер считает некэшируемыми все документы в которых есть Vary: accept-charset (что приемлемо, но слишком жестоко - документ не должен кэшироваться если Accept-Charset сменился между запросами). Как следствие, если заполнить форму, а потом нажать Back, то форма будет перезапрошена с сервера и пользователь увидит ее пустой.

Использование CharsetDisableAcceptCharset для сервера с автоматическим выбором кодировки по броузеру клиента нарушает стандарты. Владельцы правильных броузеров (с Accept-Charset) не будут видеть правильной кодировки.



Автоматическое перенаправление (redirect) клиентов на URL

без автоматического выбора кодировки


Автоматическое определение клиентской кодировки "по броузеру" удобно в эксплуатациии, но порождает проблему - выдаваемые документы не кэшируются ни транзитными proxy-серверами (почему нельзя кэшировать документы с определением кодировки по клиентскому броузеру написано здесь ).

Очевидно, что решением проблемы будет - определить клиентскую кодировку (по заданным директивой CharsetSelectionOrder правилам) и выдать HTTP-Redirect на документ в той же кодировке, но с правильным URL (например, с http://www.server.ru/ -> http://www.server.ru/koi8-r/). Эта возможность появилась в Russian Apache начиная с версии PL28.0, для настройки такого поведения сервера используются следущие директивы:



CharsetAutoRedirect (работает начиная с PL28)


Директивы включает выдачу Redirect на URL, кодировка которых не зависит от пользовательских броузеров.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:нету

Синтаксис:

CharsetAutoRedirect charset urlprefix


charset - одна из кодировок, известных серверу.

urlprefix - то, что подставляется в начало запрошенного пользователем URL. Может иметь вид:

  • http://server/dirprefix
  • http://server:port/dirprefix
  • :port
  • /dirprefix
  • none

Редирект можно запретить, установив переменную окружения CHARSET_NOREDIRECT (например через BrowserMatch).

Пример:

CharsetAutoRedirect koi8-r http://server:8100/koi8-r/

CharsetAutoRedirect windows-1251 http://server:8101

CharsetAutoRedirect iso-8859-5 :8102

CharsetAutoRedirect ibm866 /ibm866

Представим, что пришел запрос на http://server2/file.html. В этом случае, в зависимости от кодировки клиента, сервер выдаст запрос на один из следующих URL:

  • http://server:8100/koi8-r/file.html - для кодировки KOI8-R
  • http://server:8101/file.html - для кодировки Windows-1251
  • http://server2:8102/file.html - для кодировки ISO-8859-5
  • http://server2/ibm866/file.html - для кодировки IBM866

Редирект выдается после определения клиентской кодировки, причем правила определения кодировки не меняются (и задаются через CharsetSelectionOrder ). Поэтому такая вот конфигурация:

CharsetSelectionOrder Portnumber Useragent

CharsetByPort koi8-r 8101

CharsetByPort windows-1251 8100

CharsetAutoRedirect koi8-r :8100

CharsetAutoRedirect windows-1251 :8101

приведет к бесконечному зацикливанию. Если порт не указан, то он сохраняется при редиректе, поэтому если подразумевается порт по-умолчанию (80), то нужно явно писать http://server:80/.



CharsetNormalizeToURL (работает начиная с PL28)


Директива предназначена для "нормализации" URL объектов, содержащих бинарные (т.е. неперекодируемые) данные.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:нет

Синтаксис:

CharsetNormalizeToURL urlprefix [minimal-size]


urlprefix - URL с которого должен начинаться канонический URL бинарного документа.

  • http://server/dirprefix
  • http://server:port/dirprefix
  • :port
  • /dirprefix
  • none

minimal-size - минимальный размер документа, для которого нужно производить "нормализацию" URL. По-умолчанию, 0 байт.

Редирект можно запретить, установив переменную окружения CHARSET_NOREDIRECT (например через BrowserMatch).

Пример:

CharsetNormalizeToURL :80 200

Данная директива заставляет сервер выдавать редирект на все запросы к бинарным (неперекодируемым) данным, размер которых больше 200 байт. Скажем, если был запрос к http://server:8100/bigimage.gif, то будет выдан редирект на http://server:80/bigimage.gif. Это нужно для того, чтобы бинарные данные не оседали в кэшах во многих экземплярах.

Если порт не указан, то он сохраняется при редиректе, поэтому если подразумевается порт по-умолчанию (80), то нужно явно писать http://server:80/.

С помощью этой директивы легко реализовать отдельный "сервер картинок" т.е. перенаправить все запросы к картинкам на другую машину:

CharsetNormalizeToURL http://images.mydomain.ru

Редиректы выдаются только для MIME-types, описанных директивой CharsetNormalizeTypes .



CharsetNormalizeTypes (работает начиная с PL28)


Определяет MIME-types, для которых будет выполняться нормализация URL (см. CharsetNormalizeToURL ).

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:нет

Синтаксис:

CharsetNormalizeTypes type1/ type2/subtype type3/ !type4/subtype type4/ type5/subtype !type5/


Синтаксис и логика перечисления mime-types аналогичны директиве CharsetProcessType . Пример:

CharsetNormalizeTypes application/zip video/mpeg image/



CharsetRedirectFromOriginalURL (работает начиная с PL28.7)


Определяет URL относительно которого будет производиться redirect. Директива имеет смысл, если URL поменялся в процессе обработки каким-либо модулем Apache (например, mod_rewrite), если URL не менялся, то никакого влияния не будет.

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:Off

Синтаксис:

CharsetRedirectFromOriginalURL On|Off


Эта директива имеет значение, если в процессе обработки запроса сервером оригинальный был изменен на какой-либо еще (например, через RewriteRule с флагом PT). Если флаг CharsetRedirectFromOriginalURL имеет значение Off, то редирект, определенный директивой CharsetAutoRedirect будет производится относительно нового (измененного) URL, если On, то относительно оригинального (введенного пользователем) URL.



CharsetNoAutoRedirectForDefaultCharset (работает начиная с PL28.16)


Определяет, производить ли AutoRedirect, если кодировка клиента определена не по содержимому запроса (т.е. не по URL/AcceptCharset/UserAgent, а по CharsetDefault/CharsetPriority).

Context: сервер, виртуальный сервер, <Directory>, <Location>, .htaccess

Default:Off

Синтаксис:

CharsetNoAutoRedirectForDefaultCharset On|Off


Назначение этой директивы - не производить редиректа, если клиент пришел на URL c автоматическим выбором кодировки без заголовка Accept-Charset и с неизвестным (не описанным директивой CharsetAgent ) User-Agent. Наиболее типичный пример - поисковая система. Если эта директива включена, то такой клиент получит требуемый документ. Если выключена - редирект на "кэшируемый" URL с этим документом.



Управление перекодировками из других модулей.


При необходимости явно задать кодировку хранения документа (из которой производится перекодирование), либо кодировку клиента (в которую производится перекодирование) другие модули могут использовать такие переменные окружения (в r-<subprocess_env):

FORCE_CHARSET

Устанавливает кодировку клиента, если это разрешено директивой конфигурации CharsetSelectionOrder .


FORCE_SOURCE_CHARSET

Устанавливает исходную ("на диске") кодировку документа. Имеет больший приоритет, чем CharsetSourceEnc и CharsetByExtension .



Дополнительные переменные окружения CGI-скриптов


Для удобства написания нетривиальных CGI-скриптов, сервер добавляет несколько дополнительных переменных окружения, доступных как для CGI, так и для модулей.

CHARSET

в этой переменной содержится "официальное" название кодировки клиента т.е. той, в которой документ будет отдан после перекодировки.


SOURCE_CHARSET

Кодировка исходного документа (по мнению сервера). Для CGI-скриптов это означает, что их вывод должен быть в этом charset.


CHARSET_SERVER_NAME

Имя сервера и номер порта в формате www.domain:1234

Эту переменную пришлось добавить т.к. в переменной HTTP_HOST содержится то, что сервер получил в заголовке Host:, а в переменной SERVER_PORT - номер порта, сконфигурированный директивой Port. Что никак не может устроить.

CHARSET_SERVER_PORT

Номер порта к которому был текущий запрос


CHARSET_HTTP_METHOD

http:// или https://. Т.е. полный URL запроса восстанавливается как ${CHARSET_HTTP_METHOD}${CHARSET_SERVER_NAME}${REQUEST_URI}


CHARSET_SAVED_QUERY_STRING

значение переменной QUERY_STRING до перекодировки


CHARSET_SAVED_PATH_INFO

значение переменной PATH_INFO до перекодировки

Переменные CHARSET и SOURCE_CHARSET ставятся сервером только если mod_charset "включен" (CharsetDisable Off), остальные три переменные ставятся всегда.


Так же в этом разделе:
 
MyTetra Share v.0.65
Яндекс индекс цитирования