2010-02-08 3 views
5

우리는 내가 일하는 이상한 주장에 부딪 쳤고, 나는 이것에 대해 틀릴 수도 있습니다. 그래서 이것이 내가 묻는 이유입니다.디렉터리 이름에 밑줄이있는 URL 인코딩?

우리 소프트웨어는 디렉터리 이름에 밑줄을 % 5F로 바꾸는 Apache 서버로 디렉토리를 출력합니다.

예를 들어 디렉토리 이름이 우리 소프트웨어의 문자열로 나열된 경우 "andy_test"가되지만 소프트웨어가 디렉토리를 Apache 서버로 출력하면 "andy % 5Ftest"가됩니다. 불행히도 서버에있는 URL에 액세스하면 "andy % 255Ftest"가됩니다.

는 어떻게 든이 나에게 잘못된 것, 다시 한 번 진행은 다음과 같습니다

  1. andy_test < - (소프트웨어의 문자열로)
  2. 앤디 % 5Ftest < - (서버의 디렉토리로 표시)
  3. 255Ftest <이
  4. 앤디 % -. 웹 브라우저에서 서버의 URL과 같은 디렉토리를 호출 할 때 (사용해야합니다)

나는 assum 해요 "% 5"는 밑줄에 대한 인코딩이고 "% 25"은 "%"에 대한 인코딩입니다.

이제는 디렉토리 이름을 서버에 나열하는 방법이 일반 andy_test 일 것입니다. 인코딩 된 URI를 사용하는 경우 "andy % 5Ftest"로 끝나는 것일 수 있습니다. 아파치 서버의 디렉토리에 액세스하십시오.

나는 그것에 대해 백엔드에 사람을 물었고, 그들은 단지라고 말했다 : "문자 나 숫자 아니었다 아무것도 인코딩

그래서 나는 이것에 조금 혼란 스러워요 것 같아요.. ? 당신은 바로 누구인지 말해, 그 이유에 대한 몇 가지 정보를 나를 안내 할 수 있습니다

답변

9

디렉토리 이름을 만들 때 (제안 된대로) 인코딩하지 마십시오. 인코딩은 브라우저에 전달되는 마지막 단계에서만 발생해야합니다. 이유는 '이중'인코딩으로 끝나는 이유입니다. % 25는 %이고 5F는 밑줄의 첫 번째 인코딩에서 남은 것입니다.

BTW, 당신은 (내가 rfc1738에 따라 생각) 어쨌든 밑줄 인코딩 할 필요가 없습니다.

2.2.URL 문자 인코딩 문제

...

따라서, 단지 알파벳과 숫자, 특수 문자 "$ -_는. +! * '()', 그들의 예약 목적으로 사용 예약 된 문자는 를 사용할 수있다 URL 내에서 인코딩되지 않은

+1

RFC 참고 자료를 제공해 주셔서 감사합니다! – leeand00

3

당신이 보여주는 무슨에서 일어나고있는 이중 인코딩이 두 단계는 충분합니다.

andy_test는 소프트웨어의 문자열 모두입니다 파일 시스템의 디렉토리 또는 스크립트의 실제 이름 (웹 서버가 액세스하는 자원)

andy%5Ftestandy_test입니다. 이 문자열은 브라우저에서 사용해야합니다 (밑줄 문자에는 실제로 필요하지 않지만 다른 경우에있을 수 있음).

andy%255ftest은 할 필요가 없을 것, 말도 안돼 두 번 인코딩 단지 andy_test URL입니다. 인코딩을 수행 할 위치를 결정하십시오. 코드 레벨과 웹 서버 레벨에서이 작업을 수행하면 실제로 일어날 수있는 일이며 결과가 두 번 다시 디코딩되지 않으면 링크가 끊어집니다. 실제로는 필요하지도 않고 정상적이지 않습니다.

+0

나는 소프트웨어를위한 백엔드를 쓰지 않았다, 나는 백엔드에서 사람들이 뭔가 잘못되었다고 납득 시키려하고있다. – leeand00

+0

@ leeand00 : 두 번 일을하는 것이 잘못되었다는 것은 분명합니다. 목표는 인코딩을 수행 할 최적의 위치가 어디인지 확인하고 그 위치에서만 수행해야합니다 (두 번이 아님). –