Кодирование/декодирование Параметры пути REST

Question

Я пытаюсь найти лучший способ обойти недостатки дизайна в веб-приложении, которое я поддерживаю. Одна часть службы передает параметр («myparam») на страницу .jsp, которая, в свою очередь, вызывает службу REST, включая наш myparam в качестве параметра пути. Конструктивный недостаток состоит в том, что myparam следует передавать как параметр формы, поскольку он может быть свободным текстом. Однако мы не можем изменить реализацию, поскольку другие стороны вовлечены в конец .jsp.

Мое решение заключалось в кодировании myparam с использованием шестнадцатеричного кодирования (только кодирование URL-адреса не работает, поскольку вы заканчиваете «%» и т. Д., Что реализация REST в org.restlet не нравится в параметрах пути). Использование библиотеки Apache кодек, у меня есть что-то вроде этого:

Вариант 1 (только шестигранный):

String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); 

, которая работает для наших целей. То, что я действительно хотел сделать, чтобы объединить url- и Hex-кодирование, так что я действительно могу охватить все:

максимальными возможностями

Вариант 2 (шест + URL-декодирование): подготовка

Параметр:

String workText = URLEncoder.encode(inText, encoding); // a 
char[] encodedBytes = Hex.encodeHex(workText.getBytes()); // b 
String myparam = new String(encodedBytes); 

Декодирование (REST):

String decodedParam = new String(Hex.decodeHex(myparam.toCharArray())); // c 
String doubleDecodedParam = URLDecoder.decode(decodedParam, "UTF-8"); // d 

у меня есть два вопроса:

1. Почему не работает второй вариант? (всякий раз, когда я пытаюсь и URL-декодировать мою строку в d), я получаю java.lang.IllegalArgumentException). Я протестировал двойное кодирование и декодирование значений моих параметров на http://ostermiller.org/calc/encode.html без проблем.

2. есть ли лучший способ кодирования параметров пути с помощью REST?

Answer 1

Есть куча вещей, которые не выглядят совершенно правильно для меня в приведенном выше коде, касающемся наборов символов. На шаге кодирования вы предполагаете, что независимо от того, что делает класс Hex (какая структура является такой из?), Возвращает байты, которые могут быть интерпретированы как строка в кодировке, в которой работает JVM. Думаю, это работает, если договор Hex.encodeHex() поддерживает его.

Тогда есть другая сторона. Во-первых, вы декодируете шестнадцатеричную строку, используя UTF-8. Вы молчаливо предположили, что ваша JVM работает в UTF-8, поскольку вы передаете результат new String(), который предполагает, что массивы char из Hex.decodeHex() находятся в кодировке, в которой в настоящее время работает JVM, что может быть только UTF-8, если вы его декодируете как таковой. Я также не вижу смысла в этом кодировании URL-адреса. Похоже, что это полностью избыточно.

Я думаю, что все это не является основной проблемой. Есть еще одна проблема того, что именно происходит в промежуточном JSP. Вероятно, он расшифровывает все, что он получает, и перекодирует его. Это должно быть прозрачным, но я не уверен, на каком уровне вы принимаете эти данные. Если вы видите это, прежде чем он будет декодирован как параметр, может возникнуть неправильная интерпретация.