Re: [apache-talk] meta charset problems

["Valera V.Kosmodamiansky" <valera@xxxxxxxxxxxxxxxx>]

    Уважаемые господа!

    Прочел всю эту перепалку про http-equiv, и не понял, почему
народ так горячится из-за (в сущности) ерунды. Предлагается вполне
конкретная вещь: извлекать кодировку хранения документа из <META> тага и
сообщать ее RA. Фича эта весьма полезна (другое дело, что многим она
_не нужна_ :), именно когда на сервере существует общественная свалка,
куда каждый кладет документы в одной ему известной кодировке. Если таких
документов мало, то web admin еще может как-то следить за целосностью
сервера, если же свалка большая, а людей, работающих с ней - много, то
было бы неплохо, если бы с этим справлялась программа - автоматически,
не требуя вмешательства людей.

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

   1. Специальной программой править файл .htaccess или же (если есть
      необходимость в запрете пользования .htaccess) - *.conf для
      данного virtual сервера.

      + Большой плюс этого решения (в особенности для Алекса) в том,
        что не нужно править RA. К сожалению, других плюсов я не вижу,
        хотя они могут и быть.

        Минусов же очень много.

      - Необходимо написать такую программу. И правильно, т.к. не дай бог
        что-либо неверно будет сгенерено в .htaccess - сервер выдаст 
        status 500. Но допустим, что программа создана, отлажена и прекрасно
        работает. Возникают проблемы с ее эксплуатацией.
      - Кто должен запускать эту программу? Очевидно cron, в противном случае
        это нужно будет делать ручками. Как часто? Раз в сутки - а если
        за эти сутки свалка сильно изменилась? Тогда юзеры могут
        получить документы из рассматриваемой свалки в неверной кодировке.
        Раз в десять минут (или в час)? (Это время, положим, среднее время 
        внесения существенных изменений в свалку) Тоже плохо: если свалка
        большая, то надо грепить большое число директорий и файлов. К
        тому же Apache придется часто перечитывать .htaccess. 
      - Со всем этим можно было бы примириться, если бы не факт, что
        пользователь, внеся изменния на сайте, хочет эти изменния увидеть
        _сейчас же_, а не через час и даже не через 10 мин. Не заставлять
        же вносившего изменения самому запускать эту программу (с доступом
        через Web)?

   2. На мой взгляд, менее тернистый и более правильный путь. Использовать
      (как правильно указал Frodo) готовый handler, который сейчас просто
      выкусывает <META> из HTML файлов. Просто необходимо его подправить
      так, чтоб он на некоторых файлах или директориях (здесь, видимо, 
      придется добавить еще одну директиву в конфиги Апача) он делал
      другое: 

        * определял локальную кодировку из тега META;
        * заменял эту кодировку на кодировку клиента.

      Решение этой задачи чисто техническое, и не требует внесения особых 
      изменений в RA. 

        + Плюсы этого решения: не нужно ничего дополнительно запускать из
          крона, .htaccess остаются без изменений и спокойно кешируются
          сервером и т.д. Т.е. админу не нужно проводить вообще никакой
          дополнительной работы, а пользователи свободно копируют свои
          файлы на сайт - в какой хошь кодироке...
        - Минусы: один и существенный. Необходимо править RA, в часности
          тот самый handler.

      Основные беды этого решения:

        * отсутствие возможности корректно менять локальную кодировку на лету. 
          Для этого должна быть создана особая подпрограмма в рамках
          RA API. Это предложение к Алексу.

        * handler должен определить локальную кодировку до того момента,
          как отдаст какой-либо кусок документа клиенту. Это уж делается
          совсем просто: 

             . в начале считывается N первых байт документа, которые и 
               парсятся;
             . если в них найден <META http-equiv>, то из него считывается
               кодировка (пусть из первого встречного тега, в надежде, что
               других не будет), устанавливается локальная кодировка
               (выше описанным еще не созданным вызовом API), а затем уже 
               отдается считаный кусок файла в нужной кодировке и с 
               исправленным тегом <META>. Далее - как было.
             . если не найден подобный тег - тогда какие проблеммы?

      Здесь можно и не править уже существующий handler, а на его базе 
      написать свой.


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

   С уважением, Valera.


PS В свое время у меня была задача изменения remote charset на лету
   (с условием, что charset не сообщался ни в HTTP ответе, ни в META)
   в SSI файлах (в которых, кстати, Апач все же имеет дело с HTML, пусть и в
   урезанном виде). Кодировка менялась особыми директивами SSI. Решив
   эту проблемму (а заодно еще несколько), я поспешил сообщить о ней Алексу.
   В ответ он мне написал, что модуль mod_include еще не затронут RA, а
   по сему и не хочется его затрагивать. Быть может Алекс и в данном вопросе
   придерживается той точки зрения, что чем меньше вносится изменений, тем 
   лучше?
=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =