第3章：文字エンコーディングの理論 - 情報表現とテキスト処理の科学
導入：人類と符号化の歴史
文字を電気信号として表現するという問題は、コンピュータ以前から人類を悩ませてきました。ft_printfで%cや%sを実装する際、私たちは1830年代から続く符号化理論の系譜を継承しています。
この章では、文字符号化の歴史的発展を辿りながら、なぜ現代のコンピュータが特定の方法でテキストを処理するのかを深く理解します。その知識を基盤として、堅牢な文字・文字列処理を実装していきます。
---
第1部：電信から始まる符号化の歴史
1.1 モールス符号：可変長符号化の原点（1838年）
サミュエル・モールス（Samuel Morse）とアルフレッド・ヴェイル（Alfred Vail）が1838年に開発したモールス符号は、情報理論が存在する前に、驚くべき洞察を示していました。
モールス符号の設計原則：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
頻度順の符号長割り当て：
E = ・ （1単位） - 英語で最頻出
T = ─ （1単位）
A = ・─ （2単位）
I = ・・ （2単位）
N = ─・ （2単位）
...
Q = ─ ─・─ （4単位） - 稀に使用
J = ・─ ─ ─ （4単位）
これは後にシャノンとハフマンが理論化する
「最適符号化」の直感的な先取りでした。
この設計は、1948年にクロード・シャノン（Claude Shannon）が定式化した情報理論の基本原理を先取りしていました：
シャノンの情報量（エントロピー）：
H(X) = -Σ p(x) log₂ p(x)
ここで p(x) は文字 x の出現確率。
最適符号化の条件：
各記号の符号長 l(x) は理想的には -log₂ p(x) に比例すべき。
モールス符号は、印刷所の活字ケースを調査して
文字頻度を推定し、この原則を経験的に実現していた。
1.2 ボドー符号：固定長符号化への移行（1870年）
エミール・ボドー（Émile Baudot）は1870年に、電信の自動化のために5ビット固定長符号を開発しました。
ボドー符号の構造：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5ビット = 32通りの組み合わせ
問題：アルファベット26文字 + 数字10個 + 記号 > 32
解決策：シフト状態の導入
- LETTERS シフト：アルファベットモード
- FIGURES シフト：数字・記号モード
これはCapsLockやShiftキーの概念的先祖であり、
「状態を持つ符号化」の最初の例の一つ。
この「シフト状態」の概念は、後のASCIIにおける制御文字や、Unicodeにおける結合文字の先駆けとなりました。
1.3 テレタイプとASCIIへの道
20世紀初頭のテレタイプ（Teletype）は、様々な符号体系を使用していました：
主要なテレタイプ符号：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. ITA2（International Telegraph Alphabet No. 2）
- ボドー符号の国際標準版
- 5ビット、シフト方式
2. FIELDATA（1960年、米軍）
- 6ビット、64文字
- 大文字のみ
3. BCD（Binary Coded Decimal）
- 6ビット
- IBMメインフレーム用
問題点：
- 互換性がない
- 小文字が表現できない
- 制御文字が標準化されていない
---
第2部：ASCII - 現代文字符号化の基礎（1963年）
2.1 ASCII標準化の背景
1960年代初頭、コンピュータ間の通信における文字コードの混乱は深刻でした。アメリカ規格協会（ASA、後のANSI）はこの問題を解決するため、1963年にASCII（American Standard Code for Information Interchange）を策定しました。
ASCII設計委員会のメンバーと貢献：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
主要メンバー：
- Robert W. Bemer（IBMから参加、「ASCIIの父」）
- Hugh McGregor Ross
- Eric Fischer
主な設計決定：
1. 7ビット符号（128文字）
2. 制御文字と印字文字の分離
3. アルファベットの連続配置
4. 数字の連続配置
5. パリティビット用の1ビット予備
2.2 ASCIIの構造的設計
ASCIIの7ビット構造は、驚くほど計算に適した設計になっています：
ASCII構造（7ビット = 128コードポイント）：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ビットパターン分析：
b6 b5 b4 | b3 b2 b1 b0
─────────┼────────────
0 0 0│ 0000-1111 制御文字 (0x00-0x1F)
0 1 0│ 0000-1111 記号・数字 (0x20-0x2F)
0 1 1│ 0000-1111 数字・記号 (0x30-0x3F)
1 0 0│ 0000-1111 大文字 (0x40-0x4F)
1 0 1│ 0000-1111 大文字 (0x50-0x5F)
1 1 0│ 0000-1111 小文字 (0x60-0x6F)
1 1 1│ 0000-1111 小文字・DEL (0x70-0x7F)
天才的な設計ポイント：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 大文字と小文字の関係：
'A' = 0x41 = 0100 0001
'a' = 0x61 = 0110 0001
差分 = 0x20 = 第5ビットのみ
変換操作：
c | 0x20 → 小文字化
c & ~0x20 → 大文字化
c ^ 0x20 → 大小反転
2. 数字文字と数値の関係：
'0' = 0x30 = 0011 0000
'5' = 0x35 = 0011 0101
変換操作：
c - '0' → 数値取得
n + '0' → 文字化
3. 制御文字の規則性：
Ctrl+A = 0x01 = 'A' - 0x40
Ctrl+Z = 0x1A = 'Z' - 0x40
2.3 ASCII制御文字の設計思想
ASCII制御文字は、テレタイプの機械的動作を制御するために設計されました：
ASCII制御文字の分類：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
伝送制御（Communication Control）：
0x01 SOH (Start of Heading) ヘッダ開始
0x02 STX (Start of Text) テキスト開始
0x03 ETX (End of Text) テキスト終了
0x04 EOT (End of Transmission) 伝送終了
0x05 ENQ (Enquiry) 問い合わせ
0x06 ACK (Acknowledge) 肯定応答
0x15 NAK (Negative Acknowledge) 否定応答
書式制御（Format Control）：
0x08 BS (Backspace) 後退
0x09 HT (Horizontal Tab) 水平タブ
0x0A LF (Line Feed) 改行
0x0B VT (Vertical Tab) 垂直タブ
0x0C FF (Form Feed) 改ページ
0x0D CR (Carriage Return) 復帰
情報区切り（Information Separator）：
0x1C FS (File Separator) ファイル区切り
0x1D GS (Group Separator) グループ区切り
0x1E RS (Record Separator) レコード区切り
0x1F US (Unit Separator) ユニット区切り
特殊：
0x00 NUL (Null) 空文字
0x07 BEL (Bell) ベル音
0x1B ESC (Escape) エスケープ
0x7F DEL (Delete) 削除
NUL文字（0x00）の存在は、C言語の文字列設計に決定的な影響を与えました。
2.4 Robert Bemerの貢献
Robert W. Bemerは「ASCIIの父」と呼ばれ、多くの重要な決定に関わりました：
Bemerの主要な貢献：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. ESCキー（エスケープシーケンスの基盤）
- 将来の拡張性を確保
- ANSIエスケープシーケンスの基礎
2. バックスラッシュ（\）
- C言語のエスケープ文字として採用
- UNIXパス区切りとWindowsパス区切りの起源
3. 中括弧 { }
- ALGOL→C→現代言語のブロック記法
4. Y2K問題の警告（1958年）
- 2桁年表記の危険性を最初に指摘
---
第3部：8ビット時代と文字コードの混乱
3.1 拡張ASCIIとコードページ
ASCIIの7ビット設計は、8ビットバイトが標準になると、残りの128コードポイントの使用方法で混乱を招きました：
主要な拡張ASCII：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IBM PC（1981年）：
Code Page 437（DOS Latin US）
- 0x80-0xFF：罫線文字、アクセント付き文字、ギリシャ文字
ISO 8859シリーズ（1987年〜）：
ISO-8859-1（Latin-1）：西ヨーロッパ言語
ISO-8859-2（Latin-2）：東ヨーロッパ言語
ISO-8859-5：キリル文字
ISO-8859-6：アラビア語
ISO-8859-7：ギリシャ語
ISO-8859-8：ヘブライ語
ISO-8859-15（Latin-9）：ユーロ記号追加版
Windows：
CP-1252（Windows Latin-1）
- ISO-8859-1の亜種
- 0x80-0x9F：追加の印字文字
日本語：
JIS X 0201：カタカナ
JIS X 0208：漢字
Shift_JIS：混合符号化
EUC-JP：UNIX向け符号化
この混乱は「文字化け」という現象を生み出しました：
/* 文字化けの例 */
// ドイツ語テキスト（ISO-8859-1でエンコード）
const char *german = "Größe"; // 0x47 0x72 0xF6 0xDF 0x65
// 同じバイト列をISO-8859-2で解釈すると
// "Größe" → "Gr÷ße"（全く異なる文字に）
// Shift_JISで解釈すると
// 意味不明なテキストになる可能性
3.2 日本語エンコーディングの複雑さ
日本語の符号化は、特に複雑な歴史を持っています：
日本語文字集合の階層：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
JIS X 0201（1969年）：
- ローマ字（ASCII類似）
- 半角カタカナ（0xA1-0xDF）
JIS X 0208（1978年）：
- 第1水準漢字：2,965字
- 第2水準漢字：3,384字
- ひらがな、カタカナ、記号
- 合計約6,800文字
- 94×94の区点コード
JIS X 0212（1990年）：
- 補助漢字：5,801字
JIS X 0213（2000年、2004年改定）：
- 第3水準漢字：1,259字
- 第4水準漢字：2,436字
符号化方式：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ISO-2022-JP（JISコード）：
- エスケープシーケンスで文字集合切り替え
- 7ビット安全
- 電子メールで使用
Shift_JIS：
- 1バイト文字と2バイト文字の混在
- バイト値で判定可能
- Windowsで標準
EUC-JP：
- 各文字集合に固有の先頭バイト
- UNIXで標準
3.3 マルチバイト文字の問題
マルチバイト符号化は、C言語の文字列処理に深刻な問題をもたらしました：
/* Shift_JISの問題例 */
// "表" のShift_JIS表現
// 0x95 0x5C
// ↑ これは '\' (バックスラッシュ) と同じバイト値！
char *filename = "表示.txt"; // "表示" = 0x95 0x5C 0x8E 0xA6
// プログラムが '\' をエスケープ文字と誤認する可能性
// strlen()の問題
char *japanese = "日本語"; // Shift_JIS: 6バイト、3文字
size_t len = strlen(japanese); // 6を返す（文字数ではなくバイト数）
// 文字列操作の問題
char *s = "漢字";
s[0] = 'A'; // マルチバイト文字の途中を破壊
// 結果は文字化けまたは不正なバイト列
---
第4部：Unicode - 統一への道（1991年〜）
4.1 Unicodeの誕生
1987年、Xerox社のJoe BeckerとApple社のLee Collinsは、世界中の全ての文字を単一の符号体系で表現するという野心的なプロジェクトを開始しました。
Unicode設計原則：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 普遍性（Universal）
- 世界中の全ての文字を包含
2. 効率性（Efficient）
- 実装と処理が効率的
3. 統一性（Uniform）
- 固定幅解釈が可能（当初の16ビット設計）
4. 明確性（Unambiguous）
- 各コードポイントは一意に一つの文字を表す
5. 論理的順序（Logical Order）
- 文字は論理的順序で格納
6. 動的構成（Dynamic Composition）
- 結合文字による柔軟な表現
4.2 Unicodeの構造
当初の16ビット設計（65,536文字）では不十分であることがすぐに判明し、現在は21ビット空間（約110万コードポイント）に拡張されています：
Unicodeコードスペース：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
範囲：U+0000 〜 U+10FFFF（1,114,112コードポイント）
平面（Plane）構造：
Plane 0: BMP（Basic Multilingual Plane）
U+0000 - U+FFFF
- 最も一般的な文字
- ASCII、ラテン拡張、CJK統合漢字（一部）
Plane 1: SMP（Supplementary Multilingual Plane）
U+10000 - U+1FFFF
- 古代文字、絵文字、音楽記号
Plane 2: SIP（Supplementary Ideographic Plane）
U+20000 - U+2FFFF
- CJK統合漢字拡張B, C, D, E, F
Plane 3-13: 未使用（将来の拡張用）
Plane 14: SSP（Supplementary Special-purpose Plane）
U+E0000 - U+EFFFF
- タグ文字、バリエーションセレクタ
Plane 15-16: 私用領域（Private Use Area）
サロゲート領域（BMP内）：
U+D800 - U+DFFF：サロゲートペア用（UTF-16で使用）
この領域のコードポイントは文字に割り当てられない
4.3 UTF-8：Ken Thompsonの天才的設計（1992年）
UTF-8は、Plan 9オペレーティングシステムのために、Ken ThompsonとRob Pikeによって1992年に設計されました。その設計は、既存のシステムとの互換性を維持しながら、全てのUnicode文字を表現できる驚異的なものでした。
UTF-8の設計原則：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. ASCII互換性
- ASCII文字は1バイトでそのまま表現
- 既存のCプログラムの多くがそのまま動作
2. 自己同期性
- 任意の位置から文字境界を特定可能
- ストリーム途中からの解析が可能
3. バイト順非依存
- エンディアンに依存しない
4. NUL透過性
- 文字列中にNUL(0x00)が現れない（終端以外）
- C言語の文字列関数が使用可能
UTF-8のバイト構造：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コードポイント範囲 バイト数 バイト形式
U+0000 - U+007F 1バイト 0xxxxxxx
U+0080 - U+07FF 2バイト 110xxxxx 10xxxxxx
U+0800 - U+FFFF 3バイト 1110xxxx 10xxxxxx 10xxxxxx
U+10000 - U+10FFFF 4バイト 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
先頭バイトの判定：
0xxxxxxx (0x00-0x7F): 1バイト文字（ASCII）
110xxxxx (0xC0-0xDF): 2バイト文字の先頭
1110xxxx (0xE0-0xEF): 3バイト文字の先頭
11110xxx (0xF0-0xF7): 4バイト文字の先頭
10xxxxxx (0x80-0xBF): 継続バイト
エンコード例：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
'A' (U+0041):
コードポイント: 0x41 = 0100 0001
UTF-8: 0x41
バイナリ: 0100 0001
'é' (U+00E9):
コードポイント: 0xE9 = 1110 1001
UTF-8: 0xC3 0xA9
計算: 110 00011 10 101001
↑先頭 ↑継続
'日' (U+65E5):
コードポイント: 0x65E5 = 0110 0101 1110 0101
UTF-8: 0xE6 0x97 0xA5
計算: 1110 0110 10 010111 10 100101
'😀' (U+1F600):
コードポイント: 0x1F600 = 0001 1111 0110 0000 0000
UTF-8: 0xF0 0x9F 0x98 0x80
計算: 11110 000 10 011111 10 011000 10 000000
4.4 UTF-8の自己同期性
UTF-8の最も優れた特性の一つは、自己同期性です：
/* UTF-8の自己同期性の実証 */
// バイト列の任意の位置から文字境界を見つける
const char *find_char_start(const char *p) {
// 継続バイト（10xxxxxx）をスキップして先頭バイトを見つける
while ((*p & 0xC0) == 0x80)
p--;
return p;
}
// バイト列から次の文字の先頭を見つける
const char *next_char(const char *p) {
p++;
while ((*p & 0xC0) == 0x80)
p++;
return p;
}
// UTF-8文字のバイト数を取得
int utf8_char_len(unsigned char c) {
if ((c & 0x80) == 0x00) return 1; // 0xxxxxxx
if ((c & 0xE0) == 0xC0) return 2; // 110xxxxx
if ((c & 0xF0) == 0xE0) return 3; // 1110xxxx
if ((c & 0xF8) == 0xF0) return 4; // 11110xxx
return 0; // 不正なバイト（継続バイトまたは無効）
}
---
第5部：C言語における文字と文字列
5.1 char型の歴史的背景
C言語のchar型は、8ビットの整数型として設計されました。これはASCIIの7ビット + パリティビットという当時の標準的なバイト構造を反映しています。
/* char型の特性 */
// C標準による保証
// - char は少なくとも8ビット
// - sizeof(char) は常に1
// - CHAR_BIT は char のビット数（通常8）
#include <limits.h>
void char_properties(void)
{
printf("sizeof(char) = %zu\n", sizeof(char)); // 常に1
printf("CHAR_BIT = %d\n", CHAR_BIT); // 通常8
printf("CHAR_MIN = %d\n", CHAR_MIN); // -128または0
printf("CHAR_MAX = %d\n", CHAR_MAX); // 127または255
printf("SCHAR_MIN = %d\n", SCHAR_MIN); // -128
printf("SCHAR_MAX = %d\n", SCHAR_MAX); // 127
printf("UCHAR_MAX = %d\n", UCHAR_MAX); // 255
}
// charの符号は実装定義！
// - x86 Linux/macOS: signed char（デフォルト）
// - ARM: unsigned char（多くの場合）
// - コンパイラオプションで変更可能（-funsigned-char等）
5.2 Null終端文字列：設計と批判
C言語の文字列は、NUL文字（'\0'、0x00）で終端される文字配列として定義されています。この設計にはトレードオフがあります：
/* Null終端文字列の構造 */
// 文字列 "Hello" のメモリレイアウト
// +---+---+---+---+---+---+
// | H | e | l | l | o | \0|
// +---+---+---+---+---+---+
// 0x48 0x65 0x6C 0x6C 0x6F 0x00
// 長さの計算にはO(n)の走査が必要
size_t ft_strlen(const char *s)
{
const char *p = s;
while (*p)
p++;
return (p - s);
}
Null終端文字列の利点：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. メモリ効率
- 長さを格納する追加のフィールド不要
- 構造体ではなく単なる配列
2. 可変長への自然な対応
- 任意の長さの文字列を同じ型で表現
3. 部分文字列へのポインタ
- 文字列の途中へのポインタがそのまま文字列として機能
4. API のシンプルさ
- 関数は char* だけを受け取れば良い
Null終端文字列の欠点：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. O(n)の長さ計算
- 長さが必要な度に走査が必要
2. バイナリデータの格納不可
- データ内にNULを含められない
3. バッファオーバーフロー脆弱性
- 終端の欠如は即セキュリティホール
4. 非効率な連結
- 連結には両文字列の走査が必要
5.3 Dennis Ritchieの設計判断
Dennis RitchieがC言語でNull終端を選択した理由について、彼自身が述べています：
「BCPL（Cの先祖言語）では、文字列は先頭に
長さを持つパック配列として表現されていた。
しかし、文字列リテラルの動的な取り扱いと、
限られたメモリ環境での効率を考慮し、
ゼロ終端を採用した。
当時のマシンでは、追加の長さフィールドは
貴重なメモリを消費した。また、PDP-7の
アセンブリ言語との相互運用も考慮した。」
— Dennis Ritchie（意訳）
---
第6部：文字分類とロケール
6.1 ctype.hの関数群
ASCII時代に設計された
/* ctype.h の主要関数 */
#include <ctype.h>
// 文字分類関数
int isalpha(int c); // アルファベットか
int isdigit(int c); // 数字か（0-9）
int isalnum(int c); // アルファベットまたは数字か
int isspace(int c); // 空白文字か
int isupper(int c); // 大文字か
int islower(int c); // 小文字か
int isprint(int c); // 印字可能文字か
int iscntrl(int c); // 制御文字か
int isxdigit(int c); // 16進数字か（0-9, a-f, A-F）
int ispunct(int c); // 句読点か
int isgraph(int c); // 可視文字か（空白を除く印字可能文字）
// 文字変換関数
int toupper(int c); // 大文字に変換
int tolower(int c); // 小文字に変換
これらの関数の引数がcharではなくintである理由は重要です：
/* ctype.hがintを使用する理由 */
// 1. EOFの表現
// getchar()はEOF（通常-1）を返す可能性がある
int c;
while ((c = getchar()) != EOF) {
if (isalpha(c))
// ...
}
// 2. 符号付きcharの問題
// signed char の負の値（0x80-0xFF）は
// int に昇格すると負の値になる
char c = '\xff'; // signed charでは-1
if (isprint(c)) // 未定義動作の可能性！
// ...
// 正しい使用法
if (isprint((unsigned char)c))
// ...
// 3. 引数の範囲
// ctype関数の引数は、unsigned char で表現可能な値
// または EOF でなければならない（C標準による）
6.2 ロケールと文字分類
ロケール設定により、ctype関数の動作は変化します：
/* ロケール依存の文字分類 */
#include <locale.h>
#include <ctype.h>
void locale_example(void)
{
// デフォルト（C/POSIX）ロケール
setlocale(LC_ALL, "C");
printf("isalpha('é') in C locale: %d\n", isalpha((unsigned char)'é'));
// 結果: 0（アルファベットではない）
// フランス語ロケール
setlocale(LC_ALL, "fr_FR.UTF-8");
printf("isalpha('é') in French locale: %d\n", isalpha((unsigned char)'é'));
// 結果: 非ゼロ（アルファベットとして認識）
}
---
第7部：ft_printfにおける文字・文字列処理の実装
7.1 %c（文字出力）の実装
理論的基礎を理解した上で、%cの実装に取り組みます：
/* 文字出力の実装 */
#include "ft_printf.h"
/**
* 可変引数からの文字取得
*
* 重要：va_arg(args, char) ではなく va_arg(args, int) を使用
*
* 理由：デフォルト引数昇格により、char は int に昇格される
* （第1章で解説した通り）
*/
static char get_char_arg(va_list args)
{
return ((char)va_arg(args, int));
}
/**
* 単一文字の出力
*
* @param c 出力する文字
* @return 出力したバイト数（常に1）
*
* 注意：writeシステムコールは、NUL文字(0x00)も
* 正しく出力する。printfと同様の動作。
*/
int print_char_simple(char c)
{
return (write(1, &c, 1));
}
/**
* パディング文字列の出力
*
* @param width パディング幅
* @param c パディング文字（通常は空白）
* @return 出力したバイト数
*/
int print_padding(int width, char c)
{
int count;
count = 0;
while (width > 0)
{
count += write(1, &c, 1);
width--;
}
return (count);
}
/**
* フラグ対応の文字出力
*
* 対応フラグ：
* - 幅指定：最小出力幅
* - '-'：左揃え
*
* 非対応（%cでは無視）：
* - '0'：ゼロパディング
* - 精度：文字には意味がない
*/
int print_char(char c, t_flags *flags)
{
int count;
int padding_width;
count = 0;
/* パディング幅の計算 */
padding_width = flags->width - 1;
if (padding_width < 0)
padding_width = 0;
if (flags->minus)
{
/* 左揃え：文字 → パディング */
count += write(1, &c, 1);
count += print_padding(padding_width, ' ');
}
else
{
/* 右揃え：パディング → 文字 */
count += print_padding(padding_width, ' ');
count += write(1, &c, 1);
}
return (count);
}
7.2 %s（文字列出力）の実装
文字列出力は、NULL処理と精度制限が重要です：
/* 文字列出力の実装 */
/**
* 精度を考慮した文字列長の計算
*
* @param str 文字列
* @param precision 精度（負の場合は無制限）
* @return 実際に出力すべきバイト数
*
* 注意：この関数はバイト数を返す。
* UTF-8文字列の場合、文字数とは異なる。
*/
static int get_print_len(const char *str, int precision)
{
int len;
len = 0;
while (str[len])
{
if (precision >= 0 && len >= precision)
break;
len++;
}
return (len);
}
/**
* NULL文字列の処理
*
* C標準では、%sにNULLを渡した場合の動作は未定義。
* しかし、多くの実装（glibc等）は "(null)" を出力する。
* ft_printfもこの慣例に従う。
*/
static const char *handle_null_string(const char *str)
{
if (str == NULL)
return ("(null)");
return (str);
}
/**
* 文字列出力の完全実装
*
* @param str 出力する文字列（NULLの場合は "(null)" を出力）
* @param flags フォーマットフラグ
* @return 出力したバイト数
*
* 処理順序：
* 1. NULL文字列の処理
* 2. 精度による出力長の制限
* 3. パディング幅の計算
* 4. フラグに基づく出力順序の決定
*/
int print_string(const char *str, t_flags *flags)
{
int count;
int print_len;
int padding;
count = 0;
/* NULL処理 */
str = handle_null_string(str);
/* 出力長の決定 */
print_len = get_print_len(str, flags->precision);
/* パディング幅の計算 */
padding = flags->width - print_len;
if (padding < 0)
padding = 0;
/* 出力 */
if (flags->minus)
{
/* 左揃え */
count += write(1, str, print_len);
count += print_padding(padding, ' ');
}
else
{
/* 右揃え */
count += print_padding(padding, ' ');
count += write(1, str, print_len);
}
return (count);
}
7.3 %%（パーセント出力）の実装
エスケープシーケンスとしての%%：
/* パーセント記号の出力 */
/**
* パーセント記号の出力
*
* %% は「%を出力せよ」という指示。
* 多くの実装ではフラグを無視するが、
* 一部の実装（GNU printf等）は幅指定を尊重する。
*
* ft_printf基本要件：単に '%' を1文字出力
*/
int print_percent(void)
{
return (write(1, "%", 1));
}
/**
* 幅指定対応版（ボーナス実装用）
*/
int print_percent_with_flags(t_flags *flags)
{
int count;
int padding;
count = 0;
padding = flags->width - 1;
if (padding < 0)
padding = 0;
if (flags->minus)
{
count += write(1, "%", 1);
count += print_padding(padding, ' ');
}
else
{
count += print_padding(padding, ' ');
count += write(1, "%", 1);
}
return (count);
}
---
第8部：セキュリティ考慮事項
8.1 バッファオーバーフローと文字列
文字列処理は、セキュリティ脆弱性の主要な原因です：
/* 危険なパターンと安全な代替 */
// 危険：境界チェックなし
void dangerous_copy(char *dest, const char *src)
{
while (*src)
*dest++ = *src++;
*dest = '\0';
// destの容量を超える可能性
}
// 安全：境界チェックあり
void safe_copy(char *dest, const char *src, size_t dest_size)
{
size_t i;
if (dest_size == 0)
return;
i = 0;
while (i < dest_size - 1 && src[i])
{
dest[i] = src[i];
i++;
}
dest[i] = '\0';
}
8.2 書式文字列攻撃への対策
書式文字列攻撃は、ユーザー入力を書式文字列として使用する際に発生します：
/* 書式文字列攻撃の例 */
// 脆弱なコード
void vulnerable(const char *user_input)
{
printf(user_input); // 危険！
// user_input が "%s%s%s%s%s" の場合、スタック内容を読み取れる
// user_input が "%n" を含む場合、メモリに書き込める
}
// 安全なコード
void safe(const char *user_input)
{
printf("%s", user_input); // user_inputはデータとして扱われる
}
// ft_printf実装時の考慮
// - ユーザー入力を直接書式文字列として使用しない
// - %n 指定子は実装しない（42課題では不要かつ危険）
8.3 NUL文字とセキュリティ
NUL文字は、文字列処理でセキュリティ問題を引き起こすことがあります：
/* NUL文字インジェクション */
// 問題のシナリオ
void file_extension_check(const char *filename)
{
// ユーザーが "malware.exe\0.txt" を入力
const char *ext = strrchr(filename, '.');
if (strcmp(ext, ".txt") == 0)
{
// 安全と判断して処理
// しかし実際のファイル名は "malware.exe"
process_file(filename);
}
}
// 対策：文字列全体の長さと内容を検証
---
第9部：パフォーマンス最適化
9.1 システムコールのオーバーヘッド
writeシステムコールは比較的高コストな操作です：
/* システムコールオーバーヘッドの理解 */
// 非効率：1文字ずつwrite
int slow_print_string(const char *str)
{
int count = 0;
while (*str)
{
write(1, str++, 1); // 各文字でシステムコール
count++;
}
return count;
}
// 効率的：まとめてwrite
int fast_print_string(const char *str)
{
size_t len = strlen(str);
return write(1, str, len); // 1回のシステムコール
}
// システムコールの内部処理：
// 1. ユーザーモード → カーネルモード遷移
// 2. カーネル内でのバッファ処理
// 3. カーネルモード → ユーザーモード復帰
// この遷移は数百〜数千CPUサイクルを消費
9.2 バッファリング戦略
効率的な出力のためにバッファリングを実装します：
/* 内部バッファリングの実装 */
#define PRINTF_BUFFER_SIZE 4096
typedef struct s_buffer
{
char data[PRINTF_BUFFER_SIZE];
int pos;
int total;
} t_buffer;
/* バッファ初期化 */
void buffer_init(t_buffer *buf)
{
buf->pos = 0;
buf->total = 0;
}
/* バッファフラッシュ */
int buffer_flush(t_buffer *buf)
{
int written;
if (buf->pos == 0)
return (0);
written = write(1, buf->data, buf->pos);
if (written > 0)
buf->total += written;
buf->pos = 0;
return (written);
}
/* バッファに1文字追加 */
void buffer_putchar(t_buffer *buf, char c)
{
if (buf->pos >= PRINTF_BUFFER_SIZE)
buffer_flush(buf);
buf->data[buf->pos++] = c;
}
/* バッファに文字列追加 */
void buffer_putstr(t_buffer *buf, const char *str, int len)
{
int i;
i = 0;
while (i < len)
{
if (buf->pos >= PRINTF_BUFFER_SIZE)
buffer_flush(buf);
buf->data[buf->pos++] = str[i++];
}
}
9.3 パディングの最適化
パディング出力も最適化できます：
/* 最適化されたパディング */
// 静的バッファを使用
static const char spaces[] =
" " // 32スペース
" "; // 32スペース = 計64
static const char zeros[] =
"00000000000000000000000000000000" // 32ゼロ
"00000000000000000000000000000000"; // 32ゼロ = 計64
int print_padding_optimized(int width, char c)
{
const char *pad;
int written;
int chunk;
if (width <= 0)
return (0);
pad = (c == '0') ? zeros : spaces;
written = 0;
while (width > 0)
{
chunk = (width > 64) ? 64 : width;
written += write(1, pad, chunk);
width -= chunk;
}
return (written);
}
---
第10部：テストと検証
10.1 体系的なテストケース
/* 包括的なテストスイート */
#include <stdio.h>
#include <string.h>
/* テスト結果の比較 */
int compare_printf(const char *format, ...)
{
va_list args1, args2;
int ret1, ret2;
char buf1[1024], buf2[1024];
va_start(args1, format);
va_start(args2, format);
// 出力をキャプチャして比較
// （簡略化のため、戻り値のみ比較）
ret1 = ft_printf(format, args1);
ret2 = printf(format, args2);
va_end(args1);
va_end(args2);
return (ret1 == ret2);
}
/* %c のテスト */
void test_char_specifier(void)
{
printf("=== %c Tests ===\n");
/* 基本文字 */
ft_printf("[%c]\n", 'A');
printf("[%c]\n", 'A');
/* 数字として渡された文字 */
ft_printf("[%c]\n", 65); // 'A'
printf("[%c]\n", 65);
/* NUL文字 */
ft_printf("[%c]\n", '\0');
printf("[%c]\n", '\0');
/* 幅指定 */
ft_printf("[%5c]\n", 'X');
printf("[%5c]\n", 'X');
/* 左揃え */
ft_printf("[%-5c]\n", 'X');
printf("[%-5c]\n", 'X');
/* 拡張ASCII（128-255）*/
ft_printf("[%c]\n", 200);
printf("[%c]\n", 200);
}
/* %s のテスト */
void test_string_specifier(void)
{
printf("=== %s Tests ===\n");
/* 通常の文字列 */
ft_printf("[%s]\n", "Hello, World!");
printf("[%s]\n", "Hello, World!");
/* 空文字列 */
ft_printf("[%s]\n", "");
printf("[%s]\n", "");
/* NULL文字列 */
ft_printf("[%s]\n", (char *)NULL);
printf("[%s]\n", (char *)NULL);
/* 精度指定 */
ft_printf("[%.5s]\n", "Hello, World!");
printf("[%.5s]\n", "Hello, World!");
/* 精度0 */
ft_printf("[%.0s]\n", "Hello");
printf("[%.0s]\n", "Hello");
/* 幅指定 */
ft_printf("[%10s]\n", "Hi");
printf("[%10s]\n", "Hi");
/* 左揃え + 幅 */
ft_printf("[%-10s]\n", "Hi");
printf("[%-10s]\n", "Hi");
/* 幅 + 精度 */
ft_printf("[%10.3s]\n", "Hello");
printf("[%10.3s]\n", "Hello");
/* 左揃え + 幅 + 精度 */
ft_printf("[%-10.3s]\n", "Hello");
printf("[%-10.3s]\n", "Hello");
/* NULL + 精度 */
ft_printf("[%.3s]\n", (char *)NULL);
printf("[%.3s]\n", (char *)NULL);
/* NULL + 幅 + 精度 */
ft_printf("[%10.3s]\n", (char *)NULL);
printf("[%10.3s]\n", (char *)NULL);
}
/* %% のテスト */
void test_percent_specifier(void)
{
printf("=== %% Tests ===\n");
/* 単一 */
ft_printf("[%%]\n");
printf("[%%]\n");
/* 連続 */
ft_printf("[%%%%]\n");
printf("[%%%%]\n");
/* 他の指定子と混合 */
ft_printf("[%d%%]\n", 100);
printf("[%d%%]\n", 100);
}
10.2 エッジケースのテスト
/* エッジケーステスト */
void test_edge_cases(void)
{
printf("=== Edge Cases ===\n");
/* 非常に長い文字列 */
char long_str[10000];
memset(long_str, 'A', 9999);
long_str[9999] = '\0';
int ret1 = ft_printf("%.100s\n", long_str);
int ret2 = printf("%.100s\n", long_str);
printf("Returns: %d vs %d\n", ret1, ret2);
/* 大きな幅指定 */
ft_printf("[%1000c]\n", 'X');
printf("[%1000c]\n", 'X');
/* UTF-8文字列（バイト単位で処理される）*/
ft_printf("[%s]\n", "日本語");
printf("[%s]\n", "日本語");
/* UTF-8と精度（バイト単位で切れる可能性）*/
ft_printf("[%.3s]\n", "日本語"); // 不完全なUTF-8になりうる
printf("[%.3s]\n", "日本語");
/* 特殊文字を含む文字列 */
ft_printf("[%s]\n", "Tab:\tNewline:\n");
printf("[%s]\n", "Tab:\tNewline:\n");
/* 最大値に近い幅 */
ft_printf("[%2147483647c]\n", 'X'); // INT_MAX
// 実装によっては問題が発生
}
---
まとめ：文字符号化の統一的理解
この章では、以下の知識を統合しました：
歴史的発展：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1838年 モールス符号 - 可変長符号化の原点
1870年 ボドー符号 - 固定長符号化への移行
1963年 ASCII - 7ビット標準の確立
1987年 ISO-8859 - 8ビット拡張の混乱
1991年 Unicode - 統一への道
1992年 UTF-8 - 互換性を保った解決
技術的理解：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- ASCIIの計算しやすい設計（ビット操作による変換）
- Null終端文字列のトレードオフ
- UTF-8の自己同期性と後方互換性
- ctype関数の正しい使用法
実装への応用：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- %c：デフォルト引数昇格を考慮した実装
- %s：NULL処理と精度制限の正確な実装
- %%：エスケープシーケンスの処理
- バッファリングによる最適化
セキュリティ考慮：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- バッファオーバーフローの防止
- 書式文字列攻撃への対策
- NULインジェクションへの認識
次章では、整数の表現理論（2の補数、エンディアン）と、%d、%i、%uの実装について深く掘り下げます。数値から文字列への変換アルゴリズムと、効率的な実装技法を学びます。