한국어
한국어
PHP에서 멀티 바이트 스트링을 다룰 때, 우리는 종종 더 나은 유니 코드 호환성을 위해 MBString 확장에 의존합니다. 특히, MB_EREG_REPLACE 및 MB_EREGI_REPLACE는 다중 바이트 친화적 인 일반 교체 기능이라고 주장합니다. 많은 개발자들은 PCRE와 같은 \ p {han}과 같은 유니 코드 속성을 인식 할 수 있다고 잘못 생각하여 한자의 정확한 일치를 달성합니다.
불행히도이 아이디어는 잘못되었습니다.
우선, MB_EREG_REPLACE 및 MB_EREG_REPLACE는 Oniguruma를 기반으로 일반 엔진을 사용하지만 사용하는 구문 패턴은 PCRE (Perl-Compative Regular Expressions)이지만 구형 제한된 기능 Posix 변형입니다. Oniguruma 자체가 유니 코드 속성 일치를 지원하지만, 전제는 적절한 모드를 활성화해야한다는 것입니다 (예 : Preg_match는 PHP 7.3+에서 \ p {han}을 지원합니다).
일반적인 오해 코드 예를 살펴 보겠습니다.
$text = '이것은 test 콘텐츠 123';
$result = mb_eregi_replace('\p{Han}+', '', $text);
echo $result;
이 대본은 한자를 제거하고 영어와 숫자를 보존 할 것이라고 생각하십니까? 사실, 그렇지 않습니다. MB_EREGI_REPLACE \ P는 정상적인 백 슬래시 및 문자 P 로 취급하며 {han}은 전혀 특별한 의미로 인식되지 않습니다. 이로 인해 Regex는 전혀 유효하지 않으며 중국어와 일치하지 않습니다.
유니 코드 속성에 대한 지원을 구현하려면이를 수행하는 올바른 방법은 preg_replace를 사용하고 U 수정자를 추가하여 PHP가 유니 코드 모드를 사용하여 문자열을 해석 할 수 있도록하는 것입니다.
올바른 예를 보자 :
$text = '이것은 test 콘텐츠 123';
$result = preg_replace('/\p{Han}+/u', '', $text);
echo $result;
산출:
test 123
이것이 우리가 정말로 원하는 효과입니다.
많은 개발자들이 MB_EREGI_REPLACE 에 "다중 바이트 지원"을 가지고 있다는 설명을 볼 때, 자연스럽게 유니 코드 속성, 특히 중국 커뮤니티의 많은 오래된 튜토리얼이나 기사가 명확히하지 않았다고 생각합니다. 예를 들어, mb_eregi_replace \ p {han} 을 검색하면 모호하거나 오래된 설명을 찾을 수 있으며, 이는 사람들이 실수로 "실행 가능하다"고 잘못 생각하게 할 수 있습니다.
또한, 프로젝트가 MB_EREGI_REPLACE를 사용하여 규칙 성을 처리하는 데 사용되는 경우 중국어 또는 기타 유니 코드 문자 세트를 다룰 때 갇히게 될 가능성이 높으므로, 특히 텍스트 청소 및 데이터 추출과 같은 작업에서 불완전한 데이터 필터링 또는 논리 오류가 불완전하게됩니다.
솔직히 말해서, 당신은 그것을 사용하지 않는 것이 좋습니다. 그러나 호환성 요구에 사용해야하는 경우 중국어를 인코딩하는 유니 코드 범위를 사용하는 것을 고려할 수 있습니다.
$text = '이것은 test 콘텐츠 123';
$result = mb_eregi_replace('[하나-장미]+', '', $text);
echo $result;
이 접근법은 충분히 정확하지는 않지만 (예를 들어, 모든 중국어 확장과 일치 할 수는 없음) \ p {han}을 사용하는 것보다 적어도 훨씬 더 신뢰할 수 있습니다. 더 나아가서, 정확도를 향상시키기 위해 여러 중국어 간격을 수동으로 나열 할 수 있지만 궁극적으로는 증상을 치료하지만 근본 원인은 아닙니다.
더 나은 접근 방식은 preg_replace 로 완전히 전환하고 mbstring.func_overload 또는 적절한 멀티 바이트 지원 정책이 활성화되어 PCRE의 전력을 극대화하는 것입니다.
mb_eregi_replace ( '\ p {han}', ...)를 오용하지 마십시오. 더 이상 \ p {} 의 구문을 전혀 인식하지 못합니다. 유니 코드 속성을 처리 해야하는 경우 신뢰할 수있는 유일한 옵션은 u 수정 자와 함께 preg_replace 입니다. 이러한 오해는 수년 동안 많은 PHP 개발자들에게 어려움을 겪었으며 이제 소스를 수정해야 할 때입니다.
