问题标签 [uri]

.NET 中是否有一种简单的方法可以快速获取当前协议、主机和端口？例如，如果我在以下 URL 上：

http://www.mywebsite.com:80/pages/page1.aspx

我需要返回：

http://www.mywebsite.com:80

我知道我可以Request.Url.AbsoluteUri用来获取完整的 URL，并且我知道我可以Request.Url.Authority用来获取主机和端口，但我不确定在不解析 URL 字符串的情况下获取协议的最佳方法。

有什么建议么？

我目前正在使用该模块URI::URL从相对 URL 生成完整 URL；但是，它的运行速度并没有我希望的那么快。有谁知道另一种可能更快的方法？

尝试运行 JSP 时出现以下错误。我正在使用 Tomcat 6.0.18，我想使用最新版本的 JSTL。

我应该使用哪个版本的 JSTL，哪个 URL 与哪个版本的 JSTL 一起使用？

我收到此错误

“根据标记文件中的 TLD 或属性指令，属性键不接受任何表达式”

我只想说我有这个工作，但我想切换 jar 文件中包含 TLD 文件的 JSTL jar 文件。（而不必将它们部署在 Web 应用程序中的某个位置并在 web.xml 中定义引用）。

我想鼓励我们的 RCP 应用程序的用户将问题详细信息发送给我们的支持部门。为此，我在标准错误对话框中添加了“联系支持”小部件。

我已经设法使用 URI 标头通过 Java 6 的 JDIC 调用发送堆栈跟踪：Desktop.getDesktop().mail(java.net.URI). 这将启动用户的邮件客户端，准备好让他们添加评论，然后点击发送。

我喜欢启动电子邮件客户端，因为它是用户习惯的，它告诉支持人员很多关于用户的信息（签名、联系方式等），我真的不想使用 Java Mail。

我想做的是将日志文件和堆栈跟踪作为文件附加，因此没有最大长度要求，用户会看到一封漂亮干净的电子邮件，并且支持部门有更多信息可供使用。

我可以用我正在采取的方法做到这一点吗？或者，还有更好的方法？

编辑：我在 OSGi 上下文中，所以捆绑 JDIC 是必要的。如果可能的话，我希望提供尽可能少的依赖项，并且为多个平台捆绑 JDIC 听起来并不有趣，尤其是对于这样一个小功能。

JavaMail 可能是合适的，但事实上这将在我们公司客户的桌面上。配置的设置/发现必须是透明的、自动的和可靠的。关于 JavaMail，配置似乎只是手动的。是这样吗？

我最喜欢的答案是使用Desktop.open()*.eml 文件。不幸的是Outlook Express（而不是 Outlook）打开 eml 文件。我不知道这是否是通常或默认配置 Windows 以打开这样的 EML 文件。这是平常的吗？或者是否有另一种基于文本的格式，a) 易于生成，b) 默认情况下在用户已经使用的同一电子邮件客户端中打开？

如何在文本块中发现 URI？

这个想法是将这样的文本运行变成链接。如果只考虑 http(s) 和 ftp(s) 方案，这很简单；但是，我猜一般问题（考虑到 tel、mailto 和其他 URI 方案）要复杂得多（如果可能的话）。

如果可能的话，我更喜欢 C# 中的解决方案。谢谢你。

无论站点是否在虚拟目录中，也无论我的代码在目录结构中的什么位置，我怎样才能始终如一地获得站点的绝对、完全限定的根或基本 URL？我已经尝试了所有我能想到的变量和函数，但没有找到好的方法。

我希望能够获取当前站点的 url，即http://www.example.com或者如果它是一个虚拟目录，http://www.example.com/DNN/

这是我尝试过的一些事情和结果。唯一包含我想要的整个部分（http://localhost:4471/DNN441）的是 Request.URI.AbsoluteURI：

• Request.PhysicalPath: C:\WebSites\DNN441\Default.aspx
• 请求.应用程序路径：/DNN441
• Request.PhysicalApplicationPath: C:\WebSites\DNN441\
• 地图路径：C:\WebSites\DNN441\DesktopModules\Articles\Templates\Default.aspx
• RawURL：/DNN441/ModuleTesting/Articles/tabid/56/ctl/Det​​ails/mid/374/ItemID/1/Default.aspx
• Request.Url.AbsoluteUri：http://localhost:4471/DNN441/Default.aspx
• Request.Url.AbsolutePath: /DNN441/Default.aspx
• Request.Url.LocalPath: /DNN441/Default.aspx Request.Url.Host: localhost
• Request.Url.PathAndQuery: /DNN441/Default.aspx?TabId=56&ctl=Details&mid=374&ItemID=1

给 TOpenFileDialog 一个 URL，Execute 方法抛出一个异常：

但是您可以从 URL 打开文件。

德尔福5

使用全局唯一的 URI（如 REST 那样）引用资源与使用专有的 id 格式相比有什么好处？

例如：

1. http://host.com/student/5
2. http://host.com/student?id=5

在第一种方法中，整个 URL 是 ID。在第二种方法中，只有 5 是 ID。第一种方法比第二种方法有什么实际好处？

为什么 REST（似乎）不遗余力地提倡第一种方法？

- 编辑：

我的问题令人困惑，因为它确实问了两个不同的问题：

1. 可寻址性有什么好处？
2. 上面看到的两种 URI 形式有什么区别。

我已经使用自己的帖子回答了以下两个问题。

人们谈论URL、URI和URN就好像它们是不同的东西，但在肉眼看来它们是一样的。

它们之间有什么可区分的区别？

我正在构建一个数据库，该数据库将存储有关一系列对象（例如科学论文、标本、DNA 序列等）的信息，这些对象都在线存在并且可以通过 URL 或诸如DOI之类的标识符来识别. 使用这些 GUID 作为对象的主键似乎是一个合理的想法，并且我在使用 GUID 的 md5 哈希时遵循了美味和Connotea 。如果您将鼠标悬停在美味或 Connotea 书签中的编辑或删除按钮上，您将在浏览器状态栏中看到 md5 哈希。例如，http://stackoverflow/的书签是

其中 e4a42d992025b928a586b8bdc36ad38d a 是http://stackoverflow/的 md5 哈希值。

有人对这种方法的优缺点有看法吗？

对我来说，这种方法的一个优点（与使用由数据库本身生成的自动递增主键相反）是我必须在对象之间做很多链接，并且通过使用 md5 哈希，我可以将这些链接外部存储在一个文件中（例如，作为数据挖掘/抓取的结果），然后将它们批量导入数据库。同样，如果必须从头开始重建数据库，则指向对象的 URL 不会更改，因为它们使用 md5 哈希。

我欢迎任何关于这听起来是否合理的想法，或者是否有其他（更好的？）方法来做到这一点。