요약

  • 2005년 10월 RFC 4180은 널리 쓰이던 CSV 형식을 기록하고 text/csv 미디어 유형을 등록했다. 정보 제공 문서로서 프로그램 간 차이를 인정했고, 첫 줄이 머리글인지 알리는 매개변수는 선택 사항으로 뒀다.
  • 2014년 1월 RFC 7111은 CSV의 행·열·셀을 위치로 선택하는 #row=4, #col=2, #cell=4,1을 정의했다. 행과 열은 1부터 센다. 이 문법을 모르는 클라이언트도 파일 전체는 받는다.
  • 위치는 기록의 신원이 아니다. 넷째 줄 위에 한 줄을 넣으면 같은 #row=4는 새 넷째 줄을 선택한다. 서버는 파일 요청에 어떤 프래그먼트가 쓰였는지 확실하게 알 수 없다.

자료의 한 줄에 주소를 달다

어떤 기관이 결정 목록을 CSV로 공개했다. 기자는 넷째 줄의 결정을 기사에서 인용하려 한다. 파일 주소만 적으면 독자가 표를 열고 직접 찾아야 한다. 주소 끝에 #row=4를 붙이면 마치 그 결정으로 바로 가는 문이 생긴다. 간편하고, 숫자 덕분에 확인 가능한 각주처럼 보인다.

그 문법은 2014년 1월의 RFC 7111에 담겼다. 이 문서는 text/csv 자원의 URI 프래그먼트를 정의한다. row는 행, col은 열, cell은 둘의 교차점을 선택한다. 문서의 data.csv#row=4 예시는 파일의 넷째 줄을 뜻한다. 예시에선 첫 줄이 열 이름이므로 넷째 줄은 세 번째 데이터 기록이다. ‘네 번째 데이터’라고 세기 시작한 사람은 이미 다른 줄에 도착한다.

CSV의 토대는 그보다 먼저 기록됐다. 2005년 10월 RFC 4180은 text/csv를 등록하고 쉼표, 따옴표, 줄바꿈, 머리글에 관한 흔한 규칙을 정리했다. 서두는 CSV가 오랫동안 스프레드시트 사이에서 오갔는데도 공통의 정식 설명이 없었다고 적었다. 구현마다 상당한 차이가 있다는 점도 인정했다. 이미 돌아가는 파일 교환을 설명한 정보 제공 RFC였지, 전 세계의 CSV를 한날한시에 같은 모습으로 고친 법령이 아니었다.

머리글이 있다면 미디어 유형의 선택 매개변수 header=present로, 없다면 header=absent로 알릴 수 있다. 빠져 있으면 읽는 프로그램이 판단해야 한다. RFC 7111의 번호는 어디까지나 파일의 줄을 1부터 센다. 사람이 말하는 ‘네 번째 기록’과 파일의 ‘넷째 줄’ 사이에 머리글 한 줄이 놓일 수 있다. 위치를 인용하려면 먼저 파일의 첫 줄부터 확인해야 한다.

번호는 자리를 기억하고, 기록은 기억하지 않는다

선택 방식은 넓다. #col=2는 둘째 열을, #cell=4,1은 넷째 줄 첫 칸을 가리킨다. 붙임표는 범위를, 별표는 마지막 행 또는 열을 뜻하며 세미콜론은 떨어진 구역들을 함께 고를 수 있게 한다. 파일 소유자가 모든 행에 개별 페이지를 만들어 주지 않아도 다른 사람이 작은 부분을 인용할 수 있다.

그런데 #row=4에는 기록의 고유 번호, 기대한 값의 해시, 작성자가 봤던 파일의 날짜가 들어 있지 않다. 클라이언트는 방금 받은 파일에서 넷째 줄을 찾는다. 그곳에 무언가 있으면 정확히 선택할 수 있다. 몇 달 전 링크를 만들었을 때 그 자리에 무엇이 있었는지는 숫자만으로 알 수 없다.

예를 들어 넷째 줄에 승인 결정이 있었다고 하자. 공개자가 이전 날짜의 누락된 결정을 발견해 그 위에 새 줄을 넣는다. 승인 기록은 다섯째 줄로 밀린다. 옛 링크는 깨지지 않는다. 파일도 있고 넷째 줄도 있다. 지원하는 프로그램은 그 줄을 반듯하게 강조한다. 링크의 성공만 검사하면 안심할 수 있지만, 이제 그 자리에 있는 결정은 다르다.

앞쪽 행을 지우면 반대 방향으로 움직인다. 정렬 순서를 바꾸면 많은 행이 한꺼번에 이동한다. 셀보다 앞에 열을 추가하면 #cell=의 열 번호도 다른 필드를 가리킨다. 이는 클라이언트의 오류를 상정하지 않아도 성립한다. 문서가 정의한 위치 선택을 충실하게 수행했을 때 생기는 결과다. 정확히 작동하는 링크가 잘못된 증거를 보여줄 수 있다.

어떤 실제 인용이 바뀌었다고 증명하려면 날짜가 있는 이전 파일과 이후 파일을 놓고 같은 기록이 어디로 움직였는지 봐야 한다. 여기의 원문 규격은 그 작동 원리를 보여주며 특정 사고 사례를 열거하지 않는다. 개별 각주를 확인할 때 필요한 자료는 명확하다. 작성자가 인용 당시 보았던 파일이다.

서버는 표를 보내고, 독자가 위치를 정한다

# 뒤의 내용을 누가 해석하는지는 2005년 1월 RFC 3986에 더 넓게 설명돼 있다. URI 프래그먼트는 클라이언트 쪽의 간접 참조다. 주 자원을 가져오기 전에 나머지 URI와 분리되고, 반환된 미디어 유형에 따라 사용자의 프로그램이 어느 부분을 지칭하는지 정한다. RFC 7111은 이 구조를 CSV에 적용했다.

서버는 ‘넷째 줄만 보내라’는 명령을 받지 않는다. 전체 CSV를 보내고, 지원하는 클라이언트가 받은 뒤 줄을 선택한다. 2014년 문서는 서버가 요청에 프래그먼트가 있었는지 신뢰할 만하게 판별할 방법이 없다고 적는다. 접속 기록은 파일이 전달됐다는 사실을 남기지만 독자가 어느 행을 보려 했는지는 남기지 않는다.

클라이언트에 따라 화면도 달라진다. 지원하는 프로그램은 넷째 줄을 보여줄 수 있다. 그 문법을 모르는 프로그램은 같은 주소에서 파일 전체를 열거나 내려받는다. 문서는 이를 점진적 도입의 한 장면으로 본다. 기본 파일은 여전히 접근 가능하므로 링크 자체는 잘 퍼진다. 그러나 한 독자의 정밀한 화면을 다른 독자가 똑같이 볼 것이라고 가정할 수 없다.

이 분리는 글쓴이에게 쓸모 있는 자유를 준다. 남의 공개 파일 안쪽을 가리키면서 파일 서버를 고칠 필요가 없다. 반대로 서버가 성공 응답을 보냈다는 사실만으로 어떤 행이 표시되거나 확인됐는지는 증명되지 않는다. 선택은 전송 뒤, 읽는 사람의 프로그램에서 일어난다.

규격에는 잘못된 위치를 다루는 규칙도 있다. 문법이 틀리면 추측해 고치지 않고 무시한다. 파일 끝을 넘은 단일 행도 무시하며, 끝을 넘는 범위는 실제 길이에 맞춘다. 존재하지 않는 좌표를 처리하는 방식이다. 넷째 줄은 존재하지만 예전과 다른 사실을 담은 경우는 이 규칙들로 찾아낼 수 없다.

RFC 7111의 보안 설명은 한 프로그램이 선택 부분만 보여주고 다른 프로그램이 전체 CSV를 보여주는 차이가 오해를 낳을 수 있다고 경고한다. 문서는 지원 클라이언트의 처리 방법을 정하지만 어느 브라우저의 어느 출시판에서 보급됐는지는 나열하지 않는다. 그런 연대기에는 날짜가 확인되는 구현 기록이 필요하다.

주소가 증거보다 오래 남을 때

CSV가 웹에서 널리 오간 까닭은 만들고 배포하기 쉬웠기 때문이다. RFC 4180은 파일의 미디어 유형을 정리했고, RFC 7111은 그 안쪽을 가리키는 방법을 붙였다. 공개자와 인용자 모두 일을 덜게 된다. 다만 주소가 오래 살아남는 것과 그 주소가 같은 사실을 보존하는 것은 다른 과제다.

오늘의 넷째 줄을 보여주는 임시 안내라면 위치로 충분할 수 있다. 몇 년 뒤에도 검증해야 하는 주장은 당시 파일의 보존본, 행 순서와 독립적인 기록 키, 또는 그 기록 자체의 안정된 주소가 필요하다. 모두 단순한 #row=4보다 손이 간다. 그 비용 덕분에 표가 다시 정렬된 뒤에도 원래 무엇을 인용했는지 알 수 있다.

RFC 7111은 독립 제출된 정보 제공 RFC이며, text/csv 등록 변경에 필요한 IESG 승인을 받았다. 규격은 위치를 선택하는 방법을 줬다. 그 자리에 앉은 기록에 영구적인 이름을 붙여주지는 않았다. 문패가 멀쩡해도 거주자는 이사할 수 있다.