전체 글143 UTF-8과 Base64: 두부 2글자가 6바이트, 8문자가 되는 이유 두부는 두 글자다. 그런데 UTF-8로 바꾸면 6바이트, Base64로 표현하면 65GQ67aA라는 8문자가 된다. 왜 길이가 달라지는지 브라우저에서 A·두부·두부!를 직접 넣어 확인했다.헷갈리기 쉬운 지점은 문자열 길이, UTF-8 바이트 길이, Base64 문자열 길이를 같은 단위처럼 보는 것이다.UTF-8과 Base64의 역할을 나눈 개념도. 실제 입력값은 두부다.두부를 Base64가 바로 바꾸는 것이 아니다. 먼저 문자열을 UTF-8 바이트로 만들고, Base64는 그 바이트를 ASCII 문자만으로 표현한다. UTF-8은 문자 인코딩이고 Base64는 binary-to-text 인코딩이다.2글자 → 6바이트 → Base64 8문자두의 UTF-8 바이트는 EB 91 90, 부는 EB B6 80이다... 2026. 10. 24. 이번 주 개발자가 손대야 할 공식 발표 3개: Node.js 10월 보안 릴리스, gh --expiring 토큰, Actions 허용 목록 표지: 10월 20~23일 공식 발표 중 로컬과 CI에서 바로 확인한 3가지를 한 장으로 묶었다.토요일 아침에 이번 주 Node.js 블로그와 GitHub Changelog를 훑다가 손이 멈췄다. Node.js가 10월 21일에 보안 릴리스를 냈고, 같은 주에 GitHub CLI 토큰 방식과 Actions 네트워크 허용 목록도 바뀌었다.처음에는 "공지 링크만 모아두고 다음 주에 보면 되겠지" 했다. 그런데 Node.js 공지를 읽다 보니 내 노트북에 깔린 버전들이 전부 영향 범위에 들어가 있었다. 그래서 이번 주는 뉴스를 요약하는 대신, 각 발표가 내 로컬과 CI에서 실제로 무엇을 바꾸는지 직접 돌려보고 정리해봤다.이번 주 결론1. Node.js 22·24·26을 쓰면 v22.23.4 / v24.22.1.. 2026. 10. 24. AI로 공지문 두 버전 비교하기: 사라진 문장을 폐지로 단정하지 않는 법 8명 초과 회의의 사전 승인 규칙이 폐지됩니다.AI로 공지문 두 버전을 잘못 대조하면 이런 안내문이 나올 수 있다. 하지만 새 공지에 8명 초과 문장이 없다는 사실만으로 규칙 폐지를 확정할 수는 없다.이 글은 코드를 쓰지 않는 운영·지원 담당자가 AI 텍스트 채팅으로 공지 두 버전을 비교하는 실습이다. 날짜, 대상, 조건을 원문 줄번호와 함께 정리하고, 문서만으로 확정할 수 없는 부분은 확인 질문으로 남긴다.두 공지는 공개 가능한 실습을 위해 만든 가상 자료다. 실제 회사 규정이 아니며, 아래 판정표와 안내문은 AI 실행 결과가 아니라 원문을 기준으로 편집자가 작성한 예시다. 특정 제품 화면이나 기능도 전제로 하지 않는다.비교할 공지 두 개를 먼저 붙여 넣는다새 텍스트 채팅을 열고, 아래 A와 B를 모두.. 2026. 10. 23. 커밋 직전 git diff --cached --check: 작업 파일을 고쳐도 공백 오류가 남는 이유 작업 파일(working tree)에서 줄 끝 공백을 지웠는데도, 다음 커밋에는 그 오류가 그대로 들어갈 수 있다. 작업 파일 수정과 스테이징된 사본(index) 수정은 같은 일이 아니기 때문이다. 새 로컬 합성 저장소에서 두 검사 명령을 실행해보니, 커밋 직전 확인할 대상은 git diff --check가 아니라 git diff --cached --check였다.파일을 고쳐도 스테이징된 사본은 그대로다Git 2.52.0의 새 임시 저장소에 기준 커밋을 만들었다. 줄 끝 공백(trailing whitespace)이 붙은 줄을 추가해 스테이징한 다음, 작업 폴더의 파일에서만 공백을 지웠다. 다시 git add하지 않은 상태다. 실제 회사 저장소나 업무 사건은 사용하지 않았다.이때 세 사본은 서로 다르다.H.. 2026. 10. 23. JSON.parse 후 큰 ID 끝자리가 바뀌어 404가 난 이유: MAX_SAFE_INTEGER와 id_str·BigInt 해법 표지 이미지. 서버가 보낸 ID 텍스트와 JSON.parse 뒤의 Number 값이 달라지는 흐름을 요약했다.목록 API에서 받은 주문을 눌렀는데 상세 화면이 404를 띄우는 상황을 재현해봤다. 서버 로그를 보니 클라이언트가 요청한 ID 끝자리가 ...475가 아니라 ...400이었다.처음에는 라우터가 경로 파라미터를 잘못 자르는 줄 알았다. 그런데 범인은 서버가 아니라 클라이언트의 JSON.parse였다. 2^53을 넘는 정수 ID를 JSON 숫자로 내려주면, 자바스크립트는 그걸 double로 반올림해서 들고 있다가 그대로 다시 보낸다.이 글은 Node.js와 Chrome에서 직접 돌려본 결과로 큰 ID 끝자리가 왜, 얼마나 바뀌는지, 그리고 문자열 ID(id_str)와 BigInt reviver 중 .. 2026. 10. 21. Cache-Control no-cache와 no-store 차이: 서버엔 304, fetch에선 200으로 보인 이유 표지: no-cache는 "저장하지 마"가 아니라 "쓰기 전에 물어봐"라는 뜻이다.목록 API 응답이 바뀌었는데 화면에는 예전 값이 남아 있다는 얘기를 듣고, 나는 처음에 Cache-Control: no-cache 한 줄이면 끝이라고 생각했다. 이름부터가 "캐시 없음"이니까.그런데 로컬에서 재현해 보니 서버 로그에는 304가 찍히는데, 브라우저의 fetch()는 계속 200을 돌려줬다. 캐시를 안 한다면서 304는 왜 오고, 304가 왔다면서 JS에서는 왜 200일까?이 글은 그 질문 하나를 따라간다. Node로 작은 서버를 띄우고 curl, Chrome의 fetch, Node의 fetch로 max-age, no-cache, no-store를 각각 두 번씩 불러서 서버까지 요청이 갔는지, ETag 재검증.. 2026. 10. 20. 이전 1 2 3 4 ··· 24 다음 반응형
