The Rust Programming Language

문자열에 UTF-8 텍스트를 저장하기

4장에서도 문자열을 다뤄봤지만, 이번에는 좀 더 깊이 살펴보겠습니다. 러스트 입문자는 흔히 문자열 부분에서 막히곤 합니다. 이는 세 가지 이유가 조합된 결과인데요. 발생할 수 있는 에러를 최대한 표시하는 러스트의 성향, 많은 프로그래머의 예상보다 문자열이 복잡한 자료구조라는 점, UTF-8 이 그 이유입니다. 이 때문에 다른 언어를 사용하다 오면 러스트의 문자열은 어려워 보이죠.

문자열이 컬렉션 장에 있는 이유는 문자열이 바이트의 컬렉션으로 구현되어 있고, 이 바이트들을 텍스트로 통역할 때 유용한 기능을 제공하는 여러 메서드들을 구현해 두었기 때문입니다. 이번 절에서는 생성, 갱신, 값 읽기와 같은 모든 컬렉션 타입이 가지고 있는, String에서의 연산에 대해 이야기해 보겠습니다. 또한 String을 다른 컬렉션들과 다르게 만드는 부분, 즉 사람과 컴퓨터가 String 데이터를 통역하는 방식 간의 차이로 인해 생기는 String 인덱싱의 복잡함을 논의해 보겠습니다.

문자열이 뭔가요?

먼저 문자열이라는 용어가 정확히 무엇을 뜻하는 것인지 정의해 보겠습니다. 러스트는 핵심 언어 기능 내에서 딱 한 가지 문자열 타입만 제공하는데, 이는 바로 문자열 슬라이스인 str이고, 이것의 참조자 형태인 &str을 많이 봤죠. 4장에서는 문자열 슬라이스 에 대해 얘기했고, 이는 다른 어딘가에 저장된 UTF-8으로 인코딩된 문자열 데이터의 참조자입니다. 예를 들어, 문자열 리터럴은 프로그램의 바이너리 출력물 내에 저장되어 있으며, 그러므로 문자열 슬라이스입니다.

String 타입은 핵심 언어 기능 내에 구현된 것이 아니고 러스트의 표준 라이브러리를 통해 제공되며, 커질 수 있고, 가변적이며, 소유권을 갖고 있고, UTF-8으로 인코딩된 문자열 타입입니다. 러스타시안들이 “문자열”에 대해 이야기할 때, 그들은 보통 String과 문자열 슬라이스 &str 타입 둘 중 하나를 이야기한 것이지, 특정한 하나를 뜻하는 것은 아닙니다. 이번 절은 대부분 String에 관한 것이지만, 두 타입 모두 러스트 표준 라이브러리에서 매우 많이 사용되며 String과 문자열 슬라이스 모두 UTF-8으로 인코딩되어 있습니다.

새로운 문자열 생성하기

Vec<T>에서 쓸 수 있는 많은 연산이 String에서도 마찬가지로 똑같이 쓰일 수 있는데, 이는 String이 실제로 바이트 벡터에 더하여 몇 가지 보장, 제한, 기능들을 추가한 래퍼(wrapper)로 구현되어 있기 때문입니다. Vec<T>와 String이 같은 방식으로 동작한다는 함수의 예로서 예제 8-11과 같이 새 인스턴스를 생성하는 new 함수가 있습니다.

fn main() {
    let mut s = String::new();
}

예제 8-11: 비어있는 새로운 String 생성하기

이 라인은 우리가 어떤 데이터를 담아둘 수 있는 s라는 빈 문자열을 만들어 줍니다. 종종 우리는 문자열에 담아두고 시작할 초깃값을 가지고 있을 것입니다. 그런 경우, to_string 메서드를 이용하는데, 이는 Display 트레잇이 구현된 어떤 타입이든 사용 가능하며, 문자열 리터럴도 이 트레잇을 구현하고 있습니다. 예제 8-12에서 두 가지 예제를 보여주고 있습니다:

fn main() {
    let data = "initial contents";

    let s = data.to_string();

    // the method also works on a literal directly:
    let s = "initial contents".to_string();
}

예제 8-12: to_string 메서드를 사용하여 문자열 리터럴로부터 String 생성하기

이 코드는 initial contents를 담고 있는 문자열을 생성합니다.

또한 문자열 리터럴로부터 String을 생성하기 위해서 String::from 함수를 이용할 수도 있습니다. 예제 8-13의 코드는 to_string을 사용하는 예제 8-12의 코드와 동일합니다:

fn main() {
    let s = String::from("initial contents");
}

예제 8-13: String::from 함수를 사용하여 문자열 리터럴로부터 String 생성하기

문자열이 너무나 많은 것들에 사용되기 때문에, 문자열을 위해 다양한 제네릭 API들을 사용할 수 있으며, 다양한 옵션들을 제공합니다. 몇몇은 쓸모없는 것처럼 느껴질 수도 있지만, 다 사용할 곳이 있습니다! 지금의 경우, String::from과 to_string은 정확히 똑같은 일을 하며, 따라서 어떤 것을 사용하는가는 여러분의 스타일과 가독성에 따라 달린 문제입니다.

문자열이 UTF-8으로 인코딩되었음을 기억하세요. 즉, 아래의 예제 8-14에서 보는 것처럼 우리는 인코딩된 어떤 데이터라도 포함시킬 수 있습니다:

fn main() {
    let hello = String::from("السلام عليكم");
    let hello = String::from("Dobrý den");
    let hello = String::from("Hello");
    let hello = String::from("שָׁלוֹם");
    let hello = String::from("नमस्ते");
    let hello = String::from("こんにちは");
    let hello = String::from("안녕하세요");
    let hello = String::from("你好");
    let hello = String::from("Olá");
    let hello = String::from("Здравствуйте");
    let hello = String::from("Hola");
}

예제 8-14: 문자열에 다양한 언어로 인사말 저장하기

위의 모두가 유효한 String 값입니다.

문자열 갱신하기

String은 크기가 커질 수 있으며 이것이 담고 있는 내용물은 Vec의 내용물과 마찬가지로 더 많은 데이터를 집어넣음으로써 변경될 수 있습니다. 추가로, + 연산자나 format! 매크로를 사용하여 편리하게 String 값들을 서로 접합할 수 있습니다.

push_str과 push를 이용하여 문자열 추가하기

예제 8-15와 같이 문자열 슬라이스를 추가하기 위해 push_str 메서드를 이용하여 String을 키울 수 있습니다:

fn main() {
    let mut s = String::from("foo");
    s.push_str("bar");
}

예제 8-15: push_str 메서드를 사용하여 String에 문자열 슬라이스 추가하기

s는 위의 두 라인 뒤에 foobar를 담게 될 것입니다. push_str 메서드는 문자열 슬라이스를 매개변수로 갖는데 이는 매개변수의 소유권을 가져올 필요가 없기 때문입니다. 예를 들어, 예제 8-16의 코드에서는 s2의 내용물을 s1에 추가한 후 s2를 쓰려고 합니다.

fn main() {
    let mut s1 = String::from("foo");
    let s2 = "bar";
    s1.push_str(s2);
    println!("s2 is {s2}");
}

예제 8-16: 문자열 슬라이스를 String에 붙인 이후에 문자열 슬라이스를 사용하기

만일 push_str 함수가 s2의 소유권을 가져갔다면, 마지막 줄에서 그 값을 출력할 수 없었을 것입니다. 하지만, 이 코드는 우리가 기대했던 대로 작동합니다!

push 메서드는 한 개의 글자를 매개변수로 받아서 String에 추가합니다. 예제 8-17은 push 메서드를 사용하여 String에 “l”을 추가하고 있습니다:

fn main() {
    let mut s = String::from("lo");
    s.push('l');
}

예제 8-17: push를 사용하여 String 값에 한 글자 추가하기

위의 코드를 실행한 결과로 s는 lol을 담고 있을 것입니다.

+ 연산자나 format! 매크로를 이용한 접합

종종 우리는 가지고 있는 두 개의 문자열을 조합하고 싶어 합니다. 그렇게 하는 방법 중 하나는 아래 예제 8-18과 같이 + 연산자를 사용하는 것입니다:

fn main() {
    let s1 = String::from("Hello, ");
    let s2 = String::from("world!");
    let s3 = s1 + &s2; // note s1 has been moved here and can no longer be used
}

예제 8-18: + 연산자를 사용하여 두 String 값을 하나의 새로운 String 값으로 조합하기

문자열 s3는 Hello, world!를 담게 될 것입니다. s1이 더하기 연산 이후에 더 이상 유효하지 않은 이유와 s2의 참조자가 사용되는 이유는 + 연산자를 사용했을 때 호출되는 함수의 시그니처와 맞춰야 하기 때문입니다. + 연산자는 add 메서드를 사용하는데, 이 메서드의 시그니처는 아래처럼 생겼습니다:

fn add(self, s: &str) -> String {

표준 라이브러리를 보면 add가 제네릭과 연관 타입을 사용하여 정의되어 있음을 알 수 있습니다. 여기서는 제네릭에 구체 타입(concrete type)을 대입하였고, 이는 String 값으로 이 메서드를 호출했을 때 발생합니다. 제네릭에 대한 내용은 10장에서 다룰 것입니다. 이 시그니처는 교묘한 + 연산자를 이해하는데 필요한 단서를 줍니다.

첫 번째로, s2는 &를 가지고 있는데, 즉 첫 번째 문자열에 두 번째 문자열의 참조자를 더하고 있음을 뜻합니다. 이는 add 함수의 s 매개변수 때문입니다: String에는 &str만 더할 수 있고, 두 String끼리는 더하지 못합니다. 아니, 잠깐만요 - &s2의 타입은 &String이지, add의 두 번째 매개변수에 명시한 것처럼 &str은 아니죠. 어째서 예제 8-18의 예제가 컴파일되는 걸까요?

&s2를 add 호출에 사용할 수 있는 이유는 &String 인수가 &str로 강제될 수 있기 때문입니다 -add 함수가 호출되면, 러스트는 역참조 강제(deref coercion) 라 불리는 무언가를 사용하는데, 이는 add 함수 내에서 사용되는 &s2가 &s2[..]로 바뀌는 것으로 생각할 수 있도록 해줍니다. 역참조 강제에 대한 것은 15장에서 다룰 것입니다. add가 매개변수의 소유권을 가져가지는 않으므로, s2는 이 연산 이후에도 여전히 유효한 String일 것입니다.

두 번째로, 시그니처에서 add가 self의 소유권을 가져가는 것을 볼 수 있는데, 이는 self가 &를 안 가지고 있기 때문입니다. 즉 예제 8-18의 예제에서 s1이 add 호출로 이동되어 이후에는 더 이상 유효하지 않을 것이라는 의미입니다. 따라서 let s3 = s1 + &s2;가 마치 두 문자열을 복사하여 새로운 문자열을 만들 것처럼 보일지라도, 실제로 이 구문은 s1의 소유권을 가져다가 s2의 내용물의 복사본을 추가한 다음, 결과물의 소유권을 반환합니다. 달리 말하면, 이 구문은 여러 복사본을 만드는 것처럼 보여도 그렇지 않습니다: 이러한 구현은 복사보다 더 효율적입니다.

만일 여러 문자열을 접하고자 한다면, +의 동작은 다루기 불편해 집니다:

fn main() {
    let s1 = String::from("tic");
    let s2 = String::from("tac");
    let s3 = String::from("toe");

    let s = s1 + "-" + &s2 + "-" + &s3;
}

이 지점에서 s는 tic-tac-toe가 될 것입니다. 모든 +와 " 문자들과 함께 보면 어떤 결과가 나올지 알기 어렵습니다. 그 대신 더 복잡한 문자열 조합을 위해서는 format! 매크로를 사용할 수 있습니다:

fn main() {
    let s1 = String::from("tic");
    let s2 = String::from("tac");
    let s3 = String::from("toe");

    let s = format!("{s1}-{s2}-{s3}");
}

이 코드 또한 s에 tic-tac-toe를 설정합니다. format! 매크로는 println!처럼 작동하지만, 스크린에 결과를 출력하는 대신 결과를 담은 String을 반환해 줍니다. format!을 이용한 버전이 훨씬 읽기 쉽고, format! 매크로로 만들어진 코드는 참조자를 이용하므로 이 호출은 아무 매개변수의 소유권도 가져가지 않습니다.

문자열 내부의 인덱싱

다른 많은 프로그래밍 언어들에서, 인덱스를 이용한 참조를 통해 문자열 내부의 개별 문자들에 접근하는 것은 유효하고 범용적인 연산에 속합니다. 그러나 러스트에서 인덱싱 문법을 이용하여 String의 부분에 접근하고자 하면 에러를 얻게 됩니다. 아래 예제 8-19와 같은 코드를 생각해 봅시다:

fn main() {
    let s1 = String::from("hello");
    let h = s1[0];
}

예제 8-19: 문자열에 인덱싱 문법을 사용하는 시도

이 코드는 아래와 같은 에러를 출력합니다:

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
error[E0277]: the type `String` cannot be indexed by `{integer}`
 --> src/main.rs:3:13
  |
3 |     let h = s1[0];
  |             ^^^^^ `String` cannot be indexed by `{integer}`
  |
  = help: the trait `Index<{integer}>` is not implemented for `String`
  = help: the following other types implement trait `Index<Idx>`:
            <String as Index<RangeFrom<usize>>>
            <String as Index<RangeFull>>
            <String as Index<RangeInclusive<usize>>>
            <String as Index<RangeTo<usize>>>
            <String as Index<RangeToInclusive<usize>>>
            <String as Index<std::ops::Range<usize>>>

For more information about this error, try `rustc --explain E0277`.
error: could not compile `collections` due to previous error

에러와 노트 부분이 이야기해 줍니다: 러스트 문자열은 인덱싱을 지원하지 않는다고. 그렇지만 왜 안 되는 걸까요? 이 질문에 답하기 위해서는 러스트가 어떻게 문자열을 메모리에 저장하는지에 관하여 살짝 이야기해야 합니다.

내부적 표현

String은 Vec<u8>을 감싼 것입니다(wrapper). 예제 8-14에서 보았던 몇 가지 적절히 인코딩된 UTF-8 예제 문자열을 살펴봅시다. 첫 번째로, 이것입니다:

fn main() {
    let hello = String::from("السلام عليكم");
    let hello = String::from("Dobrý den");
    let hello = String::from("Hello");
    let hello = String::from("שָׁלוֹם");
    let hello = String::from("नमस्ते");
    let hello = String::from("こんにちは");
    let hello = String::from("안녕하세요");
    let hello = String::from("你好");
    let hello = String::from("Olá");
    let hello = String::from("Здравствуйте");
    let hello = String::from("Hola");
}

이 경우, len은 4가 되는데, 이는 문자열 "Hola"를 저장하고 있는 Vec이 4바이트 길이라는 뜻입니다. UTF-8으로 인코딩되면 각각의 글자들이 1바이트씩 차지한다는 것이죠. 그러나 다음 줄은 아마도 여러분을 놀라게 할 수도 있습니다. (맨 앞의 문자는 아라비아 숫자 3이 아닌, 키릴 문자 Ze입니다)

fn main() {
    let hello = String::from("السلام عليكم");
    let hello = String::from("Dobrý den");
    let hello = String::from("Hello");
    let hello = String::from("שָׁלוֹם");
    let hello = String::from("नमस्ते");
    let hello = String::from("こんにちは");
    let hello = String::from("안녕하세요");
    let hello = String::from("你好");
    let hello = String::from("Olá");
    let hello = String::from("Здравствуйте");
    let hello = String::from("Hola");
}

이 문자열의 길이가 얼마인지 묻는다면, 여러분은 12라고 답할지도 모릅니다. 실제 러스트의 대답은 24입니다. 이는 "Здравствуйте"를 UTF-8으로 인코딩된 바이트들의 크기인데, 각각의 유니코드 스칼라값이 저장소의 2바이트를 차지하기 때문입니다. 따라서, 문자열의 바이트들 안의 인덱스는 유효한 유니코드 스칼라 값과 항상 대응되지는 않을 것입니다. 이를 보여주기 위해, 다음과 같은 유효하지 않은 러스트 코드를 고려해 보세요:

let hello = "Здравствуйте";
let answer = &hello[0];

여러분은 이미 answer가 첫 번째 글자인 З이 아닐 것이란 점을 알고 있습니다. UTF-8으로 인코딩될 때, З의 첫 번째 바이트는 208이고, 두 번째는 151이므로, answer는 사실 208이 되어야 하지만, 208은 그 자체로는 유효한 문자가 아닙니다. 208을 반환하는 것은 사람들이 이 문자열의 첫 번째 글자를 요청했을 경우 사람들이 기대하는 것이 아닙니다. 하지만 그게 러스트가 인덱스 0에 가지고 있는 유일한 데이터죠. 바이트 값을 반환하는 것은 아마도 사용자들이 원하는 것이 아닐 것입니다. 심지어는 라틴 글자들만 있을 때도요. &"hello"[0]는 h가 아니라 104를 반환합니다.

따라서, 기대치 않은 값을 반환하고 즉시 발견하기 힘들지도 모를 버그를 야기하는 것을 방지하기 위해, 러스트는 이러한 코드를 전혀 컴파일하지 않고 이러한 오해들을 개발 과정 내에서 일찌감치 방지한다는 것이 정답입니다.

바이트와 스칼라값과 문자소 클러스터! 이런!

UTF-8에 대한 또 다른 지점은, 실제로는 러스트의 관점에서 문자열을 보는 세 가지의 의미 있는 방식이 있다는 것입니다: 바이트, 스칼라값, 그리고 문자소 클러스터 (grapheme cluster, 우리가 글자라고 부르는 것과 가장 근접한 것)입니다.

데바가나리 글자로 쓰인 힌디어 “नमस्ते”를 보면, 이것은 궁극적으로 아래와 같이 u8 값들의 Vec으로서 저장됩니다:

[224, 164, 168, 224, 164, 174, 224, 164, 184, 224, 165, 141, 224, 164, 164,
224, 165, 135]

이건 18바이트이고 컴퓨터가 이 데이터를 궁극적으로 저장하는 방법입니다. 만일 우리가 이를 유니코드 스칼라값, 즉 러스트의 char 타입인 형태로 본다면, 아래와 같이 보이게 됩니다:

['न', 'म', 'स', '्', 'त', 'े']

여섯 개의 char 값이 있지만, 네 번째와 여섯 번째는 글자가 아닙니다: 그 자체로는 이해할 수 없는 발음 구별 부호입니다. 마지막으로, 만일 이를 문자소 클러스터로서 본다면, 사람들이 발음할 이 힌디 단어를 구성하는 네 글자를 얻습니다:

["न", "म", "स्", "ते"]

러스트는 컴퓨터가 저장하는 가공되지 않은(raw) 문자열을 번역하는 다른 방법을 제공하여, 데이터가 담고 있는 것이 어떤 인간의 언어든 상관없이 각각의 프로그램이 필요로 하는 통역방식을 선택할 수 있도록 합니다.

러스트가 String을 인덱스로 접근하여 문자를 얻지 못하도록 하는 마지막 이유는 인덱스 연산이 언제나 상수 시간(O(1))에 실행될 것으로 기대받기 때문입니다. 그러나 String을 가지고 그러한 성능을 보장하는 것은 불가능한데, 그 이유는 러스트가 문자열 내에 얼마나 많은 유효 문자가 있는지 알아내기 위해 내용물의 시작 지점부터 인덱스로 지정된 곳까지 훑어야 하기 때문입니다.

문자열 슬라이싱하기

문자열 인덱싱의 반환 타입이 어떤 것이 (바이트 값인지, 캐릭터인지, 문자소 클러스터인지, 혹은 문자열 슬라이스인지) 되어야 하는지 명확하지 않기 때문에 문자열의 인덱싱은 종종 나쁜 아이디어가 됩니다. 따라서, 여러분이 문자열 슬라이스를 만들기 위해 정말로 인덱스를 사용하고자 한다면 러스트는 좀 더 구체적으로 지정하도록 요청합니다. 여러분의 인덱싱을 더 구체적으로 하고 문자열 슬라이스를 원한다는 것을 가리키기 위해서, []에 숫자 하나를 사용하는 인덱싱보다, []와 범위를 사용하여 특정 바이트들이 담고 있는 문자열 슬라이스를 만들 수 있습니다:

#![allow(unused)]
fn main() {
let hello = "Здравствуйте";

let s = &hello[0..4];
}

여기서 s는 문자열의 첫 4바이트를 담고 있는 &str가 될 것입니다. 앞서 우리는 이 글자들이 각각 2바이트를 차지한다고 언급했으므로, 이는 s가 “Зд”이 될 것이란 뜻입니다.

만약에 &hello[0..1]처럼 문자 바이트의 일부를 슬라이스를 얻으려고 한다면, 러스트는 벡터 내에 유효하지 않은 인덱스에 접근했을 때와 동일한 방식으로 런타임에 패닉을 발생시킬 것입니다.

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
    Finished dev [unoptimized + debuginfo] target(s) in 0.43s
     Running `target/debug/collections`
thread 'main' panicked at 'byte index 1 is not a char boundary; it is inside 'З' (bytes 0..2) of `Здравствуйте`', src/main.rs:4:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

여러분은 문자열 슬라이스를 만들기 위하여 범위를 이용하는 방법을 조심스럽게 사용해야 하는데, 이는 여러분의 프로그램을 죽게 만들 수도 있기 때문입니다.

문자열을 순회할 때 쓰는 메서드, 반복자(iterator)

문자열의 조각들에 대한 연산을 하는 가장 좋은 방법은 문자를 원하는 것인지 혹은 바이트를 원하는 것인지에 대해 명시적으로 하는 것입니다. 개별적인 유니코드 스칼라값에 대해서는 chars 메서드를 사용하세요. “Зд”에 대해 chars 함수를 호출하면 각각을 분리하여 char 타입의 두 개의 값을 반환하고, 각 요소에 접근하기 위해서 이 결과에 대해 반복할 수 있습니다:

#![allow(unused)]
fn main() {
for c in "Зд".chars() {
    println!("{c}");
}
}

이 코드는 다음을 출력할 것입니다:

З
д

다른 방법으로 bytes 메서드는 가공되지 않은 각각의 바이트를 반환하는데, 여러분의 문제 범위에 따라 적절할 수도 있습니다:

#![allow(unused)]
fn main() {
for b in "Зд".bytes() {
    println!("{b}");
}
}

위의 코드는 이 문자열을 구성하는 네 개의 바이트를 출력합니다:

208
151
208
180

하지만 유효한 유니코드 스칼라값이 하나 이상의 바이트로 구성될지도 모른다는 것을 확실히 기억해 주세요.

데바나가리(Devanagari) 문서와 같은 문자열로부터 문자소 클러스터를 얻는 방법은 복잡해서, 이 기능은 표준 라이브러리를 통해 제공되지 않습니다. 여러분이 원하는 기능이 이것이라면 crates.io에 사용 가능한 크레이트가 있습니다.

문자열은 단순하지 않습니다

종합하면, 문자열은 복잡합니다. 다른 프로그래밍 언어들은 이러한 복잡성을 프로그래머에게 어떻게 보여줄지에 대해 각기 다른 선택을 합니다. 러스트는 String 데이터의 올바른 처리가 모든 러스트 프로그램에 대한 기본적인 동작이 되도록 선택했는데, 이는 솔직히 프로그래머들이 UTF-8 데이터를 처리하는 데 있어 더 많은 생각을 해야 한다는 의미입니다. 이러한 거래는 다른 프로그래밍 언어들에 비해 더 복잡한 문자열을 노출시키지만, 한편으로는 여러분의 개발 생활 주기 후반에 비 ASCII 캐릭터를 포함하는 에러를 처리해야 하는 것을 막아줄 것입니다.

좋은 소식은 이러한 복잡한 상황을 올바르게 다루는 것을 돕기 위하여 표준 라이브러리가 String과 &str 타입에 대한 다양한 기능을 제공한다는 점입니다. 문자열 검색을 위한 contains와 문자열 일부를 다른 문자열로 바꾸는 replace 같은 유용한 메서드들에 대해 알아보려면 꼭 문서를 확인해 보세요.

이것보다 살짝 덜 복잡한 것으로 옮겨 갑시다: 해쉬맵이요!