Perl/한글 페이지의 소스 보기 (부분)

내용출력
로그인[l]
수정할 수 없습니다: Perl/한글 는 읽기 전용 페이지입니다.
=== # 기본 개념, 문자열 상수, 표준 입출력, 정규표현식 ===

컴퓨터에서 영어 이외의 언어를 다룰 때는 이래저래 신경써야 하는 점들이 생깁니다. 8비트, 16비트 컴퓨터 시절에 비하면야 훨씬 상황이 나아졌습니다만, 여전히 영어를 사용할 때에 비해 손이 더 갑니다.


'''1) 다음 문자열의 길이는 몇인가'''

일단 코드 하나를 가지고 얘기해 봅시다.

{{{#!vim perl
#!perl
# 01_length.pl
use strict;
use warnings;

my $eng = "hello";
print length($eng), "\n";
my $kor = "안녕하세요";
print length($kor), "\n";
}}}

실행결과:
{{{
5
10
}}}

똑같이 "다섯 글자"로 이루어진 스트링인데, 첫번째 줄은 5가 나오는데, 두번째 줄은 5가 아니라 10입니다. 게다가 어떤 환경에서는 15가 나올 수도 있습니다.

왜 이런 현상이 발생하는지부터 알아봅시다.



'''2) 아무리 그래도 이건 알고 있어야 얘기가 되는 것들'''

컴퓨터에는 모든 정보가 1 또는 0의 조합으로 저장됩니다. 이렇게 1 또는 0이 들어가는 한 자리가 비트(bit).

보통은 8개의 비트를 묶어서 한 단위로 처리합니다. 이것이 바이트(byte). 네트워크 통신에 관련된 분야에서는 옥텟(octet)이라고도 부릅니다.

한 바이트는 8비트이므로, 00000000 부터 11111111까지, 10진수로는 0부터 255, 16진수로는 0부터 FF 까지 총 256가지 조합 중 하나를 저장할 수 있습니다.

(앞으로는 16진수는 0x 를 앞에 붙여서 0x00, 0xA0FF 등으로 표기하겠습니다, 자릿수가 많을 때는 0x45 65 2A F3 이렇게 공백을 삽입하고, 명백히 16진수인 걸 알 수 있을 때는 0x를 생략하겠습니다)



'''3) 얘기를 해야 하나 말아야 하나 망설여지는 것들'''

컴퓨터에서 문자를 저장할 때는 각 문자에 특정한 비트조합이 대응됩니다.
* A는 0100 0001(2진수) = 65(10진수) = 41(16진수) 로 저장됩니다.
* B는 0100 0010 = 66 = 0x42 로 저장됩니다.
* ...

어느 문자가 어느 수에 대응될지 규약이 있는데, 이것을 "인코딩(encoding)"이라고 합니다.
보통 널리 사용되는 건 ASCII 규약입니다. 프로그램에 관심을 가진 후에는 "아스키 코드"란 걸 들어보셨을 겁니다.

인코딩은, "추상적인 정보를 구체적인 코드로 변환하는 것, 또는 변환하는 규칙"이라고 생각하면 됩니다. 그 역은 디코딩(decoding)이라고 합니다. 즉
* "영어에서 사용하는 알파벳 문자 중에 '에이'라고 발음하는 첫번째 문자의 대문자 형태, 종이에 그릴 때는 A 이렇게 그림" - 추상적인 정보
* 0100 0001 또는 0x41 - 구체적인 코드
둘 사이를 변환하는게 인코딩과 디코딩이라는 얘기입니다.



영문과 특수문자는 전부 합쳐도 127개보다 적기 때문에, 256가지 정보를 저장할 수 있는 한 바이트 안에 한 문자를 넣을 수 있습니다.

그런데 그외 언어의 문자를 전부 추가하려니 택도 없습니다. 특히나 중국의 한자, 한국의 한글(한글의 경우 자모가 조합된 음절 하나하나가 다 개별 문자입니다)의 수는 어마어마합니다. 그래서 한 바이트 안에 한 문자를 넣을 수 없고, 2바이트, 또는 3바이트, 또는 4바이트가 필요합니다.


자, 영문자 A를 어느 숫자에 대응할 지는 ASCII 규약을 따르면 됩니다. 그러면 한글 "가"를 어느 숫자에 대응할지는 어떻게 정하느냐?

안타깝게도 이걸 정하는 규약이 단 하나가 아니라 여러 가지가 있고,
* MS윈도우즈에서 사용되는 코드페이지949(cp949)에서는 0xb0a1 에 대응됩니다.
* 유닉스/리눅스에서 사용되었던 euc-kr에서도 0xb0a1 에 대응됩니다. (cp949는 euc-kr에 빠져있던 문자들을 추가한 거라서, euc-kr에 들어있던 문자들은 그대로 cp949에서도 같은 값에 대응됩니다)
* cp949나 euc-kr에서는 한글 "가"를 저장하기 위해서는 2바이트가 필요합니다. 다른 한글 문자들도 다 마찬가지로 2바이트가 필요합니다.
* 유닉스/리눅스에서 최근에 일반적으로 사용되고, 웹페이지에서도 널리 사용되는 UTF-8 규약에서는 0xea b0 80 에 대응됩니다. 즉 "가" 또는 그 외 한글 문자 하나를 저장하기 위해서는 3바이트가 필요합니다.



'''4) 펄 스크립트를 어떤 인코딩에 따라 저장했느냐에 따라서...'''


이제 1)의 프로그램으로 다시 돌아가봅시다. 저 프로그램을 작성하여 저장할 때, 에디터에서 어떤 인코딩을 사용하여 저장했느냐에 따라서 스크립트 내의 모든 문자가 어떤 숫자에 대응되어 저장될지, 몇 바이트를 차지할지가 달라집니다.

윈도우의 메모장(notepad.exe)에서는 "새 이름으로 저장" 메뉴에서 인코딩을 지정할 수 있습니다. 다음 그림에서 ANSI 가 cp949 입니다. ANSI와 UTF-8 말고 두 개 더 있는데 여기서는 통과.

Upload:encoding01.png

그러면 저 스크립트를 두가지 인코딩으로 각각 저장한 후 파일의 크기를 비교해 보겠습니다.

Upload:encoding02.png

두 인코딩 모두 영문,숫자,특수 기호를 저장하는 건 ASCII와 동일하게 대응시킵니다. 따라서 차이는 "안녕하세요" 다섯글자 뿐인데, cp949는 한글 문자 하나에 2바이트를 사용해서 총 10바이트. UTF-8은 3바이트씩 총 15바이트가 필요합니다. 따라서 전체 크기는 5바이트 차이가 납니다.

그런데 막상 확인해보면
* cp949 인코딩을 사용해 저장한 파일은 151바이트
* UTF-8 인코딩을 사용해 저장한 파일은 159바이트
이렇게 8바이트 차이가 납니다. 이것은 메모장이 UTF-8 인코딩을 사용해 문서를 저장할 때 제일 앞에 추가로 3바이트짜리 정보를 집어넣기 때문입니다. 다른 에디터를 사용할 경우는 정확히 5바이트 차이날 것입니다.

(** 메모장이 문서 제일 앞에 집어넣은 3바이트 정보는 BOM(byte order marks)이라 부르는데, 사실 UTF-8 인코딩의 경우 BOM을 넣을 필요가 없습니다. 이 이유로, 메모장에서 UTF-8로 저장한 텍스트를 다른 에디터나 프로그램에서 읽을 때 문제가 될 수 있습니다. **)



'''5) 파일 크기만 달라지면 다행인데...'''


처음 프로그램 마지막에, $eng 와 $kor 에 저장된 문자열을 출력하는 라인을 추가합니다.

{{{#!vim perl
print "[$eng][$kor]\n";
}}}

그런 후 마찬가지로 두 가지 인코딩을 사용해서 따로 저장한 후 실행해보면...

Upload:encoding03.png

cp949 로 인코딩한 스크립트를 실행하면 제대로 "안녕하세요"가 출력이 되는데, UTF-8로 인코딩한 스크립트를 실행하면 한글이 깨져 나옵니다. 아아, 악몽의 시작입니다ㅠㅠ

우리가 작성한 펄 프로그램이 "안녕하세요"를 출력할 때는, "한글 음절 안,녕,하,세,요를 출력해주세요~"라고 하는게 아닙니다. 펄 프로그램은 명령 프롬프트 창에게 단지 "바이트들의 덩어리 be c8, b3 e7, c7 cf, bc bc, bf e4 를 출력해주세요"라고 전달하거나(cp949의 경우) "바이트들의 덩어리 ec 95 88, eb 85 95, ed 95 98, ec 84 b8, ec 9a 94 를 출력해주세요"(utf-8의 경우)라고 전달합니다.

명령 프롬프트창은 펄 프로그램에게서 넘겨받은 바이트 덩어리를 화면에 뿌리면서, 다시 해당 바이트 덩어리에 대응되는 문자로 바꾸어서 출력합니다. 이 때 "어떠한 바이트 덩어리가 어떤 문자에 대응될 것인가" 역시 인코딩 규약을 따르는데, 한글 윈도우를 쓸 경우 명령 프롬프트 창이 기본적으로 사용하는 인코딩은 cp949입니다. 따라서 be c8 을 "안"으로 바꿔줄 수는 있지만, ec 95 88 을 "안"으로 바꿔주지는 못합니다.

출력 뿐 아니라 입력을 받을 때도 마찬가지, 우리가 <STDIN> 표준 입력을 통해서 입력을 받는다면, 명령 프롬프트 창에서 실행한 프로그램에 키보드로 입력한다면 기본적으로 cp949 인코딩을 따르고, 키보드로 "안"을 입력했다면 실제로 펄 프로그램에게 전송되는 건 "한글 음절 안"이 아니라 "be c8"이라는 2바이트의 데이타입니다.

비슷한 맥락으로, 펄로 웹사이트 방명록 CGI를 만들었다면, 유저가 방명록에 "안"을 입력하고 전송할 경우 웹사이트의 인코딩에 따라서 "be c8"이 들어올 수도 있고 "ec 95 88"이 들어올 수도 있습니다.



'''6) 바이트 덩어리와 문자열 간의 변환'''


이제 문제의 원인을 (수박 겉핧기나마) 알았으니, 해결책을 알아봅시다.

Perl 5.8 부터는 Perldoc:Encode 모듈을 제공하며, 다음 두 가지를 구분해서 처리하고 서로간의 변환을 할 수 있도록 지원합니다.
* 입출력에 사용되기 위한 바이트들의 덩어리. 이것을 Encode 문서에서는 octets 라고 부릅니다. 이 연재에서는 주로 "바이트 덩어리"라고 부를 것입니다.
* 세상 여러 언어에서 사용되는 문자들이 하나 이상 모여 이뤄진 문자열. 이걸 string 으로 부르며, 이 연재에서는 "문자열" 또는 "추상적 문자열"이라고 표현할 것입니다.

Encode 모듈은 encode와 decode함수를 제공합니다.
* decode 함수는 "바이트 덩어리"를 "문자열"로, octets을 string으로 바꿉니다.
* encode 함수는 "문자열"을 "바이트 덩어리"로, string을 octets로 바꿉니다.

자, 해 봅시다.

똑같은 소스코드가 두 가지 인코딩으로 각각 따로 저장되어 있어서 두 번 나옵니다. 내용도 살짝 달라지니 주의합시다.

먼저 cp949 로 인코딩했던 스크립트입니다.

{{{#!vim perl number
#!perl
# 02_length_cp949.pl
use strict;
use warnings;
use Encode;

my $eng = "hello";
print length($eng), "\n";
my $kor = "안녕하세요";
print length($kor), "\n";
# 문자열로 변환
my $string = decode("cp949", $kor);
print length($string), "\n";
# 명령 프롬프트 창에 출력하기 위해 cp949 에 맞춰 변환
my $output = encode("cp949", $string);
print "[$output]\n";
}}}

다음은 UTF-8로 인코딩해서 저장한 스크립트입니다.

{{{#!vim perl number
#!perl
# 02_length_utf-8.pl
use strict;
use warnings;
use Encode;

my $eng = "hello";
print length($eng), "\n";
my $kor = "안녕하세요";
print length($kor), "\n";
# 문자열로 변환
my $string = decode("UTF-8", $kor);
print length($string), "\n";
# 명령 프롬프트 창에 출력하기 위해 cp949 에 맞춰 변환
my $output = encode("cp949", $string);
print "[$output]\n";
}}}

10번 라인까지는 1)에서와 같습니다.

12번 라인에서, $kor 변수에 들어 있던 바이트 덩어리를, Perl의 진정한 "문자열"로 변환합니다. 이 때 decode의 첫번째 인자로는 인코딩 규약의 이름이 들어갑니다. cp949 로 저장했던 스크립트에서는 저 문자열을 cp949 규약에 맞추어서 변환해야 하고, UTF-8 로 저장했던 스크립트에서는 UTF-8 규약에 맞추어야 할 것입니다.

실행 결과는

Upload:encoding04.png

스크립트가 어떤 인코딩으로 저장되었느냐에 따라서, $kor 변수에 들어있는 바이트 덩어리에 length() 함수를 적용한 결과는 10 또는 15가 나왔습니다. 그러나 이 바이트 덩어리를 문자열로 변환하고 나면, 인코딩에 상관 없이 글자의 개수가 반환됩니다. 둘 다 "안녕하세요"의 길이는 5가 나오는 것을 볼 수 있습니다.


화면에 출력해봅시다.

두 파일에 동일하게 다음 라인들을 추가해줍니다.

{{{#!vim perl
14 # 명령 프롬프트 창에 출력하기 위해 cp949 에 맞춰 변환
15 my $output = encode("cp949", $string);
16 print "[$output]\n";
}}}

명령 프롬프트 창이 cp949 인코딩을 사용하고 있기 때문에, 스크립트 자체가 어떤 인코딩을 사용해 저장했느냐에 무관하게, 명령 프롬프트 창에 문자열을 출력하기 위해서는 cp949 인코딩 규약에 기반해서 다시 바이트 덩어리로 바꾸어 준 후에 전달해야 합니다. 이때 encode 함수를 사용합니다.

실행 결과는 다음과 같습니다

Upload:encoding05.png

아까는 UTF-8 로 인코딩한 스크립트에서 "안녕하세요"를 출력하면 한글이 깨져서 나왔지만, 이제는 제대로 나오는 걸 알 수 있습니다. "안녕하세요"가 cp949 인코딩에 맞춰 바이트 덩어리로 바뀌어 전달되었고, 명령 프롬프트 창은 전달받은 바이트 덩어리를 다시 cp949 인코딩에 맞춰 해석하여 그에 대응되는 문자들을 출력하기 때문입니다.



'''7) 또 다른 경우 - 정규표현식의 예'''


문자열과 바이트 덩어리 간의 변환관계, 즉 인코딩의 문제는 입출력에만 영향을 끼치는 게 아니라, 문자열을 대상으로 한 여러가지 연산에도 적용이 됩니다.

예를 하나 들어보겠습니다. 키보드로 입력을 받아서, 입력받은 문자열이 변수에 저장되어 있던 문자열에 포함이 되는지 검사하는 코드입니다. (사실 이것도 "키보드로 입력을 받는" 부분에서 입출력과 관련이 있긴 합니다)

{{{#!vim perl
my $str = "안녕하세요";

chomp( my $input = <STDIN> );
if ( $str =~ /$input/ ) {
    print "match\n";
}
else {
    print "not match\n";
}
}}}


이 코드를 cp949 로 저장을 하여 명령 프롬프트 창에서 실행을 시키거나, UTF-8로 저장을 한 후 UTF-8 인코딩을 사용하는 리눅스 쉘에서 실행을 한다면 상관이 없지만, 코드를 저장할 때 사용한 인코딩과 실행환경에서 사용하는 인코딩이 일치하지 않으면 문제가 됩니다.

Upload:encoding06.png

$str 변수에는 "안녕하세요"라는 문자열이 들어가있고, 키보드로 "안녕"을 입력했는데, 어떤 때는 일치 검사를 통과하고 어떤 때는 하지 못합니다. 게다가 좌우 두 창을 비교해보면 통과 여부가 서로 반대입니다.

여기서도 앞의 경우와 마찬가지로..

* $str 변수에는 "안녕하세요"라는 문자열이 아니라, 사실은 be c8, b3 e7, c7 cf, bc bc, bf e4 (cp949로 저장한 코드) 또는 ec 95 88, eb 85 95, ed 95 98, ec 84 b8, ec 9a 94 (UTF-8로 저장한 코드) 로 구성된 바이트 덩어리가 들어 있습니다.
* 키보드로 입력한 "안녕"은 펄 프로그램으로 전달될 때 be c8, b3 e7 (cp949를 사용하는 쉘) 또는 ec 95 88, eb 85 95 (UTF-8을 사용하는 쉘)의 형태로 전달됩니다.
* 매치연산자는 저장된 바이트 덩어리 내의 일부가 전달받은 바이트 덩어리와 일치하는지를 검사합니다.

따라서 저장되어 있는 be c8, b3 e7, c7 cf, bc bc, bf e4 (cp949로 저장한 코드) 에 ec 95 88, eb 85 95 (UTF-8을 사용하는 쉘)가 포함되는지를 비교하면 일치하지 않는 것으로 판정됩니다. 우리 눈에는 "안녕하세요" 안에 "안녕"이 분명히 포함되어 있지만 말입니다.



이 문제도 마찬가지로, Encode 모듈을 사용해서, 저장되어 있는 바이트 덩어리와 입력받은 바이트 덩어리를 문자열로 변환을 함으로써 해결할 수 있습니다.

아래 코드는, 코드 자체는 cp949 인코딩을 사용하여 저장하고, 실제 실행은 UTF-8을 사용하는 쉘에서 실행할 거라고 가정했을 때의 코드입니다.

{{{#!vim perl number
# 이 파일은 cp949 로 저장되어 있음
use Encode;

my $str = decode("cp949", "안녕하세요");

chomp( my $input = <STDIN> );
$input = decode("UTF-8", $input);   # 입력이 UTF-8로 들어오는 경우
if ( $str =~ /$input/ ) {
    print "match\n";
}
else {
    print "not match\n";
}
}}}

4번 라인에서, 코드 내 문자 리터럴 "안녕하세요"를 decode를 써서 추상적인 문자열로 변환합니다. 이때는 cp949 인코딩 규약에 따라 변환합니다.
7번 라인에서, 키보드로 입력받은 문자열을 역시 추상적인 문자열로 변환합니다. 이때는 UTF-8에 따라 변환합니다.

변환이 끝나면 $str 과 $input 둘 다 바이트 덩어리가 아닌 문자들의 집합으로 취급되며, 8번 라인에서는 "안녕하세요"라는 문자열 안에 입력받은 문자열, 아래 스크린샷에서는 "안녕"이 포함되는지를 검사합니다.

Upload:encoding07.png

UTF-8을 사용하는 쉘에서 cp949 인코딩으로 저장된 코드를 실행했는데도 일치 여부가 제대로 판정이 되는 걸 알 수 있습니다.



'''8) 정규 표현식 하나 더'''


단순 일치 뿐 아니라, 정규표현식에서 "임의의 문자 하나"를 뜻하는 "."의 동작도 인코딩에 영향을 받습니다.

아래 코드는 $str 에 들어있는 문자열에서, "녕"이라는 문자 바로 뒤에 있는 문자 1개, 2개, 3개를 각각 출력합니다.

{{{#!vim perl number
my $str = "안녕하세요";

if ( $str =~ /녕(.)/ ) {
    print "[$1]\n";
}
if ( $str =~ /녕(..)/ ) {
    print "[$1]\n";
}
if ( $str =~ /녕(...)/ ) {
    print "[$1]\n";
}
}}}

(** 정규표현식에 익숙하지 않은 분들을 위해 짧게 설명하면, 정규표현식 내에 괄호로 둘러쌓인 부분에 매치되는 문자열이 그 다음 줄에서 $1 이라는 변수에 담깁니다. 우리가 하고자 하는 건 "안녕하세요"에서 "녕" 바로 뒤에 오는 게 뭔지를 출력하려는 겁니다. **<footnote([[/정규표현식]]))

섹션 7)에서와 같이, 위 코드를 cp949, UTF-8 두 가지 버전으로 따로 저장하고, 두 가지 쉘에서 각각 실행해보면 다음과 같이 나옵니다.

Upload:encoding08.png

* cp949 에서는, 코드의 6번 라인에서 "녕" 뒤에 (..) 이렇게 마침표 두 개를 넣었을 때 제대로 "하"를 잡아냅니다.
* UTF-8 에서는, 코드의 9번 라인에서 (...) 이렇게 마침표 세 개를 넣었을 때 제대로 "하"를 잡아냅니다.

즉, "."가 "한 바이트"에 해당이 되고, cp949 에서는 한글은 2바이트를 차지하므로 ".."를 써야 제대로 한 글자에 매치가 되고, UTF-8 에서는 한글은 3바이트를 차지하므로 "..."를 써야 매치가 된다는 얘깁니다.

따라서,

여러분은 한글이 포함된 문자열에 정규표현식을 사용할 때는 항상 그 문자열이 무슨 인코딩을 써서 저장되었는지를 감안해서 정규표현식을 다르게 써 주어야 합니다.\\
...\\
...\\
죄송합니다, 거짓말입니다. 설마 진짜로 믿으신 분은 안 계시겠죠..?

여기서도 마찬가지로, 바이트 덩어리가 아닌 문자열로 처리하도록 고쳐줍시다.

UTF-8로 저장한 스크립트를 다음과 같이 고치겠습니다:

{{{#!vim perl number
# 이 파일은 UTF-8 로 저장되어 있음
use Encode;

my $str    = decode("UTF-8", "안녕하세요");
my $prefix = decode("UTF-8", "녕");

if ( $str =~ /$prefix(.)/ ) {
    print "[", encode("UTF-8", $1), "]\n";
}
if ( $str =~ /$prefix(..)/ ) {
    print "[", encode("UTF-8", $1), "]\n";
}
if ( $str =~ /$prefix(...)/ ) {
    print "[", encode("UTF-8", $1), "]\n";
}
}}}

cp949로 저장한 스크립트였다면, "UTF-8"이라고 쓰인 부분을 "cp949"로 고치면 되겠죠?

4번 라인, "안녕하세요"를 바이트 덩어리에서 문자열로 변환했습니다.
5번 라인, 정규표현식 내에 들어가는 한글도 마찬가지로 바이트 덩어리가 아닌 문자열로 간주하게 하기 위해서 별도의 변수를 써서 문자열로 변환하여 저장했습니다.
8, 11, 14번 라인, 정규식에서 괄호안에 마침표에 매치되는 게 $1 변수에 담겼습니다. 그런데 $1 변수에 담긴 건 추상적인 문자열이고, 이것을 print 를 써서 출력할 때는 다시 바이트 덩어리로 바꿔서 쉘에 전달해야 합니다. 따라서 encode 합니다.

실행 결과는 다음과 같습니다.

Upload:encoding09.png

이제는 한글이 깨지지 않을 뿐 아니라, 마침표 하나가 한글 음절 하나에 매치되는 것을 확인할 수 있습니다. cp949 로 저장된 스크립트를 수정해서 실행해도 동일한 출력이 나옵니다.

즉, 원래의 텍스트가 어떤 인코딩을 써서 저장되었든지간에, 일반 decode를 써서 문자열로 변환하고 나면 무조건 정규표현식의 "."는 "문자 하나"에 매치됩니다. 한글 영어 가릴 것 없이 적용할 수 있습니다.

한번 더 예를 들어, 
{{{#!vim perl
/.{4}/
}}}
위 정규식은 바이트 덩어리를 대상으로 검사할 때는 4바이트에 매치되지만, 문자열을 대상으로 할 때는 바이트에 관계없이 문자 4개에 매치됩니다.



'''9) substr 의 예'''


substr 내장 함수는 문자열의 일부를 얻어낼 때 사용됩니다. (perldoc -f substr)

예를 들어 <code>substr( "hello", 1, 2 );</code> 는 hello 라는 문자열에서 1번 오프셋 뒤에 있는 "e"부터 시작해서 길이가 2인 문자열, 즉 "el"을 반환합니다. (제일 첫번째 문자는 오프셋 1이 아니라 0에 해당되니 조심)

문제는, 영어로 된 문자열은 상관이 없는데, 한글 문자열은 오프셋을 계산할 때도 길이를 계산할 때도 한글 한 글자가 몇 바이트냐를 따져야 된다는 겁니다.
* cp949 인코딩을 쓰는 경우 substr( "안녕하세요" , 2, 4 ) 가 "녕하"입니다.
* UTF-8 인코딩을 쓰는 경우 substr( "안녕하세요", 3, 6 ) 가 "녕하"입니다.

이것도, 문자열처럼 보이지만 사실은 바이트 덩어리였던 놈을 진정한 문자열로 변환하면 해결됩니다.

{{{#!vim perl number
# 이 파일은 cp949로 저장되어 있음
use Encode;

my $str    = decode("cp949", "English와 한글");
my $length = length($str);

for (my $i = 1; $i < $length; $i++) {
    printf "%2d : ", $i;
    print "[",
        encode("cp949", substr($str, 0, $i)),
        "] [",
        encode("cp949", substr($str, $i)),
        "]\n";
}
}}}

위 코드는 "English와 한글"이라는 문자열을 두 조각으로 쪼개는 예제입니다.

* 4번 라인, 바이트 덩어리를 디코드해서 문자열로 변환했습니다.
* 5번 라인, 이제 length는 정확히 문자 갯수를 반환합니다. 11글자입니다.
* 7번 라인, $i 는 1부터 10까지 증가하며 루프를 돕니다
* 10번 라인, substr은 $str의 제일 처음(오프셋0)부터, $i개의 문자를 얻어냅니다. 이걸 출력하기 위해 다시 인코드합니다.
* 12번 라인, substr은 $str의 오프셋 $i 부터, 그 뒤의 문자 모두를 얻어냅니다. 즉 $i+1번째 문자부터 마지막 문자까지로 구성된 문자열을 반환합니다. 역시 인코드해서 출력합니다.

실행결과는 다음과 같습니다.

Upload:encoding10.png


한글 영문 가리지 않고, 정확히 글자수를 세어서 앞뒤로 분리하는 걸 볼 수 있습니다.

이 코드를 decode, encode 없이 그냥 했다면 어떻게 될지 짐작해보시고 한번 직접 해보시기를 권장합니다.



'''10) 이 장의 내용 정리'''

글이 너무 길어지는 것 같아서 일단 여기서 끊고 다음 글에서 계속 쓰겠습니다.

이 장의 내용을 정리하면

<blockquote>
1. "인간에게 의미있는 정보를 담고 있는 추상적인 문자열"과 "컴퓨터가 그 정보를 저장하기 위해 사용하는 구체적인 바이트 덩어리"를 구분해서 생각해야 한다. (사용자는 그럴 이유가 없지만 프로그래머는 그래야 한다)

2. Perl 은 "문자열"을 다룰 수 있으나, 기본적으로 우리가 작성해서 저장한 펄 스크립트는 "바이트 덩어리" 형태로 저장되어 있고, 따라서 별도의 지시가 없으면 바이트 단위로 연산을 하게 된다.

3. 안타깝게도 한글은 한개의 "문자"가 한개의 "바이트"에 대응되지 않기 때문에, 문제가 생긴다.

4. 따라서 Perl 프로그램 내에서 한글 영문을 가리지 않고 "문자열"로써 다루고자 하면 바이트 덩어리를 문자열로 변환, 즉 디코드해야 한다.

5. 일단 디코드된 문자열은, 정규식이나 각종 스트링 관련 함수에서 정확히 의미에 맞게 다룰 수 있다.

6. 문자열을 외부에 출력하기 전에는 다시 바이트 덩어리로 인코드해야 한다. 또 외부에서 입력을 받을 때도 바이트 덩어리 형태로 들어온다는 걸 염두에 둬야 한다.
</blockquote>
정도가 되겠습니다.

다음 글에서는 디스크에 담긴 파일을 읽고 쓸 때의 인코딩/디코딩을 하는 예와, 매번 불편하게 decode, encode를 호출하지 않고 간편하게 처리하는 방법 등을 살펴 보겠습니다.
Perl/한글 페이지로 돌아가기 | 다른 수정본 보기