유니 코드와 ASCII의 정확한 차이점은 무엇입니까?
ASCII는 총 128 자입니다 (확장 세트에서 256 자).
유니 코드 문자에 대한 크기 지정이 있습니까?
답변:
ASCII는 숫자 0–127에 매핑되는 128자를 정의합니다. 유니 코드를 정의 2 개 (이하) (21) , 유사, 숫자 0-2에 매핑 문자 (21)는 (비록 모든 숫자가 현재 할당하지, 일부는 예약되어 있습니다).
유니 코드는 ASCII의 상위 집합이며 0-127의 숫자는 ASCII의 유니 코드와 동일한 의미를 갖습니다. 예를 들어 숫자 65는 "라틴 대문자 'A'"를 의미합니다.
유니 코드 문자는 일반적으로 하나의 8 비트 바이트에 맞지 않기 때문에 UTF-32 및 UTF-8과 같은 유니 코드 문자를 바이트 순서로 저장하는 방법에는 여러 가지가 있습니다.
이해 왜 ASCII 및 유니 코드가 처음에 만들어진 날 둘 사이의 차이점을 이해하는 데 도움.
ASCII, 원점
다른 답변에서 언급했듯이 ASCII는 7 비트를 사용하여 문자를 나타냅니다. 7 비트를 사용하면 최대 2 ^ 7 (= 128) 개의 고유 한 조합 *을 가질 수 있습니다 . 즉, 최대 128자를 나타낼 수 있습니다.
잠깐, 7 비트? 그러나 왜 1 바이트 (8 비트)가 아닌가?
마지막 비트 (8 번째)는 패리티 비트로 오류를 피하기 위해 사용됩니다 . 이것은 몇 년 전과 관련이 있습니다.
대부분의 ASCII 문자는 abc, ABC, 123,? &! 등과 같은 알파벳의 인쇄 가능한 문자입니다. 다른 문자 는 캐리지 리턴, 줄 바꿈 , 탭 등과 같은 제어 문자입니다 .
ASCII에서 몇 문자의 이진 표현을 아래에서 참조하십시오.
0100101 -> % (Percent Sign - 37)
1000001 -> A (Capital letter A - 65)
1000010 -> B (Capital letter B - 66)
1000011 -> C (Capital letter C - 67)
0001101 -> Carriage Return (13)
ASCII는 영어로만 사용되었습니다.
뭐? 왜 영어 만? 너무 많은 언어가 있습니다!
당시 컴퓨터 산업의 중심은 미국에 있었기 때문입니다. 결과적으로 악센트 또는 á, ü, ç, ñ 등과 같은 다른 표시 ( 분음 부호 ) 를 지원할 필요가 없었습니다 .
ASCII 확장
일부 영리한 사람들은 8 번째 비트 (패리티에 사용되는 비트)를 사용하여 언어를 지원하기 위해 더 많은 문자를 인코딩하기 시작했습니다 (예 : 프랑스어로 "é"지원). 하나의 추가 비트를 사용하면 원래 ASCII 테이블 크기의 두 배가되어 최대 256 자 (2 ^ 8 = 256 자)로 매핑됩니다. 그리고 이전과 같이 2 ^ 7이 아닙니다 (128).
10000010 -> é (e with acute accent - 130)
10100000 -> á (a with acute accent - 160)
이 "ASCII는 이전과 같이 7 비트가 아닌 8 비트로 확장되었습니다"라는 이름을 "확장 ASCII"또는 "8 비트 ASCII"라고합니다.
따라 @ 톰은 그의 주석에서 지적한 "같은 것은 없다 아래에 확장 된 ASCII는 "아직이 8 비트 트릭을 참조 할 수있는 쉬운 방법입니다. 8 비트 ASCII 테이블에는 여러 가지 변형이 있습니다 (예 : ISO Latin-1이라고도 하는 ISO 8859-1) .
유니 코드, 더 라이즈
ASCII Extended는 라틴 알파벳을 기반으로하는 언어의 문제를 해결합니다. 완전히 다른 알파벳이 필요한 다른 사람들은 어떻습니까? 그리스 어? 러시아인? 중국인과 좋아요?
우리는 완전히 새로운 문자 세트를 필요로했을 것입니다. 그것은 유니 코드의 합리적입니다. 유니 코드는 모든 언어의 모든 문자를 포함하지는 않지만 엄청난 양의 문자 ( 이 표 참조 ).
텍스트를 "유니 코드"로 하드 드라이브에 저장할 수 없습니다. 유니 코드는 텍스트의 추상 표현입니다. 이 추상 표현을 "인코딩"해야합니다. 그것이 인코딩 이 시작 되는 곳 입니다.
인코딩 : UTF-8 vs UTF-16 vs UTF-32
이 답변 은 기본 사항을 설명하는 데 매우 효과적입니다.
UTF-8은 처음 128 자에 ASCII 세트를 사용합니다. ASCII 텍스트가 UTF-8에서도 유효하다는 것을 의미하기 때문에 편리합니다.
기억술:
노트 :
왜 2 ^ 7입니까?
이것은 일부에게는 명백하지만, 경우에 따라서 만 가능합니다. 0 또는 1 ( 이진 코드 )로 채워진 7 개의 슬롯이 있습니다 . 각각 두 가지 조합을 가질 수 있습니다. 7 개의 스팟이 있다면 2 * 2 * 2 * 2 * 2 * 2 * 2 = 2 ^ 7 = 128 조합입니다. 이것을 7 개의 바퀴가있는 콤비네이션 자물쇠라고 생각하십시오. 각 바퀴에는 2 개의 숫자 만 있습니다.
출처 : Wikipedia , 이 위대한 블로그 게시물 및 Mocki 는 처음 에이 요약을 게시했습니다.
ASCII는 0에서 127까지 128 개의 코드 포인트를 갖습니다. 단일 8 비트 바이트에 맞을 수 있으며 128에서 255 사이의 값은 다른 문자에 사용됩니다. 선택 사항이 호환되지 않아 코드 페이지가 손상되었습니다 . 한 코드 페이지에서 인코딩 된 텍스트는 다른 코드 페이지에서 가정하거나 추측하는 프로그램에서 올바르게 읽을 수 없습니다.
이 재난을 해결하기 위해 유니 코드가 등장했습니다. 버전 1은 일반적으로 16 비트로 인코딩 된 65536 코드 포인트로 시작되었습니다. 나중에 버전 2에서 110 만 코드 포인트로 확장되었습니다. 현재 버전은 6.3이며 사용 가능한 110 만 코드 포인트 중 110,187 개를 사용합니다. 더 이상 16 비트에 맞지 않습니다.
16 비트 인코딩은 v2가 등장 할 때 일반적이며 Microsoft 및 Apple 운영 체제에서 사용되었습니다. Java와 같은 언어 런타임. v2 사양은 110 만 코드 포인트를 16 비트로 매핑하는 방법을 제시했습니다. 하나의 코드 포인트가 2 또는 4 바이트를 취할 수있는 가변 길이 인코딩 UTF-16이라는 인코딩. 원래 v1 코드 포인트는 2 바이트가 걸리고 추가 된 코드 포인트는 4가 걸립니다.
* nix 운영 체제 및 도구에서 사용되는 매우 일반적인 또 다른 가변 길이 인코딩은 UTF-8이며, 코드 포인트는 1-4 바이트이며, 원래 ASCII 코드는 1 바이트이며 나머지는 더 많은 시간이 걸립니다. 가변 길이가 아닌 유일한 인코딩은 UTF-32이며 코드 포인트에는 4 바이트가 필요합니다. 그것은 꽤 낭비이기 때문에 자주 사용되지 않습니다. UTF-1 및 UTF-7과 같은 다른 것들이 널리 무시됩니다.
UTF-16 / 32 인코딩의 문제점은 바이트 순서가 텍스트 스트림을 작성한 시스템의 엔디안 (endian-ness)에 따라 달라진다는 것입니다. 따라서 UTF-16BE, UTF-16LE, UTF-32BE 및 UTF-32LE 혼합에 추가하십시오.
이처럼 다양한 인코딩을 선택하면 UTF 페이지 선택이 "최고"인 프로그래머들 사이의 열띤 논쟁과 함께 코드 페이지 재난이 어느 정도 다시 발생합니다. 운영 체제 기본값과의 연관성은 거의 선을 그립니다. 한 가지 대책은 텍스트 스트림의 시작 부분에 나머지 스트림이 인코딩되는 방법을 나타내는 BOM, 바이트 순서 마크, 특수 코드 포인트 (U + FEFF, 폭이 0 인 공간)의 정의입니다. UTF 인코딩과 엔디안을 모두 나타내며 텍스트 렌더링 엔진에 중립적입니다. 불행히도 그것은 선택 사항이며 많은 프로그래머는 그것을 생략 할 권리를 주장하므로 사고는 여전히 흔합니다.
java는 유니 코드를 지원합니다. 즉, 전세계 모든 알파벳을 지원합니다. 따라서 Java에서 char의 크기는 2 바이트입니다. 범위는 0 ~ 65535입니다.
ASCII에는 128 개의 코드 위치가 있으며 그래픽 문자 및 제어 문자 (제어 코드)에 할당됩니다.
유니 코드에는 1,114,112 개의 코드 위치가 있습니다. 이들 중 약 10 만 개가 현재 문자에 할당되었으며 많은 코드 포인트가 영구적으로 문자가 아닌 문자로 만들어졌으며 (즉, 문자를 인코딩하는 데 사용되지 않음) 대부분의 코드 포인트가 아직 할당되지 않았습니다.
ASCII와 유니 코드가 공통적 으로 갖는 유일한 것은 다음과 같습니다. 1) 문자 코드입니다. 2) 유니 코드의 첫 번째 128 코드 위치는 ASCII 제어 문자의 코드 위치가 ASCII 문자에 해당하는 이름으로 제어 문자를 나타내는 것으로 정의되지만 그 의미는 ASCII와 동일한 의미를 갖도록 정의되었습니다. 유니 코드로 정의되지 않았습니다.
그러나 때때로 유니 코드는 (유니 코드 표준에서도)“와이드 ASCII”로 특성화됩니다. 이것은 다른 코드를 사용하는 것과는 달리 유니 코드가 ASCII와 같은 방식으로 유니 코드가 ASCII와 같은 방식으로 유니버설 문자 코드 라는 의미를 주로 전달하는 슬로건입니다 . 다른 시스템 및 응용 프로그램 및 다른 언어.
유니 코드는 문자의 "논리적 크기"만 정의합니다. 각 문자는 특정 범위의 코드 번호를 갖습니다. 이러한 코드 번호는 다른 전송 인코딩을 사용하여 표시 할 수 있으며 내부적으로 메모리에서 유니 코드 문자는 일반적으로 문자 범위에 따라 문자 당 하나 또는 두 개의 16 비트 수량을 사용하여 표현되며 때로는 문자 당 하나의 32 비트 수량을 사용합니다.
ASCII 및 유니 코드는 두 문자 인코딩입니다. 기본적으로 이진 문자로 차이 문자를 표현하여 디지털 미디어에서 쓰고 저장하고 전송하고 읽을 수있는 방법에 대한 표준입니다. 이 둘의 주요 차이점은 문자를 인코딩하는 방식과 각각에 사용하는 비트 수입니다. ASCII는 원래 각 문자를 인코딩하기 위해 7 비트를 사용했습니다. 나중에 확장 ASCII를 사용하여 원본의 외관상 부적합한 문제를 해결하기 위해 8로 늘 렸습니다. 반대로 유니 코드는 32, 16 및 8 비트 인코딩 중에서 선택할 수있는 가변 비트 인코딩 프로그램을 사용합니다. 더 많은 비트를 사용하면 더 큰 파일을 사용하여 더 많은 문자를 사용할 수 있지만 더 적은 비트는 제한된 선택을 제공하지만 많은 공간을 절약합니다. 더 적은 비트 사용
유니 코드가 문제가 된 주요 이유 중 하나는 많은 비표준 확장 ASCII 프로그램에서 발생했습니다. Microsoft 및 대부분의 다른 소프트웨어 회사에서 사용하는 기본 페이지를 사용하지 않으면 상자로 나타나는 문자에 문제가 발생할 수 있습니다. 모든 문자 코드 포인트가 표준화되었으므로 유니 코드는 사실상이 문제를 해결합니다.
유니 코드의 또 다른 주요 장점은 최대한 많은 문자를 수용 할 수 있다는 것입니다. 이 때문에 유니 코드에는 현재 가장 많은 언어가 포함되어 있으며 여전히 더 많은 언어를 사용할 수 있습니다. 여기에는 영어와 같은 일반적인 왼쪽에서 오른쪽 스크립트와 아랍어와 같은 오른쪽에서 왼쪽 스크립트가 포함됩니다. 중국어, 일본어 및 기타 여러 변형도 유니 코드로 표시됩니다. 따라서 유니 코드는 곧 교체되지 않습니다.
당시에 널리 사용되었던 이전 ASCII와의 호환성을 유지하기 위해 유니 코드는 처음 8 비트가 가장 널리 사용되는 ASCII 페이지와 일치하도록 설계되었습니다. 따라서 유니 코드로 ASCII 인코딩 파일을 열면 파일에 올바른 문자가 인코딩됩니다. 이는 이미 ASCII를 사용하고있는 사람들을 위해 새로운 인코딩 표준을 채택 할 때의 영향을 줄임으로써 유니 코드 채택을 촉진했습니다.
요약:
1.ASCII uses an 8-bit encoding while Unicode uses a variable bit encoding.
2.Unicode is standardized while ASCII isn’t.
3.Unicode represents most written languages in the world while ASCII does not.
4.ASCII has its equivalent within Unicode.
출처 : http://www.differencebetween.net/technology/software-technology/difference-between-unicode-and-ascii/#ixzz4zEjnxPhs
주어진 숫자는 1자를 저장하기위한 것입니다
UTF가 ASCII의 상위 집합 인 방법 외에도 ASCII와 UTF 사이에서 알아야 할 또 다른 좋은 차이점은 디스크 파일 인코딩, 데이터 표현 및 임의 메모리의 저장과 관련이 있습니다. 프로그램은 주어진 데이터가 데이터 시작시 특수 바이트 순서 마크 코드를 감지하거나 프로그래머가 데이터를 텍스트라고 가정하고 데이터가 텍스트임을 나타내는 패턴을 확인함으로써 ASCII 또는 UTF 문자열로 이해되어야 함을 알고 있습니다. 하나의 텍스트 인코딩 또는 다른 텍스트.
0x16 진 데이터 에 대한 일반적인 접두사 표기법을 사용하면 기본적으로 ASCII 텍스트는 바이트 값 0x00으로 시작 0x7F하여 가능한 ASCII 문자 값 중 하나 를 나타내는 것입니다 . UTF 텍스트는 일반적으로 0xEF 0xBB 0xBFUTF8 의 바이트로 시작하여 표시됩니다 . UTF16의 경우, 시작 바이트 순서로 표시되는 텍스트 바이트의 엔디안 순서와 함께 시작 바이트 0xFE 0xFF또는 0xFF 0xFE사용됩니다. 가능한 바이트 값의 ASCII 범위에없는 바이트 값의 단순한 존재는 데이터가 아마도 UTF임을 나타냅니다.
데이터를 특정 인코딩 표준에서 인코딩 된 텍스트로 해석해야 함을 나타 내기 위해 다른 코드를 사용하는 다른 바이트 순서 표시 가 있습니다.