string으로 선언된 데이터 타입들은 이제 UnicodeString으로 사용됩니다. 또, Char 타입은 WideChar으로, PChar 타입은 PWideChar으로 사용됩니다. 명시적인 PAnsiChar, AnsiString, PWideChar, WideString은 유지됩니다.

이 변경에 의해 검토할 사항은, 코드상에서 string과 AnsiString 또는 PAnsiChar를 혼용해서 사용하는 코드를 검토하고 수정해야 합니다. string과 AnsiString 또는 PAnsiString을 혼용해 사용하는 경우 데이터 크기의 차이에 따라 데이터 손실이 발생할 수 있습니다. 자세한 내용은 “문자열의 메모리 크기 변경” 항목을 참고하시기 바랍니다.

대표적으로 검토해야 할 항목은 다음과 같습니다.

1, UnicodeString과 AnsiString을 혼용해서 사용하는지 검토

2, 데이터 형변환 시 데이터 타입 검토

3, 윈도우 API 호출하는 코드 검토

4, 외부 라이브러리(DLL 등) 인터페이스 검토

5, 데이터베이스 캐릭터셋 검토

UnicodeString과 AnsiString을 혼용해서 사용하는 경우

string 변수를 AnsiString 변수에 할당하는 경우 데이터 손실이 발생할 수 있습니다.

데이터 형변환(Type Casting) 시 데이터 타입 검토 

PChar(PWideChar)로 형변환 시 string(WideString)을 전달, PAnsiChar로 형변환 시 AnsiString으로 전달해야 합니다. 만약, PAnsiChar(string)와 같이 형변환 시 string 변수의 첫글자만 전달될 수 있습니다.

윈도우 API 호출하는 코드 검토

문자열을 다루는 대부분의 윈도우 API는 AnsiString과 WideString용 API를 제공합니다. 델파이는 AnsiString과 WideString외에도 기본 문자열 캐릭터셋(string)을 제공합니다. 즉, string이 AnsiString에서 WideString으로 변경됨에 따라 윈도우 API도 WideString용 API를 사용하게 됩니다.

코드상에서 문자열 포인터를 만들어 전달 시 AnsiString 기반의 캐릭터를 이용할 경우 AnsiString용 API를 사용하도록 코드를 변경해야 합니다. 

다음과 같이 데이터 타입에 맞도록 문자열 포인터를 만들어 전달해야 합니다.

외부 라이브러리(DLL 등) 인터페이스 검토

외부 라이브러리(DLL)와 문자열을 주고 받을 경우 다음 경우에 따라 조치하기 바랍니다.

* 델파이로 직접 DLL을 제작한 경우

  - DLL의 export 메소드의 문자열 포인터 데이터 타입을 PChar 또는 PWideChar로 변경 후 다시 빌드해 사용합니다.

* DLL을 직접 제작하지 않은 경우

  -DLL에서 유니코드 지원 메소드를 제공하는지 확인합니다.

  - 만약, 제공하지 않는다면, DLL 인터페이스를 참고해 PAnsiChar 로 DLL Export 메소드의 데이터타입을 변경하고, PAnsiChar(AnsiString(string))와 같이 형변환해 데이터를 전달합니다.
    (이 경우 DLL로 전달하거나, 전달받는 문자열은 유니코드를 제공하지 않습니다.)

데이터베이스 캐릭터셋 검토

데이터베이스 연결 시 한글이 정상표시되는지 확인해야합니다.

만약, 한글이 정상표시되지 않는다면 연결설정의 캐릭터셋을 Unicode 또는 UTF8로 설정하기 바랍니다.

만약, FireDAC을 이용한다면, MapRules을 통해 AnsiString을 WideString으로 적용하는 규칙을 추가할 수 있습니다.

자세한 내용은 http://tech.devgear.co.kr/429974 링크를 참고하세요.

문자열 길이의 변경

UnicodeString 기반의 문자열의 길이는 문자의 종류와 관계없이 모두 1로 계산됩니다. AnsiString 기반의 문자열은 한글등의 멀티-캐릭터셋 문자의 경우 2로, 영문자/숫자/특수문자의 길이는 1로 계산됩니다.

문자열 데이터 크기의 변경

UnicodeString 기반의 문자열은 모든 문자가 2Byte의 메모리를 사용합니다. 

이제 더 이상 문자열의 길이와 문자열의 데이터 크기가 일치하지 않습니다. UnicodeString 문자열의 데이터 크기를 계산하려면 문자열의 길이 * SizeOf(Char)로 계산해야 합니다.

이 변경으로 검토할 대표적인 항목은 다음과 같습니다.

1. 문자열 길이와 데이터크기가 같다고 간주한 코드
2. Char 크기를 1로 간주해 길이를 직접 입력한 코드

검토해야하는 대표적인 키워드

잠재적으로 수정될 필요가 있을 수 있는 코드

•  “of Char” 텍스트와 “of AnsiChar” 텍스트를 검색하여 버퍼가 유니코드에 맞게 사용되었는지 확인합니다. 
•  “string[” 텍스트를 검색하여 스트링 인덱스의 문자가 대입되는 변수가 Char(즉 WideChar)가 아닌 AnsiChar 타입 변수로 지정되도록 수정합니다. 
•  “AnsiString”, “AnsiChar”, “PAnsiChar”를 명시적으로 지정한 부분을 찾아 그럴 필요가 있고 제대로 되어 있는지 확인합니다. 
•  “ShortString”을 명시적으로 지정한 부분을 찾아 그럴 필요가 있고 제대로 되어 있는지 확인합니다. 
•  “Length(” 텍스트를 검색하여 Length가 SizeOf와 동일한 의미로 사용되지는 않았는지 확인합니다. 
•  “Copy(” , “Seek(” , “Pointer(” , “AllocMem(”, “GetMem(” 텍스트를 검색하여 스트링 혹은 문자 배열에 대해 제대로 동작하는지 확인합니다.

• [바로가기] 유니코드 분석 도구 : 유니코드 적용을 검토할 영역을 분석해 줍니다.

위에서 설명한 각 키워드별 조치방법을 아래의 문서에서 찾아보시기 바랍니다.

 - [바로가기] 데브기어-마이그레이션-이슈공유 문서 보기

위 문서에도 원하는 답이 없다면 개발자 Q&A에서 검색 후, 결과가 없다면 질문을 등록해 다른 개발자들의 도움을 받아보시기 바랍니다.

 - [바로가기] 데브기어 개발자 Q&A

•  데브기어 마이그레이션 업그레이드 센터 : http://www.devgear.co.kr/rad-in-action/migration-upgrade-center/
•  엠바카데로 기술문서
   - Unicode in RAD Studio : http://docwiki.embarcadero.com/RADStudio/Seattle/en/Unicode_in_RAD_Studio 
   - Enabling Applications for Unicodes : http://docwiki.embarcadero.com/RADStudio/Seattle/en/Enabling_Applications_for_Unicode
•  볼랜드 포럼에 박지훈님이 번역한 닉 하지스의 델파이의 유니코드 지원 Part 1 ~ 3

   - 델파이의 유니코드 지원 Part I: 유니코드란 무엇이며, 왜 필요하며, 어떻게 쓸 것인가

    : http://www.borlandforum.com/impboard/impboard.dll?action=read&db=del_tutorial&no=135

   - 델파이의 유니코드 지원 Part II: 유니코드 지원을 위한 새 RTL 기능들과 클래스들

    : http://www.borlandforum.com/impboard/impboard.dll?action=read&db=del_tutorial&no=136 

   - 델파이의 유니코드 지원 Part III: 기존 코드의 수정

    : http://www.borlandforum.com/impboard/impboard.dll?action=read&db=del_tutorial&no=137