我阅读了以前的答案，写我自己的方法，因为我不能有一些正确的工作使用以前的答案的解决方案，它看起来对我很好，但如果你能找到不与此工作的URL，请让我知道。

public static URL convertToURLEscapingIllegalCharacters(String toEscape) throws MalformedURLException, URISyntaxException {
            URL url = new URL(toEscape);
            URI uri = new URI(url.getProtocol(), url.getUserInfo(), url.getHost(), url.getPort(), url.getPath(), url.getQuery(), url.getRef());
            //if a % is included in the toEscape string, it will be re-encoded to %25 and we don't want re-encoding, just encoding
            return new URL(uri.toString().replace("%25", "%"));
}

我同意马特的观点。事实上，我从未在教程中看到过很好的解释，但一个问题是如何编码URL路径，另一个非常不同的问题是如何编码附加到URL的参数(“?”符号后面的查询部分)。它们使用类似的编码，但并不相同。

专门用于空白字符的编码。URL路径需要编码为%20，而查询部分允许使用%20和“+”符号。最好的方法是使用Web浏览器对我们的Web服务器进行测试。

对于这两种情况，我总是会编码组件组件，而不是整个字符串。实际上URLEncoder允许查询部分这样做。对于路径部分，您可以使用类URI，尽管在本例中它要求整个字符串，而不是单个组件。

无论如何，我相信避免这些问题的最好方法是使用个人无冲突的设计。怎么做?例如，我从来不使用a-Z, a-Z, 0-9和_以外的字符命名目录或参数。这样，唯一需要做的就是对每个参数的值进行编码，因为它可能来自用户输入，使用的字符是未知的。

我开发了一个用于此目的的库:galimatias。它解析URL的方式与web浏览器相同。也就是说，如果一个URL在浏览器中工作，它将被galimatias正确解析。

在这种情况下:

// Parse
io.mola.galimatias.URL.parse(
    "http://search.barnesandnoble.com/booksearch/first book.pdf"
).toString()

会给你:http://search.barnesandnoble.com/booksearch/first%20book.pdf。当然，这是最简单的情况，但它可以用于任何东西，远远超出java.net.URI。

你可以在https://github.com/smola/galimatias上查看

我把上面的内容做了一些改变。我首先喜欢正逻辑，并且我认为HashSet可能比其他选项(比如通过String进行搜索)提供更好的性能。虽然，我不确定自动装箱的代价是否值得，但如果编译器针对ASCII字符进行了优化，那么装箱的代价就会很低。

/***
 * Replaces any character not specifically unreserved to an equivalent 
 * percent sequence.
 * @param s
 * @return
 */
public static String encodeURIcomponent(String s)
{
    StringBuilder o = new StringBuilder();
    for (char ch : s.toCharArray()) {
        if (isSafe(ch)) {
            o.append(ch);
        }
        else {
            o.append('%');
            o.append(toHex(ch / 16));
            o.append(toHex(ch % 16));
        }
    }
    return o.toString();
}

private static char toHex(int ch)
{
    return (char)(ch < 10 ? '0' + ch : 'A' + ch - 10);
}

// https://tools.ietf.org/html/rfc3986#section-2.3
public static final HashSet<Character> UnreservedChars = new HashSet<Character>(Arrays.asList(
        'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z',
        'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z',
        '0','1','2','3','4','5','6','7','8','9',
        '-','_','.','~'));
public static boolean isSafe(char ch)
{
    return UnreservedChars.contains(ch);
}

不幸的是，org.apache.commons.httpclient.uti.uriutil已弃用，替代的org.apache.commons.codec.net.URLCodec编码适用于表单帖子，而不适用于实际URL。所以我必须写我自己的函数，它只做一个组件(不适合有?'s和&'s的整个查询字符串)

public static String encodeURLComponent(final String s)
{
  if (s == null)
  {
    return "";
  }

  final StringBuilder sb = new StringBuilder();

  try
  {
    for (int i = 0; i < s.length(); i++)
    {
      final char c = s.charAt(i);

      if (((c >= 'A') && (c <= 'Z')) || ((c >= 'a') && (c <= 'z')) ||
          ((c >= '0') && (c <= '9')) ||
          (c == '-') ||  (c == '.')  || (c == '_') || (c == '~'))
      {
        sb.append(c);
      }
      else
      {
        final byte[] bytes = ("" + c).getBytes("UTF-8");

        for (byte b : bytes)
        {
          sb.append('%');

          int upper = (((int) b) >> 4) & 0xf;
          sb.append(Integer.toHexString(upper).toUpperCase(Locale.US));

          int lower = ((int) b) & 0xf;
          sb.append(Integer.toHexString(lower).toUpperCase(Locale.US));
        }
      }
    }

    return sb.toString();
  }
  catch (UnsupportedEncodingException uee)
  {
    throw new RuntimeException("UTF-8 unsupported!?", uee);
  }
}

如果你的URL中有一个编码的“/”(%2F)，这仍然是一个问题。

RFC 3986 -章节2.2说:“如果URI组件的数据与保留字符作为分隔符的目的相冲突，那么冲突的数据必须在URI形成之前进行百分比编码。”(rfc3986 -第2.2节)

但是Tomcat有一个问题:

http://tomcat.apache.org/security-6.html - Fixed in Apache Tomcat 6.0.10 important: Directory traversal CVE-2007-0450 Tomcat permits '\', '%2F' and '%5C' [...] . The following Java system properties have been added to Tomcat to provide additional control of the handling of path delimiters in URLs (both options default to false): org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH: true|false org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH: true|false Due to the impossibility to guarantee that all URLs are handled by Tomcat as they are in proxy servers, Tomcat should always be secured as if no proxy restricting context access was used. Affects: 6.0.0-6.0.9

因此，如果您有一个含有%2F字符的URL, Tomcat将返回:"400 Invalid URI: noSlash"

你可以在Tomcat启动脚本中切换bug修复:

set JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%   -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true