>  Q&A  >  본문

PHP 8.1로 마이그레이션 - 더 이상 사용되지 않는 null을 매개변수로 전달하는 오류를 수정하는 방법 - 함수에서 빌드 이름 바꾸기

PHP 8.1에서 더 이상 사용되지 않음 null 作为参数传递给许多核心函数。我的主要问题是 htmlspecialchars(php)trim(php) 等函数,其中 null 더 이상 자동으로 빈 문자열로 변환되지 않습니다.

많은 코드를 사용하지 않고 이 문제를 해결하기 위해 원래 내장 함수의 이름을 바꾸고 null의 입력을 (빈) 문자열로 변환하는 래퍼로 대체해 보았습니다.

이 접근 방식의 주요 문제점은 기능 rename_function(PECL apd)이 더 이상 작동하지 않으며 2004년 1에 마지막으로 업데이트되었다는 것입니다.

함수가 호출될 때마다 null 검사를 작성하여 모든 코드가 두 배 커지는 것을 방지하려면 내장 함수를 다시 작성해야 합니다.

제가 생각할 수 있는 유일한 다른 해결책은 맞춤 기능을 사용하는 것입니다. 하지만 그러려면 여전히 제가 가지고 있는 모든 코드와 타사 라이브러리를 거쳐야 합니다.

PHP 8.1에서는 내장 함수에 전달될 때 null이 더 이상 자동으로 빈 문자열로 변환되지 않습니다.


  1. https://pecl.php.net/package/apd

P粉420868294P粉420868294306일 전475

모든 응답(2)나는 대답할 것이다

  • P粉811329034

    P粉8113290342024-01-11 15:36:30

    저는 그러한 "문제"를 어떻게 보고 해결하는지에 대한 다른 그림을 그릴 수 있다고 생각합니다. 이는 설명된 접근 방식의 옳고 그름을 감소시키지는 않지만 상호 이익이 되기를 바라는 추가 관점일 뿐입니다. 모든 프로젝트는 다릅니다.

    주어진 전제:

    글쎄 제가 보기에는 (처음에는) 보고 문제인 것 같습니다. 신고하지 않음 E_DEPRECATED.

    이것의 이점은 (귀하의 코드뿐만 아니라) 이제 귀하의 코드가 더 이상 사용되지 않는다는 알림과 함께 제공된다는 것을 알게 된다는 것입니다. 보고서는 정말 효과적입니다 .

    반면에 지원 중단 알림을 표시하지 않으면 해당 알림이 사라질 수 있습니다. 사용 중단 알림으로 코드베이스를 잃어버린 경우 기술적으로 여전히 손실을 복구하기가 쉬울 수 있지만(다시 말하면 사용 중단 알림 보고), 변경 사항이 연장되면 이제 엄청난 소음(E_TOO_MUCH_NOISE)이 발생할 수 있습니다.

    그럼 코드가 자동이 아닌 것은 실제로 나쁜 것인가요? 아니면 혜택으로 바뀔 수 있나요? 저는 후자를 선택하겠습니다. 그럼에도 불구하고 우리는 이미 이 정보를 처리하고 있습니다.

    그래서 이 경우에서 내 생각은 일반적으로 지원 중단 알림을 억제하지 않고 함수 호출을 "무음"시키는 것입니다. 쉽지만 좋은 의미로든 나쁜 의미로든 어리석습니다:

    으아아아

    이것은 물론 표준 텍스트 도구를 사용하여 코드 베이스에 적용할 수 있는 작업입니다. 또한 과거에 @ 억제 연산자가 사용된 위치도 보여줍니다.

    으아아아

    당신이 PHP 개발자이고 편집기에서 이와 같은 코드(케이스 #2-#4)를 본다면 그들은 즉시 당신에게 비명을 지르며 네 가지 경우 모두 적어도 주의를 끌 것입니다($mixed).

    침묵을 지켜주셔서 감사합니다. 우리는 이러한 장소에서 비명을 허용하지만 런타임에는 1 허용하지 않습니다.

    신고하지 않음으로써 묵비권을 행사하는 첫 번째 방법E_DEPRECATED 来保持沉默的方法不同,这种方法很容易丢失信息,而信息是通过使用所有 @과 달리 정보는 쉽게 유실될 수 있으므로 모든

    기호를 사용하여 정보를 저장합니다.

    @소음 문제 해결에 도움이 될까요? 우리가 여기서 일을 멈춘다면, 그것은 전혀 작동하지 않을 것입니다. 이제 코드에 - 기호를 표시하고 추가 조치를 취하지 않기로 결정하여 코드를 건드리지 않고 첫 번째 솔루션(지원 중단 메시지를 보고하지 않음)을 사용하여 완료할 수 있습니다.

    그렇다면 어떤 이점이 있나요? 이제 코드가 자동으로 실행

    하더라도 PHP는 여전히 진단 메시지를 제공합니다. 즉, 이제 (코드를 실행하는 동안) PHP 오류 핸들러를 리스너로 등록할 수 있습니다.

    @코드 수준에서만

    기호도 (보통) 코드에서도 쉽게 찾을 수 있으므로 이러한 위치를 쉽게 확인할 수 있습니다. 🎜

    두 번째 부분 중요합니다. 여러 장소가 지원 중단의 영향을 받을 수 있지만 모든 것을 해결하는 하나의 솔루션이 있어서는 안 되기 때문입니다(가능한 경우 "일률적인 솔루션"을 피하는 것을 선호합니다). 특히 질문의 맥락에서 PHP 8.1의 변경 사항을 보면 PHP 8.1이 사용되는 위치에 따라 요구 사항이 달라질 것이라고 생각됩니다

    예를 들어 템플릿 코드(출력)에서 구체적인 유형은 문제가 되지 않으므로 문자열로 변환하는 것이 가장 선호되는 솔루션입니다.

    으아아아

    템플릿(출력)은 안정적으로 유지됩니다.

    그러나 실제 입력 처리의 경우 지원 중단 공지는 누락된 기본값(일을 지나치게 복잡하게 함), 불분명한 값 처리(null 대 null, 문자열, 부울 대 숫자)와 같이 수정해야 할 실제 잠재적인 결함을 드러낼 수 있습니다. ) )는 PHP의 배열과 객체) 또는 일반적으로 $mixed와 혼동됩니다.

    trim($mixed)는 아마도 수년간 잊혀진 보안이고 한 번도 업그레이드된 적이 없는 보안일 것입니다(더 나은 보안이 가능합니다). 이와 같은 코드의 경우 trim ()을 사용하기 전에trim($mixed) 可能是一个被遗忘多年的安全防护,从未进行过升级(有更好的安全防护可用)。对于这样的代码,我很确定我已经想要并要求 $mixed 实际上是 $string before 我使用 trim () 실제로 $string

    을 이미 원하고 요구한다고 확신합니다. 그 이유는 매우 간단합니다. 적어도 두 가지가 직접적으로 떠오릅니다.
    • trim()a)는 더 이상 필요하지 않습니다 - 삭제할 수 있습니다(내가 가장 좋아하는 수정 사항 중 하나: 코드 삭제!) - 또는 -
    • b) 그것은
    • 끈 작업을 하는 것인데, 끈이 아닌 선물을 원하지 않기 때문에 문제가 있습니다. 문제는 일반적으로 샷건 접근 방식에서는 작동하지 않는다는 것입니다(Gießkanne 누구?).

    $mixed 进行修补是完全有效的? ''如果原始使用是字符串或null$mixed를 사용한 패치가 완전히 유효한가요? '' 원래 사용법이 문자열이거나 null

    only

    인 경우. TypeError 으아아아

    그러나 그 외에 예를 들어 42와 같은 숫자는 지원 중단 메시지 대신

    을 표시합니다. 이는 실행 중인 코드와 그렇지 않은 코드를 구별합니다.

    그래서 여기에서는 위치 확인, 가능한 경우 추가 클러스터링, 보다 전문적인 수정 사항 적용 등 유지 관리해야 할 작업이 더 많습니다. 누락된 테스트나 어설션이 드러날 수도 있고, 전체 애플리케이션 흐름을 안정화하는 데 시간이 걸릴 수도 있습니다. @

    이 경우 코드 마이그레이션을 완료하고 클러스터링을 수행하고 널 병합 연산자를 처리하고 실제 수정을 위해 적절한 서류 작업을 수행합니다. Null 병합 연산자를 사용하여 명확하지 않은 오류 억제를 완료하고

    억제 연산자를 제거한 후 수정 계획에서 해당 정보를 캡처하지 않으면 이 정보가 손실될 수 있습니다.

    이러한 부분을 좀 더 공부한 것 같아 머리를 긁적이거나 눈을 비비고 있는 모습을 보면 놀랍지 않습니다. 그런 다음 이러한 오류는 PHP 8.1 버전으로 인해 발생한 것이 아니며 버전 변경으로 인해 해당 오류가 (다시) 나타나며 때로는 PHP 버전을 유지 관리하여 전체 오류 클러스터가 부수적으로 발생한다는 점을 스스로 상기시킵니다.

    치트 시트🎜🎜
    • (string)$mixed - 이전 동작
    • $mixed ?? '' - 仅在 null 上抑制 TypeError 오류
    • @ - 전체 오류 억제. 해당되는 경우 코드베이스를 문서화해야 합니다.
    • @@ - 이런 일이 발생한다면, 이곳을 살펴보는 흥미로운 장소가 될 수 있습니다.
    • 空($mixed)? '' : xxx($mixed) - 전형적인 공기 마비/하이브리드 혼란인 쓰레기를 치우고 클러스터를 찾으십시오. 이는 코드 기반을 크게 단순화할 수 있는 기회입니다. 스칼라 유형(PHP 7)으로 마이그레이션하여 내부부터 엄격한 유형 지정을 도입하고 해당하는 경우 PHP "클래식" 및 "엄격한" 유형을 사용합니다. PHP 7.0 어설션과 PHP 8.1 지원 중단 메시지는 이를 잘 지원합니다.

    오류 처리기

    오류 처리에는 마법 같은 것이 없습니다. 이는 PHP.net에 문서화된 표준(예제 #1 포함)으로, 오류 이벤트에 대한 관찰자 역할을 하며 < 코드>를 통해 억제된 오류와 억제되지 않은 오류를 구별할 수 있습니다. error_reporting(php)error_reporting(php) / error_reporting(php-ini) 至少达到通常需要的级别,如果需要进行区分(在生产环境中,E_DEPRECATED 通常不是报告的一部分)。此示例性处理程序会抛出所有报告的错误,对于弃用事件以及 E_ALL 也会抛出此类错误,因此需要 @ / < code> error_reporting(php-ini)

    차별화가 필요한 경우 적어도 일반적으로 필요한 수준까지(프로덕션 환경에서

    는 일반적으로 report의 일부가 아닙니다). 이 예제 핸들러는 지원 중단 이벤트 및 E_ALL뿐만 아니라 보고된 모든 오류를 발생시키므로

    억제 연산자는 다음을 발생시키지 않아야 합니다.

    으아아아 비슷한 오류 처리기는 보고할 더 이상 사용되지 않는 코드를 포함하여 E_USER_DEPRECATED3v4l.org의 확장 예제에서 찾을 수 있습니다.

    E_USER_DEPRECATED 结合使用,与上面 E_DEPRECATED

    기술적으로 오류 억제 연산자는 위의

    에 대해 설명한 것과 동일한 방식으로

    와 함께 사용할 수 있습니다. E_DEPRECATED

    그러나 이에 대한 통제력은 약하고 🎜 🎜 이미 프로젝트 종속성에 있는 타사 코드에서 이미 사용 중일 수 있습니다. 다음과 같은 코드는 드문 일이 아닙니다: 🎜 으아아아 🎜정확히 동일한 작업을 수행합니다. 지원 중단 이벤트를 내보내지만 PHP 보고에서는 제외합니다. 이런 것들을 구독하면 소음에 빠져들게 될 수 있습니다. 🎜를 사용하면 언제든지 PHP에서 직접 "좋은 원본"을 얻을 수 있습니다. 🎜
    1. @ 错误抑制运算符的方法并对其进行评论时,IMSoP 立即举起红/黑旗(正确!),很容易将婴儿与洗澡水一起倒掉@ 억제 연산자 사용을 고려하는 경우. 내 대답의 목적은 단지 지원 중단 알림을 억제하는 것뿐이지만 사용의 결과는 모든 진단 메시지와 오류, 심지어 일부 PHP 버전의 치명적인 메시지도 억제하므로 PHP는 255로 종료됩니다. 더 이상 진단이 필요하지 않습니다. - 조심하고 관리하세요. 이 연산자는 강력합니다. 코드 베이스에서 사용량을 추적하고 기준/기대치를 충족하는지 지속적으로 확인하세요. 법적인 상황에서는 소음기 사용을 고려해보세요. 코드를 이식/유지하려면 먼저 표시하십시오. 일괄 편집을 마친 후에는 다시 삭제하세요.
    2. 회신하다
      0
  • P粉592085423

    P粉5920854232024-01-11 00:24:47

    먼저 기억해야 할 두 가지:

    1. PHP 8.1에서는 더 이상 사용되지 않는 이 호출로 인해 오류가 발생하지 않습니다. 사용 중단의 목적은 작성자에게 코드 수정을 사전에 알리는 것입니다. 따라서 귀하와 귀하가 사용하는 라이브러리 작성자는 PHP 9.0이 출시되기 전에 문제를 해결할 수 있습니다. 따라서 모든 문제가 즉시 해결될 수 있는 것은 아니므로 당황하지 말고 시간이 지나면 문제를 해결할 라이브러리 관리자에게 인내심을 가지십시오.
    2. 대부분의 경우 빠른 수정은 null 병합 연산자를 사용하여 적절한 기본값을 제공함으로써 사용할 때마다 긴 null 검사가 필요하지 않도록 하는 것입니다. 예를 들어 htmlspecialchars($something) 可以替换为 htmlspecialchars($something ?? '')

    다음으로 몇 가지 옵션:

    • 사례 수에 따라 몇 가지 문제를 한 번에 수동으로 수정하거나 ?? '' 추가하거나 논리 오류를 수정할 수도 있지만 어쨌든 null은 원하지 않습니다.
    • nullable_htmlspecialchars와 같은 사용자 정의 함수를 만들고 코드에서 직접 찾아 바꾸세요.
    • nullableoverridehtmlspecialchars;然后在添加 use function nullableoverridehtmlspecialchars;와 같은 사용자 정의 네임스페이스 함수를 생성하는 모든 파일은 내장 함수 대신 해당 함수를 사용합니다. 하지만 이는 모든 파일에 추가되어야 하므로 자동으로 추가하는 도구가 필요할 수 있습니다.
    • Rector를 사용하여 적절한 함수 호출에 ?? ''를 자동으로 추가하면 수동으로 편집할 필요가 없습니다. 불행히도 아직 이에 대한 기본 규칙이 없는 것 같으므로 직접 작성하는 방법을 배워야 합니다.
    • 기술에 따라 정규식 찾기 및 바꾸기를 사용하여 간단한 사례에 ?? ''를 추가하는 것이 더 쉬울 수도 있습니다.

    회신하다
    0
  • 취소회신하다