1. Redmine에서 직접 Git Repository를 생성할 수 있다.
2. GitHub와 유사하게 Redmine에서 Git Repository 접근을 위한 publickey를 등록할 수 있다.
3. Redmine 계정 기반으로 사용자들의 Git Repository 접근 권한을 편하게 관리할 수 있다.

아래 링크를 참고하시면 Redmine 설치는 10분 이내에 끝나니 여기서는 Gitolite와 Redmine+gitolite plugin설치 및 연동만 다룹니다.

• Redmine 공식 설치 가이드 :  http://www.redmine.org/projects/redmine/wiki/RedmineInstall

Gitolite 설치

Gitolite는 Gitosis와 유사한 ssh 기반의 Git server 관리툴입니다. Gitosis는 python으로, Gitolite는 perl로 구현되었다는게 조금 다를 뿐이죠. (Gitolite home: https://github.com/sitaramc/gitolite)

자세한 내용은 홈페이지를 참고하시고, 여기서는 빠른 설치를 위해서 속성으로 가이드하겠습니다. ^^

## install gitolite
git clone git://github.com/sitaramc/gitolite gitolite-source
cd gitolite-source
sudo mkdir -p /usr/local/share/gitolite/conf
/usr/local/share/gitolite/hooks
sudo src/gl-system-install /usr/local/bin
/usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks

## add user 'git'
sudo adduser --system --group --disabled-password --shell /bin/bash --home /opt/gitolite git

## generate key for admin
ssh-keygen -t rsa
cp ~/.ssh/id_rsa.pub /tmp/USERNAME.pub

## init gitolite
sudo -H -u git  gl-setup /tmp/USERNAME.pub

gitolite 초기화할 때 설정파일이 열리게 되는데 이때 아래처럼 repository의 umask 값을 바꿔줍니다.

# ------------------------------------------------------------------------------
# most often used/changed variables
# ------------------------------------------------------------------------------
$GL_WILDREPOS = 0;
$PROJECTS_LIST = $ENV{HOME} . "/projects.list";
#$REPO_UMASK = 0077;
#0077에서 아래처럼 0027로 바꿔줍니다.
$REPO_UMASK = 0027;

이렇게 umask값을 바꾸는건 redmine에서 gitolite repository를 읽을 수 있어야 하기 때문입니다. redmine이 실행되는 사용자 계정이 redmine이라면 아래처럼 git group에 추가시켜줍니다.

> sudo addgroup redmine git

그리고 ‘redmine’ user가 gitlite-admin repository에 접근할 수 있도록 아래와 같이 publickey를 추가합니다.

sudo -H -u redmine ssh-keygen
cp ~redmine/.ssh/id_rsa.pub /tmp/redmine.pub
git clone git@localhost:gitolite-admin.git
cd gitolite-admin
cp /tmp/redmine.pub keydir/

이제 gitolite-admin/conf/gitolite.conf 파일에도 redmine user로 gitolite-admin에 접근할 수 있도록  아래처럼 내용을 수정합니다.

repo    gitolite-admin
RW+     =       oddpoet redmine
repo    testing
RW+     =       @all

이제 gitolite-admin을 commit하고 push합니다.

git add .
git commit -m "add redmine user'
git push origin master

## 아래 명령이 잘 수행되면 성공!
sudo -H -u redmine git@localhost:gitolite-admin.git

Redmine-gitolite 설치

redmine-gitolite plugin은 redmine-gitosis(https://github.com/rocket-rentals/redmine-gitosis)에서 fork되었습니다만, original plugin도 그렇고 다수 fork들도 제 환경에서는 문제들이 많더군요. 그래서 제가 patch한 버전(https://github.com/odd-poet/redmine-gitolite)을 씁니다.

편의를 위해 redmine의 설치 경로가 ~/redmine/apps/redmine 이라고 가정하겠습니다.

# 필요한 gem 설치.
gem install lockfile 

# plugin 설치
sudo -H -i -u redmine
cd apps/redmine
script/plugin install git@github.com:odd-poet/redmine-gitolite.git
rake db:migrate_plugins

이제 rails만 재시작해주면 redmine>관리>플러그인 페이지에 redmine-gitolite 가 보이고 설정으로 들어가면 아래와 같은 화면을 볼 수 있습니다. 여기에 Repository 정보를 잘 입력해주시면 됩니다.

redmine_gitolite 설정

그리고 publickey는 내계정 페이지서 등록 및 관리할 수 있습니다.

publick_key 등록

debian/ubuntu package가 항상 조금씩 늦게 나오기 때문에 ruby 최신버전(현재 1.9.2-p136)을 사용해야 할 경우 source compile이 최선책이죠.
(참고:  debian package의 ruby-1.9.1은 실제로 ruby-1.9.2-p0입니다.)

그런데  source compile 해서 사용할때 의존성이 있는  library들 때문에 rails 등에서  문제가 발생하지요. 대략적으로 rails 환경을 위한 ruby source compile에 필요한 library는 다음과 같습니다.

• zlib
• openssl
• readline
• sqlite3

그래서 ruby source compile을 할 경우 아래와 갈이 관련 lib들을 먼저 설치해줘야 합니다.

$ sudo apt-get install build-essential libssl-dev libsqlite3-dev libreadline5-dev zlib1g-dev

그런 후에  아래처럼 ruby source를 compile하고, rails를 설치하면 rails를 위한 기본  환경설정이 끝납니다.

$ cd /tmp
$ mkdir src
$ cd src
$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p136.tar.gz
$ tar xzvf ruby-1.9.2-p136.tar.gz
$ cd ruby-1.9.2-p136
$ ./configure
$ sudo make && sudo make install

$ gem install rails

자신이 만든 ruby library를 gem으로 만들고 공개배포할 계획이 있다면 rubygems를 이용할 수 있습니다.
그러면 누구나 gem 명령어를 이용하여 내가 만든 gem을 설치할 수 있지요. 그럼 gem을 등록하고, 삭제하는 방법과 prerelease 버전으로 등록하는 방법을 알아봅니다.

gem 생성하기

NetBeans에서 ruby project를 만들면 기본 Rakefile 템플릿을 만들어줍니다만, 없으면 만들면 되지요. ^^
대충 아래처럼 프로젝트 루트에 Rakefile을 생성합니다. 설정 세부 사항은 Gem::Specification Reference 를 참조하시면 됩니다.

require 'rubygems'
require 'rake'
require 'rake/clean'
require 'rake/gempackagetask'
require 'rake/rdoctask'

spec = Gem::Specification.new do |s|
  s.name = 'sample' # gem name
  s.version = '1.0.0' # version
  s.extra_rdoc_files = ['README', 'LICENSE']
  s.summary = 'simple description'
  s.description = "description'
  s.author = 'my name'
  s.email = 'abc@gmail.com'
  s.files = %w(LICENSE README) + Dir.glob("{lib}/**/*")
  s.require_path = "lib"
end

Rake::GemPackageTask.new(spec) do |p|
  p.gem_spec = spec
  p.need_tar = true
  p.need_zip = true
end

이제 shell에서 ‘rake gem’ 이라고 타이핑하시면 gem파일이 ‘sample-1.0.0.gem’이라는 이름으로 생성됩니다.

rubygems.org 에 등록하기

rubygems.org에 등록하기 위해서는 rubygems.org에 계정이 있어야합니다. 계정을 만드셨다면 이제 shell에서 gem push 명령으로 간단하게 등록하실 수 있습니다.

> gem push sample-1.0.0.gem
email address:
password:

이메일 주소와 비밀번호를 물어보는데 rubygems에 가입할 때 사용했던 이메일과 비밀번호를 입력하면 됩니다. 수 분뒤에는 rubygems 에서도 등록된 나의 gem을 확인할 수 있고 shell에서  ’gem list -r’ 명령으로도 확인해볼 수 있답니다.

rubygems.org에서 gem 삭제하기

rubygems.org의 dashboard를 아무리 뒤져봐도, gem help를 아무리 뒤져봐도 등록했던 gem을 삭제하는 방법은 보이지 않습니다. 구글링을 해보니 yank라는게 있더군요. gem 1.3.5 버전 이후부터 가능하니 gem update를 하시고 gemcutter라는 gem을 설치하면 gem을 삭제할 수 있습니다.

> gem update --system # gem 자체 업데이트
> gem install gemcutter # gemcutter 설치
> gem yank -h # gem yank help
> gem yank sample -v 1.0.0

잘못 등록한 gem은 이런 방법으로 삭제하시면 됩니다. (버전 단위로만 삭제할 수 있습니다.)

prerelease 버전으로 gem 올리기

언제부터인가 gem install 시에 –pre 옵션이 생겼지요. 개발 중인 버전을 미리 배포할 경우 일반적인 gem list, install 명령으로는 prerelease 버전의 정보를 보거나 설치할 수 없습니다. ‘–pre‘ 옵션을 줄 때만 설치하거나 정보를 확인할 수 있지요.

prerelease 버전으로 gem을 등록하는 방법을 한참 찾아헤맸으나 관련 문서를 찾지 못했답니다. 그러나 어느 뉴스그룹에 올라온 게 있더군요. 그냥 버전을 붙일때 숫자가 아닌 문자를 쓰면 된답니다. 즉, ’1.0.0′ 대신 ’1.0.beta1′ 이런 식으로 패치버전 부분에 숫자대신 문자를 사용해서 gem을 만들고 등록하면 됩니다.

spec = Gem::Specification.new do |s|
  s.name = 'sample'
  s.version = '1.1.beta1' # 이렇게 써서 gem을 만들면 prerelease 버전이 됨.
  ...
end

RadRails는 이클립스 기반 IDE답게 느리고 무겁고, TextMate는 수년간 업데이트도 없는데다가 cucumber/rspec 을 이용하면서 한글 사용할 일이 많아졌는데 한글입출력이 많이 불편하지요. NetBeans의 경우 많이 무겁지도 않고, 기능상으로도 꽤나 괜찮은 편이라서 Ruby IDE로 개인적으로 추천할 만 하네요. (IntelliJ기반의 RubyMine은 30일 평가판을 쓸 수 있지만, 기본적으로 유료라서 써보질 않았네요.)

Netbeans 6.9.1 기준으로 Windows / Ruby 1.9 환경에서 필요한 설정들을 정리해봅니다.

Ruby 1.9 설치

Netbeans에 내장된 Ruby는 JRuby이므로 아직 완전하게 Ruby1.9를 지원하지 않습니다. 따라서, 별도로 Ruby1.9를 설치하는 것이 좋습니다.

Windows환경을 위한 인스톨러는  RubyInstaller(http://rubyinstaller.org/)에서 구하실 수 있습니다. 단, 2010/08/19  기준으로 ruby 1.9.1p378 버전을 사용하시는 것이 좋습니다. 아직은 p400번대 버전들이 문제가 많습니다.

인코딩 설정

요즘은 Linux이던 Mac이던 콘솔환경 자체도 UTF-8을 쓰는게 대세입니다만, 한글 Windows의 경우 cmd창은 기본적으로 ‘EUC-KR’을 사용합니다. 따라서 Netbeans에서의 Output에 한글이 있을 경우 처참히 깨집니다.

NetBeans의 설치폴더(default: C:\Program Files (x86)\NetBeans 6.9.1\) 의 etc/netbeans.conf 파일을 열어보면 netbeans_default_options="...." 라고 되어 있는 라인에 -J-Dfile.encoding=UTF-8를 추가해줍니다.

# encoding 설정을 추가함.
netbeans_default_options="... -J-Dfile.encoding=UTF-8"

Ruby 1.9에서 파일을 UTF-8 인코딩으로 작성할 경우, 파일 첫 라인에  # coding: utf-8 이라는 매직 코맨트를 써주어야 합니다.

# coding: utf-8
# 반드시 첫라인에 인코딩 설정이 있어야 합니다.

class KoreanSample
  def 한글_메소드
    puts "헬로우 월드"
  end
end

KoreanSample.new.한글_메소드

(참고) Ruby  1.8의 경우에는 ruby 실행 옵션으로 ‘-Ku’를 주셔야 합니다. 따라서 ‘Project Propetries > Run’ 의 Ruby options: 에 ‘-Ku’를 넣어주시면 됩니다.

Debuging 설정

Netbeans에서 Ruby debuggin을 하기 위해서는  ruby-debug, ruby-debug-ide gem이 필요합니다. Ruby 1.9의 경우에는 ruby-debug19, ruby-debug-ide19 gem이 필요하지요.

그러나 Windows 환경에서는 ruby-debug19, ruby-debug-ide19 gem을 설치할 때 native compile 관련 문제로 정상적으로 설치가 되지 않습니다. 따라서 이 gem들을 설치하기 위해서는 RubyInstaller for windows(http://rubyinstaller.org/) 에서 devkit을 추가로 설치하셔야 합니다.

devkit 설치

1. RubyInstaller 다운로드  페이지(http://rubyinstaller.org/downloads/)에서 devkit을 다운로드 받아서, Ruby설치폴더(e.g. C:\Ruby191)에 압축을 풉니다.
2. 그리고 devkit\msys\1.0.11\tec\fstab (e.g. C:\Ruby191\devkit\msys\1.0.11\etc\fstab) 파일을 열어서, 경로 설정을 자신의 환경에 맞게 수정합니다.
3. cmd 창에서 아래와 같이 입력하여, 정상적으로 결과가 표시되는지 확인합니다. 아래처럼 autoconf의 경로가 정상적으로 나오지 않으면 뭔가 잘못된 겁니다.

   C:\Users\oddpoet> sh which autoconf
   /usr/local/bin/autoconf

Ruby debug gem 설치

이제 ruby debug gem들을 설치할 수 있습니다.

C:\Users\oddpoet> gem install ruby-debug19 ruby-debug-ide19
...[이제 정상설치된다]...

Netbeans를 다시 실행하면 Ruby1.9에서도 Fast debug engine이 정상적으로 동작하게 됩니다.

이제 Netbeans에서 Ruby1.9를 문제없이 사용하실 수 있습니다. 저는 요즘 RSpec 2.0 beta 버전을 사용해서 테스트를 작성하고 있는데, 아직 RSpec2는 Netbeans에서 정상 이용이 안되네요. RSpec2가 정식 릴리즈되는 9월 이후를 기다려봐야 겠습니다.

(추가)
2010.08.22에 릴리즈된 ruby-debug-base19 (ver0.11.24)가 정상적으로 설치되지 않습니다. 따라서 아래와 같이 ruby-debug-base19의 v0.11.23버전을 설치하신 후에 ruby-debug-ide19를 설치하시기 바랍니다.

C:\Users\oddpoet> gem install ruby-debug-base19 -v=0.11.23
C:\Users\oddpoet> gem install ruby-debug19 ruby-debug-ide19

참고로 BDD(Behaviour Driven Development)를 일반적으로 ‘행위주도개발’이라고 번역하는 듯하지만, 문맥상 Behavior를 ‘행위’로 번역할 경우 의미전달이 힘든 부분이 있어서 ‘기대행동(Behavior)’라고 번역/표기했습니다.
사실 길지 않은 글이니 원문을 읽어보시는 걸 권장합니다. (발번역이라 죄송~)

A New Look at Test Driven Development

Test Driven Development (TDD)는 요즘 전성기를 맞고 있다. 큰 회사들은 개발자들이 TDD를 교육하는데 많은 돈을 쓰고 있으며, 컨퍼런스에도 TDD는 단골주제다. 내 책(Test-Driven Development: A Practical Guide)은 Jolt award를 수상했다. 모든게 잘 되어 가는 것 같다. TDD를 적용한 모두가 TDD를 완전히 이해하고 있고, 그로 인한 혜택을 누리고 있다. 정말 그런가?

우울한 현실 (Fat Chance!)

내가 얘기해본 10% 정도의 사람들만 TDD가 무엇인지 이해하고 있다. 사실 5% 정도밖에 안될지도… 어디서 잘못된걸까? 사람들은 TDD를 “test”에 대한 것이라고 생각한다. “case”라고 생각하지 않는다는 거다.

조금 비슷하기는 하지만, 일반적으로 사람들은 TDD를 low level의 회귀테스트 정도로 본다. 그런데 그건 TDD의 부수적인 이익 정도에 불과하다. 왜 이런 일들이 비일비재하게 일어나는 걸까? 잠깐 과거로 돌아가보자. 만약 “my old Coad Letter” 의 예전 이슈들을 봤다면, 그곳에서 TDD의 배경이 되는 것들을 찾을 수 있다.

원래 XP는 깨질 수 있는 모든 것들을 테스트한다는 원칙을 가지고 있었다. 그리고 XP의 테스팅 관습은 Test Driven Development로 진화했다.
XP originally had the rule to test everything that could possibly break. Now, however, the practice of testing in XP has evolved into Test-Driven Development.

그들이 테스트를 작성하는 것에 대해 얘기하던 그 시절을 생각해보면, 왜 TDD가 테스트 중심의 어휘들을 가지게 되었는지를 상상할 수 있다. 그리고 이게 사람들이 TDD가 테스트가 목적이라고 생각하게된 이유이다. 그들이 TestCases, TestSuites, Tests 등에 대해 얘기했고, 메소드 이름을 “test”로 시작하게 했기 때문이다. jUnit의 경우 그렇다. nUnit은 test로 메소드 이름이 시작해야 한다는 제약은 없다. (역주: JUnit도 annotation을 활용하게 되면서 이제 method 이름에 대한 명명제약은 없어졌지요.)

결국 TDD로 진화하면서 우리는 전혀 다른 종의 동물을 만들어 냈다. 원래 XP 관습은 깨질 수 있는 모든 것들에 대한 테스트를 작성하는 것이었다. 그래서 테스트를 먼저 작성하는 것에서 시작했고, 결국 TDD가 되었다. 그러나 TDD는 사람들이 생각하는 것처럼 최종점이 아니다. TDD는 단지 다음 단계를 위한 발판일 뿐이다.

사실 “unit”이라는 단어가 가장 큰 문제다. 그 이유는 첫번째로 “unit”은 막연한 용어라는 점이고, 두번째로는 그 단어가 코드의 구조적 분할을 의미한다는 점이다. 그래서 사람들은 method나 class를 테스트해야 한다고 생각한다. 우리는 unit에 대해서 생각해야 하는게 아니고, 기대행동(behavior)의 관점에서 생각해야 한다.

unit test에 대한 이런 생각들은 우리들이 코드의 구조에 따라 테스트를 나누도록 한다. 예를 들면, product class들과 test class들이 1:1 관계를 만드는 것이다.

그건 우리가 원하는 게 아니다. 실제로는 기대행동(behaviour) 단위로 나누는 것이 필요하다. 또한 일반적인 unit test보다 더 작은 단위의 레벨에서 작업하는 것이 필요하다. 우리는 작은 단위의 기대행동들에 초점을 맞추어, 매우 작은 단위로 작업해야 한다. 예를 들면, “리스트가 비어 있을 때[Given], 객체에 대해 add() 메소드가 호출되면[When], 리스트에는 하나만 들어있어야 한다[Then].”에서 메소드는 매우 특정 상황(context)에서 특정 매개변수와 함께 호출되고, 매우 특정한 결과가 만들어지는… 이렇게 하나의 메소드에 대해 더 작은 단위로 작업해야 한다.

이것이 바로 “테스트”라는 관점에 의해서 가려져버린 고대의 아이디어이다. 왜 이렇게 되었을까? 사람들이 “Test”에 대해 어떻게 생각하는지 보자.

개발자들은 보통 이렇게 생각한다: “난 모든 테스트를 작성할 생각은 없어”, “이건 매우 단순한 코드라서 테스트할 필요가 없거든”, “테스트는 시간 낭비야”, “난 이미 많이 해봤어”.

프로젝트 매니져들은 이렇게 생각한다: “테스트는 코드가 다 만들어 진 후 하는거야”, “우리는 테스팅할 사람들이 따로 있어”, “당장 거기에 쏟을 시간은 없어”….

사람들은 테스팅에 대한 생각은 이렇게도 부정적이고, 하지 않을 이유를 쉽게도 찾아낸다. 특히나 시간이 없고, 압박이 심한 경우는 더욱….

TDD가 테스트가 아니라면, 뭔데? (So if it’s not about testing, what’s it about?)

TDD는 실제 코딩을 하기 전에 무엇을 만들 것인지 생각해보는 작업이다. 즉, 간략하고, 모호하지 않으며, 실행가능한 형태으로 기대행동(behavior)들을 보다 작은 단위로 명세화(specification)하는 과정이다. 이 과정은 테스트를 작성하는 것일까? 아니다. 이것은 코드가 무엇을 해야하는지에 대한, 명세(specification)을 작성하는 것이다. 그래서 이것은 코드를 작성하기 전에 작성하는 것이 좋다. 더 많은 명세들이 해야할 일을 더 명확히 해주기 때문이다. TDD의 기본 방식대로 조금씩 점진적으로 작업한다. 기대행동(behavior)들을 작은 단위로 명세화하고, 그리고 그것을 구현한다.

이제 TDD가 테스트를 작성하는 것이 아니라, 기대행동(behavior)에 대한 명세에 대한 것이라는 걸 알았다면 관점이 바뀔 것이다. 각 product class마다 test class를 만든다거나, 어떤 method에 대한 test method를 만들어서 테스트한다던가 하는 일들이 얼마나 어이없는 일인지 느껴질 것이다.

그럼 무엇을 할까?(So What to do?)

test라는 관점에서 생각하지 않으려고 해도 JUnit은 그걸 어렵게 만든다. 그럼 이런 일에 걸맞는 새로운 프레임웍이 있을까? ThoughtWorks의 Dan North는 jBehave 라는 프로젝트를 시작했다.

기대행동(behavior) 중심의 어휘와 개념들을 사용하는 행동 중심의 프레임웍을 사용하면, 기대행동(behavior)에 대한 명세로써 생각하는데 도움이 된다.

기대행동 명세 프레임웍(A Behaviour Specification Framework)

기대행동(behavior)에 대한 명세는 어떤 모습이어야 할까? 다음과 같은 부분에서는 jUnit과 같은 것들과 비슷해야 할 것이다.

1. 충분히 잘 동작한다.
2. 모든 사람들에게 익숙한 형태이다.

가장 큰 차이는 어휘(vocabulary)이다. TestCase를 상속받는 것이 아니라, Context를 상속받는다. 그리고 method를 쓸때 test가 아니라, should로 시작하는 이름을 사용한다. 검증에는 assertions(e.g. assertEquals(exp, act)) 대신, shouldBeEqual(act, exp) 같은 어휘들을 사용한다.

Smalltalk와 Ruby의 경우, class library 안으로 이런 framework을 내장시키는데 좀더 용이하다. 예를 들면, ‘actual shouldEqual: expected‘ 나, ‘result shouldBeNull‘, ‘[2/0] shouldThrow: DivideByZeroException‘ 과 같은 형태로 쓰는 것이 가능하다.

현재 진행 상황은…(What Now?)

앞에서 얘기한 대로 Dan North는 기대행동(behavior) 명세를 위한 junit 대체물로 jBehave 프로젝트를 시작했다. 나도 조금 다른 방법으로 그 프로젝트에 참여할 것이다. 나는 Smalltalk와 Ruby에서 이러한 아이디어들을 적용해볼 계획을 가지고 있고, 행위기반의 jUnit 버전을 위한 작업을 진행중이다.

요약

TDD에 대해 알고 있는 모든 것이 무용지물이 된다는 얘기인가? 아니다. TDD의 모든 기술을은 BDD에도 적용가능하다. 행위를 기술한다는 접근에서 이것은 TDD와 같다. 여전히 mock을 사용할 수도 있다. 바뀐 것은 어휘와 관점이다.

관점은 매우 중요하다. 프로세스의 가치가 어떻게 바뀌었는가? 다수의 ‘sould’를 사용하며, should method의 이름들은 보다 명세를 명확하게 해줄 것이다. 예를 들면…

• shouldAllowValidUser
• shouldCheckIsValidBeforeUpdate
• shouldUpdateRecordSet
• shouldWriteToUpdateLog

요약하면…

1. TDD에 대한 문제는 우리들이 서로 다른 방향을 바라보고 있었다는 것이다. 틀린 방향을…
2. 우리는 검증 테스트(verification test)가 아니라, 기대행동 명세(behavior specifications)를 생각하는 것에서 시작할 필요가 있다.
3. 클래스나 메소드에 대한 테스트라는 관점보다, 각각의 기대행동(behavior)의 관점이 더 명확해지므로써, 실행가능한 문서를 가질 수 있게 된다는 잇점이 있다.
4. TDD가 생겨난 이후 어느 누구도 그 이름의 의미를 바꾸거나, 우리가 기대하는 바를 바꾸지 않았다. 그래서 우리는 이 새로운 작업 방식에 BDD:”Behaviour Driven Development” 라는 새로운 이름을 사용하려고 한다.

최근 Ruby와 Rails를 공부하고 있는데, Ruby의 Symbol이라는 게 잘 이해가 되지 않았다.
기존에 내가 배웠던 언어들 중에는 그와 비슷한게 없었던 터라 도무지 감이 안 잡혔다.
구글링 결과 대략 감을 잡았으니, Ruby Symbol의 정체에 대해 간단히 정리해본다.

String vs. Symbol

puts :hello  #symbol
puts "hello"   #string

위의 두 문장 모두 ‘hello’라는 문자열을 출력한다. 이런 이유로 Symbol을 String의 오리타입(duck type) 클래스로 오해하기도 한다. 하지만, 아래 코드를 보면 알겠지만, Symbol은 절대로 String이 아니다.

puts :hello.size  # NoMethodError
puts :hello[0,2]  # NoMethodError
puts "hello".size  #5
puts "hello"[0,2]  # "he"

Symbol이 String의 사촌 쯤으로 오해받는 것은 Symbol을 immutable string 용도로 많이 사용하기 때문이다. 나처럼 기존 다른 언어에서 Symbol을 써본적이 없는 사람이라면, 대충 예제코드들을 보면서 그렇게 생각할 가능성이 매우 높다.

Java등의 언어에서는 String이 immutable Class이므로 Hash의 키로 사용했을 경우 그다지 문제될 것이 없지만, Ruby에서는 String이 mutable class이므로 Hash의 키로 쓰일 때, 키로 쓰인 객체의 값이 변경될 경우 rehash 메소드를 호출해줘야 하는 경우가 생긴다. 따라서 Ruby에서는 가능하면 Hash의 키로 String대신 Symbol을 쓰는 것을 선호한다. 그러니 나 같은 놈은 처음부터 Symbol = Immutable String 으로 이해하고는 그 뒤부터는 미궁으로 빠져버린다.

Symbol을 그 정의대로 ‘이름을 가진, 그리고 그 이름에 대해서 유니크(unique)한 객체‘이다. String이 따옴표로 둘러쌓인 문자열로 표기되듯이, Symbol은 :name의 형태로 표기되며, name이 문자열로 표기될 수 있지만 그 자체는 String이 아닌 Symbol객체이다. 그리고 아래 코드에서 보여지듯이, 특정 이름을 갖는 Symbol 객체는 유일하다.

puts :hello.class   # Symbol
puts "hello".class   # String
puts :hello.object_id == :hello.object_id   # true
puts "hello".object_id == "hello".object_id   #false

Symbol의 용도

그렇다면 Symbol은 언제 사용하는 것이 좋을까?
Ruby의 String이 mutable 객체이므로, 성능상의 이유로 Symbol이 immutable string의 대체물로 사용되곤 하지만, Symbol은 garbage collect가 되지 않으므로 자칫하면 메모리 누수가 발생할 수 있음을 유의해야 한다. 대충 아래와 같은 용도로 사용하는 것이 추천된다.

1. 메소드의 argument list에 옵션 키워드의 이름

   link_to 'Show', :action=>'show', :id= product

2. C의 enum와 같은 값을 표현할 때

    /* C code*/
   enum BugStatus { OPEN, CLOSED };
   BugStatus original_status = OPEN;
   BugStatus current_status  = CLOSED;

   # Ruby
   original_status = :Open
   current_status= :Closed

3. Hash의 키 이름

   foo = {
   :host => 'localhost',
   :port => 80 }

특히 위 3번의 예는 String을 사용하는 아래의 예보다, Symbol이 사용자 정의 식별자(user defined identifier)로 사용됨으로써 코드의 의도가 명확히 드러난다 점에서도 더 낫다.

# String을 사용한 경우, 속성-값의 관계가 덜 명확해 보인다.
foo = {
'host' => 'localhost',
'port' => 80}

Reference

• 13 Wasy of Looking at a Ruby Symbol
• Symbols are not immutable strings
• Using Symbols for wrong reason
• Understanding Ruby Symbols

다른 대안을 찾다가 RVM(Ruby Version Manager)라는 멋진 녀석을 찾았습니다.
당분간 1.8.x, 1.9.x 사이를 오가면서 놀텐데 RVM으로 각 루비 버전들을 설치 및 관리하면 편할 것 같습니다.

RVM 설치

설치는 매우 간단합니다.

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

쉘에서 위와 같이 입력하고, .profile 마지막에 아래 라인을 추가해주면 됩니다.

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

Ruby 설치

원하는 Ruby 버전은 쉘에서 다음과 같이 입력하여 설치할 수 있습니다.

# MRI 1.9.1 버전 설치
rvm install 1.9.1

# MRI 1.8.7-p160 버전 설치
rvm 1.8.7-p160

# MRI 1.8.7-p174 버전 설치
rvm 1.8.7-p174  

# JRuby 설치
rvm install jruby

패치버전 단위까지 따로 관리할 수 있고, 공식 버전(MRI), JRuby, IronRuby 등등 다양한 Ruby Interpreter를 지원합니다.

사용할 Ruby 변경하기

# 설치된 ruby 목록 보기
rvm list

# ruby 변경하기 (현재 쉘에서만)
rvm 1.9.1

# 기본 ruby 변경하기
rvm 1.9.1 --default

# 시스템 기본 ruby 사용하기
rvm system --default

macport와는 별도로 ruby 패키지를 관리한다는게 썩 내키지는 않지만, 여러 버전의 ruby를 간편하게 관리하고 스위칭할 수 있으니 좋네요. 그리고 기본적으로 ~/.rvm/ 밑에 소스 및 설치파일들을 관리하기 때문에 서버에서 rvm에 의한 영향을 특정 계정으로 한정지을 수 있다는 점도 장점일 수 있겠습니다.

간만에 Ruby 세상으로 돌아오니 좋군요. ^^

문제상황

하지만 XStream은 Object의 property 값이 null 인 경우에는 해당 property를 serialize 하지 않습니다. 예를 들면…

@XStreamAlias("Person")
class Person {
	public String firstName;
	public String lastName;
	public String middleName;
}
......
Person jobs = new Person();
jobs.firstName = "Steve";
jobs.lastName = "Jobs";

XStream xstream = new XStream();
xstream.processAnnotations(Person.class);
String xml = xstream.toXML(jobs);
System.out.println(xml);

위와 같은 코드는 아래와 같은 XML을 출력하게 됩니다.

  Steve
  Jobs
  

해결방법(XML) : Converter 구현

null value serialize를 위해서 여러가지 접근 방법이 있겠지만, Converter를 구현해서 사용하는게 가장 심플합니다.
아래코드는 null value를 빈 element로 변환하도록 하는 Converter 구현입니다.

/**
 * NullConverterHack.
 *
 *


 * {@link XStream}으로 serialize 할때 기본적으로 null value를 skip처리하므로,
 * 빈 엘리먼트를 삽입하도록 하는 {@link Converter} 클래스임.
 * 

 *


 * 아래와 같은 형태로 사용한다. 반드시 LOW PRIORITY로 사용해야 함.
 * 
 *  xstream.registerConverter(new NullConverterHack(xstream.getMapper()), XStream.PRIORITY_LOW);
 * 
 * 

 *
 * (주의) unmarshal을 지원하지 않는다.
 *
 * @see JsonWriterHack Json으로 serialize 할 경우에는 {@link NullConverterHack}과 {@link JsonWriterHack}을 함께 사용한다.
 * @author oddpoet
 */
public class NullConverterHack implements Converter {
	private Mapper mapper;

	public NullConverterHack(Mapper mapper) {
		this.mapper = mapper;
	}

	/**
	 * 모든 클래스에 대해서 작동.
	 *
	 * @param type
	 * @return
	 * @see com.thoughtworks.xstream.converters.ConverterMatcher#canConvert(java.lang.Class)
	 */
    @SuppressWarnings("unchecked")
	public boolean canConvert(Class type) {
        return true;
    }

    /**
     * marshalling.
     *
     * @param source
     * @param writer
     * @param context
     * @see com.thoughtworks.xstream.converters.Converter#marshal(java.lang.Object, com.thoughtworks.xstream.io.HierarchicalStreamWriter, com.thoughtworks.xstream.converters.MarshallingContext)
     */
    public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) {
    	Field [] fieldSet = source.getClass().getDeclaredFields();

		for (Field field : fieldSet) {
    		Object member;

			if (!mapper.shouldSerializeMember(source.getClass(), field.getName())) {
    			continue;
			}

    		field.setAccessible(true);
			try {
				member = field.get(source);
				String name = mapper.serializedMember(field.getDeclaringClass(), field.getName());

				if (member == null) {
	    			writer.startNode(name);
	    			// 값이 null이면 내용은 채우지 않고 startNode(), endNode()만 호출
	    			writer.endNode();
	    		} else {
	    			ExtendedHierarchicalStreamWriterHelper.startNode(writer, name, member.getClass());
	    			context.convertAnother(member);
	    			writer.endNode();
	    		}
			} catch (IllegalArgumentException e) {
				e.printStackTrace();
			} catch (IllegalAccessException e) {
				e.printStackTrace();
			}

    	}
    }

    /**
     * unmarshal을 지원하지 않는다.
     *
     * @param reader
     * @param context
     * @return
     * @see com.thoughtworks.xstream.converters.Converter#unmarshal(com.thoughtworks.xstream.io.HierarchicalStreamReader, com.thoughtworks.xstream.converters.UnmarshallingContext)
     */
    public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) {
        return null;
    }
}

Converter 구현 코드가 길지 않으니 자세한 설명은 생략하겠습니다. 실제 사용방법은 아래와 같습니다.

Person jobs = new Person();
jobs.firstName = "Steve";
jobs.lastName = "";
jobs.middleName = null;

XStream xstream = new XStream();
// Converter를 등록한다. 단, PRIORITY_LOW로 등록하도록 한다.
xstream.registerConverter(new NullConverterHack(xstream.getMapper()), XStream.PRIORITY_LOW);

xstream.processAnnotations(Person.class);
String xml = xstream.toXML(jobs);
System.out.println(xml);

위와 같은 방법으로 객체를 XML로 serialize 하면 아래와 같은 결과를 얻을 수 있습니다. 공백문자와 null이 다른 형식으로 표현되고 있음에 유의하세요.

  Steve
   
   

JSON의 경우

위와 같이 Converter를 추가해서 사용할 경우 XML 변환시 null 값에 대한 빈 element 출력은 가능합니다만, JSON 출력의 경우 아래와 같이 null 이 아닌 빈 객체({})로 출력되는 문제가 있습니다.

Person jobs = new Person();
jobs.firstName = "Steve";
jobs.lastName = "";
jobs.middleName = null;

XStream xstream = new XStream(new JsonHierarchicalStreamDriver() {

	@Override
	public HierarchicalStreamWriter createWriter(Writer out) {
		return new JsonWriter(out, JsonWriter.DROP_ROOT_MODE | JsonWriter.STRICT_MODE);
	}

});
xstream.registerConverter(new NullConverterHack(xstream.getMapper()), XStream.PRIORITY_LOW);
xstream.processAnnotations(Person.class);
String xml = xstream.toXML(jobs);
System.out.println(xml);

즉 위와 같은 코드는 아래와 같은 JSON을 출력하게됩니다. null 대신 {}이 출력되지요.

{
  "firstName": "Steve",
  "lastName": "",
  "middleName": {}
}

Conveter의 Interface를 보면 알 수 있겠지만, JSON 출력시의 null 문제를 풀기 위해서는 Conveter 레벨에서 처리가 안됩니다. 결국 Writer 레벨에서 null 처리를 해야합니다. 그런데 기존 JsonWriter를 상속받아서 해결할 수 없기 때문에, 깔끔하지는 않지만 기존 JsonWriter 소스를 복사해서 새로운 클래스를 만들고 관련된 부분을 수정합니다. 수정해야할 부분은 endNode() 함수입니다. (아래 소스 참고)

/**
 * JsonWriterHack.
 *
 *


 * XStream 패키지에 있는 {@link JsonWriter}에 수정을 가한 클래스이며, (상속받아서 해결 불가능함)
 * {@link NullConverterHack}과 함께 사용할 경우, null 값을 Json의 null로 변환해준다. 당연히 공백문자열("")과는 구분된다.
 * 

 *


 * 수정된 부분은 {@link #endNode()} 함수이며, 수정한 부분에 comment를 달아놓았다.
 * 하지만 변경된 JsonWriter에 의해 사용시 예기치 못한 JSON 변환이 이루어질 수 있으므로, 주의하도록한다.
 * 

 *
 * @see NullConverterHack {@link NullConverterHack}과 함께 사용해야 한다.
 * @author oddpoet
 */
public class JsonWriterHack implements ExtendedHierarchicalStreamWriter {
	// ... 나머지 코드는 JsonWriter와 동일하게 그대로 두고, endNode() 함수만 수정한다.
	public void endNode() {
		depth--;
		Node node = (Node)elementStack.pop();

		if (node.clazz != null && node.isCollection) {
			if (node.fieldAlready) {
				readyForNewLine = true;
			}

			finishTag();
			writer.write("]");
		} else if (tagIsEmpty) {
			readyForNewLine = false;
			writer.write("null");  // <- 이부분을 수정. 원래는 writer.write("{}"); 였음.
			finishTag();
		} else {
			finishTag();

			if (node.fieldAlready) {
				writer.write("}");
			}
		}

		readyForNewLine = true;

		if (depth == 0 && ((mode & DROP_ROOT_MODE) == 0 || (depth > 0 && !node.isCollection))) {
			writer.write("}");
			writer.flush();
		}
	}
	// 나머지 코드는 그대로 유지...
}

자 그럼, JsonWriter 대신 위에서 만든 JsonWriterHack으로 대체하면 원하는 null 출력을 볼 수 있습니다.

Person jobs = new Person();
jobs.firstName = "Steve";
jobs.lastName = "";
jobs.middleName = null;

XStream xstream = new XStream(new JsonHierarchicalStreamDriver() {

	@Override
	public HierarchicalStreamWriter createWriter(Writer out) {
		return new JsonWriterHack(out, JsonWriterHack.DROP_ROOT_MODE | JsonWriterHack.STRICT_MODE);
	}

});
xstream.registerConverter(new NullConverterHack(xstream.getMapper()), XStream.PRIORITY_LOW);
xstream.processAnnotations(Person.class);
String xml = xstream.toXML(jobs);
System.out.println(xml);

{
  "firstName": "Steve",
  "lastName": "",
  "middleName": null
}

Json에서의 null serialize 의 경우, 기존 구현체를 Rewrite해야해서 그다지 깔끔한 방법은 아닙니다. XStream으로 JSON 출력제어를 하는데 제약이 있으므로, 다른 object – JSON 매핑 library를 사용하는게 좋을 수도 있습니다.

가정

1. 한글 인코딩은 UTF-8, EUC-KR(MS949) 만 고려합니다.
2. EUC-KR과 MS949가 동일한 character set은 아니지만, MS949가 EUC-KR의 확장이므로 이 글에서는 동일하게 취급합니다.
3. UTF8에 대해서는 국내에서 일반적인 다국어 환경(한글/영어 등)만 가정합니다.

Byte array 얻어내기

UTF-8 으로 encoding된 byte array를 EUC-KR로 decoding해서 String 객체를 생성해버리면(반대의 경우도 마찬가지), 최상위 비트가 이미 손실된 상황이므로 String 객체 만으로는 한글 인코딩을 바꿔 다시 디코딩할 방법이 없습니다. 따라서 request parameter의 한글인코딩을 판단하고, 그에 맞는 적절한 인코딩 방법으로 parameter에 대한 String 객체를 생성하기 위해서는 우선적으로 parameter에 대한 String 객체가 아닌 byte array를 얻어낼 수 있어야 합니다.

그런데 문제는 HttpServletRequest에 request에 대한 byte array를 얻어낼 인터페이스가 없다는 점이죠. GET method의 Request의 경우 URL 정보에서 직접 파라메터를 파싱해내는 방법도 적용해볼 수 있지만, POST method의 요청에서는 그것도 불가능합니다. 게다가 GET인 경우에도 IE계열의 경우에는 uri encoding도 하지 않은 채로 보내주는 막강센스를 보여주기 때문에 로직이 좀 짜증이 납니다.

그래서 byte array를 얻어내기 위해서 저는 request에 characterEncoding을 “ISO-8859-1″ 를 사용합니다. 그렇게 하면, String에서 원래 byte array를 얻어낼 수 있습니다.

byte [] barray; // EUC-KR encoded byte array
...
String ko2 = new String(barray, "ISO-8859-1");
byte [] barray2 = ko.getBytes("ISO-8859-1");
// barray2 is same as barray.

String ko2 = new String(barray, "UTF-8");
byte [] barray3 = ko2.getBytes("UTF-8");
// barray3 may be not same as barray.

tomcat의 경우 HttpServletRequest 객체에 처음으로 getParameter() 메소드를 호출할 때, paramter들의 파싱이 이루어지므로 첫번째 Filter에서 아래와 같은 코드로 전체 파라메터를 ISO-8859-1 로 decoding해서 String 객체를 생성하도록 할 수 있습니다.

if (!isMultiPart(request)) {
	request.setCharacterEncoding("ISO-8859-1"); // byte array으로 변환하기 위해 ISO-8859-1로 설정함.
	request.getParameter("dummy"); // parameter parsing을 위해서 getParameter 호출
}

자~ 그럼 파라메터에서 byte array를 다음과 같은 형태로 얻어낼 수 있겠죠?

String query = request.getParameter("query");
byte [] bQuery = query.getBytes("ISO-8859-1"); // 원래의 byte array를 얻음.

UTF-8 인지 EUC-KR인지 판별하기

byte array를 가져 왔으니 byte sequence로 부터 한글 인코딩을 판별해내야겠지요.

php 등의 스크립트 언어에서는 iconv 같은 함수들을 썼겠지만, 아시다시피 그런 방식으로는 한글 인코딩을 완전하게 판별할 수 없습니다. 왜냐하면 UTF-8 한글과 EUC-KR(MS949)와는 코드영역이 겹치는 부분이 있기 때문입니다. 예를 들면, “천호“, “치킨” 같은 단어들이죠.

• UTF-8 코드영역 : http://ko.wikipedia.org/wiki/UTF-8
• UTF-8 byte sequence에 대한 정규식 : http://www.w3.org/International/questions/qa-forms-utf-8.en.php
• MS949 코드영역 : http://ko.wikipedia.org/wiki/코드_페이지_949

위의 링크를 참고하면, UTF-8의 non-overlong 2-byte 영역이 MS949의 코드 영역과 겹치는 걸 확인 할 수 있습니다. 즉, “치킨“이라는 단어의 경우 UTF8로 인코딩하면 EC.B9.98.ED.82.A8 인데 이 byte sequence는 UTF-8 인코딩에도 valid하며, MS949 인코딩에도 valid 합니다. 결론적으로 byte sequence 만으로는 UTF-8인지, EUC-KR인지 완벽하게 판별가능한 방법은 없다는 얘기입니다. (iconv 역시 마찬가지입니다.)

그래서 여기에 3번째 가정을 적용합니다. 위의 첫번째 링크(Wikipedia: UTF-8)의 내용 중에 아래와 같은 내용이 있습니다.

그 다음 1920문자 – 발음 구별 기호가 붙은 라틴 문자, 그리스 문자, 키릴 문자, 콥트 문자, 아르메니아 문자, 히브리 문자, 아랍 문자 – 는 2바이트로 표시되며…

UTF-8 코드영역에서 이 부분이 바로 non-overlong 2-byte 에 해당하는 부분입니다. 일반적으로 자주 쓰는 문자들은 아닌것 같죠? 이 코드 영역을 쓰지 않는다는 가정을 하면, 한글에 있어서는 완전하게 UTF-8과 EUC-KR 중 어떤 인코딩으로 encode된 byte array인지 판별가능합니다.

byte sequence에 대한 한글 UTF-8 여부를 판별하는 코드는 아래에 있습니다. 참고로 전체를 정규식으로 로직을 쓸 경우, 큰 byte array에 대해서 Stack overflow가 발생하기 때문에 아래와 같이 byte 별로 쪼개어 test했습니다.

/**
 * 문자열이 UTF8 Character인지 검사하는 Utility Class.
 *


 * byte arry 및 최상위 비트가 보존된 iso-8859-1로 decoding 문자열에 대한 체크만 가능하다.
 * 한마디로, 이미 깨진 한글 따윈 검증할 수 없다.
 * 

 *


 * utf8 문자셋에 대한 정규식.
 * 

 * MS949와 충돌나는 코드 영역 때문에, 2byte로 인코딩되는 문자들은 제외한다. (e.g. 치킨)
 * 한글 유니코드는 모두 /u0800 보다 큰 코드값에 배열되므로,
 * utf8 인코딩시 2바이트로 인코딩되는 일이 없다. (첫자끝, 한글자모도 동일함)
 * 물론, 이렇게 함으로써 해당 코드영역을 사용하는 타언어의 코드를 체크할 수 없다.
 * 

 *
 * 관련 정보 :
 * 	1. http://ko.wikipedia.org/wiki/UTF-8
 *  2. http://forum.standardmag.org/viewtopic.php?id=462
 *
 * @see http://www.w3.org/International/questions/qa-forms-utf-8.en.php
 *
 * @author oddpoet
 */
public final class UTF8KoreanChecker {
	/**
	 * Utility Class이므로 생성자를 막는다.
	 */
	private UTF8KoreanChecker() { }

	/**
	 * 주어진 byte array가 한글 UTF8 인코딩인지 체크한다.
	 *
	 * @param bytes bytes
	 * @return true/false
	 */
	public static boolean isUTF8Korean(byte[] bytes) {
		for (int i = 0; i < bytes.length;) {
			if (isAscii(bytes, i)) {
				i += 1; // 1byte 체크함.
				continue;

			/*
			 * 위에서 언급한 바처럼, UTF-8 인코딩의 2바이트 영역이 MS949와 겹치므로,
			 * 한글 UTF8 검증에는 사용하지 않는다.
			 * 게다가 한글 UTF8은 2바이트로 인코딩되는 경우가 없으므로,
			 * 한글에 한해서는 체크는 완전하게 가능하다.
			 */
			//} else if (isNonOverlong(bytes, i)) {
			//	i += 2;
			//	continue;
			//}

			} else if (isExcludeOverlogs(bytes, i)
				|| isExcludingSurrogates(bytes, i)
				|| isStraight(bytes, i)) {
				i += 3; // 3byte 체크함.
				continue;
			} else if (isPlane1to3(bytes, i)
				|| isPlane4to15(bytes, i)
				|| isPlane16(bytes, i)) {
				i += 4; // 3byte 체크함.
				continue;
			} else {
				return false;
			}
		}

		return true;
	}

	/**
	 * (1byte)ascii ([\\x09\\x0A\\x0D\\x20-\\x7E])
	 * @param bytes bytes
	 * @param index 체크시작할 바이트
	 * @return true/false
	 */
	private static boolean isAscii(byte[] bytes, int index) {
		return bytes[index] == (byte)0x09
			|| bytes[index] == (byte)0x0A
			|| bytes[index] == (byte)0x0D
			|| (bytes[index] >= (byte)0x20
				&& bytes[index] <= (byte)0x7E
			);
	}

	/**
	 * (3bytes) excluding overlogs (\\xE0[\\xA0-\\xBF][\\x80-\\xBF])
	 * @param bytes bytes
	 * @param index index
	 * @return true/false
	 */
	private static boolean isExcludeOverlogs(byte[] bytes, int index) {
		return index + 2 < bytes.length
			&& bytes[index] == (byte)0xE0
			&& (bytes[index + 1] >= (byte)0xA0
				&& bytes[index + 1] <= (byte)0xBF
			)
			&& (bytes[index + 2] >= (byte)0x80
				&& bytes[index + 2] <= (byte)0xBF
			);
	}

	/**
	 * (3bytes) straight ([\\xE1-\\xEC\\xEE\\xEF][\\x80-\\xBF]{2})
	 * @param bytes bytes
	 * @param index index
	 * @return true/false
	 */
	private static boolean isStraight(byte[] bytes, int index) {
		return index + 2 < bytes.length
				&& (
					(bytes[index] >= (byte)0xE1
						&& bytes[index] <= (byte)0xEC
					)
					|| bytes[index] == (byte)0xEE
					|| bytes[index] == (byte)0xEF
				)
				&& (bytes[index + 1] >= (byte)0x80
					&& bytes[index + 1] <= (byte)0xBF
				)
				&& (bytes[index + 2] >= (byte)0x80
					&& bytes[index + 2] <= (byte)0xBF
				);
	}

	/**
	 * (3bytes) excluding surrogates (\\xED[\\x80-\\x9F][\\x80-\\xBF])
	 * @param bytes bytes
	 * @param index index
	 * @return true/false
	 */
	private static boolean isExcludingSurrogates(byte[] bytes, int index) {
		return index + 2 < bytes.length
			&& (bytes[index] == (byte)0xED)
			&& (bytes[index + 1] >= (byte)0x80
				&& bytes[index + 1] <= (byte)0x9F
			)
			&& (bytes[index + 2] >= (byte)0x80
				&& bytes[index + 2] <= (byte)0xBF
			);
	}

	/**
	 * (4bytes)planes 1-3 (\\xF0[\\x90-\\xBF][\\x80-\\xBF]{2})
	 * @param bytes bytes
	 * @param index index
	 * @return true/false
	 */
	private static boolean isPlane1to3(byte[] bytes, int index) {
		return index + 3 < bytes.length
			&& (bytes[index] == (byte)0xF0)
			&& (bytes[index + 1] >= (byte)0x90
				&& bytes[index + 1] <= (byte)0xBF
			)
			&& (bytes[index + 2] >= (byte)0x80
				&& bytes[index + 2] <= (byte)0xBF
			)
			&& (bytes[index + 3] >= (byte)0x80
				&& bytes[index + 3] <= (byte)0xBF
			);
	}

	/**
	 * planes 4-15 ([\\xF1-\\xF3][\\x80-\\xBF]{3})
	 * @param bytes bytes
	 * @param index index
	 * @return true/false
	 */
	private static boolean isPlane4to15(byte[] bytes, int index) {
		return index + 3 < bytes.length // 4byte check
			&& (bytes[index] >= (byte)0xF1
				&& bytes[index] <= (byte)0xF3
			)
			&& (bytes[index + 1] >= (byte)0x80
				&& bytes[index + 1] <= (byte)0xBF
			)
			&& (bytes[index + 2] >= (byte)0x80
				&& bytes[index + 2] <= (byte)0xBF
			)
			&& (bytes[index + 3] >= (byte)0x80
				&& bytes[index + 3] <= (byte)0xBF
			);
	}

	/**
	 * (4bytes)plane 16 (\\xF4[\\x80-\\x8F][\\x80-\\xBF]{2})
	 * @param bytes bytes
	 * @param index index
	 * @return true/false
	 */
	private static boolean isPlane16(byte[] bytes, int index) {
		return index + 3 < bytes.length // 4byte check
			&& (bytes[index] >= (byte)0xF4)
			&& (bytes[index + 1] >= (byte)0x80
				&& bytes[index + 1] <= (byte)0x8F
			)
			&& (bytes[index + 2] >= (byte)0x80
				&& bytes[index + 2] <= (byte)0xBF
			)
			&& (bytes[index + 3] >= (byte)0x80
				&& bytes[index + 3] <= (byte)0xBF
			);
	}

	/**
	 * (2bytes)non-overlong ([\\xC2-\\xDF][\\x80-\\xBF])
	 * 이 코드 영역은 MS949와 겹치는 영역이므로, 한글 검증용으로 사용하지 않는다.
	 *
	 * UTF8 한글의 경우 2byte로 인코딩되는 경우가 없음.
	 *
	 * @param bytes bytes
	 * @param index index
	 * @return true/false
	 */
	/* 사용하지 않으므로 주석처리.
	private static boolean isNonOverlong(byte[] bytes, int index) {
		return index + 1 < bytes.length // 2byte check
			&& bytes[index] >= (byte)0xC2 && bytes[index] <= (byte)0xDF
			&& bytes[index + 1] >= (byte)0x80 && bytes[index + 1] <= (byte)0xBF;
	}
	*/
}

정리

byte array를 얻어서, 사용된 encoding을 판별하고 나면 아래와 같은 방법으로 적절한 encoding을 사용해서 한글 String 객체를 만들어 낼 수 있습니다.

String param = request.getParameter("param");
byte [] bytes = param.getBytes("ISO-8859-1");
String koparam;
if (UTF8KoreanChecker.isUTF8Korean(bytes)) {
	koparam = new String(bytes, "UTF-8");
} else {
	koparam = new String(bytes, "MS949");
}