💻 Encoding / Decoding

🌊 Recap on Input / Output

• 단순 InputSystem 과 BufferedInputSystem 의 read() 효율성은 검증했다. write() 도 마찬가지인가 ?
  : YES. InputStream을 동일한 것으로 쓰고, 같은 용량을 FileOutputStream으로 썼을 때는 5.3s, BufferedOutputStream으로 썼을 때는 0.4s 가 걸렸다. 오히려 read보다 차이가 더 나는 것을 볼 수 있다.
• Buffer 사이즈가 넘어갈 때, 내부적으로 처리를 해주는가?
  : NO. 아래와 같은 에러를 던진다.
  

	BufferedInputStream bis = new BufferedInputStream(fis,1000000000);
	BufferedOutputStream bos = new BufferedOutputStream(fos,1);
	
	// Exception in thread "main" java.lang.NullPointerException
	//	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
	//	at java.io.BufferedOutputStream.write(BufferedOutputStream.java:95)
	
	 public synchronized void write(int b) throws IOException {
	        if (count >= buf.length) {
	            flushBuffer();
	        }
	        buf[count++] = (byte)b;
	    }

✔ 출력할 때 문자가 깨지는 문제

Mission 1을 위한 세팅을 진행하다가, Tomcat 관련 Log의 한글 부분이 IDE 출력 창에서 깨져서 나오는 것을 확인했다. 이를 고치기 위해 구글링을 했더니,

1. 설정에서 모든 인코딩 관련 설정을 UTF-8로 바꿀 것
2. VM Options 에 아래 두 줄을 추가할 것:

	-Dfile.encoding=UTF-8
    -Dconsole.encoding=UTF-8

이런 솔루션을 제공해서 따라해봤더니 한글이 잘 나온다. UTF-8 이라고 하면 막연하게 유니코드를 잘 읽을 수 있게 하는 인코딩이라고는 알고 있지만, 정확하게 내부적으로 이 설정이 작용하는지 모르고 있어서, 이를 공부하고 공유하려고 한다.

💻 Encoding : 인간의 언어를 컴퓨터의 언어로

우선 사전적으로, Encoding 이란 '~를 코드화하다' 라는 의미이다. 컴퓨터는 인간의 문자를 모르기 때문에 컴퓨터가 이해할 수 있는 언어로 변환하는 작업이 필요하기에 각각의 문자를 컴퓨터 언어로 코드화 하는 것이 필요하다.

공부하면서 조금 놀라고, 또 재밌었던 부분을 먼저 던지려고 한다 :

U+1F600

위 코드가 어떤 것을 의미할까? 영어 ? 한글 ? 숫자 ? 어느 나라의 언어?
힌트를 주자면 만국공통의 언어라고 할 수 있겠다.

정답

이것을 알고, 내 생각보다 더 많은 것이 이 "인코딩"이라는 과정을 통해 컴퓨터에게 인식되고 있다는 것을 알았다. 컴퓨터는 우리가 사용하는 문자를 숫자로 변환하는데, 이를 다시 이진수로 치환한다. 본격적으로 내부적으로 어떤 과정을 통해 이 변환이 이루어지는 지, 그리고 다양한 변환법에는 어떤 것들이 있는지, 그리고 잘못된 Encoding 을 선택하게 되면 어떤 일이 일어나는지 알아보자.

Encoding 이란 문자를 코드로 변환하는 것이고, 그 반대로 Decoding 이란 코드를 문자로 변환하는 것이다.

✔ ASCII

역사에 대해 조금 알아보자면, ASCII의 탄생 전에는 컴퓨터의 제조업체마다 각자의 방식으로 알파벳, 숫자 및 다른 문자를 표현했기 때문에, 이들간의 데이터 교환이 어려웠다고 한다. 이러한 문제를 해결하기 위해 ASCII (American Standard Code for Information Interchange) 또는 한국어로 미국정보교환표준부호가 태어났다.

7비트를 사용하는데 이는 $2^7$ 즉 128개의 다른 문자를 표현할 수 있다.000 0000 - NULL 로 시작하여, 영어 대소문자 및 10개의 숫자, 32개의 특수 문자 그리고 하나의 공백 문자로 이루어져 있다.

처음에는 ASCII로 부족함이 없었지만, PC가 더 널리 보급화되고, 세계화가 진행되며, 각 다른 나라의 언어를 표현하는 것이 필요해졌다. 그래서 남은 1비트도 사용하여 $2^8$ , 즉 256 문자를 표현 한 것이 확장 아스키 (Extended ASCII) 코드이다. 국가별로 다른 변형이 존재한다. 예로 들어서, ISO-8859-1 ~ ISO-8859-16 가 있는데, ISO-8859-1 은 서유럽에서 많이 쓰이는 라틴어를 포함한 문자가 있다고 한다. 어떤 인코딩 기법을 썼는지 알아야, 정확하게 데이터를 해석할 수 있다.

ASCII로는 한글을 표현하기에는 역부족이다. 이를 어떻게 해결했을까?

✔ EUC-KR (Extended Unix Code - Korea)

2바이트를 사용해 한글을 표현하는 방법이다. 2350자의 한글 음절과 4888자의 한자를 지원하며, '가' 에서 '힝' 까지 대부분의 한글 문자를 표현 할 수 있다. 한글에는 초성,중성,종성이 존재하는데, EUC-KR은 모든 글자가 완성된 형태로 존재하기 때문에 표현하지 못하는 문자도 존재한다. 예로 들어, "뷁"이라는 문자를 표현 할 수 없다.

String str = "뷁";
byte defaultBytes[] = str.getBytes();		// CP 949
byte eucBytes[] = str.getBytes("euc-kr");

System.out.println("기본 인코딩 : "+ new String(defaultBytes));
System.out.println("EUC-KR 인코딩 : "+ new String(eucBytes,"euc-kr"));

출력:
기본 인코딩 : 뷁
EUC-KR 인코딩 : ?

• 참고로 String 클래스의 getBytes 함수는 바이트 배열을 어떤 인코딩을 사용해 문자로 치환할지 지정하는 생성자가 존재해서 이를 썼다. 또한, new String(byte[], "인코딩명") 을 통해 디코딩 할 수 있다.

가끔 작업을 하다가 � 라는 문자가 도배된 것을 볼 수 있다. 이는 해석할 수 없는 문자를 의미한다. 잘못된 인코딩 방식을 선택하면 이런 현상을 볼 수 있으니 주의하자.

✔ CP949

PC가 보급됨에 따라, 이를 사용하는 지역 또는 국가에 따라 여러 확장 아스키가 필요해졌는데, 이 코드페이지 마다 'CP XXX'라고 이름을 붙였다. 참고로 코드페이지(CP)란 256문자를 어떤 숫자로 각각 매핑 할 것인지를 표시해놓은 것이다.

cmd 를 실행시켜 chcp 라는 명령어를 치면 아래와 같은 출력이 나온다 :

한국어판 윈도우의 기본 코드페이지(CP)는 949인데, MS가 개발했기 때문에 MS949 또는 Windows-949 라고도 불린다. CP949 는 EUC-KR에 없는 8822글자를 추가해서 더 많은 한글을 표현할 수 있다. EUC-KR과는 다르게, 5비트씩 끊어 초성,중성,종성에 대응시키는 방식이다.

여기서 더 알 수 있는 점은, 운영체제마다 사용하는 인코딩 방식이 다르다는 것이다. 실제로 Window는 CP949 , MacOS 와 Linux 는 UTF-8을 사용한다.

✔ Unicode - UTF-8? 16? 32?

위 인코딩으로 한글은 잘 표현되지만, 한글 외에 다른 언어를 지원해야 하는 니즈가 발생할 수 있다. 이 때 쓸 수 있는 것이 Unicode - 전세계의 대부분의 문자를 표현할 수 있는 인코딩 방식이다. U+로 시작한다.

먼저, UTF-8은 범위에 따라 1~4 byte를 가변적으로 쓴다. 영문의 경우 ASCII처럼 1바이트를 쓰고, 한글에 경우 3바이트로 나타낸다. 참고로, 0~127 영역에서는 ASCII코드와 완전히 동일하기 때문에 호환성이 있다. 이 말은 즉슨 UTF-8을 지원하는 프로그램은 무리없이 ASCII 코드를 읽을 수 있다는 말이다. 그리고 사용빈도가 높은 글자는 적은 공간을 차지하고, 낮은 글자는 많은 저장공간을 차지하게끔 효율적으로 만들어졌다.

반면 UTF-16은 유니코드 문자를 2바이트 또는 4바이트로 인코딩한다. 주로 사용되는 문자는 2바이트로, 그 이외의 문자는 4바이트로 인코딩 되는데, 한글은 2바이트로 표현된다. 따라서 UTF-8과 비교했을 때, 한글을 표현하기에 더 적은 메모리가 드는 것은 UTF-16이다.

UTF-32는 4바이트로 인코딩한다. 하지만 고정 길이 문자열이기 때문에, 문자열 내의 문자 위치를 찾는 등의 문자열 조작 작업이 용이하다.

💻 Encoding In Java

자바는 기본적으로 UTF-8 방식을 채택한다. String.getBytes() 메서드를 활용하면 자바에서 인코딩을 할 수 있다.

String str = "테스트";
byte eucBytes[] = str.getBytes("euc-kr");

추가적으로는, 웹 개발을 하다보면 URL 관련하여 인코딩이 필요한 경우가 생기는데, 이 때는 URLEncoder / URLDecoder 클래스를 사용하면 된다. 간단하게 설명하자면, URL 을 구성하는 데에는 규칙이 있는데, 이 클래스를 사용하면 이 규칙을 사용해서 character set을 잘 변환해준다.

💻 올바른 인코딩을 쓰는 것의 중요성

올바른 인코딩의 중요성은 인코딩된 문자를 디코딩 할 때 더 크게 느낄 수 있다. "테스트" 라는 문자열을 EUC-KR 인코딩으로 변환하면 C5D7 BDBA C6AE 이다. (16진수이고 컴퓨터 내부적으로는 바이너리). 이를 각각 다른 인코딩 형식을 사용하여 decode 하면 :

EUC-KR : 테스트
ASCII : ������
iso-8859-1 : Å×½ºÆ®
UTF-8 : �׽�Ʈ

위와 같이 제대로 정보를 표현하지 못하는 것을 알 수 있다.

💻 그럼 다시, 출력할 때 문자가 깨지는 문제는?

그럼 IDE 출력창에서 한글 로그가 깨졌던 문제는 출력창에 사용된 인코딩 방식과 실제 문자열의 인코딩 방식이 일치하지 않기 때문에 생겼던 일이라고 결론지을 수 있다. 내가 사용한 IntelliJ 같은 경우에는 UTF-8을 기본 인코딩으로 사용하고 있는데, 출력창에서 사용한 건 CP949 였기 때문에 생긴 일이었다. 위에서 했듯이, 출력창의 인코딩 방식을 UTF-8로 바꾸어 줬더니 해결 된 것을 확인할 수 있었다.

운영체제마다, 파일마다, 응용 프로그램마다 인코딩 방식을 잘 확인해서 올바르게 데이터를 읽고 , 써야 한다.