- DrugImg.DIK_CODE 44자 Base64 image key 가능성 문서화 - 평문 DIK_CODE 직접 join 단정 제거 - health.kr zoom 후보 URL과 실제 이미지 GET 검증 스크립트 추가
2.9 KiB
DrugImg.DIK_CODE 44자 이미지키 / 외부 이미지 URL 검증 메모
결론
PM_IMAGE..DrugImg.DIK_CODE는 인스턴스/버전에 따라 PM_DRUG..CD_GOODS.DIK_CODE의 평문 숫자값과 다를 수 있습니다.
VM303 PIT3000 샘플에서 확인된 PM_IMAGE..DRUGIMG.DIK_CODE 예시는 다음과 같습니다.
xiY4jUZTAZB0p8JpHEa+Zt9DEcOVQFq9sgtAxSG7GXY=
이 값은 길이 44자의 Base64 문자열이고, strict base64 decode 시 32 bytes입니다.
len(base64_text) = 44
len(base64_decode(text)) = 32
즉 형태상 SHA-256 digest를 Base64로 인코딩한 값과 같은 길이입니다. 다만 확인한 평문 CD_GOODS.DIK_CODE를 단순히 UTF-8/CP949/UTF-16LE로 SHA-256한 결과와는 일치하지 않았습니다. 따라서 현재 단계의 정확한 표현은 다음입니다.
DrugImg.DIK_CODE = 평문 DIK_CODE가 아닐 수 있는 44자 Base64 image key
암호화된 이미지라는 뜻은 아닙니다. 이미지 BLOB 자체는 FF D8 FF ... JPEG bytes로 확인되었습니다. 문제는 이미지 BLOB 매칭키입니다.
잘못된 단정
다음 join은 일부 구버전/일부 DB에서만 가능할 수 있고, VM303/다른 인스턴스에서는 실패할 수 있습니다.
PM_DRUG..CD_GOODS.DIK_CODE = PM_IMAGE..DrugImg.DIK_CODE
따라서 이 저장소에서는 위 join을 기본 경로가 아니라 legacy/plain-key 가능성으로만 취급합니다.
외부 URL 검증
다음 직접 이미지 URL은 일반적으로 성공한다고 보면 안 됩니다.
http://pharm.or.kr/images/sb_photo/big3/{DIK_CODE}.jpg
https://www.pharm.or.kr/images/sb_photo/big3/{DIK_CODE}.jpg
https://www.health.kr/images/sb_photo/big3/{DIK_CODE}.jpg
테스트한 여러 일반의약품 DIK_CODE에서 직접 URL은 404였습니다.
반면 다음 zoom.asp는 HTML을 반환하고 내부 JS/img 후보 경로를 포함할 수 있습니다.
https://www.health.kr/drug_info/sb/zoom.asp?drug_code={DIK_CODE}
하지만 중요한 점은, zoom.asp 안에 big3/{DIK}.jpg 또는 marked3/{DIK}00_x.jpg 문자열이 보이더라도 그 이미지 GET이 실제 200이라는 뜻은 아닙니다. 실제 GET/HEAD를 별도로 확인해야 합니다.
현재 권장 매칭 우선순위
DRUGIMG_USER처럼DRUG_CODE컬럼이 있는 테이블을 먼저 확인합니다.PM_IMAGE..DRUGIMG*.DIK_CODE가 44자 Base64 image key인지, 13자리 평문 DIK_CODE인지 샘플 분포를 확인합니다.- PIT 코드에서 image key 생성 함수 또는 legacy MDB 매핑을 역추적합니다.
- 외부 health.kr/약학정보원 페이지는 보조 경로로 쓰되, 이미지 URL은 반드시 HTTP 200과 content-type/image magic을 검증합니다.
- 복약지도 pictogram은 별도 경로입니다:
CD_MC.DIK_CODE → CD_PICTOGRAM_SUB.PIC_CODE → CD_PICTOGRAM.PIC_IMG.
샘플 검증 코드
scripts/probe_drugimg_keys.py 참고.