유니 코드 코딩 이론과 문제

역사
1963 년은, 컴퓨터 사용이 아직 널리 퍼져 있지 않은 경우, 문자 인코딩으로 0 ~ 127의 범위에서, 7 비트 ASCII 코드를 사용, 캐릭터의 작은 부분 만 지원하지만, 컴퓨터의 인기와 함께, 다른 국가는 상호 호환되지 않는, 문제가 될지도하는, 자신의 코딩 표준을 생산하기 시작했다.
이 문제를 해결하기 위해, ISO는 코딩 UCS의 문자와 기호의 대부분은 유니 코드 인코딩을 포함을 개발하기 위해 노력하기 시작했다.

유니 부호화
유니 실제로 문자 및 숫자가 아닌 실제 코딩 방식이므로 UTF-8, UTF-16을 포함하는 UTF 표준의 개발 간의 매핑 테이블등, 유니 코드는 디자인 이론의 실현을위한 UTF.

코드 포인트와 단위 코드
코드 포인트가 표준에서 유니 코드 문자의 수를 현재의 문자로 표시되는 0 ~ 0x10FFFF 유니 코드 인코딩 범위, U + XXXX를 사용합니다.
코드 유닛은 포인트 코드 필요한 바이트 유니 최소 인코딩되어, UTF-8, 적어도 1 바이트, UTF-16, UCS-2는 적어도 2 바이트를 필요 UCS -4- 필요 UTF-32은 네 개의 단어 인 섹션 3, 고정 길이 부호화 후술.

문제
는 다양한 문제를 일으킬 가능성이 코딩의 다수가 포함되어 있기 때문에 :
시각적 속임수
일부 문자가 매우 유사, 비주얼 등 аррӏе.com 등의 문제, (U + 04CF에 ӏ) 및 apple.com에 이르게 도메인 코딩 퓨니 코드 CHROM을 사용하여이 문제를 해결하기 위해, 도메인 인코딩되면을 xn-- 시작으로 예시 аррӏе.com 들어 CHROM 시각적 속이는 경우를 검출 할 수 있고, 그것은 (xn--80ak6aa92e.com로 부호화 잘 알려진 사이트로의 변환은 파이어 폭스,) 시각기만하고이 기능이 없습니다. (파이썬 라이브러리는 IDNA이 기능을 구현하는 라이브러리입니다)
그러나, 또한 시각적기만 예 퓨니 :䕮䕵䕶䕱.COM xn--google.com로서 부호화

양방향 디스플레이
인해 아랍 및 히브리어는 오른쪽에서 왼쪽으로 판독되는 등 txt.exe 유니 코드 제어 문자를 추가 한 후 문제가있을 수있다 exe.txt된다

디지털 디스플레이
벵골 0-9 ২ 0 1 2 3 4 5 6 7 8 9 4 (U + 09EA) 실제로 4

당량의
일부 등가 처리 WAF 클래스 고지 문자를 의미하고, 여과, 예를 들어 로컬 호스트 당량 로컬 호스트하지만 이외에 ⓛocaⓛhost도 상당이 간과하기 쉬운

문자 삭제
\ x3c \ X73 \ X63 \ X72에 \ XC2 \ X69 \ X70 \ x74 \ X3E을 문자열은 \의 XC2 유효한 문자열은 제목으로 이어질 수 과정에서 일부 로직, 제거 할 수 있습니다

문자 대체
어떤 경우에는, U + FFFF이 문제가 발생할 수있는?로 대체됩니다,

버퍼 오버 플로우
소문자 변환을 수행 할 때, 변환 전의 상기 케이스의 길이가, 그 오버 플로우가 존재 버퍼링 가능한지 'ß'.toUpperCase ()을 확인하는 SS가된다 예를 들어, 다중 문자가있다.