PHP 8.2의 새로운 기능 — 새로운 기능, 사용 중단, 변경 사항 등

PHP 8.2는 PHP 8.0 및 PHP 8.1에서 제시한 갱신된 기반을 기반으로 합니다. 2022년 11월 24일 개봉 예정입니다.

이 기사에서는 PHP 8.2의 새로운 기능에 대해 자세히 설명합니다. 새로운 기능과 개선 사항부터 사용 중단 및 사소한 변경 사항에 이르기까지 모두 살펴보겠습니다.

PHP 8.2가 2022년 7월 19일에 기능 정지에 들어갔으므로 이 목록에 중요한 추가 사항이 없을 것으로 예상할 수 있습니다.

흥분한? 우리도 그래.

의 시작하자!

PHP 8.2의 새로운 기능 및 개선 사항

모든 최신 PHP 8.2 기능을 살펴보는 것으로 시작하겠습니다. 상당히 광범위한 목록입니다.

새로운 readonly 클래스

PHP 8.1은 클래스 속성에 대한 readonly 기능을 도입했습니다. 이제 PHP 8.2는 전체 클래스를 readonly 로 선언하는 지원을 추가하고 있습니다.

클래스를 readonly 로 선언하면 모든 속성이 자동으로 readonly 기능을 상속합니다. 따라서 클래스를 readonly 로 선언하는 것은 모든 클래스 속성을 readonly 로 선언하는 것과 같습니다.

예를 들어, PHP 8.1에서는 모든 클래스 속성을 readonly 로 선언하기 위해 이 지루한 코드를 작성해야 했습니다.

 class MyClass { public readonly string $myValue, public readonly int $myOtherValue public readonly string $myAnotherValue public readonly int $myYetAnotherValue }

더 많은 속성으로 동일한 것을 상상해보십시오. 이제 PHP 8.2에서는 다음과 같이 작성할 수 있습니다.

 readonly class MyClass { public string $myValue, public int $myOtherValue public string $myAnotherValue public int $myYetAnotherValue }

추상 또는 최종 클래스를 readonly 로 선언할 수도 있습니다. 여기서 키워드의 순서는 중요하지 않습니다.

 abstract readonly class Free {} final readonly class Dom {}

속성이 없는 readonly 클래스를 선언할 수도 있습니다. 효과적으로 이것은 동적 속성을 방지하는 동시에 자식 클래스가 readonly 속성을 명시적으로 선언하도록 허용합니다.

다음으로 readonly 클래스는 유형이 지정된 속성만 포함할 수 있습니다. 개별 읽기 전용 속성을 선언하는 것과 동일한 규칙입니다.

엄격한 형식의 속성을 선언할 수 없는 경우 mixed 형식 속성을 사용할 수 있습니다.

유형이 지정된 속성 없이 readonly 클래스를 선언하려고 하면 치명적인 오류가 발생합니다.

 readonly class Type { public $nope; } Fatal error: Readonly property Type::$nope must have type in ... on line ...

또한 특정 PHP 기능에 대해 readonly 을 선언할 수 없습니다.

• 열거형 (속성을 포함할 수 없으므로)
• 특성
• 인터페이스

이러한 기능을 readonly 으로 선언하려고 하면 구문 분석 오류가 발생합니다.

 readonly interface Destiny {} Parse error: syntax error, unexpected token "interface", expecting "abstract" or "final" or "readonly" or "class" in ... on line ...

모든 PHP 키워드의 경우와 마찬가지로 readonly 키워드는 대소문자를 구분하지 않습니다.

PHP 8.2는 또한 동적 속성을 더 이상 사용하지 않습니다(나중에 자세히 설명). 그러나 동적 속성이 클래스에 추가되는 것을 막을 수는 없습니다. 그러나 readonly 클래스에 대해 그렇게 하면 치명적인 오류만 발생합니다.

 Fatal error: Readonly property Test::$test must have type in ... on line ...

독립 실행형 유형으로 true , false 및 null 허용

PHP에는 이미 int , string 및 bool 과 같은 스칼라 유형이 포함되어 있습니다. 이는 PHP 8.0에서 공용체 유형을 추가하여 확장되어 다른 유형의 값을 허용합니다. 동일한 RFC는 또한 false 및 null 을 공용체 유형의 일부로 사용할 수 있도록 허용했지만 독립형 유형으로는 허용되지 않았습니다.

false 또는 null 을 선언하거나 공용체 유형의 일부가 아닌 독립형 유형으로 선언하려고 하면 치명적인 오류가 발생했습니다.

 function spam(): null {} function eggs(): false {} Fatal error: Null can not be used as a standalone type in ... on line ... Fatal error: False can not be used as a standalone type in ... on line ...

이 시나리오를 피하기 위해 PHP 8.2는 독립형 유형으로 false 및 null 사용에 대한 지원을 추가합니다. 이 추가로 PHP의 유형 시스템은 더 표현력 있고 완전해졌습니다. 이제 반환, 매개변수 및 속성 유형을 정확하게 선언할 수 있습니다.

또한 PHP에는 여전히 false 유형의 자연스러운 대응물인 true 유형이 포함되어 있지 않습니다. PHP 8.2는 이 문제를 수정하고 true 타입에 대한 지원도 추가합니다. false 유형이 작동하는 방식과 똑같이 강제를 허용하지 않습니다.

true 및 false 유형은 본질적으로 PHP의 bool 유형의 통합 유형입니다. 중복을 피하기 위해 이 세 가지 유형을 공용체 유형에서 함께 선언할 수 없습니다. 그렇게 하면 컴파일 타임에 치명적인 오류가 발생합니다.

분리 정규형(DNF) 유형

DNF(Disjunctive Normal Form)는 부울 표현식을 구성하는 표준화된 방법입니다. 그것은 접속사의 분리로 구성됩니다. 부울 용어 로 AND의 OR입니다 .

유형 선언에 DNF를 적용하면 파서가 처리할 수 있는 결합된 Union 및 Intersection 유형을 작성하는 표준 방법이 허용됩니다. PHP 8.2의 새로운 DNF 유형 기능은 적절하게 사용하면 간단하지만 강력합니다.

RFC는 다음 예를 제공합니다. 다음 인터페이스 및 클래스 정의가 이미 존재한다고 가정합니다.

 interface A {} interface B {} interface C extends A {} interface D {} class W implements A {} class X implements B {} class Y implements A, B {} class Z extends Y implements C {}

DNF 유형을 사용하면 다음과 같이 속성, 매개변수 및 반환 값에 대한 유형 선언을 수행할 수 있습니다.

 // Accepts an object that implements both A and B, // OR an object that implements D (A&B)|D // Accepts an object that implements C, // OR a child of X that also implements D, // OR null C|(X&D)|null // Accepts an object that implements all three of A, B, and D, // OR an int, // OR null. (A&B&D)|int|null

경우에 따라 속성이 DNF 형식이 아닐 수 있습니다. 그렇게 선언하면 구문 분석 오류가 발생합니다. 그러나 항상 다음과 같이 다시 작성할 수 있습니다.

 A&(B|D) // Can be rewritten as (A&B)|(A&D) A|(B&(D|W)|null) // Can be rewritten as A|(B&D)|(B&W)|null

DNF 유형의 각 세그먼트는 고유해야 합니다. 예를 들어, (A&B)|(B&A) 선언은 두 OR ed 세그먼트가 논리적으로 동일하므로 유효하지 않습니다.

이에 더해 다른 세그먼트의 엄격한 하위 집합인 세그먼트도 허용되지 않습니다. 상위 집합에 이미 하위 집합의 모든 인스턴스가 있으므로 DNF를 사용하는 것이 중복되기 때문입니다.

역추적에서 민감한 매개변수 수정

거의 모든 프로그래밍 언어와 마찬가지로 PHP는 코드 실행의 모든 ​​지점에서 호출 스택을 추적할 수 있습니다. 스택 추적을 사용하면 오류 및 성능 병목 현상을 수정하기 위해 코드를 쉽게 디버그할 수 있습니다. WordPress 사이트용으로 맞춤 설계된 성능 모니터링 도구인 Kinsta APM과 같은 도구의 중추를 형성합니다.

스택 추적을 수행해도 프로그램 실행이 중단되지 않습니다. 일반적으로 대부분의 스택 추적은 백그라운드에서 실행되며 나중에 필요한 경우 검사를 위해 자동으로 기록됩니다.

그러나 이러한 상세한 PHP 스택 추적 중 일부는 일반적으로 오류 로그 분석, 오류 추적 등을 위해 타사 서비스와 공유하는 경우 단점이 될 수 있습니다. 이러한 스택 추적에는 사용자 이름, 암호 및 환경 변수와 같은 민감한 정보가 포함될 수 있습니다. .

이 RFC 제안은 다음과 같은 예를 제공합니다.

하나의 일반적인 "공격자"는 데이터베이스 암호를 생성자 매개변수로 사용하고 순수한 생성자와 별도의 ->connect() 메서드를 사용하는 대신 생성자 내에서 즉시 데이터베이스에 연결을 시도하는 PDO입니다. 따라서 데이터베이스 연결이 실패하면 스택 추적에 데이터베이스 암호가 포함됩니다.

 PDOException: SQLSTATE[HY000] [2002] No such file or directory in /var/www/html/test.php:3 Stack trace: #0 /var/www/html/test.php(3): PDO->__construct('mysql:host=loca...', 'root', 'password') #1 {main}

PHP 8.2에서는 이러한 민감한 매개변수를 새로운 \SensitiveParameter 속성으로 표시할 수 있습니다. 민감한 것으로 표시된 매개변수는 역추적에 나열되지 않습니다. 따라서 타사 서비스와 걱정 없이 공유할 수 있습니다.

다음은 단일 민감한 매개변수가 있는 간단한 예입니다.

 <?php function example( $ham, #[\SensitiveParameter] $eggs, $butter ) { throw new \Exception('Error'); } example('ham', 'eggs', 'butter'); /* Fatal error: Uncaught Exception: Error in test.php:8 Stack trace: #0 test.php(11): test('ham', Object(SensitiveParameterValue), 'butter') #1 {main} thrown in test.php on line 8 */

역추적을 생성할 때 \SensitiveParameter 속성이 있는 매개변수는 \SensitiveParameterValue 개체로 대체되며 실제 값은 추적에 저장되지 않습니다. SensitiveParameterValue 객체는 어떤 이유로든 필요한 경우 실제 매개변수 값을 캡슐화합니다.

새로운 mysqli_execute_query 함수 및 mysqli::execute_query 메소드

매개변수화된 MySQLi 쿼리를 실행하기 위해 사용자 값을 위험하게 이스케이프하는 mysqli_query() 함수를 사용한 적이 있습니까?

PHP 8.2에서는 새로운 mysqli_execute_query($sql, $params) 함수와 mysqli::execute_query 메소드를 사용하여 매개변수화된 MySQLi 쿼리를 더 쉽게 실행할 수 있습니다.

본질적으로, 이 새로운 함수는 mysqli_prepare() , mysqli_execute() 및 mysqli_stmt_get_result() 함수의 조합입니다. 이를 통해 MySQLi 쿼리가 준비되고 바인딩되며(매개변수를 전달하는 경우) 함수 자체 내에서 실행됩니다. 쿼리가 성공적으로 실행되면 mysqli_result 객체를 반환합니다. 실패하면 false 를 반환합니다.

RFC 제안은 간단하면서도 강력한 예를 제공합니다.

 foreach ($db->execute_query('SELECT * FROM user WHERE name LIKE ? AND type_id IN (?, ?)', [$name, $type1, $type2]) as $row) { print_r($row); }

const 표현식에서 enum 속성 가져오기

이 RFC는 ->/?-> 연산자가 const 표현식의 enum 속성을 가져올 수 있도록 제안합니다.

이 새로운 기능의 주된 이유는 배열 키와 같은 일부 위치에서 enum 개체를 사용할 수 없기 때문입니다. 이 경우 enum 케이스를 사용하기 위해 해당 값을 반복해야 합니다.

enum enum 속성을 가져오는 것을 허용하면 이 절차를 단순화할 수 있습니다.

다음 코드가 이제 유효함을 의미합니다.

 const C = [self::B->value => self::B];

그리고 안전을 위해 이 RFC에는 nullsafe 연산자 ?-> 지원도 포함되어 있습니다.

특성에 상수 허용

PHP에는 Traits라는 코드를 재사용하는 방법이 포함되어 있습니다. 클래스 간 코드 재사용에 적합합니다.

현재 Traits는 메서드와 속성 정의만 허용하고 상수는 허용하지 않습니다. 즉, Trait 자체 내에서 Trait에서 기대하는 불변량을 정의할 수 없습니다. 이 제한을 해결하려면 구성 클래스에서 상수를 정의하거나 구성 클래스에서 구현하는 인터페이스를 정의해야 합니다.

이 RFC는 Traits에서 상수를 정의할 수 있도록 제안합니다. 이러한 상수는 클래스 상수를 정의하는 것처럼 정의할 수 있습니다. RFC에서 직접 가져온 이 예는 사용량 주변의 공기를 맑게 합니다.

 trait Foo { public const FLAG_1 = 1; protected const FLAG_2 = 2; private const FLAG_3 = 2; public function doFoo(int $flags): void { if ($flags & self::FLAG_1) { echo 'Got flag 1'; } if ($flags & self::FLAG_2) { echo 'Got flag 2'; } if ($flags & self::FLAG_3) { echo 'Got flag 3'; } } }

Trait 상수는 또한 Trait의 속성 및 메서드 정의와 마찬가지로 구성 클래스의 정의에 병합됩니다. 또한 Traits의 속성과 유사한 제한 사항이 있습니다. RFC에서 언급했듯이 이 제안은 비록 좋은 시작이지만 기능을 구체화하기 위해 추가 작업이 필요합니다.

PHP 8.2의 사용 중단

이제 PHP 8.2의 모든 지원 중단을 탐색할 수 있습니다. 이 목록은 새로운 기능만큼 크지 않습니다.

동적 속성 지원 중단(및 새로운 #[AllowDynamicProperties] 속성)

PHP 8.1까지는 PHP에서 선언되지 않은 클래스 속성을 동적으로 설정하고 검색할 수 있었습니다. 예를 들어:

 class Post { private int $pid; } $post = new Post(); $post->name = 'Kinsta';

여기서 Post 클래스는 name 속성을 선언하지 않습니다. 그러나 PHP는 동적 속성을 허용하기 때문에 클래스 선언 외부에서 설정할 수 있습니다. 그것이 가장 큰 – 그리고 아마도 유일한 – 장점입니다.

동적 속성을 사용하면 코드에서 예기치 않은 버그와 동작이 나타날 수 있습니다. 예를 들어, 클래스 외부에서 클래스 속성을 선언하는 동안 실수를 하면 특히 해당 클래스 내에서 오류를 디버깅할 때 이를 놓치기 쉽습니다.

PHP 8.2부터 동적 속성은 더 이상 사용되지 않습니다. 값을 선언되지 않은 클래스 속성으로 설정하면 속성이 처음 설정될 때 사용 중단 알림이 표시됩니다.

 class Foo {} $foo = new Foo; // Deprecated: Creation of dynamic property Foo::$bar is deprecated $foo->bar = 1; // No deprecation warning: Dynamic property already exists. $foo->bar = 2;

그러나 PHP 9.0부터 동일하게 설정하면 ErrorException 오류가 발생합니다.

코드가 동적 속성으로 가득 차 있고 PHP 코드가 많은 경우 PHP 8.2로 업그레이드한 후 이러한 사용 중단 알림을 중지하려면 PHP 8.2의 새로운 #[AllowDynamicProperties] 속성을 사용하여 동적 속성을 허용할 수 있습니다. 클래스에 대한 속성.

 #[AllowDynamicProperties] class Pets {} class Cats extends Pets {} // You'll get no deprecation warning $obj = new Pets; $obj->test = 1; // You'll get no deprecation warning for child classes $obj = new Cats; $obj->test = 1;

RFC에 따라 #[AllowDynamicProperties] 로 표시된 클래스와 해당 하위 클래스는 사용 중단 또는 제거 없이 동적 속성을 계속 사용할 수 있습니다.

또한 PHP 8.2에서 #[AllowDynamicProperties] 로 표시된 유일한 번들 클래스는 stdClass 입니다. 또한 __get() 또는 __set() PHP 매직 메서드를 통해 액세스하는 모든 속성은 동적 속성으로 간주되지 않으므로 사용 중단 알림이 표시되지 않습니다.

부분적으로 지원되는 콜러블 지원 중단

영향은 미미하지만 부분적으로 지원되는 호출 가능 항목을 더 이상 사용하지 않는 또 다른 PHP 8.2 변경 사항이 있습니다.

이러한 호출 가능 항목은 $callable() 을 통해 직접 상호 작용할 수 없기 때문에 부분적으로 지원된다고 합니다. call_user_func($callable) 함수를 통해서만 접근할 수 있습니다. 이러한 호출 가능 목록은 길지 않습니다.

 "self::method" "parent::method" "static::method" ["self", "method"] ["parent", "method"] ["static", "method"] ["Foo", "Bar::method"] [new Foo, "Bar::method"]

PHP 8.2부터 call_user_func() 또는 array_map() 함수를 통해 이러한 호출 가능을 호출하려는 모든 시도는 사용 중단 경고를 발생시킵니다.

원래 RFC는 이 지원 중단에 대한 확실한 근거를 제공합니다.

마지막 두 경우를 제외하고 이러한 모든 호출 가능 항목은 컨텍스트 종속적입니다. "self::method" 가 참조하는 메서드는 호출 또는 호출 가능성 검사가 수행되는 클래스에 따라 다릅니다. 실제로 이것은 [new Foo, "parent::method"] 형식으로 사용될 때 일반적으로 마지막 두 경우에도 적용됩니다.

콜러블의 컨텍스트 종속성을 줄이는 것이 이 RFC의 2차 목표입니다. 이 RFC 이후에 남아 있는 유일한 범위 종속성은 메서드 가시성입니다. "Foo::bar" 는 한 범위에서는 볼 수 있지만 다른 범위에서는 볼 수 없습니다. 콜러블이 미래에 공용 메소드로 제한된다면(프라이빗 메소드는 일급 콜러블을 사용하거나 Closure::fromCallable() 을 사용하여 범위 독립적으로 만들어야 함) 콜러블 유형은 잘 정의되고 다음을 수행할 수 있습니다. 속성 유형으로 사용할 수 있습니다. 그러나 가시성 처리에 대한 변경 사항은 이 RFC의 일부로 제안되지 않습니다 .

원래 RFC에 따라 is_callable() 함수와 callable 유형은 이러한 호출 가능을 예외로 계속 허용합니다. 그러나 PHP 9.0 이상에서 지원이 완전히 제거될 때까지만 가능합니다.

혼동을 피하기 위해 이 사용 중단 알림 범위가 새로운 RFC로 확장되었습니다. 이제 이러한 예외가 포함됩니다.

PHP가 잘 정의된 callable 유형을 갖는 방향으로 이동하는 것을 보는 것이 좋습니다.

#utf8_encode() 및 utf8_decode() 함수 사용 중단

PHP의 내장 함수 utf8_encode() 및 utf8_decode() 는 ISO-8859-1("라틴어 1")로 인코딩된 문자열을 UTF-8로 또는 UTF-8에서 변환합니다.

그러나 그 이름은 구현이 허용하는 것보다 더 일반적인 용도를 암시합니다. "Latin 1" 인코딩은 일반적으로 "Windows 코드 페이지 1252"와 같은 다른 인코딩과 혼동됩니다.

또한 이러한 함수가 문자열을 제대로 변환할 수 없는 경우 일반적으로 Mojibake가 표시됩니다. 오류 메시지가 없다는 것은 특히 읽을 수 있는 텍스트의 바다 내에서 오류 메시지를 발견하기 어렵다는 것을 의미합니다.

PHP 8.2는 #utf8_encode() 및 utf8_decode() 함수를 더 이상 사용하지 않습니다. 호출하면 다음과 같은 지원 중단 알림이 표시됩니다.

 Deprecated: Function utf8_encode() is deprecated Deprecated: Function utf8_decode() is deprecated

RFC는 대신 mbstring , iconv 및 intl 과 같은 PHP에서 지원하는 확장을 사용할 것을 제안합니다.

${} 문자열 보간 사용 중단

PHP는 여러 가지 방법으로 큰따옴표( " ) 및 heredoc( <<< )를 사용하여 문자열에 변수를 포함할 수 있습니다.

1. 직접 임베딩 변수 — “$foo”
2. 변수 외부에 중괄호 사용 — “{$foo}”
3. 달러 기호 뒤에 중괄호 포함 — “${foo}”
4. 변수 변수 — “${expr}” — (string) ${expr} 사용과 동일

처음 두 가지 방법에는 장단점이 있는 반면, 후자에는 복잡하고 상충되는 구문이 있습니다. PHP 8.2는 마지막 두 가지 문자열 보간 방법을 더 이상 사용하지 않습니다.

앞으로 이런 식으로 문자열을 보간하지 않도록 해야 합니다.

 "Hello, ${world}!"; Deprecated: Using ${} in strings is deprecated "Hello, ${(world)}!"; Deprecated: Using ${} (variable variables) in strings is deprecated

PHP 9.0부터 이러한 지원 중단이 업그레이드되어 예외 오류가 발생합니다.

Base64/QPrint/Uuencode/HTML 엔티티에 대한 mbstring 함수 사용 중단

PHP의 mbstring(다중 바이트 문자열) 함수는 유니코드, HTML 엔터티 및 기타 레거시 텍스트 인코딩 작업을 돕습니다.

그러나 Base64, Uuencode 및 QPrint는 텍스트 인코딩이 아니며 주로 레거시 이유로 인해 여전히 이러한 기능의 일부입니다. PHP에는 이러한 인코딩의 별도 구현도 포함되어 있습니다.

HTML 엔티티의 경우 PHP에는 htmlspecialchars() 및 htmlentities() 와 같은 내장 함수가 있어 이를 더 잘 처리합니다. 예를 들어, mbstring과 달리 이 함수는 < 도 변환합니다. > , 및 & 문자를 HTML 엔터티로 변환합니다.

또한 PHP는 HTML 인코딩 및 디코딩 기능이 있는 PHP 8.1과 마찬가지로 항상 내장 기능을 개선하고 있습니다.

따라서 모든 것을 염두에 두고 PHP 8.2는 다음 인코딩에 mbstring 사용을 더 이상 사용하지 않습니다(레이블은 대소문자를 구분하지 않음).

• 베이스64
• 유니코드
• HTML 엔터티
• html(HTML-ENTITIES의 별칭)
• 인용-인쇄 가능
• qprint(Quoted-Printable의 별칭)

PHP 8.2부터 위의 내용을 인코딩/디코딩하기 위해 mbstring을 사용하면 사용 중단 알림이 표시됩니다. PHP 9.0은 이러한 인코딩에 대한 mbstring 지원을 완전히 제거합니다.

PHP 8.2의 기타 사소한 변경 사항

마지막으로 제거된 기능을 포함하여 PHP 8.2의 사소한 변경 사항에 대해 논의할 수 있습니다.

mysqli에서 libmysql 지원 제거

현재 PHP는 mysqli 및 PDO_mysql 드라이버가 mysqlnd 및 libmysql 라이브러리에 대해 빌드할 수 있도록 허용합니다. 그러나 PHP 5.4 이후 기본 및 권장 드라이버는 mysqlnd 입니다.

이 두 드라이버에는 많은 장점과 단점이 있습니다. 그러나 그 중 하나에 대한 지원을 제거하는 것(이상적으로는 기본값이 아닌 libmysql 을 제거하는 것)은 PHP의 코드와 단위 테스트를 단순화할 것입니다.

이 호의를 논하기 위해 RFC는 mysqlnd 의 많은 장점을 나열합니다.

• PHP와 함께 번들로 제공됩니다.
• PHP 메모리 관리를 사용하여 메모리 사용량을 모니터링하고
  성능 향상
• 삶의 질 함수 제공(예: get_result() )
• PHP 기본 유형을 사용하여 숫자 값을 반환합니다.
• 그 기능은 외부 라이브러리에 의존하지 않습니다
• 선택적 플러그인 기능
• 비동기 쿼리 지원

RFC는 또한 다음을 포함하여 libmysql 의 몇 가지 장점을 나열합니다.

• 자동 재연결이 가능합니다( mysqlnd 는 쉽게 악용될 수 있기 때문에 이 기능을 의도적으로 지원하지 않습니다)
• LDAP 및 SASL 인증 모드( mysqlnd 도 곧 이 기능을 추가할 수 있음)

또한 RFC는 PHP 메모리 모델과의 비호환성, 테스트 실패, 메모리 누수, 버전 간 기능 차이 등 libmysql 의 많은 단점을 나열합니다.

이 모든 것을 염두에 두고 PHP 8.2는 libmysql 에 대한 mysqli 빌드 지원을 제거했습니다.

libmysql 에서만 사용할 수 있는 기능을 추가하려면 기능 요청으로 mysqlnd 에 명시적으로 추가해야 합니다. 또한 자동 재연결을 추가할 수 없습니다.

로케일 독립적인 대소문자 변환

PHP 8.0 이전에는 PHP의 로케일이 시스템 환경에서 상속되었습니다. 그러나 이것은 일부 극단적인 경우에 문제를 일으킬 수 있습니다.

Linux를 설치하는 동안 언어를 설정하면 내장 명령에 적절한 사용자 인터페이스 언어가 설정됩니다. 그러나 C 라이브러리의 문자열 처리 기능이 작동하는 방식도 예기치 않게 변경됩니다.

예를 들어, Linux를 설치할 때 "터키어" 또는 "카자흐어" 언어를 선택한 경우 대문자를 얻기 위해 toupper('i') 를 호출하면 점으로 구분된 대문자 I(U+0130, I )을 얻을 수 있습니다.

PHP 8.0은 사용자가 setlocale() 을 통해 명시적으로 변경하지 않는 한 기본 로케일을 "C"로 설정하여 이 이상 현상을 중지했습니다.

PHP 8.2는 대소문자 변환에서 로케일 민감도를 제거하여 한 단계 더 나아갑니다. 이 RFC는 주로 strtolower() , strtoupper() 및 관련 함수를 변경합니다. 영향을 받는 모든 기능의 목록은 RFC를 읽으십시오.

대안으로 지역화된 대소문자 변환을 사용하려면 mb_strtolower() 를 사용할 수 있습니다.

랜덤 확장 개선

PHP는 임의 기능을 정밀 검사할 계획입니다.

현재 PHP의 임의 기능은 Mersenne Twister 상태에 크게 의존합니다. 그러나 이 상태는 PHP의 전역 영역에 암시적으로 저장됩니다. 사용자가 액세스할 수 있는 방법이 없습니다. 초기 시드 단계와 의도된 사용 사이에 무작위화 기능을 추가하면 코드가 손상될 수 있습니다.

이러한 코드를 유지 관리하는 것은 코드에서 외부 패키지를 사용하는 경우 훨씬 더 복잡할 수 있습니다.

따라서 PHP의 현재 임의 기능은 임의 값을 일관되게 재현할 수 없습니다. TestU01의 Crush 및 BigCrush와 같은 균일한 난수 생성기의 경험적 통계 테스트에도 실패합니다. Mersenne Twister의 32비트 제한은 이를 더욱 악화시킵니다.

따라서 PHP의 내장 함수인 shuffle() , str_shuffle() , array_rand() 를 사용하는 것은 암호학적으로 안전한 난수가 필요한 경우 권장되지 않습니다. 이러한 경우 random_int() 또는 유사한 함수를 사용하여 새 함수를 구현해야 합니다.

그러나 투표가 시작된 후 이 RFC와 관련된 몇 가지 문제가 제기되었습니다. 이러한 차질로 인해 PHP 팀은 모든 문제를 각 문제에 대해 생성된 투표 옵션과 함께 별도의 RFC에 기록해야 했습니다. 그들은 합의에 도달한 후에만 더 나아가기로 결정할 것입니다.

PHP 8.2의 추가 RFC

PHP 8.2에는 많은 새로운 기능과 사소한 변경 사항도 포함되어 있습니다. 추가 리소스에 대한 링크와 함께 아래에서 언급하겠습니다.

1. 새로운 curl_upkeep 함수: PHP 8.2는 이 새로운 함수를 Curl 확장에 추가합니다. PHP Curl 확장이 사용하는 기본 C 라이브러리인 libcurl에서 curl_easy_upkeep() 함수를 호출합니다.
2. 새로운 ini_parse_quantity 함수: PHP INI 지시문은 승수 접미사가 있는 데이터 크기를 허용합니다. 예를 들어 25메가바이트를 25M 으로, 42기가바이트를 42G 로 쓸 수 있습니다. 이러한 접미사는 PHP INI 파일에서 일반적이지만 다른 곳에서는 일반적이지 않습니다. 이 새로운 함수는 PHP INI 값을 구문 분석하고 데이터 크기를 바이트 단위로 반환합니다.
3. 새로운 memory_reset_peak_usage 함수: 이 함수는 memory_get_peak_usage 함수에 의해 반환된 최대 메모리 사용량을 재설정합니다. 동일한 작업을 여러 번 실행하고 각 실행의 최대 메모리 사용량을 기록하려는 경우에 유용할 수 있습니다.
4. preg_* 함수에서 캡처 금지 수정자( /n ) 지원: 정규식에서 () 메타 문자는 캡처 그룹을 나타냅니다. 즉, 괄호 안의 표현식에 대한 모든 일치 항목이 반환됩니다. PHP 8.2는 이 동작을 중지하기 위해 no-capture modifier( /n )를 추가합니다.
5. iterator_*() 계열이 모든 이터러블을 허용하도록 설정: 현재 PHP의 iterator_*() 계열은 \Traversables 만 허용합니다(즉, 일반 배열은 허용되지 않음). 불필요하게 제한적이며 이 RFC가 이를 수정합니다.

요약

PHP 8.2는 PHP 8.0 및 PHP 8.1의 대대적인 개선을 기반으로 하며 이는 결코 쉬운 일이 아닙니다. 가장 흥미로운 PHP 8.2 기능은 새로운 독립형 유형, 읽기 전용 속성 및 수많은 성능 향상이라고 생각합니다.

다양한 PHP 프레임워크와 CMS로 PHP 8.2를 벤치마킹할 수 있기를 기대합니다.

나중에 참조할 수 있도록 이 블로그 게시물을 북마크에 추가하세요.

어떤 PHP 8.2 기능이 가장 마음에 드십니까? 가장 선호하지 않는 지원 중단은 무엇입니까? 댓글로 여러분의 생각을 커뮤니티와 공유해주세요!