DROP TABLE IF EXISTS `sosi`.`sosi`;
CREATE TABLE `sosi`.`sosi` (
`idx` int(10) unsigned NOT NULL AUTO_INCREMENT,
`sosiname` varchar(45) NOT NULL,
`height` int(10) unsigned NOT NULL,
`blood` varchar(45) NOT NULL,
PRIMARY KEY (`idx`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8;
INSERT INTO `sosi` (`idx`,`sosiname`,`height`,`blood`) VALUES
(1,'윤아',166,'B'),
(2,'수영',170,'O'),
(3,'효연',160,'AB'),
(4,'유리',167,'AB'),
(5,'태연',162,'O'),
(6,'제시카',163,'B'),
(7,'티파니',162,'O'),
(8,'써니',158,'B'),
(9,'서현',168,'A');
②. Flex Project 'ZendAmfTest'를 만듭니다. 머드초보님은 Application server type을 php으로 하셨는데 저는 서버가 외부에 있어서 None/Other로 하였습니다. 로컬이라면 php를 선택하신 다음에 아파치나 iis가 돌아가는 폴더를 지정하면 됩니다. 지정하게 되면 SWF가 서버로 바로 위치하게 되므로 테스트하기 편합니다.
③. 그런 다음 system>application>libraries에 sosimember.php라는 파일을 만듭니다. CI특성상 파일명은 소문자로 만드셔야합니다.
④. 다음은 DB에서 데이터를 가져오고 반환하는 모델을 만듭니다. system>application>models에 sosimodel.php를 생성하시고 아래 코드입력합니다.
-한마디로 말해서 서버와 SWF(플래시)의 통신이 AMF라고 불리는 Binary형식의 프로토콜을 사용하여 이루어지며 서버상에 있는 원격지 객체를 호출합니다.
-가장 작은 패킷 크기에 데이터 통신에 필요한 거의 모든 옵션을 넣을 수 있는 바이너리 메세징 프로토콜
-HTTP(80포트), HTTPS(443)를 통해 통신하기 때문에 방화벽을 무시할 수 있습니다.
-AMF는 플래시 플레이어가 인식 가능한 기본 메세징 포맷이므로 클라이언트에서 데이터 직렬화와 역직렬화가 자동으로 처리되며 속도도 빠릅니다.
-게이트웨이는 HTTP(80포트), HTTPS(443)를 통해 AMF패킷 송수신, AMF직렬화/역직렬화, 적절한 서비스에 요청위임 등을 수행할 수 있는 게이트웨이 라이브러리가 필요합니다. 이러한 게이트웨이 라이브러리 여러 종류 중에 우리는 여기서 ZendAMF라는 것을 사용할 것입니다.
위 그림은 왼쪽부터 IE, 파이어폭스, 크롬, 오페라, 사파리를 재미있게 표현한 그림입니다. 서로 사이 좋게 손을 잡고 있는데요. 그럴일은 없겠지만 5개의 브라우저 제작업체들이 힘을 모아서 완벽한 표준을 만들고 지킨다면 웹프로그래머들이 고생하는 일은 많이 줄어들텐데 말이죠. 그런 의미에서 이러한 재미있는 그림으로 표현한거 같습니다.
트라이던트(Trident)
트라이던트(MS HTML이라고도 합니다)는 마이크로소프트 윈도우즈에 탑재되는 브라우저인 인터넷 익스플로러의 코어(속칭 IE 코어)입니다. 이 엔진은 1997년에 인터넷 익스플로러 4부터 처음으로 사용되었으며, 이후에 지속적으로 신기술이 추가된어 인터넷 익스플로러와 같이 업데이트됐습니다. 트라이던트는 실제로는 오픈 소스 코어이며, 트라이던트 엔진은 모듈 방식의 소프트웨어이기 때문에 다른 소프트웨어 개발자들이 쉽게 웹 브라우저 기능을 자신이 만든 어플리케이션이 추가할 수 있습니다. 그 포트 코어 설계가 매우 안정적이라서 IE 코어를 사용하지만 인터넷 익스플로러는 아닌 브라우저(예를 들면 Maxthon, GreenBrowesr, 중국의 메신저 번들 브라우저 등)가 많지만, 트라이던트는 윈도우즈 플랫홈만 지원합니다.
인터넷 익스플로러의 시장 독점은 트라이던트 코어가 오랜 시간동안 독점적인 위치를 차지할 수 있게 해주었습니다. 이것 때문에 마이크로소프트는 상당히 긴 시간 동안 트라이던트 코어의 업데이트를 하지 않았고, 그 결과 트라이던트 코어는 W3C 표준과 거의 맞지 않게 되었을 뿐만 아니라, 트라이던트 코어 내부의 대량의 버그와 보안 문제가 해결되지 않고 누적되게 되었습니다. 현재 마이크로소프트는 트라이던트의 배포 엔진에큰 변화를 주어, 새로운 기술 외에도 웹 페이지 표준의 지원을 추가하기 시작했습니다. (그래서 인터넷 익스플로러 6이 오랜 시간 사용되었던 것에 비해, 7, 8, 9로 이어지는 변화 속도는 매우 빠르지요). 하지만 이런 변화는 다른 엔진-게코, 웹코어, KHTML, 프레스토 등에 비해 많이 떨어진 편입니다.
게코(Gecko)
게코는 오픈 소스 코드이며, C++로 짜여진 웹 페이지 렌더링 엔진입니다. 현재 모질라에서 제작하는 웹 브라우저(파이어폭스)와, 넷스케이프 6 이후 버전에서 사용하고 있습니다. 이 소프트웨어의 원 코드는 넷스케이프에서 개발하였으며, 지금은 모질라 기금이 유지-보수를 담당하고 있습니다. 게코의 특징은 코드가 완전히 공개되어 있다는 것인데, 따라서 개발 수준이 매우 높고 전 세계의 프로그래머들이 이 코드를 사용하여 기능을 추가할 수 있습니다. 오픈 소스이기 때문에 게코 엔진을 사용하는 브라우저도 매우 많습니다. 이것은 게코 코어가 수년 동안 시장 점유율을 유지해 왔던 원인이기도 합니다.
게코 엔진은 풍부한 어플리케이션 인터페이스와 커뮤니케이션 어플리케이션을 제공하고 있습니다. 이를 사용하여 인터넷 브라우저, HTML 에디터, 클라이언트/호스트 등을 만들 수 있습니다. 비록 처음에는 넷스케이프 네비게이터와 모질라 파이어폭스 정도였지만, 현재에는 많은 프로그램들이 이 엔진을 사용하고 있습니다. 그 밖에 게코는 확장성을 지닌 코어로서 윈도우즈, BSD, 리눅스, 맥 OS X에서 사용할 수 있습니다.게코는 트라이던트 다음으로 많이 사용되는 엔진입니다. 게코 엔진을 사용한 브라우저는 파이어폭스, 넷스케이프 네비게이터 6~9, SeaMonkey, Camino, Mozilla, Flock, Galeon, K-Meleon, Minimo, Sleipni, Songbird, XeroBank가 있습니다. 구글 가젯 엔진도 게코 엔진을 사용한 것입니다.
프레스토(Presto)
프레스토는 오페라 소프트웨어가 개발한 랜더링 엔진으로, 현재 오페라 7~10 버전이 이 엔진을 사용하고 있습니다. 프레스토의 특징은 렌더링 속도의 최적화입니다. 프레스토는 지금 공개된 브라우저 중에서 제일 빠른 속도를 자랑하지만, 그 댓가로 호환성을 일부 희생했습니다.
프레스토는 하나의 동적인 코어입니다. 트라이던트나 게코와 제일 큰 차이는 스크립트의 처리에 있습니다. 페레스토는 선천적인 장저으로 웹페이지의 전부 혹은 일부에서 스크립트를 만나면 이에 알맞는 상황에 따라 새로 해석을 합니다. 그 밖에도 이 코어는 자바스크립트를 실행할때 속도가 아주 빠릅니다. 동일한 조건에서 테스트를 할 경우, 프레스토는 자바스크립트를 실행하는데 걸리는 시간이 트라이던트와 게코 엔진의 1/3밖에 되지 않습니다. 하지만 프레스토는 상업용 엔진이라서 프레스토를 사용하는 제품이 오페라 외에 NDS 브라우저, 노키아 770 정도밖에 없어, 프레스토의 발전을 크게 가로막고 있습니다. 오페라 위젯 엔진 역시 프레스토 엔진입니다.
웹킷(WebKit)
웹킷은 오픈 소스 웹 브라우저 엔진이며, 웹킷의 시조는 KDE의 KHTML과 KJS입니다(이들은 모두 오픈 소스 코드로서 GPL 라이센스를 사용합니다). 따라서 웹킷 역시 오픈 소스입니다.
사파리 브라우저 외에도 맥의 옴니웹(OmniWeb), Shiira 등의 브라우저들이 웹페이지를 사용하고 있으며, 구글의 크롬 역시 웹킷입니다. 웹킷은 핸드폰에서 비교적 널리 사용하고 있는데, 구글 안드로이드, 애플 아이폰, 노키나 S60의 브라우저들이 전부 웹킷 엔진입니다. 또한 위젯 엔진에서도 그 사용율이 높아, 차이나 텔레콤의 BAE, 애플의 대쉬보드, 노키아 WRT가 전부 웹킷 엔진입니다.
1. SVN이란? -자유 소프트웨어버전 관리 시스템입니다. 명령행 인터페이스에서 사용하는 명령어를 따서 “SVN”이라고 줄여서 부르기도 합니다. 제한이 있던 CVS를 대체하기 위해 2000년부터 콜랩넷에서 개발되었습니다.
2. 사용 후기 -사용한지는 1년여정도 되었습니다. 1년여동안은 외부서버에 SVN서버를 설치하여 사용하였지만 요번에 제 개인컴퓨터에 SVN을 적용했습니다.
3. 용어설명
Repository(저장소)란? Subversion이 version control 관련 data를 저장하는 곳입다. 구성하는 방법은 다양하다: 한 repository에 여러 project를 담을 수도 있고, 한 repository에 한 project만 담는 경우도 있다. 두 방법 모두 장단점이 있다. 한 project당 하나씩의 repository를 사용하는 것이 일반적으로 더 바람직하다.
Check out이란?
저장소에서 project를 작업공간에 인출하는 것. Download와 유사하다.
Commit이란?
작업공간에서 수정된 project를 저장소에 반영하는 것. Upload와 유사하다. Commit하기 전에 작업 공간의 file을 충분히 시험하여야 한다.
Commit message란?
Commit 할 때 수정된 내용의 의미를 적어둔다.
Update란?
공동으로 작업할 때 다른 사람들이 수정하여 commit한 모든 최신 version을 일괄적으로 받아오는 것. 역시 download와 유사하다.
Diff란?
수정된 file의 내용 또는 저장소에 저장된 두 revision 사이의 차이를 비교해 준다.
Conflict란?
개발자 Joe 와 Sue 가 같은 file의 같은 version을 수정중이었다. Joe가 자신이 수정한 file을 먼저 commit 하였다. Sue가 그 사실을 알지 못하고 수정한 file 부분이 Joe가 수정한 부분과 달랐다. 위 그림의 경우, 둘째줄이 Cheese가 되어야 하는지 Hot Dog이 되어야 하는지 혼란이 일어난 것이다. 이런 상태를 방지하기 위해 lock을 사용할 수 있다.
Conflict는 어떻게 해결하는 것인지?
Sue가 r4를 우선 update 받아서 수정 (Hot Dog을 추가 또는 file 전체 덮어쓰기)한 다음 commit할 수 있다.
여러사람이 동시에 작업한 결과를 안전하게 합치는 법?
모든 경우에 다 가능한 것은 아니다.
잘만 되면 생산성을 n배 늘릴 수도 있다.
CVS나 Subversion인 경우에는 가능하지만, 다른 version control system에서는 불가능할 수도 있다.
주의: Commit에 성공과 compile에 성공은 별개의 문제이다. Conflict 없이 여러 commit에 error 없이 성공하더라도 build 과정에서 error가 발생할 수 있다. Compile에 성공과 bug 없는 SW도 별개의 문제이다.
먼저, 어느 version을 기반으로 작업할 것인지 결정한다.
누가 어느 부분을 개정할 것인지 겹치지 않게 분명하게 결정한다. (누가 먼저 commit하더라도 상관 없도록 한다.)
각자 개정 후 commit 한다.
어떤 project가 lock 되었을 때의 효과는?
Subversion은 기본적으로 locking을 별로 선호하지 않는 system이다. 충돌이 일어날 수 있는 상황인 두 사람이 같은 file 같은 version의 같은 부분을 수정할 확률이 높지 않다고 보는 것이다. 그러나 file의 크기가 크지 않은 경우에는 누가 수정을 하더라도 비슷한 위치에서 수정이 일어나기 때문에 충돌이 일어날 가능성이 더 높을 것이다. 또한, 그림 file 등과 같이 merge가 곤란한 file의 경우, lock을 하는 편이 훨씬 안전하다.
Harry가 어떤 file을 lock하면, Sally는 file을 check-out하거나 update 받을 수는 있지만 commit하지는 못한다. 이후 Harry가 lock을 풀면 Sally가 다시 commit할 수 있다.
Keyword란?
Subversion 안에 보관중인 file 자체에 file의 이름, 저자, 개정 번호 등의 정보를 자동적으로 기록, 갱신하기 위하여 keyword를 사용할 수 있다. Subversion에서 사용할 수 있는 keyword들 가운데는 다음과 같은 것들이 있다. (대소문자 구별)
$Date$ 마지막으로 commit된 날짜
$Revision$ 마지막으로 commit된 개정판
$Author$ 마지막으로 commit한 개발자
Branch란?
Project의 진행에 영향을 주지 않으면서 새로운 기능, 기술 등을 시험해 보고 싶을 때가 있다. 그럴 때 branch를 만들어서 프로젝트의 본류와 병행으로 개발할 수 있다. 개발이 성공적이라면 추후에 본류에 합류시킬 수 있다. 그렇지 못하다면 합류시키지 않으면 된다.
Branch 또는 Tag 만드는 법?
TortoiseSVN → Branch/tag
Copy (Branch / Tag) dialog box의 To URL 항목 에서 [...] button 선택, Repo Browser를 연다.
branch 또는 tag를 저장할 folder를 새로 만듦. 예를 들어 원류가
file:///c:/svn_repository/Project01/trunk/
였다면 branch 위치는 file:///c:/svn_repository/Project01/branch/
와 같은 형식, Tag 위치는 file:///c:/svn_repository/Project01/tags/Success_LED_On/
와 같은 형식으로 한다.
libmcrypt가 정상적으로 설치되지 않은 것이다. libmcrypt.tar.gz 파일을 다운 받아 ./configure && make && make install로 설치
컴파일 시 configure: error: xml2-config not found. Please check your libxml2 installation. 오류가 나오면
yum install *-devel 이것도 안되면 아래와 같이 수행
libxml2 설치 - XML C 파서(Parser)
다운로드 : ftp://xmlsoft.org/libxml2/
[root@localhost apm]# tar xvfz libxml2-2.6.16.tar.gz
[root@localhost apm]# cd libxml2-2.6.16
[root@localhost libxml2-2.6.16]# ./configure && make && make install
[root@localhost libxml2-2.6.16]# cd ..
[root@kimsr php-5.2.7]# make && make install
4.1 PHP 환경설정 파일 복사
[root@kimsr php-5.2.7]# cp php.ini-dist /usr/local/server/apache/conf/php.ini
본인도 APM을 설치하기위해 무단한 노력을 한거 같다. 몇번의 실패와 역경을 딛고 설치에 성고하였다.
모두 오류없이 설치할 수 있기를 기원하며 설치방법을 만들어 보았다.
이 내용은 어디까지나 설치까지만의 내용을 정리한 것이면 설치 완료 후 세팅해야 하는 사항들이 있다
mysql 기본 DB을 설정하거나 Apache httpd.conf 파일등을 수정해야 한다. 이 부분에 대해서는 추후에 올리는 내용에서
unicode는 모든 문자에 index를 줘 놓은 것이다. 더 이상도 아니고, 더 이하도 아니다.
이 index를 code point라고 부르는데, 그냥 index라고 칭하도록 하자.
'A'라는 글자는 0x0041 이라는 index를 가진다.
'a'라는 글자는 0x0061 이라는 index를 가진다.
'가'라는 글자는 0xac00 이라는 index를 가진다.
( 더 많은 글자와 index를 보려면 http://www.unicode.org/charts/ 를 참고하자 )
표현방법
저렇게 정해져 있는 index를 표시하는 방법에는 UTF와 UCS두가지 종류가 있다.
( UTF - Unicode Transformation Format , UCS - Universal Character Set )
UCS
UCS는 몇바이트로 index를 표현할 수 있느냐를 나타낸다.
즉 UCS-2는 2byte로 index를 나타낼꺼고 UCS-4는 4byte를 이용해서 index를 나타낼거라는거다.
UTF
UTF는 몇 비트단위로사용해서 index를 나타낼것인가를 말한다.
UTF-8은 8bit씩 늘려가며 index를 나타낼꺼라는거고,
UTF-16은 16bit씩 index를 나타낼꺼고, UTF-32는 32bit씩 index를 나타낼꺼라는거다.
( 실상 UTF-16과 UCS-2는 같다고 볼 수 있다. 마찬가지로 UTF-32와 UCS-4도 마찬가지다. )
UTF-16
원래 처음에 unicode의 index는 2byte로 나타낼 수 있었다.
그랬는데, unicode 가 버젼업되어 4.0이 나왔을때에는 0x10FFFF 까지의 index가 생겼다.
처음에는 UTF-16으로 모든 문자를 나타낼 수 있었으나,
( 2byte로 표현할 수 있는 index를 가진 문자 목록을 BMP Basic Multilingual Plane 라고 부른다. )
유니코드 4.0이 나오면서, 2byte로는 0x10FFFF 같은 값을 가리킬 수 없게 되었다.
그래서 UTF-16으로는 BMP에 있는 문자들은 2byte로 처리하고,
BMP보다 더 높은 index를 가지는 놈들은 4byte로 처리 한다.
문자 index 0x0000 부터 0xFFFF 까지는 2byte로 처리 하고
문자 index 0x10000 부터 0x1FFFF 까지는 4byte로 처리 된다.
UTF-32
UTF-32는 기본적으로 4byte를 사용하기 때문에, 위와 같은 짓을 하지 않아도 된다.
UTF-8
영어권에 있는 사람들은 UTF-16을 쓰면 손해다.
모든 영어는 1byte만 있으면 256개를 표현할 수 있으므로, 모든 문자를 넣을 수 있기 때문이다.
그래서 나온게 UTF-8이다.
영어권은 1byte로 표현하고, 그것보다 높은 index를 가지는것은 2byte 혹은 3byte 혹은 4byte ..
요렇게 늘려 가면서 쓰도록 되어 있다.
UTF-8은 8비트를 사용하여 매직 U+ 넘버를 기억공간에 저장함으로서 영어권의 수많은 0으로 사용되는 저장공간의 낭비를 막는 방법입니다. 일반적인 영어텍스트(예, a-z, A-Z, digits 0-9, etc.) 는 1바이트로 인코딩됩니다. 바꾸어 말하면 7-bits ASCII는 UTF-8의 서브셋으로 취급될 수 있습니다.
UTF8은 현재 다양한 플랫폼(Windows, Linux, Unix, Mac OS)이 접속하는 인터넷환경에서 de facto standard(사실상의 표준)으로 자리 잡았습니다. 이는 UTF-16, 32와 비교해서 자원의 낭비를 줄여서 효율적이기 때문만은 아닙니다. UTF-8에는 큰 장점이 있는데, endianness 인코딩으로 little endian, big endian의 구분이 없습니다. 그래서 이 기종간의 데이터 교환을 위해 현재 가장 선호되는 인코딩입니다.
서로간의 변환
UTF-8, UTF-16, UTF-32, UCS-2, UCS-4 는
모두 unicode의 문자 index를 나타내기 위한 방법이기 때문에,
서로간의 변환은 당연히 잘 된다.
글자처리
우리가 글자 "가"를 쓴다고 해 보자. 글자 "가"는 1글자이다.
그러므로 "가"를 나타내는 index가 있다. 물론 "나"를 나타내는 index도 있다.
한글로 표현할 수 있는 글자는 매우 많다.
그 많은 글자 모두에게 index를 줄 수가 없다.
현재 사용하고 있는 모든 글자에 index를 준다고 해도,
시간이 지나서 새로운 글자가 추가 되어 index가 모자르게 된다면 어떻게 할것인가?
그래서 유니코드는 완전한 글자를 제공해 주기도 하지만,
글자를 조립할 수 있도록 조립가능한 글자를 제공해 준다.
다시 "가"를 쓴다고 해 보다.
"가"라는 글자는 1개이지만, 실제로는 초성 "ㄱ"과 중성"ㅏ" 가 합쳐져서 만들어진 글자이다.
그러므로 "가"를 표현하는 방법은 완성된 글자 "가"0xAC00가 될 수도 있고,
초성"ㄱ"과 중성"ㅏ"를 조립한 "가"0x1100,0x1161 로 나타낼 수도 있다.
( 초성 "ㄱ"은 0x1100 - HANGUL CHOSEONG KIYEOK )
( 중성 "ㅏ"는 0x1161 - HANGUL JUNGSEON A )
이는 비단 한글뿐만 아니라,
일본어 역시 완성된 글자가 있기도 하고, 조합할 수 있게도 되어 있다.
영어 역시 그렇다. 영어에서 무슨 글자를 조합하냐 라고 말하겠지만,
이력서를 나타내는 Résumé 의 경우에는 e 와 ' 의 조합으로 이루어 질 수도 있다.
출처: http://ggaman.com/tt/896
유니코드 용어의 이해
유니코드 관련 문서를 읽다보면 가장 많이 마주치는 용어들이 UCS2, UCS4, UTF8, UTF16, UTF32 등과 같은 단어들입니다.
기본언어판, BMP (Basic Mulitilingual Plane)
유니코드의 첫 65,536개의 코드를 의미합니다.
언어판, Plane (256x256 즉 65,536 개씩의 코드 묶음)
유니코드에서는 현재 17개의 언어판을 사용할 수 있습니다.
모두 그룹 00에 포함됩니다.
언어판 그룹, Group (256개씩의 언어판을 묶어 하나의 그룹)
유니코드의 17개 언어판은 모두 Group 00에 있습니다.
유니코드는 17개의 언어판에 한정되어 정의됩니다.
반면 ISO 표준(UCS-4)에서는 모두 128개의 언어판 그룹이 정의될 수 있습니다.
1 Plane = 65,536 code points
1 Group = 256 planes = 256x65,536 = 16,777,216 code points
UCS-4 = 128 groups = 128x16,777,216 = 2,147,483,648 code points
인코딩, Encoding (문자집합을 표현하는 방식)
유니코드는 코드체계 또는 문자집합을 명명하는 것이며 이를 표현하기 위해서는
UTF-8, UTF-16, UTF-32 등과 같은 인코딩이 필요합니다.
UCS-2: Universal Character Set 2(octets)
좀더 정확하게는 Universal Multipe-Octet Coded Character Set 2입니다.
ISO/IEC 10646의 용어로 BMP의 65,536 코드를 정의하며, 2바이트로 표현됩니다.
1개의 언어판, 즉 BMP만이 이에 해당합니다.
UCS-2는 인코딩 방법이 아니며 문자코드 자체입니다.
인코딩으로 봐도 무방하겠군요. 여기서 octet이라는 용어를 사용했는데 이 용어는
ISO쪽에서 사용하는 용어로, 유니코드 진영에서 사용하는 바이트와 같은 뜻입니다
UCS-4: Universal Character Set 4(octets)
ISO/IEC 10646의 용어로 4바이트로 표현됩니다.
모두 128개의 언어판 그룹, 즉 128*256 언어판 = 32,768 언어판을 정의합니다.
이는 대략 231 = 2,147,483,648개의 코드에 해당합니다.
UCS-4는 인코딩 방법이 아니며 문자코드 자체입니다.
UTF-8: UCS Transformation Format, 8-bit form
Unicode 표준의 인코딩 방식중의 하나입니다.
표준에서는 17개 언어판의 문자만을 표현할 수 있으나 기술적으로는
UCS-4 전영역의 문자를 표현할 수 있습니다.
문자에 따라 1 ~ 4(또는 6) 바이트로 표현됩니다.
UTF-16: UCS Transformation Format, 16-bit form
유니코드 3.0에서는 16을 16비트로 해석한 것이 아니라,
그룹 00의 16개 언어판이라고 써 놓았군요.
UTF-32의 32가 32비트를 지칭하므로 통일성을 위해 16비트로 이해하시는 게 좋습니다.
16비트로 표현한다는 점에서는 UCS-2와 흡사하지만 대행문자영역(Surrogates)을
이용하여 16개의 보충 언어판 코드를 표현할 수 있는 인코딩입니다.
대행문자영역 2개로 16개의 보충 언어판을 표현할 수 있습니다.
UCS-2에서는 65536개의 코드만을 정의할 수 있으나 UTF-16에서는
1백만여자를 더 표현할 수 있습니다.
UTF-32: UCS Transformation Format, 32-bit form
32비트 즉 4바이트로 각 문자를 표현합니다.
이점에서 UCS-4와 동일하지만 17개의 언어판만을 정의한다는 점에서는
UCS-4의 부분집합으로 간주하면 됩니다. UCS-4와 동일하나
0x00000000 ~ 0x0010FFFF 범위만을 문자코드로 간주한다고 이해하시면 됩니다.
/* Detect character encoding with current detect_order */
echo mb_detect_encoding($str);
/* "auto" is expanded to "ASCII,JIS,UTF-8,EUC-JP,SJIS" */
echo mb_detect_encoding($str, "auto");
/* Specify encoding_list character encoding by comma separated list */
echo mb_detect_encoding($str, "JIS, eucjp-win, sjis-win");
/* Use array to specify encoding_list */
$ary[] = "ASCII";
$ary[] = "JIS";
$ary[] = "EUC-JP";
echo mb_detect_encoding($str, $ary);
하지만 한글에 대해선 완벽하게 지원해주지 않는 걸 확인했다. URL의 파라미터에 직접 한글을 입력하여 한 결과 처음 자음이 ㅈ~ㅎ으로 시작하면 UTF-8로 인식한다.
따라 함수를 따로 만들거나 해야 함.
1. detect_encoding함수
Another light way to detect character encoding:
function detect_encoding($string) {
static $list = array('utf-8', 'windows-1251');
foreach ($list as $item) {
$sample = iconv($item, $item, $string);
if (md5($sample) == md5($string))
return $item;
}
return null;
}
2. Function to detect UTF-8, when mb_detect_encoding is not available it may be useful.
Function to detect UTF-8, when mb_detect_encoding is not available it may be useful.
function is_utf8($str) {
$c=0; $b=0;
$bits=0;
$len=strlen($str);
for($i=0; $i<$len; $i++){
$c=ord($str[$i]);
if($c > 128){
if(($c >= 254)) return false;
elseif($c >= 252) $bits=6;
elseif($c >= 248) $bits=5;
elseif($c >= 240) $bits=4;
elseif($c >= 224) $bits=3;
elseif($c >= 192) $bits=2;
else return false;
if(($i+$bits) > $len) return false;
while($bits > 1){
$i++;
$b=ord($str[$i]);
if($b < 128 || $b > 191) return false;
$bits--;
}
}
}
return true;
}
3. conver to Utf8 if $str is not equals to 'UTF-8'
/*
*QQ: 290359552
* conver to Utf8 if $str is not equals to 'UTF-8'
*/
function convToUtf8($str){
if( mb_detect_encoding($str,"UTF-8, ISO-8859-1, GBK")!="UTF-8" ){
return iconv("gbk","utf-8",$str);
}else{
return $str;
}
}
6. Sometimes mb_detect_string is not what you need. When using pdflib for example you want to VERIFY the correctness of utf-8. mb_detect_encoding reports some iso-8859-1 encoded text as utf-8. To verify utf 8 use the following:
//
// utf8 encoding validation developed based on Wikipedia entry at:
// http://en.wikipedia.org/wiki/UTF-8
//
// Implemented as a recursive descent parser based on a simple state machine
// copyright 2005 Maarten Meijer
//
// This cries out for a C-implementation to be included in PHP core
//
function valid_1byte($char) {
if(!is_int($char)) return false;
return ($char & 0x80) == 0x00;
}
function valid_2byte($char) {
if(!is_int($char)) return false;
return ($char & 0xE0) == 0xC0;
}
function valid_3byte($char) {
if(!is_int($char)) return false;
return ($char & 0xF0) == 0xE0;
}
function valid_4byte($char) {
if(!is_int($char)) return false;
return ($char & 0xF8) == 0xF0;
}
function valid_nextbyte($char) {
if(!is_int($char)) return false;
return ($char & 0xC0) == 0x80;
}
function valid_utf8($string) {
$len = strlen($string);
$i = 0;
while( $i < $len ) {
$char = ord(substr($string, $i++, 1));
if(valid_1byte($char)) { // continue
continue;
} else if(valid_2byte($char)) { // check 1 byte
if(!valid_nextbyte(ord(substr($string, $i++, 1))))
return false;
} else if(valid_3byte($char)) { // check 2 bytes
if(!valid_nextbyte(ord(substr($string, $i++, 1))))
return false;
if(!valid_nextbyte(ord(substr($string, $i++, 1))))
return false;
} else if(valid_4byte($char)) { // check 3 bytes
if(!valid_nextbyte(ord(substr($string, $i++, 1))))
return false;
if(!valid_nextbyte(ord(substr($string, $i++, 1))))
return false;
if(!valid_nextbyte(ord(substr($string, $i++, 1))))
return false;
} // goto next char
}
return true; // done
}
for a drawing of the statemachine see: http://www.xs4all.nl/~mjmeijer/unicode.png and http://www.xs4all.nl/~mjmeijer/unicode2.png
여기서 말하는 인코딩이란, 네트워크를 통해서 정보를 공유할 때 어떤 시스템에서나 읽을 수 있는 ASCII 문자로 바꿔주는 것을 말한다. 모든 네트워크를 통한 전송에는 ASCII 문자가 기반이 된다. 특히 한글이나 특수문자의 경우 이를 2진수 바이트코드로 변환해서 전송하면 받는 상대편의 시스템에 따라 잘못 해석되거나, 해석이 불가능할 수 있기 때문이다.
이를 해결하기 위해 모든 시스템에서 공통으로 읽을 수 있는 ASCII 문자로 바꿔서 데이터를 전송할 필요가 있다.
그 변환된 형식은 16진수 형식으로 표시되며 1바이트 문자는 %XX 형태로, 2바이트 문자는 %uXXXX 형태로 변환된다.
1바이트 문자는 빈칸(%20)을 들 수 있고, 2바이트 문자는 한글(%uD55C%uAE00)이 있을 수 있다.
가끔 인터넷검색을 하면 주소창에 %XX형식의 문자들이 들어있는 것을 볼 수 있는데, 이는 인코딩 된 것의 한 종류라고 볼 수 있다.
가끔은 홈페이지의 자바스크립트나 HTML 소스, 음원URL을 보기 힘들게 하기 위해 사용하기도 하지만,
이는 자바스크립트의 인코딩을 아는 자라면 어렵지 않게 풀어 사용할 수 있다.
2. encodeURI()
기본적으로는 escape()와비슷한 동작을 하지만 인터넷 주소표시에 쓰이는 특수문자들을 인코딩하지 않는다.
즉, : ; / = ? & 등의 특수문자는 인코딩이 되지 않는다.
그래서 보통은 파라미터를 전달하는 인터넷주소(URL) 전체를 인코딩할 때 사용한다.
3. encodeURIComponent()
기본적인 동작은 역시 escape()와 비슷하지만 인터넷 주소표시에 쓰이는 모든 문자를 추가로 인코딩한다.
즉, : ; / = ? & 등의 특수문자가 추가로 인코딩 되는 것이다.
그래서 인터넷주소(URL) 전체를 인코딩할 때는 사용할 수 없고, 넘기는 필드 하나하나를 따로 인코딩할 때 사용한다.
그 이유는 넘어가는 값이 text="test=&테스트" 이와 같이 text라는 필드 값이 test=&테스트인 경우 그냥 encodeURI()로 인코딩 하면, '=' 나 '&'는 인코딩되지 않아서 필드값을 처리할 때 데이터값이 아닌 여러개의 필드를 넘기는 명령어로 인식할 수 있기 때문이다.
하지만, "http://test.com/test.php?text=테스트" 와 같은 URL 전체를 encodeURIComponent()로 인코딩하게 되면 : / ? 를 모두 인코딩하여 주소를 인식할 수 없게 된다.
4. 실제 인코딩의 차이를 보여주는 Javascript 소스
var chr = 'http://test.com/folder1/folder2/default.html?mode=write&value=&*테스트';
^^ jQuery framework plugins which provide a way to sort and nest elements in web applications, using drag-and-drop(테이블드래그앤드랍) --활용가능성 중간 http://code.google.com/p/nestedsortables/