文字コードの話 - Speaker Deck

文字コードの話

by Masaki Hara

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 2024 Wantedly, Inc. 登場人物紹介 ● IBM, DEC, AT&T, NEC: 20世紀のビッグテック。 ● Adobe, Microsoft, Apple, Google: 20世紀〜21世紀のビッグテック。 ● ISO: 工業標準の国際団体。 ● ANSI, JIS, KSA(KS), SAC(GB): それぞれアメリカ、日本、韓国、中華人民共和国の標準化団体。 ● Ecma International: 元々はヨーロッパの情報処理関連の標準化団体。今は国際的に活動している。 ● IEC: 電気・電子系の標準化団体。 ISOとよく協業している。 ● IEEE: 電気電子・情報系の学術団体。今回の登場は控えめ。 ● ITU: 電信・電話・ラジオなどの分野の専門機関。 ● ITSCJ: 日本の情報系の学術団体である IPSJの下部組織で、ISOの文字コード関連業務の秘書業務なども担当している。 ● IETF: インターネットの標準化団体。 ● IANA: インターネットにおける番号や識別子の割り当てを行う管理団体。 ● W3C: Webの標準化団体。 ● WHATWG: ブラウザベンダの業界団体。 ● Unicode Consortium: Unicodeや関連仕様の策定を行うための業界団体。

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2024 Wantedly, Inc. タイプライターの構造打鍵後、紙面が左に送られる。この左右に動く部分をキャリッジという Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et do 紙面 (可動) 本体 (固定部分) キャリッジ (可動部分) カーソル (固定) ※機種による

Slide 12

Slide 12 text

© 2024 Wantedly, Inc. キャリッジリターンレバーを引くと 1. キャリッジが右端に戻る (狭義のCR) 2. 加えて、紙面が上に送られる (Line Feed) Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna ali- 紙面 (可動) 本体 (固定部分) キャリッジ (可動部分) カーソル (固定) キャリッジリターンレバー ※機種による

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 2024 Wantedly, Inc. テレタイプとボドー・マレーコード 19世紀に電信技術が発展し、印刷の自動化も進んだそこで使われた文字コードのひとつに ITA2 がある。 ● 5bit 固定長 + 2状態 (文字/数字) ● 制御コードを文字の一種として扱う ○ 数字モードへの切り替え / 文字モードへの切り替え ○ NULL文字と削除 ○ キャリッジリターンとラインフィード ○ Who are you? ○ ベル

Slide 22

Slide 22 text

© 2024 Wantedly, Inc. 制御コード通信装置と印字装置が一体だった時代に、「制御コード」を文字の一種として扱う慣習が確立制御コードは大きく以下のように大別できる ● 通信の制御 ● エンコーディングの制御 ● 印字の制御 → 現代の計算機では通常イーサネットやTCPなど下位のレイヤでハンドルされるが、ASCIIのDC1/DC3等を使うプロトコルもある → ASCIIのSO/SI等に相当。UTF-8では使わない → ASCIIのHT/CR/LFやUnicodeのCf文字などに相当

Slide 23

Slide 23 text

© 2024 Wantedly, Inc. 文字のレトロニム「文字」の概念が広がったので、旧来の「文字」の概念に名前が必要になった。これらは現代では ● 「図形文字」 (graphic character) あるいは ● 「印字可能文字」 (printable character) と呼ばれるスペースは何も印字しないが、図形文字の一種として扱うことが多い。結合文字は特殊な印字規則を持つが、図形文字の一種として扱う。

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2024 Wantedly, Inc. パンチカードによる統計 ● ソーター: パンチカードを、穴の位置に応じて分類する機械 ○ GROUP BY と ORDER BY に相当 ● 作表機: パンチカードを集計する機械 ○ 基本的には特定の位置に空いた穴の数を数える ○ SELECT COUNT(*) に相当 ● 初期の統計機械は電気機械的に実装された ○ たとえば、パンチ穴があるときだけ回路が導通し、カウンター機械 (アキュムレーター) が機械的に作動する

Slide 29

Slide 29 text

© 2024 Wantedly, Inc. IBM 80列パンチカード ● 1928年登場、汎用のパンチカード ● 10行 × 80列 ● 各列で、0〜9のうち1つに穴をあける ○ 穿孔や統計のシステム上、このような “one-hot” 形式が都合がよかったのかも 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

Slide 30

Slide 30 text

© 2024 Wantedly, Inc. IBM 80列パンチカード (拡張) ● 1930年に拡張 ● 12行 × 80列 ● 複数行に同時に穴をあけて使う 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2024 Wantedly, Inc. 1940s〜1950s ● 1940s: 電子計算機が登場 (ENIAC, EDSAC, etc.) ● 1950s: 汎用化/量産化 (UNIVAC, IBM 701, etc.) ○ 量産といっても、大きくて高価なものであり、研究機関や政府の統計局などが購入するものだった ● パンチカードに書かれていた情報も電子的に処理されるようになっていく ○ それまでは電気機械的に処理していた

Slide 36

Slide 36 text

© 2024 Wantedly, Inc. BCD ● 12bitコードは電子計算機用としては冗長 ● 0〜9 を2進数で表現すれば4bit + 2bitで表せる → BCD (Binary Coded Decimal) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x space 1 2 3 4 5 6 7 8 9 0 # @ 1x / S T U V W X Y Z , % 2x - J K L M N O P Q R $ * 3x & A B C D E F G H I . ⌑ 初期のBCD (1950年頃) 6bitコードには他にECMA-1やFieldataなどもある

Slide 37

Slide 37 text

© 2024 Wantedly, Inc. EBCDIC ● 1960年代、ASCIIが使われはじめる ○ IBMはASCIIの推進にも関わっており、System/360ではASCIIの8bit亜種もサポートされる予定だった ● 一方、IBMの顧客はBCDで記録されたデータを多数持っていた ● → BCDを拡張した8bitコード (EBCDIC) を制定 ○ System/360 で採用 ○ BCDの拡張であるため、英文字が連続していないなどの特徴がある EBCDICにも多数の亜種があり、ASCII系のコードの進化にあわせて進化しているが、本発表では以降はASCII系のコードのみ扱う。 ※ASCII-1963の下から6bit目に0を入れ、上位2bitをシフトしたようなもの

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© 2024 Wantedly, Inc. ASCII-1963 ● 1963年に米国標準として制定された7bitコード ● 現在のASCIIとは結構違う (特に、小文字がない) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x NUL SOM EOA EOM EOT WRU RU BEL FEO HT LF VT FF CR SO SI 1x DC0 DC1 DC2 DC3 DC4 ERR SYN LEM S0 S1 S2 S3 S4 S5 S6 S7 2x SP ! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ?

Slide 41

Slide 41 text

© 2024 Wantedly, Inc. ASCII-1963 ● 1963年に米国標準として制定された7bitコード ● 現在のASCIIとは結構違う (特に、小文字がない) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 4x @ A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ \ ] ↑ ← 6x 7x ACK ESC DEL

Slide 42

Slide 42 text

© 2024 Wantedly, Inc. ASCII-1965 ● 1965年の改訂版 ● 小文字が追加され、 ↑ と ← が ^ と _ になった x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI 1x DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SS ESC FS GS RS US 2x SP ! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 冪乗はもともと x↑y のように書かれていたので、この改訂で x^y という記法が成立したと言われているただし、この版は出版されることはなかった

Slide 43

Slide 43 text

© 2024 Wantedly, Inc. ASCII-1965 ● 1965年の改訂版 ● 小文字が追加され、 ↑ と ← が ^ と _ になった x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 4x ` A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ ~ ] ^ _ 6x @ a b c d e f g h i j k l m n o 7x p q r s t u v w x y z { ¬ } | DEL 冪乗はもともと x↑y のように書かれていたので、この改訂で x^y という記法が成立したと言われているただし、この版は出版されることはなかった

Slide 44

Slide 44 text

© 2024 Wantedly, Inc. ASCII-1967 ● 1967年に、現在のASCIIとおおむね同等になった x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI 1x DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US 2x SP ! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ?

Slide 45

Slide 45 text

© 2024 Wantedly, Inc. ASCII-1967 ● 1967年に、現在のASCIIとおおむね同等になった x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 4x @ A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ \ ] ^ _ 6x ` a b c d e f g h i j k l m n o 7x p q r s t u v w x y z { | } ~ DEL

Slide 46

Slide 46 text

© 2024 Wantedly, Inc. ASCII - 制御コード ● 制御コードは 0x00 〜 0x1F と 0x7F ○ パンチカードでは穿孔が不可逆操作のため、文字を抹消するために 0b1111111 がDELに割り当てられた ○ 残りの制御コードはまとまった領域に確保された ● 0x00 〜 0x1F を C0制御コードという制御コードに意味が決まっていても、機器やソフトウェアがそれを実装しているとは限らないので注意。

Slide 47

Slide 47 text

© 2024 Wantedly, Inc. ASCII - 制御コード ● CR / LF … CRはキャリッジの復帰、LFは行送りに由来 ○ 実装差異があり、改行を CR+LF, CR単独, またはLF単独で表すことがある ○ C1制御コードのNELのほうが意味は明確だが、あまり使われない ● HT / VT … タブ ○ HT はタイプライターで作表用にキャリッジの位置を飛ばす機能に由来 ○ VT はその垂直版 ● BS … バックスペース ● FF … ページ送り

Slide 48

Slide 48 text

© 2024 Wantedly, Inc. ASCII - 制御コード ● NUL / DEL ○ NULはデータがない状態。DELはデータが抹消された状態であり、読み飛ばす。 ○ NULはCの文字列終端としても使われる ● SOH, STX, ETX, EOT … メッセージの構造指定 ● FS, GS, RS, US … データの区切り ○ JSON Text Sequence などで微妙に使われることも ● EM … ストレージの終わり ● SUB … Unicodeの � と類義だが、EOFとしても扱われる

Slide 49

Slide 49 text

© 2024 Wantedly, Inc. ASCII - 制御コード ● BEL … 受信側でベルやビープ音を鳴らす ● ENQ, ACK, DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN … その他通信用 ● SO, SI … 文字集合の切り替え (シフト) ● ESC … エスケープシーケンスの開始 ↑SO, SI, ESC はあとで出てくるので覚えておいてください

Slide 50

Slide 50 text

© 2024 Wantedly, Inc. Control キー Control キー: 元々はC0制御コードを発生させる修飾キー ● 文字 & 0x1F が送信される ○ たとえば “J” は 0x6A なので、 0x6A & 0x1F = 0x0A = LF が送信される ● よく使われるControlキー ○ ^@ = NUL ○ ^C = ETX → SIGINT ○ ^J = LF, ^M = CR ○ ^D = EOT → EOF, ^Z = SUB → EOF or SIGTSTP ○ ^[ = ESC

Slide 51

Slide 51 text

© 2024 Wantedly, Inc. ASCII - 図形文字 ● 0x20 〜 0x7E (0x7F は含まない) が図形文字 ● 数字、英文字 (大文字・小文字) と記号類を収録 ○ 0/1 と O/I は区別される ○ 数字・英文字ともに順に並ぶが、大文字と小文字は別ブロックなのでコレーションでは注意が必要 ● シフト関係 ○ 2列目と 3列目 ○ 4〜5列目と 6〜7列目 ○ 一般的な日本語キーボード配列は ASCIIのシフト関係を強く反映している

Slide 52

Slide 52 text

© 2024 Wantedly, Inc. ASCII - 図形文字 ● - は hyphen-minus と呼ばれる ○ ハイフンとマイナスの兼用だが、ダッシュにも使われる ● " は引用符 (開き・閉じ兼用) ● ' はアポストロフィー ○ 引用符 (開き・閉じ兼用) やプライムにも使われる ● ^ ~ ` はサーカムフレックス、チルダ、鈍アクセント ○ 本来はダイアクリティカルマークなので上付きだが、今では中央にも書かれる ○ ` は開き引用符、 ~ はスワングダッシュとして使われることもある

Slide 53

Slide 53 text

© 2024 Wantedly, Inc. ASCII - 図形文字 ● _ は下線 ○ 文字に重ね打ちして下線を引くためのものだった ● < > は不等号 ○ 山括弧として使われることもある ● # は番号記号 (井桁) ○ シャープ ♯ の代用表記としても使われる (C# など) が、斜線の向きが異なる ● | は縦棒 ○ 中置記法が多いが、数学等では括弧のように使われることがある ○ 異書体 (allograph) として ¦ が使われることもある

Slide 54

Slide 54 text

© 2024 Wantedly, Inc. プログラミング言語とASCII 0-9 A-Z ( ) * + , - . / = FORTRAN (on IBM 704) LISP 1 0-9 A-Z ( ) , $ も条件によって使用可能 LISP-1のReference Manualによると、本来のS式のリスト記法ではコンマが使われる予定だったが、事故によりコンマが省略可能となった。 M式では [ ] ; も利用される。 1954 1958 0-9 A-Z " ( ) * + , - . / ; < = > COBOL-60 1960

Slide 55

Slide 55 text

© 2024 Wantedly, Inc. プログラミング言語とASCII C (K&R 1st) 0-9 A-Z a-z ! " # % & ' ( ) * + , - . / : ; < = > ? [ \ ] ^ { | } ~ APL 0-9 A-Z A-Z ⍞ ⎕ ! ' ( ) × ⋆ + , − . / ÷ ⌹ : ; < ≤ = ≥ > ≠ ? ⌈ ⌊ [ \ ] ↑ ↓ _ ∣ ≡ ∨ ⍱ ∧ ⍲ ¬ ∼ ¯ ¨ ∈ ⊂ ⊃ ∩ ∪ ⊥ ⊤ ⍝ ○ ⍟ ⌽ ⊖ ⍉ ⍋ ⍒ ∇ ⍫ Δ ⍙ ⍎ ⍕ ⍪ ⌿ ⍀ ⍺ ⍳ ⍴ ⍵ ∘ 1962 ALGOL-60 0-9 A-Z a-z ' ( ) × + , - . / ÷ : ; < ≤ = ≥ > ≠ ? [ ] ↑ ≡ ⊃ ∨ ∧ ¬ ` ₁₀ ␣ 1960 1972

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

© 2024 Wantedly, Inc. 言語と国 ● 言語 vs 国カナダアメリカ英語フランス語フランススペイン語そもそも、「ある国である言語が話されているか ?」というのはゼロイチではなく、公用語としての地位・事実上の公用語としての地位・ネイティブスピーカーの割合・ノンネイティブスピーカーの割合などさまざまな尺度が存在し、同じ国の中での地域差もある。それを差し引いてもなお多様な関係があるというのが、以下の図。

Slide 64

Slide 64 text

© 2024 Wantedly, Inc. 文字と言語 ● 文字 & 表記体系 vs 言語 Script Writing Systems 英語フランス語ラテン文字ベトナム語漢字英語の表記体系フランス語の表記体系クオックグーチュノム中国語中国語の表記体系日本語平仮名片仮名日本語の表記体系日本語のラテン文字表記体系などもある (ローマ字運動) が、省略している。複数の文字のうちいずれかを使うものが多いが、日本語 (の漢字による表記体系 )では 3つの文字を組み合わせて書かれる。

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

© 2024 Wantedly, Inc. コードページ ● 様々な文字エンコーディングに番号をつけて管理 ● IBMとMSのものが有名 ○ 元々はコード表が記載された本のページ番号だったらしい ○ MSはIBMと同じ番号体系だったが、OSでの協業をやめてからは独自に番号を割り当てている ● 代表的なもの ○ IBM/MSコードページ 932 (Shift_JIS 派生) ○ Windows-1252 ○ MSコードページ 65001 (UTF-8)

Slide 68

Slide 68 text

Slide 69

Slide 69 text

© 2024 Wantedly, Inc. MIME Type ● Content-Type: text/plain; charset=utf-8 ○ 元々はメールプロトコルの拡張機能として 1992年に導入されたもの ○ 今ではHTTPで見ることが多い ● RFC 2978の規定により、IANAが文字コードの名前を管理 ○ ただし、実際のブラウザの判別アルゴリズムは WHATWG MIME Sniffingに規定

Slide 70

Slide 70 text

Slide 71

Slide 71 text

© 2024 Wantedly, Inc. ISO/IEC 646 ISO/IEC 646 (ECMA-6) ● ASCIIベースの各国用7bitコード ● 置換できるのは12文字だけ ○ 2行目の記号から #, $ を置換可能 (# → £, $ → ¤ のみ) ○ 4〜5行目の記号から @, [, \, ], ^ を置換可能 ○ 6〜7行目の記号から `, {, |, }, ~ を置換可能 ● 12文字ではラテン文字の拡張くらいしかできない ○ 他の方法については後述「各言語用」ではなく「各国用」という扱いだったたとえば通貨記号を追加したイギリス版がある

Slide 72

Slide 72 text

© 2024 Wantedly, Inc. ISO/IEC 646 IRV 1973 1973年の ISO/IEC 646 の「デフォルト版」として定義されたコード (IRV) 0x33 # 0x34 $ 0x40 @ 0x5B [ 0x5C \ 0x5D ] 0x5E ^ 0x60 ` 0x7B { 0x7C | 0x7D } 0x7E ~ # ¤ @ [ \ ] ^ ` { | } ‾ ドル ↓ 国際通貨記号チルダ ↓ オーバーライン 2度の改訂を経て、現在はIRV = ASCIIとなっている ã と ā では意味が違う点に注意 (そもそもオーバーラインとマクロン自体が違う記号)

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

© 2024 Wantedly, Inc. ISO/IEC 646 と C - Trigraph と Digraph # $ @ [ \ ] ^ ` { | } ~ Trigraph ??= ??( ??/ ??) ??' ??< ??! ??> ??- Digraph %: <: :> <% %> | || |= bitor or or_eq ~ compl ^ ^= xor xor_eq & && &= bitand and and_eq ! != not not_eq 代替トークン (iso646.h) # ## %: %:%:

Slide 79

Slide 79 text

© 2024 Wantedly, Inc. JIS X 0201 ラテン文字用図形文字集合 IRV (1973年版) をもとにドル記号と円記号を定義 0x33 # 0x34 $ 0x40 @ 0x5B [ 0x5C \ 0x5D ] 0x5E ^ 0x60 ` 0x7B { 0x7C | 0x7D } 0x7E ~ # $ @ [ ¥ ] ^ ` { | } ‾ 通貨記号用として使えそうな 0x33, 0x34は置換先の記号が £ と ¤ に限定されていた。そのため \ を置換対象に選んだのではないかと思う。

Slide 80

Slide 80 text

Slide 81

Slide 81 text

© 2024 Wantedly, Inc. 文字集合の拡大 ASCIIにさらに文字を足すには以下のいずれかが必要 ● 文字集合の切り替え機能をつける ● 8bitに増やす ● (上に加えて)マルチバイト文字の導入 → ISO/IEC 2022 (ECMA-35) もちろん、ビット数を8bitに増やすには、関連する機器やソフトウェアがそれに対応している必要がある。しかし時代の流れは、8bitをフルに使える方向に進んでいった。

Slide 82

Slide 82 text

Slide 83

Slide 83 text

© 2024 Wantedly, Inc. 文字集合と符号化方式せっかく定義した文字集合を使い回したい → 文字集合と符号化方式の分離 (符号化)文字集合 (CCS) 文字に番号をつける符号化方式 (CES) 番号をバイト列に対応づけるとはいっても、任意の文字集合を任意の方式で符号化できるわけではない。たとえばJIS X 0208をUTF-8で符号化することはできない。あくまで緩くモジュラー化するための枠組みだと考えるのがベスト。文字エンコーディング (character encoding) このような区別は後から生じたものであるため、文字エンコーディングのことを charsetと呼ぶこともある。

Slide 84

Slide 84 text

Slide 85

Slide 85 text

© 2024 Wantedly, Inc. ISO/IEC 2022の基本構造 ● 8bit空間を CL / GL / CR / GR の 4つに分割 ● CL / CR は制御コード ● GL / GR は図形文字 ○ ただし DEL が入る場合、それは制御コードとして扱う 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR 規格文書ではこの図を45度で反転した形で書かれることが多いが、本スライドでは横向きで統一する。

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

© 2024 Wantedly, Inc. JIS X 0201 JIS X 0201 (JIS C 6220) は以下の2つの集合を規定 ● ラテン文字用図形文字集合 (A, B, C, …) ○ ISO/IEC 646 互換, G0に指示 ● 片仮名図形文字集合 (ア, イ, ウ, …) ○ いわゆる半角カタカナ, G1に指示 7bitで運用する場合、SIでカタカナに切り替え、 SOでラテン文字に戻す

Slide 89

Slide 89 text

© 2024 Wantedly, Inc. JIS X 0201 片仮名図形文字集合 ● カタカナを含む63文字を定義 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 2x 。「」、・ヲァィゥェォャュョッ 3x ーアイウエオカキクケコサシスセソ 4x タチツテトナニヌネノハヒフヘホマ 5x ミムメモヤユヨラリルレロワン゛゜ 6x 7x いわゆる半角カナ。ただし、半角 vs. 全角については後述これが最初のカナ文字コードというわけではないが、現代での重要度を考慮してこれを紹介

Slide 90

Slide 90 text

© 2024 Wantedly, Inc. JIS X 0201 片仮名図形文字集合 ● 仮名の基本文字は46文字 ○ 促音と拗音に使われる捨て仮名は 9文字 ○ 濁点つきの文字が最低17文字、半濁点つきの文字が最低 5文字必要だが、濁点と半濁点を別の文字に分けて2文字に節約している ● 94文字ある領域のうち、全体の2/3にあたる63文字しか使っていない ○ このことがあとのShift_JISの制定につながるヰとヱは除く

Slide 91

Slide 91 text

© 2024 Wantedly, Inc. シフトイン・シフトアウト ● SOとSIで切り替え 4A 6F 68 6E 0F 3B 5D 20 31 43 20 43 5E 3D 36 0E 3F J o h n サンアテテ゛スカ ? Shift In Shift Out 制御コードをエンコードに使うということは、その制御コード自体を表現することができない (または、難しくなる) ことを意味する。実用的には、これが問題になることはそれほど多くないはず。

Slide 92

Slide 92 text

© 2024 Wantedly, Inc. КОИ-7 Н1 ロシア語で使われたコードの例 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 2x ! " # ¤ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 4x ю а б ц д е ф г х и й к л м н о 5x п я р с т у ж в ь ы з ш э щ ч ъ 6x Ю А Б Ц Д Е Ф Г Х И Й К Л М Н О 7x П Я Р С Т У Ж В Ь Ы З Ш Э Щ Ч 2行に収めるためにЁ/ё/Ъを削っている点、ASCIIとの対応関係のためにアルファベット順を変更している点が興味深い

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

© 2024 Wantedly, Inc. 8bitコード ● 8bitになることで、2つの文字集合を切り替えずに同時に使えるようになる ○ 自己同期符号の条件を満たすことが (場合によっては) 可能 ● 7bit用に定義したものをGRにマップして使うだけ! ○ ISO/IEC 2022のおかげ ○ JIS X 0201 はそのまま8bitコードとしても使える (ANKコード) ○ КОИ-7 は文字を整理して КОИ-8 になった

Slide 96

Slide 96 text

Slide 97

Slide 97 text

© 2024 Wantedly, Inc. C1制御コード ● ISO/IEC 2022 にはCR領域もある ● ここには通常 ISO/IEC 6429 由来のC1制御コードが入る x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 8x PAD HOP BPH NBH IND NEL SSA ESA HTS HTJ VTS PLD PLU RI SS2 SS3 9x DCS PU1 PU2 STS CCH MW SPA EPA SOS SGC SCI CSI ST OSC PM APC

Slide 98

Slide 98 text

Slide 99

Slide 99 text

Slide 100

Slide 100 text

© 2024 Wantedly, Inc. ISO/IEC 8859 À È ß Ą Ł Đ À Ş Ż Å Õ Ļ Э Ю Я ج ب ا Φ Ψ Ω ג ב א İ Ö Ğ ก ซ ฏ Å Ä Ø Ą Ł Š Á Ḃ Ŷ È Œ ß Ç Ž Ő 1: 西欧 2: 中欧 3: 南欧 4: 北欧 5: キリル文字 6: アラビア文字 7: ギリシャ文字 8: ヘブライ文字 9: トルコ 10: ノルド系 11: タイ文字 12: 破棄 13: バルト沿岸 14: ケルト 15: 西欧(再編) 16: 南東欧

Slide 101

Slide 101 text

Slide 102

Slide 102 text

© 2024 Wantedly, Inc. ISO/IEC 8859-1 ● Part 1 (Latin-1 とも呼ばれる) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax NBSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ SHY ® ¯ Bx ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ Cx À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Dx Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß Ex à á â ã ä å æ ç è é ê ë ì í î ï Fx ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ

Slide 103

Slide 103 text

© 2024 Wantedly, Inc. ISO/IEC 8859-1 ● NBSP, SHY ○ NBSPはスペースだが、折り返し禁止。数値の区切りなどで使われる。 ○ SHYは折り返し可能な位置を表すが、折り返したときはハイフンになる。 ○ これらはフォーマットを制御する文字だが、制御コードではなく図形文字として扱われる。 ● ¦, ¯, ¥ ○ ¦, ¯ はそれぞれ | と ~ の異書体 (allograph) だったもの。 ○ ¥ はJIS X 0201では5Cに収録されていたが、ISO/IEC 8859-1ではA5に収録されている

Slide 104

Slide 104 text

© 2024 Wantedly, Inc. ISO/IEC 8859-11 ● Part 11: タイ文字 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax NBSP ก ข ฃ ค ฅ ฆ ง จ ฉ ช ซ ฌ ญ ฎ ฏ Bx ฐ ฑ ฒ ณ ด ต ถ ท ธ น บ ป ผ ฝ พ ฟ Cx ภ ม ย ร ฤ ล ฦ ว ศ ษ ส ห ฬ อ ฮ ฯ Dx ะ ั า ํา ิ ี ึ ื    ฿ Ex เ แ โ ใ ไ ๅ ๆ ็ ่ ้ ๊ ๋ ์ ํ ๎ ๏ Fx ๐ ๑ ๒ ๓ ๔ ๕ ๖ ๗ ๘ ๙ ๚ ๛

Slide 105

Slide 105 text

Slide 106

Slide 106 text

Slide 107

Slide 107 text

Slide 108

Slide 108 text

Slide 109

Slide 109 text

Slide 110

Slide 110 text

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

© 2024 Wantedly, Inc. JIS X 0213 JIS X 0213: JIS X 0208に漢字2面を追加して拡張 ● したがって、日本語では主に以下の4面を扱うことになる最初の出版は2000年 123ABC ラテン文字用文字集合 (JIS X 0201) またはASCII アイウ、。片仮名用文字集合 (JIS X 0201) あいうアイウ安以宇衣於加漢字コード第1面 (JIS X 0208 / JIS X 0213) 丂佔坯宁杌泬綌䚯邡阬骯𩸕漢字コード第2面 (JIS X 0212 / JIS X 0213)

Slide 114

Slide 114 text

© 2024 Wantedly, Inc. JIS X 0208 / JIS X 0213 JIS X 0208 / JIS X 0213 を使う主な文字エンコーディング ● EUC-JP 系コード ● ISO-2022-JP 系コード ● Shift_JIS 系コードここではEUC-JPを紹介し、ISO-2022-JPとShift_JISについては後述する …… が、その前にJISが公式に定義するエンコーディングを紹介後述するように、これはJIS規格の本文には定義されていない。ただし、現在は附属書に定義がある。

Slide 115

Slide 115 text

© 2024 Wantedly, Inc. JISの「公式」エンコーディング JIS X 0201 本文§6規定の文字エンコーディング G0 G1 G2 G3 7bitラテン文字コード JIS X 0201 ラテン文字 – – – 7bit片仮名コード JIS X 0201 片仮名 – – – 7bitコード JIS X 0201 ラテン文字 JIS X 0201 片仮名 – – SI/SOで切り替え 8bitコード (ANK) JIS X 0201 ラテン文字 JIS X 0201 片仮名 – – GR領域を利用注: EUC-JP, ISO-2022-JP, Shift_JIS のいずれでもない (Shift_JISは上記8bitコードの上位互換)

Slide 116

Slide 116 text

© 2024 Wantedly, Inc. JISの「公式」エンコーディング JIS X 0213 本文§7規定の文字エンコーディング G0 G1 G2 G3 7bit漢字コード漢字1面漢字2面 – – SI/SOで切り替え 7bit ISO/IEC 646 互換コード JIS X 0201 ラテン文字またはASCII 漢字1面 – 漢字2面 SI/SO/SS3で切り替え 8bit漢字コード漢字1面漢字2面 – – GR領域を利用 8bit ISO/IEC 646 互換コード JIS X 0201 ラテン文字またはASCII 漢字1面 – 漢字2面 GR領域を利用し、 SS3で切り替え注: EUC-JP, ISO-2022-JP, Shift_JIS のいずれでもない (EUC-JPは上記8bit ISO/IEC 646互換コードの上位互換 )

Slide 117

Slide 117 text

© 2024 Wantedly, Inc. JISの「公式」エンコーディング JIS X 0213 (2面がない場合) G0 G1 G2 G3 7bit漢字コード漢字1面 – – – 7bit ISO/IEC 646 互換コード JIS X 0201 ラテン文字またはASCII 漢字1面 – – SI/SOで切り替え 8bit ISO/IEC 646 互換コード JIS X 0201 ラテン文字またはASCII 漢字1面 – – GR領域を利用注: EUC-JP, ISO-2022-JP, Shift_JIS のいずれでもない (EUC-JPは上記8bit ISO/IEC 646互換コードの上位互換 )

Slide 118

Slide 118 text

© 2024 Wantedly, Inc. EUC-JP EUC = Extended Unix Code ● Unix系OSを中心に採用されたコード群 ○ EUC-KR, EUC-CN なども存在 ● ISO/IEC 2022 から状態を排した8bitコード ○ G0, G1, G2, G3 に文字コードをあらかじめ指示しておいた状態でスタート ○ G0はGL, G1はGRに呼び出し ○ SS2とSS3を使うことで一時的にG2, G3をGRに呼び出せる ○ 指示・呼び出しについて詳しくは後述

Slide 119

Slide 119 text

Slide 120

Slide 120 text

© 2024 Wantedly, Inc. EUC-JP系エンコーディング ● 漢字コード第1面を優先する形でG0〜G3を割り当て G0 G1 G2 G3 文字集合ラテン文字用文字集合漢字コード第1面片仮名用文字集合漢字コード第2面符号化 GL (20〜7F) に直接マップ GR (A0〜FF) に直接マップ SS2 (8E) を前置 SS3 (8F) を前置バイト数 1 2 2 (1 + 1) 3 (1 + 2) 例 41 A A4 A2 あ [8E] B1 ア [8F] A1 A2 丂 C0, C1制御コードは普通に使える (エンコーディングに使うもの自身を除く)

Slide 121

Slide 121 text

Slide 122

Slide 122 text

Slide 123

Slide 123 text

© 2024 Wantedly, Inc. EUC-JP vs. JIS X 0213 符号化方式 EUC-JP と JIS規格の符号化方式は以下の点で異なる ● EUC-JPはJIS X 0201 片仮名を呼び出せる ○ JIS X 0213の符号化方式では、片仮名集合は呼び出せないことになっている ● EUC-JPは漢字コード1面の英数領域の使用を許可している ○ JIS X 0213の符号化方式では、ASCIIと併用する場合、同じ文字が収録された漢字コードの領域の利用を禁止しているこれについて次で説明

Slide 124

Slide 124 text

Slide 125

Slide 125 text

Slide 126

Slide 126 text

© 2024 Wantedly, Inc. 文字の幅 ● 欧文組版: 字幅は連続的で、フォントによって決まる ● 欧文タイプライター: 字幅は固定 ○ 文字は縦長 ○ 同様の仕様がテレタイプや仮想端末でも採用された ● 和文組版: 基本的に字幅は固定 ○ 基本は正方形で、この幅を全角という ○ 組版規則に基づき、半角 (二分; 1/2) や四分 (1/4) を組み合わせて使う全てのタイプライターが固定幅というわけではない。また、固定幅は単に技術的な制約があるときだけではなく、位置揃えが有益である場合にも使われる。ただし、em と en の2つが文字幅の基準としてよく使われる

Slide 127

Slide 127 text

Slide 128

Slide 128 text

© 2024 Wantedly, Inc. 文字幅とJIS X 0201 ● JIS X 0201 の片仮名は、慣習的に英数と同じ幅で印字されることが多かった ○ おそらく、幅を切り替える技術的な困難によるもの (JIS X 0201は1969年) ○ また、JIS X 0201 は JIS X 0208 とは異なり1byteコードであるため、ソフトウェアの大規模な改造をしなくても文字のイメージデータ (キャラクタROM) の差し替えで動かせたのかもしれない Mintﾐﾝﾄ Mintミント

Slide 129

Slide 129 text

Slide 130

Slide 130 text

Slide 131

Slide 131 text

Slide 132

Slide 132 text

Slide 133

Slide 133 text

Slide 134

Slide 134 text

Slide 135

Slide 135 text

Slide 136

Slide 136 text

Slide 137

Slide 137 text

© 2024 Wantedly, Inc. JIS X 0208 区割り JIS X 0208の区割り (1byte目) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あア Ω Я ┨ Bx 亜院押魁粥機供掘検后此察次宗勝拭 Cx 澄繊臓叩帖邸董如函鼻福法漫諭痢蓮 Dx 弌僉辧咫圈奸屐廖悄戞據曄棔檗沺漾 Ex 燹瓠癲磧筺紂罅隋茵蕁蝓襦譟蹇遏錙 Fx 陝顱髻鵝堯非漢字についてはわかりやすさのため恣意的に代表文字を選定した。

Slide 138

Slide 138 text

Slide 139

Slide 139 text

© 2024 Wantedly, Inc. JIS X 0208 区割り第1水準 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あア Ω Я ┨ Bx 亜院押魁粥機供掘検后此察次宗勝拭 Cx 澄繊臓叩帖邸董如函鼻福法漫諭痢蓮 Dx 弌僉辧咫圈奸屐廖悄戞據曄棔檗沺漾 Ex 燹瓠癲磧筺紂罅隋茵蕁蝓襦譟蹇遏錙 Fx 陝顱髻鵝堯読みの五十音順

Slide 140

Slide 140 text

Slide 141

Slide 141 text

© 2024 Wantedly, Inc. JIS X 0208 区割り空き領域 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あア Ω Я ┨ Bx 亜院押魁粥機供掘検后此察次宗勝拭 Cx 澄繊臓叩帖邸董如函鼻福法漫諭痢蓮 Dx 弌僉辧咫圈奸屐廖悄戞據曄棔檗沺漾 Ex 燹瓠癲磧筺紂罅隋茵蕁蝓襦譟蹇遏錙 Fx 陝顱髻鵝堯文字が書かれているのに色が塗られている部分は、同じ区の中で部分的に空き領域がある。

Slide 142

Slide 142 text

© 2024 Wantedly, Inc. JIS X 0213 漢字第1面区割り JIS X 0213 漢字第1面の区割り (1byte目) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あア Ω Я ┨ À Ą Œ ❶ ① 俱咩 Bx 亜院押魁粥機供掘検后此察次宗勝拭 Cx 澄繊臓叩帖邸董如函鼻福法漫諭痢蓮 Dx 弌僉辧咫圈奸屐廖悄戞據曄棔檗沺漾 Ex 燹瓠癲磧筺紂罅隋茵蕁蝓襦譟蹇遏錙 Fx 陝顱髻鵝堯擄㯃滇琇硃絁菑訢釥顗

Slide 143

Slide 143 text

© 2024 Wantedly, Inc. JIS X 0213 漢字第1面区割り追加の非漢字 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あア Ω Я ┨ À Ą Œ ❶ ① 俱咩 Bx 亜院押魁粥機供掘検后此察次宗勝拭 Cx 澄繊臓叩帖邸董如函鼻福法漫諭痢蓮 Dx 弌僉辧咫圈奸屐廖悄戞據曄棔檗沺漾 Ex 燹瓠癲磧筺紂罅隋茵蕁蝓襦譟蹇遏錙 Fx 陝顱髻鵝堯擄㯃滇琇硃絁菑訢釥顗

Slide 144

Slide 144 text

© 2024 Wantedly, Inc. JIS X 0213 漢字第1面区割り第3水準 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あア Ω Я ┨ À Ą Œ ❶ ① 俱咩 Bx 亜院押魁粥機供掘検后此察次宗勝拭 Cx 澄繊臓叩帖邸董如函鼻福法漫諭痢蓮 Dx 弌僉辧咫圈奸屐廖悄戞據曄棔檗沺漾 Ex 燹瓠癲磧筺紂罅隋茵蕁蝓襦譟蹇遏錙 Fx 陝顱髻鵝堯擄㯃滇琇硃絁菑訢釥顗

Slide 145

Slide 145 text

Slide 146

Slide 146 text

Slide 147

Slide 147 text

Slide 148

Slide 148 text

Slide 149

Slide 149 text

Slide 150

Slide 150 text

© 2024 Wantedly, Inc. ESC ESC (0x1B) + 図形文字 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 2x 0F 1F 2F 3F 4F 5F 6F 7F 8F 9F 10F 11F 12F 13F 14F 15F 3x 4x PAD HOP BPH NBH IND NEL SSA ESA HTS HTJ VTS PLD PLU RI SS2 SS3 5x DCS PU1 PU2 STS CCH MW SPA EPA SOS SGC SCI CSI ST OSC PM APC 6x DMI INT EMI RIS CMD LS2 LS3 7x LS3R LS2R LS1R nF Fp Fe Fs

Slide 151

Slide 151 text

© 2024 Wantedly, Inc. ESC 参考: 元の図形文字 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 2x SP ! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 4x @ A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ \ ] ^ _ 6x ` a b c d e f g h i j k l m n o 7x p q r s t u v w x y z { | } ~

Slide 152

Slide 152 text

© 2024 Wantedly, Inc. ESC ● ESC + 20〜2F は nF と呼ばれる ○ 3F 以外の15種は ISO/IEC 2022 で利用 ● ESC + 30〜3F は Fp と呼ばれる (私用領域) ● ESC + 40〜5F は Fe と呼ばれる (C1と対応) ○ C1コードを直接呼び出してもよい。 ○ SS2/SS3 を ISO/IEC 2022 で利用 ● ESC + 60〜7F は Fs と呼ばれる (標準領域) ○ CMD, LS2, LS3, LS1R, LS2R, LS3R を ISO/IEC 2022 で利用

Slide 153

Slide 153 text

Slide 154

Slide 154 text

© 2024 Wantedly, Inc. 仮想端末向けシーケンス - CSI ● ESC [ は C1制御コードの CSI に対応 ○ CSI = Control Sequence Introducer, 狭義の制御シーケンスにあたる ● CSI → 引数 → コマンド名の順で入力する ○ 引数 = 0, 1, 2, … など ○ コマンド名 = A, B, C, … など ● 例 ○ ESC [ 2 4 A … カーソルを上に24回移動 ○ CSI 1 ; 1 H … カーソルを右上に移動

Slide 155

Slide 155 text

Slide 156

Slide 156 text

Slide 157

Slide 157 text

Slide 158

Slide 158 text

© 2024 Wantedly, Inc. ISO-2022-JP ISO-2022-JP ● インターネット (メールやIRC) を中心に広く使われた7bit文字エンコーディング ● JISコードとも呼ばれるが、JIS X 0208で定義されているわけではない ● ISO-2022とついているが、ISO/IEC 2022で定義されているわけではない EUC-JP, ISO-2022-JP, Shift_JISの3つの中で、漢字コードを GLにマッピングして利用する唯一の方式だったためにそう呼ばれたのかも ……。

Slide 159

Slide 159 text

Slide 160

Slide 160 text

Slide 161

Slide 161 text

Slide 162

Slide 162 text

Slide 163

Slide 163 text

Slide 164

Slide 164 text

© 2024 Wantedly, Inc. EUC-JP in ISO/IEC 2022 ● EUC-JPを指示するシーケンス(例) ○ つまり、EUC-JP文字列に以下を前置するとISO/IEC 2022文字列になるシーケンス効果 ESC SP P G0の呼び出し方法はLS0 ESC SP S G1の呼び出し方法はLS1R ESC SP Z G2の呼び出し方法はSS2 ESC SP [ G3の呼び出し方法はSS3 ESC SP G C1を利用シーケンス効果 ESC ( B G0にASCIIを指示 ESC $ ) B G1にJIS X 0208:1983 1面を指示 ESC * I G2にJIS X 0201仮名を指示 SI G0をGLに呼び出し ESC } G1をGRに呼び出しここでは漢字第2面がない古いバージョンとして例示している

Slide 165

Slide 165 text

Slide 166

Slide 166 text

Slide 167

Slide 167 text

© 2024 Wantedly, Inc. ISO-2022-JP ● オリジナルのISO-2022-JP 切り替え方法備考 ASCII ESC ( B 初期状態 & 終了状態 JIS X 0201 ラテン文字 ESC ( J テキストの終わりでは ASCIIに戻す JIS C 6226:1978 漢字第1面 ESC $ @ テキストの終わりでは ASCIIに戻す改行禁止 (改行時はモードを変える ) JIS X 0208:1983 漢字第1面 ESC $ B テキストの終わりでは ASCIIに戻す改行禁止 (改行時はモードを変える ) ※JIS C 6226 = JIS X 0208

Slide 168

Slide 168 text

Slide 169

Slide 169 text

© 2024 Wantedly, Inc. ISO-2022-JP ISO-2022-JP: 単なる「EUC-JPの7bit版」ではない ● 呼び出しではなく指示を利用 ○ 結果として、文字集合のバージョン差異に対しても厳密に動作する ○ ASCIIと JIS X 0201 ラテン文字用文字集合も区別できる ○ 初期版では漢字集合をJIS78とJIS83から選択可能 ● JIS X 0201 仮名文字 (いわゆる半角カナ) は使わない ○ ISO/IEC 2022上は ESC ( I で指示できるため、非公式に対応しているケースもある

Slide 170

Slide 170 text

Slide 171

Slide 171 text

Slide 172

Slide 172 text

Slide 173

Slide 173 text

© 2024 Wantedly, Inc. Windows-1252 Windows-1252 ● ISO/IEC 8859-1 (Latin-1) のC1領域に図形文字を割り当てたバージョン x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 8x € ‚ ƒ „ … † ‡ ˆ ‰ Š ‹ Œ Ž 9x ‘ ’ “ ” • – — ˜ ™ š › œ ž Ÿ

Slide 174

Slide 174 text

Slide 175

Slide 175 text

© 2024 Wantedly, Inc. VISCII VISCII: GR, C1にC0まで使ってクオックグーを配置 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 8x Ạ Ắ Ằ Ặ Ấ Ầ Ẩ Ậ Ẽ Ẹ Ế Ề Ể Ễ Ệ Ố 9x Ồ Ổ Ỗ Ộ Ợ Ớ Ờ Ở Ị Ỏ Ọ Ỉ Ủ Ũ Ụ Ỳ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x NUL SOH Ẳ ETX EOT Ẵ Ẫ BEL BS HT LF VT FF CR SO SI 1x DLE DC1 DC2 DC3 Ỷ NAK SYN ETB CAN Ỹ SUB ESC FS GS Ỵ US

Slide 176

Slide 176 text

© 2024 Wantedly, Inc. VISCII VISCII: GR, C1にC0まで使ってクオックグーを配置 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax Õ ắ ằ ặ ấ ầ ẩ ậ ẽ ẹ ế ề ể ễ ệ ố Bx ồ ồ ỗ Ỡ Ơ ộ ờ ở ị Ự Ứ Ừ Ử ơ ớ Ư Cx À Á Â Ã Ả Ă ẳ ẵ È É Ê Ẻ Ì Í Ĩ ỳ Dx Đ ứ Ò Ó Ô ạ ỷ ừ ử Ù Ú ỹ ỵ Ý ỡ ư Ex à á â ã ả ă ữ ẫ è é ê ẻ ì í ĩ ỉ Fx đ ự ò ó ô õ ỏ ọ ụ ù ú ũ ủ ý ợ Ữ

Slide 177

Slide 177 text

© 2024 Wantedly, Inc. VISCII ● 母音字 ○ A, Ă, Â, E, Ê, I, O, Ô, Ơ, U, Ư, Y の12文字 ○ それぞれに声調記号 ´, `, ̉, ~, . の5種類がつく ○ 全ての組み合わせを収録するには (12 × 6 - 6) ×2 = 132 文字必要 ● 子音字 ○ 追加で Đ を利用するため、大文字小文字あわせて 2 文字必要 ● C1 + GR で 128 文字 → 6文字入らない ○ → C0 領域も使わないと入らない ○ かといって、2バイトにするほどでもない

Slide 178

Slide 178 text

Slide 179

Slide 179 text

Slide 180

Slide 180 text

Slide 181

Slide 181 text

© 2024 Wantedly, Inc. Dingbat系フォント ● フォント選択が意味を決定してしまっている ● フォントが暗黙的に新しい文字エンコーディングを定義している、ともいえる現在、これらのDingbat系フォントによって表されていた文字の多くは Unicodeに収録されている。これらの文字を使えば、フォント設定に依存せずに適切に情報交換を行える。ツールによっては、これらの Dingbat系のフォント設定を特別扱いし、挙動を変えているものもあるようだ。たとえば、Microsoft WordではWebdingsが設定された区画のコピー &ペーストや検索の挙動を変えている。

Slide 182

Slide 182 text

Slide 183

Slide 183 text

Slide 184

Slide 184 text

Slide 185

Slide 185 text

Slide 186

Slide 186 text

Slide 187

Slide 187 text

Slide 188

Slide 188 text

Slide 189

Slide 189 text

Slide 190

Slide 190 text

Slide 191

Slide 191 text

© 2024 Wantedly, Inc. Shift_JIS 2バイト目問題 Shift_JIS の2バイト目と重複する領域 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 2x SP ! " # $ % & ' ( ) * + , - . / 3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 4x @ A B C D E F G H I J K L M N O 5x P Q R S T U V W X Y Z [ ¥ ] ^ _ 6x ` a b c d e f g h i j k l m n o 7x p q r s t u v w x y z { | } ‾ DEL

Slide 192

Slide 192 text

Slide 193

Slide 193 text

© 2024 Wantedly, Inc. 5C問題 ● 5C (\, ¥) は特別扱いされがち ○ プログラミング言語 ○ データフォーマット ● 5Cが含まれる文字が問題を起こしうる (ダメ文字) ○ ―ソЫ噂浬欺圭構蚕十申曾箪貼能表暴予禄 etc. ● 2F (/) も特別扱いされる ○ ファイルパスなどで問題になりうる ○ Shift_JISでは重複しないが、Big5やGBKでは問題になりうる

Slide 194

Slide 194 text

Slide 195

Slide 195 text

Slide 196

Slide 196 text

Slide 197

Slide 197 text

Slide 198

Slide 198 text

Slide 199

Slide 199 text

Slide 200

Slide 200 text

© 2024 Wantedly, Inc. Shift_JISの追加領域 ● 2面と1byte目の対応 (Shift_JISX0213) 1byte目 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC 奇数区 1 3 5 13 15 79 81 83 85 87 89 91 93 偶数区 8 4 12 14 78 80 82 84 86 88 90 92 94 ここに記載のない2区、6区、7区、9区、10区、11区、および16〜77区はJIS X 0212用で、 JIS X 0213では使われていない。

Slide 201

Slide 201 text

© 2024 Wantedly, Inc. ベンダー拡張再掲: JIS X 0208時代の空き領域 (1978～2000) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あア Ω Я ┨ Bx 亜院押魁粥機供掘検后此察次宗勝拭 Cx 澄繊臓叩帖邸董如函鼻福法漫諭痢蓮 Dx 弌僉辧咫圈奸屐廖悄戞據曄棔檗沺漾 Ex 燹瓠癲磧筺紂罅隋茵蕁蝓襦譟蹇遏錙 Fx 陝顱髻鵝堯

Slide 202

Slide 202 text

© 2024 Wantedly, Inc. ベンダー拡張空き領域 + Shift_JISの拡張区番号区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 区 95 96 97 98 99 100 101 102 103 104 105 106 107 区 108 109 110 111 112 113 114 115 116 117 118 119 120

Slide 203

Slide 203 text

© 2024 Wantedly, Inc. ベンダー拡張ここに各ベンダーが独自の拡張を入れていった区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 区 95 96 97 98 99 100 101 102 103 104 105 106 107 区 108 109 110 111 112 113 114 115 116 117 118 119 120 ここではIBM, NEC, MSによるもののみを扱うが、他にも色々な拡張があったようだ。そもそもJIS X 0208では空き領域の一部を自由領域と規定していたらしい。

Slide 204

Slide 204 text

© 2024 Wantedly, Inc. ベンダー拡張: IBM IBM拡張 (IBM CP932) 区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 区 95 96 97 98 99 100 101 102 103 104 105 106 107 区 108 109 110 111 112 113 114 115 116 117 118 119 120 ⅳ 夋涖蘒髜私用領域 (外字) 私用領域 (外字) IBM拡張文字 ※IBM漢字システム (1971) との互換用

Slide 205

Slide 205 text

© 2024 Wantedly, Inc. ベンダー拡張: NEC NEC拡張 (PC-9800) 区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 A ｱ ┨ ┨ ① 纊忞犾釗区 95 96 97 98 99 100 101 102 103 104 105 106 107 区 108 109 110 111 112 113 114 115 116 117 118 119 120 ⅳ 夋涖蘒髜選定 NEC選定IBM拡張文字 JIPS由来特殊文字それぞれ2バイト半角英数、2バイト半角カナ、半角罫線素片、全角罫線素片、NEC特殊文字

Slide 206

Slide 206 text

© 2024 Wantedly, Inc. ベンダー拡張: MSによる統合 Windows-31J (NECとIBMの統合; MS932) 区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 ① 纊忞犾釗区 95 96 97 98 99 100 101 102 103 104 105 106 107 区 108 109 110 111 112 113 114 115 116 117 118 119 120 ⅳ 夋涖蘒髜 NEC選定IBM拡張文字 NEC特殊文字 IBM拡張文字重複破棄

Slide 207

Slide 207 text

© 2024 Wantedly, Inc. ベンダー拡張 vs JIS X 0213 いっぽうJIS X 0213は区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 À Ą Œ ❶ ① 俱咩擄㯃滇琇硃絁菑訢釥顗区 2-1 2-8 2-3 2-4 2-5 2-12 2-13 2-14 2-15 2-78 2-79 2-80 2-81 𠂉宖儈唼堠幮抙晛棙殛溓熳璠区 2-82 2-83 2-84 2-85 2-86 2-87 2-88 2-89 2-90 2-91 2-92 2-93 2-94 𥆩稸糍翲芲𦿶蠮豗𨗉𨨩靪騱鳦

Slide 208

Slide 208 text

© 2024 Wantedly, Inc. ベンダー拡張: ARIB外字 ARIB外字 (放送用) 2byteコード区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 ⛌ ⛣ ➡ ㈪ Ⅳ 区 95 96 97 98 99 100 101 102 103 104 105 106 107 区 108 109 110 111 112 113 114 115 116 117 118 119 120

Slide 209

Slide 209 text

© 2024 Wantedly, Inc. ベンダー拡張: キャリア絵文字 docomo, KDDI, Willcom 絵文字 (+Windows-31J) 区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 ① 纊忞犾釗区 95 96 97 98 99 100 101 102 103 104 105 106 107 ♥ ‼ 🗿 🍂 😰 🦃 🌠 区 108 109 110 111 112 113 114 115 116 117 118 119 120 🎮 3⃣ 💾 ☀ 🌑 ✨ ⅳ 夋涖蘒髜 docomo Willcom KDDI KDDI KDDI

Slide 210

Slide 210 text

© 2024 Wantedly, Inc. ベンダー拡張: キャリア絵文字 Softbank 絵文字区 9 10 11 12 13 14 15 85 86 87 88 89 90 91 92 93 94 区 95 96 97 98 99 100 101 102 103 104 105 106 107 区 108 109 110 111 112 113 114 115 116 117 118 119 120 📬 🚶 👦 📝 😥 🏩 Softbank (J-PHONE) の絵文字はISO-2022-JPの拡張として定義されていたが、 Shift_JIS拡張としては以下の符号位置にマップされている。

Slide 211

Slide 211 text

© 2024 Wantedly, Inc. ベンダー拡張: キャリア絵文字 Softbank 絵文字 (ISO-2022-JP 拡張) 指示復帰区 ISO-IRとの重複 1 ESC $ G SO 113 CNS 11643-1992 Plane 1 2 ESC $ E SO 109 CCITT Chinese Set 3 ESC $ F SO 110 Blissymbol Graphic Character Set 4 ESC $ O SO 114 JIS X 0213:2000 Plane 1 5 ESC $ P SO 117 JIS X 0213:2000 Plane 2 6 ESC $ Q SO 118 JIS X 0213:2004 Plane 1

Slide 212

Slide 212 text

© 2024 Wantedly, Inc. Softbank 絵文字 ISO/IEC 2022風シーケンスの問題 ● そもそもエスケープシーケンスがおかしい ○ ESC $ の次には指示先を指定する文字が来ないといけない ■ ESC $ @, ESC $ A, ESC $ B のみ例外として認められている ○ ESC $ は指示を行うコードなのに、復帰時は SO で呼び出しのみを行っている ● 文字集合の問題 ○ ESC $ は多バイト文字集合用だが、この絵文字シーケンスは 1バイトしか使っていない ○ ESC $ を ESC $ ( と解釈すると、ISO-IRに登録済みの文字集合と重複してしまう ■ これらの誤解釈を避けるために、あえて誤ったシーケンスを実装したのかも

Slide 213

Slide 213 text

Slide 214

Slide 214 text

© 2024 Wantedly, Inc. JISのバージョン JIS X 0208 / JIS X 0213 の主要なバージョン第1水準第2水準第3水準第4水準非漢字 JIS C 6226:1978 2965 3384 0 0 453 JIS C 6226:1983 2965 3388 0 0 524 JIS X 0208:1990 2965 3390 0 0 524 JIS X 0213:2000 2965 3390 1249 2436 1183 JIS X 0213:2004 2965 3390 1259 2436 1183

Slide 215

Slide 215 text

Slide 216

Slide 216 text

Slide 217

Slide 217 text

Slide 218

Slide 218 text

© 2024 Wantedly, Inc. 非互換性への対応 ISO-2022-JP系コード: バージョンが区別できる 1面 2面 JP -1 -2 -3 -2004 78JIS ESC $ @ ✓ ✓ ✓ 83JIS ESC $ B ✓ ✓ ✓ (✓) (✓) 90JIS ESC $ B ✓ ✓ ✓ JIS X 0212 ESC $ ( D ✓ ✓ JIS2000 ESC $ ( O ESC $ ( P ✓ JIS2004 ESC $ ( Q ESC $ ( P ✓

Slide 219

Slide 219 text

© 2024 Wantedly, Inc. 非互換性への対応 EUC-JP系コード: バージョンの合意が必要 ● 一般的には最新バージョンとして解釈されると思われる ○ JIS X 0213:2000ベースのエンコーディングは EUC-JISX0213 と呼ばれる ○ JIS X 0213:2004ベースのエンコーディングは EUC-JIS-2004 と呼ばれる ● eucJP-ms系のコードとして解釈する場合もある

Slide 220

Slide 220 text

© 2024 Wantedly, Inc. 非互換性への対応 Shift_JIS系コード: バージョンの合意が必要 ● 一般的には90JISベースのWindows-31Jとして解釈されると思われる ● Windows-31JとJIS X 0213には互換性がない ○ JIS X 0213:2000ベースのエンコーディングは Shift_JISX0213 と呼ばれる ○ JIS X 0213:2004ベースのエンコーディングは Shift_JIS_2004 と呼ばれる

Slide 221

Slide 221 text

Slide 222

Slide 222 text

Slide 223

Slide 223 text

Slide 224

Slide 224 text

Slide 225

Slide 225 text

Slide 226

Slide 226 text

Slide 227

Slide 227 text

Slide 228

Slide 228 text

Slide 229

Slide 229 text

Slide 230

Slide 230 text

Slide 231

Slide 231 text

Slide 232

Slide 232 text

© 2024 Wantedly, Inc. 第2部まとめ ● ASCII登場以後、ASCII互換の各国コードが出現 ● 日本では以下の3つがとりわけ流通した ○ ISO-2022-JP系コード: Web/Internet ○ Shift_JIS系コード: DOS/Windows ○ EUC-JP系コード: UNIX/Linux ● ISO/IEC 2022の構造に従うものが多かった一方、独自の構造を持つものやベンダ拡張も多数あった

Slide 233

Slide 233 text

Slide 234

Slide 234 text

Slide 235

Slide 235 text

Slide 236

Slide 236 text

Slide 237

Slide 237 text

Slide 238

Slide 238 text

Slide 239

Slide 239 text

Slide 240

Slide 240 text

Slide 241

Slide 241 text

Slide 242

Slide 242 text

Slide 243

Slide 243 text

Slide 244

Slide 244 text

© 2024 Wantedly, Inc. 復習: 文字集合と符号化方式せっかく定義した文字集合を使い回したい → 文字集合と符号化方式の分離 (符号化)文字集合 (CCS) 文字に番号をつける符号化方式 (CES) 番号をバイト列に対応づけるとはいっても、任意の文字集合を任意の方式で符号化できるわけではない。たとえばJIS X 0208をUTF-8で符号化することはできない。あくまで緩くモジュラー化するための枠組みだと考えるのがベスト。文字エンコーディング (character encoding) このような区別は後から生じたものであるため、文字エンコーディングのことを charsetと呼ぶこともある。

Slide 245

Slide 245 text

© 2024 Wantedly, Inc. Unicode コードポイントコードポイント (符号位置) = 文字を割り当てられる位置 ● 文字が割り当てられていない位置もある ○ まだ文字が割り当てられていない = Reserved ○ 文字が割り当てられない = Noncharacter / Private Use / Surrogate ● 全部で 17 × 65536 = 1114112 個ある (約 20.1 ビット) ○ 最初の 65536 個 = 基本多言語面 (BMP) ○ 残りの 16 × 65536 個 = 追加面 ○ この個数制限は UTF-16 の設計に由来する (後述) [Unicode] §2.4 [Unicode] §2.4 [Unicode] §2.4.1 [Unicode] §2.9 [Unicode] §2.5.2

Slide 246

Slide 246 text

Slide 247

Slide 247 text

© 2024 Wantedly, Inc. サロゲートとUSV ● サロゲートは、文字の基本単位として扱わないほうが都合がよい ● サロゲート以外のコードポイントを USV と呼ぶ ○ USV = コードポイント - サロゲート ○ Unicode Scalar Value の略 ● U+0000 ～ U+D7FF + U+E000 ～ U+10FFFF ○ 合計 1112064 個ある [Unicode] §3.9

Slide 248

Slide 248 text

Slide 249

Slide 249 text

Slide 250

Slide 250 text

Slide 251

Slide 251 text

© 2024 Wantedly, Inc. 割り当て状況割り当ての歴史 (〜2.0 までを拡大) 現在のUnicodeは互換性を保証しているが、初期のUnicodeには重大な破壊的変更が多数入っていた。 Unicode 1.0.1 で私用領域の位置がずらされると同時に大きくなっている。 Unicode 1.1 では削除された文字が多くあったため、文字数がむしろ減ってしまっている。 [UCD], [UCD1.0.0]

Slide 252

Slide 252 text

© 2024 Wantedly, Inc. 私用面と予約 ● 初期の JIS X 0208 では、未定義領域にベンダ拡張が詰め込まれ、混乱のもととなった。 ○ 規格自体はその後修正されたが、ベンダ拡張の影響は残り続けている ● Unicodeでは、予約領域と私用領域が区別されている。 ○ 予約領域 (Reserved): 将来Unicode Consortiumが使う (勝手に使えない) ○ 私用領域 (Private Use): 勝手に使ってよい (Unicode Consortiumは使わない) ○ ベンダ拡張同士の衝突リスク自体はあるが、私用領域が大きいので回避はしやすい [Unicode] §2.14.2 [Unicode] §2.14.3

Slide 253

Slide 253 text

Slide 254

Slide 254 text

Slide 255

Slide 255 text

© 2024 Wantedly, Inc. UTF UTF は Unicode の符号化方式を定義する ● 最も重要なのは UTF-8, UTF-16, UTF-32 ● 付属文書に定義: ○ CESU-8, UTF-EBCDIC, SCSU, BOCU-1 ● 非公式に UTF-7, Punycode などもある ○ 上記2つは IETF RFC で定義されている (標準化の主体が異なる) ○ UTF-9, UTF-18 もある (エイプリルフールRFC) [Unicode] §2.5, §2.6, §3.9, §3.10 [UTR#26], [UTR#16], [UTS#6], [UTN#6] [RFC2152], [RFC3492] [RFC4042]

Slide 256

Slide 256 text

© 2024 Wantedly, Inc. 符号化形式 vs 符号化スキーム「符号化形式」と「符号化スキーム」の区別が大事！符号化形式 (Encoding Form) ● メモリ上への保管が目的 ● 3種類 ○ UTF-8 ○ UTF-16 ○ UTF-32 ● BOM なし符号化スキーム (Encoding Scheme) ● 保存・送受信が目的 ● 7種類 ○ UTF-8 ○ UTF-16, 16BE, 16LE ○ UTF-32, 32BE, 32LE ● BOM の利用が可能 (一部) [Unicode] §2.5, §3.9 [Unicode] §2.6, §3.10

Slide 257

Slide 257 text

© 2024 Wantedly, Inc. UTF-16 符号化形式 vs UTF-16* 符号化スキーム「何の配列として扱うか」が異なる 0x6587 0x5B57 0x30B3 0x30FC 0x30C9 UTF-16 符号化形式 UTF-16* 符号化スキーム 0x65 0x87 0x5B 0x57 0x30 0xB3 0x30 0xFC 0x30 0xC9 なので、UTF-16符号化「形式」にはバイトオーダーの問題はない (原則として)

Slide 258

Slide 258 text

Slide 259

Slide 259 text

© 2024 Wantedly, Inc. UTF-16 符号化形式 UTF-16 符号化形式 0x3042 U+0000 ～ U+FFFF U+10000 ～ U+10FFFF 0xD83C 0xDF7A コードポイントをそのまま埋め込むコードポイントから 65536 を引く 20bit 整数になるので、10bitずつに分割 0xD800 + 上位10bit (上位サロゲート) 0xDC00 + 下位10bit (下位サロゲート) (サロゲートを除く) この形式をサロゲートペアという [Unicode] §2.5.2, §3.9.2

Slide 260

Slide 260 text

Slide 261

Slide 261 text

© 2024 Wantedly, Inc. UTF-16 符号化スキーム UTF-16: バイト順を検出するギ 30 AC FE FF 30 AC FF FE AC 30 U+30AC BE, No BOM BE, BOM LE, BOM U+FEFF または U+FFFE で始まる場合はBOMが必須だが、こうしたケースはほぼないと考えてよいギ U+30AC 3通りのエンコード方法がある (どれでも良い) BOM (バイト順マーク) [Unicode] §3.10

Slide 262

Slide 262 text

Slide 263

Slide 263 text

© 2024 Wantedly, Inc. UTF-8 符号化形式 UTF-8 符号化形式: ASCIIとの高い相性が特徴 41 U+0000 ～ U+007F コードポイントをそのまま埋め込む (サロゲートを除く) U+0080 ～ U+07FF CE 91 [0xC0 + 上位5bit, 0x80 + 下位6bit] U+0800 ～ U+FFFF E3 81 82 [0xE0 + 上位4bit, (0x80 + 6bit) × 2つ] U+10000 ～ U+10FFFF F0 91 96 80 [0xF0 + 上位3bit, (0x80 + 6bit) × 3つ] [Unicode] §2.5.3, §3.9.3

Slide 264

Slide 264 text

© 2024 Wantedly, Inc. UTF-8 符号化スキーム UTF-8 符号化スキーム = UTF-8 符号化形式 + BOM ● エンコード時: BOMを足してもよい ○ 基本的にBOMは不要 (バイトオーダーの問題はないため ) ○ UTF-8 を識別したい場合など、特に必要なときのみ BOM (EF BB BF) を出力 ● デコード時: BOMを削る ○ 先頭の EF BB BF は文字としないことが推奨 ○ ただし、この規定は §3.10 ではなく §23.8.1 にのみあり、 UTF-16* の BOM に関する規定より弱い [Unicode] §2.6, §3.10 [Unicode] §23.8.1 [Unicode] §23.8.1

Slide 265

Slide 265 text

© 2024 Wantedly, Inc. UTF-32 ● UTF-32 符号化形式: USVをそのまま保持 ● 符号化スキームについてはUTF-16と同様 ○ UTF-32 は BOMを使ってバイト順を判別 ○ UTF-32BE / UTF-32LE は、バイト順を事前に合意 (BOMは使わない) 0x000323AF U+0000 ～ U+10FFFF コードポイントをそのまま埋め込む (サロゲートを除く) 00 00 Ā ᷎ BE LE U+0100 U+10000 01 00 [Unicode] §2.5.1, §3.9.1 [Unicode] §2.6, §3.10

Slide 266

Slide 266 text

Slide 267

Slide 267 text

© 2024 Wantedly, Inc. UnicodeとUCS ● Unicode: Unicode Consortium が策定 ○ Unicode Consortium (Unicode, Inc.) はIT業界の支援を受けている専門の標準化団体 ● UCS (ISO/IEC 10646): ISO が策定 ○ ISO は工業や農業を含む広範な標準化を行う団体 ○ IEC は電気・電子分野の標準化団体 ● 現在は実質 Unicode = UCS と思ってOK、だが…… ○ 歴史を理解するには区別が重要 [Unicode] [ISO10646]

Slide 268

Slide 268 text

© 2024 Wantedly, Inc. Unicode 1.0 ● Unicodeプロジェクトは1987年頃に開始 ○ Xerox と Apple のエンジニアが創始し、その後名だたる企業のメンバーが参加 ● 16bit固定長のワイド文字として計画された ○ XeroxのXCCSの影響を受けていると言われる ○ 今でいう UTF-16 での表現のみが想定されていた ● 「統合漢字」を持つ ○ 中国・日本・韓国の類似する漢字は、同じ文字として扱う Unicodeでは漢字のことを CJK Ideograph (中日韓表意文字) と呼ぶ。実際には漢字は Logograph (表語文字) あるいは Logosyllabary だが、今さら呼び名を変えるわけにはいかないのでこうなっている。 [UNarrative] [Yasuoka2006] §3.2.4, p.214 [UNarrative] [Yasuoka2006] §3.2.4, p.214

Slide 269

Slide 269 text

© 2024 Wantedly, Inc. DIS 10646 ● ISOの統合文字コードのプロジェクトは1983年まで遡る ● 当初は ISO 2022 を踏襲した符号体系だった ○ これらの古いドラフトは DP 10646 (2byteコード), DIS 10646-1 (4byteコード) と呼ばれる ● 「統合漢字」を持たない ○ 中国・日本・韓国の漢字は、異なる文字として扱う [Yasuoka2006] §3.2.3, p.184 [Yasuoka2006] §3.2.3, p.214 [Unicode] §C.1 [Yasuoka2006] §3.2.3, p.184, [UChrono], [Unicode] §C.1

Slide 270

Slide 270 text

© 2024 Wantedly, Inc. UCSの誕生 ● いくつかの理由から DIS 10646-1 は否決 ○ 統合漢字を推す中国の意向、コード長の問題、コード体系の複雑さ、統合コードの乱立に対する懸念など ● Unicodeとの互換性を意識した UCS (ISO/IEC 10646) が誕生 [Yasuoka2006] §3.2.5, p.216 [Yasuoka2006] §3.2.6, p.218 [Unicode] §C.1

Slide 271

Slide 271 text

© 2024 Wantedly, Inc. UCS (1993) ● UCS (1993年) は31bitの文字集合 ○ 表現方法として UTF-1, UCS-2, UCS-4 が定義された。これらは現在の UTF-8, UTF-16, UTF-32 のコンセプトに近い ○ Unicodeの計画より複雑なのは、ISOらしいと言えるかも ● 最初の 65536 文字分は Unicode と同期 ○ 同じコードポイントなら、同じ文字が割り当てられている状態を維持 ○ UCS-2 は、この 65536 文字分のみを扱える [n0783] §6.1 [n0783] §14.1, §14.2, §F

Slide 272

Slide 272 text

Slide 273

Slide 273 text

© 2024 Wantedly, Inc. Unicode 2.0 ● 追加漢字や多くの文字体系の収録が必要になった ● 16bit固定長という夢を捨て、21bit可変長に移行 → UTF-16 の誕生 ○ 実際に追加面への文字の割り当てが開始されたのは Unicode 3.1 ● この間に UTF-8 (FSS-UTF) も誕生している ○ UTF-1 を置き換え ○ Ken Thompson による発案 ● UTF の2義性 (U = Unicode or UCS)

Slide 274

Slide 274 text

Slide 275

Slide 275 text

Slide 276

Slide 276 text

Slide 277

Slide 277 text

Slide 278

Slide 278 text

© 2024 Wantedly, Inc. UTF-16の制限 ● UTF-16符号化形式にも不正な形式がある ● 「孤立したサロゲート」は禁止 ○ 上位サロゲートがあるのに、次のコードユニットが下位サロゲートではない ○ 下位サロゲートがあるのに、前のコードユニットが上位サロゲートではない ● 整形式 (well formed) / 不正形式 (ill formed) [Unicode] §3.9.2

Slide 279

Slide 279 text

© 2024 Wantedly, Inc. UCS-2 ● 歴史的経緯から、UTF-16符号化形式を使うAPIは整形式を要求しないことが多い ○ 背景: サロゲートペア以前に作られたAPIは互換性から整形式を要求できない。サロゲートペア以後に作られたAPIは、そもそもUTF-16を使う利点が少ない。 ● 便宜上 UCS-2 と呼ばれることがある ● 代表的なAPI群 ○ Java / JavaScript の文字列処理全般 ○ Windows NTのUnicode API (W suffix) [ECMA262] §4.4.20

Slide 280

Slide 280 text

© 2024 Wantedly, Inc. WTF-8 ● WTF-8: 非公式の符号化方式で、UTF-8の拡張 ○ UTF-8では表現できない「孤立サロゲート」を許可し、そのままエンコード ○ サロゲートペアの表現はUTF-8と同じ ● UCS-2 API とのマッピングが必要なときに有益 ○ たとえば、Windowsプラットフォーム上でのRust APIで使われている WTF-8 と CESU-8 は似ているように見えて全然違う。 CESU-8 はサロゲートペアを分解し、孤立サロゲートは禁止。 WTF-8 はサロゲートペアは分解せず、孤立サロゲートを許可。 [WTF-8]

Slide 281

Slide 281 text

Slide 282

Slide 282 text

© 2024 Wantedly, Inc. 文字エンコーディングの特性ここでは以下の特性を扱う ● 一意復号 / 一意符号化 ● モノイド準同型 ● 瞬時復号 ● 自己同期 ● 単調性こうした議論は符号理論と形式言語理論の両輪にまたがっており、なるべくこれらの理論に由来する用語を用いている。しかし、現実の文字エンコーディングについて議論するにあたって適切な語彙がないものもいくつかあったため、そこには独自に用語を充てている。

Slide 283

Slide 283 text

Slide 284

Slide 284 text

Slide 285

Slide 285 text

Slide 286

Slide 286 text

Slide 287

Slide 287 text

Slide 288

Slide 288 text

Slide 289

Slide 289 text

Slide 290

Slide 290 text

Slide 291

Slide 291 text

Slide 292

Slide 292 text

Slide 293

Slide 293 text

Slide 294

Slide 294 text

Slide 295

Slide 295 text

© 2024 Wantedly, Inc. UTF-8 コードユニット ● 80 〜 BF (6bit) を「後続バイト」に割り当て ● 残りを「先頭バイト」に割り当て ○ 00 〜 7F (7bit) → 1バイトコード (ASCII) ○ C0 〜 DF (5bit) → 2バイトコード ○ E0 〜 EF (4bit) → 3バイトコード ○ F0 〜 F7 (3bit) → 4バイトコード ○ F8 〜 FB (2bit) → 5バイトコード ○ FC 〜 FD (1bit) → 6バイトコード

Slide 296

Slide 296 text

Slide 297

Slide 297 text

© 2024 Wantedly, Inc. UTF-8 ● 原理的には、UTF-8方式には複数の表現方法がある ○ たとえば U+0061 を 61 ではなく C1 A1 や E0 81 A1 とも表せる ● 実際には最短の表現のみを許可する ● UTF-8は以下も禁止する ○ 追加面の文字をサロゲートペアで表現すること (→ CESU-8) ○ 孤立サロゲートを表現すること (→ WTF-8) ○ U+110000 以上のコードポイントを表現すること (→ 古いUCSのUTF-8)

Slide 298

Slide 298 text

Slide 299

Slide 299 text

Slide 300

Slide 300 text

© 2024 Wantedly, Inc. 自己同期だと何が嬉しいのか自己同期 + ASCII互換の嬉しさ ● UTF-8の7bit断片は全て、 U+0000〜U+007F である ● 逆に言えば、他の文字が ASCII に誤解されることがない ● この性質は FSS (File System Safe) と呼ばれていた ○ スラッシュを含まないため、ファイル名に使っても問題が起きにくい ○ 同様にバックシュラッシュも含まない (5C問題が起きない)

Slide 301

Slide 301 text

Slide 302

Slide 302 text

© 2024 Wantedly, Inc. 単調性 ● UTF-8 は単調性を持つ ○ 必ず最小バイト数で表現するため、 USVに対してバイト長が単調 ○ さらに、バイト長に対してバイト位置が単調 (第1バイトの選び方を思い出そう) ○ 加えてビッグエンディアンなので、全体として辞書順を保つ ● UTF-16 は単調性を持たない ○ 追加面のコードポイントは U+Exxx, U+Fxxx より手前に来てしまう ○ JavaScriptのsortのデフォルト比較アルゴリズムが該当

Slide 303

Slide 303 text

© 2024 Wantedly, Inc. 各形式のバイト数各形式のバイト数 UTF-8 UTF-16 UTF-32 〜 U+007F 7bit 1 2 4 ASCII 〜 U+07FF 11bit 2 2 4 ギリシャ文字など〜 U+FFFF 16bit 3 2 4 ひらがな、漢字など〜 U+10FFFF 21bit 4 4 4 変体仮名、梵字、絵文字など UTF-8の3byte上限(16bit)が、UTF-16の2byte上限と一致している。また、UTF-8の4byte上限(21bit)が、USVを表現するギリギリの量と一致している。偶然の一致か、はたまたKen Thompsonの狙い通りか……?

Slide 304

Slide 304 text

Slide 305

Slide 305 text

Slide 306

Slide 306 text

© 2024 Wantedly, Inc. 10の設計原理 Unicodeが定める「10の設計原理」普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2

Slide 307

Slide 307 text

Slide 308

Slide 308 text

© 2024 Wantedly, Inc. 原則と例外 ● 文字の収録・統合の原則は、以下の原理に基づく ○ 普遍性 Universality ○ グリフ(字形)ではなく文字を扱う Characters, not Glyphs ○ プレーンテキスト Plaintext ○ 統合 Unification ○ 動的な合成 Dynamic composition ● ただし、例外的に以下の原理は優先される ○ 安定性 Stability ○ 変換可能性 Convertibility

Slide 309

Slide 309 text

© 2024 Wantedly, Inc. 文字収録の原則 1 ● 「普遍性」原理: Unicodeは世界中の文字を収録する。 ● 現代で使われていない文字も収録される ○ 線文字Bなど ● 例外もある ○ 利用形態について十分な知見がないものなど、収録できないものもある ● 固定長時代のUnicodeでは不可能だった ○ 65536文字に収まるというのは、収録範囲を限定した上で漢字を包摂する前提だったあ 𐎧 ᷎ ᷎ ᷎ [Unicode] §2.2.1

Slide 310

Slide 310 text

© 2024 Wantedly, Inc. 文字収録の原則 2 ● 「プレーンテキスト」原理: 文字の内容だけを扱い、文字のスタイルは扱わない ○ 対義語は Rich Text で、HTMLなどを指す ● 太字、赤色、上付き、下付き、…… などは収録しない ● 例外も(たくさん)ある ○ スタイルが文字内容と関連している場合 (日本語の小書き文字など) ○ 互換性要件 (後述) [Unicode] §2.2.5

Slide 311

Slide 311 text

© 2024 Wantedly, Inc. 文字収録の原則 3 ● 「動的な合成」原理: ダイアクリティカルマークとハングルは部品から合成する ● したがって、これらの合成済み形式は提供しない ● 例外も(たくさん)ある ○ 主要なハングル音節 ○ 漢字の会意文字・形声文字 ○ アラビア文字のイジャーム ○ タイ文字の母音記号の一部 (通常の文字として提供) ○ 互換性 (後述) Q ◌ ̋ Q ̋ [Unicode] §2.2.8

Slide 312

Slide 312 text

Slide 313

Slide 313 text

© 2024 Wantedly, Inc. 文字統合の原則 2 ● 「統合」: 文字体系 (script) ごとに、同じとみなせる文字はまとめる ○ 「同じ」かどうかは、形や意味から総合的に判断する ● 言語ごとではない点に注意 ○ 英語・フランス語・ドイツ語は統合の対象 ○ ラテン文字・ギリシャ文字は統合の対象外 ○ 中国・日本・韓国の漢字は統合の対象 ○ ひらがな・カタカナは統合の対象外 [Unicode] §2.2.7

Slide 314

Slide 314 text

Slide 315

Slide 315 text

Slide 316

Slide 316 text

Slide 317

Slide 317 text

Slide 318

Slide 318 text

Slide 319

Slide 319 text

Slide 320

Slide 320 text

© 2024 Wantedly, Inc. 互換文字以上を踏まえて、Unicodeの文字は2つに分けられる: ● 通常の文字: Unicodeの文字収録原則に基づく文字 ● 互換文字: round-trip ruleのために必要な文字 ○ スタイルの当たった文字や合字 ○ 合成済みの文字 ○ Unicode の包摂基準上は区別されない JIS X 0208 の文字など ● ただし、この区別は厳密なものではない ○ 「互換分解可能な文字」は厳密に定義されているが、少しニュアンスがずれる

Slide 321

Slide 321 text

Slide 322

Slide 322 text

Slide 323

Slide 323 text

Slide 324

Slide 324 text

© 2024 Wantedly, Inc. ブロック ● ブロック = 連続したコードポイントのまとまり ● Basic Latin (U+0000 - U+007F, 128) ● Latin-1 Supplement (U+0080 - U+00FF, 128) ● Greek and Coptic (U+0370 - U+03FF, 144) ● Katakana Phonetic Extensions (U+31F0 - U+31FF, 16) ● CJK Unified Ideographs (U+4E00 - U+9FFF, 20992) [Unicode] §2.8.2

Slide 325

Slide 325 text

Slide 326

Slide 326 text

© 2024 Wantedly, Inc. コードポイントの注意 ● ブロック名は参考程度 ○ Basic Latin は ASCII と一致するため、汎用の記号を含む ○ Arabic Presentation Forms-A には、非文字として予約されたコードポイントが 32個含まれる ● コードポイント順 ≠ 照合順 ○ 原規格で照合順に近い並びになっているものも多いが、完全ではない ○ 照合については後述 ● 同じ用途のブロックが複数あるのも普通 ○ CJK Unified Ideographs の拡張ブロックは A - J まである

Slide 327

Slide 327 text

Slide 328

Slide 328 text

© 2024 Wantedly, Inc. 文字を繋げる仕組み似たような概念が色々ある結合 (combining) メインの文字 + 補助的な記号 q + ◌̣ = q̣ 等位結合 (conjoining) 字母 + 字母 + 字母 (ハングル専用) ᄊ + ᆞ = ᄊᆞ 合成 (composition) 結合によって1つのコードポイントになる場合 a + ◌̀ = à 合字 (ligature) 文字が並ぶことで形が変わる (文字数は変わらない ) f + f + l = ffl 連結 (joining) 筆記体文字の合字システム (主にアラビア文字) لھ = ل + ه

Slide 329

Slide 329 text

Slide 330

Slide 330 text

Slide 331

Slide 331 text

Slide 332

Slide 332 text

Slide 333

Slide 333 text

Slide 334

Slide 334 text

Slide 335

Slide 335 text

Slide 336

Slide 336 text

Slide 337

Slide 337 text

Slide 338

Slide 338 text

Slide 339

Slide 339 text

Slide 340

Slide 340 text

Slide 341

Slide 341 text

© 2024 Wantedly, Inc. 連結 ● 連結 (joining) ○ cursive joining とも ● アラビア文字などを対象とした合字の亜種 ○ これらの文字は、標準で筆記体を使う ● Unicodeでは、合字 ≠ 連結 ○ 「連結」は「合字」とは独立したシステムで処理される ○ たとえば ل + ا をそのまま並べると ا ل だが、連結すると ﺎ ﻟ となり、さらに合字を適用すると ﻻ になる [Unicode] §23.2.2

Slide 342

Slide 342 text

Slide 343

Slide 343 text

Slide 344

Slide 344 text

© 2024 Wantedly, Inc. 正準等価性 ● 正準等価性: 同じ見た目かつ同じ振舞いが期待される文字列同士の関係 ○ Gc値, Script値や「バックスペースの振舞い」などの差異はあり、全く同じではない ● 通常の文字・互換文字の両方で生じうる ○ 結合文字の適用順序の違い (通常の文字で発生) ○ 合成済み文字 (互換文字で発生) ○ round-trip ruleのために追加されたシングルトン等価な文字 (互換文字で発生) [Unicode] §3.11, [UAX#15]

Slide 345

Slide 345 text

Slide 346

Slide 346 text

Slide 347

Slide 347 text

Slide 348

Slide 348 text

Slide 349

Slide 349 text

Slide 350

Slide 350 text

Slide 351

Slide 351 text

Slide 352

Slide 352 text

Slide 353

Slide 353 text

Slide 354

Slide 354 text

Slide 355

Slide 355 text

Slide 356

Slide 356 text

© 2024 Wantedly, Inc. 正準結合クラス - Attach A ccc=Not_Reordered (0) ccc=Attached_Below (202) ccc=Attached_Below_Left (200) ccc=Attached_Below_Right (204) ccc=Attached_Left (208) ccc=Attached_Above_Left (212) ccc=Attached_Above (214) ccc=Attached_Above_Right (216) ccc=Attached_Right (210) ̧ ᷎ ̛ [UAX#44] §5.7.4

Slide 357

Slide 357 text

© 2024 Wantedly, Inc. 〯正準結合クラス - 非Attach A ccc=Not_Reordered (0) ccc=Below (220) ccc=Below_Left (218) ccc=Below_Right (222) ccc=Left (224) ccc=Above_Left (228) ccc=Above (230) ccc=Above_Right (232) ccc=Right (226) 〪 ̣〭 𝅭 　〫　̂ 　〬 [UAX#44] §5.7.4

Slide 358

Slide 358 text

© 2024 Wantedly, Inc. ◌् ◌़ 正準結合クラス - その他 A ccc=Not_Reordered (0) ccc=Han_Reading (6) ccc=Kana_Voicing (8) ゙ ccc=Nukta (7) ccc=Virama (9) ͅ ccc=Iota_Subscript (240) これらに加えて、固定位置クラスと呼ばれる正準合成クラスがある (10 ～ 199) [UAX#44] §5.7.4

Slide 359

Slide 359 text

Slide 360

Slide 360 text

Slide 361

Slide 361 text

Slide 362

Slide 362 text

Slide 363

Slide 363 text

Slide 364

Slide 364 text

Slide 365

Slide 365 text

Slide 366

Slide 366 text

© 2024 Wantedly, Inc. 正準等価性とUnicodeアルゴリズム ● 正準等価性: 同じ見た目・同じ振舞いを期待 ● 規格で規定されているアルゴリズムの多くは、正準等価な文字列に対して同じ振舞いをするよう規定 ○ 正規化アルゴリズム自体もそう ○ テキストの区切り、Bidi は性質の保存を保証 ○ 識別子構文では、等価性を尊重するための定義をいくつか用意 ○ 例外もある (東アジアの文字幅など)

Slide 367

Slide 367 text

© 2024 Wantedly, Inc. Recap: 10の設計原理 Unicodeが定める「10の設計原理」普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2

Slide 368

Slide 368 text

Slide 369

Slide 369 text

Slide 370

Slide 370 text

© 2024 Wantedly, Inc. 正規化の安定性 - 応用 ● 例: パスワードを正準等価性で比較するシステムを考える ○ ダイアクリティカルマークを持つ言語では、単純比較が問題になりえるため ● パスワード設定時 ○ 未割り当ての文字 /\p{Cn}/ がないことを検証 → あればパスワードを拒否 ○ NFCで正規化し、適切なKDFでハッシュ化して保存 ● パスワード比較時 ○ NFCで正規化後ハッシュを取り比較 ● 安定性保証により、ログインの成功が保証される [UAX#15] §12

Slide 371

Slide 371 text

Slide 372

Slide 372 text

Slide 373

Slide 373 text

© 2024 Wantedly, Inc. 正準順序の代数的性質 ● 文字列結合は商集合に対しても well-defined ○ A と A’ が正準等価で B と B’ が正準等価なら、 AB と A’B’ も正準等価 ○ ただし、 toNFD(A)toNFD(B) = toNFD(AB) とは限らない (例: A = [U+0301], B = [U+0323]) ● 自由モノイドにはならない ○ 証明方針例: 正準順序が文字数を保存することに注目すると、結合文字がモノイド上既約であることがわかる。もし商集合が自由モノイドなら既約 ⇔ 生成元となるが、自由モノイドでは異なる生成元同士は交換しない。 Cccの異なる結合文字を2つ持ってくると反例になる。

Slide 374

Slide 374 text

© 2024 Wantedly, Inc. モノイドとしての性質 ● 消約性は満たす ○ ax = ay ならば x = y であるという性質 (左消約) またはその逆 ○ 接頭辞を特定して取り除けるという性質 ○ ただし、NFDで単純接頭辞判定してもうまくいかない ○ 消約性の証明方針: aが1文字の場合を示せば良い。aが開始子なら明らか。aが非開始子の場合、 ax の正準順序は x’ax’’, a ∉ x’ であり、 x’ax’’ = y’ay’’ から x’x’’ = y’y’’ が得られる。ここで x’x’’ は x の正準順序であるから、 x と y は商モノイド上で等しい。

Slide 375

Slide 375 text

Slide 376

Slide 376 text

Slide 377

Slide 377 text

Slide 378

Slide 378 text

Slide 379

Slide 379 text

Slide 380

Slide 380 text

Slide 381

Slide 381 text

Slide 382

Slide 382 text

Slide 383

Slide 383 text

Slide 384

Slide 384 text

Slide 385

Slide 385 text

Slide 386

Slide 386 text

Slide 387

Slide 387 text

Slide 388

Slide 388 text

© 2024 Wantedly, Inc. 1文字 = 書記素 ● このような「1文字」の単位を言語学で「書記素」と呼ぶ ● 書記素クラスター = Unicodeにおける書記素 ○ 言語学的な「書記素」と区別するために「書記素クラスター」と呼ぶ ○ Unicode Text Segmentation で、単語境界や文境界と合わせて定義 ● 通常は「拡張書記素クラスター」を使う ○ レガシー書記素クラスターはなるべく使わない書記素とは関係ないが、 Unicode Text Segmentationでは平仮名や片仮名の単語境界も定めている。ブラウザで、カタカナの単語をダブルクリックしたときとひらがなの単語をダブルクリックしたときの挙動を比べてみると面白い。

Slide 389

Slide 389 text

© 2024 Wantedly, Inc. 書記素クラスターの注意点 ● 書記素クラスターは理論上かなり長くなる ○ ストレージサイズの制限を意図しているなら、コードポイント数の制限も設定するべき ● 書記素境界の決定には無制限の後読みが必要 ○ Emoji Flag Sequences の設計のせい ○ Emoji Flag Sequences の設計のせい ○ Emoji Flag Sequences の設計のせい ○ Emoji Flag Sequences の問題を除けば、有限の後読み・先読みで解決できる

Slide 390

Slide 390 text

© 2024 Wantedly, Inc. セグメンテーションテキスト分割アルゴリズムは他に2つある書記素クラスター h, e, l, l, o 編集の単位、カーソルの動き、照合、縦書き、最初の1文字のスタイリング、文字数の表示など単語 “Hello, “, “world!” ダブルクリックによる選択、Ctrl+矢印による移動、単語検索、単語数の表示など文 “This is a pen.” トリプルクリックによる選択など

Slide 391

Slide 391 text

Slide 392

Slide 392 text

Slide 393

Slide 393 text

Slide 394

Slide 394 text

Slide 395

Slide 395 text

Slide 396

Slide 396 text

Slide 397

Slide 397 text

Slide 398

Slide 398 text

© 2024 Wantedly, Inc. 制御文字 ● Unicodeの制御文字 (Cc) = C0/C1/DEL の計65文字 ● このうちいくつかは、フォーマット文字に準じて扱う ○ U+000A (LF), U+000B (VT), U+000C (FF), U+000D (CR), U+0085 (NEL), U+001C (FS), U+001D (GS), U+001E (RS) … 改行文字に準じた扱い ○ U+0009 (HT), U+001F (US) … スペースに準じた扱い ● 残りの意味論を Unicode は定義しない ○ 通常 ISO/IEC 6429 に準じて扱う

Slide 399

Slide 399 text

© 2024 Wantedly, Inc. フォーマット文字 – 空白 ● U+0020 SPACE … 基本の空白 ● 固定空白 ○ U+2000 - U+200A および U+205F がそれぞれ特定の長さ指定を持つ空白 ○ U+1680 もオガム文字用のスペースとみなされている ● U+3000 IDEOGRAPHIC SPACE … いわゆる全角空白 ○ 互換文字としての側面もある。 ○ いっぽう、東アジアの組版慣習に適した空白でもあり、単なる互換文字とも言い切れない。

Slide 400

Slide 400 text

© 2024 Wantedly, Inc. フォーマット文字 – 空白 ● 改行しない空白文字 2種類 ○ U+00A0 … 改行しない空白文字 ○ U+202F … 改行しない空白文字 (狭い) ○ 慣用表現 (et al.)、数字 (1 234) など組版の慣習上必要な場面がある ● U+0009 水平タブ ○ 表組み (tabulation) のためのタイプライター等の慣習を引き継いだ文字 ● U+001F ユニット区切り ○ U+001C 〜 U+001E と組み合わせて使う。今どきは使わない

Slide 401

Slide 401 text

Slide 402

Slide 402 text

© 2024 Wantedly, Inc. フォーマット文字 – 改行 ● U+000B 垂直タブ。ほぼ使わない。 ● U+000C 改ページ。ほぼ使わない。 ● U+0085 次の行。ほぼ使わない。 ● U+001C〜1E ほぼ使わない。 ● U+2028 行区切り。ほぼ使わない。 ● U+2029 段落区切り。ほぼ使わない。水平タブと同様の起源。スペース扱いの場合もある紙面を送るという意味。メインフレームでは現役かもテキストをツリー構造で管理できる仕組み。RFC 7464で見たことはあるこの2つはUnicodeで導入された。いわゆる
と

に相当。たとえば JavaScript では改行扱い

Slide 403

Slide 403 text

Slide 404

Slide 404 text

Slide 405

Slide 405 text

© 2024 Wantedly, Inc. カスタマイズ (tailoring) ● Unicodeは多くのアルゴリズムを定義している ○ 正規化、テキストの区切り、改行処理、大文字小文字処理、 Bidi、照合、東アジアの文字幅、プログラミング言語の識別子、正規表現、 etc. ● 言語・文化・産業等によって最適な振舞いは異なる → カスタマイズ (tailoring) の必要性 ● カスタマイズ可能な範囲も、規格で規定 ○ たとえば、正規化アルゴリズムはカスタマイズ禁止 ○ Bidiや照合にはカスタマイズの余地がある

Slide 406

Slide 406 text

Slide 407

Slide 407 text

Slide 408

Slide 408 text

Slide 409

Slide 409 text

Slide 410

Slide 410 text

Slide 411

Slide 411 text

Slide 412

Slide 412 text

Slide 413

Slide 413 text

© 2024 Wantedly, Inc. フォント(原義)とタイプフェイス ● タイプフェイス (typeface): 　一定のコンセプトで作られた字形のシリーズ ○ フォントファミリー (font family) とも呼ぶ ○ 例: Helvetica ● フォント (font): 　タイプフェイスのうち、　特定のスタイル・ウェイトを持つもの ○ 例: Helvetica Condensed Bold Italic [BitesizeTypography3], [GoogleFontsGlossaryA] [BitesizeTypography3]

Slide 414

Slide 414 text

Slide 415

Slide 415 text

Slide 416

Slide 416 text

Slide 417

Slide 417 text

Slide 418

Slide 418 text

Slide 419

Slide 419 text

© 2024 Wantedly, Inc. OpenType と TrueType ● OpenType と TrueType: 代表的な2つのフォント規格 ○ OpenType (狭義): CFF (3次Bezier)、アラインメントゾーン ○ TrueType: glyf (2次Bezier)、VMベースのヒンティング ● 広義のOpenType = OpenType + TrueType ● OpenType = OFF ○ OFF (Open Font Format) はISO化されたOpenType仕様の名称 ● いずれも sfnt形式に包含される [OpenTypeOverview] [OpenTypeOverview] [OpenTypeComparison]

Slide 420

Slide 420 text

© 2024 Wantedly, Inc. OpenType と TrueType OpenType (CFF outline) TrueType OpenType spec = OFF spec Apple bitmap-only Apple Type1 wrapper *.otf, *.ttf, *.otc, *.ttc *.ttf, *.otc, *.ttc X11 bitmap-only *.otb *.dfont (suitcase内) sfnt-housed font (sfnt形式) [OpenTypeOverview], [OpenTypeFile], [OpenTypeRecom],, [OpenTypeComparison], [TrueTypeTables], [FontForgeGen], [FontForgeBitmap]

Slide 421

Slide 421 text

© 2024 Wantedly, Inc. OpenType と TrueType sfntのバージョン情報 "OTTO" OpenType CFF/CFF2 outline "\x00\x01\x00\x00" OpenType (TrueType) glyf outline "true", "\xA5kbd", "\xA5lst" TrueType (Apple専用フォント) "\x00\x02\x00\x00" TrueType (Win3.1 CJK) "typ1" PostScript Type 1 in sfnt TTC/OTC の場合は TTC Header が最初につくため、シグネチャは "ttcf" になる [OpenTypeFile], [TrueTypeTables], [FreeTypeSrc] src/sfnt/sfobjs.c sfnt_open_font, [FreeTypeSrc] src/truetype/ttobjs.c tt_face_init

Slide 422

Slide 422 text

© 2024 Wantedly, Inc. OpenType と TrueType ● Adobe が PostScript font を開発 ○ Type 1, Type 2, … ● Apple が TrueType を開発 ● Microsoft が TrueType と Type 2 を統合し OpenType を開発 ○ OpenType には TrueType と Type 2 (CFF) の両方を含められる [Perry1998], [Type1EOL] [TTHistory] [OpenTypeFAQ]

Slide 423

Slide 423 text

Slide 424

Slide 424 text

Slide 425

Slide 425 text

Slide 426

Slide 426 text

Slide 427

Slide 427 text

Slide 428

Slide 428 text

Slide 429

Slide 429 text

Slide 430

Slide 430 text

© 2024 Wantedly, Inc. グリフ・グリフ位置の決定 ● OTL: OpenType Layout ○ GSUB, GPOS, BASE, JSTF および GDEF を使用、OpenTypeの標準 ● AAT: Apple Advanced Typography ○ morx, kerx, feat, opbd などを使用、 TrueType で使われることがある ● SIL: SIL Graphite ○ Slif, Glat, Gloc, Feat, Sill を使用、高度なレイアウト制御用 ○ マイナー言語の特殊なレイアウトを、フォント側で実現することが主な目的 [OpenTypeLayoutOverview] [TrueTypeAAT] [Graphite] OpenType specはOTLのみ規定。AATはAppleのTrueType 仕様、SILはGraphite仕様でそれぞれ定義されている。

Slide 431

Slide 431 text

Slide 432

Slide 432 text

Slide 433

Slide 433 text

© 2024 Wantedly, Inc. OTL – GSUB ● GSUB はグリフの置き換えを指示する ● 各ルールは3つの適用条件を持つ ○ 条件1: 特定の文字体系 (script) のみで実行 ○ 条件2: 特定の言語体系 (language system) のみで実行 ○ 条件3: 特定の機能 (feature) が有効な場合のみ実行 ● ルールは典型的には「グリフ列」→「グリフ列」 ○ 代替置換 (alternate) や文脈依存の置換もできる置換ルールの適用順 (優先度) は LookupListでの宣言順で決まる。

Slide 434

Slide 434 text

Slide 435

Slide 435 text

© 2024 Wantedly, Inc. OTL – GPOS ● GPOS はグリフの位置計算を指示する ● 各ルールは3つの適用条件を持つ (GSUB と同じ) ○ 条件1: 特定の文字体系 (script) のみで実行 ○ 条件2: 特定の言語体系 (language system) のみで実行 ○ 条件3: 特定の機能 (feature) が有効な場合のみ実行 ● 各ルールはグリフの位置調整命令になっている

Slide 436

Slide 436 text

Slide 437

Slide 437 text

Slide 438

Slide 438 text

Slide 439

Slide 439 text

Slide 440

Slide 440 text

© 2024 Wantedly, Inc. アウトラインの決定主要なアウトライン形式は3種類 ● CFF: PostScript outline ○ 元々はAdobeのPostScript fontで使われていたもの ● TTF: TrueType outline ○ 元々のAppleのTrueType技術で使われていたアウトライン方式 ● SVG ○ 補助的なアウトライン方式で、主にカラー絵文字に使われる [RFC8081] §4.4.1 カラー絵文字はSVGを使わず COLR/CPAL で表現することも可能

Slide 441

Slide 441 text

Slide 442

Slide 442 text

© 2024 Wantedly, Inc. 曲線 ● 曲線: 連続した点の動き (曲がっていてもよい) ○ 曲線の数学的な扱いは、目的に応じてバリエーションがある ○ ここでは区分的 C1 級関数 γ: [0, a] → ℝ2 を考える。 ○ 交差や重複があってもよい (単純性は要求しない) ● 曲線の速度情報を除去する ○ 上記の曲線には速度情報が含まれている。イージング関数として使うときは必要だが、形状の記述には必要ないので、速度を除去した曲線も考えたい。 ○ ここでは区分的 C1 級関数 γ: [0, a] → ℝ2 を、狭義単調連続関数 φ: [0, a] → [0, b] の結合で同一視したものと考える。すなわち γ 〜 γ’ ⇔ ∃φ. γ ∘ φ = γ’ で同値類を構成する。

Slide 443

Slide 443 text

Slide 444

Slide 444 text

Slide 445

Slide 445 text

© 2024 Wantedly, Inc. 性質のよい曲線 ● 曲線を表す式は無数にある ○ たとえば y = sin(x) もそうした式のひとつ ○ 任意の形状を考えるときりがない ● 曲線を区分的に性質のいいもので表す ○ ここでは、スカラー係数を多項式または有理式で表せるものを考える ● 区分的 = いくつかの性質のいい曲線を繋げたもの ○ 定義域 [a, b] を a = a 1 , a 2 , …, a n = b で分割し、 [a 1 , a 2 ], [a 2 , a 3 ], …, [a n-1 , a n ] に制限した曲線をそれぞれ考える

Slide 446

Slide 446 text

Slide 447

Slide 447 text

Slide 448

Slide 448 text

© 2024 Wantedly, Inc. 区分的多項式曲線の表現力 ● n次曲線に固有の曲線が存在 ○ 曲線 y = xn は n-1 次曲線では表現できない ○ 多項式の一致を使って証明 (y(t) - x(t)n が恒等的に 0 であることから矛盾を導く) ● 有理曲線に固有の曲線が存在 ○ 円弧は多項式曲線では表現できない ○ 有理式の一致を使って証明 (x(t)2 + y(t)2 - 1 が恒等的に 0 であることから矛盾を導く)

Slide 449

Slide 449 text

© 2024 Wantedly, Inc. 区分的多項式曲線の表現力 ● 円弧は有理曲線 ○ (cos θ, sin θ) のままだと有理的でない ○ u = tan(θ/2) とおくと (cos θ, sin θ) = ((1 - u2)/(1 + u2), 2u/(1 + u2)) ■ ただし、 θ = π の場合は u = ±∞ になってしまう ○ さらに、 u = (2t - 1)/(t(1 - t)) とおけば円周も表現可能

Slide 450

Slide 450 text

Slide 451

Slide 451 text

Slide 452

Slide 452 text

© 2024 Wantedly, Inc. 曲線の表現力 ● アウトライン形式によって曲線表現が異なる ● CFF outline: 区分的3次多項式 ○ 3次Bezier曲線として表現 ● TTF outline: 区分的2次多項式 ○ 2次Bezier曲線として表現 (ただし後述の Boring Expansion も参照) ● SVG outline: 区分的3次多項式 + 楕円弧 ○ 任意の有理曲線ではないが、円弧や楕円弧を描ける逆に、双曲線などは描けない [OpenTypeComparison]

Slide 453

Slide 453 text

© 2024 Wantedly, Inc. 塗りのルール ● アウトライン形式によって塗りのルールが異なる ● CFF outline: 非ゼロ (原則として) ○ CFF2テーブルは非ゼロだが、CFFテーブルの扱いは明示されていない ● TTF outline: 非ゼロ ● SVG outline: 非ゼロ (奇数ルールにもできる) ○ fill-rule で変更可能 [OpenTypeComparison]

Slide 454

Slide 454 text

Slide 455

Slide 455 text

Slide 456

Slide 456 text

Slide 457

Slide 457 text

Slide 458

Slide 458 text

Slide 459

Slide 459 text

© 2024 Wantedly, Inc. ヒンティングの方式 ● CFF outline: 宣言的ヒンティング ○ フォントの構造に対する補助情報を宣言しておく ○ レンダリングエンジンがアウトラインの調整処理を行う ● TTF outline: 手続き的なヒンティング ○ アウトラインが簡易的なVMになっている ○ アウトライン命令から解像度を参照し、フォント自身がアウトラインを調整 [OpenTypeComparison], [AdobeType1] §5.1

Slide 460

Slide 460 text

Slide 461

Slide 461 text

Slide 462

Slide 462 text

Slide 463

Slide 463 text

© 2024 Wantedly, Inc. カウンター (counter) カウンター (counter) ● ステムの補助を行う情報 ● 縦画と縦画の隙間・横画と横画の隙間を指定 ○ Type1 ではかわりに vstem3 / hstem3 を使用 ● 十分な空間を確保したり、等間隔性を維持したり ● 記号や漢字等で利用 ○ たとえば Source Sans では U+2026 (…) と U+2261 (≡) で利用 [AdobeCIDKeyed] §4

Slide 464

Slide 464 text

Slide 465

Slide 465 text

Slide 466

Slide 466 text

Slide 467

Slide 467 text

Slide 468

Slide 468 text

Slide 469

Slide 469 text

Slide 470

Slide 470 text

Slide 471

Slide 471 text

Slide 472

Slide 472 text

Slide 473

Slide 473 text

Slide 474

Slide 474 text

Slide 475

Slide 475 text

Slide 476

Slide 476 text

Slide 477

Slide 477 text

Slide 478

Slide 478 text

Slide 479

Slide 479 text

Slide 480

Slide 480 text

Slide 481

Slide 481 text

© 2024 Wantedly, Inc. スポンサー文字コードの維持に協力する方法 ● Unicodeのスポンサーになる ○ Unicodeでは「文字」に対してスポンサーをすることができる ○ たとえば IBM は ☁ に対してスポンサーしている ● 大企業の製品を使う ○ IBM, Adobe, Apple 等、長くUnicodeに関与している企業を支援することも有用 ● その他 ○ ISOやJIS, IPSJ なども文字コードに関する仕事をしている

Slide 482

Slide 482 text

© 2024 Wantedly, Inc. まとめ ● 過去から現在にかけての文字コードの進化を紹介した ○ 文字コードは業界ごとに独自に発展してきた側面もあり、本当の意味で「満遍なく」紹介できているわけではない ○ オープンシステムやWebで使われている(使われていた)コードをターゲットに広く紹介することはできたと思う ● その終着点として、Unicodeがいかにして現実の問題に取り組んでいるかを紹介した

Slide 483

Slide 483 text

Slide 484

Slide 484 text

© 2024 Wantedly, Inc. 文献 – 第1部その1 [Heide2009] Punched-Card Systems and the Early Information Explosion, 1880–1945 (Studies in Industry and Society) (English Edition), Lars Heide, Johns Hopkins University Press, 2009, Amazon Kindle edition

Slide 485

Slide 485 text

© 2024 Wantedly, Inc. 文献 – 第2部その1 [ISO-IR] International Register of Coded Character Sets to be Used with Escape Sequences (archived, PDF) https://web.archive.org/web/20220925210553/https://itscj.ipsj.or.jp/english/vbcqpr00000004qn-att/ISO-I R.pdf

Slide 486

Slide 486 text

© 2024 Wantedly, Inc. 文献 – 第3部その1 [Unicode] The Unicode® Standard Version 17.0 — Core Specification https://www.unicode.org/versions/Unicode17.0.0/core-spec/ [UCD] Unicode Character Database 17.0 https://www.unicode.org/ucd/ https://www.unicode.org/Public/17.0.0/ucd/ [UCD1.0.0] Reconstructed Unicode Character Database for Unicode 1.0.0 and Unicode 1.0.1 https://www.unicode.org/versions/Unicode1.0.0/ [UAX#9] Unicode® Standard Annex #9 Unicode Bidirectional Algorithm, Version 51 https://www.unicode.org/reports/tr9/tr9-51.html [UAX#11] Unicode® Standard Annex #11 East Asian Width, Version 44 https://www.unicode.org/reports/tr11/tr11-44.html

Slide 487

Slide 487 text

© 2024 Wantedly, Inc. 文献 – 第3部その2 [UAX#14] Unicode® Standard Annex #14 Unicode Line Breaking Algorithm, Version 55 https://www.unicode.org/reports/tr14/tr14-55.html [UAX#15] Unicode® Standard Annex #15 Unicode Normalization Forms, Version 57 https://www.unicode.org/reports/tr15/tr15-57.html [UAX#29] Unicode® Standard Annex #29 Unicode Text Segmentation, Version 47 https://www.unicode.org/reports/tr29/tr29-47.html [UAX#31] Unicode® Standard Annex #31 Unicode Identifiers and Syntax, Version 43 https://www.unicode.org/reports/tr31/tr31-43.html [UAX#38] Unicode® Standard Annex #38 Unicode Han Database (Unihan), Version 39 https://www.unicode.org/reports/tr38/tr38-39.html

Slide 488

Slide 488 text

© 2024 Wantedly, Inc. 文献 – 第3部その3 [UAX#44] Unicode® Standard Annex #44 Unicode Character Database, Version 36 https://www.unicode.org/reports/tr44/tr44-36.html [UAX#50] Unicode® Standard Annex #50 Unicode Vertical Text Layout, Version 33 https://www.unicode.org/reports/tr50/tr50-33.html [UAX#53] Unicode® Standard Annex #53 Unicode Arabic Mark Rendering, Version 11 https://www.unicode.org/reports/tr53/tr53-11.html [UAX#57] Unicode® Standard Annex #57 Unicode Egyptian Hieroglyph Database (Unikemet), Version 5 https://www.unicode.org/reports/tr57/tr57-5.html [UTS#10] Unicode® Technical Standard #10 Unicode Collation Algorithm, Version 53 https://www.unicode.org/reports/tr10/tr10-53.html

Slide 489

Slide 489 text

© 2024 Wantedly, Inc. 文献 – 第3部その4 [UTS#18] Unicode® Technical Standard #18 Unicode Regular Expressions, Version 23 https://www.unicode.org/reports/tr18/tr18-23.html [UTS#37] Unicode® Technical Standard #37 Unicode Ideographic Variation Database, Version 14 https://www.unicode.org/reports/tr37/tr37-14.html [UTS#39] Unicode® Technical Standard #39 Unicode Security Mechanisms, Version 32 https://www.unicode.org/reports/tr39/tr39-32.html [UTS#51] Unicode® Technical Standard #51 Unicode Emoji, Version 29 https://www.unicode.org/reports/tr51/tr51-29.html [UTS#55] Unicode® Technical Standard #55 Unicode Source Code Handling, Version 5 https://www.unicode.org/reports/tr55/tr55-5.html

Slide 490

Slide 490 text

© 2024 Wantedly, Inc. 文献 – 第3部その4 [UTS#6] Unicode® Technical Standard #6 A Standard Compression Scheme for Unicode, Version 4 (Stabilized) https://www.unicode.org/reports/tr6/tr6-4.html [UTR#16] Unicode® Technical Report #16 UTF-EBCDIC, Version 8 (Stabilized) http://www.unicode.org/reports/tr16/tr16-8.html [UTR#26] Unicode® Technical Report #26 Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8), Version 4 (Stabilized) https://www.unicode.org/reports/tr26/tr26-4.html [UTN#6] Unicode Technical Note #6 BOCU-1: MIME-Compatible Compression, Version 2 http://www.unicode.org/notes/tn6/tn6-2.html

Slide 491

Slide 491 text

© 2024 Wantedly, Inc. 文献 – 第3部その5 [RFC2152] RFC 2152 - UTF-7 A Mail-Safe Transformation Format of Unicode, D. Goldsmith and M. Davis https://www.rfc-editor.org/rfc/rfc2152.html [RFC3492] RFC 3492 - Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA), A. Costello https://www.rfc-editor.org/rfc/rfc3492.html [RFC4042] RFC 4042 - UTF-9 and UTF-18 Efficient Transformation Formats of Unicode, M. Crispin https://www.rfc-editor.org/rfc/rfc4042.html

Slide 492

Slide 492 text

© 2024 Wantedly, Inc. 文献 – 第3部その6 [ISO10646] ISO/IEC 10646:2020 Information Technology — Universal coded character set (UCS) https://www.iso.org/standard/76835.html [n0783] Working document for ISO/IEC Draft International Standard 10646-1.2 ISO/IEC DIS 10646-1.2, 1991, obtained at Historical Directory of the UTC Document Registry https://www.unicode.org/L2/Historical/ [Yasuoka2006] 文字符号の歴史―欧米と日本編―, 安岡孝一・安岡素子, 共立出版, 2006 初版第1刷, ISBN 9784320121027 https://www.kyoritsu-pub.co.jp/book/b10010457.html [UNarrative] Summary Narrative — History of Unicode https://www.unicode.org/history/summary.html, obtained at 2025-11-15, http://web.archive.org/web/20251004185748/https://www.unicode.org/history/summary.html [UChrono] Chronology of Unicode Version 1.0 — History of Unicode https://www.unicode.org/history/versionone.html, obtained at 2025-11-15, http://web.archive.org/web/20251004185748/https://www.unicode.org/history/summary.html

Slide 493

Slide 493 text

© 2024 Wantedly, Inc. 文献 – 第3部その7 [ECMA262] ECMA-262 ECMAScript® 2025 language specification, 15th edition, June 2024 (PDF version), obtained at https://ecma-international.org/publications-and-standards/standards/ecma-262/ [WTF-8] The WTF-8 Encoding https://wtf-8.codeberg.page/, version 2022-02-23, obtained at 2025-11-15, https://web.archive.org/web/20250923071415/https://wtf-8.codeberg.page/

Slide 494

Slide 494 text

© 2024 Wantedly, Inc. 文献 – 第3部その8 [BitesizeTypography3] Fonts and typefaces - Typography - Eduqas - GCSE Art and Design Revision - Eduqas - BBC Bitesize https://www.bbc.co.uk/bitesize/guides/zyv4jfr/revision/3, retrieved at 2025-11-23 [GoogleFontsGlossaryA] Typeface – Fonts Knowledge - Google Fonts https://fonts.google.com/knowledge/glossary/typeface, retrieved at 2025-11-23, https://web.archive.org/web/20250830075708/https://fonts.google.com/knowledge/glossary/typeface [Perry1988] Inventing Postscript, the Tech That Took the Pain out of Printing, Tekla S. Perry, IEEE Spectrum, 1998-05. Obtained from https://spectrum.ieee.org/adobe-postscript at 2025-11-23, https://web.archive.org/web/20250917214607/https://spectrum.ieee.org/adobe-postscript [Type1EOL] PostScript Type 1 fonts end of support https://helpx.adobe.com/fonts/kb/postscript-type-1-fonts-end-of-support.html, retrieved at 2025-11-23, https://web.archive.org/web/20250603062638/https://helpx.adobe.com/fonts/kb/postscript-type-1-fonts -end-of-support.html

Slide 495

Slide 495 text

© 2024 Wantedly, Inc. 文献 – 第3部その9 [OpenTypeFAQ] OpenType overview - Typography | Microsoft Learn https://learn.microsoft.com/en-us/typography/opentype/, retrieved at 2025-11-23, https://web.archive.org/web/20250707080959/https://learn.microsoft.com/en-us/typography/opentype/ [TTHistory] A brief history of TrueType - Typography | Microsoft Learn https://learn.microsoft.com/en-us/typography/truetype/history, retrieved at 2025-11-23, https://web.archive.org/web/20250728024258/https://learn.microsoft.com/en-us/typography/truetype/h istory

Slide 496

Slide 496 text

© 2024 Wantedly, Inc. 文献 – 第3部その10 [OpenType] OpenType specification (OpenType 1.9.1) - Typography | Microsoft Learn https://learn.microsoft.com/en-us/typography/opentype/spec/, retrieved at 2025-11-23 [OpenTypeOverview] OpenType specification overview https://learn.microsoft.com/en-us/typography/opentype/spec/overview [OpenTypeLayoutOverview] OpenType Layout overview https://learn.microsoft.com/en-us/typography/opentype/spec/ttochap1 [OpenTypeFile] OpenType font file https://learn.microsoft.com/en-us/typography/opentype/spec/otff [OpenTypeRecom] Recommendations for OpenType Fonts https://learn.microsoft.com/en-us/typography/opentype/spec/recom [OpenTypeComparison] Comparison of 'glyf', 'CFF ' and CFF2 tables https://learn.microsoft.com/en-us/typography/opentype/spec/glyphformatcomparison

Slide 497

Slide 497 text

© 2024 Wantedly, Inc. 文献 – 第3部その11 [TrueType] Fonts - TrueType Reference Manual - Apple Developer https://developer.apple.com/fonts/TrueType-Reference-Manual/, retrieved at 2025-11-23, https://web.archive.org/web/20250921230019/https://developer.apple.com/fonts/TrueType-Reference-M anual/ [TrueTypeTables] Font Tables https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html [TrueTypeAAT] About Apple Advanced Typography Fonts https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6AATIntro.html

Slide 498

Slide 498 text

© 2024 Wantedly, Inc. 文献 – 第3部その12 [FontForgeGen] Generate Font Dialog - FontForge 20230101 Documentation https://fontforge.org/docs/ui/dialogs/generate.html, retrieved at 2025-11-23 https://web.archive.org/web/20250919153344/https://fontforge.org/docs/ui/dialogs/generate.html [FontForgeBitmap] Several Formats for bitmap only sfnts - FontForge 20230101 Documentation https://fontforge.org/docs/techref/bitmaponlysfnt.html, retrieved at 2025-11-23 https://web.archive.org/web/20251007182038/https://fontforge.org/docs/techref/bitmaponlysfnt.html [FreeTypeSrc] FreeType 2.14.1 source code https://github.com/freetype/freetype/tree/VER-2-14-1

Slide 499

Slide 499 text

© 2024 Wantedly, Inc. 文献 – 第3部その13 [RFC8081] RFC 8081 - The "font" Top-Level Media Type, C. Lilley, https://www.rfc-editor.org/rfc/rfc8081.html [Graphite] SIL Graphite official site https://graphite.sil.org/ [AdobeDocs] Font technical notes https://adobe-type-tools.github.io/font-tech-notes/ [AdobeType1] Adobe Type 1 Font Format, third printing, Adobe Systems Incorporated, 1993, Addison-Wesley, obtained from https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf [AdobeCIDKeyed] CID-Keyed Font Technology Overview (Adobe Tech Note #5092) https://adobe-type-tools.github.io/font-tech-notes/pdfs/5092.CID_Overview.pdf