Quiz: The Characters Are Broken

고객이 보낸 CSV 가 엄격 UTF-8 디코딩에 성공했다. 이 사실이 갖는 무게로 가장 정확한 것은?

• 아무 바이트나 UTF-8 로 읽히므로 이 사실만으로는 아무것도 알 수 없다
• UTF-8 은 올바른 바이트 열이 규격으로 정해져 있어, 디코딩 성공 자체가 강한 증거가 된다
• 디코딩이 성공했으니 글자가 뭉개졌을 가능성은 완전히 사라진다
• 파일 안에 인코딩이 적혀 있으므로 디코딩 성공 여부와 무관하게 알 수 있다

한글이 알파벳 기호로 보이지만 encode("latin-1").decode("utf-8") 로 원문이 돌아오는 파일이 있다. 왜 되돌릴 수 있는가?

• latin-1 은 0부터 255까지 모든 바이트에 글자를 하나씩 붙여 두어 바이트를 잃지 않기 때문이다
• latin-1 이 UTF-8 의 부분집합이어서 두 인코딩이 같은 바이트를 쓰기 때문이다
• 파이썬이 원래 바이트를 문자열 객체 안에 따로 보관해 두기 때문이다
• 한글이 세 바이트라서 세 글자로 나뉜 것을 다시 세 개씩 묶으면 되기 때문이다

어떤 파일을 열어 보니 U+FFFD 가 수백 개 들어 있다. 가장 적절한 판단은?

• 다른 인코딩으로 다시 읽으면 되돌아오므로 후보를 더 넣어 본다
• U+FFFD 를 공백으로 바꾸고 나머지 값으로 집계를 진행한다
• 읽을 수 없던 바이트가 한 글자로 뭉개져 원래 바이트를 알 수 없으므로 원본을 다시 받는다
• 파일이 UTF-16 이라는 뜻이므로 UTF-16 으로 다시 읽는다

두 파일의 이름 칸을 조인했더니 0건이 맞았다. 화면에서는 이름이 똑같이 보인다. 가장 먼저 의심할 것은?

• 한쪽 파일의 줄 끝이 CRLF 라서 이름 값이 통째로 달라졌다
• 한쪽은 완성형 음절로, 다른 쪽은 자모 분해형으로 저장되어 코드포인트가 다르다
• 조인 키의 대소문자가 달라 한글 비교가 실패했다
• 이름 칸의 순서가 파일마다 달라 다른 칼럼끼리 비교됐다

웹 화면에서 복사해 온 고객명에 제로폭 공백(U+200B)이 섞였다. strip() 만으로 처리하면 어떻게 되는가?

• 제로폭 문자는 공백이 아니어서 남고, 눈에 보이지 않은 채 키 비교를 계속 실패시킨다
• 제로폭 문자는 길이가 0 이라 문자열에 저장되지 않으므로 아무 문제가 없다
• strip() 이 유니코드 공백을 모두 제거하므로 제로폭 문자도 함께 사라진다
• 제로폭 문자가 앞뒤가 아니라 가운데 있을 때만 남고 양끝은 지워진다

UTF-8 로 저장된 CSV 앞에 BOM 세 바이트가 붙어 있다. 이것을 떼지 않고 읽으면 가장 흔히 무엇이 깨지는가?

• 파일 전체가 UTF-8 로 디코딩되지 않아 읽기 자체가 실패한다
• 마지막 줄이 잘려 마지막 행이 통째로 사라진다
• 숫자 칼럼이 문자열로 읽혀 합계가 0 이 된다
• 첫 칼럼 이름 앞에 보이지 않는 글자가 붙어 헤더 이름 비교가 조용히 실패한다