타기관 파일 연계할때 인코딩 약속의 의미

Question

안녕하세요 타기관과 연계업무를 담당하고 있는 개발자 인데요본격적인 개발전에 타 기관과 파일 포멧에 대해 약속을 했었습니다. 확장자는 무엇이며, 구분자는 무엇이고, 파일명은 무엇이다,,,,,,,,, 그러면서 한가지 더 약속한게 있는데요, &#34;인코딩은 무엇이다.&#34;이렇게 정한 인코딩의 의미가 궁금해졌습니다. 처음엔 '정한 인코딩으로 파일을 만들고 송신할때도 그 인코딩으로, 타 기관이 수신했을때도 그 인코딩 상태로 넘겨준다' '정한 인코딩으로 파일을 생성할거 뿐만 아니라, 타 기관이 수신해서 그 파일의 인코딩을 확인해도 약속했던 인코딩이어야 한다'고 생각했어요.제가 이게 틀리다고 생각하는 이유는,, 숫자만으로 이루어진 데이터를 약속했던 인코딩으로 파일을 생성했음에도 불구하고 OS에서 해당 파일의 인코딩을 확인했을 때 그 인코딩이 안나오는 경우가 있더라구요. 이대로 연계를 태우면 약속했던 인코딩이 아닌채로 넘어가게될 꺼고, 수신 기관도 그 인코딩이 아닌 파일을 받게 되겠더라구요. '그럼 애초에 저렇게 약속을 하면 안되는거였을까..'라고 생각이 들었지만!연계파일의 인코딩에 대해 이렇게 생각하는게 더 맞을거 같다고 생각하는데 어떠신가요? '(OS에서 해당 파일의 인코딩이 무엇으로 나오든) 약속했던 인코딩으로 읽어서 사용하세요.' 여러분들 의견이 어떤지 궁금합니다.예시를 적어야 겠습니다 ㅎㅎA서버는 linux, B서버는 ubuntu 라고 가정하구요. 서로 송수신하기 위한 데이터는이름1|취미1|나이1 이름2|취미2|나이2 이름3|취미3|나이3 ....위와 같은 형식의 파일이고 txt파일이든 csv파일이든 상관없습니다. A서버과 B서버의 기본인코딩?(locale)값은 서로 다른 상황입니다. 예를들어 A서버는 utf8, B서버는 euckr 이라고 가정할께요 A서버와 B서버 사이에 연계를 통해서 파일을 주고 받는다고 가정을 할께요. (A서버의 send폴더에 파일을 생성하면 자동으로 몇 초 후 B서버의 rcv폴더로 옮겨집니다)A서버와 B서버는 서로 연계할때 파일에 대한 약속을 했습니다. 확장자는 txt, 구분자는 파이프(|), 인코딩은 unicode이 경우, A서버에서 파일을 생성 시, 인코딩을 unicode로 이름,취미,나이 데이터를 파일로 생성했습니다. A서버의 send폴더로 파일을 옮기면 B서버의 rcv폴더로 옮겨지게 되고 B서버에서 그 파일을 열때 기본인코딩이 euckr이니까(unicode가 아니니까) 일부 문자가 깨질꺼 같습니다. 서로 unicode로 약속했는데 B서버가 unicode로 열지 않아서요. 맞나요??문제는 이름,취미,나이가 아닌 숫자로만 이루어진 데이터일때 입니다. 예를들어 키,나이,몸무게 라고 하면170|24|45 180|30|70 .........이럴 경우, A서버에서 unicode로 인코딩해서 파일을 생성했더라도 B서버에서 파일을 열었을 때 잘 열립니다. 내용이 숫자밖에 없어서요. A서버에서 unicode로 인코딩해서 파일을 만들었는데 A서버에서 파일의 인코딩을 확인해보니 (unicode일줄 알았는데)utf8입니다.(?) B서버로 옮겨지고 나서 B서버에서 확인해도 utf8입니다. <-- 이 부분이 unicode로 약속했던거를 깨게 되는건가요? 저는 위의 '인코딩은 unicode'라고 약속했던것의 뜻은 'B서버에 파일이 떨어질때 unicode상태로 떨어지게 해줄께'가 아니라 'B서버에서 (그 파일의 인코딩을 확인했을 때 utf8이든 euckr이든) 그 파일을 읽을 때 인코딩을 unicode로 읽어서 사용하기'라고 받아들이는게 맞는거 아닐까? 라는 생각이 들더라구요.

엡실론 · Accepted Answer

일반적인 텍스트 파일, csv 파일 같은 경우에는 파일에 인코딩 정보가 저장되지 않습니다. 그래서 인코딩을 맞추는게 필요하지요.OS에서 말하는 파일의 인코딩은 어디까지나 추정입니다. UTF-8, EUC-KR 같은 경우 모두 ascii와 호환되도록 되어 있는데, 다시 말하면 숫자와 '|'는 세 인코딩에서 모두 똑같이 표현됩니다. 따라서 숫자만으로 이루어진 예시 데이터 같은 경우, OS에서는 정확하게 인코딩을 추정할 방법도 없고, 무엇으로 읽든 별 상관도 없습니다.'(OS에서 해당 파일의 인코딩이 무엇으로 나오든) 약속했던 인코딩으로 읽어서 사용하세요.'맞는 말입니다. 애초에 OS에서 나오는 인코딩은 큰 의미가 없습니다.

자읭식과읭 · Answer

예시가 뭔지 궁금합니다보통 연계업무 관련 업무할 때 euckr을 쓰시는 분들이 있어서 그러지 마시라고 미리 인코딩을 정하시더라구요디비에 한글이 euckr로 저장되어있으면 골치 아픈게 있어서...꼭 그걸로 쓰셔야 하는 분들은 어쩔수 없지만...말씀하신 예시가 뭔지는 모르겠지만,Utf8로 하기로 하셨다면 모두 그걸로 하시는게 맞지 않을까요?톰캣에서 내부 application properties 인코딩이 다른거다? 뭐 이런 예시가 있으면 좋겠습니다

ansdbduf · Answer

Http 프로토콜은 그래서 요청/응답헤더에 Accept랑 Content-Type을 명시하죠. 혹시 인코딩 문제가 아니라 이 기종간의 byte order 문제일 수 있습니다. 빅엔디안/리틀엔디안

rezigrene · Answer

인코딩은⠟⠋⠥⠊⠕⠶와 같은 신호를 어떻게 해석할까하는 규칙같은 것입니다.https://ko.wikipedia.org/wiki/%ED%95%9C%EA%B8%80_%EC%A0%90%EC%9E%90한글점자 인코딩으로 해석하면 '인코딩' 이되고https://www.teachingvisuallyimpaired.com/uploads/1/4/1/2/14122361/ueb_braille_chart.pdf영문점자 규칙으로 해석하면 'qfuio7' 이 되겠지요.영문점자 규칙으로 신호를 주고받기(연계) 하였는데 받아서 해석하니 qfuio7 이라고 나오고 한글점자 규칙으로 해석해서 '인코딩' 이라고 제대로 된 원본이 보이면, 알아서 바꿀게 아니라 우선 규칙을 서로 잘못정하거나, 잘못보낸게 아닌지 확인하는 작업이 필요합니다.OS에서 해당 파일의 인코딩을 확인했을 때 그 인코딩이 안나오는 경우가 가 무슨말씀이신지는 잘 모르겠습니다.

rezigrene · Answer

유니코드에서 주로 사용하는 인코딩방식이 UTF-8 이니 그냥 동일한 의미로 말했을 가능성이 높습니다. UTF-8(유니코드 문자셋)을 쓰는 시스템이든 euc-kr(ks x 1003 문자셋) 을 쓰는 시스템이든 영문, 숫자의 바이트 값은 같으니 해당 문자만으로 이루어진 파일은 양쪽다 잘 열릴 겁니다. 다만 언제 한글/특수문자등이 들어갈지모르니 동일하게 UTF-8로 읽고 쓰도록 구성하는게 좋겠죠.좀더 구분지어 설명하자면 아래와 같습니다. ---------------------------문자를 숫자(코드)에 대응시키는 방식 (문자셋, 문자표?)- unicode- ks x 1001- ks x 1003숫자를 컴퓨터에서 쓸 바이트로 변환(인코딩)하는 방식- UTF-8(unicode)- UTF-16(unicode)- euc-kr(ks x 1001 + ks x 1003)

신히 · Answer

타기관 연계할 때 인코딩 방식은 필수입니다. 과거에는 EUC-KR을 주로 사용했지만 웹서비스가 많아지면서 UTF-8 인코딩도 늘었죠. 만일 우리쪽 인코딩이 EUC-KR로 되어 있고 UTF-8로 통신하기로 약속했다면 우리쪽 인코딩을 UTF8로 변환해서 보내야 합니다. 서버측의 locale은 의미가 없습니다. 최종 전송할 때 전문의 인코딩을 무엇으로 하냐가 중요합니다. 보내는 쪽에서 우리쪽의 인코딩이 뭔 줄 모른다. 그냥 UTF8로 변환해서 보낸다. 이런것은 말이 안됩니다. (그리고 유니코드랑 UTF-8이랑 말씀하신 것은 문자셋과 인코딩 의미를 혼동하신듯)

타기관 파일 연계할때 인코딩 약속의 의미

6개의 답변

Q&A 목록