가라

Q : Google reCAPTCHA (구글 리캡차) API 를 웹페이지에 적용하고 싶어요.

A :

구글계정이 없으면 구글 계정부터 만들어야 해요. [구글계정생성하기]

Google reCAPTCHA : 구글 리캡차 홈페이지로 이동해서 우측상단에 "Get reCAPTCHA"를 클릭해요.

API를 사용할 Domains 에 작성하고, 그룹을 구분하기위해 닉네임을 Label에 작성해요. 나중에 변경/추가/제거 가능해요

예) Label : 홍길동회사, Domains : www.pcmaker.co.kr

등록하면 API 적용에 사용할 Site key, Secret key, client-side, Server side 적용가이드를 확인할 수 있어요.

샘플역시 구글 페이지에서 제공하고 있어서 복사/붙여넣기 후 소스 수정하시면 되요. [샘플보러가기]

InStr 함수는 문자열에서 특정 문자열의 위치를 앞에서 부터 찾는 함수이고요.

InStrRev 함수는 뒤에서 부터 찾는 함수에요.

그런데 위 이미지와 같이 생각과 다르게 나올때가 있어요. [마]

찾는 문자열이 하나일때는 앞위치를 내보내고 있어요. [다]

둘 이상일때는 뒤에서 부터 세고있고요. [사]

* Fix

  설명 : 버림함수, 소숫점이하 버림

  코딩 : Response.Write Fix(65.23)

  결과 : 65

* Mod

  설명 : 나머지 반환

  코딩 : Response.Write 3 Mod 2

  결과 : 1

* Int

  설명 : 정수형 반환

  추가 : 0.4 는 0 과 1 에 끼어있는 수인데 그중 작은수인 0을 반환, -1.7는 -1 과 -2 에 끼어있는 수인데 그중 작은 -2를 반환, 이 점을 이용하여 올림함수로 사용가능 함 [예:-(Int(- (7.0 / 3.0)))]

  코딩 : Response.Write Int(0.9)

  결과 : 0

<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

* width : 뷰포트의 크기

예) width=1024
예) width=device-width  (100% 화면의 폭)

* initial-scale : 줌레벨

예) initial-scale=1

* shrink-to-fit : 사이즈변경 방지

예) shrink-to-fit=no

* user-scalable : 사용자에 의한 줌인/줌아웃 허용여부


예) user-scalable=no

* 메타태그 속성

- http-equiv 또는 name : 항목명

- content : 내용

* 캐쉬에 저장하지 않기(뒤로가기시 만료된 페이지입니다), 프로토콜을 모를시에 중복사용 가능, 뒤로가기 클릭시 페이지 재방문에 따른 오동작 방지

  (Pragma, no-cache, cache-control, must-revalidate)

- HTTP 1.0

예) <meta http-equiv="Pragma" content="no-cache">

- HTTP 1.1

예) <meta http-equiv="cache-control" content="no-cache, must-revalidate" />

* 호환성 강제 렌더링, ActiveX, 기타 스크립트 등 IE 상위버전까지 지원이 되지 않아 호환성 문제 발생시 메타태그 고정으로 해결

  (X-UA-Compatible, IE=Edge)

- 표준모드 : IE=5, IE7, IE8 등

- 표준모드 : IE=EmulateIE7, IE=Edge 등

예) <meta http-equiv="X-UA-Compatible" content="IE=Edge">

* 검색엔진(robot, 봇 등) 정보수집 허용여부 설정

- noindex : 페이지 색인 허용 안함

- nofollow : 페이지내 링크 추적 허용 안함

- nono : noindex, nofollow 둘다

예) <meta name="robots" content="noindex, nofollow" />

* 만든 단체나 회사 이름 (publisher)

예) <meta name="publisher" content="HELLO WORLD INSTITUE" />   

사용 예) <td bgcolor="aqua"></td>

* Len

설명 : 문자열 길이 반환

코딩 : Response.Write Len("rocket")

결과 : 6

* Left

설명 : 왼쪽부터 정해진 길이만큼 문자열 반환

코딩 : Response.Write Left("rocket", 3)

결과 : roc

* Right

설명 : 오른쪽부터 정해진 길이만큼 문자열 반환

코딩 : Response.Write Right("rocket", 3)

결과 : ket

* Mid

설명 : 정해진 위치부터 정해진 길이만큼(또는 문자열 끝까지) 문자열 반환

코딩A : Response.Write Mid("rocket", 4, 3)

코딩B : Response.Write Mid("rocket", 3)

결과A : ket

결과B : cket

* InStr

설명 : 문자열내 지정된 문자열의 시작하는 위치 반환

코딩 : Response.Write InStr("Get on a rocket ship", "rocket")

결과 : 10

* LTrim

설명 : 문자열 왼쪽 공백 제거후 반환

코딩 : Response.Write "□" & LTrim(" rocket ") & "□"

결과 : □rocket □

* RTrim

설명 : 문자열 오른쪽 공백 제거후 반환

코딩 : Response.Write "□" & RTrim(" rocket ") & "□"

결과 : □ rocket□

* Trim

설명 : 문자열 양쪽 공백 제거후 반환

코딩 : Response.Write "□" & RTrim(" rocket ") & "□"

결과 : □rocket□

* Space

설명 : 공백을 정해진 숫자만큼 더한 문자열을 반환

코딩 : Response.Write Len(Space(10))

결과 : 10

* Replace

설명 : 문자열내 정해진 문자(열)을 주어진 문자(열)로 변경후 반환

코딩 : Response.Write Replace("Get on a rocket ship", "ship", "plane")

결과 : Get on a rocket plane

* UCase

설명 : 문자열내 영문자를 대문자로 변환후 반환

코딩 : Response.Write UCase("Get on a rocket ship")

결과 : GET ON A ROCKET SHIP

* LCase

설명 : 문자열내 영문자를 대문자로 변환후 반환

코딩 : Response.Write LCase("Get on a rocket ship")

결과 : get on a rocket ship

* Split

설명 : 문자열을 정한 문자로 구분하여 배열로 반환

코딩 : Response.Write Split("Get on a rocket ship", " ")(0)

결과 : Get

* Join

설명 : 문자열 배열을 정한 문자를 연결매개로 하여 반환

코딩 : Response.Write Join(Split("Get on a rocket ship", " "), " ")

결과 : Get on a rocket ship

* FormatCurrency

설명 : 숫자(숫자 및 문자열)를 통화값으로 변환한 문자열을 반환

코딩 : Response.Write FormatCurrency("39900")

결과 : ￦39,900

이미지 중앙정렬 태그 속성 absmiddle 의 웹표준

* 기존

<img src="search.gif"  alt="검색" align="absmiddle" />

* 표준

<img src="search.gif"  alt="검색" style="vertical-align:middle;" />

<script type="text/javascript">

$(document).ready(function () {

    setInterval("$('.blink').fadeOut().fadeIn();",1000);

});

</script>

<span class="blink">깜빡이는 텍스트</span>

<iframe name="ifrSample" id="ifrSample" onload="fnAutoResize(this)"></iframe>

<script type="text/javascript">
function fnAutoResize(obj) {
    obj.height = eval(obj.name+".document.body.scrollHeight");
}
</script>

iframe 내 들어오는 SRC 에 맞게 iframe 사이즈를 재설정 합니다.

* 미디어 쿼리 사용조건 : HTML5 / CSS3

* 다운로드 사이트 : https://github.com/scottjehl/Respond/tree/master/dest

respond.min.js 파일을 다운로드 하여 사용서버에 업로드후 아래 코드를 추가

<!--[if lt IE 9]>
<script type="text/javascript" src="경로/respond.min.js"></script>
<![endif]-->

* 데모 페이지

http://scottjehl.github.io/Respond/test/test.html

<head>내에 아래 코드를 추가합니다.

<!--[if lt IE 9]>

<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>

<![endif]-->

Ogg Theora, H.264 and the HTML 5 Browser Squabble

By Prince McLean
Published: 08:00 PM EST

전문가들은 HTML 5용 공식 비디오 코덱 채택을 위해, 무료인 Ogg Theora 코덱을 세우려는 모질라와 오페라가 애플에게 싸움을 걸었다고 평한다. 그러나 문제가 있다. HTML은 콘텐트용 코덱을 세우라고 만들어지지 않았다. 설사 거의 10년 전, 상업적으로 포기된 코덱인 Ogg Theora를 채택한다 하더라도, Ogg Theora는 점차 늘어나고 있는 모바일 웹용 비디오를 전달할 능력이 없다.

기술 언론들은 HTML 5를 가로막는 거대한 장벽, 혹은 자유 소프트웨어 투쟁가들과 대기업들간의 전쟁같은 불화를 기사화시키기 좋아한다. 그러나 HTML 5와 같은 사양의 현실은 정치적인 관점이 아니라 기술적인 상호작용성에 있다. 새로운 HTML 5 사양에 있는 비디오 포맷에 대한 이슈를 보자. 원래 HTML 사양은 웹 개발자들이 그래픽을 페이지에 넣는 것처럼 간단한 임베딩 비디오 시스템을 정의내린 적이 없었다.

웹브라우저는 GIF에서 JPEG, PNG에 이르는 그래픽 포맷을 인식하고 표시하기 위해 "img"라는 태그를 사용한다. 그러나 HTML 내에 비디오나 오디오를 임베딩하기 위해 똑같은 역할을 하는 태그는 없었다. 대신 웹 개발자들은 비디오를 나름 임베디드 파일로 포스팅하였고, 이를 정확히 표시할줄 모르는 브라우저가 있을 수 있었다.

웹상에서 오디오와 비디오 재생에 이런 문제가 있었던 이유는, 퀵타임, 그리고 ISO MPEG 비디오표준 개발의 역사와 궤를 같이 한다. 모질라와 오페라, 오픈소스 지지자들 일부가 덤비고 있는 산업과 동일한 산업이다. 물론 마이크로소프트도 한 몫 하고 있다.

The QuickTime Plugin

모든 브라우저에서 동일하게 잘 작용되는 비디오 표시방법은 쉽지 않다. 서로 경쟁중인 멀티미디어 재생 플러그인이 특정 컨테이너 파일(미디어 데이터를 담는 형식)과 코덱(오디오와 비디오 데이터 압축방식)만을 지원할 때가 많아서다. 초창기 웹 개발자들은 MJPEG (Motion JPEG)을 사용했다. MJPEG는 JPEG 스틸로 화면을 재생하고, 기본적인 WAV 파일로 오디오를 재생시키는 간단한 비디오 포맷이다. 사실 모든 브라우저에서 다 돌아가는 유일한 포맷이 MJPEG이다. 그러나 다운로드 크기나 화질로 볼 때 MJPEG은 그리 효율적이지 못하다.

애플의 퀵타임은 MJPEG를 포함, 여러가지 코덱 안에서 비디오를 재생하기 위한 시스템으로서 웹보다 앞서 나왔다. 따라서 써드파티에서 나오는 새로운 코덱도 지원 가능했다. 90년대 웹이 유명해지자, 애플은 넷스케이프와 그 외 브라우저용 퀵타임 포맷을 제공하였다. 브라우저 내에서 오디오와 비디오를 직접 재생시킬 수 있게 하기 위해서였다. 덕분에 퀵타임은 웹 비디오에 진출하게 되었고, 특히 웹 사용자와 웹 개발자들의 맥 사용비율은 당시 맥 사용비율과는 사못 달랐다.

개방성 웹, 그리고 윈도 독점에 웹이 지닌 잠재성에 주목하게 된 마이크로소프트는 넷스케이프를 죽음으로 몰아넣는다. 마이크로소프트는 퀵타임도 죽이려 하였다. 당시 마이크로소프트는 NCSA의 SpyGlass 브라우저 코드(넷스케이프도 이 코드를 기반으로 만들어졌다)를 라이센스받아 인터넷 익스플로러를 만든다. 그리고 이를 윈도에 무료로 번들시켜서 넷스케이프 브라우저 시장을 파괴시킨다.

Microsoft's War on QuickTime

그러나 퀵타임 베끼기와 죽이기는 더 어려웠다. 이미 마이크로소프트는 90년대 초, Video for Windows를 선보였으나 퀵타임의 질에 미치치 못하였다. 그리고는 샌프란시스코 Canyon 스캔들때문에 퀵타임 코드를 의도적으로 훔쳤다는 법정공방에까지 빠지게 되었다. 맥과 윈도 시스템의 표준 비디오 재생용 퀵타임을 죽이는데 실패한 마이크로소프트는 90년대 후반, 인터넷 익스플로러가 설치된 퀵타임 플러그인을 무시하도록 하였다.

넷스케이프를 파괴시킨 혐의에 집중된 마이크로소프트 독점 재판 때, 애플 중역진들은 넷스케이프가 퀵타임 플러그인과 잘 작동되었다 증언했다. 그러나 인터넷 익스플로러의 후대 버전들은 점차 퀵타임으로 비디오를 적절히 보내지 않았으며, 이 때문에 소비자들은 퀵타임이 잘 안돌아간다 여길 수 있었다. 재판 때 애플은 22개의 미디어 파일의 차트를 보여주면서, 윈도 95의 넷스케이프 4에서 22개 미디어 모두가 퀵타임으로 잘 돌아갔지만, 인터넷 익스플로러 3에서는 15개만이, 익스플로러 4에서는 11개만이 퀵타임으로 잘돌아갔다. 이것이 윈도 98 상에서는 4개에 불과했다. 마이크로소프트 변호사들은 마이크로소프트가 악의를 갖고 퀵타임 호환성을 일부러 깨뜨렸다는 주장은 아무도 입증할 수 없노라 주장할 뿐이었다.

그러니 바로 그 때, 마이크로소프트 중역들은 애플이 퀵타임을 포기하고 마이크로소프트와의 경쟁을 없애지 않는 한, 애플의 비디오 오쏘링 사업을 파괴시켜 버리리라 위협하고 있었다. 그러나 이런 위협에 굴복한 다른 기업들과는 달리 애플은, 마이크로소프트의 그 유명한 "knife the baby" 요구를 거절하고, 직접적인 경쟁에 나섰다.

마이크로소프트에 대한 격렬한 경쟁이 퀵타임 3이라는 결과물을 냈으며, 마이크로소프트가 발표한 다양한 기술들은 모두 실패하였다. 마이크로소프트는 크로스-플랫폼 Active Movie를 약속했으나 전혀 발표하지 못하였고, 새로운 윈도 미디어 컨테이너 파일 또한 별 반응을 이끌어내지 못하였다. 1998년 ISO는 MPEG-4 멀티미디어 표준으로서 퀵타임 컨테이너를 채택하였다.

Microsoft pushes Flash against Adobe

비디오에서 애플의 퀵타임과 싸우는 한편, 마이크로소프트는 PGML을 밀고 있던 어도비와 썬과의 싸움도 벌이고 있었다. PGML은 어도비 포스트스크립트에 기반하며, 벡터그래픽을 웹에 표시하기 위한 공개표준이었다. 마이크로소프트는 매크로미디어와 연합하여, 고유의 경쟁 표준인 VML을 선보였다. W3C 표준기구는 결국 두 진영으로부터 협상을 이끌어내서, 새로이 SVG (Scalable Vector Graphics)라 불리우는 표준을 만들어낸다.

그러나 마이크로소프트는 SVG 표준을 지원하지 않았다. 마이크로소프트는 인터넷 익스플로러에서 계속 VML을 밀었다. 그 결과 시장은 혼란스러워했고, SVG에 대한 실질적인 채택이 이뤄지지 않았다. 어도비의 무료 SGV 웹플러그인의 채택을 방해하기 위해, 마이크로소프트는 1999년, 인터넷 익스플로러 5에 매크로미디어의 폐쇄형 Flash 플레이어를 번들하기 시작한다. 윈도 독점을 이용, Flash 벡터 그래픽 플러그인에게 광범위한 기반을 안겨다준 것이다. 마이크로소프트는 Flash를 이용하여 특정 영화 포맷과의 호환성을 깨면서까지 퀵타임을 죽이려고도 했었다.

마이크로소프트의 퀵타임에 대한 반-경쟁적인 압박은 Flash에 새로운 기능을 안겨다준다. 바로 비디오 재생 기능이다. Flash 플러그인이 워낙 광범위하게 설치되었기에, 브라우저 안에서 폐쇄형 비디오를 재생시키는 데에 쓸 수 있었다. 표준형 비디오 파일을 비디오 플러그인 형태로 링크시키는 대신, 웹 개발자들은 폐쇄형 Flash 무비파일을 Flash 플레이어 플러그인으로 재생시키도록 웹을 만들기 시작했다. 다름 아닌 마이크로소프트가 광범위하게 배포시킨 플러그인이 Flash다.

인터넷 익스플로러를 사용하지 않는 사용자들도 매크로미디어 Flash 플러그인을 퀵타임 플러그인처럼 다운로드받을 수 있다. 웹 비디오가 이제 Flash 포맷에 묶였기에, 퀵타임-호환형 영상을 다른 미디어 소프트웨어에서 재생시킬 수 있는 것처럼, 다른 대안형 플레이어로 Flash 파일을 돌릴 수 없다. 추가적으로 매크로미디어 Flash 플레이어는 윈도에서만 대단히 잘 돌아간다. 이 때문에 Flash 콘텐트를 익스플로러에 묶어두는 효과가 발생하였다.

Apple takes back media with the iPod

웹비디오를 장악하는 데 실패했었던 마이크로소프트는 적어도 인터넷 익스플로러에서 제일 잘 돌아가는 포맷으로 웹 비디오를 끌어들이는 데에 성공하였다. 그 다음 마이크로소프트는 음악과 비디오 저작용 표준에 관심을 기울이기 시작했다. 마이크로소프트는 DVD의 ISO MPEG-2 표준을, 같은 디스크 상에서 DRM화된 윈도 미디어 포맷으로 바꾸기를 희망하였다. 소위 iHD라 불리우는 포맷이다. 음악에 있어서는 MPEG MP3를 윈도 미디어 오디오로 바꾸려 하였다. 불법복제가 불가능한 DRM을 약속하면서 제작사들도 끌어들였다.

그러나 마이크로소프트는 약속했던 윈도미디어 DRM 기술을 제 때 선보이지 못하였다. 이 때문에 애플 아이포드와 아이튠스 뮤직스토어가 성업하게 된다. 애플은 ISO의 표준 MPEG AAC를 채택하였다. 이 AAC는 세련된 데이터 압축 형식이며, 제작사들이 요구한 DRM도 지원하였다. 더구나 아이포드의 성공덕택에, 상업적인 오디오 배포용 포맷으로서 WMA는 위축되었고, 윈도용 아이튠스는 AAC를 맥과 윈도 양측의 새 표준으로 만들어버렸다. 데스크톱 전쟁에서 2%까지 줄어들었던 회사치고는 놀라운 성공이다.

그 다음 애플은 비디오에서도 같은 전술을 펼쳤다. MPEG H.264 표준을 아이튠스 비디오로 채택하고, 효율적인 재생을 위해 아이포드 상에서는 하드웨어 비디오 디코딩까지 지원하였다. WMV 재생기능을 준-표준화시키는 데에 실패한 마이크로소프트는 미국 내 SMTPE 표준을 통해 WMV 코덱을 겨우 세워 두었다. 후에 이 포맷은 이름이 VC-1으로 바뀌게 된다. VC-1은 Blu-Ray와 HD-DVD 사양 모두에 일부로 들어가 있게 되지만, 실제로 사용한 사양은 불운의 HD-DVD 뿐이었다. 그동안 아이튠스는 음악의 AAC처럼 비디오에서 H.264를 대중화시켰다.

Apple takes on WMV and Flash

애플은 상호 운용 가능한 공개표준을 위해 콘텐츠만 활용하지 않았다. 윈도 전용으로 콘텐츠를 묶어버리는 비표준 코덱에 대한 의존성도 없애버리는 작업을 시작하였다. 원래 마이크로소프트는 맥용 WMA와 WMV 지원을 결국 거부했었고, 매크로미디어 또한 맥과 리눅스, 인터넷 익스플로러 외의 브라우저용 Flash 플러그인을 거의 개선시키지 않고 있던 상황이다.

맥과 아이포드 하드웨어에서 상용 콘텐츠를 모두 잘 돌리도록 하기 위해, 애플은 아이포드 상에서 마이크로소프트의 폐쇄형 WMA/WMV 코덱 지원을 거부하고, 원형 WAV 오디오 포맷에서 MP3이나 AAC 표준만 지원해주는 음악 시장을 조성하는 데에 아이포드를 활용하였다. 아이포드 비디오도 마찬가지다. 아이포드 비디오는 WMV나 리얼비디오와 같은 폐쇄형 포맷이 아닌, MPEG-4/H.264 포맷만을 지원하였다.

아이폰이 나오자 이번 상대는 Flash였다. 아이폰은 Flash 영상 재생을 마찬가지 이유로 거부하였다. 공식적으로야 현재 어도비가 소유하고 있는 Flash가 아이폰과 잘 돌아가지 않는다는 이유다. 사실일 것이다. 그러나 아이폰용 Flash를 죽여야 할 진짜 이유는 웹개발자들이 다시금 표준형 비디오 포맷을 사용하도록 하기 위함이다. 폐쇄형 Flash 바이너리에 둘러싸인 콘텐트가 아니고 말이다.

좀 아이러니컬한데, 마이크로소프트는 Silverlight 런타임과 함께 원래 Sparkle이라 부르던 고유 포맷을 들고 나섰다. 어도비 Flash를 노리고 나온 포맷이다. 인터넷 익스플로러는 이제 경쟁자도 많아지고 점유율도 하락하고 있으며, 퀵타임에게 했던 것처럼 경쟁사(Flash)의 플러그인을 죽일 수 있는 힘은 약화되었다.

HTML 5 and the Ogg Theora option

그동안 오페라와 모질라의 파이어폭스, 애플의 사파리, 구글의 크롬과 같은 브라우저가 나와, 웹브라우저 시장에서 마이크로소프트의 통제력을 조금씩 뺏어갔다. 그리고 이들이 한데 모여, 비디오를 표시할 표준을 모의하기에 이르렀다. HTML 5는 비디오 파일 임베딩을 간단히 정의내려서 클라이언트 브라우저가 이를 표시할 수 있게 만든다. 마이크로소프트 입장은 일단 두고보자이다. 상호운용이 불가능하고 웹-표준에 적대적이며 Flash를 베껴서 만든 자신의 Silverlight이나 Flash의 수요를 떨어뜨릴 기세를 보인다면, 표준화 작업을 파괴시키려들 것이다.

애플은 이미 구글을 설득하여 YouTube 비디오 포맷에 H.264를 더해 놓았다. 이는 아이폰용 YouTube로 첫등장하였다. 구글은 또한 Flash 없이, H.264 비디오를 HTML 5 기본지원으로 보여주는 YouTube 웹사이트를 시연한 적도 있다.

그러나 문제점은 남아 있다. 무료 배포에 의존하는 두 브라우저의 회사 둘(모질라와 오페라) 다 H.264 코덱 라이센스에 적대적이기 때문이다. 이들은 H.264 대신, W3C가 HTML 5 공식 비디오 코덱으로 Ogg Theora를 채택하기 바라고 있다. Ogg Theora는 원래 On2에 묶여있던 VP3 비디오 기술을 기반으로 하고 있으며, 현재는 버려진 포맷이다. Flash 비디오가 On2의 VP6 기반이며, Skype의 고유 화상회의는 VP7을 사용한다. ISO의 상호운용가능 표준에서 보면 On2는 마이크로소프트의 WMV/V1만큼이나 독점적인 코덱이다. 다만 마이크로소프트의 영향력이 없을 뿐이다.

오픈소스 커뮤니티는 2001년 On2가 포기한 포맷인 VP3을 H.264에 대한 대안으로 홍보해왔다. 소프트웨어 개발자에게 있어서, Ogg Theora 사용은 MPEG 회원사들의 특허를 공유하기 위해 지불하는 로열티를 없애준다. 덕분에 비디오 게임 개발자나 Wikipedia와 같은 조직들이 Ogg Theora를 채택해왔다.

Ogg Theora vs. H.264

그러나 애플과 노키아와 같은 하드웨어 업체들은 여러가지 실용적인 이유를 들면서 Ogg Theora와 HTML 5의 결합에 반대하고 있다. 첫째로 H.264 라이센스 비용은 애플이나 노키아 입장에서, 소규모 소프트웨어 개발사들만큼 부담이 안된다. (즉, 무료로 소프트웨어를 배포하는 브라우저 회사 입장에서는 비용이 크다.) 애플도 사파리를 무료로 배포하기는 하지만, 사파리 사용자 대부분은 맥이나 아이폰을 구입하여 사파리를 돌린다. 이에 반해 모질라의 파이어폭스 사업방식은 1년에 구글이 모질라에게 지불하는 검색창값 5천만 달러가 거의 전부다. 구글과 같은 더 거대한 기업들 또한 Ogg Theora 사용에 특별히 비용을 고려하지는 않는다.

둘째로 애플과 구글, 노키아는 이미 H.264에 투자를 해 놓았다. 예전에 버려진 코덱을 지원하기란 별로 바람직스럽지 못하다는 의미다. 구글은 YouTube의 엄청난 스트리밍을 훨씬 덜 효율적인 Ogg Theora로 지원해줄 방법이 없다고 지적하였다. 덜 세련된 압축방식때문에 세상의 인터넷 대역을 소비해버리면 안된다는 의미다. 또한 Ogg Theora는 H.264처럼 하드웨어 가속 기능을 갖고 있지 않다. 즉, 넷북이나 스마트폰 사용에 있어서 Ogg Theora는 완전히 매력이 없다.

오페라와 모질라는 휴대용 기기를 만들지 않기에, 하드웨어 가속 기능에 연연해하지 않는다. 모질라는 휴대기기용 브라우저도 갖고 있지 않다. 반면 오페라는 오페라 미니에 모바일 사업을 집중시키고 있지만, 오페라 미니는 웹브라우저가 아니라 하나의 애플릿이다. 실제 브라우저를 돌릴정도로 강력하지 못한 휴대폰들을 위해, 오페라의 웹프록시 서버가 뿌려주는, 이미 렌더링된 웹페이지를 보여주기 때문이다. 진보적인 새 휴대기기들은 아이폰/아이포드 터치에서부터 Palm Pre, 블랙베리 Storm, 구글 안드로이드에 이르기까지 모두 WebKit 기반의 브라우저를 사용한다.

애플은 Ogg Theora의 특허권이 불명확하다는 주장도 하고 있다. 이것도 모질라와 오페라에게는 중요한 사안이 아니다. 문제가 될 경우, 두 회사 모두 Ogg Theora를 버리면 그만이기 때문이다. 전력이 있다. Unisys가 GIF을 사용하는 모두를 소송하고 있을 때, GIF에 대한 상용 지원을 일시적으로 포기했던 사례가 있었다. 그러나 애플과 같은 기업들은 미디어 콘텐트를 판매하고 있으며, 휴대용기기에서 하드웨어 가속을 지원해야 할 입장이다. 따라서 잠재적으로 특허소송이 날 수 있는 코덱 기술을 섣불리 채택할 수 없다. 게다가 애플에게는 현금이 많다. 특허괴물들이 노릴 만하다. 모질라와 오페라는 그러하지 못하다.

A problem that lacks any need for a solution

HTML 5의 미래를 둘러싼 진짜 문제는 다른 데에 있다. 공식 코덱을 지정해야 할 필요가 있느냐이다. 그래픽에는 공식 코덱이 없다. 웹 개발자들은 JPEG이나 GIF, PNG를 자유로이 선택할 수 있다. 사용자가 이미지를 볼 수 없다면, 관련 플러그인을 설치하면 될 일이다. 즉, 공식 그래픽 포맷이 없다하여 문제가 발생하지 않는다.

비디오도 마찬가지이다. 모질라가 제일 야단이기는 하지만, 브라우저가 비디오 코덱 지원을 라이센스해야 할 이유는 없다. 파이어폭스를 다운로드받아 쓸 정도의 자세라면, 퀵타임도 다운로드받아서 H.264 비디오를 볼 수 있다. 아니면 무료 H.264 코덱을 사용할 수도 있을 것이다. VLC와 FFmpeg, HandBrake가 사용하는 엔진인 GPLed x264을 포함한, FOSS 플랫폼용 코덱을 이용해도 된다.

더구나 웹 개발자들이 단일 코덱만 지원해야 할 필요도 없다. HTML 5는 H.264나 Ogg Theora, 심지어 Flash 바이너리도 쉽게 제공할 수 있게 되어있다. MPEG 라이센스를 하지 않기 위해 Ogg Theora를 택한 Wikipedia와 같은 조직이 아니라면, 퀵타임이나 다른 미디어 시스템의 오픈소스 코덱 컴퍼넌트 패키지를 다운로드 받아서 쓰면 된다.

즉, HTML 5용 공식 비디오 코덱을 둘러싼 전쟁은 지어낸 전쟁이다. 문제 거리가 못된다. HTML 5 자체의 채택이야말로 진짜 문제이다. 상호운용 가능한 비디오 홍보에 더해서, HTML 5는 클라이언트-사이드 데이터베이스와 오프라인 지원 등 웹 애플리케이션 지원을 골자로 하고 있다. HTML 5는 Flash나 Silverlight와 같은 폐쇄형 플러그인에 대한 의존을 없애고, 세련된 클라이언트-사이드 상호운용성으로 웹 콘텐트를 표시하려 한다.

누가 최고로 HTML 5를 지원하느냐가 유일한 문제다. 지난 과거의 폐쇄형 기술로 발목을 잡아끄는 이들은 뒤쳐질 것이다.

[댓글]

[출처]

http://www.appleforum.com/mac-column/57512-ogg-theora%EC%99%80-h-264-%EA%B7%B8%EB%A6%AC%EA%B3%A0-html-5-a.html

self.resizeTo(800, 600);

새창열기시 주어진 창 사이즈에 상관없이 자기 스스로 창사이즈를 재설정합니다.

1. * 커서 손모양 없음
2. <img alt="음성파일 내려받기" src="/Images/img_mp3.gif" border="0" style="cursor:hand;">
3. 
   
4. * 커서 손모양 있음
5. <img alt="음성파일 내려받기" src="/Images/img_mp3.gif" border="0" style="cursor:pointer;">

반환값 : Integer

FUNCTION stripTags(HTMLstring)
     SET RegularExpressionObject = New RegExp
     WITH RegularExpressionObject
          .Pattern = "<[^>]+>"
          .IgnoreCase = TRUE
          .Global = TRUE
     END WITH
     stripTags = RegularExpressionObject.Replace(HTMLstring, "")
     SET RegularExpressionObject = NOTHING
END FUNCTION

1. * 텍스트 좌, 중, 우 로 정렬하기
2. <td align="left">왼쪽 정렬</td>
3. <td align="center">중앙 정렬</td>
4. <td align="right">오른쪽 정렬</td>
5. 
   
6. * 텍스트 상, 중, 하 로 정렬하기
7. <td valign="top">위쪽 정렬</td>
8. <td valign="middle">중앙 정렬</td>
9. <td valign="bottom">아래쪽 정렬</td>