Предложенное решение:
Request.QueryString["VLTrap"].Replace(" ", "+");
Должен работать просто великолепно. Что касается Вашего беспокойства:
я имел, хотя из этого, но мое беспокойство с ним, и я должен был упомянуть это для запуска, то, что я не знаю то, что другие символы могли бы быть уродливыми в дополнение к знаку "плюс".
Это легко облегчить чтение о base64. Единственное не алфавитно-цифровые символы, которые законны в современном base64, "/", "+" и "=" (который только используется для дополнения).
Из тех, "+" единственный, который имеет особое значение как завершенное представление в URL. В то время как другие два имеют особое значение в URL (разделитель пути и разделитель строки запроса), они не должны создавать проблему.
, Таким образом, я думаю, что необходимо быть в порядке.
Если все, что у вас есть, - это файлы WAR, то полезность EAR ограничена, поскольку он служит только контейнером развертывания для ваших WAR. Вы можете сэкономить немного времени, разделяя JAR-файлы между WAR таким образом, но это само по себе не слишком убедительно.
EAR-файлы необходимы, однако, при работе с полными приложениями JavaEE / J2EE, которые используют WAR, EJB-файлы, JMS, ресурсы JCA и т. Д. Взаимодействиями и зависимостями между компонентами такого рода приложений намного проще управлять в EAR.
Но если все, для чего вы используете Weblogic, - это контейнер WAR, то вы также можете используйте ванильный контейнер сервлетов, такой как Tomcat или Jetty, для всех функциональных возможностей, которые вы получаете от Weblogic.
Я согласен почти со всеми комментариями Скаффмана (обычно).
Если вы используете Spring без EJB, вы, конечно, можете придерживаться WAR-файла. Я вижу, что уши не нужны.
Однако, если ваше приложение Spring использует объекты POJO, управляемые сообщениями, я могу видеть, где вы все еще развертываете файл WAR в WebLogic, чтобы воспользоваться преимуществами JMS.
EAR может потребоваться, если у вас есть EJB или JCA, но я бы не сказал, что JMS требует EAR. Я использовал JMS и развернул файл WAR в WebLogic, и он работал нормально.
Если вы решите пойти с Tomcat и развернуть там WAR, вы все равно можете сохранить функциональность JMS, если используете ActiveMQ.
Аргумент для упаковки нескольких WAR в EAR может быть убедительным, если вы столкнетесь с ситуацией, которую сделал мой последний работодатель, когда у вас есть общий набор библиотечных JAR, которые используются несколькими WAR, и размер этой коллекции JAR значительный. В нашей конкретной ситуации общий размер 3 WAR с общими JAR, упакованными в каждую WAR, составил 124 МБ. Путем размещения JAR в содержащем EAR и настройки пути к классам каждой WAR для использования этих JAR размер EAR, который содержал 3 WAR, был уменьшен до 40 МБ. Я считаю это веской причиной.