URL에 악센트 부호가있는 문자를 사용해야합니까?
영어와 다른 언어로 웹 콘텐츠를 만들면 검색 엔진 최적화 및 사용자 친화적 인 URL 문제가 발생합니다.
일부 단어가 특정 악센트가 있거나없는 완전히 다른 의미를 가질 위험이 있으므로 URL에서 악센트가없는 문자를 사용하는 것이 가장 좋은 방법인지 궁금합니다. 아니면 영어가 아닌 문자를 사용하는 것이 좋습니다. 덜 고급 환경 (예 : MSIE, 소스보기)에서 해당 URL의 가독성을 희생해야합니다.
"이국적인"문자는 문서 제목, 태그, 사용자 이름 등 어디에나 나타날 수 있으므로 항상 웹 사이트 관리자의 완전한 감독하에있는 것은 아닙니다.
물론 가능한 접근 방식은 원래 대상을 가리키는 대체 URL을 설정하는 것입니다.하지만 강조 표시된 URL을 기본 문서 식별자 로 사용하는 것에 대한 귀하의 의견을 배우고 싶습니다 .
비슷한 문제에 직면했을 때 URL 재 작성 을 이용 하여 악센트가있는 문자 나 악센트가없는 문자로 이러한 페이지에 액세스 할 수 있도록했습니다. 실제 URL은 다음과 같습니다.
http://www.mysite.com/myresume.html
그리고 다시 쓰기 + 문자 번역 기능은이 참조를 허용합니다
http://www.mysite.com/myresumé.html
동일한 리소스를로드합니다. 따라서 귀하의 질문에 대답하기 위해 기본 리소스 식별자 로서 0-9, AZ, az 및 가끔 하이픈으로 제한합니다.
여기에는 모호함이 없습니다. RFC3986은 no라고 말합니다 . 즉, URI는 유니 코드 문자를 포함 할 수없고 ASCII 만 포함 할 수 있습니다.
완전히 다른 문제는 브라우저가 URI를 표시 할 때 인코딩 된 문자를 나타내는 방법입니다. 예를 들어 일부 브라우저는 URL에 '% 20'대신 공백을 표시합니다. 이것이 IDN도 작동하는 방식입니다. punycoded 문자열은 브라우저에서 즉시 인코딩 및 디코딩되므로 café.com을 방문하면 실제로 xn--caf-dma.com을 방문하는 것입니다. URL에서 유니 코드 문자로 보이는 것은 실제로 브라우저 부분의 '시각적 설탕'일뿐입니다. IDN 또는 유니 코드를 지원하지 않는 브라우저를 사용하는 경우 URL의 기본 정의가 간단하기 때문에 인코딩 된 버전이 작동하지 않습니다. 지원하지 않으므로 일관되게 작동하려면 % 인코딩해야합니다.
악센트가있는 URL을 고려하면 종종 다음과 같이 보이는 경향이 있습니다.
http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant
... 그다지 좋지는 않습니다. 우리는 당분간 여전히 de-accented URL을 사용할 것이라고 생각합니다.
그러나 악센트 부호가있는 URL이 이제 웹 브라우저에서 허용되기 때문에 상황이 좋아질 것입니다.
내가 현재 사용하고있는 파이어 폭스 3.5는 URL을 % stuff, btw가 아닌 멋진 방식으로 표시합니다. 이것은 파이어 폭스 3.0 이후로 "새로운"것 같습니다 ( Firefox 3 : 위치 표시 줄에서 UTF-8 지원 참조 ); 따라서 적어도 IE 6에서는 지원되지 않을 것입니다. 그리고 여전히 이것을 사용하는 사람들이 너무 많습니다 :-(
악센트가없는 URL이 최상의 상태가 아닐 수 있습니다. 그러나 여전히 사람들은 그들에게 익숙하고 일반적으로 그들을 아주 잘 이해하는 것 같습니다.
사용자가 브라우저에 수동으로 입력 할 수있는 URL에 비 ASCII 문자를 사용하지 않아야합니다. 서버에서 미리 인코딩 된 포함 된 링크는 괜찮습니다.
우리는 브라우저가 다양한 방식으로 URL을 인코딩 할 수 있으며 어떤 인코딩을 사용하는지 파악하기가 매우 어렵다는 것을 알게되었습니다. 이 문제에 대한 내 질문을 참조하십시오.
전체 URL에는 여러 영역이 있으며 각 영역에는 다른 규칙이있을 수 있습니다. 프로토콜은 일반 ASCII입니다. DNS 항목은 IDN (International Domain Names) 규칙에 의해 관리되며 대부분의 유니 코드 문자를 포함 할 수 있습니다. 경로 (첫 번째 / 뒤), 사용자 이름 및 암호는 다시 모든 것이 될 수 있습니다. 이스케이프 처리되지만 (% XX로) 바이트 일뿐입니다. 이러한 바이트의 인코딩은 무엇인지 알기 어렵습니다 (http 서버에서 해석 됨). 매개 변수 부분 (첫 번째? 뒤)은 "있는 그대로"(% XX 이스케이프 해제 후) 일부 서버 측 응용 프로그램 사물 (php, asp, jsp, cgi)에 전달되며 바이트를 해석하는 방법은 또 다른 이야기입니다. 경로 / 사용자 / 암호 / 인수는 utf-8이지만 필수는 아니며 모든 사람이이를 존중하는 것은 아닙니다.
따라서 비 ASCII (우리는 더 이상 80 년대가 아님)를 허용해야하지만 정확히 수행하는 작업은 까다로울 수 있습니다. 유니 코드를 사용하고 레거시 코드 페이지를 멀리하고 가능한 경우 적절한 인코딩 / 문자 세트로 콘텐츠에 태그를 지정합니다 (html의 메타, asp / jsp에 대한 언어 지시문 사용 등).
참고 URL : https://stackoverflow.com/questions/1386262/should-i-use-accented-characters-in-urls
'Programing' 카테고리의 다른 글
| 뷰포트 메타 태그로 최소 너비 달성 (0) | 2020.12.13 |
|---|---|
| 시간대 정보로 MySQL에 datetime을 저장하는 방법 (0) | 2020.12.13 |
| foreach는 자동으로 Dispose를 호출합니까? (0) | 2020.12.13 |
| DateTime.Now가 메서드가 아닌 속성 인 이유는 무엇입니까? (0) | 2020.12.13 |
| 무엇을 (0) | 2020.12.13 |