UTF-8을 임의 길이 코드 유닛으로 확장한 UTF-8000 공개, 켄 톰슨은 "ipv6를 ipv50으로 바꾸는 것"

UTF-8000은 유니코드 컨소시엄이 승인한 것도 아니고 대표하는 것도 아님. 이모지 범위 늘리고 가상 언어에 조류 울음이나 개 짖는 소리까지 배정할 날이 오면 누군가 좋아하겠지만, 어쨌든 재밌는 해킹임. 큰 수를 바이트로 인코딩할 방법을 만들었으면 왜 24비트에서 멈추겠어.

24비트? 지금 UTF-8은 21비트까지만 감. 그건 유니코드 범위 때문에 생긴 제한이고 인코딩 자체로는 임의라서, 단일 리드 바이트 방식이면 36비트까지 페이로드가 들어감.

FF 바이트가 있으면 잘못된 UTF-8 파일인 걸 바로 알아낼 수 있는데, 이 방식은 그 성질이 없음.

0xFF가 없는 비UTF8 바이트열도 많아서 실용적으로는 별로 유용하지 않음.

그래도 UTF-8 스펙이 얼마나 우아하고 확장 가능한지 보는 건 즐거움. 0xFF 리드 바이트 같은 변칙 없이 0xFE 리드 바이트만 써도 지금 21비트에 비해 36비트 여유가 있음.

켄 톰슨 서한이 정확함. 5, 6바이트 확장은 원래 예상했고 표준은 유니코드 크기를 덮으려고 만든 거라 더 설명하는 건 종이 낭비라고 봤음. 7에서 8바이트로 가는 확장은 좀 엉성한데, 팔로우 바이트 수를 아는 게 아니라 문자열 전체를 읽어야 하거든. ipv6를 ipv50으로 바꾸는 것과 같음.

8바이트로 제한하면 첫 바이트만 보고 팔로우 바이트 수를 항상 알 수 있음. 4.47조 문자면 아무도 더 필요 없음. 유명한 마지막 말이 되겠지만.

UTF-8은 원래 6바이트까지 지원했는데(RFC 2279), 2003년에 UTF-16 제약에 맞추려고 4바이트로 제한됨. 코드포인트 공간은 아직 85% 남아 있으니 그게 문제가 될 때쯤이면 UTF-16은 오래전에 사라졌으면 좋겠음.

실용적으로 코드포인트가 임의 바이트 수를 갖는 건 버퍼 오버플로 문제를 부름. 한계를 두면 어떤 구현은 디코딩하고 다른 구현은 못 하는 상황이 생김.

그 공간으로 뭘 할까? RPG 캐릭터 커스터마이징 같은 완전 커스텀 이모지, JPEG나 GIF, 유니코드 스크립트로 Doom 돌리기까지 가능하겠음. 다만 U+E000–U+F8FF 같은 사설 사용 영역이 이미 꽤 넓음.

자기동기화가 좋다는데 실제로 의존해본 기억이 없음. UTF-8의 더 강한 성질은 부분 문자열 검색이 바이트열 검색으로 환원된다는 것인데, UTF-8000은 그게 안 됨.

첫 문단에 동기가 있었으면 좋겠음. 임의로 큰 정수를 인코딩한다는 건 알겠는데 그래서 뭐? 재미로 하는 건 알겠음.

어떤 프로젝트도 복잡하게 만드는 사람에게서 안전하지 않음. KISS를 강제할 사람이 필요함.

UTF-8의 좋은 점은 이 제안이 복잡화가 아니라 리드 바이트를 여러 개 쓰는, 원래 아이디어의 최소하고 자연스러운 확장이라는 것임.