프론트 라우터 url(클라이언트 라우터? 사이트 주소? 사용자에게 보여지는 url?)에서 space를 어떻게 처리하는 게 좋을지에 대해 고민하다.
이에 대한 글을 써보기로 했다.
URLs cannot contain spaces.
url은 space를 포함할 수 없다.
평소 프론트 개발 시 바라봤던 관점
프론트에서 바라봤을 때 router를 표시하기 위한 url은
- 페이지 간 소통
- 유입자의 유형 구별(데이터 수집)
- 사용자가 원하는 상태에 맞게 끔 router를 통해 들어온 정보로 페이지 업데이트
등 개발자, 서비스를 제공하는 자 시점에서 더 많이 사용하고 고민했던 것 같다.
웹에 익숙해진 사용자들
하지만 점차 프론트 URL에서 사용되는 주소들이 읽기 쉬워지는 요즘
어떤 변화들이 일어나고 있나 고민하게 되었다.
각 커뮤니티의 주소는 원래 1:1간의 공유로 잠시 사용되었지만.
이제는 홈페이지나 이메일처럼 1:N의 공유로 이뤄지는 경우가 많고
커뮤니티들은 그에 맞춰 사용자들이 편하게 접근하고 인식할 수 있도록 변하는 추세이다.
숫자나 hash된 어려운 주소가 아닌 사람이 읽을 수 있는 주소를 사용할 수 있게 하고 있다.
읽기 쉬운 주소는 더 믿음이 가기도 한다.(정확한 입력을 의미하기도, 외우기도 쉽고, 안전한 사이트의 느낌을 준다.)
또한 해당 주소를 들어가기 전에 무슨 사이트 혹은 페이지인지 이해할 수 있게 되었다.
이는 더 나은 seo를 의미한다.
그렇다면 space 표시를 %20 대신 어떤 걸 사용하면 좋을까?
원래는 대부분 띄어쓰기는 인코딩 된 그대로인 %20를 많이 사용했었다.
하지만 아무리 다른 부분이 읽을 수 있는 단어로 되어있어도
중간에 %20가 들어간다면 일반 사용자에게는 일단 불편한 주소로 보일 것이다.
이를 대체하기 위해 '_', '-', '+' 등 다양한 시도들이 일어나고 있음을 볼 수 있다.
하지만 '+'는 2개 이상의 단어를 혼합하여 검색할 때 사용되는 것이 타당하다고 보기에 이는 제외하기로 했다.
'_'도 많이 사용되지만
space를 넣을 수 없는 TAG에서 시작된 _의 사용법은
이제 사용자가 직접 스페이스를 추가한 1개의 단어를 만들고 싶을 때 사용하는 것으로 많이 자리 잡은 듯하다.
그래서 나는 사용자가 직접 제공하는 데이터는 최대한 보존하고 싶기에 '-'를 띄어쓰기 대신에 사용하기로 했다.
그리고 중복되는 이름의 경우 가독성은 떨어지지만,
그래도 이름이 보이도록하기 위해 암호화 값 + 이름을 사용하기로 했다.
(해쉬는 비암호화 할 수 없음...)
한글을 주소 URL에 포함시키면 어떻게 될까?
%와 같은 특수기호들은 예상치 못한 문자들은 URL에서 에러를 일으킨다. 그렇기 때문에 encodeURIComponent()과 같은 함수들로 URL을 sanitize하는 것이 중요하다.
하지만 예전과 다르게 종종 한국어도 주소에 포함되어 사용되는 모습을 발견할 수 있다. velog도 공유하기 버튼을 통해 공유하면, 한글 제목이 포함된 URL이 생성되어 공유됨을 확인할 수 있다.
한글은 URL에 포함될 수 있을까?
처음 사용된 URL에서는 사용될 수 없었다.
하지만, 이제 모던 브라우저에서는 한글 주소를 사용할 수 있다.
그 이유는, 모던 브라우저들이 Uniform Resource Identifier (URI)의 확장인 Internationalized Resource Identifier (IRI)을 이제 따르기 때문이다.
원래 URL에는 ASCII characters (A-Z, a-z, 0-9, -, _, ., ~). 만 제한되어 사용될 수 있었다.
하지만, 이제 모던 브라우저가 라틴이 아닌 문자(예, 한글, 중국어, 일본어)를 UTF-8와 함께 URL에 사용할 수 있도록 허용하기 때문에 가능한 것이다.
작동 방법
브라우저는 내부적으로 자동적으로 URL을 인코딩하고 디코딩한다.
한국어로 된 주소를 입력창에 입력하면 브라우저는 주소를 인코딩(Domain Names -> Punycode, Path -> Percent-encoding)한다.
서버는 인코딩된 버전을 받고
브라우저는 다시 그것을 한국어로 디코딩하여 주소바에 보여준다.
wikipedia - Internationalized domain name
wikipedia - Punycode
wikipedia - Percent-encoding
한글 URL을 웹앱 서비스에 붙여 넣기하면 어떻게 될까?
서비스마다 처리 방식이 다르다.
URL 형식인 http로 시작하는 단어의 경우 주소로 인식하고 이를 처리하는 방식에서의 차이가 있는 듯하다.
노션, 카톡과 네이버 블로그는 한글이 포함된 URL을 한글이 포함되도록 붙어 넣기가 가능했다.
하지만, 작은 차이가 있었다.
노션과 카톡은 브라우저 URL과 같은 URL이 붙여넣기가 됐다.(스페이스를 분기로 주소를 인식하는 것 같다.)
네이버 블로그는 '『'처럼 특수문자가 나오면 에러가 나는 것처럼 그전까지만 URL로 표시됐다. 그래서 정상적으로 URL을 클릭 시 정상적이 페이지 이동이 불가능했다.('『'처럼 특수문자를 추가할 특이한 케이스까지는 고려하지 않은 것 같다.)
옵시디언은 인코딩되어 붙어 넣기가 됐다.
(사실 가장 안전한? 주소 인식에 문제가 없는, 하지만 유저의 편의는 사라진 방법이지 않을까.)
번외) 데이터베이스에 데이터 저장 시 가공을 해야 할까?
새로 만드는 프로젝트에서는 검색도 많고 데이터 간 연결이 잘돼야하는 더 의미 있는 서비스라 프로젝트 막바지인 지금
사용자 입력을 저장하고, 데이터 간 연결, query에서의 문제에 대해 더 깊이 고민했다.
일단 모든 것은 비용을 줄이기 위해 노력.
그래서 결국, 시간과 공간을 어떻게 효율적으로 쓰느냐에 대한 고민이다.
저장 유형
원본 데이터 저장
특징
- 사용 시 항상 가공이 필요
- 사용에 따라 언제든 다양한 가공이 가능
- 사용자가 직접 제공한 원본을 저장(손실된 데이터 없음)
- 생각하지 못한 데이터(나중에 사용하기 위해 합하지 못한)가 존재할 수 있음
- 나중에 가공해서 데이터를 저장하는 방식을 추가할 수 있지만
- 가공된 데이터를 기준으로 사용하기 위해서는 이전에 데이터를 모두 변경하는 시간이 추가로 소요됨
사용할 수 있는 데이터 유형
- 아직 가공에 대한 확실한 기준이 없는 경우
- 가공 시 생각하지 못한 데이터 손실이 많을 것으로 예상하는 경우
- 다른 데이터와 아무 연관이 없는 경우
- 단순 정보를 저장하는 용도의 경우
가공해서 넣기
특징
- 원본 데이터 소실 - 복구할 수 없음
- 빠른 query 가능
- 나중에 원본을 넣는 로직 추가로 넣을 수 있음, 이전의 데이터를 손댈 필요 없음
사용할 수 있는 데이터 유형
- 다른 데이터와 연관성이 있어야 하는 경우
- 데이터 별 분리가 이뤄져 쌓여야 하는 경우
- 해당 데이터를 정렬해야 하는 경우
원본 + 가공된 데이터
특징
- 추가적인 공간 필요 - 비용
사용할 수 있는 데이터 유형
- 가공에 소요되는 시간이 많고 언제나 가공이 필요하지만, 다양하게 가공되야 하는 경우
- 원본의 가치가 높다고 여겨지는 경우
space 처리
위 사항을 기준으로 3가지 방식으로 데이터를 분류해 저장하기로 했다.
사용자 입력에서 space 없애기
tag 처럼 사용자는 space를 ''나 2번째 이상의 단어에서 대문자로 변화를 나타내는 방법을 찾는다.
(요즘에는 ''를 사용하는 방식으로 일관화되고 있는 듯하다. 그리고 등록된 수를 보여주면 그 쪽으로 등록이 모이기 때문에. 등록된 수를 보여주는 방식은 확실히 데이터 추후 사용에 도움이 되는 것으로 보인다.)
- 일단 이는 사용자가 한 묶음으로 처리한 입력이기 때문에 데이터 사용 시 1묶음으로 특별한 경우가 아니라면 사용하면 될 듯하다.
space를 모두 '-'로 변경해서 저장하기
- 파편화된 데이터가 아닌 분류되어야 하는 데이터
- 해당 데이터를 기준으로 연결된 데이터가 존재하는 경우
space 가공 없이 저장
- 연결된 데이터 처리 없음
데이터의 흐름이 중요하고
소실된 데이터는 돌아오지 않고
가공하는데 시간이 많이 드는
데이터 세상에서
더 나은 방법으로 데이터를 재구성해
사람들에게 더 좋은 서비스를 제공하고 싶다 :)
