정규화 유니 코드는 PHP

에서 W3C에 따라 나는 다음과 같은 경고 가지고 :정규화 유니 코드는 PHP

Line 157, Column 220: Text run is not in Unicode Normalization Form C. 

…i͈̭̋ͥ̂̿̄̋̆ͣv̜̺̋̽͛̉͐̀͌̚e͖̼̱ͣ̓ͫ͆̍̄̍͘-̩̬̰̮̯͇̯͆̌ͨ́͌ṁ̸͖̹͎̱̙̱͟͡i̷̡͌͂͏̘̭̥̯̟n̏͐͌̑̄̃͘͞…

내가 PHP의 5.3.x에서을 개발하고 있어요를, 그래서 Normalizer을 사용할 수 있습니다 수업.

이 문제를 해결하려면 사용자가 입력 한 내용 (예 : 댓글)을 표시 할 때 Normalizer::normalize($output)을 사용해야합니까, 아니면 데이터베이스에 저장하기 전에 모든 사용자 입력에 Normalizer::normalize($input)을 사용해야합니까?

tl; dr : 사용자 입력을 데이터베이스에 저장하기 전에 또는 표시 할 때 Unicode normalization을 사용해야합니까?

출처

2012-01-07 federicot

페이지에 어떤 데이터가 표시됩니까? 이는 데이터가 아닌 유효성 검사기의 문제와 유사합니다. – powtac

사용자가 합법적으로 게시 할 수있는 [this] (http://eeemo.net/)과 같은 것입니다. 그것은 굉장히 많이 보이는 윗 첨자와 아래 첨자가 많은 텍스트의 모음입니다. – federicot

흥미 롭다 : 나는 validator가 그런 종류의 chars 조합을 깨뜨렸다 고 확신한다 ... 그러나 나는 또한이 스레드를 찾았다. http://comments.gmane.org/gmane.org.w3c.validator/13243 – powtac

응용 프로그램의 목적과 특성에 따라 사용자 입력을 읽거나 데이터베이스에 저장하거나 기록 할 때 표준화를 적용할지 여부는 사용자가 결정해야합니다. 주관적인 규칙을 적용, http://validator.w3.org/feedback.html

경고 메시지가 정말 린터 인 실험 "HTML5 확인"(에서 유래에서 공식 목록 아카이브 형태로도 주문 가능합니다 질문에 대한 코멘트에 언급 긴 스레드를 요약하면 일부 공식 테스트에 추가).
메시지는 HTML5 초안의 요구 사항을 기반으로하지는 않지만 일부 소프트웨어에서 문제를 일으킬 수있는 것에 대한 의견을 기반으로합니다.
원래 "HTML5 유효성 검사"로 작성된 의견은 오류 메시지 인 지금 경고를 표시합니다.

비정규 화 된 데이터를 사용자 입력으로받을 수도 있습니다. 이것은 브라우저에 의해 수행되는 정규화에 의존하지 않습니다 (그들은 미래에 있을지도 모르지만 그러한 일을하지는 않습니다). 그러나 입력 방법과 습관에 의존합니다. 예를 들어, ü (움라우트 또는 분음 기호를 사용하는 문자)를 입력하는 방법은 정규화 된대로 미리 작성된 형식으로 문자를 생성하는 경향이 있습니다. 사람 은 분해되지 않은 형태로 문자 u를 출력하고 분음 기호를 결합하여 생성 할 수 있지만 대개 그렇게 할 이유가 없으며 대부분의 사람들은이를 수행하는 방법조차 모를 것입니다.

소프트웨어에서 문자열 비교를 수행하는 경우 사용되는 비교 루틴에 따라 다르거 나 그렇지 않을 수 있습니다. 분해 된 프리젠 테이션과 동등한 사전 구성 ü. 간단한 구현은 단순 문자 레벨 (유니 코드 코드 포인트)에서 분명히 다르므로 다른 문자로 처리합니다.

늦어도 쓰기 단계에서 어느 시점에서 정상화해야하는 한 가지 이유는 사전 합성 된 문자가 일반적으로 더 안정적으로 표시된다는 것입니다. 정규화 된을 표시하려면 프로그램에서 글꼴의 글리프를 선택하면됩니다. 분해 된 ü를 제시하려면, 프로그램은 그것을 정규화 된 ü과 정오식으로 인식해야하거나 그 위에 적절히 배치 된 분음 기호를 사용하여 문자 u를 작성해야하며, 문자 모양의 그래픽 속성에주의를 기울여 많은 프로그램이 실패합니다 이걸로.

한편, 비정규 화 된 데이터가 사용자 입력으로 수신되는 드문 경우에서 사용자는이를 생성 한 이유가있을 수 있습니다. 그는 정규화 된 ü와 비정규 화 된 ü가 구별되고 그와 같이 취급 될 필요가 있다는 생각을 가질 수 있습니다.

출처

2012-01-07 09:15:43

정말 자세히 대답하고 생각했습니다. 그러나, 나는 마지막 단락에 동의하지 않습니다 ... 문자 u를 입력하는 두 가지 방법 (움라우트 또는 분음 기호를 사용하는 경우)은 인간과 눈에 띄는 차이가없는 똑같은 성격을 갖게됩니다. 그들을 다른 것들로 대우하니? 나는 아마 여기 틀릴 것이지만 이것이 정규화 **를 사용해야하는 완벽한 예가 아니겠습니까? – federicot

텍스트는 동등한 것으로 간주되어야합니다. 옥텟으로 취급하는 연산이 있다면, 그렇게 할 수 없습니다. 디지털 서명이있는 경우를 예로들 수 있습니다. 정규화하면 더 이상 서명되지 않은 것으로 변경됩니다. 이것이 XML 서명에 실제 서명의 일부로 정규화 단계가 있기 때문에 서명 된 NFC 일뿐입니다. HTML로 출력 할 때 그것은 텍스트로 출력 될 것이고 이것은 무의미한 것이므로 여전히 NFC이어야합니다. 그러나 양식을 유지할 이유가있을 수도 있습니다. –

@ John Doe와 같은 문자는 아니지만 문자와 두 문자로 구성된 시퀀스가됩니다. 표준 정점은 신원이 아니며 프로그램은 수 있습니다. 별다른 문자는 없지만 * 프로그램이 그렇게 할 것을 기대해서는 안됩니다. 정준 적 등가성은 내가 언급 한 렌더링 메커니즘으로 인해 시각적 정체성을 암시하지도 않습니다 (예 : 글리프를 직접 사용하지만 "u"글리프를 사용하여 분해 된 ü을 표시하고 그 위에 "¨" 다른 글꼴에서 구두점!). –

엄밀히 말하면 웹 캐릭터 모델의 규칙은 NFC로 정상화해야하는 것이 아니라 다른 메커니즘의 텍스트가 포함 된 기술 이전의 양식과 NFC가 모두 실행 된 양식이 모두 NFC에 있어야합니다. 예는 XML 포함, 문자 참조 및 엔티티 참조입니다.예를 들어 ä은 캐릭터 모델에 맞지 않습니다. NFC를 확장하면 문자 참조가 a으로 바뀌고 NFC가 아닌 결합 지어 있습니다. 이것을 피하는 것은 실제로는 쉽지만, 주목할 가치가 있습니다.

흥미로운 사례가 U + 0338입니다. >에 이어 U + 0338이 ≯으로 그리고 <으로 정상화되어 ≮을 생성한다. 엘리먼트 이름의 시작이나 엘리먼트 내의 첫 번째 문자로 허용해서는 안되는 이유는 분명해야한다.

일반적으로 어떤 경우에도 텍스트를 결합 문자로 시작하는 것은 의미가 없지만,이 특정 예에서는 전체 문서가 맹 글링되도록 허용합니다 (정규화하지 않더라도 그렇지 않을 수도 있습니다).

텍스트 퀘스트 텍스트 (예 : 디지털 서명에 아무런 관심이 없음)에만 관심이있는 경우 입력시 정규화하면 텍스트의 내부 사용 (예 : 검색) 그래서 갈 길입니다.

자세한 내용은 http://www.w3.org/TR/charmod-norm/을 참조하십시오.

출처

2012-01-12 09:10:55

답변

관련 문제