사진 이름을 적었는데 내부 파일 ID까지 다시 물으면 글쓰기 입구가 복잡해진다. 그렇다고 같은 이름의 첫 파일을 쓰면 다른 사진이 올라갈 수 있다. 앞서 간단한 발행 입구를 만들었다면 이번에는 그 안에서 사람이 읽는 이름이 실제 선택한 파일로 연결되는 두 단계를 더 깊게 살폈다.
본문의 표시는 경로가 아닌 선택 자료의 이름이다
publicationInputs는 별도 줄의 사진·영상 표시를 만나면 현재 문단을 마무리하고 선택 파일 목록에서 이름을 찾는다. 정확히 하나가 아니면 PUBLICATION_SELECTED_FILE_REQUIRED다. 이름이 겹치면 먼저 보이는 파일을 쓰지 않고 선택을 분명하게 해야 한다. 일반 경로를 입력했다고 그 파일을 새로 읽어 오는 통로도 아니다.
이 첫 입구는 매체 표시의 종류에 맞는 확장자와 SHA 형식을 확인한다. 하지만 확장자 검사를 실제 파일의 전체 내용 판정으로 설명하지는 않는다. 요청의 표시를 지원 가능한 입력으로 연결하는 형태 검사이며 실제 선택 범위와 바이트 확인은 다른 층에서 이어진다. 작은 입력 뒤의 역할을 나누어 읽었다.
계획에는 파일 이름과 hash를 함께 남긴다
변환된 ArticlePlan의 매체 블록은 fileName과 sha256을 가진다. 원고 안에서는 어느 위치에 어떤 파일을 쓰려 했는지 읽을 수 있고 실행에서는 같은 이름의 바이트가 바뀌었는지 비교할 단서가 된다. 사용자에게 handle을 외우게 하지 않으면서도 표시 이름 하나로 정체성을 끝내지 않은 것이다.
원래 rich 입력은 이미 구성한 계획을 직접 받을 수도 있다. 그 경로의 fileFor는 이름과 hash가 모두 같은 메타데이터를 정확히 하나 찾는다. 간단한 표시 입구의 이름 단독 모호성 거절과 하위의 이름·hash 연결은 조건이 다르다. 모든 경로가 같은 규칙이라고 뭉쳐 쓰지 않았다.
뒤쪽 누락을 앞 문단을 쓰기 전에 찾는다
naver-article의 fill은 files.describe로 선택 ID의 메타데이터를 읽고 모든 매체 블록에 fileFor를 적용한 뒤 첫 본문 블록으로 간다. 마지막 영상이 누락됐는데 앞 문단과 사진을 먼저 써 놓는 부분 진행을 줄이려는 순서다. 원고 뒤까지 파일 연결을 검사해야 준비를 마쳤다고 말할 수 있다.
이것이 화면의 어떤 값도 바뀌기 전이라는 보장은 아니다. 상위 절차가 글 제목을 확인하거나 입력한 뒤 매체 본문 준비로 들어올 수 있다. 내가 설명하는 정확한 경계는 첫 본문 블록 전의 전체 매체 연결 검사다. 제목·본문·외부 전송을 한꺼번에 변경0이라고 표현하지 않는다.
메타데이터도 현재 허용한 파일에서 다시 읽는다
TaskFiles.describe는 요청 ID가 allowed 목록에 있는지와 프로필 소속을 확인한다. 파일을 읽기 전후에 일반 파일인지, 크기와 수정 시각이 선택 당시와 같은지 비교하며 실제 바이트로 SHA-256을 계산한다. 경로와 인증 자료를 원고 입력에 넣는 대신 필요한 이름·크기·hash를 돌려준다.
이 검사를 모든 악의적 파일시스템 경쟁을 막는 보장으로 확대하지 않는다. 실제 업로드 직전의 추가 검사는 handle과 파일 상태를 다시 보지만 모든 바이트를 같은 방식으로 다시 hash하는 것은 아니다. 시간 차이와 저장 환경의 신뢰는 남는다. 어떤 자료를 언제 읽었는지까지 알려야 이 확인의 강도를 판단할 수 있다.
시험은 이름이 맞아도 거절해야 할 때를 본다
기존 publication 시험은 없는 이름과 중복 이름, 경로 표시, 잘못된 매체 종류를 거절하는지 확인한다. 파일 시험은 다른 프로필의 handle과 선택 뒤 바뀐 파일을 거절한다. 나는 이 코드를 현재 함수와 대조했으며 원래 운영 파일을 바꾸거나 외부 선택을 새로 실행하지 않았다.
공유 모듈에서는 같은 이름·다른 바이트를 구별하고 같은 이름·같은 hash 후보 둘은 거절한다. 뒤쪽 누락이 있어도 호출자 원고가 바뀌지 않는지 실제 시험했다. 이 모듈은 전달한 합성 메타데이터만 다루며 운영 파일 hash를 직접 읽는 TaskFiles의 복제판이 아니라는 범위도 함께 적었다.
사용자에게 쉬운 이름과 내부의 정확한 연결을 함께 둔다
사용자는 사진을 어떤 문단에 쓸지 결정하면 된다. 프로그램은 그 이름이 어느 선택 파일인지, 바이트가 어떤지, 현재 사용할 수 있는지 책임지고 연결한다. 쉬운 입력을 만들려면 내부 식별을 없애기보다 정확한 식별이 필요한 자리에 남겨 두는 편이 낫다.
나는 파일 ID를 숨겼다는 이유로 파일의 출처와 선택도 숨기고 싶지는 않았다. 이름이 겹치거나 바이트가 바뀌면 명확히 멈추고 필요한 선택을 다시 확인할 수 있어야 한다. 글쓰기 자동화에서 중요한 편의는 적은 질문의 숫자만이 아니라 어떤 자료를 실제로 쓰는지 알 수 있는 연결이었다.