# Django 6.0.7 문서

# 커스텀 스토리지 클래스를 작성하는 방법

만일 사용자 정의 파일 스토리지를 제공하고자 하는 경우 – 흔한 예로 원격 시스템에 파일을 저장할 때 – 사용자 정의 스토리지 클래스를 정의하면 됩니다. 다음 단계들을 진행해주세요.

1. 당신의 커스텀 저장소 시스템은 `django.core.files.storage.Storage`의 하위 클래스여야만 합니다.

       from django.core.files.storage import Storage

       class MyStorage(Storage): ...

2. Django는 어떤 인자없이도 너의 저장 시스템을 인스턴스화 할 수 있습니다. 이는 “django.conf.settings”로 부터 설정을 받아 사용한다는 것을 의미합니다.

       from django.conf import settings
       from django.core.files.storage import Storage

       class MyStorage(Storage):
           def __init__(self, option=None):
               if not option:
                   option = settings.CUSTOM_STORAGE_OPTIONS
               ...

3. 저장 클래스는 `_open`과 :meth:`_save()` 메서드를 비롯해, 해당 저장 클래스에 적합한 다른 메서드도 구현해야 합니다. 이러한 메서드에 대한 자세한 내용은 아래에서 확인할 수 있습니다.

   추가적으로, 만약 당신의 클래스가 로컬 파일 저장을 하면 “path()” 메소드로 오버라이드 되어야만 합니다.

4. Your storage class must be deconstructible so it can be serialized when it’s used on a field in a migration. As long as your field has arguments that are themselves serializable, you can use the `django.utils.deconstruct.deconstructible` class decorator for this (that’s what Django uses on FileSystemStorage).

디폴트로, 다음의 메소드는 ``NotImplementedError``를 일으키고, 일반적으로 오버라이드 되어야 합니다.

- `Storage.delete()`

- `Storage.exists()`

- `Storage.listdir()`

- `Storage.size()`

- `Storage.url()`

하지만 앞의 모든 메소드들이 필수적인 것은 아니며, 자율적으로 생략될 수 있다는 것을 유의하십시오. 그럴 경우에 각 메소드를 미구현 상태로 내버려 두면서도 작동하는 저장소를 만들 수 있습니다.

한 예시로, 만약 특정 콘텐츠를 지니고 있는 리스트를 백엔드에 저장하는게 고비용이 될 경우 당신은 ``Storage.listdir()``을 구현하지 않아도 된다.

다른 예시로 파일을 쓰기만 하는 백엔드가 있는 경우 당신은 위의 메소드를 구현할 필요가 없을 수 있다.

궁극적으로, 어떠한 메소드가 구현될 것인가는 당신이 정할 수 있습니다. 몇 몇의 메소드를 미구현 상태로 내버려둔다면 완전하지 않은(혹은 망가진) 인터페이스를 낳을 것입니다.

당신은 또한 커스텀 저장 객체를 위해 특별히 제작된 훅을 사용하고 싶을 것입니다. 이것들은:

_open(name, mode='rb')

필수.

`Storage.open()``에 의해 호출되며, 스토리지 클래스가 파일을 열때 사용하는 실제 매커니즘입니다. 이 함수는 반드시 ``File` 객체를 반환해야하지만, 대부분의 경우, 백엔드 스토리지 시스템에 특화된 로직을 구현한 서브클래스를 반환하는 것이 좋습니다. 파일이 존재하지 않을 경우 `FileNotFoundError` 예외를 발생시켜야 합니다.

_save(name, content)

`Storage.save()``으로 호출되다. "name" 은 ``get_valid_name()` 과 `get_available_name()` 을 이미 통과했을 것이고, `content` 는 `파일` 객체 자신이 될 것이다.

스토리지에 저장된 파일의 실제 이름을 반환해야 합니다. (일반적으로 파일의 ``name``을 반환하지만, 스토리지가 파일명을 변경할 필요가 있는 경우 변경된 새 이름을 반환해야 합니다.)

get_valid_name(name)

기본 저장 시스템에 사용할 수 있는 파일 이름을 반환합니다. 이 메서드에 전달된 “name” 호출 인자는 서버에 전송된 원래의 파일 이름이거나 “Upload_to”가 호출 가능한 경우 경로 정보가 제거된 후 해당 메서드에 의해 반환된 파일 이름입니다. 표준 문자가 아닌 문자가 안전한 파일 이름으로 변환되는 방법을 커스터마이즈하려면 이 옵션을 재정의하십시오.

“Storage”에 제공된 코드는 원래 파일 이름에서 영숫자, 마침표 및 밑줄만 유지하며 다른 모든 것을 제거한다.

get_alternative_name(file_root, file_ext)

“file_root” 및 “file_ext” 매개 변수를 기준으로 대체 파일 이름을 반환합니다. 기본적으로 확장명 앞에 밑줄과 임의의 7자 영숫자 문자열이 파일 이름에 추가됩니다.

get_available_name(name, max_length=None)

저장 메커니즘에서 사용할 수 있는 파일 이름을 반환합니다. 제공된 파일 이름을 고려할 수 있습니다. 위에서 설명한 “get_valid_name()” 방법에 따르면 이 방법에 전달된 “name” 인수는 이미 스토리지 시스템에 유효한 파일 이름으로 정리될 것입니다.

파일 이름의 길이는 제공되는 경우 “max_length”를 초과하지 않는다. 사용 가능한 고유 파일 이름을 찾을 수 없는 경우 a:exc:의심스러운 파일 작업 <django.core.exceptions.SuspiciousOperation >의 예외가 발생했습니다.

If a file with `name` already exists, `get_alternative_name()` is called to obtain an alternative name.

## 맞춤 스토리지 엔진 사용하기

여러분만의 스토리지를 장고와 함께 사용하기 위한 첫번째 단계는 장고에게 여러분이 사용할 파일 스토리지 백엔드를 알려주는 것입니다. `STORAGES`를 통해 알려줄 수 있습니다. 이 설정은 여러분이 사용할 스토리지의 설정값을 딕셔너리 형태로 장고의 스토리지 별칭에 매핑해주며, 이 스토리지 별칭은 장고 내에서 스토리지를 참조하기 위한 방법으로 사용됩니다. 딕셔너리의 상세한 설정값은 :setting:`STORAGES` 문서에 모두 안내되어 있습니다.

스토리지들은 `django.core.files.storage.storages` 딕셔너리에서 별칭으로 접근할 수 있습니다.

    from django.core.files.storage import storages

    example_storage = storages["example"]