▼ 평소에 포스팅하는 것은 별 의식이 없어서 궁금하지도 않았는데 갑자기 호기심이 발동한 구글신도 모르는 이글루스 밸리 미리보기 글자수 한도.
EBC에 물어볼까 하다가, 기다리기도 답답해서 내가 직접 연구해 보기로 했어요.
※ 모든 그림은 클릭하면 원래 크기로 보임.
바쁘신 분들은 안 보고 밑에 요약만 보셔도 되는 삽질과정
보기▼ 실험1 작성. 국내 사이트로서 일반적인 euc-kr 인코딩은 한글을 2바이트로 표현하므로 일단. 일~구까지 아홉 글자를 쓰고 열번째 자리마다 ㄱ부터 ㅎ까지 순서대로 쓰는 걸로, 2바이트 문자를 총 140개 썼음.
▼ 실험1 밸리. 그랬더니 밸리에서 124자(248bytes)까지 노출. 그럼 1바이트 문자는 어떨까?
▼ 실험2 작성. 이번에는 1바이트문자인 숫자를 1~9까지 쓰고 열번째 자리마다 A부터 Z까지 순서대로 쓰는 걸로, 1바이트 문자를 총 260개 썼음.
▼ 실험2 밸리. 그랬더니 밸리에서 260자(260bytes) 전부 노출...어? 뭔가 이상한데? 아까보다 바이트 긴 거 아니었나? 뭔가 계산이 틀린 듯.
▼ 실험3 작성. 이번에는 실험2와 같은 방식으로 단지 분량을 늘려보았음. 영문자 26개를 모두 쓴 다음 이어서 자판 맨윗줄의 특수문자를 집어넣어서 총 370자. 밑에는 범례를 표기하기 위해, 370자 이후 개행문자를 썼죠.
▼ 실험3 밸리. 어? 개행문자 이전까지 쓴 370bytes가 모두 노출됐어요. 그리고 생략표시 ".." 앞에 공백문자가 있네요. 이건 개행문자를 썼기 때문에 여기서 노출이 끝났을 가능성도 없지 않음.
▼ 실험4 작성. 실험2와 실험3에 이어서 분량을 더 늘렸음. 390자를 씀.
▼ 실험4 밸리. 보시다시피, 밸리에서 전부 376bytes까지 노출. 역시 개행문자에 뭔가 있었던 거군요. 뭐야 그럼 개행문자가 혼자 6bytes라도 차지한단 말인가. 대체 왜 이래?
▼ 실험5 작성. 아무래도 한글과 영문자 바이트수 계산이 심하게 안 맞아서, 1바이트(라고 추정되는) 개행문자를 써 보기로 함. 보다시피 한 줄에 2바이트 9자와 개행문자 하나씩으로 총 열 줄을 썼고 마지막 줄은 개행문자를 쓰지 않았음.
▼ 실험5 밸리. 계산이 맞다면 189bytes. 물론 글자가 전부 나와도 이상하지 않음. 여기서 알고싶었던 것은 미리보기에서 개행문자가 어떻게 처리되느냐인데, 일단 겉보기로는 띄어쓰기와 동급으로 치는 것같네요.
▼ 실험6 작성. 이번엔 실험5의 확장판. 포스팅 안에도 직접 계산을 썼지만 이 때 기본적으로
두 어절인데 한글 9자와 띄어쓰기 두개로 한글 10자(20bytes)와 같다고 간주. 이걸 한 줄에 열 번씩 반복(200bytes)하고, 마지막은 띄어쓰기와 동등하게 처리되는 개행문자를 대신 써서 이걸 다섯 줄(1000bytes) 썼음. 끝에
≒1kb는 아무 의미 없는 장난이에요.
▼ 실험6 밸리. 보시다시피 밸리에 노출되는 건 259bytes. 역시 전혀 연관성을 찾을 수 없었네요. 수사는 다시 원점으로...
▼ 실험7 작성.
띄어쓰기에 뭔가 있는 걸까?하고 생각한 끝에 실험1과 같은 내용에 단순히 낱글자마다 1byte씩 공백을 넣어 봤어요.
▼ 실험7 밸리. 네... 공백문자 포함해서 291bytes 노출됐어요. 여기까지 확인한 뒤에 저는 뭔가 크게 잘못됐다는 것을 알았지요.
찾아보니 EBC에
RSS 인코딩 방식 UTF-8로 변경이라는 글이 있더군요. 날짜를 보니 헐, 2006년 1월 10일... 이면 제가 전라도 모 부대에서 눈삽들고 환장하던 시절이네요. 이걸 왜 몰랐을꼬... ㅇ<-ㄷ
이글루스가 현재
UTF-8 방식의 인코딩이라서 여태 한 삽질은 진짜 삽질로 판정.
영문자, 숫자 포함 아스키코드는 1byte가 맞지만, 한글은 3bytes거든요. ㅇ<-ㄷ 어째 계산이 전혀 안 맞는다 했더니 한글을 2bytes로 계산한 게 최대 실수였죠.아 난 진짜
euc-kr아니면
UHC인줄 알았음. 다시 해 보기로 했죠. 스샷에 일일이 끄적거린 게 죄다 틀렸기 때문에 무시하고 글자 수만 세어봤어요.
제대로 계산한 것
보기▼ 실험1의 밸리 노출 결과는 3bytes×124자 =
372bytes이죠.
실험2의 밸리 노출 결과는 잘리지 않았으니 필요 없고요. 굳이 쓰면 뭐 260bytes지만.
▼ 실험3의 밸리 노출 결과는 1byte×370자 +
2bytes(개행문자 두 개, 실험3의 작성중 스샷을 잘 보시길) =
372bytes이죠 이번에도. 스샷에는 띄어쓰기가 하나만 된 것처럼 나오죠? 웹문서에서는 보통 단순연속한 여러 개의 띄어쓰기를 하나로 보여주기 때문이에요.
▼ 실험4의 밸리 노출 결과는 1byte×376자 =
376bytes로군요. 오차범위라기엔 뭔가 더 있을 거 같네요.
실험5의 밸리 노출 결과는 역시 잘리지 않아서 필요 없지만 계산하자면 3bytes×90자 + 1byte(개행문자)×9 = 279bytes죠.
▼ 실험6의 밸리 노출 결과는, 한 단위가 3bytes×9자 + 1byte×2자(띄어쓰기, 개행문자) = 29bytes로, 열 덩어리가 한 줄에 있으니 290bytes가 됩니다. 다섯 줄이니 훨씬 넘지만.. 아무튼 잘린 부분까지 보면 290bytes(개행문자 포함한 한 줄) + 86bytes(마지막 띄어쓰기 제외된 세 덩어리) =
376bytes로군요.
▼ 실험7의 밸리 노출 결과는, 3bytes×97자 + 1byte(띄어쓰기)×97자 =
388bytes 어? 이건 좀 심하게 다르군요. 왜 이러는지 모르겠음.
세 줄 요약.
1) 이글루스는 UTF-8 인코딩을 사용하며, 밸리에 보내는 미리보기 텍스트도 마찬가지.
2) 밸리에 노출되는 미리보기 텍스트는 글의 앞부분 372bytes 또는 376bytes 또는 388bytes만큼을 잘라냄.
3) 왜 편차가 생기는지는 나도 몰라요.
유니코드에 대하여 참고할만한
쓰레드(번역문)
※ 모든 그림은 클릭하면 원래 크기로 보임.
덧글
UTF-8, UTF-16, UTF-32 등이 있는데, UTF-8은 웹에서 사용되는 인코딩 방식입니다.
아스키코드로는 전 세계에서 사용하는 모든 문자를 표현하는데 제한이 있고 각 나라에서 인코딩의 차이로 표현이 안되는 부분도 있어서 새로운 체계를 마련한 것이 유니코드 입니다.
UTF-8은 유니코드로 정의된 문자를 1바이트에서 4바이트까지 가변적으로 인코딩합니다. 즉, 유니코드가 가진 값에 따라 인코딩되는 바이트 수가 결정되는데요. 아스키코드에 해당하는 영문 문자는 1바이트이고, 한글, 중국어, 일본어와 같은 문자는 3바이트로 사용됩니다.
유니코드에 대한 친절한 설명 감사합니다만, 그것은 제가 포스팅 후반을 정리하면서 이미 확인한 사실입니다. 제가 궁금한 것은 세줄요약의 3번이죠 옙.
"UTF-8은 유니코드로 정의된 문자를 1바이트에서 4바이트까지 가변적으로 인코딩합니다."
그래서 편차가 생기는 것으로 추정됩니다.
저는 UTF-8이라는 방식이, "가변적인 바이트"를 사용하기는 하지만 "같은 문자열에 대해서는 같은 바이트를 사용"하는 것으로 이해했는데요.
네코님께서 말씀하신 대로 추정하기 위해서는 인코딩 방식이란 것이, 특정 문자열을 상황에 따라서 "상이한 바이트"수로 인코딩할 수도 있어야겠군요. 예컨대 "일"이라는 문자를 기본적으로 3bytes로 인코딩하게끔 정의하고 있지만, 때때로 4bytes가 될 수도 있다는 것인가요? 그렇다면 정말 이상한 방식이군요 ㄱ-;; 제가 뭔가 잘못 이해하고 있는지...
아마도 계산하다가 한글의 바이트가 나눠졌거나 해서 짤린부분을 같이 제외해서 오차가 생기는 것이 아닐까 하는 생각이 드네요.
직접 코딩해서 확인해보면 도움이 될 것 같지만, 저도 유니코드 체계를 공부하고 있는 입장이다보니 정확한 답변이 아닌 제 지식에 더한 추측으로만 답해드리는게 좀 죄송스럽네요.
초성, 중성, 종성의 경우 1바이트로 계산하셔야 될 겁니다.
마지막 이미지인 test7에서는 18bytes를 뺀 370bytes가 되긴 하는데...그럼 test1에서는 372bytes에서 24bytes를 뺀 348bytes가 되네요. 석연찮기는 여전하군요 ㅇ<-ㄷ
전 미리보기방지글을 봐도 그런가보다... 라고 넘깁니다.OTL....