엔디언(endian) 그리고 UTF-8에서 illegal character: \65279 에러

빅 엔디안과 리틀 엔디안은 컴퓨터 메모리에 저장된 바이트들의 순서를 설명하는 용어이다. 빅 엔디안은 큰 쪽 (바이트 열에서 가장 큰 값)이 먼저 저장되는 순서이며, 리틀 엔디안은 작은 쪽 (바이트 열에서 가장 작은 값)이 먼저 저장되는 순서이다. 예를 들면, 빅 엔디안 컴퓨터에서는 16진수 "4F52"를 저장공간에 "4F52"라고 저장할 것이다 (만약 4F가 1000번지에 저장되었다면, 52는 1001번지에 저장될 것이다). 반면에, 리틀 엔디안 시스템에서 이것은 "524F"와 같이 저장될 것이다. IBM 370 컴퓨터와 대부분의 RISC 기반의 컴퓨터들, 그리고 모토로라 마이크로프로세서는 빅 엔디안 방식을 사용한다. 왼쪽에서 오른쪽으로 읽는 언어를 사용하는 사람들에게, 이것은 일련의 문자나 숫자를 저장하는 데 있어 자연스러운 방식이다. 한편, 인텔 프로세서나 DEC의 알파 프로세서, 그리고 적어도 그것들 상에서 운영되는 일부 프로그램들은 리틀 엔디안을 사용한다. 리틀 엔디안 순서에 대한 논리는, 수의 값을 증가시킬 때 수의 왼편에 자릿수를 추가해야할 필요가 있을지 모른다는 것이다 (지수가 아닌 경우에, 더 큰 숫자는 더 많은 자릿수를 갖는다). 빅 엔디안으로 정렬되어 저장되어 있는 숫자는 두 숫자를 더한 결과를 저장하기 위해 모든 자릿수를 오른쪽으로 옮겨야하는 일이 종종 발생한다. 그러나 리틀 엔디안 방식으로 저장된 숫자에서는, 최소 바이트가 원래 있던 자리에 그대로 머물 수 있으며, 새로운 자리 수는 최대 수가 있는 주소의 오른쪽에 추가될 수 있다. 이것은 일부 컴퓨터 연산들이 매우 단순해지고 빠르게 수행될 수 있다는 것을 의미한다. 자바나 FORTRAN과 같은 컴파일러들은 그들이 개발하는 목적 코드가 어떤 방식으로 저장될 것인지를 알아야만 한다. 필요한 경우, 한 방식에서 다른 방식으로 변경하는데 변환기가 사용될 수도 있다.

바이트 순서가 빅 엔디안이든 리틀 엔디안 이든, 각 바이트 내에 들어있는 비트들은 둘 모두 빅 엔디안으로 정렬되어 있다는 데에 유의하라. 즉, 저장된 바이트의 주어진 숫자에 의해 표현되는 전체적인 비트 스트림에 관해서는 빅이나 리틀 엔디안으로 하려는 시도가 없다는 것이다. 예를 들어 16진수 4F가 저장공간 내에 주어진 저장 주소범위 내에 있는 다른 바이트들과 함께 처음에 저장되든 또는 나중에 저장되든 간에, 그 바이트 내의 비트 순서는 다음과 같을 것이다.

01001111

비트 순서에 대해서도 빅 엔디안이나 리틀 엔디안으로 구현하는 것이 가능하긴 하지만, 거의 모든 CPU나 프로그램들은 빅 엔디안 비트 순서로 설계된다. 그러나 데이터 통신에서는, 비트 순서를 둘 중 어느 한쪽으로 하는 것이 가능하다.

에릭 레이몬드는 인터넷 도메인 이름과 전자우편 주소들이 리틀 엔디안 방식으로 표현된 것이라고 말한다. 예를 들어 만약, 텀즈 사이트의 주소를 빅 엔디안 방식으로 쓴다면 다음과 같은 형식을 가질 것이다.

kr.co.terms.www

빅 엔디안과 리틀 엔디안이라는 용어는 조나단 스위프트의 걸리버 여행기로부터 파생되었다.

==================================================================================

엔디언(Endianness)은 컴퓨터의 메모리와 같은 1차원의 공간에 여러 개의 연속된 대상을 배열하는 방법을 뜻하며, 바이트를 배열하는 방법을 특히 바이트 순서(Byte order)라 한다.

엔디언은 보통 큰 단위가 앞에 나오는 빅 엔디언(Big-endian)과 작은 단위가 앞에 나오는 리틀 엔디언(Little-endian)으로 나눌 수 있으며, 두 경우에 속하지 않거나 둘을 모두 지원하는 것을 미들 엔디언(Middle-endian)이라 부르기도 한다.

목차  [숨기기]  1 바이트 순서 1.1 장단점 1.2 바이 엔디언 1.3 미들 엔디언 1.4 비트 순서 2 유래 3 바깥 고리

[편집] 바이트 순서

바이트 순서는 크게 빅 엔디언과 리틀 엔디언으로 나눌 수 있다. 빅 엔디언은 사람이 숫자를 쓰는 방법과 같이 큰 단위의 바이트가 앞에 오는 방법이고, 리틀 엔디언은 반대로 작은 단위의 바이트가 앞에 오는 방법이다. PDP-11과 같은 몇몇 아키텍처는 2바이트 단위와 1바이트 단위로 서로 다른 순서를 사용하기도 하는데 이들을 미들 엔디언이라 부른다. 다음은 이런 방법들을 비교한 것이다.

종류	0x1234의 표현	0x12345678의 표현
빅 엔디언	12 34	12 34 56 78
리틀 엔디언	34 12	78 56 34 12
미들 엔디언	-	34 12 78 56 또는 56 78 12 34

두 방법 중 어느 한 쪽이 다른 쪽과 비교해 압도적으로 좋거나 나쁘지는 않다고 알려져 있으며, 두 방법은 서로 다른 여러 아키텍처에서 서로 공존하고 있다. 그러나 x86 아키텍처가 리틀 엔디언을 쓰기 때문에, 오늘날 x86 아키텍처를 사용하는 대부분의 데스크톱 컴퓨터는 리틀 엔디언을 쓰며 이를 ‘인텔 포맷’이라 한다. 거꾸로 네트워크에서는 주소를 빅 엔디언으로 쓰는데, 역사적으로 라우팅이 전화를 거는 식으로 접두 부호로 이루어졌기 때문이다. 이의 영향으로 많은 프로토콜과 몇몇 파일 포맷이 빅 엔디언을 사용하고 있다. 모토로라 프로세서들은 일반적으로 빅 엔디언을 사용하며, ARM 프로세서들은 성능 향상을 위해 빅 엔디언과 리틀 엔디언을 선택할 수 있도록 되어 있다.

[편집] 장단점

빅 엔디언은 소프트웨어의 디버그를 편하게 해 주는 경향이 있다. 사람이 숫자를 읽고 쓰는 방법과 같기 때문에 디버깅 과정에서 메모리의 값을 보기 편한데, 예를 들어 0x59654148은 빅 엔디언으로 59 65 41 48로 표현된다.

반대로 리틀 엔디언은 메모리에 저장된 값의 하위 바이트들만 사용할 때 별도의 계산이 필요 없다는 장점이 있다. 예를 들어, 32비트 숫자인 0x2A는 리틀 엔디언으로 표현하면 2A 00 00 00이 되는데, 이 표현에서 앞의 두 바이트 또는 한 바이트만 떼어 내면 하위 16비트 또는 8비트를 바로 얻을 수 있다. 보통 변수의 첫 바이트를 그 변수의 주소로 삼기 때문에 이런 성질은 종종 프로그래밍을 편하게 하는 반면, 리틀 엔디언 환경의 프로그래머가 빅 엔디언 환경에서 종종 실수를 일으키는 한 이유이기도 하다.

[편집] 바이 엔디언

몇몇 아키텍처는 빅 엔디언과 리틀 엔디언 중 하나를 선택할 수 있도록 설계되어 있고, 이를 바이 엔디언(Bi-endian)이라 부른다. ARM, PowerPC, DEC 알파, MIPS, PA-RISC, IA-64 등은 바이 엔디언을 사용하는 대표적인 아키텍처이다. 이들 대부분은 컴퓨터가 시작된 상태에서 소프트웨어적으로 바이트 순서를 바꿀 수 있지만, 몇몇은 하드웨어에 내장된 펌웨어에서 바이트 순서를 선택해야 하는 경우도 있다.

[편집] 미들 엔디언

종종 한 방향으로 순서가 정해져 있는 게 아니라, 이를테면 32비트 정수가 2바이트 단위로는 빅 엔디언이고 그 안에서 1바이트 단위로는 리틀 엔디언인 경우가 종종 있는데 이를 미들 엔디언(Middle-endian)이라 한다. VAX와 ARM에서는 배정도 부동 소수점 실수를 미들 엔디언으로 저장하며, PDP-11에서는 32비트 정수를 미들 엔디언으로 저장하는데 이를 PDP 엔디언이라 부르기도 한다.

[편집] 비트 순서

보통 바이트나 옥텟은 원자적인 단위로 간주되지만 종종 비트 단위의 접근이 필요할 수 있다. 따라서 바이트 순서가 아니라 비트 순서를 따질 수도 있으나, 여러 가지 이유로 비트 순서는 상대적으로 덜 중요하다. 보통 메모리의 접근은 바이트 단위로 이루어지기 때문에 비트 단위의 접근에는 별도의 연산 과정이 필요한데, 이러한 연산 자체가 비트 순서에 대해 잘 정의되어 있기 때문에 비트를 접근하는 방법은 아키텍처에 중립적이다.

비트 순서와 비슷하게, 네트워크 프로토콜이나 파일 포맷 같이 저수준으로 내려 갈 경우 비트 단위의 데이터를 최상위 비트부터 채울 것인가 최하위 비트부터 채울 것인가 하는 문제가 있다. 예를 들어 C는 구조체에서 바이트보다 더 작은 단위의 변수를 선언할 수 있는 비트 필드를 지원하는데, 여러 개의 비트 필드가 배열되는 방법은 기계어를 생성하는 과정에서 중요해진다. 이때 최상위 비트(MSB)부터 채우는 것을 최상위 비트 우선, 최하위 비트(LSB)부터 채우는 것을 최하위 비트 우선이라 한다. 예를 들어 PNG와 GIF는 각각 최상위/최하위 비트 우선을 쓰는 대표적인 파일 포맷이다.

[편집] 유래

빅 엔디언과 리틀 엔디언 중 어느 것을 쓰느냐 하는 문제는 상황에 따라서 임의적이고, 따라서 종종 플레임의 대상이 되었다. 엔디언이라는 말 자체는 대니 코헨(Danny Cohen)이 이런 플레임을 잠재우기 위해 1980년에 쓴 On Holy Wars and a Plea for Peace라는 글에서 유래했다. 이는 조나단 스위프트의 《걸리버 여행기》에 나오는 소인국 릴리퍼트 이야기에서 달걀을 깰 때 뭉툭한 끝(big-end)을 먼저 깰 것인가 뾰족한 끝(little-end)을 먼저 깰 것인가를 가지고 격론을 벌인 것을 두고 이름을 따온 것이다.

[편집] 바깥 고리

• (영어) DAV's Endian FAQ - 대니 코헨의 On Holy Wars and a Plea for Peace 포함
• (영어) 《걸리버 여행기》의 달걀 논쟁 부분

==================================================================================

바이트 순서 표식(Byte Order Mark, BOM)은 유니코드에서 엔디안을 구별하기 위해 사용되는 문자로, 문자 값은 U+FEFF이다.

UTF-16, UTF-32와 같은 인코딩에서는 엔디안의 종류에 따라 문자열의 값이 완전히 달라지므로, 문자열의 엔디안을 구별할 수 있는 표식이 필요하다. 이에 따라 유니코드 문자열 앞에 BOM 문자를 붙여, 맨 처음에 읽히는 값에 따라 엔디안을 구별한다.

예를 들어, UTF-16에서 빅 엔디안의 경우에 문자열의 가장 처음 두 바이트는 FE FF가 된다. 리틀 엔디안의 경우에는 FF FE가 된다.

UTF-8에는 엔디안 문제가 일어나지 않으므로 BOM을 붙여야 할 필요는 없지만, 해당 자료가 UTF-8 인코딩이라는 표식으로 사용하는 경우도 있다. 특히 마이크로소프트 윈도의 많은 문서 편집기는 UTF-8로 저장할 경우 자동으로 문서의 가장 앞부분에 BOM을 추가한다. 이와는 반대로 유닉스 계열의 문서 편집기는 BOM을 사용하지 않는 경우가 보통으로, 이 경우 문서의 BOM을 잘못 인식하여 문제가 발생할 수도 있다. 예를 들어, PHP 인터프리터에서는 BOM을 인식하지 못하고 일반 문자열로 간주하는데, PHP에서 HTTP 헤더를 변경하려면 그 시점에서 어떠한 문자열도 출력해서는 안 된다(php.net 도움말). 하지만 문서에 BOM이 있으면 문자열 출력이 일어나고, 따라서 헤더를 변경할 수 없다는 경고가 발생하게 된다.

[편집] BOM 표

각 유니코드 인코딩 방법에 따른 BOM 값은 다음과 같다.

Encoding	Representation
UTF-8	EF BB BF
UTF-16 빅 엔디안	FE FF
UTF-16 리틀 엔디안	FF FE
UTF-32 빅 엔디안	00 00 FE FF
UTF-32 리틀 엔디안	FF FE 00 00
SCSU	0E FE FF
UTF-EBCDIC	DD 73 66 73
BOCU-1	FB EE 28

원본 주소 ‘http://ko.wikipedia.org/w/index.php?title=%EB%B0%94%EC%9D%B4%ED%8A%B8_%EC%88%9C%EC%84%9C_%ED%91%9C%EC%8B%9D&oldid=7839491’

=================================================================================

오늘 처음으로 자바를 메모장에 코딩해서 UTF-8으로 저장한 후 javac -encoding UTF8 샤라랄라라~ 로 컴파일을 했는데...띵!!!

어이없게도 이상한 에러가 발생하였다..-_-

샤라랄라라~.java:1: illegal character: \65279

이게 뭐시다냐- _-;;; 하고 또 해봐도...앞에 시작하자마자 이상한 글자가 붙길래 지우고 다시써봐도....안 되는것이었다;;;

그래서 인터넷을 뒤져보니~!!!

문제는 BOM이라는 것 때문이다.

윈도우 편집기(메모장,워드패드..뭐 이딴것들..)을 쓰게 되면 지멋대로 자동으로 BOM이라는 UTF-8을 구별할 수 있는 식별자가 붙는다고 한다.

그래서 java컴파일러는 이 BOM까지 읽어들이게 되고 따라서 에러가 발생한다는 말씀...그런데....

메모장을 쓰면서 이 BOM문제를 해결할 방법을 알 수가 없었다;;;

결론은...?? EditPlus나 Crimson Editor와 같은 BOM을 붙이는 UTF-8코딩방식을 쓸건지 안 쓸건지를 물어보는 에디터를 사용하시라...~_~

출처 - http://blog.naver.com/myrilke?Redirect=Log&logNo=150023395673

=================================================================================

참고: http://blog.wystan.net/2007/08/18/bom-byte-order-mark-problem

참고: http://illegalargumentexception.blogspot.com/2009/05/java-rough-guide-to-character-encoding.html

 

 

개발자 PC의 Eclipse에서는 컴파일 에러가 나지 않는데

UNIX 서버에서 컴파일을 할 경우, 아래와 같은 에러가 날 수 있다.

 

illegal character: \65279

 

내용인 즉, Unicode 사용 시, 시그네처로 Byte Order Mark 라는 것이 들어갈 수 있는데

Eclipse가 아닌 다른 전문 편집기를 사용할 경우, 자동으로 삽입이 될 수 있다.

 

참고로 Windows의 Eclipse 상에서는 compile 에러가 확인되지 않으나

파일의 properties를 보면 Text file encoding 항목에

아래와 같이 표시되는 것을 알 수 있으니 참고할 것

 

Byte Order Mark is UTF-8 (BOM)

=================================================================================

회사에서 euc-kr을 utf-8로 바꾸는 작업을 했는데 바꾸고 컴파일을 하니

 

말도 안되는 오류가 막 떴다-_-

 

illegal character: \65279 라는 오류인데...

 

보면 java파일의 package 부분 앞에 이상한 문자가 섞여있다.

 

이 오류는 BOM(Byte Order Mark) 를 해석 못해서 발생하는 현상이다.

 

Bytes	Encoding Form
00 00 FE FF	UTF-32, big-endian
FF FE 00 00	UTF-32, little-endian
FE FF	UTF-16, big-endian
FF FE	UTF-16, little-endian
EF BB BF	UTF-8

 

이걸 해결하는 방법은 사용하는 에디터의 BOM을 지정안하게 하는 옵션을 활성화 하면된다.

 

그런데 오늘의 경우처럼 200파일 이상을 바꾸려면 보통일이 아니다.

 

그래서 .Net으로 간단한 프로그램을 만들었다.

 

사용법은 파일을 드레그 앤 드랍해서 '변환' 버튼을 누르면 땡이다 ㅋㅋ

 

기능이 너무 단순해서 조만간 업그레이드 해야할듯 ㅠ

출처 - http://blog.naver.com/woosiki1?Redirect=Log&logNo=20067256268