인코딩

[macOS 한글 호환성 2편] 한글 깨짐 수정법

2019. 8. 29. 15:42

 

맥을 사용하면서 자주 접하게 될 한글 인코딩 호환성 문제

인코딩이 윈도와 다르다. 맥에서 만든 파일은 윈도에서 자음과 모음이 분리되어 보인다. 많은 사람들이 이를 자소 분리현상이라고 말한다. 또한, 일부 사이트는 한글이 깨지거나, 다운로드한 파일의 이름이 깨지는 경우가 많다.`

이번 글에서 다룰 것은 아니지만, 이 현상은 iOS에서도 나타나는 현상이다. 하지만 지금까지 iOS 사용자들은 이런 불편함을 느끼지 못했다. 파일 공유가 어려워서, 다운로드 받을 파일을 수정하는 경우는 많지만, 파일을 만드는 경우는 거의 없었다. 또한, 주요 클라우드 서비스는 파일을 업로드하면 자소 분리를 해결해주기 때문에 한글 인코딩 문제가 크게 다가오지 않았다. 그런데, 앞으로는 iOS 사용자들도 자주 겪게 될 것이다. 9월 중 정식 공개될 iOS 13에서는 File 앱을 통해 파일 관리를 쉽게 할 수 있다. 문제는 맥과 같은 인코딩을 사용하기 때문에 베타 사용자들 입장에서는 iOS 13에서 한글 처리에 문제가 생긴 것으로 느끼기도 할 수 있다는 것이다.

어쨌든, 이번 글을 통해 두 가지를 다룰 것이다.

  1. 업로드 하는 파일의 자소 분리 문제와 해결법
  2. 다운로드하는 파일의 텍스트 깨짐과 해결법

원인

이 현상의 원인은 인코딩이 달라서가 아니다. 윈도우에서 CP949라는 구식 인코딩 방식을 사용하기 때문이다. CP949는 EUC-KR의 확장 버전이라고 볼 수 있다. 이 인코딩 방식은 MS에서 초기 윈도우를 개발할 때, 한글 지원을 위해 만든 인코딩 방식이다. 따라서 현재는 개량된 인코딩이 많이 나와 있으며, 많은 운영체제에서 사용하지 않는 인코딩 방식이다(지원하지 않는다는 의미는 아니다). 요즘은 영어를 제외한 대부분의 문자를 Unicode로 인코딩한다. 영어도 특수한 문자를 표시하기 위해 유니코드로 인코딩하는 경우가 많다.

그럼에도 불구하고 윈도우는 여전히 기본 인코딩 방식이 CP949이다. 그래서 기본 텍스트 편집기로 작성한 파일이나 Visual Studio에서 작성한 코드들이 다른 운영체제에서 보면 깨져서 보인다. 특이하게도 한글 윈도우만 기본 인코딩이 CP949이다. 한글 지원을 위한 인코딩이니... 당연한 결과다. 영문 윈도우는 기본 인코딩이 CP949가 아니다. 영문 윈도우에서 작성한 한글 텍스트 문서들은 다른 운영체제에서도 잘 보인다는 얘기다.
영문 윈도우가 한글을 지원하지 않는 것도 아닌데, 한글 윈도우는 왜 기본 인코딩이 CP949인지 의문이다.

그래서, 일부 웹페이지들이 CP949로 인코딩되어 있다. 이런 사이트는 일부 운영체제에서 글자가 깨져서 보인다. 앞서 언급했듯이, 한글 윈도우만 기본 인코딩이 CP949이기 때문에 다른 언어의 윈도우나 다른 운영체제에서 작성한 웹페이지는 한글이 깨지지 않는다. 가끔은 웹페이지는 잘 보이지만, 파일을 다운로드하면 파일 이름이 깨져있기도 하는데, 이 또한 파일을 전송하는데 인코딩을 제대로 바꾸지 않아서 그렇다.

증상

글자가 깨진다는 것은 아래와 같은 증상을 말한다.

텍스트파일의 내용 중 한글이 보이지 않는다.
간혹 다운로드한 파일의 이름이 위와 같이 깨지기도 한다.

이 증상은 1편의 자소 분리 현상에 비할 수 없이 불편하다. 자소 분리 현상은 파일을 공유하면 다른 사용자가 겪게 되는 문제이면서도 인코딩을 바꾸지 않더라도 읽고 이해할 수는 있다.

하지만 위의 한글 깨짐 현상은 맥의 사용자가 직접 겪을 문제이고, 인코딩을 바꾸지 않는 한, 사용자는 읽고 이해하기 어렵다.

해결법

저 텍스트를 유니코드 인코딩으로 변환하면 된다.

이번에는 iconv명령을 사용한다. iconv -f cp949 -t UTF-8 "$f"

iconv 설치

iconv는 MacOS에 내장되어 있기 때문에 따로 설치하지 않아도 된다.
하지만 MacOS에 내장된 버전은 2009년에 공개된 버전이고, 충돌 문제가 있는 것 같아 brew에서 설치하는 것을 권한다.

터미널을 열고 brew install libiconv를 입력한다.

iconv는 MacOS에 내장되어 있기 때문에 brew에서 환경변수 PATH를 설정해주지 않는다.
대신 설치가 끝나면 brew에서 설치한 iconv를 환경변수 PATH를 설정하는 방법을 알려준다.

그래서 brew가 알려주는 과정을 따라하지 않으면 터미널에서 iconv를 실행해도 MacOS에 내장된 버전이 실행된다.
위 과정을 따라하지 않더라도 추후 brew에서 설치한 버전을 사용하려면 절대경로를 사용해서 실행해주면 된다.

2022.12.14
Intel 기반 맥의 경우 /usr/local/opt/libiconv/bin/iconv를 사용하면 된다.
Apple Silicon 기반 맥의 경우 /opt/homebrew/opt/libiconv/bin/iconv를 사용하면 된다.

2021.11.17
iconv 설치 과정을 추가하였습니다.
Apple Silicon 기반 맥에서 변환 과정에 문제가 발생하는 것 같아 brew에서 다운로드 한 바이너리를 사용하도록 변경하였습니다.

Automator로 만들기

기존의 터미널은 파일을 직접 입력해야 한다. 하지만 오토메이터를 사용하면 Finder에서 파일을 선택하여 바로 실행할 수 있고, 또한 여러 파일을 자동화할 수도 있다.

실행 가능한 Workflow 파일 다운로드

깨진 한글 컨텐츠 수정_Apple_Silicon.workflow.zip
0.17MB
깨진 한글 파일명 수정_Apple_Silicon.workflow.zip
0.01MB

 

깨진 한글 컨텐츠 수정_Intel.workflow.zip
0.09MB
깨진 한글 파일명 수정_Intel.workflow.zip
0.01MB

2021.05.31
iconv가 인코딩을 인식하지 못하는 경우 파일 내용이 사라지는 문제 발생
iconv 변환에 문제가 없는지 확인 후 변환을 시도하도록 변경
변환 결과 알림 추가

2021.11.17
Apple Silicon 기반 맥에서 텍스트가 사라지는 문제가 발생하고 있습니다. 변환 전에 반드시 백업하시길 바랍니다.
이 문제는 Intel 기반 맥에서는 재현되지 않고 있기 때문에 제가 수정할 수 있는 부분이 아닙니다.
혹시 몰라 최신 버전의 iconv를 설치하는 과정도 추가하였으니 참고하시기 바랍니다.

Finder에서 사용할 수 있게 등록하기

  • 시스템 메뉴(애플 로고)
  • 시스템 환경설정(System Preferences)
  • Extentions
  • Finder
  • 방금 만든 Quick Action 선택

Quick Action에 등록된 서비스를 실행하면 아래처럼 파일 내용이 정상이 된다.

2021.05.31 파일 내용이 사라지는 문제 수정
2021.11.17 Apple Silicon 기반 맥에서 발생할 수 있는 문제 공지
2022.12.14 Apple Silicon에서 brew 바이너리들이 설치되는 위치 확인 및 수정

[macOS 한글 호환성 1편] 한글 자소분리 해결법

2019. 8. 28. 20:06

맥을 사용하면서 자주 접하게 될 한글 인코딩 호환성 문제

macOS에서 사용하는 한글 인코딩은 Windows와 다르다. 맥에서 만든 파일은 윈도우에서 자음과 모음이 분리되어 보인다. 많은 사람들이 이를 자소 분리현상이라고 말한다. 또한, 일부 사이트는 한글이 깨지거나, 다운로드한 파일의 이름이 깨지는 경우가 많다. 이 또한 인코딩이 달라서 생기는 문제이다.

이번 글에서 다룰 것은 아니지만, 이 현상은 iOS에서도 나타나는 현상이다. 하지만 지금까지 iOS 사용자들은 이런 불편함을 느끼지 못했다. 파일 공유가 어려워서, 다운로드한 파일을 수정하는 경우는 많지만, iOS 장치에서 파일을 생성하여 공유하는 경우는 거의 없었다. 또한, 주요 클라우드 서비스는 파일을 업로드하면 자소 분리를 해결해주기 때문에 한글 인코딩 문제가 크게 다가오지 않았다. 그런데, 앞으로는 iOS 사용자들도 자주 겪게 될 것이다. 9월 중 정식 공개될 iOS 13에서는 Files 앱을 통해 파일 관리를 쉽게 할 수 있다. 문제는 맥과 같은 인코딩을 사용하기 때문에 베타 사용자들 입장에서는 iOS 13에서 한글 처리에 문제가 생긴 것으로 느끼기도 할 수 있다는 것이다.

어쨌든, 이번 글을 통해 두 가지를 다룰 것이다.

  1. 업로드하는 파일의 자소 분리 문제와 해결법
  2. 다운로드하는 파일의 텍스트 깨짐과 해결법

원인

맥과 윈도우는 인코딩 방식이 다르다.

윈도우는 NFC(Normalization Form Canonical Composition) 방식을, 맥은 NFD(Normalization Form Canonical Decomposition) 방식을 사용한다. 한국어로는 보통 완성형, 조합형이라고 말한다.

조합형은 '콜'을 저장할 때, 'ㅋ' + 'ㅗ' + 'ㄹ'로 저장한다

문자 코드
11
12
13

이라고 하면 실제 저장 내용은 111213으로 저장된다
'ㅋ', 'ㅗ', 'ㄹ'을 입력하는 동안 코드는 11, 1112, 111213으로 바뀐다.

윈도우는 '콜'이라는 문자에 다른 코드를 할당한다.

문자 코드
11
12
13
2032
222355

이라고 하면 실제 저장 내용은 222355가 된다.

'ㅋ', 'ㅗ', 'ㄹ'을 입력하는 동안 코드는 11,2032,222355로 바뀐다.

위는 예시일 뿐이며, 실제로는 완성형 중에도 여러 가지, 조합형 중에도 여러 가지 인코딩 방법이 존재한다.

증상

두 가지 모두 표준 정규화 인코딩 방식이다. 맥은 윈도우에서 만든 파일을 제대로 처리할 수 있으니, 맥은 두 가지 표준을 모두 지원하는 셈이다. 다만 한국에서 지정한 KS 표준에서는 완성형 인코딩 방식을 한글 인코딩의 표준으로 정의하고 있다. 따라서 맥이 국내 표준을 준수하지 않은 것으로 봐야 한다. KS 위키 문서

2022.02.24
인코딩 출력에 관하여 책임 소재(?) 수정
인코딩 관련하여 "민중택배"님이 중요한 의견 주셨다.
오리지널을 중요하게 생각하는 사람으로서 댓글에 있던 부분을 그대로 남겨두는 방식으로 정보를 전달하고자 했다.
그러나 질답글이 많아지고 댓글을 읽기 어려워지면서 이 글이 윈도우가 표준을 미지원하는 문제의 근거로 사용되는 것을 확인했다.
따라서 해당 부분을 본문에 반영한다.

출처 : clien.net

해결법

하지만 점유율 부분에서 이런 문제를 신경 써야 하는 쪽은 맥 사용자다. 다행히도 맥에서는 완성형으로 인코딩 된 파일을 표시할 수 있다. 그래서 파일 명을 완성형으로 인코딩하면 된다.

convmv 설치

우선 convmv를 설치해야 한다. convmv는 CONVerts filenames from one encoding to another and MoVe라는 뜻으로, 인코딩을 바꾸는 툴이다. mv는 파일을 이동하는 명령인데, 이름을 바꾸는 데에도 사용한다. 그러므로 인코딩을 바꾸는 툴이라고 봐도 된다.

터미널을 열고 brew install convmv 를 입력한다. brew가 설치되어 있지 않다면 brew를 먼저 설치해야 한다. brew는 리눅스용으로 컴파일된 프로그램을 실행할 수 있게 해주는 환경을 만들어준다.

convmv 사용법

convmv -f utf8 -t utf8 --nfc --notest <filename>

텍스트 인코딩을 utf8에서 utf8로 바꾸는데, nfc 정규화 방식을 사용한다는 의미이다.

자세한 내용은 man convmv를 참고하면 된다.

2021.03.17
일부 시스템에서 convmv가 NFD로 정규화 된 파일을 인식하지 못하는 문제가 있어 수정 하였습니다.
원인을 정확히 할 수는 없지만, Argument로 파일 이름을 전달할 경우 convmv 프로그램이 인식하지 못하는 것 같습니다.
따라서 디렉토리를 인수로 사용하고, 해당 디렉토리에서 모든 파일을 검색하여 convmv를 실행하도록 변경하였습니다.

2021.05.21
3월 17일에 업데이트 한 내용 원상 복귀하였습니다.
지난 1여년 간 같은 문제가 계속 반복되어 문제를 우회할 수 있도록 코드를 수정하였으나,
최신 환경에서 문제가 해결된 것으로 보여 원상 복귀하였습니다.

추가로 프로그램 실행 결과가 알림으로 나타나도록 수정하였습니다.

Automator로 만들기

기존의 터미널은 파일을 직접 입력해야 한다. 하지만 오토메이터를 사용하면 Finder에서 파일을 선택하여 바로 실행할 수 있고, 또한 여러 파일을 자동화할 수도 있다.

실행 가능한 Workflow 파일 만들기

  • 오토메이터 실행
  • 새로 만들기
  • Quick Action 선택
  • 왼쪽 사이드바에서 Run Shell Script를 선택하고, 오른쪽으로 끌어온다.
  • 왼쪽 사이드바에서 Set Value of Variable을 선택하고, 오른쪽으로 끌어온다.
  • 왼쪽 사이드바에서 Display Notification을 선택하고, 오른쪽으로 끌어온다.
  • 오른쪽 패널을 이미지와 같이 바꾸고 입력한다.

for i in "$@"; do
    convmv -f utf-8 -t utf-8 --nfc --notest "$i"
done
  • 파일을 ~/Library/Services에 저장한다.

만약에 convmv를 찾을 수 없다는 메시지가 뜰 경우,
Intel 기반 맥에서는 convmv/usr/local/bin/convmv로 변경한다.
Apple Silicon 기반 맥에서는 convmv/opt/homebrew/bin/convmv로 변경한다.

Finder에서 사용할 수 있게 등록하기

  • 시스템 메뉴(애플 로고)
  • 시스템 환경설정(System Preferences)
  • Extentions
  • Finder
  • 방금 만든 Quick Action 선택

Finder에서 사용하기

이젠 아래 이미지처럼 사용하면 된다.

2021.03.17 일부 시스템에서 convmv가 작동하지 않던 문제 수정
2021.05.21 convmv 소스코드 원상 복귀 및 알림 추가
2021.11.17 Apple Silicon 기반 맥에서 convmv를 찾을 수 없는 문제 수정
2022.02.24 인코딩 출력에 관하여 책임 소재(?) 수정

1인미디어 시대, 게임방송, 나도 해볼까? part.4 : 비교와 결론

2018. 12. 16. 21:53

결론 및 종합

앞서 소개한 녹화 방식에 따라 차이를 비교해보기로 한다.

레인보우식스 시즈의 벤치마킹 기능을 이용했다. 그래픽 옵션은 프리셋 최상에, 텍스처는 Very High, 안티앨리어싱과 텍스처 필터링은 끈 상태로 진행했다. 인코딩은 6000kbps로 설정했다.

GPU는 소수연산에 효율적이기 때문에 그걸 강조하기 위해 전력소비도 비교해봤다. 전력소비는 소프트웨어 기반이기 때문에 정확하지 않을 수 있다.

게임 플레이

Time CPU [%] GPU [%] FPS [FPS] CPU Package Power [W] GPU Chip Power [W] Power Combined
max 61.3 100 157 62.268 149.082 206.956
min 20 87 90 46.378 123.465 174.619
avg 44.3 99.8421052631579 120.031578947368 54.7037263157894 135.544189473684 190.247915789474

CPU사용량은 최대 61%, 평균 44%이다.

FPS는 최대 157FPS, 최소 90FPS이고, 평균은 120FPS이다. 편차는 60FPS.

CPU와 GPU의 최대 전력소비량은 207W이다.

게임 플레이 + CPU 인코딩

Time CPU [%] GPU [%] FPS [FPS] CPU Package Power [W] GPU Chip Power [W] Power Combined
max 79.5 100 144 82.233 145.098 225.527
min 32.6 88 88 64.547 127.582 198.656
avg 60.3 98.7894736842105 112.252631578947 73.780 134.084557894737 207.864284210526

CPU사용량은 최대 80%, 평균 60%이다. 인코딩을 하지 않을 때에 비해 평균값은 16%차이, 최대는 19%가까이 차이난다.

FPS는 최대 144FPS, 최소 88FPS, 평균 112FPS이다. 녹화하지 않을 때보다 8FPS정도 떨어진다. 편차는 56FPS.

최대 전력소비는 225W이다. 18W차이이고, 10%가 늘어난 것이다.

게임 플레이 + GPU 인코딩

Time CPU [%] GPU [%] FPS [FPS] CPU Package Power [W] GPU Chip Power [W] Power Combined
max 88 100 141 66.048 143.406 200.306
min 18.7 87 88 50.234 128.52 182.815
avg 49.3631578947369 99.2210526315789 111.536842105263 56.3260315789474 135.858810526316 192.184842105263

CPU사용량은 최대 88%, 평균 49%이다.

FPS는 최대 141FPS, 최소 88FPS, 평균 111FPS이다. 프레임은 CPU인코딩에 비해 낮다. 편차는 53FPS.

최대 전력소비는 200W이다. 녹화하지 않을 때에 비해 오히려 줄어들었다.

뒤쪽에 그래프를 게시할 것인데, 녹화 때문에 프레임이 줄어드니 오히려 전력소비가 감소한 것으로 추측해 볼 수 있다.

게임 플레이 + NDI 전송

Time CPU [%] GPU [%] FPS [FPS] CPU Package Power [W] GPU Chip Power [W] Power Combined
max 51.6 100 147 80.255 145.574 215.345
min 13.7 90 94 32.769 131.828 169.890
avg 39.2178947368421 99 119.326315789474 54.938 139.662978947368 194.600694736842

CPU사용량은 최대 51%, 평균 39%이다. 평균값이 GPU인코딩과 별 차이 없다.

FPS는 최대 147FPS, 최소 94FPS, 평균 119FPS이다. 편차는 53FPS.

최대 전력소비는 215W이다. 다른 컴퓨터에서 인코딩을 해야 하니 결코 적은 수치는 아니다.

차트 비교하기

단순 게임 플레이

GPU사용량에 변화가 없이 안정적이다.

CPU사용량은 FPS에 따라 조금씩 변하고 있다. 13번째~41번째 스캔에서는 FPS에 따라 낮아지고, 거의 40%이하로 유지되고 있다.

CPU 인코딩

GPU사용량이 출렁이는 지점이 많다.

CPU사용량은 거의 60%대에서 변화한다. 갑자기 CPU 사용량이 떨어지는 지점은 인코딩 과부화로 영상 출력이 끊기는 부분이었다.

전체적인 FPS그래프가 인코딩을 하지 않을 때와 비슷하다.

GPU 인코딩

GPU 사용량이 출렁이는 지점이 많다. CPU 인코딩에 비해서는 적다.

65번째~75번째 스캔에서 CPU 사용량이 크게 증가한다. 위 표에서 GPU 인코딩 중의 CPU 사용량 최댓값이 88이어서 GPU 인코딩의 장점을 부각하지 못했다. 녹화 영상이나 게임 벤치마킹에서는 별 문제가 발견되지 않았다. 인코더가 불안정하거나 다른 프로세스가 갑자기 실행된 것일 수도 있다.

꼭짓점이 부드럽다고 해야할까, 전체적인 FPS 그래프가 좀 다르다.

NDI 인코딩

CPU 사용량이 다른 인코딩에 비해 안정적이다.

GPU 사용량은 자주 출렁인다. 하지만 다른 인코딩 방식처럼 크게 떨어지지 않는다.

결론

각각의 장단점이 있다. NDI는 리소스를 분산시킬 수 있지만 전체적으로는 가장 비효율적인 방법이다. 또한 좋은 네트워크 장비가 요구된다.

GPU는 전체적으로 CPU, GPU사용량에 큰 변화 없이 인코딩이 가능하다. 프레임 감소는 제일 크다.

CPU는 전력소비는 크지만, 대체로 안정적이다. FFmpeg라는 인코더가 안정적인 것도 있지만, CPU는 리소스 분배에 있어 비교적 여유롭기 때문이다.

1인미디어 시대, 게임방송, 나도 해볼까? part.1

1인미디어 시대, 게임방송, 나도 해볼까? part.2: OBS 설정

1인미디어 시대, 게임방송, 나도 해볼까? part.3: CPU 인코딩 설정

1인미디어 시대, 게임방송, 나도 해볼까? part.4 : 비교와 결론

+ Recent posts