Изменения URI Java в JDK 1.4 против JDK 1.5 - PullRequest
0 голосов
/ 26 июля 2011
import java.net.*;

public class TestURI {
     public static void main(String args[]) throws URISyntaxException
     {
        String first = new String("foo");
        String second = new String("bar");
        String third = new String("[space or another space]");

        URI temp = new URI(first, second, third);
        System.out.println(temp.getFragment());

     }
}

Когда я запускаю приведенный выше код в JDK 1.4, я получаю

[пробел или другой пробел]

Когда я запускаю тот же код в JDK 1.5 / 1.6, я получаюследующее:

[пробел% 20or% 20another% 20space]

Может кто-нибудь сказать мне, что изменилось?

Спасибо, Радж

Редактировать:

Если я сделаю что-то вроде следующего, это сработает:

import java.net.*;

public class TestURI {
   public static void main(String args[]) throws URISyntaxException
   {
      String first = new String("foo");
      String second = new String("bar");
      String third = new String("[space or another space]").replaceAll("\\[", "leftSB").replaceAll("\\]", "rightSB");

      URI temp = new URI(first, second, third);
      System.out.println(temp.getFragment().replaceAll("leftSB", "\\[").replaceAll("rightSB", "\\]"));

   }
}

1 Ответ

1 голос
/ 28 июля 2011

Похоже, что пробелы получили URI-кодировку.

%20 - шестнадцатеричное форматирование символа ASCII.

Полагаю, пробелы в идентификаторе фрагмента недопустимы, чего не знала реализация в Java 1.4.

Из документации класса , выделено мной:

RFC 2396 позволяет появлению экранированных октетов в компонентах user-info, path, query и фрагмента. Экранирование служит двум целям в URI:

  • Для кодирования символов, отличных от US-ASCII, когда требуется, чтобы URI строго соответствовал RFC 2396 не содержащие других символов.

  • Цитировать символы, которые в противном случае являются недопустимыми в компоненте. Информация о пользователе, путь, запрос, и компоненты фрагмента немного отличаются с точки зрения того, какие символы считаются законными и незаконно.

Этим целям в этом классе служат три взаимосвязанные операции:

  • Символ кодируется , заменяя его последовательностью экранированных октетов, которые представлять этот символ в наборе символов UTF-8. [...]
  • Недопустимый символ цитируется просто путем его кодирования. Символ пробела, например, заменив его на "% 20" . [...]
  • Последовательность экранированных октетов декодируется , заменяя ее последовательностью символов, которую она представляет в наборе символов UTF-8. [...]

Эти операции представлены в конструкторах и методах этого класса следующим образом:

  • Конструктор с одним аргументом [...]

  • Конструкторы с несколькими аргументами заключают в кавычки недопустимые символы , как того требуют компоненты в котором они появляются. Символ процента ('%') всегда указывается этими конструкторами. Любые другие символы сохраняются.

  • ...
  • getUserInfo, getPath, getQuery, getFragment, getAuthority и getSchemeSpecificPart методы декодируют любые экранированные октеты в соответствующих компонентах. Строки, возвращаемые этими методы могут содержать как другие символы, так и недопустимые символы и не будут содержать экранированные символы октет.

Вы используете конструктор с тремя аргументами и метод getFragment впоследствии. Похоже, он должен снова декодировать пробелы, но это не так. Это может быть ошибкой, но база данных Sun Bug, похоже, сейчас недоступна, поэтому я не могу это проверить.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...