글

10월, 2026의 게시물 표시

URLSearchParams append·set: UTM을 더할 때 같은 키가 겹치는 이유

이미지
URLSearchParams.append()는 같은 키가 있어도 새 값 쌍을 추가합니다. set()은 해당 키의 값을 지정하면서 같은 키의 다른 값은 지웁니다. UTM을 붙인 주소에서 같은 이름이 두 번 보인다면 두 메서드의 역할부터 확인하세요. 목차 1. append는 새 쌍을 덧붙입니다 2. set은 같은 키의 값을 하나로 정합니다 3. 바꾼 주소와 원본을 따로 비교합니다 1. append는 새 쌍을 덧붙입니다 링크 목록에서 반복 키를 발견했다고 곧바로 오류라고 지우지는 마세요. 검색 필터처럼 여러 값을 의도한 주소도 있을 수 있습니다. 먼저 이 주소에서 키 하나가 한 값만 가져야 하는지, 여러 선택을 표현하는지 구분하는 편이 좋습니다. 아래는 외부로 요청하지 않는 문자열 예시입니다. 실제 서비스나 추적 링크에 접속해서 결과를 얻었다는 뜻은 아닙니다. const p = new URLSearchParams('tag=book&tag=life'); p.append('tag', 'travel'); console.log(p.toString()); // tag=book&tag=life&tag=travel 2. set은 같은 키의 값을 하나로 정합니다 원본 조작 결과 tag=book&tag=life append('tag','travel') tag가 세 번 tag=book&tag=life set('tag','travel') tag=travel 키가 없는 상태 set('tag','travel') 새 tag 쌍 생성 기존 UTM을 새로운 값 하나로 교체하려는 목적과, 검색 필터를 하나 더 넣으려는 목적은 다릅니다. 메서드 이름을 외우기 전에 결과 주소에서 몇 개의 같은 키가 남아야 하는지를 먼저 적어보세요. MDN append의 같은 키 추가 예시 보기 MDN set의 값 교체·다른 값 제거 설명 보기 3. 바꾼...

URLSearchParams.sort()로 쿼리 정렬: 같은 키의 값 순서는 바뀌지 않습니다

이미지
URLSearchParams.sort() 는 쿼리의 키를 기준으로 현재 객체를 정렬합니다. 같은 키가 여러 번 나오면 그 값들의 상대적인 순서는 유지하며, 정렬된 문자열을 반환하지는 않습니다. 추출한 링크 목록을 비교하려고 정렬할 때는 ‘키 정렬’과 ‘값 정렬’, ‘중복 제거’를 같은 작업으로 생각하지 마세요. 원본과 작업용 객체를 구분하면 무엇이 바뀌었는지 설명하기 쉽습니다. 목차 1. 키 정렬과 안정 정렬의 의미 2. 원문을 보존하는 짧은 예제 3. 반환값과 결과를 나눠 기록 4. 자주 묻는 질문 1. 키 정렬과 안정 정렬의 의미 MDN은 sort()가 객체를 제자리에서 변경하며 키의 UTF-16 코드 단위 값을 기준으로 정렬한다고 설명합니다. 같은 키끼리는 기존 상대 순서를 보존하는 안정 정렬입니다. 따라서 이름이 같은 키의 값을 작은 숫자부터 다시 배열하는 기능으로 읽으면 안 됩니다. 아래 자체 예제에서는 a 값 2와 5가 그 순서대로 남습니다. 반복된 키가 하나로 합쳐지는 작업도 아닙니다. 2. 원문을 보존하는 짧은 예제 const original = "b=7&a=2&a=5"; const working = new URLSearchParams(original); const returned = working.sort(); console.log(original); // b=7&a=2&a=5 console.log(working.toString()); // a=2&a=5&b=7 console.log(returned); // undefined 원문 문자열은 별도의 변수에 남겨두고 작업용 객체를 정렬하는 예시입니다. 실제 주소를 수집했다면 원래 주소를 보관하는 열과 정렬 결과를 보는 열을 나눠두세요. 정렬한 결과를 원본 자료인 것처럼 덮어 적지 않는 방식입니다. 실제 업무에 적용하기 전에는 공개해도 되는 연습용 쿼리로 동작을 확인하세요. 고객정보나 인증 토큰이 들어 있는 실제 링크를 공유 예제로 옮길 ...

블로그 링크의 sponsored·ugc: 주소와 링크 관계를 다른 열에 기록하세요

이미지
블로그 링크를 정리할 때 href는 목적지 주소, rel은 링크와 맺는 관계를 읽는 항목입니다. sponsored나 ugc가 붙었다고 주소가 달라지거나 클릭할 수 없게 되는 것은 아니므로 목록에서도 두 값을 다른 열에 보관하세요. 목차 1. 관계 표시는 링크를 막는 버튼이 아닙니다 2. rel 값은 하나만 있을 수도, 여러 개일 수도 있습니다 3. nofollow와 색인 차단을 같은 칸에 쓰지 마세요 4. 자주 묻는 질문 1. 관계 표시는 링크를 막는 버튼이 아닙니다 Google 검색 문서는 광고·유료 배치 링크에 sponsored, 댓글과 포럼 등 사용자 작성 콘텐츠의 링크에 ugc를 사용하는 방식을 설명합니다. 일반 링크에는 이런 관계를 표시하는 rel이 반드시 필요한 것은 아니며, 다른 값이 맞지 않는 경우의 nofollow도 구분합니다. 따라서 링크 목록에서 주소가 같다고 모든 링크를 한 줄로 합치면 서로 다른 관계 정보를 잃을 수 있습니다. 같은 목적지라도 본문에서 직접 작성한 안내, 댓글의 링크, 유료 배치가 각각 있는지 원래 위치를 함께 남겨두세요. 2. rel 값은 하나만 있을 수도, 여러 개일 수도 있습니다 공식 문서는 여러 rel 값을 공백 또는 쉼표로 나눠 쓸 수 있다고 안내합니다. 예를 들어 사용자 작성 콘텐츠이면서 유료 관계가 있다면 두 관계가 함께 표시될 수 있습니다. 추출 도구에서 rel 문자열을 한 개의 값으로만 가정하지 않는 이유입니다. 목록의 열 보관할 정보 문구 독자에게 보이는 링크 설명 href 쿼리와 앵커를 포함한 목적지 rel 현재 저장된 관계 값 전체 위치·맥락 본문·댓글·유료 배치 등 확인한 사실 값이 없다고 곧바로 잘못된 링크로 분류하지 말고 맥락을 보세요. 반대로 sponsored가 보이지 않는다고 실제 유료 관계가 없다고 확정할 수도 없습니다. 원고의 운영 사실과 공개된 링크 속성을 대조하는 작업이 필요합니다. Google 링크 관계 속성 공식 안내 보기 3. nofollow와 색인 차단을 같은 칸에 쓰지 마세요...

블로그 링크의 noreferrer: 목적지 URL과 Referer 정보는 서로 다릅니다

이미지
noreferrer는 링크의 목적지 주소를 지우는 속성이 아닙니다. MDN은 이 키워드가 이동할 때 Referer 헤더와 참조 정보를 생략하도록 지시한다고 설명합니다. href에 적힌 쿼리와 출처 헤더를 같은 것으로 취급하지 마세요. 목차 1. 링크 코드의 두 부분부터 나누기 2. URL과 Referer 비교 3. 공개 글에서 남길 점검 메모 4. 새 탭 동작과도 따로 보기 5. 자주 묻는 질문 1. 링크 코드의 두 부분부터 나누기 <a href="https://example.com/guide?utm_source=sample" target="_blank" rel="noreferrer">안내 읽기</a> 위 코드는 설명용 예제이며 실제 배포 주소가 아닙니다. href에는 목적지가, rel에는 링크 관계를 나타내는 키워드가 적혀 있습니다. noreferrer를 넣는 동작 자체가 href의 utm_source 값을 삭제하는 것은 아닙니다. 공개 글을 검수할 때는 편집기에서 적은 주소와 최종 도착 주소를 먼저 대조하세요. 다른 링크 처리나 서버의 이동 규칙이 있으면 결과는 달라질 수 있으므로, 원래 코드만으로 최종 주소까지 확인했다고 기록하지 않습니다. 2. URL과 Referer 비교 항목 무엇을 확인하나요 같게 보지 않을 것 href의 쿼리 링크 주소에 직접 붙인 값 브라우저가 보내는 출처 헤더 Referer 정보 어디에서 이동했는지 전달되는 요청 정보 목적지 주소 그 자체 noreferrer 참조 정보 생략 지시 URL의 모든 추적 값 제거 분석 도구 집계 해당 도구의 실제 수집·분류 결과 링크 클릭 또는 주소 확인만으로 집계 완료 단정 MDN은 noreferrer가 noopener도 지정된 것처럼 동작한다고 설명합니다. 하지만 이 설명을 모든 익명성이나 모든 추적 차단의 보장으로 확대하지 않습니다. 무엇이 주소이고 무엇이 별도 요청 정보인지 구분하는 것이 먼저입니다. 3. 공개 글...

Python3.12 urlsplit 앞 공백이 사라질 때: 원본 문자열과 분해 결과를 따로 보관

이미지
Python3.12의 urlsplit 결과는 원본 문자열을 한 글자도 바꾸지 않고 보관하는 사본이 아닙니다. 공식 문서는 앞쪽 C0 제어 문자·공백을 제거하고, 줄바꿈·캐리지리턴·탭은 URL의 어느 위치에서든 제거한다고 설명합니다. 링크 수집 검수에서는 원본과 분해 결과를 다른 칸에 남겨야 합니다. 목차 1. 원본과 geturl 결과를 같은 값으로 덮어쓰지 않기 2. 눈에 보이는 문자열만 복사하면 놓칠 수 있습니다 3. 링크 목록에 변화 이유를 남기기 4. 자주 묻는 질문 1. 원본과 geturl 결과를 같은 값으로 덮어쓰지 않기 공식 문서는 앞쪽 제어 문자·공백 제거를3.12 변경으로, ASCII 줄바꿈·탭 제거를3.10 변경으로 구분합니다. 지금 사용하는 버전의 동작을 확인하고, 화면에 보이지 않는 문자가 있었는지 원본 표현을 함께 살펴보세요. urlsplit은 URL의 안전성·유효성을 전부 검증하는 함수도 아닙니다. from urllib.parse import urlsplit raw = ' https://example.com/a\nb' parts = urlsplit(raw) print(repr(raw)) print(parts.geturl()) # 재조합 결과: https://example.com/ab 실행 환경 Python3.12에서 확인한 독립 예시입니다. example.com은 예시용 주소이며 이 코드는 네트워크 요청을 보내지 않습니다. Python3.12 공식 urlsplit 변경 사항 확인 2. 눈에 보이는 문자열만 복사하면 놓칠 수 있습니다 보관할 값 용도 구분할 것 원본 raw 실제 받은 문자열 보존 분해한 결과로 덮어쓰지 않기 repr(raw) 줄바꿈·탭 등 관찰 보기용 표현과 원래 문자열 parts.geturl() 분해 결과에서 재조합한 URL 원본과 완전 동일하다는 추정 검수 메모에 repr 문자열을 남기는 것은 보기 위한 방법입니다. repr 결과를 그대로 새 링크 주소로 붙여 넣는 작업과는 다릅니다. 주소를 실제로 사...

Python 3.12 unquote 뒤 �가 보일 때: replace·strict와 원본 바이트 비교

이미지
Python 3.12의 unquote는 기본적으로 UTF-8을 사용하고, 잘못된 바이트열을 만났을 때 errors="replace"로 대체 문자를 넣습니다. 보기 좋은 한글로 바꾸려다가 �가 생겼다면, 변환 결과로 원본 주소를 덮어쓰지 않는 것이 먼저입니다. 목차 1. 짧은 입력으로 차이를 확인하기 2. 문자열 대체와 원본 바이트는 다른 결과입니다 3. 링크 목록에는 원본·표시·검토를 나누세요 4. 자주 묻는 질문 1. 짧은 입력으로 차이를 확인하기 네트워크 요청 없이 아래 문자열만으로 비교할 수 있습니다. %FF는 이 연습에서 의도적으로 넣은 UTF-8 오류 입력입니다. 실제 공개 글이나 고객 주소를 예제로 복사할 필요는 없습니다. from urllib.parse import unquote, unquote_to_bytes raw = "%FF" print(repr(unquote(raw))) # '�' print(unquote_to_bytes(raw)) # b'\xff' try: unquote(raw, errors="strict") except UnicodeDecodeError: print("review needed") Python 3.12 unquote 오류 처리 원문 보기 2. 문자열 대체와 원본 바이트는 다른 결과입니다 방법 예제의 결과 목록에 남길 점 unquote(raw) 대체 문자 �가 포함된 문자열 오류가 없었다고 판단하지 않기 errors="strict" UnicodeDecodeError 발생 별도 검토 대상으로 남기기 unquote_to_bytes(raw) 바이트 b'\xff' 어떤 문자 인코딩인지 아직 결정하지 않음 공식 문서는 unquote_to_bytes가 %xx를 바이트로 되돌리는 기능이라고 설명합니다. 바이트를 얻었다고 원래 작성자가 의도한 글자를 복원한 것은 아닙니다. 원문이 어떤 인코딩...

Python 3.12 urlparse의 allow_fragments=False: #뒤를 지우는 옵션이 아닙니다

이미지
urlparse에서 allow_fragments=False를 지정한다고 #뒤가 삭제되지는 않습니다. fragment로 인식하지 않은 내용은 경로·매개변수·쿼리의 일부로 남을 수 있습니다. 빈 fragment 칸만 보고 원문에도 #가 없었다고 판단하지 마세요. 목차 1. False는 삭제가 아니라 인식 방식입니다 2. 같은 주소를 두 옵션으로 비교하세요 3. 링크 목록에는 옵션도 남기세요 4. 자주 묻는 질문 1. False는 삭제가 아니라 인식 방식입니다 Python3.12 공식 문서는 allow_fragments가 거짓이면 fragment 식별자를 인식하지 않고 경로·매개변수·쿼리의 일부로 분해하며, 반환된 fragment는 빈 문자열이 된다고 설명합니다. “별도 칸으로 나누지 않는다”와 “문자열에서 제거한다”는 서로 다른 처리입니다. Python allow_fragments 인수의 공식 정의 보기 2. 같은 주소를 두 옵션으로 비교하세요 from urllib.parse import urlparse raw = "https://example.org/read?topic=camp#fees" for allow in (True, False): parts = urlparse(raw, allow_fragments=allow) print(allow, repr(parts.query), repr(parts.fragment)) # True 'topic=camp' 'fees' # False 'topic=camp#fees' '' 입력·옵션 query fragment 또는path ?topic=camp#fees / True topic=camp fragment = fees ?topic=camp#fees / False topic=camp#fees fragment = 빈 문자열 /read#fees / False 빈 문자열 path = /read#fees 예시는 실제 사이트...

Python 3.12 parse_qsl의 strict_parsing: 오류 필드를 조용히 넘길지 검토 목록에 남길지

이미지
Python 3.12의 parse_qsl은 기본 설정에서 쿼리 해석 오류를 조용히 무시할 수 있습니다. strict_parsing=True를 쓰면 해당 오류가 ValueError로 드러납니다. 링크 목록을 만들 때는 일부 결과만 남기지 말고, 원본 쿼리와 오류 항목을 함께 보존하세요. 목차 1. 같은 쿼리를 두 설정으로 비교하기 2. strict_parsing과 빈 값 옵션은 다른 질문입니다 3. 링크 하나의 오류가 목록 전체를 지우지 않도록 4. 자주 묻는 질문 1. 같은 쿼리를 두 설정으로 비교하기 다음은 Python 3.12에서 실행해 확인한 작은 예시입니다. broken에는 =로 나눈 값이 없습니다. 기본 호출에서는 a와 b의 쌍이 나오지만, strict_parsing=True에서는 예외가 발생합니다. from urllib.parse import parse_qsl raw = 'a=1&broken&b=2' print(parse_qsl(raw)) # [('a', '1'), ('b', '2')] try: pairs = parse_qsl(raw, strict_parsing=True) except ValueError as exc: review = {'original_query': raw, 'error': str(exc)} print(review) # {'original_query': 'a=1&broken&b=2', # 'error': "bad query field: 'broken'"} 기본 호출의 결과가 있다는 사실과 원본의 모든 필드가 보존됐다는 사실은 다릅니다. 추출한 주소를 다시 정리할 때 결과만 보고 원래 쿼리가 완전했다고 판단하지 마세요. 2. strict_parsing과 빈 값 옵션은 다...

Python 3.12 쿼리의 세미콜론: parse_qs 기본 구분자는 &입니다

이미지
Python 3.12의 parse_qs 기본 구분자는 &입니다. 쿼리 안에 세미콜론이 있다고 자동으로 다음 항목으로 나뉘지 않으며, separator를 세미콜론으로 바꾸면 이번에는 &를 같은 방식으로 나누지 않습니다. 목차 1. 버전을 먼저 확인하기 2. 같은 문자열을 두 설정으로 비교 3. 무조건 치환하기 전에 남길 메모 4. 자주 묻는 질문 1. 버전을 먼저 확인하기 Python 공식 문서는 3.10에서 separator 인수가 추가되고 기본 구분자가 &로 정해졌다고 설명합니다. 그 이전 버전의 동작을 소개한 글과 현재 3.12 코드를 같은 조건으로 비교하지 마세요. URL 전체와 쿼리 부분도 구분합니다. 다음 예시는 URL의 query에 해당하는 문자열만 parse_qs에 전달한 결과이며, 네트워크 요청이나 실제 사이트의 지원 형식을 확인하는 예시는 아닙니다. 2. 같은 문자열을 두 설정으로 비교 입력 예시: tag=korea;lang=ko&ref=naver . Python 3.12.8에서 아래 결과를 확인했습니다. 호출 생성된 항목 기본 parse_qs tag → korea;lang=ko / ref → naver separator=';' tag → korea / lang → ko&ref=naver 기본 호출에서는 세미콜론이 tag 값 안에 남습니다. 세미콜론을 구분자로 지정한 호출에서는 &ref=naver가 lang 값 안에 남습니다. 어느 결과가 옳은지는 입력 데이터가 어떤 형식을 약속했는지와 함께 판단해야 합니다. 3. 무조건 치환하기 전에 남길 메모 보존할 것 이유 원래 쿼리 정규화 과정에서 달라진 부분 대조 Python 버전·호출 인수 구분자 해석 조건 확인 입력 출처의 규칙 사이트가 기대하는 형식과 비교 파싱 결과 값 안에 남은 기호를 다시 확인 원문의 모든 세미콜론을 &로 바꾸면 값 자체에 들어 있던 기호의 의미까지 바꿀 수 있습니다. 퍼센트 인코딩된 데이터와 실제 구분자도 구분...

parse_qs max_num_fields: 같은 키가 반복돼도 필드 수를 셉니다

이미지
쿼리 “tag=a&tag=b&tag=c”는 고유 키가 tag 하나여도 입력 필드는 세 개입니다. Python parse_qs의 max_num_fields는 고유 키 개수와 다르게 읽어야 합니다. 목차 1. 기본값과 상한 지정 구분 2. 반복 키 예제를 직접 비교 3. 오류 처리와 값 검증을 분리 4. 자주 묻는 질문 1. 기본값과 상한 지정 구분 Python 3.12 공식 문서는 max_num_fields의 기본값이 None이며 지정한 값보다 필드가 많으면 ValueError를 발생시킨다고 설명합니다. 해당 인수는 Python 3.8에서 추가됐습니다. 사용하는 런타임 버전을 먼저 확인하세요. 링크를 만드는 서비스에서 같은 태그 키를 여러 번 사용하는 형식은 흔합니다. 고유 키가 한 개라는 이유만으로 입력량도 하나라고 계산하면 제한을 잘못 이해하게 됩니다. 2. 반복 키 예제를 직접 비교 직접 실행한 예제에서 parse_qs("tag=a&tag=b&tag=c", max_num_fields=2)는 ValueError가 났고, 상한 3에서는 {"tag": ["a", "b", "c"]}를 반환했습니다. 파싱 결과의 딕셔너리 키 수와 읽은 필드 수를 따로 비교한 결과입니다. 설정 예제 결과 의미 max_num_fields=2 ValueError 필드 3개가 상한 초과 max_num_fields=3 tag 값 목록 3개 상한 안에서 파싱 기본 None 인수에서 상한을 주지 않음 별도 입력 정책을 정해야 함 3. 오류 처리와 값 검증을 분리 상한 숫자는 서비스가 허용하는 입력 구조에 맞춰 정합니다. 이 인수 하나로 URL 전체의 안전성이나 값의 유효성이 보장되지는 않습니다. 예상한 키와 값 형식, 전체 요청 크기 같은 조건도 각자의 처리 단계에서 확인하세요. 처리 메모 확인 질문 파싱 반복 키를 허용하는가 예외 ValueError를 사용자에게 어떻게 알리...

IPv6 링크의 대괄호가 사라졌다면: urlsplit의 netloc와 hostname 확인

이미지
IPv6 주소가 들어 있는 링크를 분리할 때 netloc와 hostname의 모양이 다를 수 있습니다. hostname에 대괄호가 없다고 원본 링크를 잘못 읽었다고 단정하지 말고, URL의 어느 부분을 보고 있는지부터 구분하세요. 목차 1. 예시 주소 하나를 분리해 보기 2. 필요한 값을 목적에 맞춰 고르기 3. 오류 행도 원본과 함께 남기기 4. 자주 묻는 질문 1. 예시 주소 하나를 분리해 보기 from urllib.parse import urlsplit u = "https://[2001:db8::1]:8443/post?tag=x" p = urlsplit(u) print(p.netloc) # [2001:db8::1]:8443 print(p.hostname) # 2001:db8::1 print(p.port) # 8443 위 주소는 형식 설명용 예시이며 실제 글을 여는 목적지가 아닙니다. 이 예제에서 netloc는 대괄호와 포트를 포함하고, hostname과 port는 분리된 값입니다. 링크 목록을 만들 때 원본 열과 분리한 값의 열을 함께 두면 차이를 확인하기 쉽습니다. 2. 필요한 값을 목적에 맞춰 고르기 값 예제 결과 읽는 목적 netloc [2001:db8::1]:8443 네트워크 위치 부분을 보존 hostname 2001:db8::1 호스트 값 대조 port 8443 포트 값 확인 path /post 문서 경로 확인 hostname 값을 “https://” 뒤에 그대로 붙이고 포트까지 다시 덧붙이는 방식은 원본의 구조를 놓치기 쉽습니다. 새 주소를 만들기 전에 호스트, 포트와 경로를 어떤 형식으로 넣어야 하는지 확인하세요. 호스트 값을 뽑는 일과 유효한 URL을 조립하는 일은 다른 작업입니다. 또한 urlsplit이 반환됐다는 사실만으로 안전하거나 실제 접속 가능한 URL이라고 보장되지는 않습니다. Python 문서도 입력 검증의 필요성을 설명합니다. 목록 점검에서는 파싱 결과와 공개 목적지 확인을 별도로 남기세요. 3....

Python urlsplit은 됐는데 port에서 오류가 날 때: 잘못된 포트를 목록에서 따로 남기기

이미지
Python에서 urlsplit 결과가 만들어졌어도 port 속성을 읽을 때 ValueError가 날 수 있습니다. 잘못된 포트 번호를 가진 링크를 “분리 성공”으로만 기록하지 말고, 원본 주소와 어느 단계에서 실패했는지 남기세요. 목차 1. 결과 객체와 속성 읽기를 구분 2. 네 가지 입력을 비교하는 예제 3. 원본과 오류를 같은 행에 남기기 4. 자주 묻는 질문 1. 결과 객체와 속성 읽기를 구분 Python 3.12 문서는 유효하지 않은 포트가 지정된 경우 port 속성을 읽으면 ValueError가 발생한다고 설명합니다. 범위 밖 포트의 오류 동작은 Python 3.6부터의 변경 사항으로 명시되어 있습니다. 포트가 없는 경우의 None과 잘못된 포트의 오류를 같은 빈칸으로 묶지 마세요. 공식 문서가 경고하듯 urlsplit은 전체 URL의 유효성 검증을 수행하는 함수가 아닙니다. 속성을 읽을 수 있었다는 사실 역시 실제 웹페이지 연결이나 안전성을 확인했다는 뜻이 아닙니다. 2. 네 가지 입력을 비교하는 예제 예시 주소의 부분 port 읽기 결과 example.com:443 443 example.com (포트 없음) None example.com:99999 ValueError example.com:abc ValueError from urllib.parse import urlsplit raw = "https://example.com:99999/article" try: parts = urlsplit(raw) port = parts.port except ValueError: result = {"raw": raw, "status": "parse_or_port_error"} else: result = {"raw": raw, "port": port, "status": "port_read"} 이 ...

Python 3.12 URL 재조합 뒤 끝의 ?가 사라질 때: 원본과 urlunsplit 결과 구분

이미지
Python 3.12에서 URL을 분해한 뒤 재조합하면 값 없는 쿼리 구분자 ?가 생략될 수 있습니다. 링크 추출기의 문자열이 달라졌다고 곧바로 값이 유실됐다고 판단하지 말고, 원본과 분해 결과·재조합 결과를 나눠 보세요. 목차 1. 직접 실행한 빈 쿼리 예시 2. 빈 구분자와 값 있는 검색 조건 비교 3. 동등한 구문 설명과 실제 서비스 동작은 별도입니다 4. 자주 묻는 질문 1. 직접 실행한 빈 쿼리 예시 다음은 Python 3.12의 urllib.parse로 확인한 편집용 예시입니다. example.com은 설명을 위한 도메인이며 실제 글 링크가 아닙니다. u = "https://example.com/guide?" parts = urlsplit(u) urlunsplit(parts) → https://example.com/guide 분해 결과의 다섯 부분은 https, example.com, /guide, 빈 query, 빈 fragment입니다. Python 3.12 문서는 비어 있는 쿼리 앞의 물음표 같은 불필요한 구분자가 있으면 재조합 결과가 조금 다르지만 동등한 URL이 될 수 있다고 설명합니다. 2. 빈 구분자와 값 있는 검색 조건 비교 원본 예시 재조합 결과 확인할 차이 https://example.com/guide? https://example.com/guide 값 없는 쿼리 구분자 생략 https://example.com/guide?q=notes https://example.com/guide?q=notes 값 있는 검색 조건 유지 추출한 실제 주소 변환한 실제 주소 원본·변환본을 별도 열에 보존 이 글은 빈 값이 있는 q= 항목을 파싱할 때의 옵션과도 구분됩니다. 여기서는 query 전체가 비어 있고 끝에 구분자만 있는 예시를 다룹니다. 쿼리 키와 값이 있었는지부터 확인해야 다른 문제의 해결법을 가져오지 않습니다. 목록에는 원본 주소, 사용한 함수와 Python 버전, 변환 결과를 남길 수 있습니다. 두 문자열이 달라졌다...

Python urlencode 목록 값: doseq=True와 반복 쿼리 키를 구분해 확인하기

이미지
Python에서 쿼리 값으로 목록을 넣고 각 항목을 같은 키로 반복하려면 urlencode(..., doseq=True) 를 확인하세요. 목록 객체를 한 문자열로 표현하는 것과 여러 개의 key=value 쌍을 만드는 것은 다릅니다. 두 개의 태그를 링크에 담는 작은 예시로 결과를 직접 비교해 보겠습니다. 예시 문자열에는 실제 계정 정보나 인증 값을 넣을 필요가 없습니다. 목차 1. 두 태그로 결과부터 비교하기 2. 입력 형태와 서비스 요구를 분리하기 3. 출력 검토 메모 네 칸 4. 자주 묻는 질문 1. 두 태그로 결과부터 비교하기 Python 공식 문서는 값이 시퀀스일 때 doseq가 참이면 그 값마다 개별 키·값 쌍을 생성한다고 설명합니다. 아래 코드는 문자열 태그 두 개만 사용합니다. from urllib.parse import urlencode params = {"tag": ["museum", "family"]} print(urlencode(params, doseq=True)) # tag=museum&tag=family 결과를 볼 때 “목록이 전달됐다”는 말만 확인하지 말고 같은 tag 키가 두 번 존재하는지 읽어 보세요. 이 예시는 URL에 요청을 보내지 않고 문자열만 만듭니다. 2. 입력 형태와 서비스 요구를 분리하기 내가 원하는 표현 확인할 입력 확인할 출력 같은 키에 값 여러 개 목록 값과 doseq=True tag가 반복되는지 키·값 순서를 명시 튜플 쌍의 시퀀스 입력 순서가 유지되는지 한 값에 쉼표 포함 쉼표를 포함한 문자열 서버가 쉼표 구분을 요구하는지 공식 문서는 튜플 쌍 시퀀스를 사용할 때 쌍의 순서가 결과에 유지된다고 설명합니다. 다만 URL을 만들었다는 사실은 대상 서비스가 그 형식을 받아들인다는 뜻이 아닙니다. 반복 키, 쉼표 문자열, 대괄호 이름 등 무엇을 요구하는지는 그 서비스 문서에서 확인하세요. 가상의 검색 서비스 A는 tag 반복을 받을 수 있고 B는 ca...

urljoin 뒤 도메인이 바뀌는 이유: // 주소와 외부 링크를 목록에서 나누기

이미지
urljoin 에 블로그 기준 주소를 넣었다고 결과가 반드시 그 블로그 안에 머무는 것은 아닙니다. 두 번째 주소가 //다른도메인/경로 형태이거나 완전한 절대 주소라면 결과의 도메인이 달라질 수 있습니다. 따라서 링크 추출에서 주소 결합과 “내 블로그 링크인가” 판정은 별도 단계입니다. 이 글의 예시는 네트워크에 접속하지 않고 문자열 결과만 확인합니다. 예시 도메인을 실제 자료 주소로 사용하지 마세요. 목차 1. //로 시작하는 주소의 결합 결과 2. 원본과 결합 결과를 함께 남기기 3. 목록 확인과 실제 접속을 분리하기 4. 자주 묻는 질문 1. //로 시작하는 주소의 결합 결과 from urllib.parse import urljoin base = 'https://example.org/blog/' print(urljoin(base, '//other.example/post')) # https://other.example/post Python 공식 문서는 두 번째 인수가 절대 주소이면 그 주소의 호스트나 스킴이 결과에 반영된다고 설명합니다. 위 결과는 예시 문자열의 호스트가 바뀐 것입니다. 정상적인 외부 링크일 수도 있으므로 무조건 오류로 지우기보다 목적에 맞게 분류하세요. 2. 원본과 결합 결과를 함께 남기기 열 예시·목적 원본 href 추출한 문자열을 그대로 보존 기준 URL 어느 페이지에서 읽었는지 기록 결합 URL urljoin 결과를 별도 열에 저장 결과 호스트 허용하려는 도메인과 비교 분류 내부·외부·확인 필요를 구분 원본을 덮어쓰면 나중에 왜 다른 호스트가 됐는지 설명하기 어렵습니다. 결과를 저장하기 전에 허용할 스킴과 호스트를 정하고, 잘못된 값이나 빈 값도 별도로 다루세요. 주소를 파싱했다고 유효성과 접근 안전성 검사가 자동으로 끝나는 것은 아닙니다. 3. 목록 확인과 실제 접속을 분리하기 먼저 문자열만으로 결합 결과를 만들고, 허용한 범위에 맞는지 확인한 다음 접속 여부를 정하세요. 출처가 불명확한 입력을 ...

URL에 앰퍼샌드 표기가 남을 때: HTML 원문과 추출한 href를 구분하세요

이미지
블로그 HTML에서 복사한 주소에 &amp; 가 보인다고 곧바로 잘못된 링크라고 판단하지 마세요. HTML 원문에는 문자 참조로 적혀 있고, HTML 파서가 읽은 속성값에서는 실제 & 가 될 수 있습니다. 원문을 보고 있는지, 이미 파싱한 href를 보고 있는지 부터 구분하면 중복 변환과 쿼리 키 오류를 찾기 쉽습니다. 아래 예시는 실제 사이트를 수집하지 않는 작은 문자열 실험입니다. 목차 1. HTML 원문의 &amp;는 문자 참조 2. HTMLParser로 속성값을 읽는 작은 예시 3. 추출 뒤 다시 바꾸기 전에 남길 기록 4. 자주 묻는 질문 1. HTML 원문의 &amp;는 문자 참조 MDN은 HTML 문자 참조를 웹페이지에 다른 문자를 나타내기 위한 표기로 설명하며, &amp; 가 & 에 대응함을 안내합니다. 주소의 쿼리 구분자와 HTML 안에서 그 문자를 적는 표기를 같은 문자열 단계로 취급하지 않는 것이 핵심입니다. MDN 문자 참조 안내 HTML 원문 예: <a href="https://example.com/?a=1&amp;b=2">예시</a> HTML 파서가 읽은 href: https://example.com/?a=1&b=2 주소를 새 HTML 속성에 넣는 단계와, URL 자체의 쿼리를 분석하는 단계도 나눠 두세요. 파일에 저장된 문자열을 설명 없이 모두 ‘URL’이라고 부르면 어떤 변환이 이미 적용됐는지 알기 어려워집니다. 2. HTMLParser로 속성값을 읽는 작은 예시 Python 공식 문서에 따르면 handle_starttag 에 전달되는 속성값에서는 문자·엔터티 참조가 치환됩니다. 다음은 독립적으로 만든 예시입니다. 네트워크에 요청하거나 글을 변경하지 않고, 문자열 속 href 하나만 읽습니다. Python HTMLParser 속성값 안내 from html.parser import HTMLParser class LinkReader(HT...

링크 쿼리의 빈 값이 사라질 때: parse_qsl과 keep_blank_values 비교

이미지
주소에는 tag= 가 있는데 링크 분석 결과에는 그 항목이 없다면 파서 옵션을 확인하세요. Python의 parse_qsl() 은 기본 설정에서 빈 값을 무시하며, keep_blank_values=True를 주면 빈 문자열로 남깁니다. 원본 주소가 잘못됐다고 먼저 결론 내리지 마세요. 목차 1. 같은 문자열을 두 설정으로 읽어 보세요 2. 빈 값이 필요한 업무인지 먼저 정하세요 3. 원본·옵션·결과를 한 줄로 묶어 검수하세요 4. 자주 묻는 점 1. 같은 문자열을 두 설정으로 읽어 보세요 Python 3.12 공식 문서는 parse_qsl() 이 이름·값 쌍의 목록을 반환한다고 설명합니다. 다음 예시에서는 같은 쿼리를 두 번 읽고 빈 값이 결과에 남는지만 비교합니다. 토큰이나 실제 사용자 주소가 없는 자체 예시이며 로컬 실행 결과도 확인했습니다. from urllib.parse import parse_qsl query = "tag=&page=2&mode=" print(parse_qsl(query)) # [('page', '2')] print(parse_qsl(query, keep_blank_values=True)) # [('tag', ''), ('page', '2'), ('mode', '')] 설정 예시 결과에서 남는 항목 기본값 page=2 keep_blank_values=True tag의 빈 문자열, page=2, mode의 빈 문자열 여기서 tag와 mode는 주소에서 사라진 것이 아니라 기본 파싱 결과에 포함되지 않은 것입니다. 원본과 결과를 나란히 보관하면 두 현상을 구분할 수 있습니다. 2. 빈 값이 필요한 업무인지 먼저 정하세요 링크 추출 목록에서 빈 필드를 별도로 점검하려면 빈 값을 남기는 편이 목적에 맞을 수 있습니다. 반대로 실제 값이 들어 있는 항목만 요약하려는 작업...

블로그 링크 중복 확인에서 #뒤를 지울 때: urldefrag와 원본 주소 보존

이미지
같은 글의 #fees 와 #parking 링크를 하나로 묶기 전에 문서가 같은 것과 이동 위치가 같은 것을 구분 하세요. Python의 urldefrag는 URL에서 fragment를 분리해 돌려줍니다. 아래 코드는 Python 3.12에서 확인한 자체 예시입니다. example.com 주소는 문법 설명용이며 실제 행사 페이지를 조회한 결과가 아닙니다. 목차 1. 문서 주소와 fragment 두 값 받기 2. 중복 검사는 원본을 남긴 뒤 3. 같은 문서라고 링크를 일괄 교체하지 않기 1. 문서 주소와 fragment 두 값 받기 from urllib.parse import urldefrag original = "https://example.com/guide?lang=ko#fees" parts = urldefrag(original) print(parts.url) print(parts.fragment) # https://example.com/guide?lang=ko # fees 공식 문서에 따르면 fragment가 있으면 이를 뺀 URL과 fragment 문자열을 반환합니다. 없으면 URL은 그대로이고 fragment는 빈 문자열입니다. 이 호출은 검색 매개변수인 ?lang=ko 를 삭제하라는 지시가 아닙니다. 2. 중복 검사는 원본을 남긴 뒤 보존할 열 용도 original 독자가 실제로 누르는 전체 주소 document_url 문서 단위로 묶는 비교값 fragment 목차·본문의 이동 위치 검증 결과 대상 문서와 앵커를 실제 확인한 기록 .../guide#fees 와 .../guide#parking 는 분리 후 document_url이 같습니다. 하지만 비용 표와 주차 안내로 이동하는 목적은 다릅니다. 문서 묶음에서는 한 그룹으로 보고, 게시할 링크를 만들 때는 original을 사용하세요. 3. 같은 문서라고 링크를 일괄 교체하지 않기 문서별 HTTP 응답을 줄여 확인하는 작업과, 각 목차 앵커가 실제로 있는지 확인하는 작업을 나눕니다....

Python urlsplit 링크 목록: 주소를 나눴다고 유효성 검증이 끝난 것은 아닙니다

이미지
블로그 링크 목록을 Python의 urlsplit으로 나눴다고 그 주소가 유효하거나 안전하다는 확인이 끝난 것은 아닙니다. 공식 문서는 이 함수가 URL 검증을 수행하지 않는다고 명시합니다. 분리 결과와 서비스가 허용할 조건을 따로 확인해야 합니다. 예제는 예약된 예시 도메인을 사용하며 외부 주소로 접속하지 않는 문자열 실습 입니다. 파싱 결과를 공개 글의 실제 이동 검증으로 보고하지 않습니다. 목차 1. 분리 결과가 주는 것과 주지 않는 것 2. 세 문자열을 같은 성공으로 묶지 않기 3. 네트워크 없이 결과를 남기는 작은 예제 4. 링크 목록의 확인 단계를 분리하기 5. 자주 묻는 질문 1. 분리 결과가 주는 것과 주지 않는 것 urlsplit은 scheme, netloc, path, query, fragment로 주소를 나눕니다. 반환 객체에서는 hostname과 port 같은 속성도 읽을 수 있습니다. 공식 문서의 핵심은 이것이 주소를 구성요소로 읽는 작업이라는 점입니다. 블로그 링크 정리 도구라면 지원할 스킴, 필요한 호스트, 허용할 목적지와 오류 처리 정책을 별도로 정해야 합니다. HTTP 응답이나 실제 글의 존재 여부는 문자열 분리만으로 알 수 없습니다. 2. 세 문자열을 같은 성공으로 묶지 않기 입력 예시 살필 결과 주의할 점 https://example.org:443/post hostname과 port를 각각 확인 정상 분리와 실제 페이지 존재는 별도 example.org/post netloc이 비고 path로 읽힐 수 있음 도메인처럼 보여도 //가 없는 입력 https://example.org:abc/post 분리 후 port 속성을 읽으면 ValueError 객체 반환과 모든 속성 접근 성공은 다름 공식 문서는 netloc을 //로 도입한 경우에 인식한다고 설명합니다. 숫자가 아닌 포트는 port를 읽을 때 오류가 날 수 있습니다. 예외를 빈 문자열로 바꾸고 조용히 다음 주소로 넘어가면 원래 문제가 사라져 보일 수 있습니다. 3. 네트워크 ...

블로그 링크의 빈 href와 속성 누락: 같은 빈칸으로 묶지 마세요

이미지
링크 목록에 빈칸이 보인다면 href 속성이 없는지, 속성은 있고 값만 비었는지 를 먼저 나누세요. 두 상태를 한꺼번에 「주소 없음」으로 정리하면 브라우저가 해석한 결과를 놓칠 수 있습니다. 원래 값과 해석된 주소를 함께 기록하는 편이 좋습니다. 아래 설명은 HTML의 a 요소와 HTMLAnchorElement.href를 기준으로 합니다. 실제 페이지에는 스크립트나 다른 기준 주소가 관여할 수 있으므로 저장된 문자열만으로 클릭 결과를 확정하지 않습니다. 목차 1. 두 빈칸의 출발점이 다릅니다 2. 원래 값과 해석된 주소를 나란히 기록하세요 3. 임시 버튼이 그대로 남은 경우의 검수 예 4. 자주 묻는 질문 5. href 프로퍼티 원문 예시 보기 1. 두 빈칸의 출발점이 다릅니다 MDN은 href 속성이 없을 때 href 프로퍼티가 빈 문자열을 반환한다고 설명합니다. 반면 속성이 존재하고 값이 빈 문자열이면 유효한 상대 URL로 취급되어 문서의 기준 URL을 가리킵니다. <a>자료 보기</a> <a href="">자료 보기</a> 첫째는 href가 빠진 요소이고 둘째는 빈 값을 가진 속성이 있는 요소입니다. 두 예에서 보이는 문구가 같아도 주소 기록은 구분해야 합니다. 원하는 상세 자료의 주소가 비어 있는 상태라면 공개 전에 목적지를 다시 지정하세요. 2. 원래 값과 해석된 주소를 나란히 기록하세요 기록 항목 무엇을 남기나 구분할 내용 href 속성 존재 있음 / 없음 빈 문자열과 속성 누락 원래 속성값 입력된 문자열 그대로 브라우저가 보완한 절대 주소 해석된 href 브라우저가 해석한 URL 실제 이동 뒤 최종 주소 공개 클릭 결과 도착한 페이지와 내용 주소 문자열만 맞는 상태 개발 도구로 확인할 수 있다면 getAttribute("href")와 href 프로퍼티를 비교합니다. MDN의 안내처럼 원래 속성값과 기준 URL에 따라 해석된 절대 주소는 다른 표현일 수 있습니다. 다른 사...

블로그 링크 목록의 javascript: 주소: 공개 글과 페이지 동작을 나누기

이미지
링크 목록에 javascript: 로 시작하는 값이 보이면 공개 글 주소로 바로 등록하지 마세요. MDN은 이 형식이 탐색 시 JavaScript를 실행하는 대상으로 사용된다고 설명합니다. 버튼을 눌렀을 때 일어나는 동작과 다른 사람에게 공유할 글 주소를 구분해야 합니다. 목차 1. 주소 맨 앞의 스킴부터 읽기 2. 실행하지 않고 항목을 분류하기 3. 공유할 주소는 실제 글 화면에서 찾기 4. 자체 검수표에 분리 칸 만들기 5. 자주 묻는 질문 1. 주소 맨 앞의 스킴부터 읽기 URL의 앞부분은 주소를 어떻게 해석할지 알려 줍니다. MDN의 URL.protocol 설명은 마지막 콜론까지 포함한 문자열을 반환한다고 안내합니다. 예를 들어 일반적인 보안 웹 주소의 값은 https: 입니다. javascript: 가 있다는 사실은 “이 사이트의 새 글”을 뜻하지 않습니다. 링크 추출 과정에서 메뉴나 버튼의 동작까지 함께 모았을 가능성을 먼저 살펴봅니다. 모든 항목을 같은 글 목록에 섞으면 중복과 누락을 확인하기 어렵습니다. 2. 실행하지 않고 항목을 분류하기 아래 값은 구분을 설명하기 위한 텍스트 예시이며 실행용 링크가 아닙니다. 공개 글 후보: https://example.com/notes/one 페이지 동작 예시: javascript:void(0) 주소를 확인하려고 알 수 없는 스크립트를 주소창에 붙여 넣거나 실행할 필요는 없습니다. 수집 결과의 문자열을 읽어 공개 페이지 후보와 동작 항목을 별도 칸에 둡니다. 스크립트의 실제 기능은 이 한 줄만으로 추정하지 않습니다. 목록 항목 다음 확인 http:·https: 페이지 후보 공개 접근·제목·본문·최종 주소 javascript: 동작 항목 공개 글 목록에서 분리하고 원래 버튼 맥락 기록 빈 값·해석 불가 값 원본 위치를 적고 임의 주소를 만들지 않기 3. 공유할 주소는 실제 글 화면에서 찾기 메뉴 동작을 수집했더라도 실제 글이 없는 것은 아닙니다. 사이트의 정상 탐색으로 글을 열고 제목과 내용을 확인한 다음 ...

블로그 주소의 +가 공백으로 읽힐 때: 검색 값과 실제 더하기 기호 구분

이미지
검색 값의 + 를 실제 더하기 기호로 보존해야 한다면 주소 문자열을 만드는 방식을 확인하세요. URLSearchParams 생성자는 검색 문자열 안의 + 를 공백으로 읽습니다. 링크가 열린다는 확인과 검색 값이 보존됐다는 확인을 나눠야 합니다. 목차 1. 같은 글자처럼 보여도 해석된 값은 다르기 2. 값을 이어 붙이기보다 append로 구성 3. 원본 값·저장 주소·읽은 값 나란히 검수 4. 자주 묻는 질문 1. 같은 글자처럼 보여도 해석된 값은 다르기 MDN의 URLSearchParams 안내는 더하기 기호 보존 문제를 별도로 설명합니다. 이 규칙은 검색 매개변수를 읽고 쓰는 방식에 관한 것입니다. 주소의 모든 위치에 있는 +를 무조건 바꾸라는 의미가 아닙니다. 검색 문자열 get("q")로 읽는 값 확인할 뜻 q=A+B A B 가운데가 공백 q=A%2BB A+B 더하기 기호가 값 안에 있음 표는 실제 비공개 링크가 아닌 자체 연습 값입니다. 두 경우를 로컬 계산으로 확인했습니다. 검색어나 캠페인 코드에 +가 포함되어 있다면 원래 값과 읽은 값을 나란히 놓아 비교하세요. 2. 값을 이어 붙이기보다 append로 구성 값을 문자열에 그대로 끼워 넣으면 원래 +와 공백 표현을 혼동할 수 있습니다. MDN은 개별 키와 값을 append로 추가하는 방식을 설명합니다. 아래 코드는 URLSearchParams가 어떻게 문자열을 만드는지 보는 연습이며 실제 링크를 열거나 외부에 데이터를 보내지 않습니다. const params = new URLSearchParams(); params.append("q", "A+B"); params.toString(); // q=A%2BB params.get("q"); // A+B 개별 값에 append를 쓸 때는 이미 인코딩한 문자열을 다시 넣지 않습니다. 예를 들어 원래 값과 이미 변환한 값을 섞으면 % 기호가 다시 인코딩되어 예상과 다른 문자열을 만들 수 있...

목차 #링크가 다른 주소로 열릴 때: HTML의 base 기준 주소를 확인하세요

이미지
href="#intro"라고 적혀 있어도 HTML에 base 기준 주소가 있으면 다른 문서 주소로 해석될 수 있습니다. MDN은 조각 링크도 base를 기준으로 해석되어 해당 기준 URL에 조각이 붙은 요청을 만들 수 있다고 설명합니다. 앵커 ID만 고치기 전에 실제 이동 주소를 확인하세요. 목차 1. 상대 주소의 기준이 바뀌는 경우 2. 가상 주소로 보는 조각 링크 3. 링크 점검표 4. 자주 묻는 질문 1. 상대 주소의 기준이 바뀌는 경우 HTML의 base 요소는 문서 안 상대 URL에 사용할 기준 URL을 지정합니다. 문서에 여러 base가 있다면 첫 href와 첫 target만 적용된다는 MDN 설명도 있습니다. 이 글에서는 href 기준 주소의 영향만 살펴봅니다. 문제 확인은 공개 페이지에서 버튼이나 목차를 눌렀을 때의 주소, 링크에 적힌 href, 문서의 base href를 각각 적는 것으로 시작합니다. 어느 하나를 다른 값으로 추측해 대신 쓰지 마세요. 2. 가상 주소로 보는 조각 링크 <base href="https://example.com/guide/"> <a href="#intro">도입</a> MDN의 설명에 따라 이 조각 링크는 https://example.com/guide/#intro를 기준으로 해석됩니다. 현재 보고 있는 다른 문서의 #intro로 이동한다고 무조건 생각하면 안 됩니다. example.com은 설명용 가상 주소이며 실제 자료 목적지로 제안하는 링크가 아닙니다. 템플릿의 base를 제거하거나 바꾸면 다른 이미지·상대 링크에도 영향이 갈 수 있습니다. 목차 한 개의 문제를 고치려고 기준 주소를 바꾸기 전에 영향 범위를 확인하세요. 3. 링크 점검표 자료 적을 값 목차 원문 href에 적힌 상대 주소 또는 #조각 문서 기준 base href가 있는지와 그 값 실제 클릭 최종 문서 URL과 조각 앵커 대상 도착 문서에 ID가 실제 있는지 ...

블로그 URL에 같은 검색 키가 두 번 있을 때: get과 getAll로 값 누락 확인

이미지
URL에 같은 검색 키가 두 번 들어 있으면 한 값만 읽은 결과를 전체 값이라고 보고하지 마세요. JavaScript의 URLSearchParams에서 get은 첫 값을, getAll은 해당 키의 모든 값을 배열로 돌려줍니다. 블로그 링크를 검수할 때 원본 주소와 프로그램이 읽은 값을 구분하는 작은 예시입니다. 아래 example.com 주소는 설명용 가상 데이터이며 실제 게시물이나 신청 사이트로 안내하는 링크가 아닙니다. 목차 1. 키 이름은 하나여도 값은 여러 개일 수 있습니다 2. get과 getAll 결과를 비교하기 3. 검수 결과에 남길 비교표 4. 링크를 고치기 전 원본을 보존하기 5. 검색 키 검수의 질문 1. 키 이름은 하나여도 값은 여러 개일 수 있습니다 https://example.com/read?tag=travel&tag=food 이 주소에서는 tag라는 키가 두 번 쓰였습니다. travel과 food는 각각의 값입니다. 눈으로 주소를 읽었을 때 두 값이 있다는 사실과, 도구가 어느 방식으로 값을 추출했는지를 따로 확인합니다. 반복된 키가 무조건 오류라는 뜻은 아닙니다. 목적지 서비스가 여러 값을 어떻게 처리하는지는 그 서비스의 규칙으로 확인해야 합니다. 이 글은 URLSearchParams가 값을 읽는 동작을 설명하며 모든 웹사이트의 서버 처리를 단정하지 않습니다. 2. get과 getAll 결과를 비교하기 MDN은 get이 주어진 검색 키에 대응하는 첫 값을 반환하며 키가 없으면 null이라고 설명합니다. getAll은 그 키에 대응하는 모든 문자열 값을 배열로 반환하고, 해당 값이 없으면 빈 배열을 반환합니다. const params = new URLSearchParams("tag=travel&tag=food"); params.get("tag"); // "travel" params.getAll("tag"); // ["trav...

블로그 링크 주소에 @가 있다면: 앞의 이름과 실제 접속 도메인 구분하기

이미지
추출한 링크의 앞부분에 익숙한 이름이 보인다고 접속 도메인을 확인한 것은 아닙니다. 특히 URL에 @가 있다면 사용자 정보 부분과 호스트를 구분해서 읽어야 합니다. 링크 목록의 제목, 전체 주소, 실제 호스트를 별도 항목으로 두면 이런 혼동을 줄일 수 있습니다. 아래 주소는 형식 설명용 가상 예제이며 방문할 링크로 제공하지 않습니다. 예제는 로컬 URL 파서로 구조만 확인했고, 그 주소에 접속하거나 안전성을 검사한 결과는 아닙니다. 실제 계정명·비밀번호·인증 정보를 주소나 공유 목록에 넣지 마세요. 목차 1. @ 앞의 문자열은 호스트가 아닐 수 있어요 2. hostname과 포트·경로를 따로 적기 3. 추출 목록에 확인 상태를 남기는 방법 4. 자주 묻는 주소 검수 질문 1. @ 앞의 문자열은 호스트가 아닐 수 있어요 MDN은 URI의 authority 영역이 사용자 정보, 호스트, 포트로 구성될 수 있다고 설명합니다. user@host 형태에서는 @ 앞이 사용자 정보이고 뒤가 호스트입니다. HTTP 주소에 사용자 정보를 직접 포함하는 방식은 권장하지 않는다는 안내도 있습니다. 다음 예제를 보세요. https://news.example.com@archive.example.org/guide 여기서 호스트 이름은 archive.example.org 입니다. 앞의 news.example.com 은 이 구조에서 사용자 정보로 읽힙니다. 주소의 왼쪽에 보이는 이름만 보고 링크 목록의 도메인 칸에 옮기면 다른 결과를 적게 됩니다. @를 포함한 모든 문자열에 이 해석을 적용하는 것도 정확하지 않습니다. 이메일 주소와 웹 URL은 형식이 다르고, @가 경로나 검색 값에 등장하는 경우도 있습니다. 문자 하나를 기준으로 전체 주소를 무조건 자르기보다 URL의 구조를 확인하세요. 2. hostname과 포트·경로를 따로 적기 웹의 URL 객체에서 hostname 은 도메인 이름 또는 IP 주소 부분을 읽는 속성입니다. 포트를 따로 지정한 주소라면 host 와 hostname ...

이미지 주소가 blob:로 시작할 때: 편집 미리보기와 공개 URL 나누기

이미지
편집기에서 복사한 이미지 주소가 blob: 로 시작한다면, 그대로 오래 사용할 공개 이미지 링크라고 기록하지 마세요. 주소 안에 웹사이트 이름이 들어 있어도 서버에 저장된 이미지 파일의 공유 주소와 같은 뜻은 아닙니다. 링크 목록 작성 원칙 편집 중 미리보기 주소와 발행된 이미지 주소를 분리합니다. 먼저 원본 파일과 발행 결과를 보존하고, 공개 페이지에서 실제 이미지와 접근 범위를 확인한 뒤 사용할 링크를 기록하세요. 목차 1. blob: 주소는 무엇을 가리킬까 2. data:와 blob:를 같은 링크로 처리하지 않기 3. 언제까지 열리는지를 고정 숫자로 적지 않기 4. 편집 이미지를 공개 링크로 기록하는 순서 5. 자주 묻는 질문 1. blob: 주소는 무엇을 가리킬까 MDN의 blob: URL 문서 는 Blob 또는 MediaSource를 URL을 사용하는 기능과 연결하는 주소라고 설명합니다. 직접 문자열을 만들어 쓰는 주소가 아니라 생성·해제 함수로 관리하는 식별자입니다. 이미지를 화면에 보여 주거나 로컬에서 만든 데이터의 다운로드에 사용할 수 있습니다. 문서가 설명하는 구조에는 만든 환경의 출처와 식별자가 포함됩니다. 따라서 안쪽에 https: 와 사이트 이름이 보인다는 이유만으로 그 뒤를 일반 파일 경로처럼 읽으면 안 됩니다. blob: 부분만 지워서 “공개 주소로 변환”하는 방법도 아닙니다. 편집기의 임시 이미지 표시가 정상이라는 사실과, 발행된 글에서 독자가 이미지를 볼 수 있다는 사실은 별도로 확인해야 합니다. 2. data:와 blob:를 같은 링크로 처리하지 않기 주소에서 본 것 구분할 특징 목록에 적을 상태 data: 데이터를 주소 안에 담는 방식 내장 데이터 여부 확인 blob: 별도의 Blob 또는 MediaSource를 가리키는 식별자 편집·미리보기 주소 여부 확인 일반 웹 이미지 URL 해당 웹 요청과 접근 조건 확인 필요 발행 페이지에서 로딩 확인 글의 공개 URL 이미지 파일 주소와 목적이 다름 독자에게 안내할 글 주소 MDN...