Java codePointAt(int index)

프로젝트 내 src 내 javabasic 패키지 내 Han.java

package javabasic;

public class Han {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		String han = "ㄱ";
		// 한글 문자 기역
		// 유니코드 번호: U+3131
		// 유니코드 앞에 U+ 를 떼고
		// 대신 0x 를 붙이면 16진수가 된다.
		// 그래서 유니코드 번호 U+3131 은 십육진수로 0x3131
		// 이고 0x3131 을 10진수로 변환하면
		// 12593 이다.
		// HTML 코드: ㄱ
		// CSS 코드: \3131

		int ret = han.codePointAt(0);
		System.out.println(ret);

		han = "가";
		ret = han.codePointAt(0);
		// 한글 음절 가(Hangul Syllable Ga)
		// 유니코드 번호: U+AC00
		// HTML 코드: 가
		// CSS 코드: \AC00
		// 16진수로 0xAC00
		// 10진수로 44032
		ret = ret + 588;
		// 44032 + 588 = 44620
		System.out.println(ret);
	}

}
// 유니코드를 실제 환경에서 사용하려면 프로그래밍 언어와 운영체제 환경이 유니코드를 어떻게 지원
// 하는지 알고 있어야 한다고 한다.

// 인코딩 문제가 있거나
// 유니코드가 아닌 데이타를 유니코드라고 우긴다거나
// BMP 영역만 지원하고 있다거나 하는 것을 모르고 작업하면
// 문제가 발생할 수 있다고 한다.
// 유니코드 코드 포인트란 문자세트에서 특정 문자를 지정하는 번호라고 볼 수도 있다.
// UCS=Universal Character Set
// 유니코드는 31비트 문자세트 라고 하는데, 하지만 현재 계획상으로는 21비트 안에서 모두 표현이
// 된다고 한다.
// UCS-2 는 유니코드의 코드 포인트를 2바이트로 인코딩한다고 한다.
// 유니코드 코드 포인트는 유니코드에서 정의된 숫자라고 한다.
// Universal Character Set
// 20 억개의 문자 코드 포인트를 가진다.
// 모든 문자가 가상 테이블 안에 포함된다.
// 이 테이블은 128개의 그룹으로 나뉜다. 
// 한 그룹은 다시 256개의 판(plane) 으로 나뉜다.
// 하나의 판 안에는 다시 65535 개의 코드 포인트가 있다고 한다.
// 결국 65535 개의 문자가 256개의 판에 기록되고 그것을 그룹이라 부른다.
// 다시 요 그룹이 128개로 뭉치면 UCS 테이블이 된다.
// 65535 * 256 * 128 = 대략 20억
// 여기서 최초의 65535 개의 코드 포인트가 할당되는 부분을 기본 언어판
// (Basic Multilingual Plane === BMP === 기본 다국어 평면) 이라고 부른다고 한다.
// 일반적으로 첫 65535개가 있는 BMP 만이 사용된다.
// Unicode 는 UCS 의 서브세트이며 호환된다고 한다.
// 유니코드는 UCS 중에 그룹 0번의 0번 판부터 16번 판까지만 사용한다고 한다.
// 유니코드 인코딩에 관해서는
// 유니코드에 매겨진 코드 포인트가 바이트로 어떠하게 표현할 것인지를 나타낸다고 한다.
// UTF-32 는 코드 포인트 값을 그대로 유지하면서 바이트로 표현한다고 한다.
// UTF-16 은 코드 포인트 값을 유지하되, BMP 을 벗어난 문자는 32비트로 인코딩한다고 한다.
// UTF-8 은 코드 포인트 값에 따라 1바이트,2바이트,3바이트,4바이트로 가변 인코딩 한다고 한다.
// Java 는 1.0 이 나왔을 때부터 문자를 나타내는데 유니코드를 사용해왔다고 한다.
// Java 언어에서는 내부 문자코드로써 유니코드를 사용하여 1문자에 16비트를 할당한 것이다.
// 유니코드는 처음에 1문자가 16비트 였지만, 포함된 문자수가 증가함에 따라 유니코드 2.0 에서
// 21 비트로 확장되었다고 한다. 하지만 Java 에서는 호환성 유지를 위해 char 형 16비트인
// 상태라고 한다. 그래서 문자를 다룰 때 주의해야할 것들이 있다고 한다.
// unicode 가 나오기 전까지는 한국어는 Extended Unix Code - Korea (EUC-KR)
// 을 사용하거나 윈도우나 맥도 한글문자코드를 따로 사용하였다고 한다.
// 여러가지 문자코드를 Application 내부에서 똑같이 취급하는 것은 꽤 어려운 일이다.
// 문자수가 점점 추가되면 문제가 되는 것이 하나의 문자에 대한 비트폭이라고 한다.
// 인코딩 형식을 보면
// 유니코드에 포함된 문자는 코드 포인트로 나타나고 U+ 뒤에 16진수로 표기한다.
// 알파벳 "a" 는 U+0061 이고
// 한글의 "가" 는 U+AC00 가 된다.
// 유니코드 코드 포인트를 고대로 Application 에서 사용하는 경우는 거의 없다고 한다.
// 통상적으로 부호화(인코드)해서 사용한다고 한다.
// 유니코드의 부호화 형식은 Unicode Transformation Format(UTF) 이 사용된다고 한다.
// 부호화 형식에는 3 가지가 있다.
// UTF-32, UTF-16, UTF-8
// UTF-32 
// 유니코드의 코드포인트는 21비트를 사용하나, 이를 32비트(4바이트)의 고정길이로 엔코딩(부호화)
// 하는 것이다. 1개의 문자를 표현하는데 항상 4바이트를 사용하기 때문에 다른 엔코딩 형식과
// 비교해 많은 영역이 필요하다. 그래서 파일 등에는 거의 사용하지 않는다고 한다. 그러나,
// 엔코딩이 간단하고 다루기 쉬워 Application 내부 표현으로 UTF-32 를 사용한다고 한다.
// UTF-16
// 16비트 단위로 문자를 인코딩하는 형식이다.
// 1개의 문자를 1 또는 2 단위의 가변길이로 인코딩한다고 한다.
// 즉, 한개의 문자에 2바이트 또는 4바이트를 사용한다.
// 유니코드가 21비트로 확장되기 전의 16비트로 나타내고 있던 문자는 고대로 16비트로 엔코딩한다.
// U+0061 은 "a" 이고 0x0061 으로 표현하고,
// U+C544 는 "아" 로 0xC544 로 표현한다.
// 문제는 16비트를 넘는 영역의 문자이다.
// 확장된 영역의 문자는 U+010000 에서 U+10FFFF 에 해당한다고 한다.
// 이것을 surrogate(대리)쌍 방법으로 엔코딩한다고 한다.
// 쌍으로 2개의 surrogate 를 사용하여 표현한다고 한다.
// 21비트 중 상위 5비트와 하위16비트로 분할하여
// 상위 5비트를 uuuuu,
// 하위 16비트를 yyyyyyyy xxxx xxxx 로 한다고 한다.

// 유니코드 코드 포인트
// u uuuu yyyy yyyy xxxx xxxx
// 를 UTF-16 으로 표현하는 듯 하다..
// >>>
// UTF-16
// 1101 10ww wwyy yyyy 1101 11yy xxxx xxxx
// 상위 Surrogates 1101 10ww wwyy yyyy
// 하위 Surrogates 1101 11yy xxxx xxxx

// 위에 8줄에 쓴 것 처럼
// 21비트 중 상위 5비트와 하위16비트로 분할해 상위 5비트를 uuuuu, 하위 16비트를
// yyyyyyyy xxxx xxxx 로 하고나서 요것을
// 위에 8줄에 쓴 내용의 일부와 같이 
// 16비트 X 2 (총 32비트)로 인코딩 한다고 한다.
// 위에 8줄 내용 중에 wwww 는 상위 5비트 u uuuu 에서 1을 뺀 수 라고 한다.
// 상위 5비트가 11011 로 시작하는 0xD800 에서 
// 0xDFFF 는 원래 BMP 에서도 사용되지 않았던 영역이라고 한다. 그래서
// 상위 5비트를 체크하면 Surrogates 쌍인지 BMP 인지 판단할 수 있다고 한다.
// Surrogates 쌍인 경우, 6비트째가 0 이면 상위 Surrogate 이고
// Surrogates 쌍인 경우, 6비트째가 1 이면 하위 Surrogate 라고 판별할 수 있다.
// Java 는 문자의 내부표현으로 요 UTF-16을 사용한다. char 타입은 16비트폭으로 UTF-16
// 을 보관한다. 이는 곧 char 형이 1문자에 대응하고 있는 것만은 아니다라는 것이다.

// UTF-8
// 가변길이 부호화(엔코딩)형식으로
// 8비트 단위로 1~4 단위,
// 즉,
// 1~4바이트를 사용하여 문자를 부호화한다.
// UTF-8 은 ASCII(American Standard Code for Information Interchange)
// 의 상위호환이 되고 있어,
// ASCII 의 범위(U+0000 에서 U+007F) 는 그대로 1바이트로 엔코딩한다.
// 2바이트로 엔코딩되는 것은 U+0080 부터 U+07FF 의 범위라고 한다.
// U+0800 에서 U+FFFF 까지의 범위는 3바이트로 엔코딩된다고 한다.
// BMP에 포함되는 이모티콘이 요 범위에 있으므로 1문자로 3바이트를 사용한다. 이후
// U+010000 에서 U+10FFFF 범위의 문자는 4바이트로 인코딩된다.

// Java 에서는 유니코드가 16비트 코드포인트를 사용하고 있을 때에는
// char 형으로 모든 문자를 나타낼 수 있었다. 왜냐하면 char 형이 16비트폭의 형태이기 
// 때문이다. 하지만, 유니코드가 21비트로 확장되었기 때문에 char 형에서 모든 것을
// 표현 할 수 없게 되었다고 한다. 그래서 Java SE 5 때 확정된 문자를 어떻게
// 나타내는지를 검토한 것이 JSR204 Unicode Supplementary Character Support
// 라고 한다. String 클래스가 구현하고 있는 CharSequence 인터페이스 (규격) 에서는
// UTF-16 으로 엔코딩된 문자라인을 취급한다고 한다. 한편, 유니코드 코드 포인트를
// 나타내기 위해서 int 형도 사용이 된다.

// UTF-16 은 어떤 문자라도 2바이트이상의 용량을 사용한다.
// UTF-8 이면 1바이트로 엔코딩되는 알파벳이어도, UTF-16 에서는 2바이트가 사용된다.

int java.lang.String.codePointAt(int index)

codePointAt(int index) 메서드는 지정된 index(색인 목록 순서 숫자) 에서 그 문자 (Unicode code point) 를 반환 한다.

문자 그대로 반환하지 않고 Unicode code point 값을 int 형으로 반환한다.

그 index(순서가 있는 색인 목록의 숫자) 는 문자 값들 (Unicode code units) 을 참조하며

codPointAt(int index) 메서드으 파라메터인 int index 의 argument 의 범위는 0 부터 length() - 1 까지 이다.

codePointAt(int index) 메서드는 

int index 파라메터에 대입되는 그 값의 index(색인 목록의 순서를 나타내는 숫자) 에 있는 그 문자의 code point 값을 반환한다.

 

---

https://velog.io/@riwonkim/Java%EC%9D%98-%EB%AC%B8%EC%9E%90-%EC%B2%98%EB%A6%AC%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C-%EB%B9%84%ED%8A%B8%ED%8F%AD-%EB%B3%80%ED%99%94-%EB%8C%80%EC%9D%91

Java의 문자 처리(유니코드 비트폭 변화 대응)

---

실행 결과

12593
44620