CSV·vCard·iCalendar 파일, 열리는 것과 제대로 옮겨지는 것은 다르다

연락처가 같은 개수로 나타나도 전화번호의 앞자리나 메모의 줄바꿈이 바뀌면 이전 결과가 달라진다. CSV·vCard·iCalendar는 표와 연락처, 일정을 담는 서로 다른 구조다. 직접 읽어 본 CSV 예제와 필드·시간대·반복 점검으로 가져오기 결과를 살펴본다.

형식 이름은 담고 있는 정보의 구조를 설명한다

vCard 표준 RFC 6350과 iCalendar 표준 RFC 5545는 형식의 구조를 정의한다. 표준에 정보가 정의돼 있다는 사실과 특정 서비스가 모든 필드를 가져온다는 것은 다른 조건이다. 목적지의 실제 지원 범위를 확인해야 한다.

CSV 예제에서 선행 0과 줄바꿈을 확인했다

미디어플럭스는 실제 개인 정보가 없는 가상 레코드 두 개를 CSV로 작성하고 Python 표준 라이브러리로 다시 읽었다. 첫 식별자는 0012이고 메모에는 쉼표, 포함이 들어 있다. 두 번째 메모에는 실제 줄바꿈이 있다.

예제 CSV 파일과 읽기 결과에서 입력과 출력의 관계를 확인할 수 있다. 표준 CSV 읽기로 데이터 레코드 두 개와 선행 0, 메모의 쉼표·줄바꿈이 유지되는 것을 확인했다. 줄바꿈 문자만 세는 방식은 논리적인 레코드 수와 다른 결과를 냈다.

이 실험은 특정 연락처 서비스의 가져오기 시험이 아니다. Python csv 문서가 설명하는 표준 읽기 기능으로 구조를 확인한 예제다. 스프레드시트나 서비스가 값을 숫자로 해석하면 선행 0이 다르게 표시될 수 있으므로 실제 가져오기 결과를 다시 봐야 한다.

파일의 줄 수와 레코드 수가 달라지는 이유를 읽는다

직접 만든 CSV 예제의 두 번째 메모에는 실제 줄바꿈이 들어 있다. 텍스트 편집기에서는 그 메모가 두 줄로 보이지만 따옴표로 묶인 한 필드다. 줄마다 잘라 읽으면 한 사람의 메모가 다음 레코드로 나뉜 것처럼 보일 수 있다. CSV를 지원하는 읽기 기능으로 필드와 레코드를 해석해야 하는 이유다.

첫 식별자 0012도 같은 문제를 보여준다. 식별자는 계산할 숫자가 아니라 문자 값인데 스프레드시트가 숫자로 해석하면 앞의 0이 빠질 수 있다. 전화번호나 상품 코드처럼 앞자리의 의미가 있는 값은 표시와 저장된 내용을 함께 확인한다. 열 너비를 넓혀 보이는 문제와 값 자체가 바뀐 문제는 다르다.

메모의 쉼표를 열 구분자로 잘못 처리하면 뒷부분이 다른 필드로 밀린다. 가져오기 결과에서 이름과 전화번호가 정상이라고 메모까지 맞는 것은 아니다. 한글, 쉼표, 줄바꿈, 선행 0처럼 어려운 요소를 포함한 표본이 있어야 이런 차이를 찾을 수 있다.

연락처 한 개에 여러 값이 있다면 개수보다 연결을 본다

한 연락처에 업무 번호와 개인 번호, 두 이메일이 있을 수 있다. 목적지에 연락처 한 개가 나타나더라도 두 번호의 종류와 연결이 유지됐는지 확인한다. 이름 한 개와 번호 한 개만 보는 점검은 자료의 개수는 맞추면서 중요한 필드를 놓칠 수 있다.

일정도 한 개의 첫 시각만 확인하면 반복과 예외를 놓친다. 반복 중 한 날짜를 변경한 일정이 있다면 그 예외까지 목적지가 지원하는지 확인할 대상이다. 종일 일정과 시각이 있는 일정, 시간대가 명시된 일정은 별도 표본으로 볼 수 있다. 형식의 이름은 지원 출발점이지 자신의 모든 필드가 유지됐다는 증거가 아니다.

재시도 전에는 현재 가져온 결과를 기록한다. 누락만 채우려다가 같은 연락처나 일정을 여러 번 추가할 수 있다. 사용한 파일과 시도 날짜, 처리된 범위를 남기고 목적지가 중복을 어떻게 다루는지 안내를 확인한다. 현재 결과를 모르는 상태에서 반복 가져오기를 하지 않는다.

이전 결과에는 유지된 필드, 별도로 보관한 정보, 목적지에서 지원하지 않는 요소, 아직 확인하지 못한 항목을 남긴다. 원래 서비스를 정리할 시점은 다운로드가 끝난 때보다 필요한 정보가 실제 목적지에서 다시 쓰이는지 확인한 뒤로 잡는 것이 판단에 맞다.

열 이름보다 필드 대응을 확인한다

CSV의 열이 목적지의 어떤 필드로 들어가는지 대조한다. 이름과 성, 회사와 직책, 휴대전화와 업무 번호가 따로 있는 자료라면 하나의 이름·번호로 합쳐지지 않았는지 확인한다. 문자 인코딩이나 구분 방식이 맞지 않으면 한글이 깨지거나 여러 열이 한 칸으로 보일 수 있다.

스프레드시트에서 편집하고 다시 저장할 때 값의 해석이 바뀔 수도 있다. 식별자나 전화번호를 숫자로 변환했는지, 날짜 형식이 바뀌었는지 살핀다. 보기 편한 표시 형식과 원래 저장된 값이 같은지 확인해야 한다.

vCard에 여러 전화번호·이메일이 있으면 종류와 연결이 유지되는지 확인한다. 파일 전체를 읽을 수 있어도 목적지가 일부 필드만 처리할 수 있다. 지원하지 않는 정보를 따로 보관할지, 이전 범위에서 제외할지 결정한다.

일정은 날짜와 시간대, 반복을 함께 본다

iCalendar 자료에는 날짜·시각과 반복 등 일정 구조가 들어갈 수 있다. 한 번의 시작 시각이 맞는다고 반복 일정 전체가 정확하게 이전됐다고 판단하지 않는다. 종일 일정, 반복 일정, 예외 날짜 등 자신에게 중요한 종류를 표본에 포함한다.

시간대가 있는 일정과 현지 시각만 표시되는 일정은 목적지에서 다르게 처리될 여지가 있다. 원래 서비스에서 날짜와 시각, 시간대를 기록하고 가져온 뒤 같은 일정을 대조한다. 하루 차이가 보인다고 곧바로 원본을 일괄 수정하지 않는다.

알림이나 참석자·공유 상태가 유지되는지도 별도의 지원 사항이다. 일정 본문을 가져오는 기능이 초대 관계나 전달 권한까지 모두 이전하는 것은 아닐 수 있다. 목적지의 공식 안내와 실제 결과를 함께 확인한다.

시험 가져오기는 누락과 중복을 함께 본다

원본 파일은 유지하고 작은 묶음을 시험한다. 한글 이름, 선행 0, 여러 연락처 필드, 줄바꿈 메모, 반복 일정 등 실제 자료의 특성을 포함한다. 가져온 결과의 개수와 필드, 검색·정렬·시각을 대조한다.

재시도할 때는 같은 자료가 추가돼 중복으로 남는지 확인한다. 누락을 채우려다 동일 레코드를 여러 번 넣을 수 있으므로 시도 날짜와 파일, 처리 범위를 기록한다. 삭제하거나 덮어쓰기 전에 현재 결과의 사본을 유지할 수 있는지도 살핀다.

실제 개인 자료가 든 파일은 공개 도구나 게시물에 올리지 않는다. 형식을 질문할 때는 비공개 값을 제거한 가상 예제를 사용할 수 있지만, 그 예제의 성공이 실제 자료 전체를 검증한 것은 아니라는 점을 구분한다.

이전 완료의 범위를 기록한다

필드가 유지된 항목, 지원되지 않은 정보, 시각이나 반복의 차이, 확인하지 못한 범위를 남긴다. 원래 서비스와 목적지의 이름, 사용한 내보내기 형식, 기준 날짜도 기록하면 다음 작업을 이어가기 쉽다.

Google 데이터 내보내기 확인과 서비스 이전 인수를 함께 적용하면 파일 구조뿐 아니라 공유와 관리 관계도 점검할 수 있다. 형식의 호환성을 안다는 것과 실제 자기 자료가 올바르게 이전됐다는 것은 별개의 확인이다.