【问题标题】:HTMLCanvasElement.toDataURL - Incorrectly named function?HTMLCanvasElement.toDataURL - 函数命名不正确?
【发布时间】:2016-01-11 05:29:42
【问题描述】:

根据我目前的理解,声明数据 URI 实际上是 URL 是不正确的。

那么,考虑到这一点,我是否正确地说 JavaScript 函数 HTMLCanvasElement.getDataURL() 的名称不正确?或者有什么特定的原因让它如此命名。

我指的是this answer,因为它声明数据URI 不是 URL。

【问题讨论】:

  • 答案在您链接到的问题中。怎么又问了?
  • 我之所以问这个问题是因为我很惊讶像URL和URI之间的差异这样的愚蠢错误首先通过了规范批准过程,我想知道是否有具体原因为什么它可能以这种方式命名。我将改写这个问题,因为我的要求并不完全清楚。

标签: javascript url uri data-uri


【解决方案1】:

当前对 URI 和 URL 的定义可能会被认为是不准确的,但根据 W3 recommendation 的命名是基于定义数据 URL 方案的 RFC 2397

【讨论】:

  • 我现在明白了,谢谢。似乎 URL/URI 的具体/一致定义不存在。
  • 该 RFC 来自 1998 年。但是,在更现代的 URL spec 中保留了 URI 意义上的“不正确”使用 URL。
  • @Touffy 感谢您的链接。我特别提到了 2397,因为它在定义相关方法行为的规范中被引用。
  • 是的,实际上我重新阅读了 URL 规范,并直接从 WG 口中找到了更好的答案(请参阅我的帖子)
【解决方案2】:

WHATWG 决定这样做是可取的

对术语 URL 进行标准化。 URI 和 IRI 只是令人困惑。在实践中,两者都使用一个算法,因此保持它们不同对任何人都没有帮助。 URL 也轻松赢得搜索结果人气竞赛。

https://url.spec.whatwg.org/#goals

Web 浏览器现在有一个内置的标准化 URL 对象,用于创建 Blob URLs。告别 URI。

【讨论】:

  • 啊,我明白了。所以总体议程是逐步消除 URL 类型之间的区别?
  • 看@thephpdev,如果你想讨论这个问题,StackOverflow 不是正确的地方。使用 WHATWG 邮件列表或 github 上的规范项目。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-27
  • 1970-01-01
  • 2018-10-28
  • 1970-01-01
相关资源
最近更新 更多