노무현 대통령 배너
BLOG main image
왕미친놈의 왕미친세상입니다. 미친 소리는 써도 되지만, 근거 없는 소리는 쓰면 안 됩니다.


최근 옛한글 관련 글을 자주 쓰게 되면서 뻔질나게 위키백과의 옛한글 문서를 참조하게 되었습니다. 그런데 파이어폭스에서 소스 보기를 한 뒤 그 소스를 복사하여 스프링노트에 붙여넣기를 하면 엉뚱하게 보였습니다. 물론 확인 결과 어느 쪽도 오류가 없었습니다. 가끔 이런 기가 막힌 경우가 발생하기는 합니다.

잘못도 벌레도 없으나…

스프링노트도 잘못이 없고, 파이어폭스도 잘못이 없습니다. 논리적으로 붙여넣기 기능은 클립보드의 데이터를 붙여넣는 기능일 뿐이니까요. 그 과정에서 기본 편집 모드에서는 위지위그 편집 방식을 사용하고, HTML 편집 모드에서는 텍스트 편집 방식을 사용합니다. 이 말은 곧 위지위그 편집 모드에서는 어떤 개체가 가지는 속성까지 함께 복사하며, HTML 편집 모드에서는 겉으로 드러난 텍스트 데이터만 복사한다는 뜻입니다.

한편 모질라 파이어폭스에서 보여주는 창은 (X)HTML 자료입니다. 심지어 이번에 문제가 된 소스보기 창도 (X)HTML 문서입니다.

확인을 위해 위키백과 :: 옛한글 문서에서 문자열을 선택하여 소스보기를 하였습니다.

소스 보기 화면

소스 보기 화면

이때 위의 소스 보기 화면은 텍스트 데이터에 색상을 입힌 것이 아니라, (X)HTML 데이터에 색상을 입힌 것입니다. 따라서 위 소스 보기 화면에서 전체 선택하여 복사한 뒤 스프링노트 편집모드(기본모드)에 붙여 넣기를 하면 아래와 같이 됩니다.

물론 아래와 같이 그 내용은 제대로 복사되어 있습니다. 다만 모양이 좋지 않을 뿐이죠.






겉으로 드러나지는 않았지만, 저 안에는 (X)HTML 코드가 숨겨져 있습니다. 이는 각자 위키백과에서 소스코드를 붙여넣기 한 다음에 HTML 편집 모드로 바꾸면 알 수 있습니다.
스프링노트를 쓰지 않더라도 티스토리 편집 창에서 HTML로 보기를 하면 역시 알 수 있습니다.

[code html] <pre id="line1">&lt;<span class="start-tag">span</span><span class="attribute-name"> class</span>=<span class="attribute-value">"jamocomposed_block" </span><span class="attribute-name">style</span>=<span class="attribute-value">"font-family: '돋움 옛한글','Dotum Old Hangul','바탕 옛한글','Batang Old Hangul','궁서 옛한글','Gungsuh Old Hangul','굴림 옛한글','NewGulim Old Hangul','은 자모 바탕 확장','Un Jamo Batang Ex','UnJamoBatangEx','은 자모 바탕','Un Jamo Batang','UnJamoBatang','은 바탕','Un Batang','UnBatang',Code2002,Code2001,Code2000,serif; font-size: 105%;"</span>&gt;나랏말ᄊᆞ미 듀ᇰ귁에 달아 문ᄍᆞᆼ와로 서르 ᄉᆞᄆᆞᆺ디 아니ᄒᆞᆯᄊᆡ&lt;/<span class="end-tag">span</span>&gt;</pre> [/code]

그렇습니다. 위의 코드를 보면 <pre id="line1"> 태그로 열고 </pre> 태그로 닫았습니다.

뭐, 정확한 기술적인 내용은 저도 모르니, 그냥 저렇게 (X)HTML 코드로 나타내고 있다고만 말하겠습니다. 어쨌든 스프링노트의 편집모드에서는 파이어폭스의 소스 보기 화면이 위와 같은 (X)HTML 코드로 이루어져 있으므로, 그것을 존중하여 아주 잘 나타낸 셈입니다.

물론 사용자가 보기에는 엉뚱해 보이고, 더구나 버그가 아닌가 의심스럽지만, 절대 버그는 아닙니다.

응급 처치

일단 이 현상에 대해 파이어폭스에서 해결책을 내놓지는 않으리라 생각합니다. 넷스케이프 내비게이터가 만들어졌을 때부터 고수한 방식을 지금에 와서 바꾸라고 한다면 그들은 거부할 것이 뻔하기 때문입니다. 그것도 다 바꾸는 게 아니라 특정한 상황만 고려해서 바꾸라고 한다면 "일관성이 없으므로" 무시하게 될 터입니다. 결국 편법을 쓰는 수밖에 없습니다.

아무튼 해결책은 아주 간단합니다. 다른 편집기로 복사하여 붙여넣기를 한 뒤 다시 복사하여 스프링노트로 붙여넣기를 하면 됩니다.

앞의 소스 보기 화면에서 전체를 복사하여 메모장에 붙여넣습니다.

메모장에 붙여넣기를 한 소스 코드

메모장에 붙여넣기를 한 소스 코드

위와 같은 소스 코드는 겉보기에는, 색상을 제외하면, 소스 보기 화면과 다른 점이 없습니다. 그러나 붙여넣기를 하면 다음 그림과 같이 됩니다.

위 그림을 (X)HTML 코드로 나타내면 다음과 같습니다.

[code html] 나랏말ᄊᆞ미 듀ᇰ귁에 달아 문ᄍᆞᆼ와로 서르 ᄉᆞᄆᆞᆺ디 아니ᄒᆞᆯᄊᆡ [/code]

앞서 보았던 코드와는 상당히 다른 모습을 보여주고 있습니다. 또한 소스 보기 화면에서 본 그 코드로서, 사용자가 복사하기를 바랐던 그 코드이기도 합니다.

원리

앞서 설명한 바와 같이 파이어폭스의 소스 보기 창의 내용은 (X)HTML 코드로 이루어져 있습니다. 이것을 그대로 스프링노트에 붙여넣기를 하면 그 이면에 감추어진 (X)HTML 코드까지 붙여넣게 되므로, 중간 단계를 두어 감추어진 (X)HTML 코드를 없애 버렸을 뿐입니다.

참고로 이렇게 (X)HTML 코드를 없애어 텍스트만 뽑아내는 것을 스트립 또는 (X)HTML 코드 스트립이라고 합니다.[각주:1]

덧붙이며

파이어폭스 소스 보기 창이 (X)HTML 문서인지 아닌지를 알려면, 가장 간단한 방법으로 찾기를 실행해 보면 됩니다. 단축키는 Ctrl+F입니다. 만약 파이어폭스이 일반 화면과 같이 (X)HTML 자료로 구성되어 있다면 찾기 기능을 위한 납작한 창이 맨 아래에 생길 테니까요.

위 그림에서 보면 찾기 창이 맨 아래에 생겨 있습니다.

위 그림에서 보면 찾기 창이 맨 아래에 생겨 있습니다.

관련 문서

내부 문서

(없음)

외부 문서

이 글은 스프링노트에서 작성되었습니다.

  1. 덧붙여서 전기 코드 벗기는 것도 스트립이고, 옷 벗기는 것도 스트립입니다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

요즘 열심히 옛한글 관련 포스팅을 하고 있습니다. 일단 한글과컴퓨터한컴오피스2010 베타버전 때문에 더 열심히 하고 있지요. 그런데 제가 ᄒᆞᆫ글이라는 이름을 꼭 제대로 나타내고 싶어하기 때문에 문제가 발생하고 있습니다. 적당히 포기하면 편할 텐데 말입니다. 제가 사소한 데 목숨을 거는 스타일이라서 말입니다. 물론 이 글의 제목에서는 다음뷰만 거론했지만, 다음뷰의 상황이 가장 나쁘기 때문이지 다른 사이트도 별로 다르지 않습니다.

ᄒᆞᆫ글 (안 보이시나요? 아래 자주색 그림처럼 보여야 옳습니다.)
이렇게 보여야 옳습니다.(이렇게 보여야 옳습니다.)
이렇게 보이면 안 됩니다.(이렇게 보이면 안 됩니다.)

벌레의 유형

대부분의 사이트에서 발생하는 벌레입니다. 벌레라기보다는 무사안일한 태도 때문이라고 생각합니다. 블로그 서비스를 이용하는 사람은 그 목적이 매우 다양하여, 화학식, 물리학이나 수학의 수식, 언어학의 음성 기호, 한국어의 옛한글 등도 블로그에서 표현하려고 들 것입니다. 그런데 서비스를 제공하는 측에서 그러한 다양한 요구가 생기리라는 것을 예측하지 못하고 평범한 환경만을 대상으로 블로그 서비스 및 메타블로그 서비스를 기획, 개발했기 때문에 벌어진 일입니다.

게다가 블로그 가운데 유니코드(utf-8)를 쓰는 블로그도 많은데, 메타블로그가 유니코드가 아닌 euc-kr과 같은 코드를 쓴다면? 당장 그 메타블로그가 표현해줄 수 있는 문자 수가 확 줄어들게 된다. 어처구니없게도 여러 블로그를 아우르게 되는 메타블로그가 블로그보다 더 표현력이 떨어지는 이상한 현상이 발생하게 되는 것이다.

개발자의 답변

  • 다음 뷰에는 2010년 1월 1일 버그 리포팅을 한 상태입니다. 메타블로그임에도 비슷하게도 나타내지 못하고 있습니다.
  • 스프링노트에는 2009년 12월 31일 기능 제안(옛한글 입력 및 출력)한 상태입니다.
  • 티스토리에는 2010년 1월 1일 제안(글꼴 정보 추가 요청)한 상태입니다.
  • mixsh에는 2010년 1월 1일 제안(글꼴 정보 추가 요청)한 상태입니다.

벌레의 발견

응?! ???글 씨? 저거 또 무엇인고?

응?! 다음뷰 온 박스에 쓰인 ???글 씨? 저거 또 무엇인고?

위에서 view on 박스를 보면 조금 문제가 심각합니다. 다른 경우는 ㅎ.ㄴ 처럼 보이는데 저것은 아예 ???라고 나타납니다. 혹시나 하는 마음에 다음뷰도 살펴보았습니다.

다음뷰에서도 ???로 나타내고 있습니다.

다음뷰에서도 ???로 나타내고 있습니다.

아, 글씨, 도대체 이게 어찌된 일일까요? 아무튼 조금 난감한 경우입니다.

mixsh에서도 엉뚱하게 나타납니다. 그래도 대강은 알아볼 수 있겠네요.

mixsh에서도 엉뚱하게 나타납니다. 그래도 대강은 알아볼 수 있겠네요.

mixsh(믹시)는 그저 글꼴 정보가 지정되지 않았기 때문에 발생한 문제입니다.

티스토리 블로그 제목 : 이건 사용자가 글꼴을 지정할 수 있습니다.

티스토리 블로그 제목 : 이건 사용자가 글꼴을 지정할 수 있습니다.

위의 그림에 나타난 티스토리 블로그게시물 제목은 사용자가 글꼴을 지정할 수 있습니다. 현재 귀찮아서 안 하고 있습니다. 또한 어느 정도 사람들이 "왜 나타낼 수 없지?" 또는 "왜 저렇게 이상하게 나타나지?"라는 생각을 어느 정도 할 때까지(적어도 댓글에다가 "항의"를 적을 때까지) 그냥 둘까도 생각했습니다만, 조만간 고쳐야겠습니다.

티스토리 관리 화면. 이건 티스토리에서 해 주어야 합니다.

티스토리 관리 화면. 이건 티스토리에서 해 주어야 합니다.

티스토리 관리 화면에 관해서는 이미 제안한 상태입니다.

스프링노트. 정확하게 나와 있죠? (자주색 동그라미 부분)

스프링노트. 정확하게 나와 있죠? (자주색 동그라미 부분)

스프링노트 화면에서는 정확하게 나타내고 있습니다. 하지만 기본 기능이 아니라 HTML 모드를 사용하여 직접 HTML 태그를 입력하였습니다. 이렇게 직접 입력하는 방식은 티스토리 블로그 제목에서도 통용될 수 있습니다. 아무튼 옛한글의 입력과 출력을 스프링노트에 제안한 상태입니다.

벌레의 원인

앞서 말했듯이 이런 벌레가 생긴 까닭은 개발자나 기획자의 무사안일함 때문이라고 생각합니다.

옛한글을 전혀 사용하지 않을 로마자 문화권도 아닌데, 좀 더 넓은 안목에서 옛한글도 표현할 수 있게 지원하면 좀 좋겠습니까?

비슷한 벌레

화면 표시와 관련한 버그로는 V3 계열 백신의 폴더 경로명 표기 벌레와 ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?가 있습니다.

관련 문서

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

여러분! 고맙습니다.

2009년이 가고 2010년 새해가 되었습니다. 제 블로그에 와 주신 분들께 감사드립니다.

우선 1년 방문객 수를 5천 명으로 잡았는데, 2009년에 5만 명이 오셨습니다. 2009년 2월 27일부터였으니까, 거의 10개월 동안 5만 명이 오신 것이죠. 특히 12월은 최초로 1개월 방문객이 7000명(7024명)을 돌파했고, 12월 31일은 최초로 1일 방문객이 400명(405명)을 돌파했습니다. 올해는 조심스럽게 7만5천 명을 목표로 잡아 봅니다.

아쉬운 점은 배치파일에 대한 강좌를 끝마치지 못했다는 점입니다. 정리되는 대로 다시 시작하겠습니다. 시작했으니 끝이 있어야 하지 않겠습니까? 반드시 끝내겠습니다.

버그 리포팅은 그 수가 많았습니다. 156개 글 가운데, 34개가 버그 리포팅입니다. 11월까지의 버그 리포팅 내역은 2009년을 빛낸 진짜 버그를 참조하시기 바랍니다.

팁은 버그를 찾거나 발견하는 과정에서 생겨난 결과물입니다. 그래서 따로 목록을 만들지는 않았습니다. 불편하시더라도 검색이나 카테고리(분류)를 애용해 주십시오.

게임의 파천일검은 하도 쥐마왕[각주:1]의 횡포가 심해져서 재미삼아서 써봤습니다. 20레벨까지의 퀘스트를 올려야 하는데, 왠지 안 써지네요.

스크린샷

1일 방문객 400명 돌파!

1일 방문객 400명 돌파!


1일 방문객 400명 돌파! - 파이어폭스 부분만 잡은 화면.

1일 방문객 400명 돌파! - 파이어폭스 부분만 잡은 화면.


연 방문객 5만 명, 월 방문객 7천 명

연 방문객 5만 명, 월 방문객 7천 명

사실 남들에게는 아무것도 아닌 일일는지도 모릅니다. 하지만 저는 무지하게 기쁘군요.

 

아무튼 앞으로도 더 열심히 글 올리겠습니다.
여러분! 새배 복 많이 받으세요.
왕미친놈(koc/SALM) 올림

이 글은 스프링노트에서 작성되었습니다.


  1. 쥐마왕이 누구인지 아는 사람은 다 압니다. [본문으로]

'일기' 카테고리의 다른 글

한컴오피스2010 오픈베타 이벤트 당첨!!  (2) 2010.01.23
난 판도라 상자를 열었을까?  (0) 2010.01.02
새로운 블로그 개설에 대하여  (2) 2009.12.09
청각장애인과 휴대폰  (0) 2009.12.06
청각장애인과 휴대폰  (2) 2009.12.06
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

나는 스프링노트를 블로그에 올릴 글의 초안을 작성하려고 자주 사용합니다. 그래서인지 거의 하루에 한 번 이상은 접속하게 되죠. 자주 쓰니 그만큼 오류도 자주 접하는 편이고, 버그 리포팅도 자주 하였습니다. 그런데 이번에 발견한 벌레는 좀 난감하게 만들더군요.

  • 참고 1 : 혹시라도 이 벌레를 재현하고 싶은 사람은, 이 벌레는 일단 글을 블로그로 보내 버리면 다시 발견할 수 없으므로, 반드시 아직 블로그로 보내지 않은 글에서 시험하셔야 합니다.
  • 참고 2 : 이 벌레는 파이어폭스 v3.5.6 버전에서 확인, 부가기능이 없는 안전모드에서도 확인, 집이 아닌 PC방에 파이어폭스를 설치한 뒤에도 확인하였습니다. 다만 다른 버전에서는 확인하지 못했습니다.

벌레의 유형

목록을 다시 읽으라고 새로고침을 시키니까 이미 읽어온 목록까지 감추는 이상한 벌레입니다.

개발자의 답변

2009년 12월 31일 버그 리포팅을 한 상태입니다.

벌레의 발견

이 벌레는 며칠 전 티스토리 블로그에 글을 올리려다 발견하였습니다. 그때 티스토리에 새로운 카테고리(분류)를 만든 뒤였기에 새로운 분류에 글을 올려야 했습니다. 그런데 분류가 나타나지 않더군요. 일시적인 장애인지, 버그인지 알 수 없었지만, 재현이 불가능했기에 버그가 아닌 일시적인 장애라고 판단했습니다. 아무튼 여기에서 말하는 벌레와는 관련이 그다지 없습니다.

[블로그로 보내기] 항목을 클릭

[블로그로 보내기] 항목을 클릭

블로그로 보내기 대화상자가 나타난 화면

블로그로 보내기 대화상자가 나타난 화면

블로그로 보내기 대화상자

블로그로 보내기 대화상자

위와 같은 블로그로 보내기 대화상자가 나타나면 카테고리 콤보박스 옆의 새로고침을 클릭한다. 이때 기대할 수 있는 동작은 카테고리 콤보박스에서 목록이 갱신되는 것이다. 그런데...

사라져버린 카테고리와 공개 설정

사라져버린 카테고리와 공개 설정

카테고리 콤보박스공개설정 옵션버튼이 사라져버렸다. 남은 것은 종류 콤보박스뿐. 이때 내보내기 단추를 클릭하면, 선택한 블로그아무 카테고리도 없이, 공개설정은 발행안함으로 등록된다. 그나마 이 작동방식은 마음에 든다. 실수로 내보내기를 했는데, 공개함으로 설정되었다면 엄청 난감했을 수도 있기 때문이다.

벌레의 원인

새로고침이라는 작업은 다음과 같은 절차를 거쳐 수행한다.

  1. 일단 현재 가진 목록을 없애거나 한쪽에 치워둔다. 대개는 현재 목록을 없애지만, 복원할 일이 필요하다면 한쪽으로 옮겨두기도 한다.
  2. 목록을 다시 읽어온다.

그런데 이번에 나타난 벌레는 아마도 다음과 같이 동작하는 듯싶다.

  1. 일단 현재 가진 목록을 지운다.
  2. 그 뒤 카테고리와 공개 설정에 대한 내용을 지운다.
  3. 대화상자를 다시 그린다.

위와 같은 원인이 아닌 다른 원인일 수도 있다. 이것은 어디까지나 내 추측일 뿐이다.

비슷한 벌레

아직 없습니다.

관련 문서

내부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

2009년 한 해 동안 소개한 버그 가운데 실제로는 버그(또는 오류)가 아니었거나, 이미 수정된 버그 등이 있는지를 살펴보았다. 기간은 2009년 3월부터 11월 30일까지입니다. 12월은 내년으로 넘겨야 할 듯합니다.,

  1. 2009/11/29 스프링노트 : 문자 인코딩 관련 사항 : 관점에 따라 버그일 수도 있고 아닐 수도 있다.
  2. 2009/11/27 티스토리 BBCode 오류 : 제작자가 수정하는 중이라는 답변을 받았다. 아직 고쳐지지 않았다.
  3. 2009/11/03 스프링노트 : 첨부파일 대화상자의 옵션 가리기 벌레 : 개발자에게 전달하겠다는 답변을 받았다. 아직 고쳐지지 않았다.
  4. 2009/11/02 한/글/ 2007에서 나타난 구결 표기 오류 2 : 이 사항은 버그가 아니다. 내가 잘못 알았다.
  5. 2009/10/30 한/글/ 2007에서 나타난 구결 표기 오류 1 : 이 사항은 버그가 아니다. 내가 잘못 알았다.
  6. 2009/06/18 광고인가? 사기인가? : 광고 문구를 교묘히 조작하여 클릭을 유도한다. 구글 광고와는 다른 사기성 광고
  7. 2009/05/30 티스토리 주석에서 \ 문자 표기 문제 : 출력 과정에서 정확히 나타나지 않는 버그이다. 아직 고쳐지지 않았다.
  8. 2009/05/28 티스토리에서 주석이 제대로 인식되지 않는 현상 : 출력 과정에서 정확히 나타나지 않는 버그이다. 아직 고쳐지지 않았다.
  9. 2009/05/16 아크로에디트 : 배치파일 주석 문법 강조 기능 : 잘 고쳐져 있다.
  10. 2009/05/15 스프링노트 : 공개 및 비공개 설정에서 이상한 점 : 잘 고쳐져 있다.
  11. 2009/05/14 스프링노트 : 일부 글자 속성이 제대로 지정되지 않는 벌레 : 일부는 고쳐졌으나, 일부는 고쳐지지 않았다.
  12. 2009/05/10 버추얼박스 v2.2.2 설치 오류 : 한글 경로명 문제 : 최신 버전인 VirtualBox v3.1.0 빌드55467 (윈도 버전)에서도 고쳐지지 않았다. 이는 단순히 설치 프로그램의 문제이며, 프로그램 실행에는 아무런 영향도 없습니다.
  13. 2009/04/28 V3 계열 백신의 폴더 경로명 표기 벌레 : 고쳐지지 않았다.
  14. 2009/04/27 스프링노트의 링크 편집 벌레 : 잘 고쳐져 있다.
  15. 2009/04/26 스프링노트의 태그 표기 벌레 : 잘 고쳐져 있다.
  16. 2009/04/11 버추얼박스 2.2.0 네트워크 접속 문제 : 후속 버전에서 잘 고쳐져 있다.
  17. 2009/04/07 네이버 결계 벌레 : 현재 전혀 나아지지 않았다. 여전히 내 네이버 블로그에서 그림 파일을 불러올 수 없다.
  18. 2009/04/05 네이버 뻥튀기 벌레 : 현재 전혀 나아지지 않았다. 여전히 내 네이버 블로그에서 그림 파일을 불러올 수 없다.
  19. 2009/03/31 벌레 잡는 알약, 벌레에 먹히다 2 : 확인하지 않음.
  20. 2009/03/30 티스토리 파일 첨부 창 잘라먹기 : 잘 고쳐져 있다.
  21. 2009/03/27 벌레 잡는 알약, 벌레에 먹히다 : 확인하지 않음.
  22. 2009/03/27 네이버의 나눔고딕코딩 선문자 오류 : 선문자를 정확히 표시해 준다.
  23. 2009/03/26 아크로에디트 구문 강조 오류 : 일부는 고쳐졌지만, 일부(예컨대 @의 처리)는 고쳐지지 않았다.
  24. 2009/03/26 Offree.net에서 발견한 이상한 점 : 사이트의 문제가 아니라 IE와 파이어폭스의 문제였다.
  25. 2009/03/21 한/글/ 2005에 나타난 구결 표기 오류 : 이 사항은 버그가 아니다. 내가 잘못 알았다.
  26. 2009/03/21 티스토리 그림 파일 업로드 벌레 : 티스토리에서 수정해 주었다.

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

스프링노트에서 작성한 글을 블로그에 게시하고 나면 가끔 물음표(?)로 바뀌는 일이 있다. 처음에는 내가 유니코드KS X 1001(흔히 KS C 5601로 불린다.) 코드에 들어 있지 않은 코드를 게시한 것으로 여겼다. UTF-8 표기법으로 나타낼 수 없는 문자를 U+003F(?, 물음표)나 U+FFFD(�, 유니코드 대치 문자)로 치환하는 것은 UTF-8에서의 오류 처리이기 때문이다. 그러다가 스프링노트 측에서 또는 티스토리 측에서 잘못 게시했을 수도 있다는 생각을 갖게 되었다.

벌레의 유형

  • 벌레인지 아닌지 알 수 없었다. 이 사례는 보는 관점에 따라서는 버그일 수도 있고 아닐 수도 있다.

벌레의 발견

지난 11월 18일 알까기 1 - 알툴즈 까기 문서를 작성하다가 뮤토런트의 로마자 이름(μTorrent)이 화면에 잘못 나타나고 있음을 보고 혹시나 하는 생각을 갖게 되었다. 그에 앞서 11월 2일 한/글/ 2007에서 나타난 구결 표기 오류 2 문서에 엄(厂)과 엄(广)을 입력하다가 발견하였다. 현재 그 문서는 글자가 깨진 상태로 놔두었다.

Character-Encoding-00.png
자료 화면. 문자 인코딩이 제대로 되지 않았다.

문제가 발생하는 경우

지금까지 문제가 발생한 경우는 다음과 같다.

  • 자주 쓰지 않는 한자 : 한중일 통합 영역의 한자 가운데 (1) 특정 언어 윈도에서만 정확하게 보이는 한자, (2) 기본 다국어 평면(BMP)의 U+4E00부터 U+9FA5까지의 영역에 포함되지 않는 한자는 제대로 보이지 않는 경우가 있다.
  • 자주 쓰지 않는 로마자 : 영문자는 잘 나타내 준다. 숫자도 잘 나타내 준다. 꺽쇠(< >)도 잘 나타내 준다.[각주:1] 다만 그리스 문자나 키릴 문자 등은 가끔 정확히 표현하지 못한다. 뮤토런트에서 깨진 문자도 그리스 문자이다.
  • 특별한 구문부호가 붙은 로마자 및 기호 : 움라우트 등이 붙은 문자나 기호 등에서 가끔 깨진다.

문제 해결책

크게 두 가지 해결책이 있다. 우선 특별한 구문부호가 붙은 로마자나 기호는 글자 엔티티(character entity)로 나타내면 된다는 점이다. 그 다음으로 자주 쓰이지 않는 한자는 HTML 참조 코드를 이용하는 쪽이 낫다는 점이다.

  • 글자 엔티티 이용 : © 기호를 나타내고 싶다면 &copy; 라고 표현하면 된다.
  • HTML 참조 코드 : © 기호를 나타내고 싶다면 &#x00A9; 라고 16진수로 표현하거나, &#169; 라고 십진수로 표현하면 된다.

관련 문서

이 글은 스프링노트에서 작성되었습니다.


  1. 이것은 글자 엔티티(character entity)로써 나타내 주고 있다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

지난 10월 30일 스프링노트에서 글을 작성하다가 발견한 벌레이다. 웹사이트에 GFDL로 공개된 그림을 불러와서 스프링노트에 저장(외부 이미지를 스프링노트에 저장 옵션)을 지정하려고 했는데, 그만 미리보기에서 그 옵션을 가리는 일이 벌어졌다. 다행히 재현이 가능하여 몇 차례 더 확인하여 지금에야 올린다.

  • 참고 : 이 현상은 파이어폭스 v3.5.4 (2009년 11월 3일 현재 최신 버전)에서 확인하였습니다.

벌레의 유형

  • 파이어폭스를 사용할 때 나 혼자만 잘나면 되고 다른 놈은 제 역할도 못하게 만드는 이기적인 벌레이다.

벌레의 발견

지난 10월 30일 스프링노트에서 글을 작성하다가 외부 이미지를 불러오면서 발견한 벌레이다.

조금 옆으로 퍼진 스프링노트 화면

조금 옆으로 퍼진 스프링노트 화면

내가 자료화면으로 제시하는 800x600 화면으로는 삽입 메뉴와 부가기능 메뉴를 제대로 보여줄 수 없어서 너비를 920픽셀로 조정했다. 아울러 이미지 불러오기를 할 때 이미지 미리보기 기능을 켰을 때 위아래로 가리는 현상을 막기 위해 높이도 720픽셀로 조정했다. 이 현상은 버그가 아니라고 여겨지니 오해 없기를 바랍니다.

이미지 첨부 대화상자

위 그림에서 외부 URL로 첨부하기를 클릭한다.

외부 URL로 첨부하기

외부 URL로 첨부하기

위의 그림이 화면에 나타났을 때 미리보기를 클릭하였다.

불러올 그림 미리보기 화면

불러올 그림 미리보기 화면

위와 같이 미리보기 화면 아래쪽에 대화상자의 다른 내용을 가리는 글을 볼 수 있다. 문제가 되는 부분만 떼어내면 아래와 같다.

위 그림에서 왼쪽 체크박스오른쪽 [삽입] 단추를 가리는 것은 아래와 같은 저작권 보호를 위한 글귀이다.

특히 왼쪽의 체크박스는 잘 클릭이 되지 않아도 가려져서 그런가 보다 생각했지만, 오른쪽은 조금 의외였다. 글씨가 옅은 색이라 가려진 모습이 잘 보이지 않았기 때문이다. 결국 확대해 보니 "삽"자까지는 가려져 있고, "입"자도 일부 가려져 있었다. 처음에 이것을 눈치채지 못한 까닭은 내가 "입"자보다 오른쪽을 클릭했기 때문이리라 추측한다.

해결하기

이 문제에 대한 완전한 해결은 스프링노트 측에서 수정해 주는 방법뿐이다. 다만 그 이전까지 임시로 쓸 수 있는 방법은 그저 사용자가 주의하는 것이다.

우선 이미지 첨부 대화상자를 부른다.

위의 그림에서 자주색 네모로 표시한 부분을 잘 보자. 왼쪽 체크박스에 체크 기호가 되어 있다. 이것을 먼저 체크한 다음에 [미리보기] 단추를 클릭하자.

체크박스가 유지된 화면

체크박스가 유지된 화면

먼저 체크박스를 표시하면 위와 같이 그 체크 기호가 유지된다. 다만 이때 [삽입] 단추의 일부를 가리는 현상은 어쩔 수 없다. 앞서 말했듯이 스프링노트 개발진에서 수정해 주어야 할 부분이기 때문이다.

제작자/제공자의 답변

2009년 11월 3일 오류를 보고한 상태이다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

티스토리에 주석을 달면 가끔 한 글자씩 빼먹고 나타내는 경우가 있다. 특히 \ 문자(역슬래시)를 나타낼 때 항상 한 글자씩 빼먹고 나타낸다.

벌레의 유형

  • 덧셈을 못하는 벌레이다.
  • 그게 아니라면 자신의 본문을 화면 표시가 아니라 나눗셈으로 착각하는 벌레이다.

벌레의 발견

우연히 주석에 하드디스크 파일의 경로를 나타내다가 발견하였다.
이것은 스프링노트에서 [footnote] 표시를 붙여 나타내어도 나타나면, 티스토리에서 주석을 붙여도 나타났다.

벌레 분석

우선 편집 화면을 보면 다음과 같다.

티스토리 글쓰기(편집) 화면

티스토리 글쓰기(편집) 화면

위에서 보면 각주 부분에 어떤 파일의 경로가 있다. 파일 경로이므로 \ 문자(역슬래시 문자)가 들어가야 한다. 그 부분만 따로 떼면 다음과 같다.

위와 같이 입력했다. 다만 알아보기 쉽게 \ 문자를 자주색으로 나타냈으며, 실제로는 티스토리 글쓰기(편집) 화면처럼 모두 검은색이다.

미리보기를 하면 다음과 같다.

주석(각주)에서 \ 문자(역슬래시)를 나타내는 예제 미리보기

주석(각주)에서 \ 문자(역슬래시)를 나타내는 예제 미리보기

그런데 위에서 보면 조금 이상한 부분이 있다. 일단 그 부분만 떼어 보자.

\ 문자(역슬래시 문자)가 전혀 나타나지 않는 각주 부분

\ 문자(역슬래시 문자)가 전혀 나타나지 않는 각주 부분

무슨 까닭에서인지 \ 문자(역슬래시 문자)를 전혀 나타내지 못하고 있다.

벌레 잡기

내 짧은 지식으로 생각건대, 이것은 C 언어에서 문자열을 나타낼 때와 비슷한 현상이다. 다시 말해 C언어에서 printf 함수로 문자열을 출력할 때 \ 문자를 나타내려면 \ 문자를 1회 입력하면 안 된다. 반드시 2회, 그러니까 \\ 처럼 2회 입력해야 \ 문자를 1회 출력해 준다.

문제는 왜 이렇게 복잡한 방법으로 입력하게 만들었느냐이다. 이런 방식은 컴퓨터를 익숙지 않거나, 컴퓨터 언어(C 언어, 또는 자바스크립트 언어)를 전혀 모르는 사람에게는 꽤 큰 불편을 불러오는 악성 벌레이기 때문이다.

아무튼 이 문제를 해결하려면 \ 문자를 2회 겹쳐서 표기하면 된다.

\ 문자(역슬래시)를 2회 입력한 편집 화면

\ 문자(역슬래시)를 2회 입력한 편집 화면

각주(주석) 부분만 떼어 내면 위와 같다.

미리보기를 하면 아래와 같다.

주석 부분에 파일 경로명이 제대로 나타난 미리보기 화면

주석 부분에 파일 경로명이 제대로 나타난 미리보기 화면

제작자/제공자의 답변

2009년 5월 30일 아침에 오류 보고했다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

나는 스프링노트에서 글을 작성하여 티스토리에 글을 올리고 있다. 그런데 가끔 엉뚱한 현상을 보이는 일이 생기곤 한다. 바로 주석[각주:1]의 화면 표시에 대한 문제이다.

벌레의 유형

자기 본모습을 헷갈려하는 벌레이다.

벌레의 발견

[벌레와 팁] - ISO/UDF 이미지 파일 보기 및 풀기 1 문서에서 이상한 현상을 발견하였다. 백 번 듣기보다 한 번 보는 것이 낫다.

주석(각주) 표지가 그대로 드러나는 화면

주석(각주) 표지가 그대로 드러나는 화면

위 그림에서 없어서Tistory-X-Footnote-0.png 라는 부분이 그것이다. 주석 표시인 Tistory-X-Footnote-0.png은 원래 편집 화면에서만 보이고, 웹에 게시한 뒤에는 주석의 실제 내용으로 치환되어야 한다. 또한 Tistory-X-Footnote-0.png 표시 대신에 주석을 나타내는 수가 나타나야 한다.

그러나 주석(각주)은 어디에도 보이지 않는다.

그러나 주석(각주)은 어디에도 보이지 않는다.

위와 같이 보이며 애써 작성한 각주는 나타나지 않는다. 정상 작동할 때는 아래와 같다.

정상 표시되는 주석(각주)

정상 표시되는 주석(각주)

위 그림에서 Tistory-X-Footnote-1.png 부분이 정상적으로 나타난 주석이며, 그 아래에 주석의 실제 내용이 나타나 있다.

벌레 분석

이것은 스프링노트에서 티스토리의 주석을 나타내 주지 못해서 아래 그림처럼 입력하는 일과 관련이 있어 보인다.

스프링노트에서 티스토리의 주석을 표시하는 방법

스프링노트에서 티스토리의 주석을 표시하는 방법

다시 말해 위 그림처럼 [footnote] 치환자를 직접 입력하고 있어서 당장은 문제가 없어도 나중에 문제가 생긴다고 볼 수 있다. 이것을 따로 떼면 아래와 같다.

빨강 네모로 표시한 부분이 주석을 입력한 부분이다.

빨강 네모로 표시한 부분이 주석을 입력한 부분이다.

그러나 티스토리에 게시/출판하였을 때 편집창에서 나타나는 HTML 코드는 스프링노드에서 [footnote]를 수동으로 입력했을 때나, 티스토리에서 주석(각주) 기능을 이용해서 달았을 때나 같다.

주석 표시에서 오류가 났을 때의 편집화면의 HTML 모드

주석 표시에서 오류가 났을 때의 편집화면의 HTML 모드

문제가 생긴 주석 표시 부분 (파란색 네모 부분)

문제가 생긴 주석 표시 부분 (파란색 네모 부분)

위 그림에 보면 footnote 부분에 조금 특별함이 있기는 하다. 그렇다고 이것이 주석을 잘못 나타내는 이유로 보기는 힘들다.

주석 표시를 정상적으로 했을 때의 편집화면의 HTML 모드

주석 표시를 정상적으로 했을 때의 편집화면의 HTML 모드

비교하기 위해 잘라낸 주석 표시 부분 (파란색 네모 부분)

비교하기 위해 잘라낸 주석 표시 부분 (파란색 네모 부분)

정상적으로 보일 때도 오류가 났을 때와 같은 방식으로 편집창에는 나타난다.

벌레 잡기

이 벌레를 잡기 위해서는 특별한 방법이 없다. 그저 주석이 정상적으로 표시될 때까지 해당 문서를 편집 창에 보였다가 저장하기를 반복하는 수밖에 없다.

제작자/제공자의 답변

2009년 5월 29일 아침에 오류를 보고한 상태이다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


  1. Footnote라는 영어를 "각주"로 번역하고 있다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

지난 5월 10일 스프링노트에서 글을 작성하다가 발견한 벌레이다. 스프링노트에서 일부 글자 속성이 제대로 지정되지 않는 벌레와 거의 비슷한 때에 발견하였고, 그 벌레와는 달리 재현이 가능했다. 그래서 몇 차례 더 확인하여 지금에야 올리게 되었다. 물론 윈도7 RC에 신경 쓰다가 늦은 감도 없지 않아 있다.

벌레의 유형

  • 주변 환경이 바뀌어도 꿋꿋하게 자기 본모습(?)을 지키는 벌레이다.
    공개/비공개 설정이 바뀌었음에도 이전 설정을 그대로 따르는 이상한 벌레이다.
    1. 공개/비공개 설정이 바뀌어도 네비게이션 아이콘은 그대로 유지하는 벌레
    2. 공개/비공개 설정이 바뀌어도 메뉴를 그대로 유지하는 벌레
  • 주변 환경에 상관없이 바꾸지 말라니까 바꾸는 벌레이다.
    1. [CC 라이센스 설정하기] 레이어에서 아무 작업 없이 [적용]을 클릭하면 CC 라이센스를 바꾸는 벌레

벌레의 발견 1 : 공개/비공개 상태

지난 5월 10일 스프링노트에서 글을 작성하다가 발견한 벌레이다.

나는 스프링노트에서 글을 작성할 때 먼저 비공개로 만든다. 그 뒤에 글 내용을 모두 입력하고 그래픽 이미지를 첨부한 뒤에 공개 상태로 바꾼다. 바로 그때 약간의 오류가 발생하고 있었다.

우선 비공개 상태인 글의 화면을 보자.

비공개 상태의 화면

비공개 상태의 화면

위 그림에서 눈여겨 보아야 할 것은 붉은 사각형() 표시가 된 부분이다.

위의 두 부분에서 벌레가 살고 있다.

공개/비공개 아이콘을 클릭했을 때

먼저 제목 표시 옆에 있는 파란 자물쇠(비공개 표시 아이콘)을 보자. 위 붉은 사각형 표시가 있는 그림 두 개 가운데 오른쪽 그림이다. 그 아이콘을 클릭하면 공개/비공개를 바꿀 수 있는 화면이 나타난다.

[이 페이지를 공개합니다.]라는 레이어가 나타난 화면

[이 페이지를 공개합니다.]라는 레이어가 나타난 화면

이 페이지를 공개합니다.라고 된 레이어만 따로 보면 다음과 같다.

[이 페이지를 공개합니다.] 레이어

[이 페이지를 공개합니다.] 레이어

위 화면에서 바로 [공개하기] 단추를 클릭해도 공개가 되며, 이때에도 이 글에서 소개하는 벌레를 만날 수 있다. 또한 옵션을 클릭해서 펼쳐 보면 다음과 같다.

옵션을 클릭했을 때

옵션을 클릭했을 때

라이선스에 대한 항목을 설정한 뒤

라이선스에 대한 항목을 설정한 뒤

왼쪽은 옵션을 클릭했을 때의 화면이고, 오른쪽은 라이선스에 대한 항목을 설정한 뒤의 화면이다. 설정을 마쳤으면 [공개하기] 단추를 클릭하자.

공개/비공개 아이콘을 선택하여 공개/비공개를 설정했을 때 나타나는 오류 화면

공개/비공개 아이콘을 선택하여 공개/비공개를 설정했을 때 나타나는 오류 화면

분명히 위 그림처럼 이 페이지가 공개되었습니다.라는 메시지를 보여준다. 하지만 조금 이상함을 알 수 있다. 바로 붉은 사각형() 표시가 된 부분이다.

앞에서는 이 두 부분의 아이콘이 비슷했다. 둘 다 비공개를 뜻하는 파란 자물쇠 모양이었지만, 이제 달라졌다. 네비게이션 부분(왼쪽 그림)에서는 여전히 파란 자물쇠(비공개 표시)인데, 편집 부분에서는 주황색 자물쇠(공개 표시)로 바뀌어 있다.

비공개에서 공개로 바뀌면 네비게이션에서도 바뀌어야 함에도 불구하고 본래 모습을 그대로 유지하고 있는 벌레이다.

이때 공개에서 비공개로 바뀌어도 결과적으로 이와 비슷한 벌레를 만날 수 있다.

메뉴에서 공개/비공개 설정하기를 선택했을 때

이 벌레는 메뉴에서 공개/비공개 설정하기를 선택했을 때에도 발견할 수 있다.

메뉴를 선택하여 공개/비공개를 설정하기 전의 화면

메뉴를 선택하여 공개/비공개를 설정하기 전의 화면

위와 같이 메뉴에서 공개/비공개를 설정할 수 있다.

그러면 위에서 보았던 이 페이지를 공개합니다.라는 레이어를 볼 수 있고, 그때 [공개하기]를 선택하면 앞서 보았던 벌레를 다시 발견할 수 있다.

메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면

메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면

벌레의 발견 2 : 공개/비공개 변경 시 메뉴

앞서 공개한 그림 메뉴를 선택하여 공개/비공개를 설정하기 전의 화면메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면를 살펴보자

그 두 그림은 공개/비공개 아이콘을 제외하면 별다른 문제가 없어 보인다. 그런데 메뉴 부분에 벌레가 숨어 있었다.

벌레가 숨어 있는 비공개 상태의 메뉴 화면과 공개 상태의 메뉴 화면

왼쪽은 그림 메뉴를 선택하여 공개/비공개를 설정하기 전의 화면이고, 오른쪽은 그림 메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면이다.

이 경우에 그림 메뉴를 선택하여 공개/비공개를 설정하기 전의 화면은 아직 비공개 상태이고 그림 메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면공개 상태이다. 처음에는 비공개 상태와 공개 상태의 메뉴가 같다고 생각했으나, 다른 글을 쓰다 보니 두 경우의 메뉴가 서로 다름을 알게 되었다.

비공개 상태의 메뉴 화면

비공개 상태의 메뉴 화면

공개 상태의 메뉴 화면

공개 상태의 메뉴 화면

위 두 그림은 비공개 상태와 공개 상태의 메뉴이다. 공개 상태일 때 메뉴 항목이 하나(CC 라이센스 설정) 더 많다. 위에서 보여준 벌레가 숨어 있는 비공개 상태의 메뉴 화면과 공개 상태의 메뉴 화면과는 다른 상황이다.

이와 같이 비공개 상태에서 공개 상태로 바꾸면 당연히 그에 맞추어 CC 라이센스 설정이 나타나야 함에도 어찌된 영문인지 나타나지 않고 있다. 다시 말해 나타나야 할 CC 라이센스 설정을 보여주지 않는 벌레이다. 반대로 공개 상태에서 비공개 상태로 바꾸면 감추어야 할 CC 라이센스 설정을 감추지 않는 벌레이기도 하다.

벌레의 발견 3 : CC 라이센스 설정

일단 스프링노트의 글을 공개 상태로 바꾸었다. 메뉴에서 CC 라이센스 설정을 클릭하였다.

이때 오른쪽 아래 귀퉁이의 CCL 표시를 잘 살펴봐야 한다.

메뉴에서 CC 라이센스 설정을 클릭. 이때 오른쪽 아래 귀퉁이의 CCL 표시를 잘 살펴봐야 한다.

잘 보이지 않을 수 있으므로 따로 떼어내었다.

메뉴 부분만 나타내면 다음과 같다.

[CC 라이센스 설정하기] 레이어가 보이면 Set up a Creative Commons license ▼를 클릭하여 아래로 펼친다.

옵션을 펼치기 전 화면

옵션을 펼치기 전 화면

위 화면에서 [적용]을 클릭해도 벌레가 나타난다.

옵션을 펼친 뒤 화면

옵션을 펼친 뒤 화면

이때 그림 옵션을 펼친 뒤 화면에서 나타난 메시지가 조금 이상하다. 그 그림의 윗부분은 다음과 같다.

그런데 그 아랫부분은 다음과 같다. 이는 분명히 저작자표시 - Changes allowed under same conditions(BY-SA)와는 다르다.

또한 이러한 상세 옵션 화면에서 실수로 [적용] 단추를 클릭하게 되면, CC 라이센스가 바뀌게 된다. 이는 상세 옵션이 나타나지 않은 화면(옵션을 펼치기 전 화면)에서 [적용] 단추를 클릭해도 마찬가지 결과를 보여준다.

옵션을 펼치기 전 화면에서 [적용]을 클릭한 화면.

옵션을 펼치기 전 화면에서 [적용]을 클릭한 화면. 오른쪽 아래 귀퉁이으 CCL 표시가 바뀌어 있다.

CC 라이센스 표시만 따로 살펴보면 다음과 같다.

  • : 공개된 처음 상태의 CC 라이센스 (BY-SA)
  • : 옵션을 펼치기 전 화면에서 [적용]을 클릭한 뒤의 CC 라이센스 (BY-NC)

여기에서 옵션을 펼친 뒤 화면에서는 [적용]을 클릭했을 경우에 CC 라이센스가 바뀐다는 점을 알 수 있다. 하지만 옵션을 펼치기 전 화면에서는 [적용]을 클릭했을 때 CC 라이센스가 바뀐다는 사실을 알 수 없다. 그러므로 실수로 [적용]을 클릭하더라도 CC 라이센스가 바뀌지 않도록 옵션에서 현재의 CC 라이센스로 유지될 필요가 있다.

  • 참고 : 한글맞춤법에 따르면 라이센스가 아니라 라이이다.

제작자/제공자의 답변

2009년 5월 15일 오류를 보고한 상태이다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

지난 5월 10일 스프링노트에서 글을 작성하다가 우연히 발견한 벌레이다. 그런데 이 벌레를 무릅쓰고 정상 작동한 것과 같은 결과를 보였더니 사라져 버렸다. 현재 재현은 불가능한 상태이며, 그 원인도 파악하지 못했다.

벌레의 유형

자기가 있어야 할 영역을 구분하지 못하는 벌레이다. 혹시 개념이 출장하지는 않았을까 염려스로운 벌레이기도 하다.

벌레의 발견

5월 10일 새벽에 윈도7을 버추얼박스에 설치하면서 그 설명문을 작성하였다. 그때 발견한 이 벌레를 보는 순간 내가 밤샘을 하느라 착각했다고 생각했다. 하지만 자꾸 반복되었기 때문에 스크린샷을 잡을 수 있었다.

위의 그림에서 Use recommended settings라는 부분을 잘 살펴보자.
그 부분이 가진 특징은 (1) 영문(로마자)이며, (2) 내용 중간에서 줄바꿈이 되어 있고, (3) 숫자 목록을 사용하여 나타내고 있다.

먼저 위와 같이 블럭 설정을 하였다.

<Ctrl+B>를 눌러 강한 강조를 하였으나, 위 그림처럼 윗줄(Use recommended)은 바뀌고 아랫줄(settings)은 바뀌지 않았다.
이 그림처럼 강한 강조 아이콘을 클릭했음에도 결과는 마찬가지였다.

결국 다음과 같이 줄바꿈이 아닌 문단 나누기를 하여 블럭 지정하기로 했다.

일단 문단을 나누고

일단 문단을 나누고

블록을 지정하여 강한 강조를 하였다.

블록을 지정하여 강한 강조를 하였다.

이번에는 내가 원하는 결과가 나타났다.

제작자/제공자의 답변

2009년 5월 14일 오류를 보고한 상태이다. 재현이 불가능하기 때문에 어찌 처리될는지는 알 수 없다. 역시나 재현이 불가능하기 때문에 오류 수정이 어렵다고 한다.

그때가 새벽이라 한창 잠이 올 때였다. 스크린샷을 잡은 것도 지금 생각해보면 비몽사몽간에 했던 일이다. 미처 HTML 코드를 확보하지 못했고, 위의 방법으로 강한 강조를 성공한 뒤에는 재현되지 않았다.

관련 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

스프링노트를 사용하면서 여러 벌레를 발견했지만, 재현에 성공한 것은 거의 없다. 그러다가 바로 어제(2009년 4월 24일) 2개나 재현에 성공했다. 바로 스프링노트의 태그 표기 벌레와 지금 소개하는 링크 편집 벌레이다.

벌레의 유형

  • 수작업으로 만든 링크와 외부에서 복사하여 붙인 링크를 차별하는 벌레이다. 복사하여 붙인 링크를 편집하면 그것의 주소를 마음대로 바꾸어 버리는 벌레이다.

직접 만든 링크와 복사해 붙여넣은 링크가 다르게 해석되는 이유를 알 수 없다. 또한 어떤 경우에는 직접 만든 링크와 동등하게 취급하고, 어떤 경우에는 다르게 취급한다. 직접 만든 링크와 동등하게 처리하는 경우는 스프링노트에서 내 블로그로 발행한 문서에 포함된 링크가 대부분이었다. 그밖에 다른 웹페이지의 링크를 붙여 넣은 경우에는 모두 링크 주소를 바꾸어 버렸다.

벌레의 발견

벌레의 발견이라고 할 수도 있고, 링크의 비교라고 할 수 있는 작업이다. 

스프링노트의 링크 만들기 기능을 이용하여 만든 링크

가장 먼저 스프링노트의 링크를 HTML 코드로 살펴보자. 모질라 파이어폭스에는 선택한 소스 보기라는 기능을 제공하고 있다. 그것을 이용하면 링크 부분의 HTML 소스만 떼어 살펴볼 수 있다.

마우스 오른쪽 단추를 눌러 팝업 메뉴를 부른 화면

마우스 오른쪽 단추를 눌러 팝업 메뉴를 부른 화면

위의 작업을 통해 보게된 선택한 영역의 HTML 소스

위의 작업을 통해 보게된 선택한 영역의 HTML 소스

  1. <a href="http://salm.pe.kr/entry/Springnote-Tag-Bug" class="external newWindow" title="http://salm.pe.kr/entry/Springnote-Tag-Bug">스프링노트의 태그 표기 벌레</a>

스프링노트의 링크 만들기 기능을 이용하여 링크를 만들게 되면 위와 같이 class="external newWindow" 라는 클래스 선택자를 추가하게 된다.

다음과 같이 링크를 수정하면 링크 대상이 현재 링크된 곳을 가리키게 된다.

 

링크 수정/삭제를 선택하는 팝업

링크 수정/삭제를 선택하는 팝업


링크 수정/삭제 팝업에서 수정을 선택한 화면

링크 수정/삭제 팝업에서 수정을 선택한 화면

스프링노트의 링크 만들기 기능을 이용해서 만든 링크는 링크를 고칠 때 위와 같이 원래 주소, 곧 링크 대상을 유지해 준다.

스프링노트의 링크 만들기 기능을 이용하지 않은 링크

스프링노트의 링크 만들기 기능을 이용하지 않은 링크는 class="external newWindow" 라는 클래스 선택자를 가지지 않은 링크를 말한다.

도아의 세상사는 이야기의 게시글에서 링크 하나를 복사했다. 그런데 그것이 블로그 기사 제목이라서 아래와 같이 나타났다.

좌우 폭이 좁은 까닭은 화면 크기가 800×600px이기 때문이다.

좌우 폭이 좁은 까닭은 화면 크기가 800×600px이기 때문이다.

아무튼 단락제목2(HTML 태그로는 <H2>)에 해당하며, 녹색 글씨에 녹색 밑줄이 생긴 이유는 링크가 걸려 있기 때문이다. 이것을 위의 링크 수정하는 법대로 링크를 수정하는 과정은 아래와 같다.

우선 단락을 본문으로 바꾸었다.

그 뒤 링크 편집창(편집 애플릿?)을 띄우면 뜬금없이 "PermaLink :: 옥션의 어이없는 판매자"라고 나타난다. 저 글귀는 어디에서 나타났을까? 왜 웹 주소(URL 등)가 아닌 저런 문장이 나타났을까?

선택한 영역의 HTML 소스를 살펴보면 답이 나온다. 그렇다. 링크(A 태그)의 title 속성을 따다가 나타내 주고 있다.

이것을 확인하기 위해 다른 태그도 복사했지만, 역시나 title 속성을 따서 나타내 주고 있었다. 그렇다면 굳이 class="external newWindow" 클래스 선택자를 넣을 필요도 없었다는 말인데 왜 굳이 그렇게 하는지 이해하기 힘들었다.

기술적인 해석

기술적인 측면으로 본다면 단순히 하이퍼링크(A 태그)의 title 속성을 따올 뿐이며, 벌레라고 보기는 힘들었다. 그러나 주소를 정상적으로 링크 대상에 나타내려면 링크 주소와 title 속성을 항상 같게 해야만 한다는 점에서는 문제가 있다고 하겠다. title 속성은 누구나 정할 수 있지만, 대부분 링크를 설명하는 문구를 넣게 된다. 위에서 예로 든 링크도 "PermaLink :: 옥션의 어이없는 판매자"와 같은 글귀가 그것이다. "옥션에서 본 어이없는 판매자에 대한 링크"임을 나타내기 위해 title 속성을 저렇게 주었음을 알 수 있다.

스프링노트 링크 대상을 표시하는 문제를 해결하기 위한 방법으로도 그다지 좋지 않다고 생각한다. 물론 title 속성을 참조함으로써 간단한 코드를 만들 수 있다는 점에서는 동의한다. 하지만 이번과 같은 상황에서는 너무 단순한 것을 찾다가 낭패가 생긴 경우이다. 외부 링크인지만 검사했더라도, 외부 링크이면 title 속성이 아닌 href 속성을 참조하게 만들었다면 이번 벌레는 애초에 생기지 않았으리라 생각한다.

회사 측 답변

2009년 4월 27일 현재 오류를 보고한 상태이며, 수정하겠다는 답변을 받았다.

관련 문서 및 페이지

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

스프링노트를 자주 사용한다. 아니, 아예 끼고 산다고 해야 옳겠다. 블로그를 시작하면서부터 도아 님이 알려준 스프링노트를 써서 글을 발행하고 있기 때문이다. 처음 글 몇 개를 제외하고는 모두 스프링노트에서 작성했다.

그런데 최근에 자잘한 오류가 눈에 띄기 시작했다. 오류보고를 하려고 해도 재현을 하지 못해서 참고 있었다. 그러나 이번에 황당하게 재현하게 되어서 소개하고자 한다.

벌레의 유형

  1. 이 벌레는 남의 영역을 침범하는 벌레이다.
  2. 특정 웹브라우저에서는 자기 자신을 감추어버리는 은신술의 달인이다.

보통 경로명 등이 길어지면 경로명 일부를 ... (마침표 3개) 등으로 대치하는데, 이 벌레는 아예 태그가 있던 영역을 지워버렸다. 물론 인터넷 익스플로러에서는 다른 것이 표시되어야 하는 영역을 침범할 뿐 자기 자신의 일부를 그대로 나타내 주었다.

벌레의 발견

스프링노트에서 글을 작성하다가 너무 많은 태그를 입력하자 갑자기 태그 전체가 사라져 버렸다. 태그 고치기 단추와 태그 표시 단추가 모두 사라진 셈이다.

오류 없이 태그를 보여주는 화면

오류 없이 태그를 보여주는 화면

정상적인 상태에서는 위와 같이 나타난다. 이때 현재 편집하는 글의 상태를 알 수 있는 상태 표시줄만 따로 떼어내면 다음과 같다.

상태 표시줄 화면

상태 표시줄 화면

글을 편집하다 보니 태그를 너무 많이 입력하게 되었다. 그러자 내 파이어폭스에서 태그 표시 아이콘, 태그, 태그 편집 아이콘이 사라졌고, 아울러 페이지 히스토리 아이콘과 CCL 표시도 사라져 버렸다.

모질라 파이어폭스에서는 너무 많은 태그를 입력하자 아예 사라져 버린 태그 목록과 태그 표시 및 태그 입력 아이콘. 그리고 그 오른쪽 구성물도 사라졌다.

모질라 파이어폭스에서는 너무 많은 태그를 입력하자 아예 사라져 버린 태그 목록과 태그 표시 및 태그 입력 아이콘. 그리고 그 오른쪽 구성물도 사라졌다.

왼쪽 내비게이션을 감추자 비로소 입력한 태그 목록과 태그 표시 및 태그 편집 아이콘이 나타났다.

왼쪽 내비게이션을 감추자 비로소 입력한 태그 목록과 태그 표시 및 태그 편집 아이콘이 나타났다.

인터넷 익스플로러에서는 태그 목록과 태그 표시 아이콘은 남았으나, 태그 편집 아이콘과 그 오른쪽 구성물이 사라졌다.

왼쪽 내비게이션을 감추자 태그 편집 아이콘과 페이지 히스토리는 나타났으나, CCL 표시는 다시 나타나지 않았다.

위와 같이 모질라 파이어폭스(3.0.9판)와 인터넷 익스플로러(v6 sp2)에서는 그 정도의 차이가 있지만 제대로 화면에 출력해 주지 못하는 상태였다. 구글 크롬이나 오페라 등의 웹브라우저에서도 그다지 다르지 않은 결과를 나타내리라 생각한다.

현재 이와 관련한 해결책은 태그를 많이 입력하지 않는 방법뿐이다. 응급책으로는 왼쪽 내비게이션과 오른쪽 책갈피를 모두 감추고 쓰는 것도 한 방법이 될 수 있다.

회사 측 답변

2009년 4월 26일 현재 오류를 보고한 상태이며, 태그 표시를 수정하겠다는 답변을 받았다.

관련 문서 및 페이지

이 글은 스프링노트에서 작성되었습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

카테고리

분류 전체보기 (1005)
스크립트 (22)
벌레와 팁 (126)
소프트웨어 (240)
하드웨어 (6)
이야기 (24)
말의 나무 (506)
미쳐보자 (22)
일기 (48)
아이폰 (10)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

달력

«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

글 보관함