占쏙옙

오류로 생기는 문자열. 점쏙옙이라고도 부른다.

텍스트의 인코딩과 디코딩이 잘못됐을 때 생기는 것. UTF-8로 저장하는 과정에서 뭔가 꼬여서 온전하게 저장되지 못한 문서를 EUC-KR로 불러오면 이렇게 된다. 문서를 UTF-8로 저장할 때, UTF-8에서 유효하지 않은 byte sequence는 모두 �(U+FFFD, REPLACEMENT CHARACTER)로 대체되는데, 이 �는 UTF-8에서 EF BF BD라는 세 바이트로 저장된다. UTF-8에서 �가 두 번 붙은 ��는 EF BF BD / EF BF BD가 되는데, 이것을 EUC-KR로 해석하면 EF BF / BD EF / BF BD로 나눠지고 셋은 각각 '占', '쏙', '옙'에 대응된다. 이와 같이 UTF-8 문서 저장 과정에서 뭔가 잘못된 경우, 저장된 문서를 다시 열어보면 문서의 모든 내용이 占쏙옙으로만 채워져 있다. 불러올 대상이 이미 �로 깨져있어야만 일어나는 오류이기 때문에, 占쏙옙이 이미 일어난 상태에서는 뭔 짓을 해도 원래 나왔어야 할 문서는 못 본다.

어쨌든 데이터 저장 과정상의 오류이므로 웹에서 이 문제가 일어난다면 서버 측의 오류일 수도 있고, 클라이언트 측의 오류일수도 있다. 서버 상에서 한글 처리 오류가 발생해 입력받은 문서가 전부 �로 저장되거나, 업로드 시점에서 이미 데이터가 �로 깨져서 올라간 상태에서 사이트 기본 인코딩이 EUC-KR로 지정되어 있으면 이 문제가 일어나며, 반대로 서버와 서버 상의 데이터에는 문제가 없는데 클라이언트 상에서의 오류로 인해 서버에서 불러오는 한글이 전부 �로 깨져서 캐싱돼도 이 문제가 일어난다. 당연히 일부러 �로 깨진 페이지를 불러와서 인코딩을 EUC-KR로 강제 지정하면 맘껏(?) 감상할 수 있다.

바리에이션으로 占쌩쏙옙, 占싱깍옙, 占긍궔옙, 占쌀곤옙, 占싼깍옙, 占싱몌옙, 占쌉뤄옙, 占쌍듸옙, 占쌀븝옙, 占쌌니댐옙, 占싹시울옙, 占실심받아왔댐옙 뭘 받아? 등이 있으며, 여태까지 발견된 것 중 제일 긴 것은 '占쌩싱귐귤됐왔늡심받아왔니시왔늡싣왔늡심받아왔달앵억옙'(27자)이다. 종류가 다 적지 못할 정도로 많다. 占ㅆ~옙(내지는 占ㅅ~옙)하는 글자들은 전부 같은 원리로 생성된다. 참고로 ~옙 으로 끝나지 않는 것도 있으며 占썩본, 占썰구, 占싹기도, 占썩서, 占싫, 占쌍, 占썸남(...) 에러도 연애를 하나?등이 있다.

한때 이글루스에서 占쏙옙 때문에 대란을 겪은 적이 있으며, 요즘도 잊을 만하면 가끔씩 출몰한다.

자매품으로는 '竊잞폕'[1]과 '용습계품'[2]이 있다.

가끔씩 占쏙옙과 竊잞폕이 합쳐진 占竊잞폕옙(￯¼Ÿ？¿½) 이나 占쏙폕(�？) 혹은 竊잞옙(？�) 출현하는 경우가 있는데, 이 경우는 매우 드물다. 이건 ㅅ로 시작하지 않는데? 바이트 수도 맞지 않는다 퍼간 다음에 한번 더 깨진거지 뭐 사실 占쏙폕竊잞옙이다 카더라(�？？�가 깨진거다)

'占쏙옙'의 간체자판은 锟斤拷이며, 일본어판은 鐃緒申(EUC-JP), �ｿｽ(SHIFT-JIS)이다.

영미권 ISO/IEC 8859-1에서는 �으로 표시된다. UTF-8로 저장된 �의 EF, BF, BD 세 바이트가 ISO/IEC 8859-1에서는 각각 ï, ¿, ½에 대응되기 때문이다.

여기에 서술된 문자들은 EUC-KR 기준으로, 앞의 占과 뒤의 옙 사이에 이 문자가 걸렸다면 십중팔구 占쏙옙이라 봐도 된다.

앞에 占을 뺀 싊뿮뱦뺴쏙옙뭘 빼?도 있다.[6]