'로마자' 태그의 글 목록

2010. 2. 24. 00:34

Resize Browser v1.04 프로그램은 ASPack으로 압축되어 있어서 한국어화에 어려움이 있었습니다. 또한 메뉴나 사용법도 간단해서 한글화를 하지 않으려 했지요. 그런데 어제 쓸 만한 ASPack 압축 해제기(unpacker)를 구하게 되어, 넘어진 김에 쉬어간다고 한국어화를 끝내버렸습니다. 프로그램 전체는 아니고, 메뉴나 기타 메시지만 쓸 만큼, 불편하지 않을 만큼만 한국어로 고쳐 보았습니다.

한국어로 바꾸기 전

Resize Browser v1.04 실행 화면 : 영어/로마자

위 그림에서 윗부분에 나타난 것이 프로그램 실행 화면이고, 아랫부분의 메뉴는 트레이 메뉴입니다. 둘 다 한글이 아닌 로마자(영문자)로 나타나 있습니다.

한국어로 바꾼 뒤

Resize Browser v1.04 실행 화면 : 한국어/한글

메뉴를 대충 한글로 바꾸었습니다.

옵션 한국어화

번역 및 편집 방법

압축 해제

이 프로그램은 ASPack으 로 압축되어 있습니다. 따라서 메시지를 고치려면 우선 압축을 풀어야 합니다. 그러나 줄곧 쓸 만한 압축 해제기, 곧 언팩커(unpacker)를 구하지 못했습니다. 가장 유명한 것으로 ASPackDie가 있는데, 너무 오래되어 대부분 압축을 정확하게 해제하지 못했습니다. 그러다가 AsPack Unpacker (AbstersiverA)라는 글에서 압축 해제기를 구할 수 있었습니다. 다운로드 링크는 제가 제공하지 않으므로, 그 블로그에서 파일을 다운로드하여 압축을 풀기 바랍니다.

압축 해제에 관해서는 AsPack Unpacker (AbstersiverA) 사용법 문서를 참조하십시오.

메뉴 한글화

따로 언어 파일이 없으므로 프로그램 파일은 리소스 편집기(리소스 해커 등)로 직접 편집해야 합니다.

리소스 해커로 메시지 편집 및 한국어화

주로 번역할 부분은 RCData 부분입니다. 이것이 실제로 화면에 보이는 메뉴 등의 메시지이기 때문입니다.

번역하지 않는 메시지

한편 String Table 부분은 번역하지 않았습니다. 일단 그 부분이 언어 중립적(LANG_NEUTRAL, SUBLANG_NEUTRAL)인 메시지, 곧 에러 메시지 등을 포함하고 있기 때문입니다. 게다가 오류가 발생하는 등 특정 상황이 생기지 않으면 볼 일이 거의 없는 메시지이기도 하기 때문입니다.

재압축

용량을 줄이기 위해 다시 압축했습니다. 다만 ASPack을 이용하지 않고 UPX를 이용했습니다. 압축까지 끝나면 작업이 모두 끝납니다.

원본 : 334,848 바이트
압축 해제 : 872,960 바이트
UPX 압축 : 307,712 바이트

다운로드

작업한 파일을 압축하여 올렸습니다.

압축 해제 파일 (ZIP / 393,566 바이트)
UPX 압축 파일 (ZIP / 300,786 바이트)
리소스 압축 파일 (ZIP / 89,208 바이트) : 압축을 풀어 resize.rc를 참조하기 바랍니다.

Double Commander 한국어 언어 파일 (0)	2010.04.09
AVI-Mux GUI 한국어화 (0)	2010.03.21
MozBackup v1.4.10 한국어 언어 파일 (0)	2010.02.12

MozBackup v1.4.10 한국어 언어 파일

소프트웨어/한국어화

2010. 2. 12. 02:20

MozBackup을 사용하다 보면 한국어 언어 파일을 적용하더라도 한글로 나타나지 않는 부분이 많아서 아쉬움을 느낄 때가 있습니다. 이는 한국어 언어 파일이 MozBackup 1.4.6 버전에 맞추어 작성된, 상당히 오래된 버전이기 때문에 나타난 현상입니다. 그에 따라 기존 파일을 받아다가 새롭게 고쳤습니다.

한국어로 바꾸기 전

한국어화라는 말을 잘 쓰지 않습니다. 하지만 이것이 공식 용어입니다. 우리는 흔히 한글화라고 부르지요.^[각주:1]

각설하고, MozBackup의 번역 페이지에서 이미 한국어로 번역한 파일을 받아다가 수정하기로 했습니다.

MozBakcup 번역 페이지

MozBakcup 번역 페이지 화면에 보면, 이미 두 분(Jeong Wonho & Gabriel, Park)이 번역에 참여하셨습니다. 저는 저 두 분이 번역한 Default.lng 파일을 편집했습니다.

MozBackup 실행 화면 - 영어/로마자

한국어로 바꾼 뒤

MozBackup 실행 화면 - 한국어/한글

번역 및 편집 방법

Default.lng 파일은 압축 파일 안에 들어 있습니다. 텍스트 파일이므로 압축을 푼 뒤에 Default.lng 파일을 편집하면 됩니다.

편집 중인 Default.lng 파일

다운로드

번역 페이지에서 받은 Default.lng 파일을 편집한 파일은 다음과 같습니다.

.ZIP 압축 파일 (3,542 B)
.LNG 파일 (13,449 B)

Double Commander 한국어 언어 파일 (0)	2010.04.09
AVI-Mux GUI 한국어화 (0)	2010.03.21
Resize Browser v1.04 메뉴 한국어화 (0)	2010.02.24

ᄒᆞᆫ글2010 베타버전과 유니코드 3 - Unicode Full Set 지원??

벌레와 팁/버그

2010. 1. 28. 12:42

한컴오피스 베타버전 버그 27 - 유니코드 버그 3 및 글꼴 버그 1 - Unicode Full Set 지원??

ᄒᆞᆫ글2010 베타버전에서는 Unicode Full Set을 지원한다고 밝히고 있습니다. 자세한 사항은 한컴오피스2010 오픈베타 홈페이지에 있는 기능 설명서를 다운로드하여 읽어보기 바랍니다. 그런데 이때 Unicode Full Set은 무엇을 뜻할까요? 2009년 10월 1일 발표한 최신 유니코드 5.2일까요? 그게 아니라면 2008년에 발표한 유니코드 5.1? 2006년 발표한 5.0? 그게 아니면…? 저는 적어도 유니코드 5.0은 지원하리라 생각했습니다. 왜냐하면 한컴오피스2007이라는 제품이 있었기 때문입니다. 그런데 아니더군요. ᄒᆞᆫ글2010 베타버전은 유니코드 4.1도 제대로 지원하지 않았습니다.

벌레의 유형

ᄒᆞᆫ글 씨! ᄒᆞᆫ글에서 지원한다는 유니코드 버전 좀 알려주면 덧납니까? 사용자가 ᄒᆞᆫ글 프로그램에서 지원하는 유니코드 버전을 알기 위해 그 고생을 하도록 합니까?

개발자의 답변

2010년 1월 28일 버그 리포팅을 한 상태입니다.

벌레의 발견

일단 나는 한글 자모 영역만을 살펴보고는 ᄒᆞᆫ글2010 및 한컴오피스2010 베타에서 유니코드 5.2 또는 유니코드 5.1을 지원한다고 믿고 말았다. 조금만 더 신경을 썼더라면 전혀 그렇지 않음을 알았을 텐데, 지금 생각하면 참 어리석었습니다.

유니코드 지원이란?

유니코드 지원은 크게 두 가지로 나뉩니다. 하나는 유니코드 코드표를 지원한다는 뜻입니다. 다른 하나는 유니코드를 화면에 나타낼 수 있게 한다는 뜻이지요. 워드프로세서를 제외한 오피스 프로그램이라면 당연히 코드표만 지원하면 완벽한 지원으로 볼 수 있습니다. 그러나 워드프로세서는 사정이 다릅니다. 코드표로는 아무런 의미도 없기 때문입니다. 워드프로세서란 문서를 실제로 출력해 주어야만 그 기능이 완성된다는 점에서 보면 ᄒᆞᆫ글2010은 유니코드를 제대로 지원하지 못하고 있습니다.

'한컴오피스의 유니코드 지원'을 말한 사람은?

이런 헛소문을 퍼뜨린 사람이 누구인지를 검색해 보았습니다. 검색하다가 보니 제 블로그가 상당히 많이 눈에 띄더군요. 헛!

각설하고 우선 한글과컴퓨터 한컴오피스2010 오픈베타 홈페이지에서 그 헛소리를 발견했습니다. 오호 애재라!

Unicode Full Set 지원? 정말??

저처럼 눈 나쁜 사람을 위해 그 부분만 잘랐습니다.

함초롬돋움과 함초롬바탕 글꼴이 가독성과 미려함이 좋습니다. 하지만 Unicode Full Set을 지원하지는 않습니다. 검증은 아래에서 하기로 하고 다른 웹페이지도 살펴보죠.

베타뉴스의 한컴오피스 2010 Beta 설명에서도 Unicode Full Set을 지원한다고 그러네요.

베타뉴스에 나타난 Unicode Full Set을 지원 글귀

조금 다른 기사도 있습니다. 이투데이의 한컴, 오피스시장 점유율 20%에 도전한다라는 기사인데, 여기에 유니코드 글꼴에 대한 내용이 나옵니다.

함초롬체를 직접 언급한 이투데이 기사

이렇게까지 언론에서 말할 정도라면… 애초에 Unicode Full Set 지원을 말한 사람은 한글과컴퓨터사라는 뜻이겠죠? 더구나 유니코드를 지원하는 글꼴은 한컴오피스2010 베타에서 새롭게 제공하는 함초롬체라는 뜻이고요. 그렇지 않습니까?

'한컴오피스의 유니코드 지원'은 Unicode Full Set일까?

'한컴오피스의 유니코드 지원'은 Unicode Full Set일까요? 유감스럽게도 최신 버전은 아닙니다. 다시 말해 유니코드 5.2를 Full Set으로 지원하지는 않는다는 뜻입니다.

이것은 위키백과의 한컴 2바이트 코드 문서에 나타난 사항을 검증하면서 발견하였습니다(ᄒᆞᆫ글2010 베타버전과 유니코드 버그 1 및 문자표 버그 1 참조). 그 글에서 밝혔듯이, 이 문자표와 관련한 사항은 또 다른 판도라 상자였습니다.

위키백과의 한컴 2바이트 코드 문서에서 틀린 점을 발견했는데, 그 부분 덕분에 이 버그를 발견하게 되었습니다.

위키백과의 한컴 2바이트 코드 문서의 마지막 부분

위 화면에서 빨간색 네모로 묶은 부분은 틀린 내용입니다. 그래서 [출처 필요]라는 출처를 요구하는 태그가 붙어 있습니다(제가 붙였습니다. ^.^v). U+470C의 한자는 䜌이며, 이것은 유니코드 5.2에서 옳은 표기입니다. 여기에서 중요한 부분은 또 다른 유니코드 번호인 U+9FBB와 그 아래에 파란 밑줄 부분입니다. U+9FBB에 해당하는 한자가 나타나지 않았는데, 이는 화면 글꼴인 굴림 글꼴에 저 번호에 해당하는 글자가 없기 때문입니다. 다르게 말하면, 아니 조금 심하게 말하면, 굴림 글꼴은 유니코드를 제대로 지원하지 못하는 글꼴이라는 말이 됩니다. 그렇다면 ᄒᆞᆫ글은 저것을 잘 나타낼까요? 파란 밑줄 부분이 사실이라면 저 한자는 나타낼 수 없습니다.

일단 유니코드 문자표는 없나요? 문서에서 부수별 한자 색인 목록이 있는 PDF 파일(RSIndex.pdf 파일)을 아도비 리더에서 불러오겠습니다.

어도비 리더에서 불러온 부수 색인 파일 136쪽의 400% 확대 화면

그런데 U+470C 문자와 U+9FBB 문자가 서로 모양이 같습니다. 다만 U+9FBB가 지나치게 위로 치우쳐 있습니다. 이런 경우는 저 문자가 실제로 문자로 쓰이는 게 아니라, 다른 문자의 일부로써 쓰일 때 주로 나타나는 현상입니다.

실제 문자표 파일(CodeCharts-MulticolHan.pdf 파일)에서는 어떻게 나타나는지 살펴봅시다.

어도비 리더에서 불러온 한자 파일 747쪽 제1단의 200% 확대 화면

U+9FBB가 지나치게 위로 배치되어 있습니다. 그런데 그 앞에 나온 문자들도 만만치 않습니다. 위로 치우치거나 왼쪽으로 치우쳐 있습니다. 이 말은 이 문자들이 정상적인 글자로 쓰이지 않고 다른 용도로 쓰인다는 추측을 가능하게 합니다. 이는 곧 위키백과의 한컴 2바이트 코드 문서의 마지막 부분 그림에 나타난 빨간 네모 안의 내용이 틀렸다는 근거이기도 하지요.

이제 앞서 언급한 ᄒᆞᆫ글이 저 문자를 잘 나타내는지를 살펴보겠습니다. 위키백과의 한컴 2바이트 코드 문서의 마지막 부분 그림의 파란 밑줄 부분이 사실이라면 저 한자는 나타낼 수 없고, 그것이 거짓이라면 나타낼 수 있어야 합니다.

문자표를 불러 유니코드 문자표 탭에서 9FBB를 찾습니다.

ᄒᆞᆫ글2010의 문자표에서 나타나지 않은 U+9FBB 코드 포인트

ᄒᆞᆫ글2010의 문자표는 코드 포인트 U+9FBB에 해당하는 글자를 나타내지 못하고 있습니다.
이때 코드 포인트는 흔히 코드 값으로 부르는 것의 정식 명칭인데, 유니코드에서 다른 글자와 겹치지 않는 그 글자만의 고유값을 가리킵니다. 현재까지 유니코드에 배정된 코드 포인트는 모두 111만4112개입니다.

단순히 글꼴에서 표시해 주지 못할 뿐이라는 생각도 할 수 있습니다. 하지만 저 문자표의 글꼴은 현재 커서가 놓인 곳의 글꼴을 따르게 되어 있습니다. 그리고 지금 커서가 놓인 곳은 글꼴은 함초롬돋움 글꼴입니다.

현재 글꼴은 함초롬돋움

아, 함초롬돋움과 함초롬바탕은 다를 수 있다고요? 그럼 바꿔 보겠습니다.

현재 글꼴은 함초롬바탕

글꼴은 바뀌어도 U+9FBB 코드 포인트의 글자는 나타나지 않습니다.

그렇다면 다른 글꼴도 시험해 보겠습니다. 유명한 셰어웨어 유니코드 글꼴인 Code2000로 바꾸겠습니다. 물론 함초롬체도 유니코드 글꼴입니다.

한글이 밉게 나와서 자주 쓰지 않는 Code2000 글꼴

참고로 저는 아직 Code2000 라이선스를 갖고 있지 않습니다. 다시 말해 비등록 사용자인 셈이지요. 이 글을 쓰기 위해 다운로드해서 설치했습니다.

Code2000 글꼴로 바꾼 뒤 잘 나타나는 코드 포인트 U+9FBB의 글자

위 그림에서 자주색 테두리를 친 부분은 유니코드 4.1에서 추가된 부분입니다. 다시 말해 2005년 3월 31일에 이미 유니코드 표준이 된 글자입니다. 그렇다면 이투데이 기사의 내용대로 함초롬체 개발에 2년이 소요되었더라도 이미 추가했어야 할 글자라는 뜻입니다. 참고로 파란색 테두리를 두른 부분은 유니코드 5.1에서 추가된 부분입니다.

한자의 모양을 화면에 나타내지 못한다고 해서 유니코드를 지원하지 않는다는 말은 잘못되었다는 의견도 있을 수 있습니다. 그러나 저 글자 가운데 어떤 글자도 ᄒᆞᆫ글의 한자 사전에서 음과 훈, 한어병음 가운데 어느 하나도 나타나 있지 않습니다. 물론 음과 훈은 정해져 있지 않고, 한어병음도 정해져 있지 않을 수 있습니다. 그러나 단 하나, 정해져 있는 것이 있습니다. 바로 획수입니다.^[각주:1]

획수조차 나타나지 않는 한자 사전

도대체 무엇을 근거로 Unicode Full Set을 지원한다는 말을 했을까요?

벌레 분석

Unicode Full Set을 지원한다는 말은 그저 광고 문구로만 볼 수 없습니다. 상당히 많이 기대한 ᄒᆞᆫ글의 유니코드 지원이지만, 결과적으로 한글 자모만의 지원이라는 생각이 듭니다. 물론 한국에서 개발한 프로그램이므로 한글 자모만 지원되어도 충분할 수 있습니다. 그러나 그것이 Unicode Full Set 지원을 뜻하지는 않는다고 생각합니다.

한컴오피스 베타버전과 함초롬 글꼴의 모양 (2)	2010.01.31
ᄒᆞᆫ글2010 베타버전과 옛한글 표기 오류 (0)	2010.01.30
2010년 1월 27일자 Yslow 발표 (0)	2010.01.27
ᄒᆞᆫ글2010 베타버전과 유니코드 버그 2 및 문자표 버그 3 (0)	2010.01.27
2010년 1월 26일자 Yslow 문제 (0)	2010.01.26

ᄒᆞᆫ글2010 베타버전과 유니코드 버그 2 및 문자표 버그 3

벌레와 팁/버그

2010. 1. 27. 00:24

한컴오피스 베타버전 버그 26 - 유니코드 버그 2 및 문자표 버그 3

ᄒᆞᆫ글2010 베타버전을 사용하다 보니 문자표와 관련하여 이해하기 힘든 동작을 발견했습니다. 뭐, 문자표와 관련한 벌레 가운데 이해할 수 있는 벌레가 하나도 없었지만요.
게다가 이 벌레는 가장 먼저 발견(2009년 12월 30~31일경 발견)했음에도 그 벌레 발생의 규칙성을 알지 못해서 버그 리포팅을 하지 못하고 있었습니다.

벌레의 유형

ᄒᆞᆫ글 씨! 똑같은 글자이건만, 앞서 불러온 문자에 따라, 다르게 취급할 필요가 있나요? 그리고 유니코드 4자리에게서 안 나타나는 벌레가 왜 유니코드 5자리에서 나타나서 사람을 괴롭히게 만들어요?

개발자의 답변

2010년 1월 26일 버그 리포팅을 한 상태입니다.

벌레의 발견

이 벌레의 증명에는 동영상을 사용하지 않기로 했습니다. 글쇠 하나만 잘못 눌러도 ᄒᆞᆫ글에서 이 벌레를 만날 수 없습니다. 결국 ᄒᆞᆫ글 프로그램을 다시 실행해야 했습니다. 뭐 지금은 정확하게 이 벌레를 나타나게 만들 수 있지만 조금 귀찮습니다. 또한 동영상이 없어도 설명하는 데는 지장이 없습니다.

그리고 이 벌레는 앞서 설명했듯이 4자리의 유니코드에서는 나타나지 않습니다. 또한 이전에 사용했던 유니코드 문자가 5자리 이상이라면 이 벌레는 나타나지 않습니다.

준비 : 이전에 사용한 문자표의 문자 영역 재설정

아무 문자, 특히 영문자(로마자; 라틴 문자)나 숫자를 골라서 영역을 설정한 뒤에 문자표를 부릅니다. 이때 영역(블럭)을 설정의 방향은 상관이 없습니다. 이전에 사용한 문자표의 문자 영역 재설정하는 작업이 이 벌레를 발견하는 데에 매우 중요합니다.

예제 문서와 작업 준비 화면

이전에 사용한 문자 및 문자 영역을 재설정

위와 같은 화면에서 화면에 보이는 숫자 가운데 하나를 블럭 지정하여 문자표를 불렀습니다(단축키는 Ctrl+F10). 참고로 예제 문서는 Unicode-Test-2.hwp입니다.

앞서 입력한 문자가 유니코드 4자리일 때

이번 테스트에 이용할 문자는 준비 화면에서 보이는 한자들입니다.

한자에 커서를 두고 블럭 설정

위 그림처럼 한자 앞에 커서를 두고 블럭을 설정합니다. 이미 앞서 문자표로 불러왔던 문자의 유니코드 번호가 4자리였습니다.^[각주:1]

블럭 설정

위 그림처럼 블럭을 설정한 뒤 문자표를 불러옵니다. 단축키 사용해 주십시오. 지난번 그 벌레가 나오면 감당 못합니다. 단축키는 Ctrl+F10입니다.

유니코드 번호가 0208?? 설마?

저 번호가 맞다고 생각하지는 않겠죠? 참고로 U+0208의 문자는 다음과 같습니다.

라틴 확장-B 문자 영역에 나타난 U+0208

어이, ᄒᆞᆫ글 씨! U+0208는 한자가 아니라 라틴 확장-B라는데요.

앞서 입력한 문자가 유니코드 5자리 이상일 때

앞서 입력한 문자가 유니코드 5자리 이상인 상황은 만들기 쉽습니다. 그냥 한자에 커서를 두고 블럭 설정 화면에 보이는 한자를 골라 문자표를 두 번 연속으로 불러 내면 됩니다.

정상적으로 출력된 유니코드 번호

거참, 처음부터 이렇게 제대로 나오면 좀 좋습니까?

벌레 분석

무슨 까닭에서인지 맨 처음에 유니코드 번호 다섯 자리 이상인 문자를 제대로 인식하지 못한 듯싶습니다.

ᄒᆞᆫ글2010 베타버전과 유니코드 3 - Unicode Full Set 지원?? (3)	2010.01.28
2010년 1월 27일자 Yslow 발표 (0)	2010.01.27
2010년 1월 26일자 Yslow 문제 (0)	2010.01.26
ᄒᆞᆫ글2010 베타버전의 문자표 버그 2 (0)	2010.01.24
ᄒᆞᆫ글2010 베타버전과 유니코드 버그 1 및 문자표 버그 1 (0)	2010.01.23

ᄒᆞᆫ글2010 베타버전의 문자표 버그 2

벌레와 팁/버그

2010. 1. 24. 21:40

한컴오피스 베타버전 버그 25 - 문자표 버그 2

ᄒᆞᆫ글2010 베타버전과 유니코드 버그 1 및 문자표 버그 1 문서를 작성하며 ᄒᆞᆫ글2010 베타버전에서 검증하는 과정에서 문자표와 관련한 황당한 동작을 발견했습니다.

벌레의 유형

ᄒᆞᆫ글 씨! 똑같은 문자표 아이콘이건만, 왜 때와 장소에 따라 역할이 달라지나요? 언제나 변치 않는 녀석이 더 좋답니다.

개발자의 답변

2010년 1월 25일 버그 리포팅을 한 상태입니다.

벌레의 발견

일단 동영상 두 개를 보고 나서 설명하겠습니다.^[각주:1]

위 동영상(사례 1)은 ᄒᆞᆫ글 아래에 다른 프로그램이 없는 경우입니다.

위 동영상(사례 2)은 ᄒᆞᆫ글 밑에 다른 프로그램이 있는 경우입니다.

아무튼 두 경우 모두 리본 메뉴가 완전히 나타난 상태에서만 정상 작동하고, 리본 메뉴가 접힌 상태에서 메뉴를 클릭하여 임시로 펼쳤을 때에는 약간 이상한 동작을 하였습니다.

사례 1 살펴보기

일단 ᄒᆞᆫ글에서 한 글자를 선택하여 범위를 지정하고 문자표 보기(단축키는 Ctrl+F10)를 합니다. 그러면 범위를 지정한 글자를 문자표에서 찾아줍니다. 그런데 이 작업을 마우스로 아이콘을 클릭하거나 메뉴의 항목을 클릭함으로써 작동시켜 보았더니 위의 동영상에 나타난 벌레가 나타나더군요.

일단 앞서 다운로드한 그 문서(Unicode-Test-1.hwp)를 이용하여 봅시다. 아니면 직접 만들어서 시험해도 됩니다.

ᄒᆞᆫ글 아래에 아무것도 없는 상태

위 그림처럼 ᄒᆞᆫ글이 최상위에 위치한 경우의 반응을 먼저 보겠습니다.

리본 메뉴를 접은 상태에서 한 글자를 블럭 지정

위와 같이 한 글자를 블럭 지정합니다. 그 뒤에 입력 메뉴로 마우스를 가져갑니다.

입력 메뉴의 마우스를 가져가기 전 모습

입력 메뉴의 마우스를 가져가져간 뒤의 모습

입력 메뉴 확대

위의 확대 그림에서 1번 쪽(글자 부분)을 클릭하면 리본 메뉴가 임시로 나타나고, 2번 쪽(▼ 표시 부분)을 클릭하면 풀다운 메뉴가 나타납니다.

리본 메뉴를 접은 상태에서 메뉴를 클릭하여 임시로 리본 메뉴를 불러온 화면

위 그림에 나타난 바와 같이, (1) 1번 쪽(글자 부분)을 클릭하여 리본 메뉴를 임시로 불러오고, (2) 문자표 아이콘의 아랫부분에 있는 문자표라는 글자를 클릭합니다. 아래 그림에서는 2번의 화살표가 가리키는 곳입니다. 실수로 1번의 아이콘을 클릭하면 문자표를 이용하여 입력했던 맨 마지막 문자(그림에서는 네모로 표시된 j자 비슷한 모양인데, 이는 U+01D457 ^[각주:2]에 해당한다.)를 입력하게 되므로 조심해야 합니다.

문자표 글자를 클릭

(3) 마지막으로 맨 아래에 보이는 문자표...라는 부분을 클릭합니다.

위와 같은 과정을 거쳐서 정확히 실행했다면 문자표가 한 번 나타났다가 번개처럼 사라지는 희한한 현상을 목격할 수 있습니다.

문자표 글자를 클릭한 뒤 약간의 변화가 생기고 나서 마지막에 나타나는 화면

그밖에 다른 점이 하나 더 있습니다.

문자표를 실행하기 전 제목 표시줄

문자표를 실행한 뒤 제목 표시줄

제목 표시줄의 글자가 문자표를 실행하기 전에는 진하고 밝은 색이었습니다. 그런데 문자표를 실행한 뒤에는 연하고 어두운 색으로 바뀌었습니다.

이는 ᄒᆞᆫ글2010 프로그램 창이 마우스 포커스를 잃어버렸음을 뜻합니다. 다르게 말하면, 활성 상태의 ᄒᆞᆫ글2010 창이 비활성화되었음을 뜻합니다. 쉽게 말하면, ᄒᆞᆫ글 프로그램 창의 상태가 작업 중에서 작업 중이 아닌 상태로 바뀌었다는 뜻이지요.

참고 : 위의 과정에서 한 문자를 블럭으로 지정할 필요는 없습니다. 위의 과정은 이 벌레를 발견한 과정을 재현하기 위해 블럭을 지정했으며, 블럭 지정을 하지 않아도 이 벌레는 나타납니다.

사례 2 살펴보기

사례 2에서는 ᄒᆞᆫ글 프로그램 창 아래에 다른 프로그램 창이 존재할 경우입니다. 이 경우도 앞서 말한 대로 굳이 글자에 블럭을 지정할 필요는 없습니다.

문자표를 부르기 직전

문자표를 부른 뒤 포커스를 잃는 도중!

잠시 후 포커스를 완전히 잃어버린 ᄒᆞᆫ글 창

잠시 그대로 놔두자 포커스를 완전히 잃어버리고, ᄒᆞᆫ글 창 아래에 있던 메모장2(Notepad2) 프로그램이 마우스 포커스를 가져갑니다.

벌레 분석

무슨 이유에서인지 모르겠으나, 리본 메뉴가 활성 상태가 아닌, 임시로 리본 메뉴를 불러온 상태에서는 문자표를 정상적으로 호출하지 못한다고 여겨집니다. 아울러 문자표를 정상적으로 불러오지 못한 경우에는 문자표의 포커스 상태(또는 Z인덱스 상태)가 아닌 ᄒᆞᆫ글 프로그램 창의 포커스 상태(또는 Z인덱스 상태)를 수정해 버린다고 여겨집니다.

ᄒᆞᆫ글2010 베타버전과 유니코드 버그 2 및 문자표 버그 3 (0)	2010.01.27
2010년 1월 26일자 Yslow 문제 (0)	2010.01.26
ᄒᆞᆫ글2010 베타버전과 유니코드 버그 1 및 문자표 버그 1 (0)	2010.01.23
굵은 은 돋움 글꼴의 옛한글 조합 버그 (2)	2010.01.22
한컴사전에 나타난 이상한 하이픈 (0)	2010.01.18

ᄒᆞᆫ글2010 베타버전과 유니코드 버그 1 및 문자표 버그 1

벌레와 팁/버그

2010. 1. 23. 23:18

한컴오피스 베타버전 버그 24 - 유니코드 버그 1 및 문자표 버그 1

ᄒᆞᆫ글2010 베타버전을 사용하다 보니 문자표와 관련하여 이해하기 힘든 동작을 발견했습니다.

벌레의 유형

ᄒᆞᆫ글 씨! 문자표에서 16진수 6자리로 이루어진 유니코드 번호는 나타낼 수 있어도 입력은 안 됩니까? 입력도 되게 하면 안 되겠니?

개발자의 답변

2010년 1월 23일 버그 리포팅을 한 상태입니다.

벌레의 발견

위키백과의 한컴 2바이트 코드^[각주:1] 문서에 나타난 사항을 검증하면서 발견하였습니다. 검증 과정에서, 이 문자표는 또 다른 판도라 상자일 수도 있다는 점을 알게 되었습니다.

문자 코드의 코드 번호 붙여넣기 및 직접 입력

문자 코드의 코드 번호를 붙여넣기를 하느냐, 아니면 직접 입력하느냐에 따라 문자표의 반응이 달랐습니다.

문자표에서 HNC 코드와 유니코드를 각각 붙여넣기와 직접 입력을 하면서 어떻게 문자표가 반응하는지를 살펴보기로 하겠습니다.

HNC 코드와 유니코드를 문자표에 입력할 예시

위와 같이 두 번의 예시가 있습니다. 이것을 이용하여 실험을 해 봅시다.
아, 실험에 앞서 파일을 먼저 다운로드해 주시기 바랍니다.

invalid-file

HNC 코드 붙여넣기

문자표에 HNC 코드를 붙여넣기로 입력해 보겠습니다.

문자표를 처음 실행했을 때의 위치

문자표를 처음 실행하면 위와 같이 전각 기호(일반)에 위치하게 됩니다. 물론 위와는 달리 최근 사용한 문자는 텅 비어 있겠지요.
위 그림에서 빨간 네모로 표시한 HNC 코드 부분에 알맞은 코드 번호를 넣으면 됩니다. 그 작업은 아래와 같은 순서로 하겠습니다.

예시에서 HNC 코드라고 한 부분의 코드에서 파란색 부분만을 복사하여 붙여넣기를 합니다. 앞에 붙인 0x는 복사하지 않습니다. 그럼 341C를 복사하겠습니다.
일단 문자표의 문자 영역을 다른 곳으로 옮겨 아무 문자나 하나 입력(더미 문자 입력)하겠습니다. 이는 문자 영역이 같을 때와 다를 때의 동작이 다르기 때문에 하는 조치입니다.

다른 문자 영역의 문자를 선택하여 입력

다른 문자 영역의 문자를 선택하여 입력한 결과
다시 문자표를 불러서 붙여넣기를 합니다.

문자표를 불러오면 방금 사용한 문자를 표시하고 있습니다. 일단 HNC 코드 부분을 지웁니다.

HNC 코드 부분에 방금 복사한 341C를 붙여넣기로 입력한 순간 바뀌는 문자표
위의 작업을 확인하기 위해, 이번에는 531C를 붙여넣기로 입력합니다.

문자표에 531C를 붙여넣기로 입력

HNC 코드 붙여넣기로 입력 최종 결과

위에서 검증했듯이 HNC 코드에서는 붙여넣기로 입력하면, 그 순간 문자 영역 및 문자 선택에서 방금 입력한 코드 번호에 해당하는 문자를 가리키게 됩니다.

HNC 코드 직접 입력

이번에는 HNC 코드를 직접 입력해 보겠습니다. 순서는 따로 설명하지 않겠습니다. 직접 해 보시기 바라며, 결과는 아래와 비슷하게 나와야 합니다.

531을 입력해도 아무런 변화가 없다.

531를 입력한 뒤 C를 마저 입력해야 순간이동을 한다.

HNC 코드를 직접 입력한 최종 결과

HNC 코드에서는 직접 입력하더라도 순간이동을 해서 그 코드 번호에 해당하는 문자를 찾아 줍니다.

유니코드 붙여넣기로 입력

이번에는 유니코드를 문자표에 붙여넣기로 입력해 보겠습니다.

일단 처음에는 다른 문자 영역에서 한 문자를 입력합니다.

아무 문자나 하나 입력
유니코드를 복사하여 붙여넣기로 입력합니다. 이때도 HNC 코드와 마찬가지로 앞에 붙은 U+는 복사하지 않습니다. 여기에서는 3010을 복사하겠습니다.

HNC 코드 붙여넣기에서처럼 순간 이동에 성공!
이번에는 20850를 복사하여 붙여넣기를 합니다.

문자표에서 유니코드 20850 대신에 2085를 찾아 줍니다.

유니코드를 붙여넣기로 입력한 최종 결과

위에서 검증했듯이 유니코드에서는 붙여넣기로 입력하면, 4자리 16진수로 이루어진 코드 번호를 입력한 경우에는 입력하는 순간 문자 영역 및 문자 선택에서 방금 입력한 코드 번호에 해당하는 문자를 가리키게 됩니다. 그러나 5자리 16진수로 이루어진 코드 번호를 입력한 경우에는 입력하는 순간 가장 아래의 한 자리는 빼먹고 위의 네 자리만 받아들여 유니코드를 찾아줍니다.

유니코드 직접 입력

이번에는 유니코드를 직접 입력해 보겠습니다. 순서는 따로 설명하지 않겠습니다.

유니코드를 네 자리 입력한 뒤에는 더 이상 입력을 받지 않습니다.

위와 같은 화면에서 어쩔 수 없이 [넣기]를 클릭했습니다.

유니코드를 직접 입력한 최종 결과

위에서 검증했듯이 유니코드에서는 직접 입력하면, 앞서 붙여넣기로 입력했을 때와 마찬가지로, 4자리 16진수로 이루어진 코드 번호를 입력한 경우에는 입력하는 순간 문자 영역 및 문자 선택에서 방금 입력한 코드 번호에 해당하는 문자를 가리키게 됩니다. 그러나 5자리 16진수로 이루어진 코드 번호를 입력한 경우에는 입력하는 순간 가장 아래의 한 자리는 빼먹고 위의 네 자리만 받아들여 유니코드를 찾아줍니다.

벌레 분석

이 벌레의 원인에 대해서는 알 수 없었습니다. 유니코드의 다섯 번째 자리의 입력이 왜 안 되는지 이해할 수가 없었습니다. 분명히 해당 문자의 코드를 알려줄 때에는 네 자리를 넘겨 다섯 자리인 16진수로도 보여주기 때문입니다.

일단 유니코드의 코드 번호를 보고 싶은 글자에 범위를 지정합니다.

분명히 코드 번호가 6자리로 나타납니다.

ᄒᆞᆫ글 씨! 문자표에서 16진수 6자리로 이루어진 유니코드 번호는 나타낼 수 있어도 입력은 안 됩니까? 입력도 되게 하면 안 되겠니?

비슷한 벌레

(없음)

2010년 1월 26일자 Yslow 문제 (0)	2010.01.26
ᄒᆞᆫ글2010 베타버전의 문자표 버그 2 (0)	2010.01.24
굵은 은 돋움 글꼴의 옛한글 조합 버그 (2)	2010.01.22
한컴사전에 나타난 이상한 하이픈 (0)	2010.01.18
아크로에디트 URL 강조 오류 2 (0)	2010.01.17

다음뷰, 옛한글도 한글이란다.

벌레와 팁/버그

2010. 1. 1. 14:11

요즘 열심히 옛한글 관련 포스팅을 하고 있습니다. 일단 한글과컴퓨터의 한컴오피스2010 베타버전 때문에 더 열심히 하고 있지요. 그런데 제가 ᄒᆞᆫ글이라는 이름을 꼭 제대로 나타내고 싶어하기 때문에 문제가 발생하고 있습니다. 적당히 포기하면 편할 텐데 말입니다. 제가 사소한 데 목숨을 거는 스타일이라서 말입니다. 물론 이 글의 제목에서는 다음뷰만 거론했지만, 다음뷰의 상황이 가장 나쁘기 때문이지 다른 사이트도 별로 다르지 않습니다.

ᄒᆞᆫ글 (안 보이시나요? 아래 자주색 그림처럼 보여야 옳습니다.)
(이렇게 보여야 옳습니다.)
(이렇게 보이면 안 됩니다.)

벌레의 유형

대부분의 사이트에서 발생하는 벌레입니다. 벌레라기보다는 무사안일한 태도 때문이라고 생각합니다. 블로그 서비스를 이용하는 사람은 그 목적이 매우 다양하여, 화학식, 물리학이나 수학의 수식, 언어학의 음성 기호, 한국어의 옛한글 등도 블로그에서 표현하려고 들 것입니다. 그런데 서비스를 제공하는 측에서 그러한 다양한 요구가 생기리라는 것을 예측하지 못하고 평범한 환경만을 대상으로 블로그 서비스 및 메타블로그 서비스를 기획, 개발했기 때문에 벌어진 일입니다.

게다가 블로그 가운데 유니코드(utf-8)를 쓰는 블로그도 많은데, 메타블로그가 유니코드가 아닌 euc-kr과 같은 코드를 쓴다면? 당장 그 메타블로그가 표현해줄 수 있는 문자 수가 확 줄어들게 된다. 어처구니없게도 여러 블로그를 아우르게 되는 메타블로그가 블로그보다 더 표현력이 떨어지는 이상한 현상이 발생하게 되는 것이다.

개발자의 답변

다음 뷰에는 2010년 1월 1일 버그 리포팅을 한 상태입니다. 메타블로그임에도 비슷하게도 나타내지 못하고 있습니다.
스프링노트에는 2009년 12월 31일 기능 제안(옛한글 입력 및 출력)한 상태입니다.
티스토리에는 2010년 1월 1일 제안(글꼴 정보 추가 요청)한 상태입니다.
mixsh에는 2010년 1월 1일 제안(글꼴 정보 추가 요청)한 상태입니다.

벌레의 발견

응?! 다음뷰 온 박스에 쓰인 ???글 씨? 저거 또 무엇인고?

위에서 view on 박스를 보면 조금 문제가 심각합니다. 다른 경우는 ㅎ.ㄴ 처럼 보이는데 저것은 아예 ???라고 나타납니다. 혹시나 하는 마음에 다음뷰도 살펴보았습니다.

다음뷰에서도 ???로 나타내고 있습니다.

아, 글씨, 도대체 이게 어찌된 일일까요? 아무튼 조금 난감한 경우입니다.

mixsh에서도 엉뚱하게 나타납니다. 그래도 대강은 알아볼 수 있겠네요.

mixsh(믹시)는 그저 글꼴 정보가 지정되지 않았기 때문에 발생한 문제입니다.

티스토리 블로그 제목 : 이건 사용자가 글꼴을 지정할 수 있습니다.

위의 그림에 나타난 티스토리 블로그의 게시물 제목은 사용자가 글꼴을 지정할 수 있습니다. 현재 귀찮아서 안 하고 있습니다. 또한 어느 정도 사람들이 "왜 나타낼 수 없지?" 또는 "왜 저렇게 이상하게 나타나지?"라는 생각을 어느 정도 할 때까지(적어도 댓글에다가 "항의"를 적을 때까지) 그냥 둘까도 생각했습니다만, 조만간 고쳐야겠습니다.

티스토리 관리 화면. 이건 티스토리에서 해 주어야 합니다.

티스토리 관리 화면에 관해서는 이미 제안한 상태입니다.

스프링노트. 정확하게 나와 있죠? (자주색 동그라미 부분)

위 스프링노트 화면에서는 정확하게 나타내고 있습니다. 하지만 기본 기능이 아니라 HTML 모드를 사용하여 직접 HTML 태그를 입력하였습니다. 이렇게 직접 입력하는 방식은 티스토리 블로그 제목에서도 통용될 수 있습니다. 아무튼 옛한글의 입력과 출력을 스프링노트에 제안한 상태입니다.

벌레의 원인

앞서 말했듯이 이런 벌레가 생긴 까닭은 개발자나 기획자의 무사안일함 때문이라고 생각합니다.

옛한글을 전혀 사용하지 않을 로마자 문화권도 아닌데, 좀 더 넓은 안목에서 옛한글도 표현할 수 있게 지원하면 좀 좋겠습니까?

비슷한 벌레

화면 표시와 관련한 버그로는 V3 계열 백신의 폴더 경로명 표기 벌레와 ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?가 있습니다.

ᄒᆞᆫ글 씨! 블로그에는 글을 하나만 올리란 말입니다. (0)	2010.01.03
ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니? 2 (0)	2010.01.03
ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니? (0)	2010.01.01
ᄒᆞᆫ글 씨! 블로그 카테고리는 어디에? (0)	2010.01.01
스프링노트 - 블로그로 보내기 - 새로고침 버그 (0)	2009.12.31

스프링노트 : 문자 인코딩 관련 사항

벌레와 팁

2009. 11. 29. 00:19

스프링노트에서 작성한 글을 블로그에 게시하고 나면 가끔 물음표(?)로 바뀌는 일이 있다. 처음에는 내가 유니코드나 KS X 1001(흔히 KS C 5601로 불린다.) 코드에 들어 있지 않은 코드를 게시한 것으로 여겼다. UTF-8 표기법으로 나타낼 수 없는 문자를 U+003F(?, 물음표)나 U+FFFD(�, 유니코드 대치 문자)로 치환하는 것은 UTF-8에서의 오류 처리이기 때문이다. 그러다가 스프링노트 측에서 또는 티스토리 측에서 잘못 게시했을 수도 있다는 생각을 갖게 되었다.

벌레의 유형

벌레인지 아닌지 알 수 없었다. 이 사례는 보는 관점에 따라서는 버그일 수도 있고 아닐 수도 있다.

벌레의 발견

지난 11월 18일 알까기 1 - 알툴즈 까기 문서를 작성하다가 뮤토런트의 로마자 이름(μTorrent)이 화면에 잘못 나타나고 있음을 보고 혹시나 하는 생각을 갖게 되었다. 그에 앞서 11월 2일 한/글/ 2007에서 나타난 구결 표기 오류 2 문서에 엄(厂)과 엄(广)을 입력하다가 발견하였다. 현재 그 문서는 글자가 깨진 상태로 놔두었다.

자료 화면. 문자 인코딩이 제대로 되지 않았다.

문제가 발생하는 경우

지금까지 문제가 발생한 경우는 다음과 같다.

자주 쓰지 않는 한자 : 한중일 통합 영역의 한자 가운데 (1) 특정 언어 윈도에서만 정확하게 보이는 한자, (2) 기본 다국어 평면(BMP)의 U+4E00부터 U+9FA5까지의 영역에 포함되지 않는 한자는 제대로 보이지 않는 경우가 있다.
자주 쓰지 않는 로마자 : 영문자는 잘 나타내 준다. 숫자도 잘 나타내 준다. 꺽쇠(< >)도 잘 나타내 준다.^[각주:1] 다만 그리스 문자나 키릴 문자 등은 가끔 정확히 표현하지 못한다. 뮤토런트에서 깨진 문자도 그리스 문자이다.
특별한 구문부호가 붙은 로마자 및 기호 : 움라우트 등이 붙은 문자나 기호 등에서 가끔 깨진다.

문제 해결책

크게 두 가지 해결책이 있다. 우선 특별한 구문부호가 붙은 로마자나 기호는 글자 엔티티(character entity)로 나타내면 된다는 점이다. 그 다음으로 자주 쓰이지 않는 한자는 HTML 참조 코드를 이용하는 쪽이 낫다는 점이다.

글자 엔티티 이용 : © 기호를 나타내고 싶다면 © 라고 표현하면 된다.
HTML 참조 코드 : © 기호를 나타내고 싶다면 © 라고 16진수로 표현하거나, © 라고 십진수로 표현하면 된다.

파이어폭스 부가기능 오류 코드 : ssl_error_rx_record_too_long (30)	2009.12.28
한/글과 구결 표기 (0)	2009.12.10
티스토리 주석에서 \ 문자 표기 문제 (0)	2009.05.30
제거되지 않는 버추얼박스 제거하기 (0)	2009.04.16
Offree.net에서 발견한 이상한 점 (2)	2009.03.26

AIK7과 설치 응답 파일 4 - 응답 파일과 언어팩 적용 윈도7

소프트웨어/Windows

2009. 6. 5. 08:44

AIK7에서 설치 응답 파일을 만들어 한국어 언어팩이 적용된 윈도7에 적용해 보았다. 그런데 설치 메시지가 모조리 영어로 나와서 응답 파일에 한국어를 적용한 의미를 갖지 못했다. 그래서 이번에는 무인 설치 설정 레퍼런스(Unattended Installation Settings Reference)를 살펴보기에 앞서 한국어를 적용한 설치본에서 한국어를 한글로 설치 과정에서 출력할 수 있게 응답 파일을 고쳐보기로 했다.

윈도 설정과 언어 및 국가

윈도 비스타 및 윈도7(이하 '윈도')의 설정과 언어 문제는 약간 미묘하다. 전적으로 특정 언어에 국한하는 문제도 있고, 특정 국가에 국한하는 문제도 있다. 아무튼 설치 과정에서 한국어를 한글로 나타내려면 boot.wim에 한국어를 적용하면 되지만, 응답 파일에서 영어로 표기하도록 했다면 애써 한국어를 적용한 작업이 무효로 되고 만다. 이것은 설치한 뒤에 시스템과 사용자가 영어를 쓰도록 했다면 역시 마찬가지 결과를 보이게 된다.

이러한 일을 당하지 않으려면 응답 파일에서 언어 설정과 국가 설정을 반드시 한국(한국어)로 설정해야 하며, 이 글에서는 그 설정 방법을 다루기로 한다.

기본 환경

지금까지 실험해 왔던 환경을 그대로 사용할 예정이다. 앞의 다른 글을 읽지 않은 이들을 위해 다시 적는다.

기본적으로 윈도7의 최소 요구사항 가운데 다음 두 가지를 만족한다고 가정하고 실험하였다.

RAM 1G(32비트), RAM 2G(64비트)
HDD 40G(32/64비트)^[각주:1]

자동 설치 도구는 Windows Automated Installation Kit for Windows 7를 사용하였다. 정확하게는 Windows System Image Manager(흔히 Windows SIM; 시스템 이미지 관리자)을 사용하였다. AIK7을 위해 추가 공간이 필요하며, 또한 작업을 위해 9GB 정도가 더 필요하다.

실험에 쓰일 응답 파일은 지난번 작업에서 만든 AutoUnattend.xml 파일이다.
실험에 쓰일 설치본은 앞서 구한 윈도7 RC 7100 디스크 이미지 파일에 한글을 덧입힌 것을 이용하였다.
윈도 시스템 이미지 관리자에 대한 설명 등은 테크넷과 AIK7에 포함된 도움말 파일을 참조하였다.

실험 목표

일단 이것도 실험이니 목표가 있어야겠다.

설치 과정에서 한글로 나오게 한다.

위와 같이 영어(로마자)로 나오는 화면을 한국어(한글)로 나오도록 바꾼다.
설치한 뒤에 한글로 나오게 한다. : 다만 이것은 설정하지 않아도 한글로 나온다. 이미 한국어 언어팩을 적용할 때 화면 표시 언어도 한글(한국어)로 설정했기 때문이다.
키보드 종류를 한국어 키보드 (103/106키)로 설정한다. 위 그림에서 보면 Korean Keyboard (103/106 Key)라는 부분은 내가 수정한 것이다. 이게 처음부터 103/106키였다면 아예 이 화면이 나오지 않아야 한다. 아울러 위 화면에서 선택하는 것을 모두 자동 선택하게 설정한다.
오픈캡처의 메뉴가 알아볼 수 있는 문자로 나타나는지를 확인한다. : 이상하게 메뉴가 자꾸 깨지고 있다.

이상하게 나타나는 오픈 캡처의 메뉴

언어 설정

설치 과정과 설치한 뒤 화면에 나타날 언어 설정하는 것은 로케일(Locale; 지역)이나 랭귀지(Language; 언어)와 관련이 있습니다. 이와 관련한 구성 요소는 Microsoft-Windows-International-Core와 Microsoft-Windows-International-Core-WinPE 입니다.

이 작업을 위해 이미 윈도 시스템 이미지 관리자를 실행했다고 가정하고 설명하겠습니다.

윈도 설치 프로그램과 언어 설정

윈도 설치 프로그램과 관련한 언어 및 지역화 구성 요소는 Microsoft-Windows-International-Core-WinPE 입니다. 테크넷 문서에서는 다음과 같이 설명하였습니다.

The Microsoft-Windows-International-Core-WinPE component specifies the default language, locale, and other international settings to use during Windows Setup or Windows Deployment Services installations.

위의 내용을 한국어로 옮기면, "Microsoft-Windows-International-Core-WinPE 구성 요소는 윈도 설정 또는 윈도 배포 서비스 설치를 하는 동안 사용할 기본 언어, 지역화 및 다른 국제화 설정을 지정합니다."라는 뜻이다.

지난번 작업에서 만든 AutoUnattend.xml 응답 파일을 윈도 시스템 이미지 관리자에서 불러옵니다. 여기에는 이미 Microsoft-Windows-International-Core-WinPE 구성 요소가 설정되어 있습니다.

Microsoft-Windows-International-Core-WinPE 등록 정보 : 현재는 대부분 영어이다.

설정에 나타난 항목을 살펴보겠다. 이 항목은 크게 세 부분으로 나뉜다. 첫째는 로케일 관련 부분, 둘째는 언어 관련 부분, 셋째는 키보드 드라이버 관련 부분이다.

로케일 관련 : 언어 인식자(language identifier) 또는 로케일 아이디(locale ID)를 지정한다. 이때 언어 인식자는 en-US 또는 ko-KR과 같은 값을 일컫으며, 로케일 아이디는 16진수 및 10진수로 이루어진 0409:00000409 또는 0412:00001042^[각주:2]와 같은 값을 일컫는다.
- InputLocale : 키보드 레이아웃과 입력 로케일 시스템을 지정한다.
- SystemLocale : 유니코드를 지원하지 않는 프로그램에서 사용할 기본 시스템 로케일을 지정한다.
- UserLocale : 사용자가 이용할 날짜, 시간, 통화, 숫자 표기 등을 설정한다.
- 설정 : 위 세 항목은 현재 언어 인식자인 en-US로 되어 있는데, 모두 ko-KR로 바꾼다. 다만 InputLocale 항목에서는 로케일 아이디인 0412:00001042로 바꿀 수도 있다. 또한 InputLocale 항목에서는 여러 로케일을 지정할 수 있다. 예컨대 ko-KR; en-US; ja-JP 와 같은 꼴로 모두 표기할 수 있다.
언어 관련
- SetupUILanguage : 윈도 설치 또는 윈도 배포 서비스를 수행하는 동안 화면에 나타낼 기본 언어를 지정한다.
  - UILanguage : SetupUILanguage 항목의 값을 실제로 지정하는 요소이다. ko-KR을 지정한다.
  - WillShowUI : 사용자 인터페이스를 보여준다. 사용자 인터페이스는 위에서 키보드 종류 등을 설정하는 화면을 가리킨다. 무인 설치에서는 기본적으로 OnError 값이 주어져 있으며, 이는 오류가 발생할 때만 사용자 인터페이스를 보여준다는 뜻이다.
- UILanguage : 사용자 인터페이스에서 사용할 기본 언어를 지정한다. 한국어를 사용해야 하므로 ko-KR을 지정한다.
- UILanguageFallback : 시스템 기본 사용자 인터페이스 언어에서 부분 버전 언어팩을 사용하고 있을 때 대체할 언어를 지정한다. 현재 한국어의 경우 윈도 비스타에서는 기본 언어가 en-US, 부분 버전 언어팩은 ko-KR로 적용되어 있다. 윈도7의 상황은 알 수 없지만, 윈도 비스타의 경우와 비슷하리라 생각한다. 그러므로 이 값은 en-US를 지정하거나 공백으로 비워두자(→사용 가능 언어팩 참조).
키보드 드라이버 관련
- LayeredDriver : 한국어 키보드 또는 일본어 키보드에서 사용할 키보드 드라이버를 지정한다. 숫자를 입력하면 되며, 숫자에 따라 다음과 같은 드라이버를 선택하게 되며, 대부분 5를 입력하면 된다.
  - 1 : PC/AT 확장 키보드 (101/102-Key).
  - 2 : 한국어 PC/AT 101키 호환 키보드/MS 내추럴 키보드 (타입 1).
  - 3 : 한국어 PC/AT 101키 호환 키보드/MS 내추럴 키보드 (타입 2).
  - 4 : 한국어 PC/AT 101키 호환 키보드/MS 내추럴 키보드 (타입 3).
  - 5 : 한국어 키보드 (103/106 Key).
  - 6 : 일본어 키보드 (106/109 Key).

지금까지 Microsoft-Windows-International-Core-WinPE 구성 요소에 대한 설정을 하였다. 지금까지 작업한 내용은 아래와 같이 나타나야 한다.

대부분 한국어로 설정된 Microsoft-Windows-International-Core-WinPE 등록 정보

윈도 시스템과 언어 설정

윈도 시스템과 관련한 언어 및 지역화 구성 요소는 Microsoft-Windows-International-Core 입니다. 테크넷 문서에서는 다음과 같이 설명하였습니다.

The Microsoft-Windows-International-Core component includes the language and input locale settings for the system and the user.

위의 내용을 한국어로 옮기면, "Microsoft-Windows-International-Core 구성 요소는 사용자와 시스템을 위한 언어 및 입력 로케일 설정을 포함하고 있습니다."라는 뜻이다.

윈도 이미지 창에서 Microsoft-Windows-International-Core 구성 요소를 선택하여 응답 파일 창에 추가하기

위 그림에서 윈도 이미지 창에서 Microsoft-Windows-International-Core 구성 요소를 선택하여 응답 파일 창의 oobeSystem 구성 단계에 추가한다.

참고로 윈도7을 설치한 다음 sysprep (시스프렙)을 이용하여 어떤 시스템에서도 부팅할 수 있는 만능 윈도7을 구성할 사람은 이 윈도의 언어 및 지역화 설정을 specialize 구성단계에 넣어서는 안 되며, 반드시 oobeSystem 구성 단계에 넣어야 한다. 왜냐하면 sysprep을 이용하여 만능 윈도7을 만들려면 generalize(일반화)를 해야 하는데, 그때 specialize 구성 단계에 해당하는 작업은 모두 제거하기 때문이다.

Microsoft-Windows-International-Core 등록 정보 : 현재는 공백이다.

설정에 나타난 항목은 크게 두 부분으로 나뉜다. 첫째는 로케일 관련 부분, 둘째는 언어 관련 부분이다. 키보드 관련 부분은 없으며, 위 화면에 나타난 부분은 앞의 Microsoft-Windows-International-Core-WinPE 구성 요소를 참조하여 값을 넣기 바랍니다. 이름이 같은 항목에 같은 내용이 들어가게 하면 됩니다.

대부분 한국어로 설정된 Microsoft-Windows-International-Core 등록 정보

평가 및 실험 결과

4시 53분쯤에 시작하여 5시 20분쯤에 끝난 이번 설치는 설치 시간이 약 27분으로 종전 40~50분쯤에서 확연히 줄어서 좋았다. 하지만 키보드 설정 등을 제대로 하지 않아 처음에 한글 입력에 애를 먹었다. 결국 한국어 사용자 또는 한국 사용자를 위해서는 키보드, 언어 설정 등이 필요함을 절실하게 느꼈다.

앞서 세운 목표를 다시 새겨보자.

설치 과정에서 한글로 나오게 한다.
설치한 뒤에 한글로 나오게 한다.
키보드 종류를 한국어 키보드 (103/106키)로 설정한다.
오픈캡처의 메뉴가 알아볼 수 있는 문자로 나타나는지를 확인한다.

설치 과정

설치 과정은 한글로 나타났다(목표 1 달성).

한글로 나타나는 설치 과정

설치 과정에서 맨 처음 나타난 디스크 파티션 설정

실제로 설치를 시작하는 Windows 설치 단계

설치 완료

설치 완료한 뒤에 바로 한글로 표기되고 있다(목표 2 달성).

한글로 나타나는 시작 메뉴 및 시계

키보드 종류

키보드 종류를 제어판 한국어 키보드 (103/106키)로 설정하여 윈도가 설치된 뒤에도 그렇게 인식되도록 한다는 목표였다. 그러나 설치를 끝내고 나서 보니 키보드는 한국어 키보드 (103/106키)로 설정되지 않았다.

표준 PS/2 키보드로 설정된 키보드 드라이버

목표 3 달성하지 못하였음을 확인하였다. MS테크넷 라이브러리를 검색하고, 나아가 구글링을 하였음에도 키보드를 설치과정에서 설정하는 작업에 대해서는 해답이 없었다.

응용 프로그램의 로케일

오픈캡처의 메뉴가 알아볼 수 있는 문자로 나타나는지를 확인한다는 목표는 달성했다(목표 2 달성). 추가적인 로케일 설정 없이도 오픈캡처에서 한글 메뉴가 잘 나타나고 있다.

추가적인 로케일 설정 없이 한글 메뉴가 잘 나타나는 오픈캡처

다음 할 일

설치 응답 파일에 적용되는 무인 설치 설정 레퍼런스(Unattended Installation Settings Reference)에 대해 알아보자. 이 작업을 통해 키보드 설정에 대해 지속적으로 조사할 생각이다.

무인 설치 레퍼런스 사용하기 (0)	2009.06.12
설치 응답 파일과 한국어 언어팩을 적용한 윈도7 (0)	2009.06.03
AIK7과 설치 응답 파일 3 - 카탈로그 파일 만들기 (0)	2009.06.02
AIK7과 설치 응답 파일 2 (2)	2009.05.29
한글 적용된 윈도7 설치 프로그램 + 파티션 분할 (0)	2009.05.26

스프링노트 : 일부 글자 속성이 제대로 지정되지 않는 벌레

벌레와 팁/버그

2009. 5. 14. 10:10

지난 5월 10일 스프링노트에서 글을 작성하다가 우연히 발견한 벌레이다. 그런데 이 벌레를 무릅쓰고 정상 작동한 것과 같은 결과를 보였더니 사라져 버렸다. 현재 재현은 불가능한 상태이며, 그 원인도 파악하지 못했다.

벌레의 유형

자기가 있어야 할 영역을 구분하지 못하는 벌레이다. 혹시 개념이 출장하지는 않았을까 염려스로운 벌레이기도 하다.

벌레의 발견

5월 10일 새벽에 윈도7을 버추얼박스에 설치하면서 그 설명문을 작성하였다. 그때 발견한 이 벌레를 보는 순간 내가 밤샘을 하느라 착각했다고 생각했다. 하지만 자꾸 반복되었기 때문에 스크린샷을 잡을 수 있었다.

위의 그림에서 Use recommended settings라는 부분을 잘 살펴보자.
그 부분이 가진 특징은 (1) 영문(로마자)이며, (2) 내용 중간에서 줄바꿈이 되어 있고, (3) 숫자 목록을 사용하여 나타내고 있다.

먼저 위와 같이 블럭 설정을 하였다.

<Ctrl+B>를 눌러 강한 강조를 하였으나, 위 그림처럼 윗줄(Use recommended)은 바뀌고 아랫줄(settings)은 바뀌지 않았다.
이 그림처럼 강한 강조 아이콘을 클릭했음에도 결과는 마찬가지였다.

결국 다음과 같이 줄바꿈이 아닌 문단 나누기를 하여 블럭 지정하기로 했다.

일단 문단을 나누고

블록을 지정하여 강한 강조를 하였다.

이번에는 내가 원하는 결과가 나타났다.

제작자/제공자의 답변

2009년 5월 14일 오류를 보고한 상태이다. ~~재현이 불가능하기 때문에 어찌 처리될는지는 알 수 없다.~~ 역시나 재현이 불가능하기 때문에 오류 수정이 어렵다고 한다.

그때가 새벽이라 한창 잠이 올 때였다. 스크린샷을 잡은 것도 지금 생각해보면 비몽사몽간에 했던 일이다. 미처 HTML 코드를 확보하지 못했고, 위의 방법으로 강한 강조를 성공한 뒤에는 재현되지 않았다.

아크로에디트 : 배치파일 주석 문법 강조 기능 (0)	2009.05.16
스프링노트 : 공개 및 비공개 설정에서 이상한 점 (0)	2009.05.15
버추얼박스 v2.2.2 설치 오류 : 한글 경로명 문제 (8)	2009.05.10
V3 계열 백신의 폴더 경로명 표기 벌레 (0)	2009.04.28
스프링노트의 링크 편집 벌레 (1)	2009.04.27

버추얼박스 v2.2.2 설치 오류 : 한글 경로명 문제

벌레와 팁/버그

2009. 5. 10. 00:30

버추얼박스는 새 버전이 발표될 때마다 자잘한 벌레로 사람을 성가시게 하고 있다. 2.2.0판을 설치하면서 벌레가 많아서 사람을 성가시게 하고 있다. 이번에는 설치할 때 경로명에 한글이 포함되면 문제가 발생하는 벌레까지 발견했다.

벌레의 유형

설치 프로그램에 기생하면서 한글 경로명을 인식하지 못하게 막는 벌레이다.

벌레의 발견

낮에 집에서 윈도7을 설치한 뒤 PC방에서도 설치해 보고 싶었다. 물론 버추얼박스를 설치한 뒤에. 그런데 버추얼박스를 다운로드 받아서 설치하려고 했으나 오류가 나면서 설치가 되지 않았다.

다운로드한 버추얼박스 프로그램 파일

이 오류를 해결하기 위해 컴퓨터 설정을 살피다가 언어 설정과 관련하여 한 가지가 생각났다. 바로 "한글 경로"에서 문제가 발생하였다.

우선 프로그램이 있는 경로의 한글 경로가 문제가 된다고 생각하여 버추얼박스 프로그램을 C:\1 폴더로 옮겼다. 그러나 여전히 문제가 발생했다.

그렇다면 이것은 프로그램이 존재하는 곳의 경로와는 상관이 없다는 뜻이었고, 다른 가능성을 찾아야 했다. 그러다가 문득 시작 단추를 누르게 되었다.

"사매 로그오프"라는 부분, 곧 사용자 이름(사매)에 한글이 포함되어 있었다. 명령 프롬프트를 열어서 SET 명령을 입력했다.

명령 프롬프트에서 SET 명령 실행 화면

위와 같이 TEMP 환경 변수(핑크색 밑줄 부분)에도 한글이 포함되어 있음을 확인했다. 이 TEMP 환경변수는 프로그램이 실행될 때 임시파일을 만드는 경로인데, 한글이 포함될 경우 로마자 언어를 기준으로 작성된 프로그램에서는 가끔 오류가 생기기도 한다. 작게는 저장할 때 저장을 할 수 없는 문제가 있고, 이번처럼 아예 실행이 되지 않는 경우도 있다. 이것은 프로그램 제작자의 실수이지만, 해결할 방법은 있다. 바로 TEMP 환경변수의 경로를 바꾸면 된다.

벌레 잡기

이것을 해결하려면 시스템 환경변수를 다루어야 한다.

바탕화면에 내 컴퓨터 아이콘이 있다면 거기에서 마우스 오른쪽 단추를 클릭하여 속성을 선택하면 된다.

그게 아니라면 제어판(시작 단추 >> 설정 >> 제어판)을 열고, 거기에서 시스템을 두번클릭하면 된다. 그 뒤 고급 탭을 클릭한다.

시스템 등록 정보의 고급 탭을 클릭한

환경 변수를 클릭한다.

TEMP를 클릭하여 선택한 다음 편집 단추를 클릭한다.

위 그림처럼 보이게 되는데, 이때 아래처럼 바꾼다. 위의 그림은, 경로가 앞서 보여준 명령 프롬프트 화면의 C:\DOCUME~1\사매\LOCALS~1\Temp처럼 보이게 된다. 바로 한글 사매가 사용자 이름이고, %USERPROFILE% 환경변수는 사용자 이름을 참조하기 때문이다. 물론 근본적으로 사용자 이름을 한글이 아닌 로마자로만 지으면 되지만, 한글 이름을 쓰고 싶은 경우도 많으므로, 이렇게 고쳐 주면 해결할 수 있다.
아무튼 아래의 그림처럼 한글이 포함되지 않은 경로를 지정해 주면 된다. 이때 해당 경로가 존재하지 않는다면 그 폴더를 만들어 주면 된다. 마지막에는 반드시 확인을 클릭한다.

TMP 환경 변수도 TEMP 환경변수와 같게 만들어주면 된다.

확인을 눌러주면 편집한 환경 변수가 저장된다.

지금까지 작업을 마쳤으면 다시 버추얼박스 설치 프로그램을 클릭하여 실행한다.

제작자/제공자의 답변

2009년 5월 9일 오후 8시 20분 무렵(May 9th, 2009, 9:19 pm / 1시간의 오차는 일광시간절약제와 관련한 오류로 여겨진다.)에 버그리포팅을 하였다.

스프링노트 : 공개 및 비공개 설정에서 이상한 점 (0)	2009.05.15
스프링노트 : 일부 글자 속성이 제대로 지정되지 않는 벌레 (0)	2009.05.14
V3 계열 백신의 폴더 경로명 표기 벌레 (0)	2009.04.28
스프링노트의 링크 편집 벌레 (1)	2009.04.27
스프링노트의 태그 표기 벌레 (0)	2009.04.26

V3 계열 백신의 폴더 경로명 표기 벌레

벌레와 팁/버그

2009. 4. 28. 20:55

우연히 AhnLab V3 Internet Security 2007 Platinum 삼성생명 번들판을 사용하다가 & 문자(앰프(Amp) 문자)가 들어간 경로를 정확하게 표현하지 못하는 현상을 발견하게 되었다.

벌레의 유형

경로명을 표시하라고 했더니 메뉴를 표시하는 것으로 착각하는 벌레이다.

벌레의 발견

폴더 경로명을 제대로 보여주는지를 알아보기에 앞서 다음과 같은 작업을 하였다.

프로그램을 인터넷을 통해 구하였다. 이때 백신의 바이러스 패턴은 수동 업데이트의 경우 4월 27일자를 사용했고, 자동 업데이트의 경우 4월 28일에 업데이트하여 사용했다.
1. AhnLab V3 Internet Security 2007 Platinum(이하 'V3 IS') 안철수바이러스연구소 시험판
2. V3 IS 삼성생명 번들판
3. V3 365 클리닉
4. V3 Lite
5. V3+ Neo
6. 그밖에 기업용 제품이나 서버용 제품은 시험하지 않았다.
바이러스가 포함된 파일을 인터넷을 통하여 구하였다.
1. eMule 프로그램에서 크랙, 망가 등으로 검색한다.
2. 검색 결과에서 무작위로 다운로드한다.
3. 바이러스를 포함하는 파일을 찾아낸다.
가상머신 프로그램인 버추얼박스에 게스트OS로 윈도XP와 MS-DOS를 설치한 뒤 백신을 설치하고 경로를 어떻게 표시하는지를 조사하였다.
1. 버추얼박스에 윈도XP와 MS-DOS를 각각 설치한다.
2. 백신을 복사한다.
3. 스냅샷을 설정한다.
4. 백신을 설치한 뒤 바이러스 검사를 하면서 경로 표시를 조사한다.
5. 작업이 끝나면 3번 작업으로 되돌려서, 다른 백신으로 작업한다.

또한 파일시스템에 따라 결과가 달라지지 않을까 염려하여 NTFS와 FAT에서 시험하였으나, 같은 결과가 나왔다. 그래서 FAT의 조사 결과는 생략하였다. 또한 V3+ Neo는 FAT를 검사할 때 윈도의 명령 프롬프트와 MS-DOS의 명령 프롬프트에서 서로 다른 결과가 나오지 않을까 걱정했으나 이 역시 같은 결과가 나왔으므로 MS-DOS의 명령 프롬프트의 결과는 생략하였다.

참고로 맨 처음 발견된 경로 표시 벌레는 다음과 같다.

빨갛게 표시한 부분에서 경로명이 잘못 표시되고 있다.

위 그림에서 빨갛게 표시한 부분은 라고 나타나 있는데(연두색 사각형은 임의로 표시한 것이다), 이때 S자에 밑줄이 그어져 있다.

AhnLab V3 Internet Security 2007 Platinum 시험판

V3 IS 안철수바이러스연구소 시험판을 사용하였다. 시험판은 정품과 같으나 30일 동안 사용할 수 있는 버전으로, 정품이 가진 기능을 모두 가지고 있다. 심지어 벌레까지도. 그렇기 때문에 이번 시험에 사용하였다.

빨갛게 표시한 부분에서 경로명이 잘못 표시되고 있다.

검사 폴더라는 부분에서 소문자 o에 밑줄이 그어져 있다.

위의 목록에서 보면 밑줄이 그어진 글자는 표기가 잘못된 부분이다. 예컨대 D:\MSoft 경로명의 경우 실제로는 D:\M&Soft 라는 경로명을 가지고 있다. 앰프 문자(&)와 뒤따르는 로마자가 함께 해석되어 로마자+밑줄의 형태로 바뀌는 벌레이다.

AhnLab V3 Internet Security 2007 Platinum 삼성생명 번들판

삼성생명 보험 가입자 또는 삼성생명 웹사이트 회원에게 무료로 제공되는 V3 IS 삼성생명 번들판은 맨처음에 이 벌레를 발견한 제품이다. 확인을 위해 한 번 더 조사하였다.

위에서도 밑줄이 그어진 글자가 있다.

V3 365 클리닉

V3 365 클리닉은 토털 PC헬스 케어를 지향한다고 홈페이지에서 설명하고 있다. 이 제품은 안철수바이러스연구소에 가입한 사람만 설치할 수 있다. 설치 과정에서 아이디와 패스워드를 물어보므로 먼저 홈페이지에서 가입해야만 한다.

V3 365 클리닉에서는 경로명을 정확하게 표시해 준다.

위의 그림에서 보듯이 D:\MSS&oft 와 같은 경로명을 정확히 보여주고 있다.

V3 Lite

V3 Lite는 V3 365 클리닉의 축약 버전으로 여겨지며, 개인 사용자에게는 무료이며, 기업 사용자에게는 사용이 허가되어 있지 않다. 기업 사용자는 V3 Internet Security 7.0 Enterprise나 V3 Internet Security 7.0 Platinum Enterprise 제품을 사용하도록 권장하고 있다(참고 : V3 Lite 기업 라이선스 안내).

V3 Lite 제품도 경로명을 정확히 표시해 주고 있다.

V3+ Neo

도스용 버전인 V3+ Neo는 개인 및 등록 사용자에게 무료로 제공되고 있다. 다른 무료 제품처럼 관공서나 단체에서는 업무용으로 사용해서는 안 된다.

역시 정확하게 경로명을 표현해 주고 있다.

벌레의 원인

처음 경로명을 엉뚱하게 표기해 주는 벌레를 조사할 때에는 V3 제품군에서 공통적으로 나타날 것이라고 생각했다. 그러나 AhnLab V3 Internet Security 2007 Platinum에서만 나타나고, 다른 프로그램에서는 나타나지 않았다. 물론 여기에서 시험하지 않은 기업용이나 서버용에서도 나타날 수 있는 벌레이다.

오류가 나는 부분은 대부분 앰프 문자(&)와 관련이 있다. 이것은 HTML 등의 마크업 언어에서 엔티티 문자를 나타내는 지시자로서 쓰인다. 예컨대 & 및 © 등이 그에 해당하며, 이것들은 각각 & 및 ⓒ 기호를 나타낸다.

또한 윈도 프로그래밍에서는 메뉴 등에서 단축키를 표시하는 방법을 제공하기도 한다.

위 그림은 HxD의 메뉴이다. 그런데 밑줄이 그어진 문자가 보인다. 그것은 Alt+(밑줄 문자)의 형태로 메뉴를 호출할 수 있다는 뜻이다. 다시 말해 <Alt+F>키로는 File 메뉴를 호출할 수 있다.

이는 인터넷 익스플로러에서도 마찬가지로 나타난다. 위는 한글 인터넷 익스플로러 6 sp2의 메뉴이다. 여기에서도 위와 마찬가지로 <Alt+F>키로는 파일(F) 메뉴를 호출할 수 있다.

이렇게 메뉴에서 눌러야 할 문자를 표시하기 위해서는 &(문자)의 형태를 사용하게 된다. 다시 말해 &A라고 하면 메뉴에서는 A 라고 나타나게 되며, 이를 위해서 Alt+(문자)의 형태로 호출할 수 있게 된다.

그런데 이러한 앰프 문자와 뒤따르는 로마자 표기를 경로명에서도 적용해 버렸기 때문에 이번과 같은 벌레가 발생하게 되었다고 생각한다.

회사 측 답변

2009년 4월 28일 현재 오류를 보고한 상태이며, 4월 29일 수정을 요청했고, 5월 7일 소스 수정이 완료되었으며, 6월 말 업데이트 때 적용될 예정이라는 답변을 이메일을 통해 받았다.

스프링노트 : 일부 글자 속성이 제대로 지정되지 않는 벌레 (0)	2009.05.14
버추얼박스 v2.2.2 설치 오류 : 한글 경로명 문제 (8)	2009.05.10
스프링노트의 링크 편집 벌레 (1)	2009.04.27
스프링노트의 태그 표기 벌레 (0)	2009.04.26
티스토리 이미지 갤러리 문제 (0)	2009.04.24

IF 문자열

스크립트/배치파일

2009. 4. 18. 22:42

들어가며

IF 문자열 비교 구문은 말 그대로 문자열을 비교하는 구문이다. 이것은 윈도NT 계열에서 추가된 환경 변수 등을 이용하여 여러 가지 작업을 할 수 있도록 해준다. 문자열의 내용을 분석하여 정수(십진수, 팔진수, 십육진수)로 변환하여 계산해 주기도 한다.

말뜻

IF 문자열 비교 구문에서는 일반적으로 등호를 두 개 겹쳐서 쓰게 된다.

if [not] 문자열1==문자열2 명령 [else 구문]

위와 같은 형식을 이루게 된다. 이때 큰괄호( [ ] )로 묶인 부분은 반드시 쓸 필요는 없고 필요할 때 쓰면 된다. 또한 문자열에 공백을 포함하지 않았다면 따옴표를 사용하지 않아도 된다.

문자열 비교 구문의 명령 확장

확장 1

명령 확장이라고 말하기는 했으나, 사실 /i 선택자는 cmd.exe에 포함된 if 명령에서는 기본 선택자이다. 다만 도스의 if 명령과 호환성이 없기 때문에 확장이라고 칭했을 뿐이다.

문자열 비교 구문에서 /i 선택자를 쓰게 되면 그 기능을 확장할 수 있다. 이것은 대문자와 소문자를 무시하고 문자열을 비교하게 됩니다.

IF STRING==string ECHO STRING is string.

위의 문자열 비교 구문은 거짓을 돌려주므로 화면에 아무것도 보여주지 않는다. 그러나 아래 문자열 비교 구문은 참을 돌려주므로 화면에 "STRING is string."이라는 문자열을 출력해 준다.

IF /i STRING==string ECHO STRING is string.

확장 2

문자열 비교 구문에서는 세 문자로 이루어진 비교 연산자를 사용할 수 있다. 이것은 /i 선택자를 사용하여 융통성을 가지는데, 예컨대 숫자로만 이루어진 문자열은 수로 변환하여 비교해 준다.

세 문자로 이루어진 비교 연산자에는 다음과 같은 것이 있다.

EQU (같음)
NEQ (같지 않음)
LSS (보다 작음)
LEQ (작거나 같음)
GTR (보다 큼)
GEQ (크거나 같음)

비교 연산자는 언뜻 보아서는 숫자로 이루어진 문자열에만 쓰일 듯이 보이지만 로마자 등으로 이루어진 문자열에도 쓰일 수 있다.

예제 1

IF /i 22 EQU 026 ECHO 22 is 026.

위의 코드는 10진수 22와 8진수 026을 비교하는 구문이다. 당연히 두 값은 크기가 같으므로 화면에 문자열을 출력해 준다.

IF /i 026 EQU 0X16 ECHO 026 is 0X16.

위의 코드는 8진수 026과 16진수 0x16을 비교하는 구문이다. 당연히 두 값은 크기가 같으므로 화면에 문자열을 출력해 준다.

두 예제는 /i 선택자가 문자열을 확장하여 "일반적으로 해석"하는 예시이다. 다시 말해 문자열 22는 10진수 22로 해석해 주며, 026은 8진수로, 0x16은 16진수로 해석해 준다. 10진수는 0으로 시작할 수 없으며, 0으로 시작하는 수는 8진수이거나 16진수가 된다. 또한 0으로 시작하는 문자열 가운데 0x로 시작하는 문자열은 16진수로 여기게 된다.

하지만 089 등의 문자열은 올바르지 않으므로 오류가 발생하게 된다. 이는 8진수에 8과 9와 같은 숫자는 존재하지 않기 때문이다. 마찬가지로 0x9G 등의 문자열도 올바르지 않다고 여긴다. 이럴 경우 문자열을 수로 확장해 주지 않고, 문자열 자체(리터럴 문자열)로서 비교하게 된다. 참고로 순수한 문자열을 리터럴 문자열(literal string), 수치로서 변환되는 문자열을 숫자 문자열(number string / numeric string)이라고 부른다.

한편 다음에 오는 두 비교문은 서로 다른 결과를 가진다.

IF /i 22 EQU 026 ECHO 22 is 026.

위의 비교문은 수치 비교문으로 참값을 돌려주므로 "22 is 026."을 출력한다.

IF /i 22 == 026 ECHO 22 is 026.

위의 비교문은 리터럴 문자열 비교문으로 거짓값을 돌려주므로 아무것도 출력하지 않는다.

다시 말해 숫자로 이루어진 문자열을 숫자 문자열로서 비교하려면 반드시 문자로 이루어진 비교 연산자를 사용해야 한다.

또한 다음과 같이 사용할 수도 있다.

IF /i abc EQU ABC ECHO abc is ABC.

또는

IF /i NOT abc EQU ABC ( ECHO abd is ABC ) ELSE ECHO abd is not ABC .

앞서 말했듯이 세 문자로 이루어진 비교 연산자로 숫자 문자열뿐만 아니라 리터럴 문자열까지 비교할 수 있다.

IF /i abc NEQ ABC ( ECHO abd is ABC ) ELSE ECHO abd is not ABC .

위의 비교문도 정상 작동한다.

예제 2

그렇다면 작거나 같음을 비교할 때는 어떻게 동작할까? LSS (보다 작음), LEQ (작거나 같음), GTR (보다 큼), GEQ (크거나 같음)과 같은 세 문자로 이루어진 비교 연산자를 이용하여 대문자와 소문자를 비교해 보자,

IF /i 22 LSS 027 ECHO 22 is less than 027.

위 예제는 10진수 22가 8진수 027보다 작으면 뒤따르는 문자열을 출력하라는 문자열 비교문입니다.

그러면 다음과 같은 두 가지 예문은 어떻게 작동할까?

IF /i abc LSS ABC ECHO abc is less than ABC.
IF abc LSS ABC ECHO abc is less than ABC.

우선 1행은 아무런 출력이 없다. 왜냐하면 /i 선택자 때문에 대문자와 소문자를 무시하고 비교했기 때문이다. 그러나 2행은 소문자 abc가 대문자 ABC보다 더 작은 값으로 해석되어 문자열 "abc is less than ABC."을 출력해 준다.

IF ABC GTR abc ECHO ABC is greater than abc.

마찬가지로 위의 코드는 대문자 ABC가 소문자 abc보다 더 큰 값으로 해석되어 "ABC is greater than abc."라는 문자열을 출력해 준다.

위와 같이 대문자와 소문자 비교에서 대문자가 소문자보다 더 크다고 판정함을 알 수 있다.

예제 3

그 다음으로 문자간 비교를 해볼 수 있다.

IF d GTR a ECHO D is greater than A.

위의 예제는 문자여을 출력해 준다. 다시 말해 문자열 d가 문자열 a보다 더 큰 값을 가진다고 판단함을 알 수 있다. 반대로 아래와 같은 비교문도 성립한다.

IF a LSS d ECHO a is less than d.

로마자 알파벳을 비교할 때 순서가 빠른 문자를 더 작다고 판단함을 알 수 있다.

IF 가 LSS 나 ECHO 가 is less than 나.

한글 문자열을 비교할 때도 성립한다.

IF 가 LSS d ECHO 가 is less than d.

한글을 로마자보다 더 작다고 판정하고 있다.

과제

아무도 검사하지 않는 과제가 또 나왔습니다. 헤헤 ^^a

rem Compare.cmd
IF /i NOT %1 EQU %2 ECHO %1 is equal %2 ELSE ECHO %1 is not equal %2 .

위의 배치 파일이 정상적으로 작동하도록 고쳐 보자.

다음 예고

IF 명령을 하나씩 짚어보자. (4) : IF 명령확장

이 글은 스프링노트에서 작성되었습니다.

'스크립트 > 배치파일' 카테고리의 다른 글

GOTO 명령 (3)	2009.05.05
IF 명령 확장 (1)	2009.04.22
IF EXIST (0)	2009.04.15
IF ERRORLEVEL에 쓰이는 종료코드 (12)	2009.04.14
IF 기본 설명 (6)	2009.04.09

:

'로마자'에 해당되는 글 13건

한국어로 바꾸기 전

한국어로 바꾼 뒤

번역 및 편집 방법

압축 해제

메뉴 한글화

재압축

다운로드

관련 문서

내부 문서

외부 문서

'소프트웨어 > 한국어화' 카테고리의 다른 글

한국어로 바꾸기 전

한국어로 바꾼 뒤

번역 및 편집 방법

다운로드

관련 문서

내부 문서

외부 문서

'소프트웨어 > 한국어화' 카테고리의 다른 글

벌레의 유형

개발자의 답변

벌레의 발견

유니코드 지원이란?

'한컴오피스의 유니코드 지원'을 말한 사람은?

'한컴오피스의 유니코드 지원'은 Unicode Full Set일까?

벌레 분석

관련 벌레

관련 문서

내부 문서

외부 문서

'벌레와 팁 > 버그' 카테고리의 다른 글

벌레의 유형

개발자의 답변

벌레의 발견

준비 : 이전에 사용한 문자표의 문자 영역 재설정

앞서 입력한 문자가 유니코드 4자리일 때

앞서 입력한 문자가 유니코드 5자리 이상일 때

벌레 분석

관련 벌레

관련 문서

내부 문서

외부 문서

'벌레와 팁 > 버그' 카테고리의 다른 글

벌레의 유형

개발자의 답변

벌레의 발견

사례 1 살펴보기

사례 2 살펴보기

벌레 분석

관련 벌레

관련 문서

내부 문서

외부 문서

'벌레와 팁 > 버그' 카테고리의 다른 글

벌레의 유형

개발자의 답변

벌레의 발견

문자 코드의 코드 번호 붙여넣기 및 직접 입력

HNC 코드 붙여넣기

HNC 코드 직접 입력

유니코드 붙여넣기로 입력

유니코드 직접 입력

벌레 분석

비슷한 벌레

관련 문서

내부 문서

외부 문서

'벌레와 팁 > 버그' 카테고리의 다른 글

벌레의 유형

개발자의 답변

벌레의 발견

벌레의 원인

비슷한 벌레

관련 문서

'벌레와 팁 > 버그' 카테고리의 다른 글

벌레의 유형

벌레의 발견

문제가 발생하는 경우

문제 해결책