StudioEgo's Thoughts, seasonⅡ

이번에 Python을 이용하여 LibreOffice의 Unittest 소스코드에 공헌을 해보았습니다.

출처:

• Remapping NatNum-DBNum in Korean for compatibility tdf#130193
  https://gerrit.libreoffice.org/c/core/+/94747

관련 링크:

• tdf#130193 Japanese Traditional Numeric texts are wrong such as 1,2,3, 10, 1000, 10000
• tdf#130140 There is a string display error with numbers above 10 about All Korean Numeric text and Japanese Modern Numeric text
• tdf#130077 Korea's Hanja Upper Numbers[한자 갖은자] 5 and 1000 are wrong

링크의 Cppunit 소스코드에 보면 입력된 값에 대해서 이 값이 기대된 값(Expected value)인지 검사하는 로직이 있습니다.

이 단위테스트에서 주석과 결과를 넣어야할텐데, 문자열의 유니코드 코드포인트값을 어떻게 빠르게 뽑아낼까 고민을 하다 역시 Python이 있었지 하면서 Python으로 결과값을 뽑아내서 cppunittest 소스코드를 수정 작성하였습니다.

        // DBNum1 -> NatNum4: Korean lower case characters
        // 一億二千三百四十五万六千七百八十九
        sExpected = u"\u4e00\u5104\u4e8c\u5343\u4e09\u767e\u56db\u5341\u4e94\u4e07\u516d\u5343\u4e03\u767e\u516b\u5341\u4e5d ";
        sCode = "[NatNum4][$-0412]General\\ ";
        checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);
        sCode = "[DBNum1][$-0412]General\\ ";
        checkPreviewString(aFormatter, sCode, 123456789, eLang, sExpected);

아래는, 주석에 적은 문자열를 Python을 이용하여 Unicode Codepoint로 변환하는 예제입니다.

Python 3.8.3 (default, May 27 2020, 20:54:22) 
[Clang 11.0.3 (clang-1103.0.32.59)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "一億二千三百四十五万六千七百八十九".encode("unicode_escape")
b'\\u4e00\\u5104\\u4e8c\\u5343\\u4e09\\u767e\\u56db\\u5341\\u4e94\\u4e07\\u516d\\u5343\\u4e03\\u767e\\u516b\\u5341\\u4e5d'
>>> "壹億貳阡參佰四拾伍萬六阡七佰八拾九".encode("unicode_escape")
b'\\u58f9\\u5104\\u8cb3\\u9621\\u53c3\\u4f70\\u56db\\u62fe\\u4f0d\\u842c\\u516d\\u9621\\u4e03\\u4f70\\u516b\\u62fe\\u4e5d'
>>> "１억２천３백４십５만６천７백８십９".encode("unicode_escape")
b'\\uff11\\uc5b5\\uff12\\ucc9c\\uff13\\ubc31\\uff14\\uc2ed\\uff15\\ub9cc\\uff16\\ucc9c\\uff17\\ubc31\\uff18\\uc2ed\\uff19'
>>> "일억이천삼백사십오만육천칠백팔십구".encode("unicode_escape")
b'\\uc77c\\uc5b5\\uc774\\ucc9c\\uc0bc\\ubc31\\uc0ac\\uc2ed\\uc624\\ub9cc\\uc721\\ucc9c\\uce60\\ubc31\\ud314\\uc2ed\\uad6c'
>>> 

Python의 결과값을 이용하여 Cppunittest의 결과값 비교를 하는데 유용하여 사용했습니다.

Python이 아니였으면 일본사람인 小笠原徳彦(Naruhiko Ogasawara)님과 협업으로 리브레오피스 소스코드 수정하는데 많이 지연이 되었을 것 같아요.

ps. 파이썬(Python)같이 생산성 빠른 언어를 익혀두면 언젠간 쓸 일이 생긴다.

ps2. 참고할만한 글

https://towardsdatascience.com/a-guide-to-unicode-utf-8-and-strings-in-python-757a232db95c

일본 모리사와(Morisawa)직원이 작성한 "문자 코드는 무엇인가?"[ 文字コード is なに？ What is a character code? ] 슬라이드

The Guts of Unicode in Python 

- PyCon 2013 talk by Benjamin Peterson

Summary

Python의 CJK(Chinese-Japanese-Korean,동아시아문자처리) 라이브러리 정리

1. Cjklib 0.3.2 

Homepage: http://cjklib.org/0.3/

Python Package Index: https://pypi.python.org/pypi/cjklib/0.3.2

2. cjktools 1.6.0

Homepage: https://pypi.python.org/pypi/cjktools

Github: https://github.com/larsyencken/cjktools/

위의 2개의 CJK라이브러리를 조사해본 결과, Python2기반으로 작성되었으나, Python3로 변환되지 않았음.

cjklib의 경우는 중국어 중에서 만다린(보통화, 북경어), 상하이어, 광동어(홍콩어), 일본어, 한국어에 대한 지원이 있음을 확인했으나, 라이브러리 사용이 어렵게 느껴짐을 확인.

cjktools의 경우는 중국어와 일본어만 다루기 때문에 CJK(Chinese-Japanese-Korean)의 Korean이 없다는 것을 확인.

위의 라이브러리가 Python3로 변환되지 않은 것을 보고, 이번에 Python3를 공부할겸, Python3의 문자열 처리 및 Unicode Consortium의 unihan database 내용을 확인해보겠습니다.

CJK(Chinese-Japanese-Korean)의 개발에 대한 내용은 Adobe에서 활동하는 Ken Lunde의 책 "CJKV Information Processing"을 참조하여, 사용하기 편한 Python3 라이브러리를 만들어볼 계획입니다.

아래는 Python CJK라이브러리 조사전에 CJK에 관심을 가지게 된 트윗글

I should seriously consider a revised/updated/retitled version of my #IUC35 presentation: “CJK Uniform Ideographs” → https://t.co/ivGOx1eu8u

— Adobe CJK Type Blog (@CJKType) 2016년 1월 19일

“Genuine Han Unification is not outside the realm of extreme possibilities.”— Fox William Mulder, FBI Special Agent

슬라이드의 마지막장에 있는 의미심장한 문구

Unicode(유니코드)에 대해서 얼마나 아신가요?

홍민희님께서 작성한 Unicode 이해의 다양한 단계들 이란 글에서 심심풀이로 테스트를 하였습니다.

7단계중에서 저는 1~5단계까진 모두 경험해보고 해당되겠다는것을 알겠는데, 6~7단계는 잘 모르겠더군요.

5단계.
특정 문자셋을 사용하는 문자(열)을 바이트열로 인코딩하는 방식이 인코딩이며, UTF-8이 곧 Unicode가 아니라는 것을 아는 사람. Python에서unicode 타입과 str 타입이 왜 함께 있는지 이해하며 잘 사용한다. 혹은 C/C++에서 wchar_t[]/std::wstring으로 Unicode 문자열을 담아 사용하고 입출력 시에 그것을 인코드해서 char[]/std::string으로 변환해서 쓸 줄 안다. (또한 wchar_t가 곧 Unicode 문자를 뜻하는 것은 아니라는 것도 이해하고 있다.)

어릴때부터 컴퓨터를 사용해서 완성형과 조합형은 알았지만, 완성형은 DOS, 조합형은 한글과 컴퓨터사의 아래아한글에서 쓴다는것만 알았습니다.

그러다 MS사의 Windows95에서 한글 코드를 MS사에 맞는 문자코드(CP949, UHC)로 나온다고 해서 난리났던 잡지 기억도 나군요^^

문자 코드에 대해서 직접 접하게 된건 리눅스를 처음 설치하게 되었던 2004년 말 고3때였습니다.

2004년말 2005년초 정도부터 Linux에서 Unicode를 쓰는 것이 대세가 되어, 기본 서버에서 한글 설정이 UTF-8로 됨에 따라, 리눅스를 데탑으로 쓰는데 깨나 고생했던 기억이 나군요. (Windows와 Linux를 동시에 쓰는데 한글이 당연히 깨지는것이 부지기수)

(제가 처음 접한 Mandrake Linux에선 커널 2.4에서 2.6으로 올라가고 유니코드로 변경되는 등의 격변기를 겪던 시절)

그래서 UTF-8을 쓰면 Unicode를 완비할수 있겠다는 생각을 하였죠. (그러나 정태영님의 글 "컴퓨터 속의 한글"을 보는 순간 역시 나는 꼬꼬마였구나를 알게 되었죠@.@) 

그러다 모 학회 서버를 관리하게 되었습니다. 하드디스크 문제가 생겨서 리눅스 설치후에 복구를 하니 이런 썅이라는 소리가 나오면서 인코딩 문제때문에 정말 애 먹었지요.

그당시 리눅스의 기본 설치는 UTF-8인데, 기존 자료들은 EUC-KR이니 당연히 안깨질리는 없구요.

iconv로 삽질 하고, MySQL덤프 뜬거 억지로 UTF-8에서 끼워 넣는 식으로 겨우 돌렸던 기억이 납니다.

그러다 2008년 Ruby, 2010년 Python를 공부하다 보니 인코딩이 특정 문자셋을 사용하여 문자열을 바이트열로 인코딩 하는 방식이 인코딩(Encoding)이라는 걸 그냥 알게 되더군요.

문자열과 문자셋, 유니코드 같은 건 많이 경험해보고, 삽질을 해보고, 직접 프로그래밍을 많이 해봐야, 이해를 쉽게 하게 되더군요.

말로만 들으면 왜 저렇게 해야하는지 이해를 못했다, 직접 부딫쳐봐야  Unicode, 문자셋, 인코딩의 개념를 제대로 알게 되더군요.

대학 1~3학년때 워낙에 문자 인코딩때문에 억수로 삽질을 한 덕택에 5단계까지 온듯 합니다.

6단계 Unicode에 여러 평면(plane)이나 카테고리(category), 스크립트(script) 등의 분류가 존재한다는 것을 알고 있다. UCD의 존재를 알고 있다.

와 7단계 Unicode전문가는 저도 잘 모르는 거라... (먼산)

아래는 블로그에서 썼던 문자 인코딩때문에 겪었던 삽질기록들 (대학 입학전에도 UTF-8의 존재는 알았고, 대학 2학년때 wchar_t로 사용했던 과거도 있는데 많이 쓴 기록은 없고, 있다는건 알았다 정도?)

2005/02/08 - [분류 전체보기] - [TIP]Gmail 사용시 한글이 깨질 때

2006/09/23 - [독서(讀書)] - 질렀습니다

2007/08/04 - [컴퓨터/DB] - MySQLdump할때 한글 깨짐 방지

2007/08/05 - [컴퓨터/DB] - 꼬인 DB를 복구 완료 및 셋팅중.

2007/08/06 - [컴퓨터/DB] - DB 문자셋을 통일 시켜버릴까?