文字コードの話

ウォンテッドリー社内で数回に分けて発表した「文字コードの話」のスライドです。

2026/02/21: まだ埋めきれていない部分、出典の確認・整理が不十分な部分等がありますが、ちょうど文字コードが話題になっているので一旦アップロードしてしまいます。ご指摘歓迎です。

【未適用の修正項目】

・ DEL が想定している媒体は穿孔カードではなく鑽孔テープと思われる
・ ß は ss の合字ではなく sz の合字
・ UTF-16 の例示に使われている「ギ」「기」に対応するバイト列は 30 AC ではなく 30 AE

Transcript

1. © 2024 Wantedly, Inc. 文字コードの話 Jul. 9 2024 - Masaki Hara
2. © 2024 Wantedly, Inc. 本発表の目的 • アプリオリに与えられたものとして享受されがちな「文字コー ド」の概念を解体・再構築して理解する • 現在確立されている文字コードには多くの設計上の判断が影 響していることを理解する • 現在確立されている文字コードには多様な実装が影響を与え ていることを理解する
3. © 2024 Wantedly, Inc. この発表の聞き方 以下のような視点で聞いてみよう • 「文字コード」をプロダクトとしてみたときの、プロダクトオー ナーとして判断すべきことは何か • 少ないビット数にどうやって文字を詰めるか、実際に計算しな がら考えてみる
4. © 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や関連仕様の策定を行うための業界団体。
5. © 2024 Wantedly, Inc. 第1部: 〜ASCII
6. © 2024 Wantedly, Inc. 　単なるバラバラの線に、一定の音と一定の意味とを有たせるも のは、何か？　ここまで思い到った時、老博士は躊躇なく、文字の 霊の存在を認めた。 — ナブ・アヘ・エリバ博士 (中島敦『文字禍』)
7. © 2024 Wantedly, Inc. 文字コード前史
8. © 2024 Wantedly, Inc. 文字コード前史 「文字に数値を割り当てる」という行為は昔から広く行われてきた • シーザー暗号 • 数秘術 • 点字 etc. 全部は紹介できないので、現代で耳にする文字コードとの関連性を考慮して紹 介します。
9. © 2024 Wantedly, Inc. タイプライター
10. © 2024 Wantedly, Inc. タイプライター • 19世紀頃からタイプライターが進化し普及 • 打鍵の物理的な力でインクを押しつけて印字する機械 • タイプライター自体には文字コードはない しかし、現代の文字コードには影響を与えている
11. © 2024 Wantedly, Inc. タイプライターの構造 打鍵後、紙面が左に送られる。 この左右に動く部分をキャリッジ という Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et do 紙面 (可動) 本体 (固定部分) キャリッジ (可動部分) カーソル (固定) ※機種による
12. © 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- 紙面 (可動) 本体 (固定部分) キャリッジ (可動部分) カーソル (固定) キャリッジリターン レバー ※機種による
13. © 2024 Wantedly, Inc. スペースとバックスペース • スペースはカーソルを右に 進める (紙面を左に進める) • バックスペースはその逆 • 紙面を送らないキー = デッ ドキー Lorem ip space backspace ※ ただし、その後の整理でスペースは図形文字、バッ クスペースは制御コードとして異なる分類を受けること になる
14. © 2024 Wantedly, Inc. 合成文字 • バックスペースを使った 二重打ち込み Il est n Il est ne Il est ne E BS Il est né ´
15. © 2024 Wantedly, Inc. 合成文字 • デッドキーを使った 二重打ち込み Il est n Il est n´ Il est né ´ E
16. © 2024 Wantedly, Inc. ダイアクリティカルマーク 代表的なダイアクリティカルマーク (フランス語・スペイン語などで 使用) é è ê ë ç ñ 鋭アクセント 鈍アクセント サーカム フレックス トレマ / ウムラウト セディーユ チルダ ` ^ ~
17. © 2024 Wantedly, Inc. 下線 イタリック体のかわりに、下線を重ね打ちして強調を表現 _ 下線 _ Lorem ipsum _____
18. © 2024 Wantedly, Inc. シフト • 活字棒に複数の文字が刻まれている • シフトキーを押し込むと機械の位置が変 わり、通常と異なる文字が印字される • シフトロックを使うと、シフト状態を固定で きる ɘ Ǝ
19. © 2024 Wantedly, Inc. 文字の統合 • 限られたキーで複数の文字をあらわす (以下は一例) “ ” ‘ ’ ' ′ " 二重引用符 − ‐ – — 引用符 アポストロフィー プライム マイナス ' ハイフン enダッシュ emダッシュ - 本来、これらは別の文字 ! 手書きや活版印刷では区別されていた l 小文字のL 1 数字の1 L
20. © 2024 Wantedly, Inc. テレタイプ
21. © 2024 Wantedly, Inc. テレタイプとボドー・マレーコード 19世紀に電信技術が発展し、印刷の自動化も進んだ そこで使われた文字コードのひとつに ITA2 がある。 • 5bit 固定長 + 2状態 (文字/数字) • 制御コードを文字の一種として扱う ◦ 数字モードへの切り替え / 文字モードへの切り替え ◦ NULL文字と削除 ◦ キャリッジリターンとラインフィード ◦ Who are you? ◦ ベル
22. © 2024 Wantedly, Inc. 制御コード 通信装置と印字装置が一体だった時代に、「制御コード」を文字 の一種として扱う慣習が確立 制御コードは大きく以下のように大別できる • 通信の制御 • エンコーディングの制御 • 印字の制御 → 現代の計算機では通常イーサネットやTCPなど下位のレイヤでハンドルさ れるが、ASCIIのDC1/DC3等を使うプロトコルもある → ASCIIのSO/SI等に相当。UTF-8では使わない → ASCIIのHT/CR/LFやUnicodeのCf文字などに相当
23. © 2024 Wantedly, Inc. 文字のレトロニム 「文字」の概念が広がったので、旧来の「文字」の概念に名前が必 要になった。これらは現代では • 「図形文字」 (graphic character) あるいは • 「印字可能文字」 (printable character) と呼ばれる スペースは何も印字しないが、図形文字の一種として扱うことが多い。 結合文字は特殊な印字規則を持つが、図形文字の一種として扱う。
24. © 2024 Wantedly, Inc. パンチカード
25. © 2024 Wantedly, Inc. パンチカード パンチカード • 厚紙などに穴をあけて 作られる記録媒体 • 古くはジャカード織機 などで使われた c c
26. © 2024 Wantedly, Inc. ホレリスの機械 • ホレリスはパンチカードを使った統計機械を考案 • 1890年の米国勢調査で大活躍した • ホレリスの会社は別の3社と合併しCTR社 (Computing-Tabulating-Recording) となる。
27. © 2024 Wantedly, Inc. ホレリスの機械 • ホレリスはパンチカードを使った統計機械を考案 • 1890年の米国勢調査で大活躍した • ホレリスの会社は別の3社と合併しCTR社 (Computing-Tabulating-Recording) となる。 • CTRはのちに IBM と改称
28. © 2024 Wantedly, Inc. パンチカードによる統計 • ソーター: パンチカードを、穴の位置に応じて分類する機械 ◦ GROUP BY と ORDER BY に相当 • 作表機: パンチカードを集計する機械 ◦ 基本的には特定の位置に空いた穴の数を数える ◦ SELECT COUNT(*) に相当 • 初期の統計機械は電気機械的に実装された ◦ たとえば、パンチ穴があるときだけ回路が導通し、カウンター機械 (アキュムレーター) が 機械的に作動する
29. © 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
30. © 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
31. © 2024 Wantedly, Inc. 12bit文字コード • 12bit × 80列 12bit を1文字とみなせる • ナンバリングが特殊 ◦ 0番目 = 10番目 ◦ 11/12は下位ビット方向に進行 0 1 2 3 4 5 6 7 8 9 12 11 10 ※ここではカードを90°回転した状態で表記
32. © 2024 Wantedly, Inc. 12bit文字コード 数字 • 11/12は使わない • 0〜9 を1つだけ開ける 0 1 2 3 4 5 6 7 8 9 12 11 10 0 1 2 8 9 ※ここではカードを90°回転した状態で表記
33. © 2024 Wantedly, Inc. 12bit文字コード 英文字 (大文字) • 1〜9 と 10〜12 から1つ ずつ開ける • 9 × 3 = 27 通り • 穴が隣合うケースを除く と26通りになる ◦ 穴が隣合うケースには / を割り 当て 0 1 2 3 4 5 6 7 8 9 12 11 10 A B J K R ※ここではカードを90°回転した状態で表記
34. © 2024 Wantedly, Inc. 12bit文字コード 英文字 (大文字) • 1〜9 と 10〜12 から1つ ずつ開ける • 9 × 3 = 27 通り • 穴が隣合うケースを除く と26通りになる ◦ 穴が隣合うケースには / を割り 当て 0 1 2 3 4 5 6 7 8 9 12 11 10 / S T Y Z ※ここではカードを90°回転した状態で表記
35. © 2024 Wantedly, Inc. 1940s〜1950s • 1940s: 電子計算機が登場 (ENIAC, EDSAC, etc.) • 1950s: 汎用化/量産化 (UNIVAC, IBM 701, etc.) ◦ 量産といっても、大きくて高価なものであり、研究機関や政府の統計局などが購入するも のだった • パンチカードに書かれていた情報も電子的に処理されるよう になっていく ◦ それまでは電気機械的に処理していた
36. © 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などもある
37. © 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をシフトしたようなもの
38. © 2024 Wantedly, Inc. ASCII
39. © 2024 Wantedly, Inc. ASCIIの時代背景 • 穿孔テープで8bit単位のものが流通していた ◦ 1bitをチェックサムに使うと、残りは7bit • 記録と通信の両方で使えるコードが必要だった ◦ 現代のTCP/IPのように、通信制御と通信内容が別のレイヤーに分けられているとは限ら ない ◦ 制御コードも1文字でシンプルに表す必要がある
40. © 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 : ; < = > ?
41. © 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
42. © 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 という記法が成立したと言われている ただし、この版は出版されることはなかった
43. © 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 という記法が成立したと言われている ただし、この版は出版されることはなかった
44. © 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 : ; < = > ?
45. © 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
46. © 2024 Wantedly, Inc. ASCII - 制御コード • 制御コードは 0x00 〜 0x1F と 0x7F ◦ パンチカードでは穿孔が不可逆操作のため、文字を抹消するために 0b1111111 がDELに 割り当てられた ◦ 残りの制御コードはまとまった領域に確保された • 0x00 〜 0x1F を C0制御コードという 制御コードに意味が決まっていても、機器やソフトウェアがそれを実装している とは限らないので注意。
47. © 2024 Wantedly, Inc. ASCII - 制御コード • CR / LF … CRはキャリッジの復帰、LFは行送りに由来 ◦ 実装差異があり、改行を CR+LF, CR単独, またはLF単独で表すことがある ◦ C1制御コードのNELのほうが意味は明確だが、あまり使われない • HT / VT … タブ ◦ HT はタイプライターで作表用にキャリッジの位置を飛ばす機能に由来 ◦ VT はその垂直版 • BS … バックスペース • FF … ページ送り
48. © 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としても扱われる
49. © 2024 Wantedly, Inc. ASCII - 制御コード • BEL … 受信側でベルやビープ音を鳴らす • ENQ, ACK, DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN … その他通信用 • SO, SI … 文字集合の切り替え (シフト) • ESC … エスケープシーケンスの開始 ↑SO, SI, ESC はあとで出てくるので覚えておいてください
50. © 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
51. © 2024 Wantedly, Inc. ASCII - 図形文字 • 0x20 〜 0x7E (0x7F は含まない) が図形文字 • 数字、英文字 (大文字・小文字) と記号類を収録 ◦ 0/1 と O/I は区別される ◦ 数字・英文字ともに順に並ぶが、大文字と小文字は別ブロックなのでコレーションでは注 意が必要 • シフト関係 ◦ 2列目と 3列目 ◦ 4〜5列目 と 6〜7列目 ◦ 一般的な日本語キーボード配列は ASCIIのシフト関係を強く反映している
52. © 2024 Wantedly, Inc. ASCII - 図形文字 • - は hyphen-minus と呼ばれる ◦ ハイフンとマイナスの兼用だが、ダッシュにも使われる • " は引用符 (開き・閉じ兼用) • ' はアポストロフィー ◦ 引用符 (開き・閉じ兼用) やプライムにも使われる • ^ ~ ` はサーカムフレックス、チルダ、鈍アクセント ◦ 本来はダイアクリティカルマークなので上付きだが、今では中央にも書かれる ◦ ` は開き引用符、 ~ はスワングダッシュとして使われることもある
53. © 2024 Wantedly, Inc. ASCII - 図形文字 • _ は下線 ◦ 文字に重ね打ちして下線を引くためのものだった • < > は不等号 ◦ 山括弧として使われることもある • # は番号記号 (井桁) ◦ シャープ ♯ の代用表記としても使われる (C# など) が、斜線の向きが異なる • | は縦棒 ◦ 中置記法が多いが、数学等では括弧のように使われることがある ◦ 異書体 (allograph) として ¦ が使われることもある
54. © 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
55. © 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
56. © 2024 Wantedly, Inc. 第1部のまとめ
57. © 2024 Wantedly, Inc. 第1部まとめ • タイプライターや電信など、先行する技術の影響を受けながら ASCIIが誕生 ◦ いっぽう、パンチカードの影響を受けた EBCDICも互換性のために生き続けることになる • ASCII自身も以降の技術を大いに規定する役割となった ◦ たとえば、以降のプログラミング言語の構文は ASCIIの影響を受けることになる
58. © 2024 Wantedly, Inc. 第2部: 多言語化
59. © 2024 Wantedly, Inc. 　すべての文化集団は，独自の言語，文字，書記システムを持つ． それゆえ，個々の書記システムをサイバースペースに移転するこ とは，文化的資産の継承という意味で，情報通信技術にとって非 常に重要な責務といえよう． — W3C『日本語組版処理の要件』
60. © 2024 Wantedly, Inc. 文字コードの国際化 • 「文字コード」は普遍的な概念であり、各国・各組織で独自に 運用されてきた • 本発表ではそれらを全て扱えないので、ASCIIとの関連性に 注目しながら紹介
61. © 2024 Wantedly, Inc. 時代背景 (参考) • 1965 IBM System/360 • 1969 ARPANET開始 (インターネットの前身) • 1969 Unix開発開始 • 1974 Intel 8080 • 1981 PC DOS (MS-DOS) • 1986 Intel 80386 • 1989 World Wide Web
62. © 2024 Wantedly, Inc. 言語と文字
63. © 2024 Wantedly, Inc. 言語と国 • 言語 vs 国 カナダ アメリカ 英語 フランス語 フランス スペイン語 そもそも、「ある国である言語が話されているか ?」というのはゼロイチではなく、公用語としての地位・事実上の公用 語としての地位・ネイティブスピーカーの割合・ノンネイティブスピーカーの割合などさまざまな尺度が存在し、同じ国 の中での地域差もある。 それを差し引いてもなお多様な関係があるというのが、以下の図。
64. © 2024 Wantedly, Inc. 文字と言語 • 文字 & 表記体系 vs 言語 Script Writing Systems 英語 フランス語 ラテン文字 ベトナム語 漢字 英語の表記体系 フランス語の表記体系 クオックグー チュノム 中国語 中国語の表記体系 日本語 平仮名 片仮名 日本語の表記体系 日本語のラテン文字表記体系などもある (ローマ字運動) が、省略している。 複数の文字のうちいずれかを使うものが多いが、日本語 (の漢字による表記体系 )では 3つの文字を組み合わせて書かれる。
65. © 2024 Wantedly, Inc. コードページ
66. © 2024 Wantedly, Inc. 多言語化 ひとつのシステムで複数の言語を扱えるようにするには? • テキスト外で切り替える ◦ OSをカスタマイズして出荷 ◦ プロセスごとに切り替え ◦ 文書のメタデータに含める • テキスト内で切り替える ◦ テキスト内の制御シーケンスで、文字コードを切り替える • 統一コード ◦ 状態を持たせず、世界中の文字が入った文字コードを使う
67. © 2024 Wantedly, Inc. コードページ • 様々な文字エンコーディングに番号をつけて管理 • IBMとMSのものが有名 ◦ 元々はコード表が記載された本のページ番号だったらしい ◦ MSはIBMと同じ番号体系だったが、OSでの協業をやめてからは独自に番号を割り当て ている • 代表的なもの ◦ IBM/MSコードページ 932 (Shift_JIS 派生) ◦ Windows-1252 ◦ MSコードページ 65001 (UTF-8)
68. © 2024 Wantedly, Inc. コードページ • DOSやWindowsでは、chcpコマンドでコードページを変更 可能 ◦ つまり、OSの設定として文字エンコーディングを選ぶことができた
69. © 2024 Wantedly, Inc. MIME Type • Content-Type: text/plain; charset=utf-8 ◦ 元々はメールプロトコルの拡張機能として 1992年に導入されたもの ◦ 今ではHTTPで見ることが多い • RFC 2978の規定により、IANAが文字コードの名前を管理 ◦ ただし、実際のブラウザの判別アルゴリズムは WHATWG MIME Sniffingに規定
70. © 2024 Wantedly, Inc. ISO/IEC 646
71. © 2024 Wantedly, Inc. ISO/IEC 646 ISO/IEC 646 (ECMA-6) • ASCIIベースの各国用7bitコード • 置換できるのは12文字だけ ◦ 2行目の記号から #, $ を置換可能 (# → £, $ → ¤ のみ) ◦ 4〜5行目の記号から @, [, \, ], ^ を置換可能 ◦ 6〜7行目の記号から `, {, |, }, ~ を置換可能 • 12文字ではラテン文字の拡張くらいしかできない ◦ 他の方法については後述 「各言語用」ではなく「各国用」という扱いだった たとえば通貨記号を追加したイギリス版がある
72. © 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となっている ã と ā では意味が違う点に注意 (そもそもオーバーラインとマクロン自体が違う記号)
73. © 2024 Wantedly, Inc. ISO-IR-021 ISO/IEC 646 準拠のドイツ語コードの例 0x33 # 0x34 $ 0x40 @ 0x5B [ 0x5C \ 0x5D ] 0x5E ^ 0x60 ` 0x7B { 0x7C | 0x7D } 0x7E ~ # $ § Ä Ö Ü ^ ` ä ö ü ß
74. © 2024 Wantedly, Inc. ISO/IEC 646 と C #include <stdio.h> int main(int argc, char *argv[]) { printf("Hallo Welt!\n"); }
75. © 2024 Wantedly, Inc. ISO/IEC 646 と C #include <stdio.h> int main(int argc, char *argvÄÜ) ä printf("Hallo Welt!Ön"); ü
76. © 2024 Wantedly, Inc. ISO/IEC 646 と C - trigraph ??=include <stdio.h> int main(int argc, char *argv??(??)) ??< printf("Hallo Welt!??/n"); ??>
77. © 2024 Wantedly, Inc. ISO/IEC 646 と C - Digraph %:include <stdio.h> int main(int argc, char *argv<::>) <% printf("Hallo Welt!Ön"); %>
78. © 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) # ## %: %:%:
79. © 2024 Wantedly, Inc. JIS X 0201 ラテン文字用図形文字集合 IRV (1973年版) をもとにドル記号と円記号を定義 0x33 # 0x34 $ 0x40 @ 0x5B [ 0x5C \ 0x5D ] 0x5E ^ 0x60 ` 0x7B { 0x7C | 0x7D } 0x7E ~ # $ @ [ ¥ ] ^ ` { | } ‾ 通貨記号用として使えそうな 0x33, 0x34は置換先の記号が £ と ¤ に限定されていた。 そのため \ を置換対象に選んだのではないかと思う。
80. © 2024 Wantedly, Inc. 文字集合と符号化方式
81. © 2024 Wantedly, Inc. 文字集合の拡大 ASCIIにさらに文字を足すには以下のいずれかが必要 • 文字集合の切り替え機能をつける • 8bitに増やす • (上に加えて)マルチバイト文字の導入 → ISO/IEC 2022 (ECMA-35) もちろん、ビット数を8bitに増やすには、関連する機器やソフトウェアがそ れに対応している必要がある。 しかし時代の流れは、8bitをフルに使える方向に進んでいった。
82. © 2024 Wantedly, Inc. ISO/IEC 2022 ISO/IEC 2022 (ECMA-35) • 7bit/8bitコードの基本構造を規定 • 文字集合の切り替えや、マルチバイト文字にも対応 • 現在のUTF-8とは非互換
83. © 2024 Wantedly, Inc. 文字集合と符号化方式 せっかく定義した文字集合を使い回したい → 文字集合と符号化方式の分離 (符号化)文字集合 (CCS) 文字に番号をつける 符号化方式 (CES) 番号をバイト列に対応づける とはいっても、任意の文字集合を任意の方式で符号化できるわけではない。 たとえばJIS X 0208をUTF-8で符号化することはできない。 あくまで緩くモジュラー化するための枠組みだと考えるのがベスト。 文字エンコーディング (character encoding) このような区別は後から生じたものであるため、文字エンコーディングのことを charsetと呼ぶこともある。
84. © 2024 Wantedly, Inc. 文字集合の切り替え
85. © 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度で反転した形で書かれることが 多いが、本スライドでは横向きで統一する。
86. © 2024 Wantedly, Inc. ISO/IEC 2022の基本構造 • 制御コードで複数の文字種 を切り替えて利用することも できる ◦ GLとGRは同じ形なので、G1をGLに 呼び出してもいいし、8bitコードでGR をそのまま使ってもいい ◦ タイプライターの 「シフトロック」と類似 0x x0 xF 1x 2x 7x CL GL G0 G1 Shift In Shift Out
87. © 2024 Wantedly, Inc. 図形文字集合の大きさ • 各文字集合はGL/GRに割り当てて使われるため、最大94文 字を定めることができた • その後このルールは拡張されることになる ◦ SP/DEL用の領域を追加で利用できる、 96文字の図形文字集合 ◦ マルチバイト文字 (94×94 や 96×96)
88. © 2024 Wantedly, Inc. JIS X 0201 JIS X 0201 (JIS C 6220) は以下の2つの集合を規定 • ラテン文字用図形文字集合 (A, B, C, …) ◦ ISO/IEC 646 互換, G0に指示 • 片仮名図形文字集合 (ア, イ, ウ, …) ◦ いわゆる半角カタカナ, G1に指示 7bitで運用する場合、SIでカタカナに切り替え、 SOでラテン文字に戻す
89. © 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. 全角については後述 これが最初のカナ文字コードというわけではないが、 現代での重要度を考慮してこれを紹介
90. © 2024 Wantedly, Inc. JIS X 0201 片仮名図形文字集合 • 仮名の基本文字は46文字 ◦ 促音と拗音に使われる捨て仮名は 9文字 ◦ 濁点つきの文字が最低17文字、半濁点つきの文字が最低 5文字必要だが、濁点と半濁 点を別の文字に分けて2文字に節約している • 94文字ある領域のうち、全体の2/3にあたる63文字しか使っ ていない ◦ このことがあとのShift_JISの制定につながる ヰとヱは除く
91. © 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 制御コードをエンコードに使うということは、その制御コード自体を表現することができな い (または、難しくなる) ことを意味する。 実用的には、これが問題になることはそれほど多くないはず。
92. © 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との対応関係 のためにアルファベット順を変更している点が興味深い
93. © 2024 Wantedly, Inc. 自己同期符号 Shift In / Shift Out の問題点 • モードの情報がないと、文字が区別できない ◦ たとえば、「TRY」と「ヤメル」は同じバイト列になってしまう • 単純にバイト列検索するとおかしなことになる • 文字列処理が大変 ◦ strcatなどで単純連結するとおかしくなるかも → 自己同期符号という性質を満たすのが望ましい
94. © 2024 Wantedly, Inc. 8bitコード
95. © 2024 Wantedly, Inc. 8bitコード • 8bitになることで、2つの文字集合を切り替えずに同時に使え るようになる ◦ 自己同期符号の条件を満たすことが (場合によっては) 可能 • 7bit用に定義したものをGRにマップして使うだけ! ◦ ISO/IEC 2022のおかげ ◦ JIS X 0201 はそのまま8bitコードとしても使える (ANKコード) ◦ КОИ-7 は文字を整理して КОИ-8 になった
96. © 2024 Wantedly, Inc. ANKコード • ANKコード: JIS X 0201の8bitコードのこと x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 。 「 」 、 ・ ヲ ァ ィ ゥ ェ ォ ャ ュ ョ ッ Bx ー ア イ ウ エ オ カ キ ク ケ コ サ シ ス セ ソ Cx タ チ ツ テ ト ナ ニ ヌ ネ ノ ハ ヒ フ ヘ ホ マ Dx ミ ム メ モ ヤ ユ ヨ ラ リ ル レ ロ ワ ン ゛ ゜ Ex Fx
97. © 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
98. © 2024 Wantedly, Inc. C1制御コード • NEL: 改行 ◦ CR, LF, CR+LF のいずれとも違う新種の改行。EBCDIC由来らしい • SS2, SS3: 単一シフト ◦ EUC-JP などで利用 • CSI, DCS, OSC: エスケープシーケンスとして利用 ◦ 仮想端末で今でもお世話になる文字 他はあまり使わない
99. © 2024 Wantedly, Inc. ISO/IEC 8859 ISO/IEC 8859 (ECMA-94) (1987〜) • 複数国の需要に対応できる8ビット向け図形文字集合 • 1〜16の異なるパートからなる ◦ それぞれは異なる図形文字集合 • Part 1 である ISO/IEC 8859-1 は広く普及した ◦ Part 1 は西欧を中心にカバーした文字集合
100. © 2024 Wantedly, Inc. ISO/IEC 8859 À È ß Ą Ł Đ À Ş Ż Å Õ Ļ Э Ю Я ج ب ا Φ Ψ Ω ג ב א İ Ö Ğ ก ซ ฏ Å Ä Ø Ą Ł Š Á Ḃ Ŷ È Œ ß Ç Ž Ő 1: 西欧 2: 中欧 3: 南欧 4: 北欧 5: キリル文字 6: アラビア文字 7: ギリシャ文字 8: ヘブライ文字 9: トルコ 10: ノルド系 11: タイ文字 12: 破棄 13: バルト沿岸 14: ケルト 15: 西欧(再編) 16: 南東欧
101. © 2024 Wantedly, Inc. ISO/IEC 8859 À È ß Ą Ł Đ À Ş Ż Å Õ Ļ İ Ö Ğ Å Ä Ø Ą Ł Š Á Ḃ Ŷ È Œ ß Ç Ž Ő Latin-1 Latin-2 Latin-3 Latin-4 Latin-5 Latin-6 Latin-7 Latin-8 Latin-9 Latin-10
102. © 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 ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
103. © 2024 Wantedly, Inc. ISO/IEC 8859-1 • NBSP, SHY ◦ NBSPはスペースだが、折り返し禁止。数値の区切りなどで使われる。 ◦ SHYは折り返し可能な位置を表すが、折り返したときはハイフンになる。 ◦ これらはフォーマットを制御する文字だが、制御コードではなく図形文字として扱われる。 • ¦, ¯, ¥ ◦ ¦, ¯ はそれぞれ | と ~ の異書体 (allograph) だったもの。 ◦ ¥ はJIS X 0201では5Cに収録されていたが、ISO/IEC 8859-1ではA5に収録されてい る
104. © 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 ๐ ๑ ๒ ๓ ๔ ๕ ๖ ๗ ๘ ๙ ๚ ๛
105. © 2024 Wantedly, Inc. ISO/IEC 8859-11 母音記号 (一部) ก กา โก กิ กู ko koh ki kaa kuu ก ก タイ文字はアブギダという種類の文字体系で、 子音字に母音記号をつけて表記する。 母音記号がない場合はデフォルトの母音が使われる。
106. © 2024 Wantedly, Inc. ISO/IEC 8859-11 母音記号 (一部) ก กา โก กิ กู ko koh ki kaa kuu ก ก 母音記号を前置 (非合成) 合成文字 (後置) 母音記号を後置 (非合成)
107. © 2024 Wantedly, Inc. ISO 5426 ISO 5426 • 書誌情報向けの文字エンコーディング • 合成文字 + ベース文字 ◦ 合成文字が先行する
108. © 2024 Wantedly, Inc. マルチバイト文字
109. © 2024 Wantedly, Inc. 時代背景 (参考) • 1969 UNIX開発開始 • 1971 IBM漢字システム • 1976 UNIXが東大に導入された • 1978 JIS X 0208 • 1979 東芝JW-10 • 1986 UNIX JAE (日本語応用環境)
110. © 2024 Wantedly, Inc. マルチバイト文字 • 音素文字以外では、しばしば94文字では不足 ◦ 漢字もそうだし、ハングルも音節単位で数えると全然足りない • 94文字で足りないなら、94×94文字にすればいい ◦ 94×94 = 8836
111. © 2024 Wantedly, Inc. 面・区・点 文字を3階層に分けて分類 • 面 (plane) は最大8836文字からなる集合 • 区 (row) は最大94文字からなる集合 • 点 (cell) はそのうちの1文字 同じ面の文字は切り替えずに利用可能
112. © 2024 Wantedly, Inc. JIS X 0208 JIS X 0208 (JIS C 6226): 漢字コードの第1面を規定 • 漢字と仮名のほか、日本語でよく使われる約物や記号も収録 • ラテン文字・ギリシャ文字・キリル文字も収録 最初の出版は1978年 これが最初の漢字コードというわけではなく、たとえば IBM 漢字システムは1971年に発表されている
113. © 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)
114. © 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規格の本文には 定義されていない。 ただし、現在は附属書に定義がある。
115. © 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コードの上位互換)
116. © 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互換コードの上位互換 )
117. © 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互換コードの上位互換 )
118. © 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に呼び出せる ◦ 指示・呼び出しについて詳しくは後述
119. © 2024 Wantedly, Inc. EUC-JP EUC-JP • EUCの日本版との位置づけ • UJIS, 日本語EUC, EUC-JIS などとも呼ばれ、おおむね同じ ものを指す ◦ 厳密にはバージョンの違いなどを加味する必要がある
120. © 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制御コードは普通に使える (エンコーディングに使うもの自身を除く)
121. © 2024 Wantedly, Inc. EUC-JP系エンコーディング EUC系コードの特徴 • 自己同期符号ではない ◦ 「青写真」 (C0 C4 BC CC BF BF) には「勅命」 (C4 BC CC BF) が含まれる • ただし状態はないので扱いやすい • ASCII安全性はある ◦ より広く、0x00〜0x9Fまでのバイトのうち0x8Eと0x8F以外は必ず単独でしか出現しな い
122. © 2024 Wantedly, Inc. EUC-JP系エンコーディング EUC-JP系コードの特徴 • 漢字は2バイト (だった) ◦ あとから追加された第2面は3バイト • いわゆる半角カナも2バイト ◦ SS2を前置するため • ANKコード (JIS X 0201) とは非互換 ◦ いわゆる半角カナにSS2を前置する必要があるため
123. © 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と併用する場合、同じ文字が収録された漢字コー ドの領域の利用を禁止している これについて次で説明
124. © 2024 Wantedly, Inc. 半角/全角
125. © 2024 Wantedly, Inc. 半角/全角 半角/全角 • もとは和文組版の用語 • 文字をレイアウトするときの幅 • 本来、文字コードとは無関係
126. © 2024 Wantedly, Inc. 文字の幅 • 欧文組版: 字幅は連続的で、フォントによって決まる • 欧文タイプライター: 字幅は固定 ◦ 文字は縦長 ◦ 同様の仕様がテレタイプや仮想端末でも採用された • 和文組版: 基本的に字幅は固定 ◦ 基本は正方形で、この幅を全角という ◦ 組版規則に基づき、半角 (二分; 1/2) や 四分 (1/4) を組み合わせて使う 全てのタイプライターが固定幅 というわけではない。 また、固定幅は単に技術的な制約があ るときだけではなく、位置揃えが有益で ある場合にも使われる。 ただし、em と en の2つが 文字幅の基準としてよく使われる
127. © 2024 Wantedly, Inc. 文字の幅 Mint Mint ミント ミ ン ト
128. © 2024 Wantedly, Inc. 文字幅とJIS X 0201 • JIS X 0201 の片仮名は、慣習的に英数と同じ幅で印字される ことが多かった ◦ おそらく、幅を切り替える技術的な困難によるもの (JIS X 0201は1969年) ◦ また、JIS X 0201 は JIS X 0208 とは異なり1byteコードであるため、ソフトウェアの大規 模な改造をしなくても文字のイメージデータ (キャラクタROM) の差し替えで動かせたの かもしれない Mintﾐﾝﾄ Mintミ ン ト
129. © 2024 Wantedly, Inc. 文字幅とJIS X 0208 • 片仮名を英数幅で表示していたところに、JIS X 0208が登場 ◦ 以降の図ではJIS X 0213をもとに説明 • 漢字は英数2文字分で表示したい ◦ つまり、欧文タイプライターにおける 1文字幅を和文組版における半角とみなす ◦ 片仮名は和文組版に従うため、漢字にあわせて全角表示されるのが自然ということにな る
130. © 2024 Wantedly, Inc. 重複収録 漢字1面にはJIS X 0201との重複収録がある 漢字2面 漢字1面 ASCII JIS X 0201 片仮名 " A ア あ 漢 丂
131. © 2024 Wantedly, Inc. 重複収録 漢字1面にはJIS X 0201との重複収録がある 漢字2面 漢字1面 ASCII JIS X 0201 片仮名 " A ア あ 漢 丂
132. © 2024 Wantedly, Inc. 重複収録 JISの意図: 重複箇所は片方に寄せる 漢字2面 漢字1面 ASCII " A ア あ 漢 丂
133. © 2024 Wantedly, Inc. 重複収録 実際の運用: 重複部分を別の文字として扱う 漢字2面 漢字1面 ASCII JIS X 0201 片仮名 " A ｱ あ 漢 丂 Ａ ア
134. © 2024 Wantedly, Inc. 重複収録 実際の運用: 収録先に基づいて文字幅を決定 漢字2面 漢字1面 ASCII JIS X 0201 片仮名 " A ｱ あ 漢 丂 Ａ ア 半角 全角
135. © 2024 Wantedly, Inc. 重複収録と文字幅 • ASCII / JIS X 0201 の文字は半角で表示 ◦ つまり、JIS X 0201の片仮名は本来よりも細く表示される ◦ → 半角カナ (片仮名のバリアント) • JIS X 0208 の文字は全角で表示 ◦ つまり、JIS X 0208の英数字は本来よりも太く表示される ◦ → 全角英数 (英数のバリアント)
136. © 2024 Wantedly, Inc. JIS漢字水準と予約領域
137. © 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 陝 顱 髻 鵝 堯 非漢字についてはわかりやすさのため恣意的に代表文字を選定した。
138. © 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 陝 顱 髻 鵝 堯
139. © 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 陝 顱 髻 鵝 堯 読みの五十音順
140. © 2024 Wantedly, Inc. JIS X 0208 区割り 第2水準 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 「 ◆ A あ ア Ω Я ┨ Bx 亜 院 押 魁 粥 機 供 掘 検 后 此 察 次 宗 勝 拭 Cx 澄 繊 臓 叩 帖 邸 董 如 函 鼻 福 法 漫 諭 痢 蓮 Dx 弌 僉 辧 咫 圈 奸 屐 廖 悄 戞 據 曄 棔 檗 沺 漾 Ex 燹 瓠 癲 磧 筺 紂 罅 隋 茵 蕁 蝓 襦 譟 蹇 遏 錙 Fx 陝 顱 髻 鵝 堯 部首順
141. © 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 陝 顱 髻 鵝 堯 文字が書かれているのに色が塗られている部分は、同じ区の中で部分的に 空き領域がある。
142. © 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 陝 顱 髻 鵝 堯 擄 㯃 滇 琇 硃 絁 菑 訢 釥 顗
143. © 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 陝 顱 髻 鵝 堯 擄 㯃 滇 琇 硃 絁 菑 訢 釥 顗
144. © 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 陝 顱 髻 鵝 堯 擄 㯃 滇 琇 硃 絁 菑 訢 釥 顗
145. © 2024 Wantedly, Inc. JIS X 0213 漢字第2面 区割り JIS X 0213 漢字第2面の区割り (1byte目) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 𠂉 儈 唼 堠 宖 幮 抙 晛 棙 Bx Cx Dx Ex 殛 溓 Fx 熳 璠 𥆩 稸 糍 翲 芲 𦿶 蠮 豗 𨗉 𨨩 靪 騱 鳦
146. © 2024 Wantedly, Inc. JIS X 0213 漢字第2面 区割り 全体が第4水準 x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 𠂉 儈 唼 堠 宖 幮 抙 晛 棙 Bx Cx Dx Ex 殛 溓 Fx 熳 璠 𥆩 稸 糍 翲 芲 𦿶 蠮 豗 𨗉 𨨩 靪 騱 鳦
147. © 2024 Wantedly, Inc. 制御シーケンス
148. © 2024 Wantedly, Inc. 制御シーケンスと文字コード ISO/IEC 2022で制御シーケンスを利用するので、ここで説明す る
149. © 2024 Wantedly, Inc. 制御シーケンス 制御シーケンス: 制御コードを含む複数の文字からなる指令 • よく使うものは以下の2箇所で規定 ◦ ISO/IEC 2022 ◦ ISO/IEC 6429 • 制御コードと同じく、複数の用途がある ◦ エンコーディングの制御 (ISO/IEC 2022で利用) ◦ 印字の制御 (仮想端末で利用)
150. © 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
151. © 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 { | } ~
152. © 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 で利用
153. © 2024 Wantedly, Inc. 仮想端末向けシーケンス 参考として、仮想端末でよく使われる制御シーケンスについて軽く 説明
154. © 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 … カーソルを右上に移動
155. © 2024 Wantedly, Inc. 仮想端末向けシーケンス - APC / DCS / OSC / PM / SOS • APC / DCS / OSC / PM / SOS の5つのC1制御コード ◦ OSCは ESC ] とも書ける • OSC → テキスト → ST の順で入力 ◦ ST もC1制御コードの一種 ◦ OSC以外についても同様
156. © 2024 Wantedly, Inc. ISO/IEC 2022
157. © 2024 Wantedly, Inc. 時代背景 (参考) • 1969 ARPANET, RFC ◦ RFC 20もこの年 • 1971 ECMA-35 (ISO/IEC 2022) • 1980 RFC 772 (メールプロトコル) • 1984 JUNET ◦ 日本のインターネットの起源とされる • 1993 RFC 1468 (ISO-2022-JP)
158. © 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にマッピングして利用する唯 一の方式だったためにそう呼ばれたのかも ……。
159. © 2024 Wantedly, Inc. ISO/IEC 2022 • ISO/IEC 2022 は7bit/8bit文字コードの基本構造を定める • それに加えて、これらの文字コードが相互運用できるよう、追 加の機能も提供している
160. © 2024 Wantedly, Inc. 2段呼び出し 2段呼び出し GL GR G0 G1 G2 G3 コード表 符号要素 (バッファ) ISO-IR 呼び出し (invoke) 指示 (designate)
161. © 2024 Wantedly, Inc. 呼び出し vs. 指示 • 呼び出し (invoke) はローカルな切り替え ◦ SI/SOなどのシフト命令がどのような文字集合を呼び出すかは、コンテキストに依存して 変化してしまう • 指示 (designate) はグローバル一意な切り替え ◦ 文字集合の指示では ISO-IR が管理する一意な名前を指定する ◦ コンテキストによらず一意に解釈できる
162. © 2024 Wantedly, Inc. アナウンス • コード自身の挙動を変える様々なメタ指定ができる ◦ 例は後述 • これらがあることで、後続のエスケープの意味を一意に指定で きる
163. © 2024 Wantedly, Inc. EUC-JP in ISO/IEC 2022 • EUC-JPはISO/IEC 2022のサブセットではない • しかし、「特定の初期状態」を指定したISO/IEC 2022の亜種 であるとはみなせる ◦ このような亜種をISO/IEC 2022用語で「バージョン」という
164. © 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面がない古いバージョンと して例示している
165. © 2024 Wantedly, Inc. ISO-2022-JP ISO-2022-JP • ステートレスな7bitコード • 厳密にはISO/IEC 2022のサブセットではない (!) ◦ EUC-JPと同じく、これはISO/IEC 2022の亜種 (バージョン) である • とはいえ、サブセットに近いとも言える ◦ 仮定されているアナウンス・指示シーケンスは比較的短い
166. © 2024 Wantedly, Inc. ISO-2022-JP in ISO/IEC 2022 • ISO-2022-* を指示するシーケンス ◦ つまり、 ISO-2022-* 文字列に以下を前置すると ISO/IEC 2022 文字列になる シーケンス 効果 ESC SP A G0への指示をもって、 GLへの呼び出しとする ESC ( B G0にASCIIを指示
167. © 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
168. © 2024 Wantedly, Inc. ISO-2022-JP • 修正前のJUNETコード 切り替え方法 備考 ASCII ESC ( B JIS X 0201 ラテン文字 ESC ( H JIS C 6226:1975で誤って記載 実際にはISO/IEC 646-SW2 に割り当て JIS C 6226:1975 漢字第1面 ESC $ @ ※JIS C 6226 = JIS X 0208
169. © 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 で指示できるため、非公式に対応しているケースもある
170. © 2024 Wantedly, Inc. その他のエンコーディング
171. © 2024 Wantedly, Inc. ISO/IEC 2022 以外 • ISO/IEC 2022は7bit/8bitコードの構造に大きな影響力を与 えていた • とはいえ、この構造に従っていない文字エンコーディングも沢 山ある ◦ Unicodeがまさにそうなのだが、それについてはもう少し後で説明
172. © 2024 Wantedly, Inc. Windows-1252, VISCII
173. © 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 ‘ ’ “ ” • – — ˜ ™ š › œ ž Ÿ
174. © 2024 Wantedly, Inc. Windows-1252 • Windows-1252との互換性のためのHTML Living Standardの特別ルールがある • &#x8E; → Ž ◦ 本来であればC1制御コードのSS2を指すはずだが、Windows-1252で読み替えている ◦ 正しくは &#x17D;
175. © 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
176. © 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 đ ự ò ó ô õ ỏ ọ ụ ù ú ũ ủ ý ợ Ữ
177. © 2024 Wantedly, Inc. VISCII • 母音字 ◦ A, Ă, Â, E, Ê, I, O, Ô, Ơ, U, Ư, Y の12文字 ◦ それぞれに声調記号 ´, `, ̉, ~, . の5種類がつく ◦ 全ての組み合わせを収録するには (12 × 6 - 6) ×2 = 132 文字必要 • 子音字 ◦ 追加で Đ を利用するため、大文字小文字あわせて 2 文字必要 • C1 + GR で 128 文字 → 6文字入らない ◦ → C0 領域も使わないと入らない ◦ かといって、2バイトにするほどでもない
178. © 2024 Wantedly, Inc. Dingbat用フォント
179. © 2024 Wantedly, Inc. Dingbat系フォント 既存の文字に、本来と異なる図形を割り当てるフォント • 特に、装飾用で使われた ❁ a ✺ Z
180. © 2024 Wantedly, Inc. Dingbat系フォント • フォント選択が意味を 決定してしまっている 0x61 「英小文字のA」 という抽象的な概念 a という図形 「エー」と読み上げ ✔ という図形 Arialフォント 読み上げソフト Webdingsフォント ASCII
181. © 2024 Wantedly, Inc. Dingbat系フォント • フォント選択が意味を決定してしまっている • フォントが暗黙的に新しい文字エンコーディングを定義してい る、ともいえる 現在、これらのDingbat系フォントによって表されていた文字の多くは Unicodeに収録されている。 これらの文字を使えば、フォント設定に依存せずに適切に情報交換を行える。 ツールによっては、これらの Dingbat系のフォント設定を特別扱いし、挙動を変えているものもあるようだ。 たとえば、Microsoft WordではWebdingsが設定された区画のコピー &ペーストや検索の挙動を変えている。
182. © 2024 Wantedly, Inc. Shift_JIS
183. © 2024 Wantedly, Inc. 時代背景 (参考) • 1977 Apple II • 1978 Intel 8086 (16bit) • 1981 PC DOS (MS-DOS) および CP/M-86 • 1982 NEC PC-9801 • 1985 Intel 80386 (32bit), Windows 1.0, 漢字Talk
184. © 2024 Wantedly, Inc. 時代背景 (参考) • 1992 Windows 3.1 • 1993 Windows 3.1 日本語版 • 1995 Windows 95 • 1998 Mac OS 8.5 • 1999 NTTドコモ iモードサービス
185. © 2024 Wantedly, Inc. Shift_JIS Shift_JIS (SJIS) • DOS系の環境で広く使われた文字エンコーディング • ANKコードとの互換性を維持しつつ、JIS X 0208 のための領 域を確保 • ISO/IEC 2022の構造には沿っていない
186. © 2024 Wantedly, Inc. Shift_JIS • C0, JIS X 0201 の領域は そのまま残す 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR 片仮名文字集合 (63文字しかない) の余り分 Dx Ex
187. © 2024 Wantedly, Inc. Shift_JIS • C1 + 片仮名用で使わなかった 領域から 47文字分を確保 • 47 = 94 ÷ 2 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR Dx Ex
188. © 2024 Wantedly, Inc. Shift_JIS • 2バイト目は以下を避ける ◦ C0制御文字とDEL ◦ GL (ASCII) の下位部分 • 残りから188文字分を確保 • 188 = 94 × 2 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR Dx Ex
189. © 2024 Wantedly, Inc. Shift_JIS • 94 × 94 = 47 (1byte目) × 188 (2byte目) • これによりJIS X 0208の漢字第1面を配置可能になった
190. © 2024 Wantedly, Inc. Shift_JIS Shift_JISの特徴 • JIS X 0201 は常に1バイト、JIS X 0208 は常に2バイト ◦ 半角 = 1バイト、全角 = 2バイト という言説はこれに由来 • ステートレス • ASCII-safe ではない ◦ 当然、自己同期的でもない
191. © 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
192. © 2024 Wantedly, Inc. Shift_JIS 2バイト目問題 例: 1バイト目が 0x83 のとき x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 2x 3x 4x ァ ア ィ イ ゥ ウ ェ エ ォ オ カ ガ キ ギ ク グ 5x ケ ゲ コ ゴ サ ザ シ ジ ス ズ セ ゼ ソ ゾ タ ダ 6x チ ヂ ッ ツ ヅ テ デ ト ド ナ ニ ヌ ネ ノ ハ バ 7x パ ヒ ビ ピ フ ブ プ ヘ ベ ペ ホ ボ ポ マ ミ
193. © 2024 Wantedly, Inc. 5C問題 • 5C (\, ¥) は特別扱いされがち ◦ プログラミング言語 ◦ データフォーマット • 5Cが含まれる文字が問題を起こしうる (ダメ文字) ◦ ―ソЫ噂浬欺圭構蚕十申曾箪貼能表暴予禄 etc. • 2F (/) も特別扱いされる ◦ ファイルパスなどで問題になりうる ◦ Shift_JISでは重複しないが、Big5やGBKでは問題になりうる
194. © 2024 Wantedly, Inc. 5C問題 \x95 " \ \x8E \xA6 " " 表 示 " \x22 \x22 \x5C \x95 \x8E \xA6 侮 ｦ Shift_JIS ソーステキスト ソーステキスト バイト列 文字列リテラル バイト列 表示されるShift_JISテキスト
195. © 2024 Wantedly, Inc. ベンダー拡張
196. © 2024 Wantedly, Inc. Shift_JISの追加領域 • 再掲: Shift_JISの1byte目 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR Dx Ex
197. © 2024 Wantedly, Inc. Shift_JISの追加領域 • まだ(少しだけ)余ってる領域が ある • このうち13個を使う 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR Dx Ex
198. © 2024 Wantedly, Inc. Shift_JISの追加領域 • 活用方法1: 区の拡張 • 47領域 → 60領域に拡張 • 95区〜120区が使えるようにな る ◦ ISO/IEC 2022 や JIS X 0208 には本来 ない概念 • ベンダー拡張で利用 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR Dx Ex
199. © 2024 Wantedly, Inc. Shift_JISの追加領域 • 活用方法2: 面の拡張 • 2面の区のうち26個を並べ替え て13領域に押し込める • JIS X 0213の附属書1 0x Fx x0 xF 1x 2x 7x 8x 9x Ax CL GL CR GR Dx Ex
200. © 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では使われていない。
201. © 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 陝 顱 髻 鵝 堯
202. © 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
203. © 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では空き領域の一部を自由領域と規定していたらしい。
204. © 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) との互換用
205. © 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特殊文字
206. © 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拡張文字 重 複 破棄
207. © 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 𥆩 稸 糍 翲 芲 𦿶 蠮 豗 𨗉 𨨩 靪 騱 鳦
208. © 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
209. © 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
210. © 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拡張としては以下の符号位置にマップされている。
211. © 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
212. © 2024 Wantedly, Inc. Softbank 絵文字 ISO/IEC 2022風シーケンスの問題 • そもそもエスケープシーケンスがおかしい ◦ ESC $ の次には指示先を指定する文字が来ないといけない ▪ ESC $ @, ESC $ A, ESC $ B のみ例外として認められている ◦ ESC $ は指示を行うコードなのに、復帰時は SO で呼び出しのみを行っている • 文字集合の問題 ◦ ESC $ は多バイト文字集合用だが、この絵文字シーケンスは 1バイトしか使っていない ◦ ESC $ を ESC $ ( と解釈すると、ISO-IRに登録済みの文字集合と重複してしまう ▪ これらの誤解釈を避けるために、あえて誤ったシーケンスを実装したのかも
213. © 2024 Wantedly, Inc. 文字集合のバージョン
214. © 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
215. © 2024 Wantedly, Inc. 非互換な変更 非互換な変更 壺 壷 36-59 52-68 壷 壺 36-59 52-68 啞 16-2 唖 16-2 辻 36-52 ᷎ 36-52 78JIS 83JIS
216. © 2024 Wantedly, Inc. 非互換な変更 非互換な変更 壺 壷 36-59 52-68 壷 壺 36-59 52-68 啞 16-2 唖 16-2 辻 36-52 ᷎ 36-52 78JIS 83JIS 別の字体への変更 (異体字) 別の字形への変更
217. © 2024 Wantedly, Inc. 非互換な変更の影響 • 全く別の漢字への変更 …… はさすがに発生していない • 字体の変更 ◦ 意味は変わらないとはいっても、ユーザーの期待には反する • 字形の変更 ◦ 本来、実装が規格の例示字形に従う必要はない ◦ 現実のフォントは例示字形に追従する形で実装され、ユーザーもそのように期待していた
218. © 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 ✓
219. © 2024 Wantedly, Inc. 非互換性への対応 EUC-JP系コード: バージョンの合意が必要 • 一般的には最新バージョンとして解釈されると思われる ◦ JIS X 0213:2000ベースのエンコーディングは EUC-JISX0213 と呼ばれる ◦ JIS X 0213:2004ベースのエンコーディングは EUC-JIS-2004 と呼ばれる • eucJP-ms系のコードとして解釈する場合もある
220. © 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 と呼ばれる
221. © 2024 Wantedly, Inc. JIS X 0212
222. © 2024 Wantedly, Inc. JIS X 0212 JIS X 0212 • 「JIS補助漢字」とも呼ばれる • 2面に漢字を大量に収録したが、あまり普及しなかった ◦ また、収録基準に関して問題点も指摘されている • JIS X 0213は、JIS X 0212の「やり直し」とも言える ◦ JIS X 0212の漢字の一部はJIS X 0213にも収録されている
223. © 2024 Wantedly, Inc. JIS X 0212 JIS X 0212 (1byte目) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax № Ώ Ђ Æ Á á Bx 丂 侅 傒 凈 匌 咁 嗓 囶 堌 奯 嫄 屭 巩 彯 悻 懬 Cx 捸 擄 昞 杦 棐 樴 歾 泚 湢 濚 煨 狾 珿 甒 瘺 睤 Dx 碻 秠 笱 籡 綞 罱 胰 艋 荽 蓜 藿 蜨 蠺 襻 誶 貇 Ex 踣 轃 郄 釂 銙 鍺 镾 霃 頫 馹 鬄 鯹 鵼 黸 Fx
224. © 2024 Wantedly, Inc. JIS X 0213 漢字第2面 区割り JIS X 0213 漢字第2面の区割り (1byte目) x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Ax 𠂉 儈 唼 堠 宖 幮 抙 晛 棙 Bx Cx Dx Ex 殛 溓 Fx 熳 璠 𥆩 稸 糍 翲 芲 𦿶 蠮 豗 𨗉 𨨩 靪 騱 鳦
225. © 2024 Wantedly, Inc. JIS X 0212 JIS X 0212が使えるエンコーディング • 󰢏 ISO-2022-JP方式 ◦ ESC $ ( D で指示可能 (ISO-2022-JP-1 など) • 󰢏 EUC-JP方式 ◦ 漢字第2面に曖昧性なく割り当てられる ◦ ただし、JIS X 0213との重複収録があり、同時使用は想定されていない • ❌ Shift_JIS
226. © 2024 Wantedly, Inc. その他の非ISO/IEC 2022系文字エンコーディング
227. © 2024 Wantedly, Inc. その他 • TRONコード • Big5 • GBK 3〜5 • Extended Hangul codes in UHC Unicodeについてはあとでまとめて紹介
228. © 2024 Wantedly, Inc. 大規模文字セット
229. © 2024 Wantedly, Inc. 大規模文字セット • 包摂 = 2つの字形を同じ文字に分類すること • JIS X 0213は日常使用に適した包摂基準で作られている • さらに細かく文字を分類する需要がある ◦ 人名・地名や出版など 壺 壷 JIS: 異なる字体 (異体字) 雪 雪 JIS: 同じ字体・異なる字形 (「ヨ」の真ん中の線の長さに注目 )
230. © 2024 Wantedly, Inc. 大規模文字セット • Adobe-Japan1 ◦ DTP向けの文字セット • 戸籍統一文字・住基ネット統一文字・登記統一文字 ◦ それぞれ戸籍・住民票・登記情報のための文字セット • MJ文字 ◦ 行政用の文字セットで、戸籍統一文字と住基ネット統一文字を含む • GlyphWiki ◦ 字形の蒐集を行っている個人運営のコミュニティーサイト
231. © 2024 Wantedly, Inc. 第2部のまとめ
232. © 2024 Wantedly, Inc. 第2部まとめ • ASCII登場以後、ASCII互換の各国コードが出現 • 日本では以下の3つがとりわけ流通した ◦ ISO-2022-JP系コード: Web/Internet ◦ Shift_JIS系コード: DOS/Windows ◦ EUC-JP系コード: UNIX/Linux • ISO/IEC 2022の構造に従うものが多かった一方、独自の構 造を持つものやベンダ拡張も多数あった
233. © 2024 Wantedly, Inc. 第3部 Unicode
234. © 2024 Wantedly, Inc. 　汝のあるべき姿に戻れ — 木之本桜 (CLAMP『カードキャプターさくら』)
235. © 2024 Wantedly, Inc. 文字ってなんだ?
236. © 2024 Wantedly, Inc. 同じ文字はどれ？ (包摂基準) 同じ文字はどれ？
237. © 2024 Wantedly, Inc. 同じ文字はどれ？ (包摂基準) 異なる形、同じ意味 「命令」の「令」 算用数字の4 ひらがなの「そ」 ラテン文字のA
238. © 2024 Wantedly, Inc. 同じ文字はどれ？ (包摂基準) 同じ形、異なる意味 • ウムラウト化したE • トレマ化したE • キリル文字のヨー • ラテン文字のエックス • ギリシャ文字のキー • キリル文字のハー • ローマ数字の10
239. © 2024 Wantedly, Inc. 同じ文字はどれ？ (包摂基準) コンテキスト依存 (1) どちらも割り算に使うが、 完全に互換ではない 同じ「K」だが、 ペルシャ語では左、 アラビア語では右を使う
240. © 2024 Wantedly, Inc. 同じ文字はどれ？ (包摂基準) コンテキスト依存 (2) 日本語では左2つを使う。 中国語(簡体字)では右を使う。 左2つは同じ意味。 右2つは異なる意味。 ラテン文字としては同じ Mだが、 ギリシャ文字やキリル文字では異なる
241. © 2024 Wantedly, Inc. どれが文字？ どれが文字？ 囲み文字 上付き文字 色付き文字 書体指定 合字 合字(数字) 記号 象形文字 ロゴ 会意文字 組み文字 組み文字 (バスマラ)
242. © 2024 Wantedly, Inc. 文字とUnicode • Unicodeは文字コードを統一するべく生まれてきました • しかし、Unicodeが十分に実用的なコードにならなければ、 混乱をより深める結果になってしまいます。 • そこで、Unicodeは「文字」そのもののありかたについて、過 去の反省を踏まえた体系化が行われています。 • 本発表はこれに注意して聞いてみてください。
243. © 2024 Wantedly, Inc. コードポイント
244. © 2024 Wantedly, Inc. 復習: 文字集合と符号化方式 せっかく定義した文字集合を使い回したい → 文字集合と符号化方式の分離 (符号化)文字集合 (CCS) 文字に番号をつける 符号化方式 (CES) 番号をバイト列に対応づける とはいっても、任意の文字集合を任意の方式で符号化できるわけではない。 たとえばJIS X 0208をUTF-8で符号化することはできない。 あくまで緩くモジュラー化するための枠組みだと考えるのがベスト。 文字エンコーディング (character encoding) このような区別は後から生じたものであるため、文字エンコーディングのことを charsetと呼ぶこともある。
245. © 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
246. © 2024 Wantedly, Inc. サロゲート サロゲート: UTF-16専用のダミーコード • surrogateは代用の意味 • 上位サロゲートと下位サロゲートがそれぞれ1024個 ◦ 上位サロゲート: U+D800 ～ U+DBFF ◦ 下位サロゲート: U+DC00 ～ U+DFFF [Unicode] §3.8
247. © 2024 Wantedly, Inc. サロゲートとUSV • サロゲートは、 文字の基本単位として扱わないほうが都合がよい • サロゲート以外のコードポイントを USV と呼ぶ ◦ USV = コードポイント - サロゲート ◦ Unicode Scalar Value の略 • U+0000 ～ U+D7FF + U+E000 ～ U+10FFFF ◦ 合計 1112064 個ある [Unicode] §3.9
248. © 2024 Wantedly, Inc. 割り当て状況 約14%が割り当て済み[UCD]
249. © 2024 Wantedly, Inc. 割り当て状況 0面 (BMP) はほぼ満席 0: 基本多言語面 (BMP) 1: 追加多言語面 (SMP) 2: 追加漢字面 (SIP) 3: 第三漢字面 (TIP) 14: 追加特殊用途面 (SSP) 15/16: 私用面 (Private Use) [UCD]
250. © 2024 Wantedly, Inc. 割り当て状況 割り当ての歴史 [UCD], [UCD1.0.0]
251. © 2024 Wantedly, Inc. 割り当て状況 割り当ての歴史 (〜2.0 までを拡大) 現在のUnicodeは互換性を保証しているが、 初期のUnicodeには重大な破壊的変更が 多数入っていた。 Unicode 1.0.1 で私用領域の位置が ずらされると同時に大きくなっている。 Unicode 1.1 では削除された文字が 多くあったため、文字数がむしろ 減ってしまっている。 [UCD], [UCD1.0.0]
252. © 2024 Wantedly, Inc. 私用面と予約 • 初期の JIS X 0208 では、未定義領域にベンダ拡張が詰め 込まれ、混乱のもととなった。 ◦ 規格自体はその後修正されたが、ベンダ拡張の影響は残り続けている • Unicodeでは、予約領域と私用領域が区別されている。 ◦ 予約領域 (Reserved): 将来Unicode Consortiumが使う (勝手に使えない) ◦ 私用領域 (Private Use): 勝手に使ってよい (Unicode Consortiumは使わない) ◦ ベンダ拡張同士の衝突リスク自体はあるが、 私用領域が大きいので回避はしやすい [Unicode] §2.14.2 [Unicode] §2.14.3
253. © 2024 Wantedly, Inc. コードポイント名と文字名 U+0061 LATIN SMALL LETTER A コードポイント の名前 “U+” + 16進数で表記する 文字の名前 未割り当てのコードポイントには、名前はない [Unicode] §A.1.1 [Unicode] §A.1.2
254. © 2024 Wantedly, Inc. UTF
255. © 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]
256. © 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
257. © 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符号化「形式」には バイトオーダーの問題はない (原則として)
258. © 2024 Wantedly, Inc. UTF-16 符号化形式 • 歴史的にはUTF-16が最初 (経緯は後述) ◦ UTF-16のことを単に「Unicode」と呼ぶことも • 1～2個の16bit整数でUSVを表現 • サロゲートペアの処理がポイント
259. © 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
260. © 2024 Wantedly, Inc. UTF-16* 符号化スキーム • 符号化スキーム = 符号化形式 + バイト順の処理 • UTF-16: バイト順を検出 (BOM) • UTF-16BE / UTF-16LE: バイト順を事前に合意 ◦ BOMは使わない 30 AC ギ 기 ? ? U+30AC U+AC30 [Unicode] §3.10 [Unicode] §3.10
261. © 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
262. © 2024 Wantedly, Inc. UTF-16 符号化スキーム UTF-16BE / UTF-16LE: バイト順を事前に合意 ギ 30 AC U+30AC ギ U+30AC 기 U+AC30 기 U+AC30 AC 30 UTF-16BE UTF-16LE BOMは無く、 U+FEFF / U+FFFE として認識される [Unicode] §3.10
263. © 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
264. © 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
265. © 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
266. © 2024 Wantedly, Inc. UnicodeとUCS
267. © 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]
268. © 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
269. © 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
270. © 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
271. © 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
272. © 2024 Wantedly, Inc. Unicode ⊆ UCS (1993) 1993年時点: Unicode ⊆ UCS UCS (31bit) Unicode (16bit) この部分への実際の割り当ては無い Unicode = UCS-2 で表現 (現在の UTF-16) UTF-1 or UCS-4 で表現
273. © 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)
274. © 2024 Wantedly, Inc. Unicode ⊆ UCS (1996) 1996年時点: Unicode は 21bit に UCS (31bit) Unicode (21bit) この部分への実際の割り当ては無い UCS-2 で表現 UTF-8 or UCS-4 で表現 BMP (16bit) UTF-8 or UTF-16 で表現
275. © 2024 Wantedly, Inc. Unicode = UCS (2003) 2003年: UCS が 21bit に Unicode = UCS この部分への実際の割り当ては 将来にわたって無い UCS-2 で表現 (2010年廃止) BMP (16bit) UTF-8 or UTF-16 or UTF-32 で表現
276. © 2024 Wantedly, Inc. UnicodeとUCS (現在) • 文字の割り当て範囲が一致し、現在は実質 Unicode = UCS • なお、補助規格 (UTR) 等は Unicode 側で持っている
277. © 2024 Wantedly, Inc. UCS-2
278. © 2024 Wantedly, Inc. UTF-16の制限 • UTF-16符号化形式にも不正な形式がある • 「孤立したサロゲート」は禁止 ◦ 上位サロゲートがあるのに、次のコードユニットが下位サロゲートではない ◦ 下位サロゲートがあるのに、前のコードユニットが上位サロゲートではない • 整形式 (well formed) / 不正形式 (ill formed) [Unicode] §3.9.2
279. © 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
280. © 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]
281. © 2024 Wantedly, Inc. UTFの特性
282. © 2024 Wantedly, Inc. 文字エンコーディングの特性 ここでは以下の特性を扱う • 一意復号 / 一意符号化 • モノイド準同型 • 瞬時復号 • 自己同期 • 単調性 こうした議論は符号理論と形式言語理論の両輪にまた がっており、なるべくこれらの理論に由来する用語を用 いている。 しかし、現実の文字エンコーディングについて議論する にあたって適切な語彙がないものもいくつかあったた め、そこには独自に用語を充てている。
283. © 2024 Wantedly, Inc. 一意復号 「一意復号」は、コードに2通りの解釈がないこと。 文字コードでは、当然成立するべき性質。 CE B1 CE B2 α β ?
284. © 2024 Wantedly, Inc. 一意符号化 「一意符号化」は、同じ意味の複数の符号がないこと。 文字コードによっては成立しない。 FE FF あ い 30 42 FF FE 42 30 30 44 44 30 UTF-16 符号化スキームが 複数の符号を持つ例
285. © 2024 Wantedly, Inc. 一意符号化 • UTF-8, 16, 32 符号化形式は一意符号化を満たす • UTF-16BE, 16LE, 32BE, 32LE 符号化スキームも一意符号化 を満たす • いっぽう、 UTF-8, 16, 32 符号化スキームは一意符号化を満 たさない ◦ BOMの有無やバイトオーダーなどについて選択肢があるため
286. © 2024 Wantedly, Inc. 一意符号化 • 以降の議論では、一意符号化を仮定する ◦ UTF-16符号化スキームなど一意符号化を持たない符号でも、一定の制限をおくことで一 意なものとして扱える。 ◦ 以下、この制限については必要に応じて補足する
287. © 2024 Wantedly, Inc. モノイド準同型 • 文字列連結と、コードユニットの連結が一致する性質 • ストリーム処理や構文解析で有用 FE FF 30 42 FE FF 30 44 + あ ZW NBSP あ い FE FF 30 42 FE FF 30 44 い
288. © 2024 Wantedly, Inc. モノイド準同型 • UTF-8, 16, 32 符号化形式は準同型 • BOMを使う符号化スキームは準同型 ◦ BOMが間に挟まって、ZWNBSP (Zero Width No-Break Space) になってしまう • WTF-8も準同型にならない ◦ 孤立サロゲート同士が結合されると、符号が変化してしまう
289. © 2024 Wantedly, Inc. 瞬時復号 • 瞬時復号: 先読みせずに文字を切り出せる性質 ◦ ハフマン符号の説明をするときによく出てくる • 文字コードでは通常満たされる • UCS-2は瞬時復号を満たさない(とも解釈できる) ◦ サロゲートペアを追加面のコードポイントとして解釈する場合 ◦ 上位サロゲートの役割を決定するのに、次の 16bitを読む必要がある
290. © 2024 Wantedly, Inc. 自己同期 • 自己同期: 途中からでも区切り位置がわかる性質 • 言い換え: コードユニットとして含まれるなら、 部分文字列としても含まれる • EUC-JP や Shift_JIS などは、この性質を満たさない C0 C4 BC CC BF BF C4 BC CC BF 青 真 写 勅 命
291. © 2024 Wantedly, Inc. 自己同期 - UTF-16 • UTF-16 符号化形式は自己同期する • ポイントは上下サロゲートの分離 ◦ 上位サロゲートと下位サロゲートが区別されている ◦ そのため、サロゲートペアの開始位置が明確 D800 DC00 D801 DC01 ここがサロゲートペアにはならない (下位→上位の順のため)
292. © 2024 Wantedly, Inc. 自己同期 - UTF-16 • UTF-16* 符号化スキームは自己同期しない • 偶数バイト目か奇数バイト目かが不明なため ◦ 符号化形式の場合はバイト列ではなく16bit整数の配列とみなしているため、この問題は 起きない
293. © 2024 Wantedly, Inc. 自己同期 - UTF-8 • UTF-8は自己同期する • ここで UTF-8 の設計をおさらい
294. © 2024 Wantedly, Inc. UTF-8 コードユニット • 256領域を指数的に分割 • 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 + 1 0x Fx x0 xF 7x 8x Bx Cx ASCII 後続バイト 3byte 開始 Dx Ex 2byte 開始 4byte 開始
295. © 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バイトコード
296. © 2024 Wantedly, Inc. UTF-8 • 1バイト形式は7bit • 以後、先頭バイトの情報量が減るかわりに、6bitの情報量が 追加される ◦ 初回のみ、先頭バイトの情報量が 2bit減る • 7bit → 11bit → 16bit → 21bit → 26bit → 31bit ◦ 5byte/6byte形式はUCSが31bitだった時代のもので、今は使われない
297. © 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)
298. © 2024 Wantedly, Inc. UTF-8 • 先頭バイトと後続バイトが分離されている → 文字の開始位置を確実に特定できる • 先頭バイトに長さ情報が入っている → 文字の開始位置がわかるので、終了位置もわかる • 以上より、瞬時復号・自己同期を満たす
299. © 2024 Wantedly, Inc. 自己同期だと何が嬉しいのか 自己同期の嬉しさ • 検索アルゴリズムの簡略化 ◦ KMPやAho-Corasickをバイト単位の処理として翻訳できる • 並列処理との相性 ◦ データがチャンクで区切られているとき、 境界が決まるまで処理を待つ必要がない
300. © 2024 Wantedly, Inc. 自己同期だと何が嬉しいのか 自己同期 + ASCII互換の嬉しさ • UTF-8の7bit断片は全て、 U+0000〜U+007F である • 逆に言えば、他の文字が ASCII に誤解されることがない • この性質は FSS (File System Safe) と呼ばれていた ◦ スラッシュを含まないため、ファイル名に使っても問題が起きにくい ◦ 同様にバックシュラッシュも含まない (5C問題が起きない)
301. © 2024 Wantedly, Inc. 単調性 • 単調性: 順序を保つこと • USVの数値順の辞書順で表現できていると嬉しい ◦ ただし、ユーザー向けでは Unicode Collation Algorithm を使うべき
302. © 2024 Wantedly, Inc. 単調性 • UTF-8 は単調性を持つ ◦ 必ず最小バイト数で表現するため、 USVに対してバイト長が単調 ◦ さらに、バイト長に対してバイト位置が単調 (第1バイトの選び方を思い出そう) ◦ 加えてビッグエンディアンなので、全体として辞書順を保つ • UTF-16 は単調性を持たない ◦ 追加面のコードポイントは U+Exxx, U+Fxxx より手前に来てしまう ◦ JavaScriptのsortのデフォルト比較アルゴリズムが該当
303. © 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の狙い通りか……?
304. © 2024 Wantedly, Inc. 収録基準・統合基準
305. © 2024 Wantedly, Inc. 文字の収録 • 空間が十分にあるからといって、 闇雲に文字を足していいわけではない • 「文字を取り込む」という行為自体が 設計のような作業にあたると言える
306. © 2024 Wantedly, Inc. 10の設計原理 Unicodeが定める「10の設計原理」 普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2
307. © 2024 Wantedly, Inc. 10の設計原理 Unicodeが定める「10の設計原理」 普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2
308. © 2024 Wantedly, Inc. 原則と例外 • 文字の収録・統合の原則は、以下の原理に基づく ◦ 普遍性 Universality ◦ グリフ(字形)ではなく文字を扱う Characters, not Glyphs ◦ プレーンテキスト Plaintext ◦ 統合 Unification ◦ 動的な合成 Dynamic composition • ただし、例外的に以下の原理は優先される ◦ 安定性 Stability ◦ 変換可能性 Convertibility
309. © 2024 Wantedly, Inc. 文字収録の原則 1 • 「普遍性」原理: Unicodeは世界中の文字を収録する。 • 現代で使われていない文字も収録される ◦ 線文字Bなど • 例外もある ◦ 利用形態について十分な知見がないものなど、収録できないものもある • 固定長時代のUnicodeでは不可能だった ◦ 65536文字に収まるというのは、収録範囲を限定した上で漢字を包摂する前提だった あ 𐎧 ᷎ ᷎ ᷎ [Unicode] §2.2.1
310. © 2024 Wantedly, Inc. 文字収録の原則 2 • 「プレーンテキスト」原理: 文字の内容だけを扱い、文字のスタ イルは扱わない ◦ 対義語は Rich Text で、HTMLなどを指す • 太字、赤色、上付き、下付き、…… などは収録しない • 例外も(たくさん)ある ◦ スタイルが文字内容と関連している場合 (日本語の小書き文字など) ◦ 互換性要件 (後述) [Unicode] §2.2.5
311. © 2024 Wantedly, Inc. 文字収録の原則 3 • 「動的な合成」原理: ダイアクリティカルマークとハングルは部 品から合成する • したがって、これらの合成済み形式は提供しない • 例外も(たくさん)ある ◦ 主要なハングル音節 ◦ 漢字の会意文字・形声文字 ◦ アラビア文字のイジャーム ◦ タイ文字の母音記号の一部 (通常の文字として提供) ◦ 互換性 (後述) Q ◌ ̋ Q ̋ [Unicode] §2.2.8
312. © 2024 Wantedly, Inc. 文字統合の原則 1 • 「グリフではなく文字」: 文字の形状ではなく、役割に着目する • コンテキストで形状が変わる場合にも、「意味的な1文字」とい う単位を重視する • 例外はもちろんある ◦ 互換性 a a a a [Unicode] §2.2.3
313. © 2024 Wantedly, Inc. 文字統合の原則 2 • 「統合」: 文字体系 (script) ごとに、同じとみなせる文字はま とめる ◦ 「同じ」かどうかは、形や意味から総合的に判断する • 言語ごとではない点に注意 ◦ 英語・フランス語・ドイツ語は統合の対象 ◦ ラテン文字・ギリシャ文字は統合の対象外 ◦ 中国・日本・韓国の漢字は統合の対象 ◦ ひらがな・カタカナは統合の対象外 [Unicode] §2.2.7
314. © 2024 Wantedly, Inc. 文字統合の原則 2 • 「統合」: 文字体系 (script) ごとに、同じとみなせる文字はま とめる A A A 英語のA, ドイツ語のA, フランス語のA。 これらは同じ。 = = A Α A ≠ ≠ ラテン文字のA, ギリシャ文字のΑ, キリル文字のA。 これらは異なる。 [Unicode] §2.2.7
315. © 2024 Wantedly, Inc. 文字統合の原則 2 • 「統合」: 文字体系 (script) ごとに、同じとみなせる文字はま とめる 骨 骨 骨 中国語の骨、日本語の骨、韓国語の骨。 これらは同じ。 = = へ ヘ ≠ ひらがなの「へ」、カタカナの「ヘ」。 これらは異なる。 [Unicode] §2.2.7
316. © 2024 Wantedly, Inc. 例外規則 • ここまでの原則には、いくつもの例外がある • それらの多くは「安定性」と「変換可能性」原理によりコントロー ルされる
317. © 2024 Wantedly, Inc. 例外規則 • 安定性 (Stability) ◦ いちど追加した文字は取り消せない。また、一度決めた振舞いは、ものによってはあとか ら変更できない。 • 変換可能性 (Convertibility) ◦ 主要な文字コード規格からの変換をサポートしなければならない。 [Unicode] §2.2.9 [Unicode] §2.2.10
318. © 2024 Wantedly, Inc. 例外規則 - 変換可能性 • 変換可能性の定式化として “round-trip” 規則がある • round-trip規則: 古いエンコーディングからUnicodeに変換し、元に戻しても情 報が失われない。 JIS X 0208 Unicode JIS X 0208 埋め込み 部分写像 恒等写像 [Unicode] §2.3
319. © 2024 Wantedly, Inc. 例外規則 - 変換可能性 round-trip 規則は2つのことを含意: • 原規格にある文字は全てUnicodeに収録する。 • 原規格で区別されている文字は、Unicodeでも区別する。 (原規格分離規則) これは文字収録・統合の原則より優先される
320. © 2024 Wantedly, Inc. 互換文字 以上を踏まえて、Unicodeの文字は2つに分けられる: • 通常の文字: Unicodeの文字収録原則に基づく文字 • 互換文字: round-trip ruleのために必要な文字 ◦ スタイルの当たった文字や合字 ◦ 合成済みの文字 ◦ Unicode の包摂基準上は区別されない JIS X 0208 の文字 など • ただし、この区別は厳密なものではない ◦ 「互換分解可能な文字」は厳密に定義されているが、少しニュアンスがずれる
321. © 2024 Wantedly, Inc. 互換文字 ffi ﻼ 𝑨 Ⅶ 豈 ² ⑨ ㍿ ᷎
322. © 2024 Wantedly, Inc. ブロック
323. © 2024 Wantedly, Inc. コードポイント順 Unicodeのコードポイント順には緩やかな構造がある • 全く無意味に配列されているわけではない • しかし、明確な意味を見出すこともできない [Unicode] §2.8
324. © 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
325. © 2024 Wantedly, Inc. コードポイントの原則 コードポイント割り当ての原則 • 文字種ごとに近接させる ◦ 用途や文字体系に基づいて分類する • 原規格の順序をある程度尊重する • なるべく 2^n の位置に揃える ◦ ブロックは必ず16の倍数、さらに128の倍数であることが多い • 漢字は概ね「部首-画数」順で並べる [Unicode] §2.8.3
326. © 2024 Wantedly, Inc. コードポイントの注意 • ブロック名は参考程度 ◦ Basic Latin は ASCII と一致するため、汎用の記号を含む ◦ Arabic Presentation Forms-A には、非文字として予約されたコードポイントが 32個 含まれる • コードポイント順 ≠ 照合順 ◦ 原規格で照合順に近い並びになっているものも多いが、完全ではない ◦ 照合については後述 • 同じ用途のブロックが複数あるのも普通 ◦ CJK Unified Ideographs の拡張ブロックは A - J まである
327. © 2024 Wantedly, Inc. 文字を繋げる仕組み
328. © 2024 Wantedly, Inc. 文字を繋げる仕組み 似たような概念が色々ある 結合 (combining) メインの文字 + 補助的な記号 q + ◌̣ = q̣ 等位結合 (conjoining) 字母 + 字母 + 字母 (ハングル専用) ᄊ + ᆞ = ᄊᆞ 合成 (composition) 結合によって1つのコードポイントになる場合 a + ◌̀ = à 合字 (ligature) 文字が並ぶことで形が変わる (文字数は変わらない ) f + f + l = ffl 連結 (joining) 筆記体文字の合字システム (主にアラビア文字) لھ = ل + ه
329. © 2024 Wantedly, Inc. 文字を繋げる仕組み • 1文字を繋げる仕組み: 　結合・等位結合・合成 • 複数文字を繋げる仕組み: 　合字・連結
330. © 2024 Wantedly, Inc. 1文字を繋げる仕組み 1文字を繋げる仕組み • 結合 … 「結合文字」を足すことで文字を装飾 • 等位結合 … ハングルの構成 • 合成 … 結合・等位結合された文字を1コードポイントで表すこと
331. © 2024 Wantedly, Inc. 結合 • 結合 (combining) • 「結合文字」を後置することで文字を装飾 • 歴史的には前置もあった ◦ 前置スタイル … デッドキー方式に対応 ◦ 後置スタイル … バックスペースキー方式に対応 [Unicode] §5.12.1 [Unicode] §2.11.1
332. © 2024 Wantedly, Inc. 結合 • 結合 (combining) q U+0071 ◌̣ U+0323 q̣ Non-spacing mark 結合文字自体は 幅を占有しない。
333. © 2024 Wantedly, Inc. 結合 • 結合 (combining) क U+0915 ि◌ U+093F क Spacing mark 結合文字自体も 幅を持つ。
334. © 2024 Wantedly, Inc. 結合 • 結合 (combining) a U+0061 ◌⃝ U+20DD a⃝ Enclosing mark 両側から囲む
335. © 2024 Wantedly, Inc. 結合 • 結合 (combining) ではない例 เ U+0E40 ก U+0E01 เก [Unicode] §2.2.6 ก は子音字、 เ は母音記号のため、Unicodeの原則上は ก が先行するはず。 しかし、タイ文字を含むいくつかの文字では、すでに視覚的な順序での入力が慣例化しているため、 このような入力順序になる。
336. © 2024 Wantedly, Inc. 等位結合 • 等位結合 (conjoining) • ハングル字母を組み合わせて文字を作る • 始声 + 中声 + 終声 ◦ 始声 = 頭子音、 中声 = 母音、 終声 = 末子音 ◦ 終声は無いことがある • 対等な結合関係が特徴 ◦ 通常の結合は、ベース文字と「結合文字」の関係がある [Unicode] §3.12
337. © 2024 Wantedly, Inc. 等位結合 • 等位結合 (conjoining) ᄊ U+110A ᆞ U+119E ᄊ ᆞ
338. © 2024 Wantedly, Inc. 合成 • 合成 (composition) ◦ 対義語は分解 (decomposition) • 複合的な文字を、1つのコードポイントで表す ◦ 「結合」や「等位結合」は、複数のコードポイントで表す仕組みだった ◦ 「合成」は1つのコードポイントの話なので、やや視点が異なる • 正規化にかかわる (後述) [Unicode] §3.11
339. © 2024 Wantedly, Inc. 複数文字を繋げる仕組み 複数文字を繋げる仕組み • 合字 … 文字の並びで字形が変わる • 連結 … アラビア文字 etc. の合字 ◦ 筆記体が標準であるため、特別な扱いが必要になる
340. © 2024 Wantedly, Inc. 合字 • 合字 (ligature) • 文字の並びに応じて、形が変化する ◦ 印刷や筆記上の慣例に由来 ◦ fi, ffi, fl, ffl の合字が代表的 • 合字が独立した文字になったものも多い ◦ これも慣習的に「合字」と呼ぶ ◦ ß (s + s), œ (o + e) など ◦ どこまでを独立した文字とするかは曖昧なこともある
341. © 2024 Wantedly, Inc. 連結 • 連結 (joining) ◦ cursive joining とも • アラビア文字などを対象とした合字の亜種 ◦ これらの文字は、標準で筆記体を使う • Unicodeでは、合字 ≠ 連結 ◦ 「連結」は「合字」とは独立したシステムで処理される ◦ たとえば ل + ا をそのまま並べると ا ل だが、連結すると ﺎ ﻟ となり、さらに合字を適用すると ﻻ になる [Unicode] §23.2.2
342. © 2024 Wantedly, Inc. 正規化
343. © 2024 Wantedly, Inc. 等価性 • 2つの文字列が等しいとは、同じUSVの並びであること • この定義では不便なことがある • ここでは「正準等価性」と「互換等価性」を扱う
344. © 2024 Wantedly, Inc. 正準等価性 • 正準等価性: 同じ見た目かつ同じ振舞いが期待される 文字列同士の関係 ◦ Gc値, Script値や「バックスペースの振舞い」などの差異はあり、 全く同じではない • 通常の文字・互換文字の両方で生じうる ◦ 結合文字の適用順序の違い (通常の文字で発生) ◦ 合成済み文字 (互換文字で発生) ◦ round-trip ruleのために追加されたシングルトン等価な文字 (互換文字で発生) [Unicode] §3.11, [UAX#15]
345. © 2024 Wantedly, Inc. 正準等価性 e ◌ ̈ ë U+0065 U+0308 U+00EB = q U+0071 ◌ ̇ U+0307 ◌̣ U+0323 q U+0071 ◌̣ U+0323 ◌ ̇ U+0307 = 豈 豈 U+F900 U+8C48 =
346. © 2024 Wantedly, Inc. 互換等価性 • 互換等価性: 見た目や振舞いにかかわらず、同じ文字内容を 指している文字列同士の関係 • 通常の文字・互換文字の両方で生じうる ◦ フォーマット効果のある文字 (NBSPなど) ◦ スタイルやグリフ情報を持つ互換文字 ◦ JIS X 0208 の包摂基準に由来する互換文字 ◦ 組み文字など [Unicode] §3.11, [UAX#15]
347. © 2024 Wantedly, Inc. 互換等価性 ffi ⑨ U+FB03 = ffi U+2468 = 9 ㍿ = 株式会社
348. © 2024 Wantedly, Inc. 正規形 • 正準等価性・互換等価性は、対等な同値関係を定義する • 実際の処理では、特定の形に揃えて比較するほうが便利 → 正規形 (normalization form) を扱う ◦ 数学的には、同値類から代表元を選択する操作
349. © 2024 Wantedly, Inc. 正規形 4つの正規形がある • NFC: 正準分解 → 正準合成 • NFD: 正準分解 • NFKC: 互換分解 → 正準合成 • NFKD: 互換分解 「互換合成」はない NFC, NFD は正準等価性の正規形 NFKC, NFKD は互換等価性の正規形 を与える [Unicode] §3.11.7
350. © 2024 Wantedly, Inc. 正規形 構成 元の文字列 NFC NFD NFKC NFKD 正準分解 互換分解 正準合成 正準合成
351. © 2024 Wantedly, Inc. 正規形 ステートマシン 元の文字列 NFC NFD NFKC NFKD NFC NFD NFKC NFKC NFKD NFKD NFD NFC NFD NFKD NFC NFKC NFC NFKC NFD NFKD
352. © 2024 Wantedly, Inc. 分解アルゴリズム 分解アルゴリズム (NFD, NFKD) は2手順からなる 1. 分解可能な文字を全て展開する 2. 合成文字を正準順序に並び換える [Unicode] §3.11.7
353. © 2024 Wantedly, Inc. 分解アルゴリズム - 文字の分解 文字の分解はシンプル (再帰的に行う) ㍿ 株 式 会 社
354. © 2024 Wantedly, Inc. 分解アルゴリズム - 正準順序 正準順序 d ◌ ̇ ◌̣ d ◌̣ ◌ ̇
355. © 2024 Wantedly, Inc. 正準結合クラス - Overlay A ccc=Overlay (1) ccc=Not_Reordered (0) [UAX#44] §5.7.4
356. © 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
357. © 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
358. © 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
359. © 2024 Wantedly, Inc. 正準順序 並び替え可能な文字は限られる 開始子 (Starter) 並び替えの対象外 (Ccc = 0) • 全ての非結合文字 • 全ての囲み結合文字 • 一部の結合文字 非開始子 (Non-Starter) 並び替えの対象 (Ccc > 0) • 多くの結合文字 A U+0041 ⃝ U+20DD ◌ः U+0903 ◌́ U+0301 〯 U+302F
360. © 2024 Wantedly, Inc. 並び替え対象範囲 開始子の役割 開始子: 並び替えを制限 a U+0061 a U+0061 ◌́ U+0301 ◌̣ U+0323 ◌́ U+0301 ◌ ̊ U+030A Ccc=0 Ccc=230 Ccc=220 Ccc=0 Ccc=230 Ccc=230 並び替え対象範囲 並び替えを制限 並び替えを制限
361. © 2024 Wantedly, Inc. 非開始子の役割 各範囲内で安定ソート a U+0061 a U+0061 ◌́ U+0301 ◌̣ U+0323 ◌́ U+0301 ◌ ̊ U+030A Ccc=0 Ccc=230 Ccc=220 Ccc=0 Ccc=230 Ccc=230 この中で安定ソート (220 → 230 になる) この中で安定ソート (順番は変わらない)
362. © 2024 Wantedly, Inc. 正準順序とスタック • 開始子が254個のスタックを持つとも考えられる ◦ ただし、文字列の先頭も開始子とみなす必要がある • 1〜254個のスタックに、結合文字をpushできる ◦ それぞれのスタックは独立 ◦ 同じスタックの中では、順序が重要
363. © 2024 Wantedly, Inc. 正準順序の注意 「開始子」と「結合するかどうか」は別 • ハングルの字母結合システム (Conjoining Jamos) ◦ L + T + V で1文字を構成 ◦ L, T, V はいずれも開始子 (文字分類上は非結合文字) • 並び替えない結合文字 ◦ たとえば囲み結合文字 ⃞ は並び替えの対象外 → 囲みの内側と外側に別々に結合文字がつく
364. © 2024 Wantedly, Inc. 正準順序 正準順序 ≠ 文字の図形的な構造 • Ccc はおおむね 内側 → 外側 の順に並べられているが、あく までベストエフォート • 実際の文字構造は描画エンジンやフォントが決める ◦ たとえば UAX #53 はアラビア文字の発音記号の描画順序に関する推奨事項を定めて おり、これは正準順序とは異なる
365. © 2024 Wantedly, Inc. 正準合成 • NFC, NFKC では、最後に正準合成を行う • 正準分解の逆のプロセスを、開始位置から貪欲に行う • 合成してはいけない組み合わせがある ◦ 主に互換性のために必要
366. © 2024 Wantedly, Inc. 正準等価性とUnicodeアルゴリズム • 正準等価性: 同じ見た目・同じ振舞いを期待 • 規格で規定されているアルゴリズムの多くは、 正準等価な文字列に対して同じ振舞いをするよう規定 ◦ 正規化アルゴリズム自体もそう ◦ テキストの区切り、Bidi は性質の保存を保証 ◦ 識別子構文では、等価性を尊重するための定義をいくつか用意 ◦ 例外もある (東アジアの文字幅など)
367. © 2024 Wantedly, Inc. Recap: 10の設計原理 Unicodeが定める「10の設計原理」 普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2
368. © 2024 Wantedly, Inc. Recap: 10の設計原理 Unicodeが定める「10の設計原理」 普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2
369. © 2024 Wantedly, Inc. 正規化の安定性 • 正規化には強い安定性保証がある • 割り当て済みの文字のみからなる正規形は、 以降のバージョンでも正規形であることが保証される
370. © 2024 Wantedly, Inc. 正規化の安定性 - 応用 • 例: パスワードを正準等価性で比較するシステムを考える ◦ ダイアクリティカルマークを持つ言語では、単純比較が問題になりえるため • パスワード設定時 ◦ 未割り当ての文字 /\p{Cn}/ がないことを検証 → あればパスワードを拒否 ◦ NFCで正規化し、適切なKDFでハッシュ化して保存 • パスワード比較時 ◦ NFCで正規化後ハッシュを取り比較 • 安定性保証により、ログインの成功が保証される [UAX#15] §12
371. © 2024 Wantedly, Inc. 文字列等価性の代数 • 正準等価性・互換等価性は商集合を定める • この集合はどんな代数的な性質を持つ? • ここでは NFD / NFKD を扱う ◦ 代表元の選び方が異なるだけで、商集合としての性質は NFD でも NFC でも変わらない
372. © 2024 Wantedly, Inc. NFD の代数的性質 • NFD = 分解マッピング + 正準順序 ◦ NFKDも代数的には同じ • 分解マッピングの代数的性質は簡単 ◦ 原子的な文字の並びに対するレトラクションになっている ◦ 単に文字数が少ないだけで、自由モノイドになっている • 正準順序が代数的な困難をもたらす
373. © 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つ持ってくると反 例になる。
374. © 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 は商モノイド上で等しい。
375. © 2024 Wantedly, Inc. モノイドとしての性質 • 開始子で始まる文字列だけに限定すると 自由モノイドになる ◦ ただし、生成元の集合は無限集合になる ◦ この事実は、正規形の最初の開始子と最後の開始子の indexを保持しておくことで、正 規形同士の演算を高速に処理できることを示唆している
376. © 2024 Wantedly, Inc. Unicode Character Database
377. © 2024 Wantedly, Inc. Recap: 10の設計原理 Unicodeが定める「10の設計原理」 普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2
378. © 2024 Wantedly, Inc. Recap: 10の設計原理 Unicodeが定める「10の設計原理」 普遍性 Universality 論理的な順序 Logical order 効率性 Efficiency 統合 Unification グリフ(字形)ではなく文字を扱う Characters, not Glyphs 動的な合成 Dynamic composition よく定義された意味論 Semantics 安定性 Stability プレーンテキスト Plaintext 変換可能性 Convertibility [Unicode] §2.2
379. © 2024 Wantedly, Inc. Unicodeと意味論 • Unicodeの文字は、形状だけではなく意味を持っている • 「文字の名前」は意味を十分に説明しない ◦ 現在の用法に即しない名前 U+0028 LEFT PARENTHESIS ◦ 象形文字・表語文字の名称 CJK UNIFIED IDEOGRAPH-4E00 • 文字ごとの振舞いの違いをデータにしておく必要がある
380. © 2024 Wantedly, Inc. UCD • UCD (Unicode Character Database): Unicode の付属データ • 文字に多数の「プロパティ」を付与している
381. © 2024 Wantedly, Inc. UCD 直接利用する機会の多いプロパティ • General_Category: 文字の用途 ◦ 文字を代表的な用途で分類したもの ◦ 他のプロパティのベースとして使われたり、正規表現で利用する • Script: 文字体系 ◦ 文字を、それが所属する体系で分類したもの (ギリシャ文字、カタカナなど) ◦ 正規表現でしばしば利用される
382. © 2024 Wantedly, Inc. UCD • Simple_Uppercase_Mapping ◦ 大文字変換・小文字変換のAPIでしばしば利用される ◦ 「最も代表的な」「1対1の」大文字小文字変換を提供 ◦ Simple_Lowercase_Mapping, Simple_Titlecase_Mapping と併用 ◦ 言語によっては、この対応では不十分 (ギリシャ語、トルコ語など)
383. © 2024 Wantedly, Inc. UCD • 文字カテゴリ関連 • 東アジアの文字幅 • ハングル • アラビア文字の結合処理 • 数値 • 絵文字関連
384. © 2024 Wantedly, Inc. UCD • 正規化関連 • 大文字小文字処理関連 • コレーション関連 • セグメンテーション関連 • プログラミング言語の識別子 • Bidi関連・縦書き関連
385. © 2024 Wantedly, Inc. Unihan / Unikemet • Unihan: UCDのうち、漢字関連のデータをまとめたもの ◦ 画数 ◦ 各言語での代表的な読み ◦ 数値 ◦ 原規格からの出典 etc. • Unikemet: UCDのうち、ヒエログリフ関連のデータをまとめ たもの
386. © 2024 Wantedly, Inc. 書記素とセグメンテーション
387. © 2024 Wantedly, Inc. 1文字 • Unicodeには「動的な合成」原理がある • 複数のUSVで1つの「文字」を表すことがある → 正準等価に対し不変な「1文字」の概念が欲しい
388. © 2024 Wantedly, Inc. 1文字 = 書記素 • このような「1文字」の単位を言語学で「書記素」と呼ぶ • 書記素クラスター = Unicodeにおける書記素 ◦ 言語学的な「書記素」と区別するために「書記素クラスター」と呼ぶ ◦ Unicode Text Segmentation で、単語境界や文境界と合わせて定義 • 通常は「拡張書記素クラスター」を使う ◦ レガシー書記素クラスターはなるべく使わない 書記素とは関係ないが、 Unicode Text Segmentationでは平仮名や片仮名の単 語境界も定めている。 ブラウザで、カタカナの単語をダブルクリックしたときとひらがなの単語をダブルク リックしたときの挙動を比べてみると面白い。
389. © 2024 Wantedly, Inc. 書記素クラスターの注意点 • 書記素クラスターは理論上かなり長くなる ◦ ストレージサイズの制限を意図しているなら、コードポイント数の制限も設定するべき • 書記素境界の決定には無制限の後読みが必要 ◦ Emoji Flag Sequences の設計のせい ◦ Emoji Flag Sequences の設計のせい ◦ Emoji Flag Sequences の設計のせい ◦ Emoji Flag Sequences の問題を除けば、有限の後読み・先読みで解決できる
390. © 2024 Wantedly, Inc. セグメンテーション テキスト分割アルゴリズムは他に2つある 書記素 クラスター h, e, l, l, o 編集の単位、カーソルの動き、照合、縦書き、 最初の1文字のスタイリング、文字数の表示 な ど 単語 “Hello, “, “world!” ダブルクリックによる選択、Ctrl+矢印による移 動、単語検索、単語数の表示 など 文 “This is a pen.” トリプルクリックによる選択など
391. © 2024 Wantedly, Inc. 「ぎなた読み」問題 • 中国語や日本語では「分かち書き」を行わない ◦ 分かち書き: 単語同士をスペースで明示的に区切る表記のこと • 規格に定める単語分割はルールベースのため、 分かち書きに強く依存している ◦ 日本語では「ぎなた読み」問題と呼ばれる この先生きのこるには
392. © 2024 Wantedly, Inc. 「ぎなた読み」問題 • 規格上は簡易的なヒューリスティックスがある ◦ 規格の記述通りに実装されていれば、ダブルクリックで確かめられる ◦ 現行の Chrome などでは既に機械学習ベースのルールでカスタマイズされてしまって いるので、この現象は確認できない • ひらがな → 1文字ごとに単語境界とする • カタカナ → 全体を1単語とする
393. © 2024 Wantedly, Inc. 改行処理 • 改行処理 = 単語区切りを考 慮して行分割を行う ◦ 単語折り返し (word wrap) とも呼 ぶ • UAX #14 で規定 絶妙な改行位置で有名だった、 Javaの旧ダウンロードページ
394. © 2024 Wantedly, Inc. 改行処理と単語区切り • 改行処理の原則は「単語で区切る」 • しかし、規格上は別アルゴリズム ◦ 単語境界は UAX #29, 改行処理は UAX #14 で規定 • 振舞いには違いがある
395. © 2024 Wantedly, Inc. 改行処理と単語区切り 例: NBSPとSHY ␣ U+0020 SHY U+00AD NBSP U+00A0 通常のスペース 改行禁止スペース ソフトハイフン ✅ 単語区切り ✅ 単語区切り ❌ 単語を区切らない ✅ 改行可能 ❌ 改行しない ✅ 改行可能
396. © 2024 Wantedly, Inc. 特殊な文字
397. © 2024 Wantedly, Inc. 特殊な文字 本来の「文字」ではない文字として以下のようなものがある • 改行や空白 (Gc=Z) • 制御またはフォーマット (Gc=Cf,Cc) • 未割り当てまたはサロゲート (Gc=Cn,Co,Cs) ここではこうした特殊な文字を初回する
398. © 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 に準じて扱う
399. © 2024 Wantedly, Inc. フォーマット文字 – 空白 • U+0020 SPACE … 基本の空白 • 固定空白 ◦ U+2000 - U+200A および U+205F がそれぞれ特定の長さ指定を持つ空白 ◦ U+1680 もオガム文字用のスペースとみなされている • U+3000 IDEOGRAPHIC SPACE … いわゆる全角空白 ◦ 互換文字としての側面もある。 ◦ いっぽう、東アジアの組版慣習に適した空白でもあり、 単なる互換文字とも言い切れない。
400. © 2024 Wantedly, Inc. フォーマット文字 – 空白 • 改行しない空白文字 2種類 ◦ U+00A0 … 改行しない空白文字 ◦ U+202F … 改行しない空白文字 (狭い) ◦ 慣用表現 (et al.)、数字 (1 234) など組版の慣習上必要な場面がある • U+0009 水平タブ ◦ 表組み (tabulation) のためのタイプライター等の慣習を引き継いだ文字 • U+001F ユニット区切り ◦ U+001C 〜 U+001E と組み合わせて使う。今どきは使わない
401. © 2024 Wantedly, Inc. フォーマット文字 – 改行 • U+000A 最もよく使われる改行 (LF) ◦ 基本的にこれを使っておけば良い • U+000D U+000A 次点でよく使われる改行 (CRLF) ◦ MS-DOS, Windows, HTTP などが有名 ◦ CR 単体ではあまり使わない (classic Mac OS が有名)
402. © 2024 Wantedly, Inc. フォーマット文字 – 改行 • U+000B 垂直タブ。ほぼ使わない。 • U+000C 改ページ。ほぼ使わない。 • U+0085 次の行。ほぼ使わない。 • U+001C〜1E ほぼ使わない。 • U+2028 行区切り。ほぼ使わない。 • U+2029 段落区切り。ほぼ使わない。 水平タブと同様の起源。 スペース扱いの場合もある 紙面を送るという意味。 メインフレームでは現役かも テキストをツリー構造で管理できる仕組み。RFC 7464で見たことはある この2つはUnicodeで導入された。 いわゆる <br> と <p> に相当。 たとえば JavaScript では改行扱い
403. © 2024 Wantedly, Inc. フォーマット文字 - ゼロ幅 • 幅をもたない文字も色々ある 説明 単語 境界 改行 可能 文字の 連結 備考 U+00AD ソフトハイフン - ✅ - 改行時、ハイフンになる U+200B ゼロ幅スペース ✅ ✅ - U+200C ゼロ幅非結合子 - - ❌ U+200D ゼロ幅結合子 - ❌ ✅ U+2060 U+FEFF 単語結合子 - ❌ -
404. © 2024 Wantedly, Inc. Unicodeのカスタマイズ
405. © 2024 Wantedly, Inc. カスタマイズ (tailoring) • Unicodeは多くのアルゴリズムを定義している ◦ 正規化、テキストの区切り、改行処理、大文字小文字処理、 Bidi、照合、東アジアの文字 幅、プログラミング言語の識別子、正規表現、 etc. • 言語・文化・産業等によって最適な振舞いは異なる → カスタマイズ (tailoring) の必要性 • カスタマイズ可能な範囲も、規格で規定 ◦ たとえば、正規化アルゴリズムはカスタマイズ禁止 ◦ Bidiや照合にはカスタマイズの余地がある
406. © 2024 Wantedly, Inc. 例: 書記素クラスター • たとえば、スロバキア語では ch を1文字とみなす • デフォルトのアルゴリズムでは c + h で2文字とみなす ため、カスタマイズが必要 ch
407. © 2024 Wantedly, Inc. 照合
408. © 2024 Wantedly, Inc. Bidi
409. © 2024 Wantedly, Inc. 東アジアの文字幅
410. © 2024 Wantedly, Inc. 波ダッシュ・全角チルダ問題
411. © 2024 Wantedly, Inc. 絵文字
412. © 2024 Wantedly, Inc. OpenType
413. © 2024 Wantedly, Inc. フォント(原義)とタイプフェイス • タイプフェイス (typeface): 　一定のコンセプトで作られた字形のシリーズ ◦ フォントファミリー (font family) とも呼ぶ ◦ 例: Helvetica • フォント (font): 　タイプフェイスのうち、 　特定のスタイル・ウェイトを持つもの ◦ 例: Helvetica Condensed Bold Italic [BitesizeTypography3], [GoogleFontsGlossaryA] [BitesizeTypography3]
414. © 2024 Wantedly, Inc. フォントファイル • フォントファイル (font file): 　タイプフェイスやフォントを電子的に表現したもの ◦ 例: NotoSans-VariableFont_wdth,wght.ttf ◦ 単に「フォント」とも呼ぶ [GoogleFontsGlossaryA]
415. © 2024 Wantedly, Inc. フォントファイル フォントファイルと言っても…… • 最も簡単なフォントファイル: 　画像の集まり • 現代的なフォントファイル: 　複雑な分岐を含む、 　一種のプログラム
416. © 2024 Wantedly, Inc. フォントの仕事 • 可変フォント ◦ 「太さ」「傾き」etc. から動的にアウトラインを計算 • カーニング ◦ 文字の組み合わせによって位置を調整 • 合字 ◦ 文字の組み合わせによって形状を調整 • 自由な合字 ◦ デザイナー向けの高度な合字を組み込んでいるフォントもある
417. © 2024 Wantedly, Inc. フォントの仕事 • 結合位置の調整 ◦ Á と á ではアクセント記号の位置が異なる • スタイル指定 ◦ スモールキャピタルや古風な数字など、異なるスタイルを指定できるものもある • 言語によるスタイル差 ◦ 言語によって組版上の慣習が異なることがある • 縦書き
418. © 2024 Wantedly, Inc. フォントの仕事 • 漢字字形 ◦ 同じ漢字の異なる字形を選択 • 低解像度への最適化 (font hinting) • etc.
419. © 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]
420. © 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]
421. © 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
422. © 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]
423. © 2024 Wantedly, Inc. sfntの構造 • sfntはテーブルの集まり • 4文字のテーブル名で識別 ◦ これにより拡張性を実現 (header) maxp hhea head GDEF OS/2 cmap name loca hmtx GPOS post GSUB glyf Poppins-Regular.ttf の構造例
424. © 2024 Wantedly, Inc. テキスト描画パイプライン 大きく4段階で描画 レイアウト 改行位置の 決定 etc. アウトラインの 決定 (hinting) ラスター化
425. © 2024 Wantedly, Inc. テキスト描画パイプライン 大きく4段階で描画 レイアウト 改行位置の 決定 etc. アウトラインの 決定 (hinting) ラスター化 フォントが指定するのはこの部分
426. © 2024 Wantedly, Inc. レイアウトとグリフ • レイアウト: どこに何を描くかを決定 • レイアウトの基本単位: グリフ (glyph) ◦ グリフは文字を「形」に注目して分類したもの • グリフ ≠ 文字 ◦ 1文字が複数グリフになる (結合文字など) ◦ 複数文字が1つのグリフになる (合字など) ◦ 1種類の文字が異なるグリフに展開される (異体字など)
427. © 2024 Wantedly, Inc. レイアウトとグリフ レイアウト機能は2階層に分けられる • OpenTypeの基本レイアウト ◦ 全てのOpenTypeフォントが実装 • 高度なレイアウト ◦ 主要な方式が3つある ◦ OTL, AAT, SIL [RFC8081] §4.4.1
428. © 2024 Wantedly, Inc. レイアウトとグリフ • OpenTypeの基本レイアウト + 高度なレイアウト • 基本レイアウト: シンプルな欧文レイアウトを定義 ◦ cmap, head, hhea, hmtx で定義 • 高度なレイアウト: 代表的な方式は3種類 [RFC8081] §4.4.1
429. © 2024 Wantedly, Inc. cmap • cmap: 文字のデフォルトグリフを定義 ◦ デフォルトグリフ: 文字と1対1対応する
430. © 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仕様でそれぞれ定義されている。
431. © 2024 Wantedly, Inc. OTLのレイアウトプロセス OTLは大きく3ステップ cmap デフォルト グリフの決定 GSUB グリフの 置き換え GPOS 位置決定 加えて、以下のような処理も行う • 割り付け (JSTF) • ベースライン決定 (BASE) • キャレット位置決定 (GDEF) [OpenTypeLayoutOverview]
432. © 2024 Wantedly, Inc. OTL – cmap • cmap はデフォルトグリフを決定する ◦ これにより、文字情報を図形情報として取り扱う準備ができる • この時点では1文字 = 1グリフ
433. © 2024 Wantedly, Inc. OTL – GSUB • GSUB はグリフの置き換えを指示する • 各ルールは3つの適用条件を持つ ◦ 条件1: 特定の文字体系 (script) のみで実行 ◦ 条件2: 特定の言語体系 (language system) のみで実行 ◦ 条件3: 特定の機能 (feature) が有効な場合のみ実行 • ルールは典型的には「グリフ列」→「グリフ列」 ◦ 代替置換 (alternate) や文脈依存の置換もできる 置換ルールの適用順 (優先度) は LookupListでの宣言順で決まる。
434. © 2024 Wantedly, Inc. OTL – GSUB • GSUB 機能の例 ◦ ccmp … 前処理としてのグリフ分解 ◦ aalt … 異体字リストを提示 (ユーザーが選択) ◦ locl … 言語ごとの異体字 ◦ liga … 常に適用するべき合字 ◦ dlig … ユーザーが任意で適用する合字 (ユーザーが選択)
435. © 2024 Wantedly, Inc. OTL – GPOS • GPOS はグリフの位置計算を指示する • 各ルールは3つの適用条件を持つ (GSUB と同じ) ◦ 条件1: 特定の文字体系 (script) のみで実行 ◦ 条件2: 特定の言語体系 (language system) のみで実行 ◦ 条件3: 特定の機能 (feature) が有効な場合のみ実行 • 各ルールはグリフの位置調整命令になっている
436. © 2024 Wantedly, Inc. OTL – GPOS • GPOS 機能の例 ◦ kern 横書きカーニング ◦ mark ダイアクリティカルマークの位置決定 ◦ mkmk マーク位置を他のマークからの相対で決定
437. © 2024 Wantedly, Inc. Recap: テキスト描画パイプライン 大きく4段階で描画 グリフ・ グリフ位置の 決定 改行位置の 決定 etc. アウトラインの 決定 (hinting) ラスター化
438. © 2024 Wantedly, Inc. アウトラインの決定 • グリフ位置を決定したら、次はグリフを画像として実現する必 要がある • ここにも様々な工夫がある ◦ アウトライン記述 ◦ ヒンティング ◦ 可変フォント
439. © 2024 Wantedly, Inc. アウトラインの決定 • 拡大・縮小に対して綺麗に表示するための工夫 • アウトライン(輪郭)を数式で指定 ◦ いわゆるベクター画像に相当 ◦ 拡大してもジャギーが発生せず、なめらかに表示できる • ヒンティングでラスター化を調整 ◦ 低解像度の場合はあらかじめ図形を変形する ◦ 縮小しても綺麗に読めるように、 フォント側で手動で調整できるようになっている
440. © 2024 Wantedly, Inc. アウトラインの決定 主要なアウトライン形式は3種類 • CFF: PostScript outline ◦ 元々はAdobeのPostScript fontで使われていたもの • TTF: TrueType outline ◦ 元々のAppleのTrueType技術で使われていたアウトライン方式 • SVG ◦ 補助的なアウトライン方式で、主にカラー絵文字に使われる [RFC8081] §4.4.1 カラー絵文字はSVGを使わず COLR/CPAL で表現することも可能
441. © 2024 Wantedly, Inc. アウトラインと曲線 • グリフ形状の記述は曲線を用いて行う • 曲線の表現力についてまずは整理する
442. © 2024 Wantedly, Inc. 曲線 • 曲線: 連続した点の動き (曲がっていてもよい) ◦ 曲線の数学的な扱いは、目的に応じてバリエーションがある ◦ ここでは区分的 C1 級関数 γ: [0, a] → ℝ2 を考える。 ◦ 交差や重複があってもよい (単純性は要求しない) • 曲線の速度情報を除去する ◦ 上記の曲線には速度情報が含まれている。イージング関数として使うときは必要だが、形 状の記述には必要ないので、速度を除去した曲線も考えたい。 ◦ ここでは区分的 C1 級関数 γ: [0, a] → ℝ2 を、狭義単調連続関数 φ: [0, a] → [0, b] の結 合で同一視したものと考える。すなわち γ 〜 γ’ ⇔ ∃φ. γ ∘ φ = γ’ で同値類を構成する。
443. © 2024 Wantedly, Inc. 曲線と閉曲線 • 曲線: 連続した点の動き (曲がっていてもよい) ◦ ここでは向きの情報は残しておく • 閉曲線: 輪っか状の曲線 ◦ 始点と端点が一致 (γ(0) = γ(a)) ◦ 閉曲線を考えるときは、速度情報のないものを主に考える
444. © 2024 Wantedly, Inc. 回転数 • 回転数: 各点のまわりを 何回回転したか ◦ 曲線上 (境界) では定義されない ◦ マイナスになることもある • 回転数によって塗りを定義 ◦ 非ゼロ塗り or 奇数塗り 回転数0 回転数1 回転数2
445. © 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 ] に制限した 曲線をそれぞれ考える
446. © 2024 Wantedly, Inc. 基底関数 • 基底関数と制御点を使って曲線の一部を記述 ◦ 基底関数は f i : [a, b] → ℝ、制御点は v i ∈ ℝ2 ◦ 基底関数は partition of unity: Σ f i (t) = 1 を満たす ◦ 曲線は Σ f i (t)v i • 基底関数の形状に制約を課す ◦ n次以下の多項式 ◦ 有理式
447. © 2024 Wantedly, Inc. 区分的多項式曲線 • 区分的多項式曲線: 基底関数がn次以下の多項式 • 以下と等価 ◦ 区分的n次Bezier曲線 ◦ 区分的n次B-スプライン曲線 • 区分的有理曲線: 基底関数が有理式 ◦ 区分的NURBS曲線と等価
448. © 2024 Wantedly, Inc. 区分的多項式曲線の表現力 • n次曲線に固有の曲線が存在 ◦ 曲線 y = xn は n-1 次曲線では表現できない ◦ 多項式の一致を使って証明 (y(t) - x(t)n が恒等的に 0 であることから矛盾を導く) • 有理曲線に固有の曲線が存在 ◦ 円弧は多項式曲線では表現できない ◦ 有理式の一致を使って証明 (x(t)2 + y(t)2 - 1 が恒等的に 0 であることから矛盾を導く)
449. © 2024 Wantedly, Inc. 区分的多項式曲線の表現力 • 円弧は有理曲線 ◦ (cos θ, sin θ) のままだと有理的でない ◦ u = tan(θ/2) とおくと (cos θ, sin θ) = ((1 - u2)/(1 + u2), 2u/(1 + u2)) ▪ ただし、 θ = π の場合は u = ±∞ になってしまう ◦ さらに、 u = (2t - 1)/(t(1 - t)) とおけば円周も表現可能
450. © 2024 Wantedly, Inc. Bezier曲線 • n次Bezier曲線: n次多項式曲線の表現方法の1つ ◦ 2次、3次くらいのものがよく使われる • 制御点 n + 1 個 • 基底関数 f k (t) = n C k tk(1 - t)n - k • これを区分的に繋げていくことで曲線を表現
451. © 2024 Wantedly, Inc. Bezier曲線の滑らかさ • 区分的Bezier曲線の接続点は鋭角にできるが、 滑らかさを要求したい場合もある • 滑らかさの段階もいくつかある ◦ スムーズ: 図形的な C1 性を要求 (適切なパラメーター変換で C1 になればOK) ◦ 対称: 速度を考慮した曲線としての C1 性を要求
452. © 2024 Wantedly, Inc. 曲線の表現力 • アウトライン形式によって曲線表現が異なる • CFF outline: 区分的3次多項式 ◦ 3次Bezier曲線として表現 • TTF outline: 区分的2次多項式 ◦ 2次Bezier曲線として表現 (ただし後述の Boring Expansion も参照) • SVG outline: 区分的3次多項式 + 楕円弧 ◦ 任意の有理曲線ではないが、円弧や楕円弧を描ける 逆に、双曲線などは描けない [OpenTypeComparison]
453. © 2024 Wantedly, Inc. 塗りのルール • アウトライン形式によって塗りのルールが異なる • CFF outline: 非ゼロ (原則として) ◦ CFF2テーブルは非ゼロだが、CFFテーブルの扱いは明示されていない • TTF outline: 非ゼロ • SVG outline: 非ゼロ (奇数ルールにもできる) ◦ fill-rule で変更可能 [OpenTypeComparison]
454. © 2024 Wantedly, Inc. 曲線の表現力の含意 • 曲線の表現力が弱くても、点を増やして近似はできる • とはいえ、制御点が多すぎるのは不便もある • 3次くらいあると実用的?
455. © 2024 Wantedly, Inc. ヒンティング • ヒンティング = 低解像度用の調整 近年ではアンチエイリアシング、サブピクセルレンダリング、高密度ディスプレイ、自動ヒン ティングなど環境が整備されてきているので、必ずしもヒンティング情報が活用されるわけ ではない
456. © 2024 Wantedly, Inc. ヒンティング 高解像度では綺麗でも…… → 高解像度。 Yu Gothicの文字。
457. © 2024 Wantedly, Inc. ヒンティング 低解像度では形が揃わないことがある → ヒンティングなし。 Yu Gothicの文字を Inkscape でパ ス化し、Chromeで表示。
458. © 2024 Wantedly, Inc. ヒンティング ヒンティングを使うと、 ピクセルの位置合わせができる → ヒンティングなし。 Yu Gothicの文字を Inkscape でそ のまま保存し、Chromeで表示。 ※サブピクセルレンダリングが適用されているが、こ れはヒンティングとは直接は関係ない
459. © 2024 Wantedly, Inc. ヒンティングの方式 • CFF outline: 宣言的ヒンティング ◦ フォントの構造に対する補助情報を宣言しておく ◦ レンダリングエンジンがアウトラインの調整処理を行う • TTF outline: 手続き的なヒンティング ◦ アウトラインが簡易的なVMになっている ◦ アウトライン命令から解像度を参照し、フォント自身がアウトラインを調整 [OpenTypeComparison], [AdobeType1] §5.1
460. © 2024 Wantedly, Inc. CFF (PostScript) ヒンティング CFF (PostScript) のヒントは3種類 • ステム (stem) / カウンター (counter) • アラインメントゾーン ◦ Blue Zone ともいう • フレックス (flex) [AdobeType1] §5
461. © 2024 Wantedly, Inc. ステム (stem) ステム (stem) • 縦画・横画の位置を指定 ◦ 縦画は2つのx座標、横画は2つのy座標で指定 Times New Roman の E
462. © 2024 Wantedly, Inc. ステム (stem) ステム (stem) の使われ方 • 線幅を確保 • 線をピクセル境界に揃える • 計算方法の例 ◦ ステムの幅と位置を整数化 ◦ 元のステム位置との対応関係をもとに、アウトライン座 標を変形 Times New Roman の E
463. © 2024 Wantedly, Inc. カウンター (counter) カウンター (counter) • ステムの補助を行う情報 • 縦画と縦画の隙間・横画と横画の隙間を指定 ◦ Type1 ではかわりに vstem3 / hstem3 を使用 • 十分な空間を確保したり、等間隔性を維持したり • 記号や漢字等で利用 ◦ たとえば Source Sans では U+2026 (…) と U+2261 (≡) で利用 [AdobeCIDKeyed] §4
464. © 2024 Wantedly, Inc. アラインメントゾーン アラインメントゾーン • オーバーシュート位置を指定 ◦ オーバーシュート = 曲線を直線より大きめに配置すること Times New Roman の C, o, A, x
465. © 2024 Wantedly, Inc. アラインメントゾーン アラインメントゾーン • オーバーシュートの開始y座標 + 終端y座標 • 低解像度ではオーバーシュートを抑制する • 計算方法の例 ◦ 開始・終了位置を整数化。一致したら、同じ座標にマップされるようにアウトライン座標を 変形
466. © 2024 Wantedly, Inc. フレックス 字形の辺が凹ませてある ことがある 游明朝の I の下端 (cupped serifs)
467. © 2024 Wantedly, Inc. フレックス • フレックス: デザイン上の凹面を指定する仕組み • 低解像度では凹面を抑制する • 計算方法の例 ◦ 低解像度では、フレックス幅未満の特定の凹面を直線で置き換える
468. © 2024 Wantedly, Inc. TTF ヒンティング TTF は
469. © 2024 Wantedly, Inc. 言語依存
470. © 2024 Wantedly, Inc. HarfBuzz
471. © 2024 Wantedly, Inc. Boring Expansion
472. © 2024 Wantedly, Inc. CID-keyed CJK fonts
473. © 2024 Wantedly, Inc. ソースコード
474. © 2024 Wantedly, Inc. Windows NT
475. © 2024 Wantedly, Inc. Apple
476. © 2024 Wantedly, Inc. 文字コードと情報セキュリティー
477. © 2024 Wantedly, Inc. 多言語化から国際化へ
478. © 2024 Wantedly, Inc. 旅のおわりに
479. © 2024 Wantedly, Inc. ここまでで伝えたかったこと • 今やUnicodeはインフラ(下部構造)であり、 多くのプログラマーが意識せずに使えている ◦ これはこれで良いことではある • しかし、今のUnicodeが確立されるまでに、 長い試行錯誤の歴史があった ◦ Unicodeも最適解とは言えない選択をたくさんしている • Unicodeはこれからも進化する
480. © 2024 Wantedly, Inc. ここまでで伝えたかったこと • 文字コードは世界中の文化・芸術・経済・社会・政治を情報社 会に残していくためのインフラである ◦ 単なる情報技術ではなく、多様性との接点になっている ◦ 政治とも無関係ではない
481. © 2024 Wantedly, Inc. スポンサー 文字コードの維持に協力する方法 • Unicodeのスポンサーになる ◦ Unicodeでは「文字」に対してスポンサーをすることができる ◦ たとえば IBM は ☁ に対してスポンサーしている • 大企業の製品を使う ◦ IBM, Adobe, Apple 等、長くUnicodeに関与している企業を支援することも有用 • その他 ◦ ISOやJIS, IPSJ なども文字コードに関する仕事をしている
482. © 2024 Wantedly, Inc. まとめ • 過去から現在にかけての文字コードの進化を紹介した ◦ 文字コードは業界ごとに独自に発展してきた側面もあり、本当の意味で「満遍なく」紹介で きているわけではない ◦ オープンシステムやWebで使われている(使われていた)コードをターゲットに広く紹介す ることはできたと思う • その終着点として、Unicodeがいかにして現実の問題に取り 組んでいるかを紹介した
483. © 2024 Wantedly, Inc. 文献
484. © 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
485. © 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
486. © 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
487. © 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
488. © 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
489. © 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
490. © 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
491. © 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
492. © 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
493. © 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/
494. © 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
495. © 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
496. © 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
497. © 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
498. © 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
499. © 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