URL 应该区分大小写吗？
我注意到，
HTTPS://STACKOVERFLOW.COM/QUESTIONS/ASK
两者
https://stackoverflow.com/questions/ask
都工作正常 - 实际上前一个被转换为小写。
我认为这对用户来说是有意义的。
如果我查看 Google，那么这个 URL 工作正常：
https://www.google.com/intl/en/about/corporate/index.html
但是这个带有“关于”的 URL 不起作用：
https://www.google.com/intl/en/ABOUT/corporate/index.html
URL 应该区分大小写吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（18）
根据 W3 的“HTML 和 URL”，他们应该：
According to W3's "HTML and URLs" they should:
为了便于阅读，所有“不敏感”均以粗体显示。
根据 RFC 4343，域名不区分大小写。 URL 的其余部分通过 GET 方法发送到服务器。这可能区分大小写，也可能不区分大小写。
以此页面为例，stackoverflow.com 收到 GET 字符串 /questions/7996919/should-url-be-case-sensitive，将 HTML 文档发送到您的浏览器。 Stackoverflow.com 不区分大小写，因为它为 /QUEStions/7996919/Should-url- 生成相同的结果区分大小写。
另一方面，除了标题的第一个字符之外，维基百科区分大小写。网址 https://en.wikipedia.org/wiki/Case_sensitivity 和 https://en.wikipedia.org/wiki/case_sensitivity 导致同一篇文章，但是 https://en.wikipedia.org/wiki/CASE_SENSITIVITY 返回 404。
All “insensitive”s are boldened for readability.
Domain names are case insensitive according to RFC 4343. The rest of URL is sent to the server via the GET method. This may be case sensitive or not.
Take this page for example, stackoverflow.com receives GET string /questions/7996919/should-url-be-case-sensitive, sending a HTML document to your browser. Stackoverflow.com is case insensitive because it produces the same result for /QUEStions/7996919/Should-url-be-case-sensitive.
On the other hand, Wikipedia is case sensitive except the first character of the title. The URLs https://en.wikipedia.org/wiki/Case_sensitivity and https://en.wikipedia.org/wiki/case_sensitivity leads to the same article, but https://en.wikipedia.org/wiki/CASE_SENSITIVITY returns 404.
取决于托管操作系统。 Windows 上托管的站点往往不区分大小写，因为底层文件系统不区分大小写。 Unix 类型系统上托管的站点往往区分大小写，因为它们的底层文件系统通常区分大小写。 URL 的主机名部分始终不区分大小写，路径的其余部分会有所不同。
Depends on the hosting os. Sites that are hosted on Windows tend to be case insensitive as the underlying file system is case insensitive. Sites hosted on Unix type systems tend to be case sensitive as their underlying file systems are typically case sensitive. The host name part of the URL is always case insensitive, it's the rest of the path that varies.
URL 的域名部分不区分大小写，因为 DNS 忽略大小写：
https://en.example.org/和HTTPs://EN.EXAMPLE.ORG/都打开同一页面。该路径用于指定并可能查找所请求的资源。它区分大小写，但某些服务器（尤其是基于 Microsoft Windows 的服务器）可能将其视为不区分大小写。
如果服务器区分大小写并且
https://en.example.org/wiki/URL正确，则https://en.example.org/WIKI/URL> 或https://en.example.org/wiki/url将显示 HTTP 404 错误页面，除非这些 URL 本身指向有效资源。The domain name portion of a URL is not case sensitive since DNS ignores case:
https://en.example.org/andHTTPs://EN.EXAMPLE.ORG/both open the same page.The path is used to specify and perhaps find the resource requested. It is case-sensitive, though it may be treated as case-insensitive by some servers, especially those based on Microsoft Windows.
If the server is case sensitive and
https://en.example.org/wiki/URLis correct, thenhttps://en.example.org/WIKI/URLorhttps://en.example.org/wiki/urlwill display an HTTP 404 error page, unless these URLs point to valid resources themselves.我不喜欢翻旧文章，但因为这是针对这个特定问题的第一个回复，所以我觉得有必要澄清一些事情。
正如 @Bhavin Shah 的回答指出，url 的域名部分不区分大小写，因此
和
和
都是相同的，但域名部分之后的所有内容都被视为区分大小写。
所以...
并且
是不同的。
注意：在很多情况下，我说的是“技术上”而不是“字面上”，大多数情况下，服务器被设置为以相同的方式处理这些项目，但可以将它们设置为不以相同的方式处理它们.
不同的服务器对此的处理方式不同，并且在某些情况下它们必须区分大小写。在许多情况下，查询字符串值是经过编码的（例如作为查询字符串值传递的会话 ID 或 Base64 编码数据）。这些项目本质上区分大小写，因此服务器在处理它们时必须区分大小写。
因此，要回答“服务器在获取这些数据时是否应该区分大小写”这个问题，答案是“是的，绝对是”。
当然，并非所有内容都需要区分大小写，但服务器应该知道它是什么以及如何处理这些情况。
@Hart Simha 的评论基本上说了同样的事情。我在发布之前错过了它，所以我想在应得的信用处给予信用。
I am not a fan of bumping old articles but because this was one of the first responses for this particular issue I felt a need to clarify something.
As @Bhavin Shah answer states the domain part of the url is case insensitive, so
and
and
are all the same but everything after the domain name part is considered case sensitive.
so...
and
are different.
Note: I am talking "technically" and not "literally" in a lot of cases, most actually, servers are setup to handle these items the same, but it is possible to set them up so they are NOT handled the same.
Different servers handle this differently and in some cases they Have to be case sensitive. In many cases query string values are encoded (such as Session IDs or Base64 encoded data that's passed as a query string value) These items are case sensitive by their nature so the server has to be case sensitive in handling them.
So to answer the question, "should" servers be case sensitive in grabbing this data, the answer is "yes, most definitely."
Of course not everything needs to be case sensitive but the server should be aware of what that is and how to handle those cases.
@Hart Simha's comment basically says the same thing. I missed it before I posted so I want to give credit where credit is due.
RFC 3986 第 6.2.2.1 节 表示“方案和主机不区分大小写，因此应标准化为小写，例如 URI。
HTTPS://www.EXAMPLE.com/相当于https://www.example.com/。其他通用语法组件假定为区分大小写，除非方案另有明确定义”。服务器可能会在内部规范化传递的 URI，并为不同大小写的 URI（
/about/和/ABOUT/）提供相同的资源，使 URI 看起来不区分大小写用户。Section 6.2.2.1 of RFC 3986 says that "scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URI
HTTPS://www.EXAMPLE.com/is equivalent tohttps://www.example.com/. The other generic syntax components are assumed to be case-sensitive unless specifically defined otherwise by the scheme".A server might normalize the passed URI internally and serve the same resource for URIs of different case (
/about/and/ABOUT/), making an URI appear case-insensitive to the user.看看这里的规格：
第2.7.3节
https://datatracker.ietf。 org/doc/html/draft-ietf-httpbis-p1-messaging-25#page-19
Look at the specification here:
section 2.7.3
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p1-messaging-25#page-19
考虑以下内容：
https://www.example.com/createuser.php? name=Paul%20McCartney
在这个假设的示例中，HTML 表单（使用 GET 方法）将“name”参数发送到创建新用户帐户的 PHP 脚本。
我在这个例子中要表达的观点是，这个 GET 参数需要区分大小写，以保留“McCartney”的大写（或者，作为另一个例子，保留“Walter d'Isney”，因为还有其他方法名称打破通常的大写规则）。
正是这些情况指导了 W3C 建议，即方案和主机不区分大小写，但之后的所有内容都可能区分大小写 - 并由服务器决定。按标准强制不区分大小写将使上述示例无法保留作为 GET 查询参数传递的用户输入的大小写。
但我想说的是，虽然这必然是适应此类情况的法律条文，但法律的精神是，在与案件无关的情况下，以不区分大小写的方式行事。但是，这些标准无法告诉您哪些情况与大小写无关，因为就像我给出的示例一样，这是一个依赖于上下文的事情。
（例如，帐户用户名可能最好强制不区分大小写 - 因为“User123”和“user123”是不同的帐户可能会造成混淆 - 即使他们的真实姓名，如上所述，最好区分大小写。）
有时，大多数时候，它是相关的事实并非如此。但必须由服务器/网络开发人员来决定这些事情 - 并且不能由标准规定 - 因为只有在该级别才能知道上下文。
方案和主机不区分大小写（这表明标准对不区分大小写的偏好，可以普遍规定）。其余的由您决定，当您更好地了解上下文时。但是，正如已经讨论过的，本着法律精神，您可能应该默认不区分大小写，除非您有充分的理由不这样做。
Consider the following:
https://www.example.com/createuser.php?name=Paul%20McCartney
In this hypothetical example, an HTML form - using the GET method - sends the "name" parameter to a PHP script that creates a new user account.
And the point I'm making with this example is that this GET parameter needs to be case-sensitive to preserve the capitalisation of "McCartney" (or, as another example, to preserve "Walter d'Isney", as there are other ways for names to break the usual capitalisation rules).
It's cases like these which guides the W3C recommendation that scheme and host are case insensitive, but everything after that is potentially case sensitive - and is left up to the server. Forcing case insensitivity by standard would make the above example incapable of preserving the case of user input passed as a GET query parameter.
But what I'd say is that though this is necessarily the letter of the law to accommodate such cases, the spirit of the law is that, where case is irrelevant, behave in a case insensitive way. The standards, though, can't tell you where case is irrelevant because, like the examples I've given, it's a context-dependent thing.
(e.g. an account username is probably best forced to case insensitivity - as "User123" and "user123" being different accounts could prove confusing - even if their real name, as above, is best left case sensitive.)
Sometimes it's relevant, most times it isn't. But it has to be left up to the server / web developer to decide these things - and can't be prescribed by standard - as only at that level could the context be known.
The scheme and host are case insensitive (which shows the standard's preference for case insensitivity, where it can be universally prescribed). The rest is left up to you to decide, as you understand the context better. But, as has been discussed, you probably should, in the spirit of the law, default to case insensitivity unless you have a good reason not to.
大小写保留
URL 在客户端和服务器之间保留大小写。但出于多种原因，URL 的某些部分可能区分大小写，也可能不区分大小写，具体取决于服务器。
区分大小写
URL 的以下粗体部分可能区分大小写，具体取决于站点和/或服务器配置。
示例
https://www.示例。 com/abc/def.ghi?jkl=mno#pqr用户@example.com基本原理
URL 中的大小写敏感度可以有多种用途。主要是：
作为一名开发人员，我相信上述问题通常可以通过更好的方式处理，但我也理解在某些情况下可能不允许这样做。
例如，假设现有产品需要在“GET”URL 中放置大量数据，但它必须与所有主要服务器、浏览器和缓存/代理机制的最大 URL 长度兼容。为了适应中等长度的命令字符串（对于某些较旧的浏览器，小于 1,024 个字符），您需要使用所有可以使用的唯一 URL 安全字符（这基本上就是 base64url 编码）。
在理想世界中，
URL 是否应该区分大小写是有争议的。我个人认为，为了简单起见，它们不应该如此（尽管它可能会创建更长的 URL，但我们有百分比转义符可以轻松处理必须确保保留精确字符的情况，并且除了在 URL 中正确传输数据之外，还有其他方法可以传输数据） 。
许多人似乎都同意这一事实，即许多流行的网站和服务都明确启用了不区分大小写的 URL，以提高可用性。最突出的例子是电子邮件地址的用户名部分。大多数电子邮件提供商会忽略大小写，有时甚至忽略点和其他符号（例如“[电子邮件受保护] ”与“[电子邮件受保护]"）。尽管根据规范，电子邮件用户名默认区分大小写。
然而，事实是，无论我或其他人可能想要什么，这就是目前的情况。虽然最终在全球范围内过渡到不区分大小写的 URL 标准当然是可能的，但这可能需要相当长的时间，因为区分大小写目前在网络上广泛用于各种目的。
最佳实践
就最佳实践而言，作为用户，您可以在大多数情况下合理地坚持使用小写并期望事情能够正常工作。主要的例外是使用基于大小写的编码的 URL 或具有直接文件系统等效项的文档路径。然而，这种复杂的 URL 通常是复制粘贴（或简单地单击）而不是手动键入。
作为 Web 开发人员，您应该考虑使 URL 尽可能不区分大小写。尽管如上所述，根据具体情况，显然存在一些难以避免的情况。
Case Preservation
URLs are case-preserving, between client and server. But portions of URLs may or may not be case-sensitive, depending on the server, for a couple of reasons.
Case Sensitivity
The following bold parts of URLs may be case-sensitive, depending on the site and/or server configuration.
Examples
https://www.example.com/abc/def.ghi?jkl=mno#pqruser@example.comRationale
Case-sensitivity in URLs can have several uses. Mainly:
As a developer, I believe the above can often be handled in better ways, but I also understand there are cases where a situation may not permit this.
For example, imagine an existing product that requires a lot of data placed in the "GET" URL, yet it must be compatible with the maximum URL lengths of all major servers, browsers, and caching/proxy mechanisms. To fit even a moderate-length command string (under 1,024 characters for some older browsers), you'd need to use every unique URL-safe character you could (which is basically what base64url encoding is).
In an Ideal World
Whether or not URLs should be case-sensitive is debatable. I personally believe they should not be, for simplicity (though it may create longer URLs, we have percent-escapes to easily handle cases where we must ensure preservation of exact characters, and there are ways to transfer data other than right in the URL).
Many seem to agree based on the fact that case-insensitive URLs are explicitly enabled for many popular sites and services, in order to increase usability. The most prominent example is the username portion of email addresses. Most email providers will ignore case and sometimes even dots and other symbols (like "[email protected]" being the same as "[email protected]"). Even though email usernames are case-sensitive by default, according to spec.
However, the fact is that despite what I or others might want, this is the state of how things currently work. And while an eventual worldwide transition to a case-insensitive URL standard is certainly possible, it would likely take quite a long time since case-sensitivity is currently used extensively around the web for various purposes.
Best Practices
As far as best practices go, as a user you can reasonably stick to lowercase for most situations and expect things to work. The main exceptions would be URLs that use case-based encoding or document paths with direct filesystem equivalents. However, such complex URLs are typically copy-pasted (or simply clicked) rather than manually typed.
As a web developer, you should consider keeping URLs as case-insensitive as possible. Though there are clearly some difficult-to-avoid situations, depending on context, as noted above.
URL 应该不区分大小写，除非有充分的理由不区分大小写。
这不是强制性的（它不是 RFC 的任何部分），但它使 URL 的通信和存储更加可靠。
如果我的网站上有两个页面：
？
它们应该如何不同 也许有人写成“喊叫风格”（大写）——但从 IA 的角度来看，决不应该通过改变 URL 的大小写来进行区分。
此外，在 Apache 中实现这一点很容易 - 只需使用 mod_Speling 中的
CheckSpelling On即可。URLs should be case insensitive unless there is a good reason why they are should not be.
This is not mandatory (it is not any part of an RFC) but it makes the communication and storage of URLs far more reliable.
If I have two pages on a website:
and
How should they differ? Maybe one is written 'shouting style' (caps) - but from an IA point of view, the distinction should never be made by a change in the case of the URL.
Moreover, it is easy to implement this in Apache - just use
CheckSpelling Onfrom mod_Speling.老问题，但我在这里偶然发现，所以为什么不尝试一下，因为这个问题正在寻求不同的观点，而不是一个明确的答案。
w3c 可能有它的建议 - 我非常关心 - 但想重新考虑，因为问题就在这里。
为什么 w3c 认为域名不区分大小写，并在之后留下任何不区分大小写的内容？
我认为其基本原理是 URL 的域部分是由用户手动输入的。
成为超文本之后的一切都将由机器（后面的浏览器和服务器）来解析。
机器可以比人类更好地处理不区分大小写的情况（不是技术类型:)）。
但问题是因为机器可以处理，所以应该这样做吗？
我的意思是，命名和访问位于
hereIsTheResource的资源与hereistheresource相比有什么好处？侧面的字体比驼色字体的字体更难辨认，驼色字体的字体可读性更高。
人类可读（包括技术方面）。
因此，我的观点如下：-
资源路径位于编程结构中间的某个位置，有时靠近浏览器后面的最终用户。
如果您的用户希望触摸或键入 URL（不包括域名），则您的 URL（不包括域名）应该不区分大小写。您应该开发应用程序以尽可能避免让用户键入路径。
如果您的用户永远不会手动输入 URL（不包括域名），则您的 URL（不包括域名）应区分大小写。
结论
路径应区分大小写。我的观点是倾向于区分大小写的路径。
Old question but I stumbled here so why not take a shot at it since the question is seeking various perspective and not a definitive answer.
w3c may have its recommendations - which I care a lot - but want to rethink since the question is here.
Why does w3c consider domain names be case insensitive and leaves anything afterwards case insensitive ?
I am thinking that the rationale is that the domain part of the URL is hand typed by a user.
Everything after being hyper text will be resolved by the machine (browser and server in the back).
Machines can handle case insensitivity better than humans (not the technical kind:)).
But the question is just because the machines CAN handle that should it be done that way ?
I mean what are the benefits of naming and accessing a resource sitting at
hereIsTheResourcevshereistheresource?The lateral is very unreadable than the camel case one which is more readable.
Readable to Humans (including the technical kind.)
So here are my points:-
Resource Path falls in the somewhere in the middle of programming structure and being close to an end user behind the browser sometimes.
Your URL (excluding the domain name) should be case insensitive if your users are expected to touch it or type it etc. You should develop your application to AVOID having users type the path as much as possible.
Your URL (excluding the domain name) should be case sensitive if your users would never type it by hand.
Conclusion
Path should be case sensitive. My points are weighing towards the case sensitive paths.
URL 字符被转换为十六进制代码（如果您曾经注意到 URL 中的空格显示为 %20 等），并且由于小写和大写具有不同的十六进制值，因此 URL 绝对区分大小写是完全有道理的。然而，问题的实质似乎是应该将其作为标准，我说不，但事实确实如此。如果开发人员/提供商希望它能够工作而不管最终用户如何，则由开发人员/提供商在其代码中考虑这一点。
URL characters are converted into hex code (if you've ever noticed spaces in URLs being displayed as %20, etc.), and since lower and upper case have different hex values, it makes perfect sense that URLs are most definitely case sensitive. However the spirit of the question seems to be SHOULD that be the standard and I say no, but they are. Its up to the developer/provider to account for this in their code if they want it to work regardless for an end user.
我认为这个以及围绕规范所做或没有说的许多答案都没有抓住问题的要点。应该它们区分大小写吗？这确实是一个很沉重的问题。从用户的角度来看，区分大小写是一个痛点，并不是所有人都知道会产生影响。 URI 是否应该的问题取决于问题的上下文。出于技术灵活性的考虑，是的，它们应该是这样。就可用性而言，不，他们不应该这样。
I think this and many of the answers around what the spec does or does not say is missing the point of the question.Should they be case sensitive? That's a loaded question really. From a user's point of view, case sensitivity is a pain point, not all know makes a difference. The question of whether URIs should or shouldn't be, depends on the context of the question. For technical flexibility, yes, they should be. For usability, no, they should not be.
一般来说，URL 大小写敏感（以及大小写不同时是否相同）需要从以下几个角度来看待：
从资源等价的角度来看，一般是不可能的也就是说，无论大小写不同（小写、大写、句子大小写、驼峰式大小写……大小写的任意组合）的两个 URL 都彼此不同，除非从这两个 URL 检索资源，而这在许多情况下是不切实际的(RFC 3986，第 6.1 节，第 1 段）。因此，在无法检索资源的情况下，使用比较视角。
然而，如果可以检索资源，事情就会变得更加复杂（正如预期的那样）。根据 RFC 3986 第 3.3 节第 5 段 的规定，如下下面突出显示
因此似乎无法对 URI/URL 的其余部分做出超出通用语法的方案和权限（包括敏感性问题）的假设。
然而，对于权限的方案和主机部分，规范确实（仁慈地）声明它们不区分大小写。请参阅 RFC 3986，第 3.1 节，第 1 段 和 RFC 3986，第 6.2.2.1 节，第 2 段。
完成这一行查询后，我们应该从比较的角度来确定 URI/URL 是否区分大小写。
通过仔细阅读第 6.2.2.1 节（上文），可以看到该方向的第一个提示。
通过考虑 RFC 2616，第 3.2.3 节进一步推动该 方案
然后，最后，查询解决了，URL 区分大小写……（呵呵！），不完全是，操作词是“不透明”、“客户端”和“比较”。
除了它的语法之外，上面的 RFC 没有提到任何关于路径和查询的实际解释，除了它是“不透明的”，它只指定“客户端”如何（使用“应该”而不是“必须”）“比较”网址。它没有提到服务器（应该，更不用说必须）如何解释超出方案/权限的 URL 的其余部分。
因此，服务器拥有按照自己的意愿解释 URL 的所有自由度，正如其他人之前的帖子所强调的那样。
The case sensitivity of URLs, in general (along with whether they are same or not if they are in different case), needs to be looked at from the following perspectives:
From the perspective of resource equivalence it is generally not possible to say two URLs differing by any case (lower case, upper case, sentence case, camel case ... any combination of case) are different from each other unless the resource is retrieved from both the URLs, which in many cases is not practical (RFC 3986, section 6.1, para 1). Therefore where the resource cannot be retrieved, the comparison perspective is used.
However, in case where it is possible to retrieve the resource, the matter gets more (as expected) complicated. By the provisions of RFC 3986, Section 3.3, para 5, as highlighted below
it would appear that no assumption can be made for the rest of a URI/URL beyond it's scheme and authority from generic syntax (inclusive of the sensitivity question).
For scheme and host part of the authority, however, the specification does (charitably) state them to be case insensitive. Refer RFC 3986, section 3.1, para 1 and RFC 3986, section 6.2.2.1, para 2.
Having exhausted this line of inquiry one should look at the comparison perspective to determine whether URI/URLs are to be case sensitive or not.
The first hint to that direction emerges through perusal of the section 6.2.2.1 (above)
Which is further buoyed by considering RFC 2616, section 3.2.3
Then, finally, is the enquiry settled and URLs are case sensitive ... (heh!), not quite, the operative words are 'opaque', 'client' and 'comparing'.
Beyond it's syntax, The above RFC don't mention anything about the actual interpretation of the path and query except that it is 'opaque' and it only specifies how (with a SHOULD and not a MUST) a 'client' may 'compare' the URL. It mentions nothing regarding how a server (SHOULD, let alone MUST) interpret the rest of the URL beyond scheme/authority.
Therefore the server has all the latitude to interpret an URL as they please, which they do as highlighted by earlier posts by others.
提到官方指南后，有一个有趣的情况，应该考虑使用大写的整个 url：QR 码。
例如，
https://example.com/不适合版本 1 (21x21) QR 码，需要更大的版本 2 (25x25) QR 码。使用字母数字模式允许将
HTTPS://EXAMPLE.COM/12345填充到较小的版本 1 中！Having the official guidelines mentioned, there's an interesting case, where one should consider using the whole url in UPPERCASE: the QR codes.
For instance,
https://example.com/won't fit into a version 1 (21x21) QR code and will requre a larger version 2 (25x25) QR code.While using the alphanumeric mode allows to stuff
HTTPS://EXAMPLE.COM/12345into the smaller version 1!我认为区分大小写的 URL 没有任何用处或好的做法。它很愚蠢，很糟糕，应该始终避免。
只是为了支持我的观点，当有人问什么 URL 时，你如何解释 URL 的哪些字符是大写或小写？这是无稽之谈，应该没有人告诉你其他情况。
I see no use, or good practice behind case sensitive URL's. It stupid, it sucks and should be avoided at all times.
Just to back up my opinion, when someone asks what URL, how could you explain what characters of the URL are Upper or Lower case? That's nonsense and should no one ever tell you otherwise.
对于托管在 Linux 服务器中的网站，URL 区分大小写。
https://www.google.com/about 和 https://www.google.com/About 将被重定向到不同的位置。在 Windows Server 中，URL 不区分大小写，就像命名文件夹一样，并且将被重定向到相同位置。
For websites hosted in a Linux server, URL is case sensitive.
https://www.google.com/about and https://www.google.com/About will be redirected to different locations. While in a Windows Server, URL is case-insensitive, as in naming a FOLDER and will be redirected to same location.
可以使 URL 不区分大小写
，使 Google.com..GOOGLE.com 等直接指向 google.com
It is possible to make noncase sensitive URLs
Making Google.com..GOOGLE.com etc direct to google.com