퀴즈: 수신 파일의 형식 계약

1000건짜리 수신 파일에서 2건만 계좌 형식이 규격과 다르다. 문지기가 해야 할 일로 가장 알맞은 것은?

• 멀쩡한 998건을 적재하고 2건은 오류 목록으로 남겨 다음 날 처리한다
• 2건의 계좌를 규격에 맞게 고쳐 넣고 정정 내역을 보고서에 적는다
• 한 줄도 적재하지 않고 파일 전체를 사유와 함께 상대 기관에 돌려보낸다
• 2건을 건너뛰고 트레일러 건수를 998로 고쳐 적은 뒤 적재한다

고정폭 파일에서 수취인명 자리가 20이다. "김서준" 을 넣는 올바른 방법은? (규격은 CP949)

• CP949 로 인코딩한 6바이트 뒤에 공백 14바이트를 채운다
• 문자열 길이 3을 빼고 공백 17글자를 붙인 뒤 인코딩한다
• UTF-8 로 인코딩한 9바이트 뒤에 공백 11바이트를 채운다
• 이름을 20글자가 되게 공백으로 채운 뒤 CP949 로 인코딩한다

RFC 4180 에 대한 설명으로 옳은 것은?

• IETF 표준 트랙 문서라 따르지 않으면 규격 위반이 된다
• 쉼표가 든 필드는 역슬래시로 이스케이프하도록 정한다
• 필드 구분자를 세미콜론으로 바꾸는 방법을 함께 규정한다
• Informational 문서이며 스스로 어떤 인터넷 표준도 규정하지 않는다고 밝힌다

CSV 수신 파일을 line.split(",") 로 잘랐더니 수취인명에 쉼표가 든 줄에서 계좌 검증이 실패한다. 원인과 대처는?

• 파일이 CRLF 로 끝나서 마지막 필드에 캐리지리턴이 붙었으므로 rstrip 한다
• 인용된 쉼표까지 구분자로 세어 필드가 밀린 것이므로 csv 모듈로 읽는다
• 상대 기관이 규격을 어긴 것이므로 그 줄을 FIELD 오류로 거절하면 된다
• 계좌 정규식이 너무 엄격한 것이므로 쉼표를 허용하도록 완화한다

규격은 CP949 인데 상대가 UTF-8 로 보낸 고정폭 파일이 있다. 인코딩 검사 외에 이 사고를 한 번 더 잡아 주는 검사는?

• 레코드 바이트 폭 검사 - 한글이 2바이트에서 3바이트가 되어 줄 길이가 달라진다
• 파일 해시 검사 - 같은 내용이라도 해시가 달라지므로 중복으로 걸린다
• 트레일러 합계 검사 - 금액 필드가 숫자가 아니게 되어 합계가 어긋난다
• 파일 이름 규칙 검사 - 인코딩이 바뀌면 이름 규칙도 함께 어긋난다

어제 수용한 파일과 기관·일련번호가 같은 파일이 다시 왔다. 파일의 sha256 은 다르다. 올바른 판정은?

• 단순 재전송이므로 조용히 무시하고 수용 목록에서 빼기만 한다
• 새 내용이므로 앞 파일을 취소 처리하고 이 파일로 덮어 적재한다
• 해시가 다르니 다른 파일이다. 중복이 아니므로 그대로 적재한다
• 같은 번호에 다른 내용이라 충돌이다. 거절하고 상대에게 번호를 올려 달라고 요청한다