만일 사용자 정의 파일 스토리지를 제공하고자 하는 경우 – 흔한 예로 원격 시스템에 파일을 저장할 때 – 사용자 정의 스토리지 클래스를 정의하면 됩니다. 다음 단계들을 진행해주세요.
\n당신의 커스텀 저장소 시스템은 django.core.files.storage.Storage의 하위 클래스여야만 합니다.
from django.core.files.storage import Storage\n\n\nclass MyStorage(Storage): ...\nDjango는 어떤 인자없이도 너의 저장 시스템을 인스턴스화 할 수 있습니다. 이는 “django.conf.settings”로 부터 설정을 받아 사용한다는 것을 의미합니다.
\nfrom django.conf import settings\nfrom django.core.files.storage import Storage\n\n\nclass MyStorage(Storage):\n def __init__(self, option=None):\n if not option:\n option = settings.CUSTOM_STORAGE_OPTIONS\n ...\n저장 클래스는 _open`과 :meth:`_save() 메서드를 비롯해, 해당 저장 클래스에 적합한 다른 메서드도 구현해야 합니다. 이러한 메서드에 대한 자세한 내용은 아래에서 확인할 수 있습니다.
추가적으로, 만약 당신의 클래스가 로컬 파일 저장을 하면 “path()” 메소드로 오버라이드 되어야만 합니다.
\n저장 클래스는 deconstructible <custom-deconstruct-method>`이어야 합니다. 이는 마이그레이션의 필드에서 사용될 때 직렬화될 수 있어야 하기 때문입니다. 필드에 :ref:`serializable <migration-serializing>`한 인수가 있다면, ``django.utils.deconstruct.deconstructible` 클래스 데코레이터를 사용할 수 있습니다(이는 Django가 FileSystemStorage에서 사용하는 방식입니다).
디폴트로, 다음의 메소드는 ``NotImplementedError``를 일으키고, 일반적으로 오버라이드 되어야 합니다.
\n\n하지만 앞의 모든 메소드들이 필수적인 것은 아니며, 자율적으로 생략될 수 있다는 것을 유의하십시오. 그럴 경우에 각 메소드를 미구현 상태로 내버려 두면서도 작동하는 저장소를 만들 수 있습니다.
\n한 예시로, 만약 특정 콘텐츠를 지니고 있는 리스트를 백엔드에 저장하는게 고비용이 될 경우 당신은 ``Storage.listdir()``을 구현하지 않아도 된다.
\n다른 예시로 파일을 쓰기만 하는 백엔드가 있는 경우 당신은 위의 메소드를 구현할 필요가 없을 수 있다.
\n궁극적으로, 어떠한 메소드가 구현될 것인가는 당신이 정할 수 있습니다. 몇 몇의 메소드를 미구현 상태로 내버려둔다면 완전하지 않은(혹은 망가진) 인터페이스를 낳을 것입니다.
\n당신은 또한 커스텀 저장 객체를 위해 특별히 제작된 훅을 사용하고 싶을 것입니다. 이것들은:
\n필수.
\nStorage.open()``에 의해 호출되며, 스토리지 클래스가 파일을 열때 사용하는 실제 매커니즘입니다. 이 함수는 반드시 ``File 객체를 반환해야하지만, 대부분의 경우, 백엔드 스토리지 시스템에 특화된 로직을 구현한 서브클래스를 반환하는 것이 좋습니다. 파일이 존재하지 않을 경우 FileNotFoundError 예외를 발생시켜야 합니다.
Storage.save()``으로 호출되다. "name" 은 ``get_valid_name() 과 get_available_name() 을 이미 통과했을 것이고, content 는 파일 객체 자신이 될 것이다.
스토리지에 저장된 파일의 실제 이름을 반환해야 합니다. (일반적으로 파일의 ``name``을 반환하지만, 스토리지가 파일명을 변경할 필요가 있는 경우 변경된 새 이름을 반환해야 합니다.)
\n기본 저장 시스템에 사용할 수 있는 파일 이름을 반환합니다. 이 메서드에 전달된 “name” 호출 인자는 서버에 전송된 원래의 파일 이름이거나 “Upload_to”가 호출 가능한 경우 경로 정보가 제거된 후 해당 메서드에 의해 반환된 파일 이름입니다. 표준 문자가 아닌 문자가 안전한 파일 이름으로 변환되는 방법을 커스터마이즈하려면 이 옵션을 재정의하십시오.
\n“Storage”에 제공된 코드는 원래 파일 이름에서 영숫자, 마침표 및 밑줄만 유지하며 다른 모든 것을 제거한다.
\n“file_root” 및 “file_ext” 매개 변수를 기준으로 대체 파일 이름을 반환합니다. 기본적으로 확장명 앞에 밑줄과 임의의 7자 영숫자 문자열이 파일 이름에 추가됩니다.
\n저장 메커니즘에서 사용할 수 있는 파일 이름을 반환합니다. 제공된 파일 이름을 고려할 수 있습니다. 위에서 설명한 “get_valid_name()” 방법에 따르면 이 방법에 전달된 “name” 인수는 이미 스토리지 시스템에 유효한 파일 이름으로 정리될 것입니다.
\n파일 이름의 길이는 제공되는 경우 “max_length”를 초과하지 않는다. 사용 가능한 고유 파일 이름을 찾을 수 없는 경우 a:exc:의심스러운 파일 작업 <django.core.exceptions.SuspiciousOperation >의 예외가 발생했습니다.
\nIf a file with name already exists, get_alternative_name() is called to\nobtain an alternative name.
여러분만의 스토리지를 장고와 함께 사용하기 위한 첫번째 단계는 장고에게 여러분이 사용할 파일 스토리지 백엔드를 알려주는 것입니다. STORAGES`를 통해 알려줄 수 있습니다. 이 설정은 여러분이 사용할 스토리지의 설정값을 딕셔너리 형태로 장고의 스토리지 별칭에 매핑해주며, 이 스토리지 별칭은 장고 내에서 스토리지를 참조하기 위한 방법으로 사용됩니다. 딕셔너리의 상세한 설정값은 :setting:`STORAGES 문서에 모두 안내되어 있습니다.
스토리지들은 django.core.files.storage.storages 딕셔너리에서 별칭으로 접근할 수 있습니다.
from django.core.files.storage import storages\n\nexample_storage = storages["example"]\n