网址的最大长度是多少？
这可能与手机有关;在桌面上，它肯定取决于浏览器，如this question中所述。
我对规范或参考资料和经验数据感兴趣。
我的特殊用例是将一个非常长（约1600个字符）的URL传递给MIDlet.platformRequest(String url)，这是失败的。大多数URL（大约1575个字符）都是查询。
是否有任何其他考虑因素传递非常长的网址（例如，移动代理和网关截断网址）？
答案 0 :(得分：2)
根据HTTP规范，您可以依赖至少255个字符，但除此之外，它是特定于浏览器的。例如，根据各种来源，IE将URL的路径部分限制为2048个字符，而Apache显然抱怨URL＆gt; ~4000个字符。
来源：WWW FAQs: What is the maximum length of a URL?
我找不到任何对J2ME浏览器的URL限制的引用。
更新：“在移动浏览领域，URL限制可以低得多。许多手机仍然不支持长度超过128,256或512个字符的URL，特别是WAP设备（而不是支持完全爆炸的设备） HTTP浏览器）。“
答案 1 :(得分：0)
正如@Stephen C指出的那样，你只能依靠前255个字符来完成它。您可以修改您的应用程序以使用POST方法吗？ POST事务中可以发送的数据量没有限制。
答案 2 :(得分：0)
简短回答：这取决于，但可能足够长。
在对SonyEricsson J2ME仿真器（WTK 2.2.4），K610i和三星U700V进行调查后，答案很长。
经验测试：从模拟器中，platformRequest()将URL直接传递到桌面浏览器（在本例中为Firefox）。
http://test.example.com/?q=2048xxxxxxxxxxxxxxxxxxxxxxxxxxxx... xxxxxxxxxxxxxxxxxx2048
查看测试服务器的日志，我们发现我们可以将非常长的URL从模拟器传递到桌面到服务器。
在设备上（在这种情况下，SonyEricsson K610i，用户代理：“SonyEricssonK610i / R1CB Browser / NetFront / 3.3 Profile / MIDP-2.0 Configuration / CLDC-1.1”）可以处理至少3072个字符的URL （上限c.3800）。
在第二台设备Samsung U700V上，用户代理：“Mozilla / 5.0（X11; U; Linux i686; en-US; rv：1.8.0.7）Gecko / 20060909 Firefox / 1.5.0.7 MG（Novarra-Vision / 7.3 ）“，URL长度的下限是2048，但上限小于3072.请注意，这可能是Novarra代码转换器的问题，已知（至少）重写用户代理字符串。
没有Novarra转码（交换网络），U700V有一个用户代理“SAMSUNG-SGH-U700-Vodafone / BUGK1 SHP / VPP / R5 NetFront / 3.4 Qtv5.3 SMM-MMS / 1.2.0 profile / MIDP- 2.0配置/ CLDC-1.1“，下限为3072个字符。
这实际上结束了我对这个问题的答案的兴趣，因为这个经验测试使我的理论无效，即URL长度的上限导致了我的问题。
但是，为了完整起见，我将列出我的问题的潜在原因：
连接所需的URL至少有两个查询参数。分隔查询的＆符似乎混淆了模拟器。
模拟器以静默方式删除第二个参数。
在Samsung上，没有第二个参数，浏览器会连接，但long参数已损坏或丢失。
在K610i上使用第二个参数时，浏览器无法正常启动。
答案 3 :(得分：-4)
Microsoft Internet Explorer（浏览器） Microsoft声明Internet Explorer中URL的最大长度为2,083个字符，URL的路径部分中不超过2,048个字符。在我的测试中，尝试使用比此更长的URL会在Internet Explorer中生成明确的错误消息。 Firefox（浏览器） 在65,536个字符后，位置栏不再显示Windows Firefox 1.5.x中的URL。但是，较长的网址可以使用。我在100,000个字符后停止测试。 Safari（浏览器） 至少80,000个字符可以使用。我在80,000个字符后停止测试。 Opera（浏览器） 至少190,000个字符可以使用。我在190,000个字符后停止测试。 Opera 9 for Windows继续在位置栏中显示完全可编辑，可复制和可粘贴的URL，即使是190,000个字符。 Apache（服务器） 我早期尝试在Web浏览器中测量最大URL长度的过程会导致服务器URL长度限制大约为4,000个字符，之后Apache会产生“413 Entity Too Large”错误。我使用了当前最新的Red Hat Enterprise Linux 4中的Apache构建。官方Apache文档仅提到了请求中单个字段的8,192字节限制。 Microsoft Internet Information Server 默认限制为16,384个字符（是的，Microsoft的Web服务器接受比Microsoft的Web浏览器更长的URL）。这是可配置的。 Perl HTTP ::守护进程（服务器） 最多可以使用8,000个字节。那些使用Perl的HTTP :: Daemon模块构建Web应用程序服务器的人将在所有HTTP请求头的组合大小上遇到16,384字节的限制。这不包括POST方法表单数据，文件上载等，但它确实包含URL。实际上，当URL明显长于8,000个字符时，这会导致413错误。可以轻松删除此限制。在Daemon.pm中查找所有出现的16x1024，并用更大的值替换它们。当然，这确实会增加您遭受拒绝服务攻击的风险。 建议 极长的URL通常是一个错误。超过2,000个字符的网址在最受欢迎的网络浏览器中无效。如果您希望您的网站为大多数互联网用户工作，请不要使用它们
当您希望提交包含许多字段的表单时，否则会生成一个非常长的URL，标准解决方案是使用POST方法而不是GET方法：
...然后，表单字段作为HTTP事务正文的一部分传输，而不是作为URL的一部分传输，并且不受URL长度限制的约束。短期信息不应存储在URL中。
根据经验，如果由于返回收藏夹或书签而不需要重新生成同一页面的信息，则它不属于URL。 书签问题 在极少数情况下，在URL中保留大量“状态”信息可能很有用。例如，地图导航网站的用户可能希望将当前显示的地图添加到他们的“书签”或“收藏夹”列表中并稍后返回。如果您必须这样做并且您的网址长度接近2,000个字符，请尽可能紧凑地表达您的信息，尽可能多地挤出“空气”。如果您的字段名称占用太多空间，请使用固定字段顺序。挤出任何不需要加入书签的字段。并避免使用大的十进制数 - 只使用尽可能多的精度，并考虑使用字母和数字的base-64表示（我没有说这很容易）。
在极端情况下，请考虑使用gzip算法压缩漂亮但过长的网址。然后仅使用URL中合法的字符对base64中的二进制数据进行重新编码。这可以产生3-4倍的空间增益，当您在下次访问时再次解压缩URL时会花费一些CPU时间。再一次，我从来没有说过这很容易！
另一种方法是将状态信息存储在文件或数据库中。然后，您只能存储在URL中再次查找该信息所需的标识符。这里的缺点是你将拥有许多状态文件或数据库记录。其中一些可能与其他人运营的网站相关联。此问题的一个解决方案是删除在一定时间后未重新访问的URL的状态文件或数据库记录。