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의 정확성이 중요한 경우 누군가에게 읽을 때 공간에 밑줄을 혼동하지 않으려는 경우가 있습니다 (또는 그 반대).

나는 또한 그것이 무엇이든 중요하다면 대시가 더 미적으로 기쁘게 생각합니다.

최종 사용자보기의 경우 "about_us"가 아닌 "about-us"또는 "about us"를 선호합니다.

개인적으로 about-us 또는 about_us를 사용하지 말고 about을 사용하십시오.

일부 오래된 웹 호스팅 및 DNS 서버는 실제로 URL의 밑줄을 구문 분석하는 데 문제가 있으므로 이와 같은 규칙에 일부 영향을 줄 수 있습니다.

나는 개인적으로 모든 대시와 밑줄을 피하고 코드에 있으면 낙타 케이스 또는 파스칼 케이스를 선택 합니다.

camelCase의 Wikipedia 기사는 그 기원에 대한 약간의 추론을 설명합니다. 그들은 ~에 이른다

1. _ 키에 도달하지 않은 게으른 프로그래머
2. 가독성에 대한 잠재적 혼란
3. 밑줄 키가없는 xerox PARC의 "Alto"키보드.

사용자가 문자열을 보려면 위의 작업을 수행하지 말고 "About us"를 사용하십시오. 또는 camelCase가 제품 이름과 같은 일부 영역에서 일반적인 사용법으로 확산 된 경우 "AboutUs"입니다. 즉, ThinkPad, TiVo

URL에는 공백이 허용되므로 링크에서 "/ about us"를 사용하면됩니다 ( "/ about % 20us"로 인코딩되지만 솔직히 말하면 항상 개인적인 취향이므로 실제 답변은 없습니다) 여기에 주어질 것입니다.

대시가 단어로 나타날 수 있다는 규칙에 따라 공백을 밑줄로 변환해야합니다.

더 나은 사용. -/는 구분자로 사용됩니다. _는 구분자가 아닌 것 같습니다.

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