C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

자유게시판
세상 살아가는 이야기들을 나누는 사랑방입니다.
[14143] 코드기어의 유니코드 지원 작업 상황 (The Unicode Shift)
홍환민.행복 [hhshhm] 2901 읽음    2008-03-25 16:45
안녕하세요? 홍환민입니다.

닉 하자스의 블로그에 "The Unicode Shift" 라는 제목으로 새 글이 포스팅되었더라고요.
3월 24일날 포스팅된거군요.

요즘 영어 공부중인데... 없는 영어 실력으로 다 읽었습니다. 뿌듯합니다 히히.

내용은, RAD Stduio 2008인 코드명 티뷰론(Tiburon)의 가장 큰 특징이
제대로 된 유니코드의 지원인데, 그 작업이 아주 순조롭게 진행되고 있다는 이야기입니다.

기존에 WideString이라고 2바이트 형태를 갖은 유니코드는 지원을 했지만,
유니코드의 인코딩 방식은 다양합니다. UTF-8이 가장 많이 쓰이는데, 이것도 지원안되고 있

죠.
그래서 유니코드 문자열에 어떤 인코딩으로 되어있는 유니코드 문자열인지를 식별할 수 있

는 정보와
실제 그렇게 인코딩된 문자열 데이터를 갖는... 진정한 유니코드 문자열을 지원하는 건데,
이게 UnicodeString 이라는 것입니다.

기본 문자열 타입인 string이 바로 이 UnicodeString이 사용될 것입니다.
다음과 같이 될거랍니다.

string = UnicodeString
Char = WideChar
PChar = PWideChar

다음과 같은 순서로 작업을 진행했다고 합니다.

1. 새로운 타입인 UnicodeString을 컴파일러가 지원하게 만들었고,
   기존이의 AnsiString 사용하듯이 매우 흡사하게 동작하도록 만들었습니다.
   기존의 델파이의 행보대로.. 호환성과 그로인해 기존 코드의 마이그레이션이
   그냥 다시 컴파일하는 정도로 하도록 노력을 하고 있는 것 같습니다.
   실제로도 외부 협력 업체의 제품 코드를 마이그레이션하는데 하루가 채 안 걸렸다고 합

니다.
   (얼마나 코드 수정 없이 가능할지는.. 실제로 나와봐야 알겠네요.)

2. RTL에 기본 문자열로 UnicodeString을 사용하게끔 수정하였습니다.
   또한 그로인한, UnicodeString을 다루기 위한 클래스와 함수들이 다수 추가되었습니다.
   컨버팅 관련 함수들도 많이 추가되었습니다.

3. 이 새로운 RTL을 이용해서 VCL에 적용하는 작업을 했습니다.
   VCL은 싱글 소스로 유지가 되어왔기 때문에, 그리고 VCL.NET에서 이미 유니코드가
   가능했기에, 이 작업은 굉장히 쉽게 끝났습니다.
 
4. 마지막으로, 유니코드가 지원되게 된 컴파일러, RTL, VCL로 IDE를 다시 컴파일하였습니

다.

결과적으로 근본적으로 유니코드를 지원하는 컴파일러와 RTL, VCL, IDE 환경을 구성할 수

가 있게 되었습니다.

흠... 확실히 제대로 유니코드를 지원하게 되네요.
새로 분사한 코드기어의 작업 방식이나 방향이 참 마음에 듭니다.
델파이로 델파이를 만든다는거 아시죠? 그게 이런 식의 작업에서도 빛을 발하는 것 같습니

다.

-------------------------------------------------
홍환민. http://www.wearethebest.co.kr
김상구.패패루 [peperu]   2008-03-25 17:29 X
개인적으로 가장 기대하고 있는 부분입니다.
한가지 첨언하고 싶은것은 WideString이 2byte방식의 Unicode인게 문제가 아니라 WideString이 UCS2 기반이란게 문제였습니다. 확장코드를 사용하는 경우 WideString은 제대로 대응하지 못하죠. 조금씩 흘러나오는 내용을 보건데 UnicodeString은 UTF-16LE를 선택한 것 같더군요. 윈도우와 동일한 방식입니다.
많은 분들이 WideString에서는 Leading Byte, Trail Byte같은거 신경 안쓰고 그냥 2byte단위로 읽으면 완벽하게 처리된다고 믿고 계시는 것 같던데... 그건 UCS2기반인 WideString에서만 맞는 이야기입니다. UnicodeString에서 UTF-16을 사용하는 이상, 잠재적인 오류 없이 프로그램을 작성하려면 마치 AnsiString에서 Leading Byte 검사하듯이 반드시 각 문자에 대해 영역검사를 해 줘야 하는데 이 부분을 볼랜드에서 어떻게 처리했는지가 가장 걱정되고 궁금합니다.
자칫하면... 마치 예전에 영어권 프로그래머들이 DBCS를 전혀 고려않고 프로그램을 만들어서 동양권 사용자를 물먹인 것 처럼... 우리도 똑같은 짓을 UCS2에 포함되지 않는 언어를 사용하는 마이너 국가의 사용자에게 할 가능성이 높아진다는 얘기죠.

이런 문제만 잘 풀렸다면... 새로운 UnicodeString은 Reference 기반이기 때문에 WideString과는 비교할 수 없을만큼의 속도를 보여주게 될겁니다.
망치 [mangchy]   2008-03-25 17:34 X
우와 드뎌 유니코드를 지원하는군요...기대되는군요
양용성 [ysyang]   2008-03-25 21:39 X
양용성 [ysyang]   2008-03-25 21:43 X
2008년 중순에 나올꺼라고 합니다.
엄청 기대됩니다.
컴파일로가 유니코드화 되면 그동안 유니코드 지원안되던 서드파티 컴포넌트들도
다시 컴파일만 하면 유니코드를 지원한다고 봐야 하는건지요?
홍환민.행복 [hhshhm]   2008-03-25 23:19 X
양용성// 기본 문자열이 unicode로 병경되었고 vcl과 rtl 루틴들이 다 유니코드 기반으로 변경되었으니까... 컴파일 다시하면 그렇게 되지 않을까요?
근데 소스코드 변경없이 바로 컴파일 될지는 모르겠네요...
DrK [whitekid]   2008-03-26 09:56 X
String을 말 그대로 문자열로 사용하고 있다면 크게 문제될 것 이 없을거라고 보는데.. 가끔 String을 메모리 버퍼로 사용하는 곳은 일일이 찾아 수정해줘야할 것 같네요..
박지훈.임프 [cbuilder]   2008-03-26 11:45 X
그렇죠, DrK님.
또, 스트링의 길이를 바이트 단위로 간주한 코드는 몽땅 다 수정해줘야 할 듯.
의외로 일이 클 수도 있겠습니다.

+ -

관련 글 리스트
14143 코드기어의 유니코드 지원 작업 상황 (The Unicode Shift) 홍환민.행복 2901 2008/03/25
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.