Chrome에서 링크 위로 마우스를 가져 가면 어떻게 되나요? 닫습니다. 그러나 경우에 따라 링크 위로

http://a//%%30%30Chrome 에서이 링크 ( )를 클릭하면 Chrome이 모든 탭과 인스턴스를 끊고 닫습니다.

그러나 경우에 따라 링크 위로 마우스를 가져 가면 탭이 충돌합니다.

이 링크 위로 마우스를 가져 가면 어떻게됩니까? 링크 위에 마우스를 올렸을 때 Chrome의 기능은 무엇인가요?



답변

충돌 인해에서 최근에 발견 된 버그입니다 크롬 및 기타 – 웹킷 브라우저 (!) * – 특히 중 하나와 관련된 %%30%30, %0%30또는 %%300URL의 일부로서 어떤 내부적으로 모든 최종 같은 기호를 나타내는 최대 : 널 (null)을 . 버그에 대한 자세한 내용은 여기를 참조하십시오 .

대부분의 링크에 영향을주는 버그는 아니므로 일반적으로 링크 위로 마우스를 올릴 염려가 없습니다.

참고 :
* 다른 WebKit 브라우저 에는 Safari, Opera, Steam Browser, Midori, S60 (Symbian), Blackberry Browser 및 Playstation 3의 브라우저가 포함 되지만 Firefox, Internet Explorer 또는 Edge는 포함 되지 않습니다 .

편집 :이 버그는 이제 수정되었습니다 크롬 45.0.2454.101Deltik는 지적한다.

어떻게되는지에 대해 더 알아보기

이 문제는 URL canonicalizer 와 관련이 있습니다. URL canonicalizer 는 링크 위에 마우스를 놓 자마자 실행되며 브라우저의 상태 표시 줄에 링크를 표시 하고 웹 페이지 를 프리 페치 하여 클릭하면 더 빨리로드됩니다.

다음 URL의 canonicalizer의 역할에 관해서는
URL이 작성 될 때 HTML,이 같은 형태로 기록 될 수 /home또는 ../../home하지만, 브라우저처럼, 너무 프로토콜 및 도메인 뭔가에이 URL을 번역해야합니다 http://superuser.com/home. 또한 URL이 포함 할 수 있습니다 URL 탈출을 필요하는 것을 번역 하고, 이러한 이스케이프가 있습니다 퍼센트 인코딩 처럼 %%30%30. ( 여기서 더 철저한 URL 이스케이프 목록 ).
URL 변환을 처리하는 기능 은 개발자가 예상 / 처리하지 않은 입력을 받기 때문에 작동이 중단됩니다.

다음 은 문제를 해결 한 코드 변경 사항에 대한 요약입니다.

URL 경로에서 문제가있는 중첩 이스케이프를 올바르게 처리합니다.

특히, 입력에서 이스케이프 처리를 해제하면 새로운 이스케이프 된 시퀀스가 ​​포함 된 출력 URL이 생성되는 경우 (예 : 입력 “%% 30 % 30″을 “% 00″로 변환) 선행 ‘%’를 “% 25″로 이스케이프하여 출력을 보장하십시오. sequence는 새로운 유효한 이스케이프 시퀀스로 취급되지 않습니다.

이렇게하면 동일한 URL을 두 번 정식화해도 URL이 변경되지 않으므로 디버그 및 릴리스 빌드의 다양한 위치에서 충돌 및 기타 버그를 피하는 데 중요합니다.


답변

Fabio Turati가 말했듯이

링크 위로 마우스를 가져 가면 Chrome이 왼쪽 하단에 링크를 표시합니다. 특수 인코딩 된 문자의 “번역”을 포함하여 일부 처리가 필요합니다.

그러나 귀하의 게시물과 의견에서 Chrome이 백그라운드의 링크에 연결되는지에 대해 더 우려하고 있다고 생각합니다. 그것은 않는 , 그래서 다른 최신 브라우저 (할 파이어 폭스 , 오페라 ). 더 많은 개인 정보 보호 설정을 얻으려면 Chrome 환경 설정에서 프리 페치를 비활성화하거나 uBlock Origin 을 설치 하십시오 .


답변

여기서 정확히 무슨 일이 일어나는지 좀 더 명확하게 설명하고 싶었습니다.

기본적으로 % 30은 URL로 인코딩 된 0이고 % 00은 URL로 인코딩 된 NULL (2 진수로 0000 0000로 표시됨)입니다. 따라서 인코딩 된 중첩 문자가있는 URL이 NULL로 디코딩되면 버그가 발생합니다.

URL을 표준화 할 때 Chrome은 다음을 수행합니다 (출처 : https://code.google.com/p/chromium/issues/detail?id=533361#c13 ).

  • 입력 문자열 “http : //a.com/%%30%30″은 ” http://a.com/%00 “으로 이스케이프 해제되어 유효한 GURL로 간주됩니다.
  • 이 GURL은 결국 GURLToDatabaseURL ()으로 전송되며,이 URL은 ReplaceComponents ()를 호출하여 사용자 이름과 비밀번호를 제거합니다.
  • ReplaceComponents ()는 URL을 다시 정규화합니다.
  • 경로의 정규화가 “% 00″순서에 도달하고 이스케이프되지 않습니다.이 문자는 URL에서 유효하지 않은 0 문자이며 이스케이프 된 상태로 있지만 결과 URL은 유효하지 않은 것으로 표시합니다.
  • GURLToDatabaseURL ()으로 돌아 가면 새 URL에서 .spec ()을 호출하여 입력 URL이 유효하고 사용자 이름과 비밀번호 만 제거했기 때문에 URL이 유효 할 것으로 예상합니다. 이것은 확인합니다.

따라서 URL은 먼저 유효한 것으로 간주되지만 특정 개인 데이터를 제거한 후에는 무효화됩니다. 그러나 해당 데이터가 제거 된 후 해당 특정 코드를 호출 한 함수에는 유효한 URL이 필요합니다.

이 URL이 유효하지 않은 것으로 여겨지는 이유 중 하나는 문자열의 끝을 나타 내기 위해 많은 오래된 소프트웨어 및 언어에서 NULL을 사용하기 때문입니다 (기본적으로 컴퓨터에서 감지하기 쉬운 줄에 기본적으로 8 개의 0이 있기 때문입니다).