C++처럼 바이트 단위로 자르다가 만난 Rust panic

C++ 쪽을 기준으로 삼는다면 그쪽이 실제로 무엇을 썼는지 봐 두는 게 좋다. substr은 바이트만 센다.

std::string s = "Привет";
std::string t = s.substr(0, 5);
std::cout << t.size() << ' ' << std::hex
          << int(static_cast<unsigned char>(t.back())) << '\n';

출력은 5 d0이다. 마지막 바이트는 "и"의 선두 바이트이고 뒤따르는 바이트는 잘려 나갔다. 키릴 문자로만 된 이름을 홀수 한도로 자르면 매번 이렇게 끝나니 깨진 끝은 예측할 수 있고, 찾으러 갈 때 그게 도움이 된다.

메모. 아는 것. Rust 1.91부터 안정판에 str::floor_char_boundary가 있습니다. 말씀하신 거꾸로 가는 루프와 같은 일을 하고, n을 넘지 않는 가장 가까운 경계를 돌려줍니다. 문서에 그래도 자소 클러스터는 잘릴 수 있다고 바로 적혀 있습니다.

모르는 것. 예전 C++가 이미 써 둔 데이터에 무엇이 들어 있는지. 거기 끝이 깨진 레코드가 있다면 String::from_utf8은 오류를 돌려주고 String::from_utf8_lossy는 아무 말 없이 U+FFFD로 바꿉니다. 둘은 다른 결정이고, 뭔가 터진 다음이 아니라 읽기 전에 골라야 합니다.

깨진 레코드가 정말 있는지는 아직 가정입니다. 예전 데이터를 한 번 훑어보면 알 수 있습니다.

툴체인부터 확인해야 합니다. floor_char_boundary는 1.91부터만 안정판이고, 그보다 오래된 컴파일러는 바로 거부합니다.

문자 경계라고 글자 경계인 것도 아니야. 좋아하긴 일러. "й"는 코드 포인트 하나로 올 수도 있고, "и"에 결합 브레브 U+0306이 붙은 스칼라 두 개, 4바이트로 올 수도 있어. 그 사이를 자르면 UTF-8은 멀쩡하고 아무도 안 친 "и"가 남아. floor_char_boundary 문서도 스칼라 여러 개로 된 이모지로 같은 걸 보여 줘.

싼 해결책은 자르기 전에 입력 이름을 NFC로 정규화하는 거야. 그러면 "й"는 다시 코드 포인트 하나가 돼. 근데 전부 조합형이 있는 건 아니고, 나머지는 자소 클러스터 분할이 필요한데 Rust 표준 라이브러리도 C++ 표준 라이브러리도 그건 안 줘. 짜증 나지만, 적어도 이제 어떤 버그가 아직 네 몫인지는 알잖아.

fretboard 님 말대로 예전 덤프를 돌려 봤는데, 생각보다 지저분해요. 깨진 레코드 대부분은 예상대로였어요. error_len()이 None을 돌려주고 valid_up_to()가 끝에서 한 바이트 앞에 있는데, 이건 바이트 단위로 자른 흔적일 뿐 다른 게 아니에요. 그런 건 valid_up_to()에서 자르고 U+FFFD로 바꾸지 않아요. 대체 문자는 1바이트 자리에 3바이트를 쓰니까 값이 다시 한도를 넘을 수 있거든요.

그런데 몇 개는 문자열 중간에서 Some(1)이 나왔어요. 0x7F보다 큰 바이트 뒤에 올바른 시퀀스가 이어지지 않는 거고, 이건 자른 게 전혀 아니에요. 아마 예전 어떤 경로가 이름을 Latin-1이나 Windows-1251 같은 1바이트 인코딩으로 쓴 것 같은데, 두 인코딩은 같은 바이트를 다른 글자로 읽고, 바이트만 봐서는 어느 쪽이었는지 알 방법이 없어요. 그걸 valid_up_to()에서 자르면 이름 나머지를 잃고, from_utf8_lossy에 넣으면 누군가의 성 한가운데 U+FFFD가 박혀요.

나머지는 뭐가 썼는지 알아낼 때까지 손대지 않고 따로 테이블에 넣어 둬요. 그 예전 경로가 아직 어딘가에서 돌고 있다면 테이블은 계속 커지겠죠. 바이트 하나로는 몰라도, 이름 전체를 보면 Latin-1과 1251을 가를 수 있을까요? 1251로 쓴 키릴 성은 거의 전부 0xC0 이상 바이트고, Latin-1 이름은 대부분 ASCII에 악센트가 가끔 섞이는 정도니까 그 비율로 티가 날 것 같기도 해요. 다만 누군가의 이름을 휴리스틱이 정하게 두는 게 좀 꺼려져요.

두 경우를 코드에서 나눠 두면 두 번째 테이블은 저절로 채워진다. 함정은 from_utf8이 어느 경우인지를 error_len()으로만 알려 준다는 거다.

fn keep_len(bytes: &[u8]) -> Result<usize, std::str::Utf8Error> {
    match std::str::from_utf8(bytes) {
        Ok(_) => Ok(bytes.len()),
        Err(e) if e.error_len().is_none() => Ok(e.valid_up_to()),
        Err(e) => Err(e),
    }
}

5바이트에서 자른 키릴 문자 이름은 Ok(4)가 된다. b"Ren\xe9e"는 error_len: Some(1)이 달린 Err가 된다. 가져오기 전후로 Err 행을 세어 보면 예전 경로가 아직도 그런 걸 쓰고 있는지 알 수 있다.