노트

encodeURI와 encodeURIComponent

encodeURI and encodeURIComponent

프런트엔드#js#http · 연결된 개념 2개

쉽게 말하면

encodeURIComponent는 주소 한 칸에 넣을 글자를 포장하는 함수예요. 검색어에 &가 있으면 주소가 거기서 끊긴 걸로 읽히니, 깨지기 쉬운 글자를 %26 같은 안전한 모양으로 싸서 넣는 거죠.

비유가 깨지는 곳 포장을 두 번 하면 %가 %25가 돼서 값이 깨져요. encodeURI는 주소 전체용이라 &나 = 같은 구조 문자를 그대로 두니, 쿼리 값엔 encodeURIComponent나 URLSearchParams를 써요.

encodeURIComponent()는 URL(Uniform Resource Locator)의 한 조각(쿼리 값, 경로 세그먼트)에 넣을 문자열을 퍼센트 인코딩(Percent-Encoding)하는 함수다. encodeURI()는 URL 전체를 인코딩하므로 &·=·?·/ 같은 구조 문자는 그대로 둔다.

encodeURIComponent('a&b')   // 'a%26b'
encodeURI('a&b')            // 'a&b'  ← 쿼리 값에 쓰면 b가 별도 파라미터로 읽힌다
 
router.push(`/search?q=${encodeURIComponent('react hooks')}`) // q=react%20hooks
  • 쿼리 값이나 동적 경로에 사용자 입력·한글을 넣을 때는 encodeURIComponent를 쓴다
  • 이중 인코딩(Double Encoding): 이미 인코딩된 값을 다시 인코딩하면 %가 %25가 되어 hello%2520world처럼 깨진다
  • decodeURIComponent('%')처럼 형식이 잘못된 값은 URIError를 던진다. 외부에서 온 값을 디코딩할 때는 try/catch로 감싼다
  • 쿼리 문자열은 직접 이어 붙이기보다 URLSearchParams로 만들고 읽으면 인코딩을 알아서 처리해 준다. params.get('q')는 이미 디코딩된 값을 돌려주므로 다시 디코딩하지 않는다
  • URL에 담긴 쿼리 값이 다른 사이트로 새어 나갈 수 있는 경로는 Origin·Referer 헤더와 Referrer-Policy에 있다. 사용자 입력을 정규식에 넣을 때의 이스케이프는 정규 표현식 기초

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 우선순위 큐

    원소마다 우선순위가 있고, 들어온 순서와 상관없이 우선순위가 가장 높은 것부터 꺼내는 추상 자료형(Abstract Data Type, ADT). 같은 우선순위끼리의 순서는 보장하지 않는다. 응급실 대기 순서가 좋은 비유다.

  • 쿼리 키 설계와 키 팩토리

    쿼리 키(Query Key)는 TanStack Query가 캐시 항목을 식별하고 무효화 범위를 고르는 배열이다. 키를 일반적인 것에서 구체적인 것 순서로 쌓고, 한 곳(키 팩토리)에서 만들게 하면 부분 일치(Partial Matching)로 원하는 범위만 정확히 무효화할 수 있다.

  • XSS

    XSS(Cross-Site Scripting)는 공격자가 넣은 스크립트가 내 사이트의 출처(origin) 권한으로 사용자 브라우저에서 실행되는 공격이다. 같은 출처의 코드로 돌기 때문에 same-origin-policy가 막아 주지 못한다. 그 스크립트는 페이지를 바꾸고, 로그인한 사용자 행세를 하며 요청을 보내고, JS가 읽을 수 있는 데이터(localStorage의 토큰 등)를 빼 갈 수 있다.

  • SEO

    SEO(Search Engine Optimization)는 검색 엔진이 페이지를 잘 찾고(크롤링, crawling), 이해해서 저장하고(색인, indexing), 알맞은 검색어로 노출하도록(순위, ranking) 사이트를 다듬는 일이다. 개발자가 맡는 부분은 대부분 앞의 두 단계, 즉 "검색 엔진이 읽을 수 있게 만드는 것"이다.

  • DRF 파서·렌더러와 콘텐츠 협상

    DRF에서 파서(Parser)는 요청 본문을 파이썬 자료형으로 바꾸고, 렌더러(Renderer)는 응답 데이터를 클라이언트가 받을 형식으로 바꾼다. 어떤 렌더러를 쓸지는 요청의 Accept 헤더를 보고 고르는데, 이를 콘텐츠 협상(content negotiation)이라 한다.

보기 옵션