##00과 U002F에 대응되므로 기존 API를 약간 수정해서 쓸 수 있다. UTF - 16은 바이트 순서를 나타내기 위하여 바이트 순서 문자 ( BOM, UFEFF ) 가 필요하지만, UTF - 8은 바이트 순서가 정해져 있기 때문에 BOM이 필요하지 않다. 단점 UTF - 8은 가변 길이 인코딩이며, 다른 문자는 다른 바이트 수로 표현될 수 있다. 사실 이 문제는 별로 심각한 것이 아니며, UTF - 8 문자열을 다루기 위한 추상적인 인터페이스를 만드는 것으로 해결될 수 있다. 실제로 기술적으로는 UTF - 16도 BMP 바깥 문자를 4바이트로 표현하기 때문에 가변 길이 인코딩이다. BMP에 들어 있는 한중일 문자들은 UTF - 8에서 3바이트로 표현되지만, UTF - 16에서는 2바이트로 표현된다. 따라서 UTF - 8에서는 이러한 문자를 표현하기 위하여 더 많은 바이트가 필요하며 UTF - 16과 비교할 때 최대 50 % 까지 크기가 늘 수 있다. 하지만 반대로 U00부터 U007F 사이의 글자들은 UTF - 16에서 크기가 두 배로 늘기 때문에 실질적으로는 큰 문제가 없을 수도 있다. 같이 보기
있다.. 단점 나쁘게 만들어진 ( 그리고 현재 표준을 따르지 않는 ) UTF - 8 파서는 서로 다른 가짜 UTF - 8 표현 ( 예를 들어서 너무 긴 형식 ) 을 같은 유니코드 문자열로 해석할 수 있다. 기존의 인코딩들과 비교했을 때 [ 편집 ] 장점 UTF - 8은 모든 유니코드 문자를 표현할 수 있다. 예를 들어서, UCS - 2는 BMP 안의 문자만을 표현할 수 있다. 바이트 경계를 순서대로 혹은 역순으로 찾기 쉽다. 만약 여러 바이트로 표시된 문자의 중간에서 찾기 시작한다면, 단지 해당 문자만 손실되고 나머지 문자들은 손상을 입지 않는다. 기존의 많은 다중바이트 인코딩들은 이러한 재동기화가 훨씬 힘들다. 한 문자를 표현하는 바이트 표현은 다른 문자를 표현하는 어떤 바이트 표현에도 포함되지 않는다. 따라서 ASCII 문자가 아닌 값들에 투명한 파일 시스템이나 다른 소프트웨어 ( 예를 들어서 C의 printf 함수 ) 와 호환성을 가진다. 바이트 표현의 첫 바이트만 사용하여 해당 바이트 표현의 길이를 결정할 수 있다. 따라서 부분 문자열을 얻는 과정이 매우 쉽다. 인코딩에 간단한 비트 연산만 사용되므로 효과적이다. UT
10754 / 11822 MARC - 8 국가 표준 ArmSCII BraSCII CNS 11643 GOST 10859 GB 18030 HKSCS ISCII JIS X 0201 JIS X 0208 JIS X 0212 JIS X 0213 KOI - 7 국규 9566 KS X 1001 PASCII SI 960 TIS - 620 TSCII VISCII YUSCII EUC CN JP KR TW ISO / IEC 2022 CN JP KR CCCII MacOS 코드 페이지 ( " 스크립트 " ) 아랍어 켈트어 센트유로 ChineseSimp / 확장 유닉스 코드 ChineseTrad / Big5 크로아티아어 키릴어 데바나가리 딩뱃 에스페란토 파시 게일어 그리스어 구자라트어 구르무키 히브리어 아이슬란드 일본어 / ShiftJIS 한국어 / 확장 유닉스 코드 Latin - 1 로마어 루마니아어 사미어 심볼 태국어 / TIS - 620 터키어 우크라이나어 도스 코드 페이지 100 111 112 113 151 152 161 162 163 164 165 166 210 220 301 437 449 489 620 667 668 707 708 709 710 711 714 715 720 721 737 768 770 771 772 773 774 775 776 777 778 790 850 851 852 853 85
/ 1370 ( Big5 ) 949 / 1363 ( 확장 유닉스 코드 ) 1169 1174 확장 Latin - 8 1200 ( UTF - 16 ) 1201 ( UTF - 16 ) 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1261 1270 54936 ( GB18030 ) 확장 이진화 십진법 교환 부호 코드 페이지 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 32 33 34 35 36 37 / 1140 38 39 40 251 252 254 256 257 258 259 260 264 273 / 1141 274 275 276 277 / 1142 278 / 1143 279 280 / 1144 281 282 283 284 / 1145 285 / 1146 286 287 288 289 290 293 297 / 1147 298 300 310 320 321 322 330 351 352 353 355 357 358 359 360 361 363 382 383 384 385 386 387 388 389 390 391 392 393 394 395 410 420 / 16804 421 423 424 / 8616 / 12712 425 435 500 / 1148 803 829 833 834 835 836 837 838 / 838 839
##용 판 다른 언어 IndonesiaItaliano 日 本 語 MelayuNederlandsNorsk / 中 文 링크 편집 이 문서는 2019년 3월 29일 ( 금 ) 11 : 01에 마지막으로 편집되었습니다. 모든 문서는 크리에이티브 커먼즈 저작자표시 - 동일조건변경허락 3. 0에 따라 사용할 수 있으며, 추가적인 조건이 적용될 수 있습니다. 자세한 내용은 이용 약관을 참고하십시오. 미국 및 다른 국가에 등록되어 있는 Wikimedia Foundation, Inc. 소유의 등록 상표입니다. 개인정보 정책 위키백과 소개 면책 조항 개발자 쿠키 정책 모바일 보기
부분 문자열을 얻는 과정이 매우 쉽다. 인코딩에 간단한 비트 연산만 사용되므로 효과적이다. UTF - 8은 곱셈이나 같은 느린 연산들을 사용하지 않는다. 단점 대부분의 UTF - 8 문자열은 일반적으로 적당한 기존 인코딩으로 표현한 문자열보다 더 크다. 판독 기호를 사용하는 대부분의 라틴 알파벳 문자는 적어도 2바이트를 사용하며, 한중일 문자들과 표의 문자들은 적어도 3바이트를 사용한다. 한중일 문자들과 표의 문자를 제외한 거의 모든 기존 인코딩들은 한 문자에 1바이트를 사용하므로 문자열 처리가 간편한 반면, UTF - 8은 그렇지 않다. UTF - 7과 비교했을 때 [ 편집 ] 장점 UTF - 8은 한 문자를 표현하는 데 UTF - 7보다 더 적은 바이트들을 사용한다. UTF - 8은 " " 를 그대로 인코딩하지만 UTF - 7은 " - " 로 인코딩한다. 단점 UTF - 8은 8비트 안전한 전송 체계가 필요하다. 전자 우편에서 quoted - printable이나 base64 인코딩을 사용한다면 전송량이 더 많아진다. 예를 들어서 base64 인코딩의 경우 인코딩
##딩 en : Charset detection en : Han unification 하드웨어 ISO 6429 / IEC 6429 / ANSI X3. 64 글자 깨짐 vdeh롭 파이크운영 체제 플랜 9 인페르노 프로그래밍 언어 Newsqueak 림보 Go Sawzall 소프트웨어 acme 블릿 sam rio 출판 The Practice of Programming The Unix Programming Environment 기타 르네 프렌치 마크 V. 셰이니 UTF - 8 vdeh켄 톰프슨운영 체제 유닉스 플랜 9 프로그래밍 언어 B Bon Go 소프웨어 Belle ed Grep sam 스페이스 트래블 톰프슨 셸 기타 UTF - 8 원본 주소 " " 분류 : 유니코드 둘러보기 메뉴 개인 도구 로그인하지 않음토론기여계정 만들기로그인 이름공간 문서토론 변수 보기 읽기편집역사 보기 더 보기 검색 둘러보기 대문사용자 모임요즘 화제최근 문서 보기임의 문서로도움말기부 도구 여기를 가리키는 문서가리키는 글의 최근 올리기특수 문서 목록고유 링크문서 정보위키데이터 항목이 문서 인용하기 인쇄 / 내보내기 책 만들기PDF로 다운로드인쇄용 판 다른 언어 IndonesiaItaliano 日 本 語 MelayuNederlandsNorsk
##64 인코딩을 사용한다면 전송량이 더 많아진다. 예를 들어서 base64 인코딩의 경우 인코딩된 결과는 원본보다 약 33 % 더 커진다. 하지만 최근에는 대부분의 SMTP 서버가 8BITMIME을 지원하기 때문에 이런 단점은 크게 부각되지 않는다. UTF - 16과 비교했을 때 [ 편집 ] 장점 U00부터 U007F까지의 공백과 문장 부호를 포함한 ASCII 문자들은 1바이트로 표현할 수 있기 때문에, 한중일 문자와 표의 문자를 사용하지 않는 대부분의 문자열을 UTF - 16보다 더 작은 크기로 표현할 수 있다. 유닉스의 파일 시스템과 여러 도구들은 기본 단위로 하며, 널 문자와 경로 식별자 ( /, 0x2F ) 에 특별한 의미를 부여하는 경우가 많다. 0x00이나 0x2f U00과 U002F가 아닌 다른 문자에서도 나타날 수 있는 UTF - 16 등의 인코딩과는 달리, UTF - 8은 ASCII와 호환되기 때문에 0x00이나 0x2f 항상 U00과 U002F에 대응되므로 기존 API를 약간 수정해서 쓸 수 있다. UTF - 16은 바이트
##I 문자들은 UTF - 8에서 1바이트만으로 표시된다. 4바이트로 표현되는 문자는 모두 기본 다국어 평면 ( BMP ) 바깥의 유니코드 문자이며, 거의 사용되지 않는다. UTF - 16과 UTF - 8 중 어느 인코딩이 더 적은 바이트를 사용하는지는 문자열에서 사용된 코드 포인트에 따라 달라지며, 실제로 DEFLATE와 같은 일반적인 압축 알고리즘을 사용할 경우 이 차이는 무시할 수 있을 정도이다. 이러한 압축 알고리즘을 사용하기 힘들고 크기가 중요할 경우 유니코드 표준 압축 방식 ( Standard Compression Scheme for Unicode ) 을 대신 사용할 수 있다. 목차 1 구조 2 변형된 UTF - 8 3 UTF - 8의 설계 원칙 4 오류 처리 5 장점과 단점 5. 1 일반적으로 5. 2 기존의 인코딩들과 비교했을 때 5. 3 UTF - 7과 비교했을 때 5. 4 UTF - 16과 비교했을 때 6 같이 보기 7 각주 8 외부 링크 구조 [ 편집 ] UTF - 8은 여러 표준 문서에서 다른 방법으로 정의되어 있지만, 일반적인 구조는 모두 동일하다고 볼 수 있다. 유니코드 코드 포인트를 나타내는 비트들은 여러 부분으로 나뉘어서, UT
UTF - 16에서 크기가 두 배로 늘기 때문에 실질적으로는 큰 문제가 없을 수도 있다. 같이 보기 [ 편집 ] ASCII UCS 바이트 순서 문자 ( BOM ) UTF - 16 각주 [ 편집 ] ↑ 발음 구별 기호가 붙은 라틴 문자, 그리스 문자, 키릴 문자, 콥트 문자, 아르메니아 문자, 히브리 문자, 아랍 문자 외부 링크 [ 편집 ] UTF - 8이 만들어진 계기와 개요 유니코드 용어집 Java 언어를 이용한 유니코드 서로게이트 프로그래밍 Unicode / UTF8 변환 표 vdeh문자 인코딩 문자 집합초기 전기통신 ASCII ISO / IEC 646 ISO / IEC 6937 T. 61 BCDIC 보도 코드 모스 부호 ( 전신 부호 와분 코드 ) 특수 인쇄 전신 부호 : 라틴어가 아닌 계열, 중국어, 키릴 니들 전신 부호 ISO / IEC 8859 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 - 16 서지적 이용 ANSEL ISO 5426 / 5426 - 2 / 5427 / 5428 / 6438 / 6861 / 6862 / 10585 / 10586 / 10754 / 11822 MARC - 8 국가 표준 ArmSCII BraSCII CNS 11643 GOST 10859 GB
UTF-8은 유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로, 켄 톰프슨과 롭 파이크가 만들었다. UTF-8은 Universal Coded Character Set Transformation Format - 8-bit의 약자이다. 본래는 FSS-UTF(File System Safe UCS/Unicode Transformation Format)라는 이름으로 제안되었다. UTF-8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. 예를 들어서, U00부터 U007F 범위에 있는 ASCII 문자들은 UTF-8에서 1바이트만으로 표시된다. 4바이트로 표현되는 문자는 모두 기본 다국어 평면(BMP) 바깥의 유니코드 문자이며, 거의 사용되지 않는다. UTF-16과 UTF-8 중 어느 인코딩이 더 적은 바이트를 사용하는지는 문자열에서 사용된 코드 포인트에 따라 달라지며, 실제로 DEFLATE와 같은 일반적인 압축 알고리즘을 사용할 경우 이 차이는 무시할 수 있을 정도이다. 이러한 압축 알고리즘을 사용하기 힘들고 크기가 중요할 경우 유니코드 표준 압축 방식(Standard Compression Scheme for Unicode)을 대신 사용할 수 있다.