require("3.php")
PHP는 require(_once)/include(_once) 지시어를 만나면 먼저 다음과 같은 판단을 내립니다.
포함할 파일 경로가 절대 경로인가요?
그렇다면 직접 포함하고 종료하세요.
그렇지 않은 경우 다른 로직을 입력하여(여러 호출 후 매크로 확장 후 _php_stream_fopen_with_path 입력) 이 파일을 찾으세요.
다음으로 _php_stream_fopen_with_path에서는 다음과 같은 판단이 내려집니다.
포함할 파일 경로가 상대 경로(./file, ../dir/file 형식, 아래의 "디렉터리 상대 경로"로 대체)입니까?
그렇다면 include_path 논리를 건너뛰고 상대 경로를 직접 구문 분석하세요(추후 별도로 소개).
은 include_path와 현재 실행 중인 파일의 경로를 기반으로 후보 디렉터리 목록을 구성합니다. 예를 들어 이전 기사의 예를 들면 다음과 같이 후보 목록이 구성됩니다. ".:path_to_subdir:current_script_dir" 그런 다음 후보 목록의 선두부터 DEFAULT_DIR_SEPARATOR(본 글의 환경은 ":")에 따라 후보 목록의 경로를 꺼내고, 끝에 포함될 파일명을 추가합니다. 성공적으로 포함되면 반환하고, 그렇지 않으면 다음 후보 경로를 계속 진행하세요. 지금까지 제가 처음 제기한 세 가지 질문에 답할 수 있었습니다. 1. 루트 디렉터리에서 실행되기 때문에 1.php에 2.php가 포함되어 있으면 include_path의 두 번째 후보 경로(path_to_subdir)가 작동하고 path_to_subdir/2.php를 찾으면 2. php에는 3.php가 포함되어 있고 현재 작업 디렉터리는 루트 아래에 있으므로 3.php가 포함되면 일치하는 파일이 include_path "."(현재 작업 디렉터리)의 첫 번째 후보 경로에서 발견됩니다. ". 2. 현재 경로가 subdir이라는 점을 제외하면 1과 동일하므로 출력은 "subdir"입니다. 3. 현재 경로에 include_path가 없기 때문에 루트 디렉터리에서 실행 시 3.php에 2.php가 포함되어 있을 때 path_to_subdir이 역할을 하므로 루트든 하위 디렉터리든 "subdir"을 얻게 됩니다. 산출. 그리고 2.php에서 include_path를 지우면, ini_set("include_path", '') require("3.php"); ?> 코드를 복사하세요
디렉토리의 상대 경로에서 상황을 설명하기 위해 다른 예를 살펴보겠습니다. 여전히 위의 디렉토리 구조이지만 1.php는 다음과 같습니다. ini_set("include_path", "/") require("./subdir/2.php" ); ?> 코드 복사
require("./3.php")
루트 디렉터리에서 실행하면 2.php에서 3.php를 검색하면 현재 디렉터리의 상대경로에서 검색이 되기 때문에 얻어지는 출력은 "root"이고, 상위 디렉터리의 하위 디렉터리에서 실행하면 레벨 디렉토리 1.php(php -f ../1.php)는 하위 디렉토리에서 "./subdir/2.php"를 찾을 수 없기 때문에 비정상적으로 종료됩니다. 요약 1. include_path와 상대 경로를 사용할 경우 검색 횟수에 따라 성능이 달라지기 때문에 최악의 경우 include_path가 10개일 경우 포함할 파일을 찾기 위해 최대 11번까지 재시도해야 할 수도 있습니다. . 이므로 절대 경로를 사용할 수 있는 경우 절대 경로를 사용하는 것이 가장 좋습니다. 2. 디렉터리 상대경로의 basedir은 항상 현재 작업경로이므로 사용하려면 실제 배포경로와 연계되어야 하므로 실제로는 거의 사용되지 않습니다(물론 그런 경우도 있습니다). chdir을 사용하여 완료하는 모듈도 있습니다). 3. 모듈식 시스템 설계에서는 일반적으로 모듈의 배포 경로를 얻어 모듈 내에서 절대 경로를 사용해야 합니다(dirname(__FILE__), php5.3 이상에서는 __DIR__ 상수 제공). |