URL : 대시와 밑줄

URL : 대시와 밑줄

---

 

/ about_us

또는

/ about-us

여야합니까 ?유용성 관점에서 개인적으로

/ about-us

는 최종 사용자에게는 훨씬 낫지 만 Google 및 대부분의 다른 웹 사이트 (및 자바 스크립트 프레임 워크)는 밑줄 명명 패턴을 사용합니다. 그것은 단지 스타일의 문제입니까? 대시와의 호환성 문제가 있습니까?

---

이것은 단지 추측이지만 사람들 이 이름으로 사용

하지 않을

것 같은 것을 고른 것 같습니다 . 이런 식으로 하이픈으로 된 단어를 포함하는 이름을 가질 수 있으며 여전히 밑줄을 단어 분리 자로 사용합니다. 예를 들어 UseTwo-wayLinks는 use_two-way_links로 변환 될 수 있습니다.예를 들어, / about-us는 하이픈이 붙은 단어 "about-us"라는 디렉토리가됩니다 (이러한 단어가 존재하는 경우 / about_us는 "about us"라는 두 단어 구가 단일 문자열로 변환 된 디렉토리가됩니다) 흰색이 아닌 문자

---

Google 웹 마스터 센터에서

URL에 구두점을 사용하는 것이 좋습니다. 의 URL

http://www.example.com/green-dress.html는

보다 훨씬 더 효과적입니다

http://www.example.com/greendress.html

. URL에서 밑줄 (_) 대신 하이픈 (-)을 사용하는 것이 좋습니다.

---

대시를 선호하는 몇 가지 사항은 다음과 같습니다.

• 밑줄 ( source ) 보다 Google에서 대시를 권장합니다 .
• 대시는 최종 사용자에게 더 친숙합니다.
• 대시는 표준 키보드로 작성하기가 더 쉽습니다 (Shift 필요 없음).
• 대시는 밑줄 뒤에 숨지 않습니다.
• 대시는 도메인 이름에서 허용되는 URL의 맥락에서보다 고유 한 느낌을줍니다.

---

대시 대 밑줄이 아닙니다.

• 공백이있는 텍스트
• 공백이없는 텍스트
• encode % 20spaces % 20in % 20URL
• 밑줄 _ 평균 _ 공간
• 대쉬-공간
• 더하기 + 평균 + 공간
• 낙타
• 파스칼 케이스
• "공백이있는 인용 된 텍스트" (및 작은 따옴표와 큰 따옴표)
• 슬래시 / 평균 / 공간
• dot.means.space

---

Google은 과거에 밑줄을 단어 구분 기호로 취급하지 않았지만 꽤 미쳤다고 생각했지만 분명히 그렇게합니다. 이 기록으로 인해 대시가 선호됩니다. SEO 관점에서 밑줄을 사용할 수 있지만 대시가 가장 좋다고 생각합니다.한 가지 장점은 평균 반 컴퓨터 불완전 웹 서퍼가 키보드에 대시를 입력 할 가능성이 훨씬 높다는 것입니다. 밑줄이 무엇인지조차 모를 수도 있습니다.

---

나는 항상 밑줄을 사용했지만 이제는 누군가가 직접 링크하고 싶지 않은 웹 사이트, js 파일, CSS 등의 부분에만 사용합니다. SEO 관점에서, 대시는 말 입

http://www.mattcutts.com/blog/dashes-vs-underscores/

에서 자세한 설명을 위해 대시 보드를 처리하는 선호되는 방법 인 것 같습니다 .프로그래머보다 일반인에게 더 많은 다른 문제는 밑줄이있는 하이퍼 링크에 밑줄이 표시되면 밑줄을 볼 수 없다는 것입니다. 고급 사용자는 문제를 해결할 것이지만 Joe Public은 그렇지 않을 것입니다.여전히 대시보다는 코드에서 밑줄을 사용합니다. 프로그래머는 이해하지만 대부분의 다른 사람들은 이해하지 않습니다.

---

Jeff는 이것에 대해 몇 가지 생각을 가지고 있습니다 :

https://blog.codinghorror.com/of-spaces-underscores-and-dashes/

둘 다 단점이 있습니다. 나는 당신이 하나를 선택하고 일관성을 유지하는 것이 좋습니다.

---

SEO 전문가 인

Jim Westergren

은 엄격한 SEO 관점에서 2005 년에 이것을 다시 테스트 했으며 + (플러스)가 실제로 최고의 단어 구분 기호라는 결론에 도달했습니다. 그러나 이것은 합리적이지 않으며 검색 엔진 알고리즘의 버그로 인한 것일 수 있습니다. 그는 가독성과 SEO 모두에 대해 (대시)를 권장합니다.

---

밑줄에 더 익숙합니다. 우선, 그들은 내 정규 프로그래밍 경험과 일치합니다

variable_names_are_not-subtraction

. 두 번째로, 이것이 이미 언급되었다고 생각합니다. 단어에는 하이픈이있을 수 있지만 밑줄은 없습니다. 정말 멍청한 예를 들면 "국가 국가"는 "국가 국가"와 다릅니다. 전자는 "국가의 나라"와 같은 것을 번역한다 ( "여기는 총국이다! 가장 잘 움직여?"라고 생각한다). 후자는 언젠가 동의어 목록처럼 보인다.

http://example.com/nation-state-country/

와 같은 의미는

http://example.com/nation-state_country/

아니지만, 하이픈이 단어의 문자 외에 구분 기호 / "공백"인 경우 가능합니다. 후자는 실제 목적에 대해 더 분명한 반면 전자는 그 목록과 비슷합니다.

---

밑줄은 공백이 허용되지 않는 공백을 대체합니다. 대시 (하이픈)는 단어의 일부일 수 있으므로 이미 하이픈을 포함하는 하이픈으로 단어를 결합하는 것은보기 흉하거나 혼란 스럽습니다.나쁜:

/low-budget-movies

좋은:

/low-budget_movies

---

대시는 사용자 관점에서 더 낫다고 생각하며 SEO를 방해하지 않습니다.밑줄 컨벤션이 어디서 또는 왜 시작되었는지 확실하지 않습니다.좀 더 지식이 풍부한

토론

---

링크 밑줄로 밑줄이 다소 가려 질 수 있다는 점에서 대시를 선호합니다. 텍스트 URL은 기본적으로 문법적으로 정확하지 않고 한눈에 인식되므로 하이픈으로 묶인 단어에 대시를 유지하기위한 인수가 제한됩니다.텍스트 URL의 정확성은 다른 사람이 읽을 때 중요합니다.이 경우 공백의 밑줄을 혼동하고 싶지 않습니다 (또는 그 반대).

I also find dashes more aesthetically pleasing, if that counts for anything.

---

For end-user view i prefer "about-us" or "about us" not "about_us"

---

Personally, I'd avoid using about-us or about_us, and just use about.

---

Some older web hosting and DNS servers actually have problems parsing underscores for URLs, so that may play a part in conventions like these.

---

I personally would avoid all dashes and underscores and opt for camelCase or PascalCase if its in code.

The Wikipedia article on camelCase explains a bit of the reasoning behind it's origins. They amount to

1. Lazy programmers who didn't like reaching for the _ key
2. Potential confusion about readability
3. The "Alto" keyboard at xerox PARC that had no underscore key.

If the user is to see the string then I'd do none of the above and use "About us." or "AboutUs" if I had to as camelCase has spread to common usage in some areas such as product names. i.e ThinkPad, TiVo

---

Spaces are allowed in URL's, so you can just use "/about us" in a link (although that will be encoded to "/about%20us". But be honest, this will always be personal preference, so there is no real answer to be given here.

I would go with the convention that dashes can appear in words, so spaces should be converted to underscores.

---

Better use . - / as separators, because _ seems not to be a separator.

http://www.sistrix.com/blog/832-how-long-may-a-linktext-be.html

참고URL : https://stackoverflow.com/questions/119312/urls-dash-vs-underscore