hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
データベース ストレージ
データベースストレージは、データベースの物理的な実体の格納庫である。これは、データベースアーキテクチャの「内部（物理）レベル」を構成する。また、必要に応じて「内部レベル」から「概念レベル」や「外部レベル」を再構築するために必要なすべての情報（たとえばメタデータ、「データに関するデータ」、内部データ構造など）も含んでいる。デジタル・オブジェクトとしてのデータベースには、データ、構造、セマンティクス（意味）の3つの層からなる情報が含まれ、保存する必要がある。長期間に渡ってデータベースを保存し、長持ちさせるために、3つの層すべてを適切に保存する必要がある。データを永続的ストレージに保存するのは、一般に、データベースエンジン（別名「ストレージエンジン」）の責任である。DBMSは通常、基盤となるオペレーティングシステムを通じてアクセスするが（多くの場合、オペレーティングシステムのファイルシステムを、ストレージ配置の仲介役として使用する）、ストレージの特性と構成設定はDBMSの効率的な運用に極めて重要であるため、データベース管理者によって密接に管理される。DBMSは、その運用中に、常に数種類のストレージ（メモリや外部ストレージ）にデータベースを常駐させている。データベースのデータと、追加の必要な情報（おそらく非常に大量にある）は、ビット列に符号化される。データは通常、概念レベルや外部レベルでの見え方とは全く異なる構造でストレージ内に存在するが、ユーザーやプログラムが必要とするとき、または必要な情報の追加形式をデータから計算するとき（例: データベースに問い合わせる時）、これらのレベルの再構築を（可能な限り）最適化するような方法で格納される。
データベース ストレージ
DBMSの中には、データの格納に用いる文字エンコーディングを指定できるものがあり、同じデータベースで複数のエンコーディングを使用することができる。
データモデルをシリアル化し、選ばれた媒体に書き込めるようにするために、ストレージエンジンは、さまざまな低レベルのデータベースストレージ構造を使用する。性能を向上させるために、インデックス作成などの手法を使用することもある。従来のストレージは行指向であるが、列指向データベースや相関データベース (en:英語版) もある。
性能を向上させるためにストレージを冗長化することがよくある。一般的な例は、頻繁に必要とされる外部ビュー（external view）や、クエリ結果から構成されるマテリアライズド・ビュー（materialized view）の保存である。このようなビューを保存することで、必要になるたびに計算する費用を節約することができる。マテリアライズド・ビューの欠点は、元の更新されたデータベースデータと同期を維持するためにビューを更新する際に発生するオーバーヘッドと、ストレージの冗長化にかかる費用である。
データベース ストレージ
データベースは、データの可用性を向上させるために、データベース・オブジェクトの複製（1つ以上のレプリケーション）によるストレージ冗長性を採用することがある。これによって、同じデータベース・オブジェクトに複数のエンドユーザーが同時アクセスした場合の性能を向上させ、また、分散データベースに部分的な障害が発生した場合の回復力を提供する。複製されたオブジェクトの更新には、オブジェクトのコピー間で同期される必要がある。多くの場合、データベース全体が複製される。
データベース セキュリティ
データベース・セキュリティは、データベースの内容、その所有者、およびそのユーザーを保護するためのあらゆる側面を扱う。その範囲は、意図的な不正なデータベースの使用から、権限のないエンティティ（たとえば、人やコンピュータプログラムなど）による意図しないデータベースへのアクセスまで、さまざまな保護に及ぶ。
データベースアクセス制御は、データベース内のどの情報に誰が（人間または特定のコンピュータプログラム）アクセスを許可されるかを制御することを扱う。その情報には、特定のデータベースオブジェクト（例: レコード種類、特定レコード、データ構造）、特定のオブジェクトに対する特定の計算（例: クエリ種類、特定のクエリ）、または前者に対する特定のアクセス経路の使用（例: 情報にアクセスするために特定のインデックスまたは他のデータ構造の使用）が含まれる。データベースのアクセス制御は、データベース所有者から特別に許可された人員によって、保護された専用のセキュリティDBMSインターフェースを用いて設定される。
データベース セキュリティ
アクセス制御の管理は、個人別に直接行うことも、個人と特権をグループに割り当てることも、（最も精巧なモデルでは）個人やグループにロール（役割）を割り当ててからロールに権限を付与することもできる。データセキュリティは、権限のないユーザーによるデータベースの閲覧や更新を阻止する。パスワードを使用すると、ユーザーはデータベース全体、または「サブスキーマ」と呼ばれる一部分へのアクセスを許可される。たとえば、従業員データベースには個々の従業員に関するすべてのデータを含めていても、あるグループのユーザーには給与データのみの閲覧を許可し、別のグループには職歴と医療データのみアクセスを許可することが可能である。DBMSがデータベースの入力、更新、問い合わせを対話的に行う方法を提供している場合、この機能によって個人データベースを管理することができる。
一般にデータセキュリティは、特定のデータチャンク（data chunk、塊）を物理的に保護すること（すなわち破損、破壊、削除から。物理的セキュリティを参照）、または、データチャンクやその一部を意味のある情報に変換すること（例: それらが構成するビット列を見て、特定の有効なクレジットカード番号を決定する。データ暗号化を参照）の両方を扱う。
データベース セキュリティ
変更およびアクセスのロギングは、誰がどの属性にアクセスしたか、何が変更されたか、そしていつ変更されたかを記録する。ロギングサービスは、アクセスの発生や変更の記録を保持することで、後でフォレンジックデータベース監査を行うことを可能にする。場合によっては、データベースレベルで記録するのではなく、アプリケーションレベルのコードで変更を記録することもある。セキュリティ違反の検出を試みるために監視を設定することもできる。データベース・セキュリティには多くの利点があるため、組織はこれに真剣に取り組む必要がある。組織は、ファイアウォール内への侵入、ウィルスの蔓延、ランサムウェアなどのセキュリティ違反やハッキング行為から守られる。これは、企業において、いかなる理由があっても部外者と共有することが許されない、重要な情報を保護するために役に立つ。
データベース トランザクションと同時並行
データベース・トランザクションは、クラッシュ（障害）からの復旧後に、ある程度の耐障害性とデータ完全性を導入するために使用することができる。データベーストランザクションは通常、データベースに対する一連の操作（データベースオブジェクトの読み込み、書き込み、ロックの取得や解放など）をカプセル化した作業の単位であり、データベースやその他のシステムでサポートされている抽象概念である。各トランザクションには、どのプログラム／コードの実行がそのトランザクションに含まれるかという点で、明確に定義された境界がある（トランザクションの設計者が、特別なトランザクションコマンドで決定する）。
ACIDという頭字語は、データベーストランザクションの理想的な特性である、原子性（atomicity）、一貫性（consistency）、分離性（isolation）、永続性（durability）を表している。
データベース 移行
あるDBMSで構築されたデータベースは、別のDBMSに移植できない（つまり、別のDBMSでは実行できない）。しかし、状況によっては、あるDBMSから別のDBMSにデータベースを移行（database migration）するのが望ましい場合がある。その理由は、主に経済的（DBMS によって総所有コスト（TCO）が異なる）、機能的、および運用的（DBMSによって機能が異なることがある）である。移行には、あるDBMSの種類から別の種類へデータベースを変換することも含まれる。この変換では、（可能であれば）データベース関連のアプリケーション（つまり、関連するすべてのアプリケーションプログラム）をそのまま維持する必要がある。したがって、データベースの概念レベルおよび外部レベルのアーキテクチャは、変換時に維持する必要がある。また、アーキテクチャの内部レベルのいくつかの側面も維持されることが望まれる場合もある。複雑または大規模なデータベースの移行は、それ自体が複雑で費用のかかる（1度きりの）プロジェクトになる可能性があるので、移行を決定するときはその点を考慮する必要がある。これは、特定のDBMS間の移行を支援するツールが存在する可能性があるのにも関わらない。一般に、DBMSベンダーは、他の普及しているDBMSからデータベースをインポートするツールを提供している。
データベース 構築、保守、およびチューニング
アプリケーションのデータベースを設計したら、次の段階はデータベースの構築である。通常、この用途で用いるために、適切な汎用DBMSを選択することができる。DBMSは、データベース管理者が必要なアプリケーションのデータ構造をDBMSの各データモデルに準じて定義するために必要なユーザーインタフェースを提供する。その他のユーザーインタフェースは、必要なDBMSパラメータ（セキュリティ関連、ストレージ割り当てパラメータなど）を選択するために用いられる。
データベースの準備が整うと（データ構造およびその他の必要なコンポーネントがすべて定義される）、通常は、運用を開始する前にアプリケーションの初期データを入力する（データベースの初期化は、通常は別プロジェクトとされ、多くの場合、一括挿入をサポートする専用のDBMSインターフェースを用いる）。場合によっては、アプリケーションのデータを持たない状態でデータベースが稼働し、その運用を経てデータが蓄積されることもある。
データベース 構築、保守、およびチューニング
データベースを作成し、初期化し、データを入力した後は、データベースを維持する必要がある。たとえば、より良い性能を得るために、さまざまなデータベース・パラメータを変更し、データベースをチューニングする必要があるかもしれない。あるいは、アプリケーションの機能を追加するために、アプリケーションのデータ構造を変更または追加し、新しい関連アプリケーションプログラムを作成するかもしれない。
データベース バックアップと復元
場合によっては、データベースを以前の状態に戻すことが必要となる（たとえばソフトウェアの誤りが原因でデータベースが破損していることが判明した場合や、誤ったデータで更新された場合など、さまざまな理由が考えられる）。そのために、バックアップ操作が時々または継続的に実施され、それぞれの望ましいデータベースの状態（すなわち、データ値とデータベースのデータ構造への埋め込み）が専用のバックアップファイルに保持される（これを効果的に行うための多くの技術が存在する）。データベース管理者がデータベースをこの状態に戻すと決めたとき（たとえば、データベースがこの状態にあった時、所望の時点を指定する）、これらのファイルをその状態を復元するために使用する。
データベース 静的解析
ソフトウェア検証のための静的解析技術は、クエリ言語の領域にも適用することができる。特に、抽象解釈フレームワークは、適切な近似技術をサポートする方法として、リレーショナルデータベースのクエリ言語の分野に拡張されている。クエリ言語のセマンティクスは、データの具体的な領域（ドメイン）を適切に抽象化することによって調整することができる。リレーショナルデータベースシステムの抽象化は、特に、細粒度アクセス制御や、電子透かしなどのセキュリティ分野で、多くの興味深い応用がある。
データベース その他の機能
DBMSのその他の機能として、次のようなものもあげられる。
データベース設計、アプリケーションプログラミング、アプリケーションプログラムの保守、データベース性能分析および監視、データベース構成監視、DBMSハードウェア構成（DBMSや関連データベースはコンピュータ、ネットワーク、ストレージ装置にまたがる場合がある）および関連するデータベースマッピング（特に分散DBMS）、ストレージ割り当てとデータベースレイアウトの監視、ストレージ移行のためのツールまたはフック。
データベース管理とソース管理のために、ビルド、テスト、デプロイメントフレームワークに、これらの中心機能をすべて組み込んだ単一システムを求める声はますます高まっている。ソフトウェア業界における別の進化を借りて、そうした製品を「データベース用DevOps」として提供する企業もある。
データベース 設計とモデリング
データベース設計者の最初の作業は概念データモデル (en:英語版) の作成で、データベースに保持する情報の構造を反映する。そのための一般的な方法は、描画ツールを用いて実体関連モデルを作成することが多い。統一モデリング言語（UML）の使用は、もう一つのよく知られた方法である。出来のよいデータモデルは、モデル化される外界の可能な状態を正確に反映する。たとえば、人々が複数の電話番号を持つことができる場合、その情報を取得することが可能となる。優れた概念データモデルを設計するには、アプリケーションの領域を十分に理解する必要がある。それには、一般的に、組織が関心を持っていることについて深い問いを立てる必要がある。たとえば「顧客は発注先にもなり得るのか?」、あるいは「ある製品が2種類の包装形態で販売されている場合、それらは同じ製品か、それとも異なる製品なのか?」、あるいは「飛行機がニューヨークからフランクフルト経由でドバイまで飛ぶ場合、それは1便か2便か（または3便か）?」のような質問をする。これらの質問に対する回答によって、エンティティ（顧客、製品、フライト、フライト区間）に使用される用語の定義、およびそれらの関係や属性を確立する。
データベース 設計とモデリング
概念データモデルを作成する過程で、ビジネスプロセスからの入力や、組織内のワークフロー分析からの入力が必要な場合がある。これによって、データベースにどのような情報が必要で、何を省略できるかを特定することができる。たとえば、データベースに現在のデータだけでなく、過去の履歴データも保持する必要があるかどうかを決定するのに役立つ。
ユーザーが満足できる概念データモデルを作成したら、次の段階では、これをデータベース内の関連データ構造を実装するスキーマに変換する必要がある。この過程は、しばしば論理データベース設計と呼ばれ、スキーマの形で表現された論理データモデルを作成する。概念データモデルがデータベース技術の選択と関係しないのに対し（少なくとも理論的には）、論理データモデルは、選択したDBMSがサポートする特定のデータベースモデルの観点で表現される。（データモデルとデータベースモデルという用語はしばしば同じ意味で用いられるが、この記事では特定のデータベースの設計を「データモデル」、その設計を表現するために用いられるモデリング表記を「データベースモデル」とそれぞれ呼ぶ。）
データベース 設計とモデリング
汎用データベースで最も普及しているデータベースモデルはリレーショナルモデル、より正確には、SQL言語で表現されるリレーショナルモデルである。このモデルを用いて論理データベースを設計する過程では、正規化と呼ばれる系統的アプローチが用いられる。正規化の目的は、挿入、更新、削除の一貫性を自然に維持することで、おのおのの基本的「事実」を一箇所にのみ記録することでなされる。
データベース設計の最終段階では、特定のDBMSに依存する性能、スケーラビリティ、回復、セキュリティなどに影響する決定をする。これはしばしば「物理データベース設計」と呼ばれ、物理データモデルを作成する。この段階での重要な目標はデータの独立性である。これは、性能を最適化するために行われた決定を、エンドユーザーやアプリケーションから見えないようにすることを意味する。データの独立性には2つのタイプがあり、物理的なデータ独立性と論理的なデータ独立性である。物理設計は主に性能要件によって推進され、予想される作業負荷とアクセスパターンに関する十分な知識と、選択したDBMSが持つ機能についての深い理解を必要とする。
物理データベース設計のもうひとつの側面はセキュリティである。これには、データベースオブジェクトへのアクセス制御を定義することと、データ自体のセキュリティレベルとメソッド（手順）の定義の両方を含んでいる。
データベース 設計とモデリング
データベースモデルとは、データベースの論理構造を決定するデータモデルの一種で、データをどのように格納、整理、操作するかの根本を規定するものである。データベースモデルの最も一般的な例は、テーブルベースの形式を使用するリレーショナルモデル（またはリレーションを近似したSQL）である。
データベースの一般的な論理データモデルを次にあげる。
オブジェクトリレーショナルデータベースは、この2つの関連する構造を組み合わせたものである。
物理データモデルを次にあげる。
その他、次のようなモデルがある。
特定の種類のデータ用に最適化された特殊モデルがある。
データベース管理システムは、データベースのデータに対して三層のビューを提供する。
データベース 設計とモデリング
内部レベル（internal level）または物理レベル（physical level）とは、DBMS内におけるデータの内部編成のことである。これは費用、性能、スケーラビリティ、その他の運用上の事項に関与している。このレベルでは、データの記憶領域配置を扱い、性能を向上させるためにインデックス（索引）などの格納構造を用いる。冗長性に対する性能上の正当性が認められる場合は、一般的なデータから計算された個々のビュー（マテリアライズド・ビュー）のデータを格納することもある。すべての活動において、全体的な性能を最適化するために、すべての外部ビューの性能要件（競合する可能性のある）の間でバランスをとる。
データの概念ビュー（または論理ビュー）および物理ビュー（または内部ビュー）は、通常、1つしかないが、さまざまな外部ビューはいくつでも存在することができる。これにより、ユーザーは、技術的あるいは処理的な視点からではなく、よりビジネスに関連した視点からデータベース情報を見ることができるようになる。たとえば、企業の財務部門は会社の経費の一部として全従業員の支払明細を必要とするが、人事部門の関心事である従業員に関する明細は必要ない。このように、部門によって、企業データベースには異なるビューが必要となる。
データベース 設計とモデリング
三層データベース・アーキテクチャは、リレーショナルモデルの主要な初期推進力の1つであったデータの独立性の概念に関連している。この考え方は、あるレベルで行われた変更は、より高いレベルのビューに影響を与えないというものである。たとえば、内部レベルの変更は、概念レベルのインターフェースを使用して記述されたアプリケーションプログラムには影響しないので、性能を向上させるために物理的変更を加えてもその影響を軽減することができる。
概念ビューは、内部ビューと外部ビューの間に間接的なレベルを提供する。一方では、異なる外部ビュー構造に依存しないデータベースの共通ビューを提供し、また他方では、データがどのように格納され管理されるかという詳細（内部レベル）を抽象化する。原則として、すべてのレベルの、さらにはすべての外部ビューは、異なるデータモデルで表現することができる。実際には通常、特定のDBMSは外部レベルと概念レベルの両方で同じデータモデルを使用する（例: リレーショナルモデル）。内部レベルは特定のDBMSの内側に隠されており、（その実装にも依存するが）異なるレベルの詳細が要求され、独自の種類のデータ構造型が用いられる。
外部、概念、および内部レベルを分離することは、21世紀のデータベースを支配するリレーショナルデータベースモデルの実装における大きな特徴であった。
データベース 研究
データベース技術は、1960年代から、学界や企業の研究開発グループ（例: IBM基礎研究所）の両方で活発な研究課題となっている。研究活動には、理論やプロトタイプの開発が含まれる。注目すべき研究課題には、モデル、アトミックトランザクションの概念、関連する並行性制御技術、クエリ言語とクエリ最適化手法、RAIDがある。
データベース研究分野には、いくつかの専門学術誌や（例: ACM Transactions on Database Systems-TODS、Data and Knowledge Engineering-DKE）、年次会議（例: ACM SIGMOD、ACM PODS、VLDB、IEEE ICDE）がある。
日本の学会としては、日本データベース学会があげられる。
飲料水
飲料水（いんりょうすい、仏: eau potable、英: drinking water、独: Trinkwasser）とは、飲用に適した水を表す。「のみみず」とも。
飲料水 飲料水
飲料水は病原微生物や有毒物質を含まず、無味・無臭・透明が求められ、一般に水道水、湧水、流水、井戸水などを用いる。
飲むことができる水を確保しておくことは大切である。人は水を飲まずにいられるのは、一般的にはせいぜい4～5日程度だと言われている。安全な飲み水を確保することは、古の時代から重要な課題であった。病原体で汚染された飲み水を飲むと、それに感染することによってさまざまな病気にかかる。赤痢やコレラの大流行は、しばしば、不適切な水を飲用に用いたことで起きている。有毒物質を含んだ水を飲むことで、さまざまな障害が生じる。
世界の様々な地域の生水は概して飲料水としては使えない。熱帯地方では河川の水が病原微生物を含んでいることは多い。水道で運ばれてきて蛇口から出てくる水でさえそうである。地元の住民ならばかろうじて耐えられる場合でも、旅行者には危険な場合もあり得る。病原微生物を死滅させるためには少なくとも一旦煮沸する必要がある。
海水は塩分などが多過ぎるため、飲料水としては使えない。無寄港で海上を旅する時や、海で遭難した場合には、飲料水の確保が問題となるため、周囲にありあまるほどの海水が見えているにもかかわらず飲める水が無い、という皮肉な状況に追い込まれてしまう。同様に、内陸の塩水湖の湖水も飲料水としては使えない。火山地帯の湧水も特殊な成分を含み、飲用には適さない場合がある。
飲料水 飲料水
飲料水を得るひとつの方法として、植物体内の水を用いるという方法がある。植物体内の水であれば、あらかじめ植物の繊維構造でフィルターがかけられていることが多く、植物自体が生きのびるために菌類の繁殖を防ぐようなシステム（抗菌作用）を持っており、ほぼ無菌に近いからである。例えばココヤシの実の中の水を飲む方法がある。アマゾンには水を大量に含んだ樹木がいくつもあり、ジャングル内を旅する時などには、それを見つけて枝をナタで切り落として傾ければ、飲用に適した水が出てくる。水筒を持ち歩かなくても、そこかしこに飲料水があるため、現地人は俗称で「水筒の木」などと呼んでいる。ウツボカズラの捕食袋の水も飲用にされる（ただし、これの場合は袋が開く前に限る）。昔から、瓜（ウリ）、スイカ、メロン類、リンゴなど水分量が多い果物の果汁を飲料水の代用とする地域もある。
飲料水 世界各地の事情
世界的に、乾燥した地域も多く、そういった地域では、まず水そのものを得る方法を考案しなければならない。井戸はその代表的な技術である。サウジアラビアでは、電力を使って海水の塩分を分離し、飲用水を作り出している。サウジアラビアやイラク等々では、飲用水はガソリンよりも高価である。
日本の上水道は、水道局の関係者が日々水の質を高く保つために努力を積み重ねており、そのため蛇口をひねって出てきた水がそのまま飲める状態に保たれている。これは世界的に見て例外的なことといわれている。
米国の開拓時代、カウボーイは自分が得た水の水質を信用しきれない場合、それに殺菌防腐効果があるアルコール度の高い酒を加えて飲む、などということも行ったが、殺菌効果が最も高いのはアルコール濃度(重量％)が70から80パーセントの時 で、数パーセントまで希釈されている場合、殺菌効果はあまり期待できない。
2010年頃から、世界保健機関（WHO）や赤十字が家庭での水処理と安全な貯蔵のための実行可能な方法として太陽水殺菌を推奨している。分散型水処理のため、簡単かつ効果的な方法であり、家庭などでも行うことができる。そのため、太陽水殺菌による水の殺菌はすでに多くの発展途上国で利用されている:55。EAWAGによって発行されている太陽水殺菌の手順に関する教育用パンフレットは多くの言語で入手可能である。
飲料水 水質
給水事業ではない（例えば個人所有の井戸水等）の水質基準については、法的に定められていない。一般的な水質の目安として、約10項目（大腸菌、一般細菌、硝酸態及び亜硝酸態窒素、塩化物イオン、有機物等（全有機炭素）、pH値、臭気、色度、濁度、味：これらを総称して「簡易飲適」と言われる）及び残留塩素についてを検査・確認することが多い。飲用を目的とする場合には、出来るだけ水道水質基準の全項目の検査を実施した方がよい。不適合である場合には、滅菌装置や濾過装置の設置などによる浄化対策を講じた後、再検査を行う必要がある。検査は、保健所や環境計量証明事業所などで実施している。
飲料水 供給（販売）者
供給者は、地域住民の共同体から公的機関、公共企業体、民間事業者まで多種多様。戦争や大規模災害時は、地方自治体、国家や国際的なNGOや国連難民高等弁務官事務所などが直接供給、供給手段を提供することがある。
田村由美
田村 由美（たむら ゆみ［本名同じ］、1962年〈昭和37年〉9月5日 - ）は、日本の女性漫画家。和歌山県和歌山市出身、東京都千代田区在住。O型。
田村由美 来歴・人物
高校2年頃より気軽な気持ちで『別コミ』に投稿を始めると月例のまんが賞（佳作や期待賞等）を獲得し、直ぐに小学館から電話連絡があって担当編集者が付いたもののデビューは出来ず、高校卒業後に和歌山県より東京に上京し、色々な漫画家の制作アシスタントをしながら東京デザイナー学院グラフィックデザイン科に通い卒業する。投稿時代は手探りで中途半端な作品ばかりとなってしまっていたが、男性キャラを主役にハードボイルド寄りの話を思い切って描こうと思い立ち、規定をオーバーした41頁の読み切りを描き担当編集者に無断で応募した『オレたちの絶対時間』が第12回「小学館新人コミック大賞」に佳作入選し、1983年（昭和58年）、『別冊少女コミック 9月号増刊』（小学館）に掲載されデビューに至った。当時の担当編集者からは「女の子が主役。アクションやサスペンスはダメで、アクションがしたいならスポーツ物で。」等の指導をされた為、デビュー直後は描きたい物語がない＝ネタのストックが無かったので苦労したと、『デビュー40周年記念本 KALEIDOSCOPE』のロングインタビューにてデビュー前後の経緯を回想している。
田村由美 来歴・人物
デビュー以後、主に小学館が発行する漫画雑誌で執筆活動を展開するが、『月刊メロディ』（白泉社）で『合点〜GATTEN!〜』を2002年6月号・9月号に掲載、『Cocohana』（集英社）で『イロメン〜十人十色〜』を2012年10月号より2020年9月号まで連載などの実績がある。
2013年、和歌山県文化表彰・文化功労賞を受賞。
2024年2月に令和5年度の『芸術選奨文部科学大臣賞』を受賞し、その贈賞理由に於いて2023年にデビュー40周年を迎えた事に触れ、長期にわたり第一線で活躍し、常に新境地を開拓してきた功績に敬意を表したいと述べられている。
田村由美 受賞歴・栄典
2023年までの受賞年数は、『デビュー40周年記念本：KALEIDOSCOPE』に準拠。
田村由美 漫画作品
特記がない限り、小学館での連載・発行とする。
フラワーコミックス
田村由美ベストセレクション
田村由美The Best Selection 2008年 ISBN 978-4-09-132044-5
きねづかん、拾った男、あの夏が終わる、ウエディングベルは聞こえない、彼女は誰を殺したか
田村由美The Best Selection2 2009年 ISBN 978-4-09-132699-7
女神が落ちた日、通り魔1991、MADONNAに告ぐ
タムのなんでもカプセル
フラワーコミックススペシャル
たむたむVARIETY THEATER
小学館文庫
集英社・マーガレットコミックス
田村由美 作品提供
別冊少女コミックビデオ イラスト・アンソロジー vol.1 田村由美
田村由美、漫画の魅力を語る
デビュー作品&プロフィール紹介
インタビュー (1) デビューするまでのこと、教えて?
「神話になった午後」紹介&解説
「ちょっと英雄（ヒーロー）してみたい」紹介&解説
松本保典の仕事場拝見コーナー
インタビュー (2) キャラクターについて教えて?
「巴がゆく!」紹介&解説
「理由（ワケ）」シリーズ紹介&解説
初の映像化! 「BASARA」更紗、朱理の作画風景
「BASARA」紹介&解説
田村由美「X-DAY」について語る
これで全部! 作品年表
収録イラスト
オレたちの絶対時間
神話になった午後
ちょっと英雄（ヒーロー）してみたい
ちょっと英雄騎士団（ヒーロー・ナイツ）
巴がゆく!
理由（ワケ）シリーズ
X-DAY
BASARA
田村由美 カバーイラスト作品
集英社スーパーファンタジー文庫
前田珠子によるライトノベル「魅魎暗躍譚シリーズ」
コバルト文庫
前田珠子によるライトノベル「魅魎暗躍譚シリーズ」の再刊版
集英社オレンジ文庫
氏家仮名子によるライト文芸
田村由美 その他
スクウェア/小学館
NTT出版
株式会社アールアールジェイ
朗読ライブ「旅のラゴス」製作委員会
C言語
C言語（シーげんご、英: C programming language）は、1972年にAT&Tベル研究所のデニス・リッチーが主体となって開発した汎用プログラミング言語である。英語圏では「C language」または単に「C」と呼ばれることが多い。日本でも文書や文脈によっては同様に「C」と呼ぶことがある。制御構文などに高水準言語の特徴を持ちながら、ハードウェア寄りの記述も可能な低水準言語の特徴も併せ持つ。基幹系システムや、動作環境の資源制約が厳しい、あるいは実行速度性能が要求されるソフトウェアの開発に用いられることが多い。後発のC++やJava、C#など、「C系」と呼ばれる派生言語の始祖でもある。
ANSI、ISO、またJISにより言語仕様が標準規格化されている。
C言語 特徴
Cには他のプログラミング言語と比較して、特筆すべきいくつかの特徴がある。
Cは、移植の容易性、自由度、実行速度、コンパイル速度などを追求した。代わりにコンパイル後のコードの安全性を犠牲にしている。また、詳細を規格で規定せず処理系に委ねている部分が多く、Cで書かれたソフトウェアでは処理系依存のコードが氾濫する原因となった。セキュリティ上の脆弱性や潜在的バグによる想定外の動作、コンパイラによる最適化の難しさといった問題を抱えており、最適化するとコンパイル速度が遅くなるなどの問題が生じることがある。
上記のように、利点でもあり、同時に欠点にもなる特徴を備えている。
もともとUNIXおよびCコンパイラの移植性を高めるために開発されてきた経緯から、オペレーティングシステム（OS）のカーネルおよびコンパイラ向けの低水準な記述ができるなど、ハードウェアをある程度抽象化しつつも、必要に応じて低水準言語と同じことを実現できるようなコンピュータ寄りの言語仕様になっている。そのため、低水準な記述ができる高水準言語と言われたり、高水準言語の顔をした低水準言語（高級アセンブラ、汎用アセンブラ）と言われたりすることがある。
C言語 特徴
Cはアマチュアからプロ技術者まで、プログラマ人口が多く、プログラマのコミュニティが充実している。使用者の多さから、正負の両面含め、Cはプログラミング文化に大きな影響を及ぼしている。また、多目的性と、対応機器の多彩さのため、「コンピュータを使ってやること」は大抵、Cで対応可能である。ただし、Cで効率的かつ安全に記述できるかどうかはまた別の話である。スクリプト言語やコマンドラインシェルを使えば手軽に実現にできるような処理まで、わざわざCで記述する必要はない。また、GUIアプリケーションフレームワークは、Cからは利用できず、統合開発環境と連携する新しいプログラミングツールやプログラミングパラダイムに対応した後発言語でなければ利用できないものもある。
MISRA CやCERT Cというコーディング標準（コーディング規約）を定義して、危険な機能の使用や記述を禁止するという制限を設けることでCを安全に利用するためのガイドラインが運用されている分野もある。特にプログラミングミスが人命に直結する自動車分野などでCを利用するには、このような制約が重要である。
C言語 特徴
プログラムを戻り値つきのサブルーチンに分離できる。C言語ではこれを関数と呼び、関数内のプログラムコードでは、独立したスコープを持つ変数（ローカル変数）が使用できる。これにより、データの流れがブロックごとに完結するのでデバッグが容易になり、また関数の再帰呼び出しも可能となる。また、多人数での共同開発の際にも変数名の衝突が回避しやすくなる。なお、C言語ではUNIXのようなOSを前提としたホスト環境と、割り込み制御のようなOSを前提としないフリースタンディング環境とがある。ホスト環境では、プログラム開始直後に実行するプログラム要素を main という名前の関数として定義する。プログラム中で再帰的にmain関数を呼ぶことも可能（C++では不可能）。フリースタンディング環境では、エントリーポイントと呼ばれるアドレスに置かれたコードをプログラムの開始点とするが、それがmain関数である必要はない。なお再帰呼び出しそのものは、スタックオーバーフローの原因となるため、MISRA Cでは禁止している。
C言語 特徴
システム記述言語として開発されたため、高級言語であるがアセンブラ的な低水準の操作ができる。ポインタ演算、ビットごとの論理演算、シフト演算などの機能を持ち、ハードウェアに密着した処理を効率よく記述できる。これはオペレーティングシステムやデバイスドライバーなどを記述する上では便利であるが、注意深く利用しないと発見しにくいバグの原因となる。ライブラリ関数は、C言語規格が規定している関数と、OSが規定している関数との間の整合性、棲み分けなどが流動的である。MISRA Cのようないくつかの制約では、C言語規格が規定している関数の妥当性について指摘し、いくつかの関数を利用しないように規定している。
ソースコードの記述に使う文字集合はANSI C（C89）およびISO/IEC 9899:1990（C90）ではASCIIを標準としている。他のISO 646でも書けるように、3文字利用したトライグラフと呼ばれる表記法も存在する。その後、ISO/IEC 9899:1995 AMD（C95）などではマルチバイト文字セット対応の拡張を規定している。さらに、その後トライグラフは複数のコードを利用したシステムでしか利用がないため、より分かり易い2文字によるダイグラフを規定している。
C言語 特徴
多くの処理系がインラインアセンブラを搭載しているほか、アセンブラで出力したオブジェクトとのリンクが容易になっている。これにより速度が要求される部分だけをアセンブリ言語で記述するということが容易に行えることが多い。アセンブラとのインタフェースは#pragma asmなどを用いて局所化を図る努力はあるが、コンパイラごとに定義があり、CPUが同一であっても移植性が低い場合がある。
C言語 特徴
コンパイラの処理が1パスで済む仕様になっている。歴史的な経緯から、変数の宣言において型指定がない場合はint型とみなし、関数の戻り値の型指定がない場合はint型とみなす。ANSI C（C89）ではコンパイル時型検査の強化のために関数プロトタイプの機能が導入されたが、関数の宣言がない場合の戻り値はint型とみなし、引数は未知（任意）とみなす。しかし、このような暗黙の型指定は型安全性を損ない未定義動作を引き起こす危険性があるため、ISO/IEC C:1999（C99）以降では暗黙の型指定に関する仕様が標準規格の文面から削除された。いずれも使用（参照）するより前に適切に宣言する必要がある。ClangやGCCといったC99準拠のコンパイラは、このような暗黙の型指定について、C99モードであってもC89互換の動作を残してはいるものの、非標準の動作であるため警告を出すようになっている。なお、関数宣言において()のように引数を省略すると、引数を未知とする仕様はC99でも残されている。後継言語では完全なプロトタイプ宣言を必須とするか、あるいはプロトタイプ宣言自体を不要としているが、記述によっては先読みが必要になりうる。
C言語 特徴
マクロ記述やコンパイル条件の指定などができる前処理指令が標準化されている。前処理指令の解釈をするプリプロセッサ （preprocessor）を持っている。プリプロセッサは、その名の通りコンパイル処理の前に自動的に実行される。コンパイラの機能として、プリプロセッサを通しただけの段階のソースコードを出力可能になっているものがある。前処理の結果を検査することで、設計者の意図と前処理の結果のずれがないか確認できる。
処理系の簡素化と効率のために、以下のように安全性を犠牲にした仕様が多い。なお、ホスト環境やプログラムの内容によっては、以下に対して脆弱性対策を施したとしても実行速度の低下が無視できる程度であることも多く、言語仕様側の欠点とみなされることも少なくない。
配列の参照時に添字の値が範囲内にあるかを検査しない
C言語 特徴
これを要因とする代表的なバグが、固定長のバッファ領域をはみだしてデータの書き込みが行われてしまう「バッファオーバーフロー」（バッファオーバーラン）である。範囲外のアクセスは、書き込みだけでなく読み取りの場合も未定義動作を引き起こす。標準ライブラリにはバッファオーバーフローや範囲外アクセスを考慮していない関数があり、かつ多用されがちなため、しばしば脆弱性の原因となる。また、Cではプログラムにより明示的に制御（動的メモリ確保）することで可変長配列の実現を可能にしているが、確保した領域の範囲外にアクセスしても自動的な伸長は行なわれない。
後継言語では、標準ライブラリまたは組み込み型により可変長配列をサポートしていたり、範囲外アクセス時には例外（実行時エラー）を送出するなどして安全性を優先していたりすることが多い。
文字列を格納するための特別な型が存在しない
文字列にはchar型の配列を利用する。言語仕様上に特別な扱いはないが、ヌル文字（'\0'）を終端とする文字列表現を使い、その操作をする標準ライブラリ関数がある。これは実質的にメモリ領域へのポインタアクセスそのものであり、確保されている領域の長さよりも長い文字列を書き込めてしまうために、バッファオーバーランの元凶の1つとなっている。
C言語 特徴
後継言語では文字列処理を特に強化している場合が多く、標準ライブラリあるいは言語仕様による組み込みの文字列型を提供している。
自動変数（auto variable）の自動的な初期化をしない
自動変数（静的でないローカル変数）は変数の中でも最も頻繁に用いられる。初期化されていない変数を参照した場合にはその値は不定であるが、不定な値へのアクセスは未定義動作であるので、コンパイラ最適化の過程で想定しない形に改変することもある。変数宣言・初期化の仕様による制限から、変数宣言の時点では初期化をせずに後で代入等により値を入れてつかうことが普通なので、誤って不定の値の変数を読み出すバグを作り込みやすい。なお自動変数の自動とは変数の領域の確保と解放が自動であるという意味であり、自動的に初期化されるという意味ではない。
後継言語では、明示的な初期化が記述されていない変数は、不定値ではなくその変数の型の既定値（ゼロあるいはゼロ相当の値）で初期化される仕様になっていることが多い。
C言語 特徴
入出力や動的メモリ確保を含めほとんどの機能が、C言語自身で書かれたライブラリによって提供される。このことは、C言語の機種や環境依存性が低く、それらに依存する箇所をライブラリへ分離することにより移植性（ポータビリティ）が高いことを意味する。さまざまな機種があるUNIXの世界でC言語が普及した理由のひとつである。
例として、POSIX環境での動的メモリ確保はmallocおよびその類似関数にて提供される。一方、カーネルではメモリ確保の際にスレッドがブロックされるとカーネル内のデータが他のスレッドにより変更され、予期せぬ動作を起こす恐れがあることや、メモリ内容の初期化が必要かどうかによって割当先のページを選択することによりシステムの効率が上がることから、多くの場合POSIXとは異なるAPIを使用している。Linuxカーネルの場合、前者はフラグGFP_KERNELとGFP_ATOMICの使い分け、後者は関数kmalloc（割り当てたメモリの内容は不定）とkzalloc（割り当てたメモリの内容はゼロクリア済）の使い分けにより実装している。
ANSI/ISOにより規格が標準化された後は言語仕様の変化が小さく安定していること、C言語のプログラマ人口やコード資産が多いこと、C++やObjective-CからC言語関数を直接利用できること、また必要に応じて他のプログラミング言語からC言語関数を呼び出すためのバインディングを記述することが容易であることなどから、APIの外部仕様としてC言語の関数インターフェイスが選ばれることが多い。例えばOpenGLやOpenCLのようなオープン規格は第一級言語としてC言語を採用している。
C言語のHello worldプログラムは、ホスト環境を前提とするか、フリースタンディング環境を前提とするかで、方向性が異なる。ホスト環境を前提とする場合には、標準入出力の利用により、動作をすぐに確かめることができる。以下では、標準Cライブラリのヘッダstdio.hにて宣言されている、printf関数を利用したものを例示する。
上記サンプルソース中の「\n」は、エスケープ文字\によるエスケープシーケンスのひとつであり、改行（ラインフィード）を表す。
main関数は標準的なプログラムエントリーポイントであり、プログラムを開始すると、ランタイムライブラリによるスタートアップ処理が実行された後にこのmain関数が呼ばれる。引数のないバージョン（void）と、コマンドライン引数をポインタ配列として受け取るバージョン（int argc, char* argv[]）どちらを使ってもよい。
なお、printf関数は書式文字列とそれに対応する可変個引数を受け取り、書式化された文字列として表示できる高機能な標準出力関数であるが、序盤から例示に使用している入門書もある。
return 0;はmain関数の戻り値としてint型の値0を返している。C99以降では、main関数の戻り値のデータ型がintと互換性があるときは暗黙的に0を返す。従って、C99以降ではreturn 0;を省略しても同じ結果になる。
main関数とprintf関数は、いずれも入門者や初学者にとっては最初の関門となる難解な関数であり、C言語によるプログラミングのハードルを高くしている一因でもある。JavaやC#のような後発言語では、文字列の扱いや、可変個引数の扱いがより簡潔で安全になっている。Pythonのようなインタプリタや対話環境上で動作することを前提とした言語では、main関数を定義する必要はない。
C言語 歴史
C言語は、AT&Tベル研究所のケン・トンプソンが開発したB言語の改良として誕生した（#外部リンクの「The Development of the C Language」参照）。
1972年、トンプソンとUNIXの開発を行っていたデニス・リッチーはB言語を改良し、実行可能な機械語を直接生成するC言語のコンパイラを開発した。後に、UNIXは大部分をC言語によって書き換えられ、C言語のコンパイラ自体も移植性の高い実装のPortable C Compilerに置き換わったこともあり、UNIX上のプログラムはその後にC言語を広く利用するようになった。
ちなみに、「UNIXを開発するためにC言語が作り出された」と言われることがあるが、「The Development of the C Language」によると、これは正しくなく、経緯は以下の通りである。C言語は、当初はあくまでもOS上で動くユーティリティを作成する目的で作り出されたものであり、OSのカーネルを記述するために使われるようになるのは後の展開である。
開発者達は、コンパイラなどのユーティリティを「システムプログラム」と呼んでいたが、それらの作成に使われる「システムプログラミング言語」は、OSのカーネルを作成するための言語という意味ではない。
C言語 歴史
アセンブリ言語との親和性が高いために、ハードウェアに密着したコーディングがやりやすかったこと、言語仕様が小さいためコンパイラの開発が楽だったこと、小さな資源で動く実行プログラムを作りやすかったこと、UNIX環境での実績があり、後述のK&Rといった解説文書が存在していたことなど、さまざまな要因からC言語は業務開発や情報処理研究での利用者を増やしていった。特にメーカー間でオペレーティングシステムやCPUなどのアーキテクチャが違うUNIX環境では再移植の必要性がしばしば生じて、プログラムをC言語で書いてソースレベル互換を確保することが標準となった。
C言語の開発当初に使われた入力端末はASR-37であったことが知られている。ASR-37は1967年制定の旧ASCII ISO R646-7bitにもとづいており、「{」および「}」の入力を行うことができたが、当時は一般的に使われていた入力端末ではなかった。
当時PDP-11の入力端末として広く使われていたのはASR-33であるが、これは1963年制定の旧ASCIIであるASA X3.4に準拠しており、「{」や「}」の入力を行うことはできなかった。
C言語 歴史
このことは、ブロック構造に「{」や「}」を用いるC言語（さらに元をたどればB言語）は、当時の一般的な環境では使用不可能であったことを示している。これは、C言語はその誕生当初にあっては一般に広く使われることを想定しておらず、ベル研究所内部で使われることを一義的に考えた言語であったという側面の表れである。
これに対し、PascalやBASIC等の当初から広く使われることを想定した言語では、ブロック構造に記号を用いずにbeginとendをトークンとして用いることや、コメント行を表す際に開始トークンとしてREMという文字列を用いることなど、記号入力に制約がある多くの入力端末に対応できるように配慮されていた。この頃の他の言語やOSで大文字と小文字の区別をしないものが多いのも、当時は大文字しか入力できない環境も少なくなかったことの表れである。
このような事情のため、C言語が普及するのは、ASCII対応端末が一般化した1980年代に入ってからである。
現在、ブロック構造の書式等で、{...}形式のC言語と、begin...end等を使用する他の言語との比較において優劣を論じられることがあるが、開発時の環境等をふまえずに現時点での利便性のみで論じるのは適切ではない場合があることに留意が必要である。
C言語 歴史
1980年代に普及し始めたパーソナルコンピュータ（PC）は当初、8ビットCPUでROM-BASICを搭載していたものも多く、BASICが普及していたが、1980年代後半以降、16ビットCPUを採用しメモリも増えた（ROM-BASIC非搭載の）PCが主流になりだすと、Turbo CやQuick Cといった2万円程度の比較的安価なコンパイラが存在したこともあり、ユーザーが急増した。8ビットや8086系のPCへの移植は、ポインタなどに制限や拡張を加えることで解決していた。
1990年代中盤には、最初に学ぶプログラミング言語としても主流となった。また、同時期にはゲーム専用機（ゲームコンソール）の性能向上とプログラムの大規模化、マルチプラットフォーム展開を受け、メインの開発言語がアセンブリ言語からC言語に移行した。
C言語 歴史
1990年代後半 - 2000年代以降は、PCのさらなる性能向上と普及、GUI環境やオブジェクト指向の普及、インターネットおよびウェブブラウザの普及、スマートフォンの普及に伴い、より高水準で開発効率の高い言語やフレームワークを求める開発者が増えたことにより、C++、Visual Basic、Java、C#、Objective-C、PHP、JavaScriptなどが台頭してきた。広く利用されるプログラミング言語の数は増加傾向にあり、相対的にC言語が使われる場面は減りつつある。特にアプリケーションソフトウェアなどの上位層の開発には、C言語よりも記述性に優れるC++、Java、C#などC言語派生の後発言語が利用されることが多くなっている。資源制約の厳しかったゲーム開発においても、ハードウェアの性能向上やミドルウェアの普及により、C++やC#などが使われる場面が増えている。速度性能や省メモリが特に重視されるシステムプログラミングに関しても、伝統的にC/C++の独壇場だったが、新規コードではより安全性の高いRustを導入する事例が現れている。
しかし、C言語は比較的移植性に優れた言語であり、個人開発／業務用開発／学術研究開発やプロプライエタリ/オープンソースを問わず、オペレーティングシステムやデバイスドライバーなどの下位層、クロスプラットフォームAPIの外部仕様、C++やJavaなどの高水準言語の処理系および実行環境の実装が困難な小規模の組み込みシステムなどを中心に、2021年現在でも幅広く利用されている。
プログラミング入門者にとっては、Python、JavaScript、Swift、Kotlinなどのように、インタラクティブな対話環境（REPL、インタプリタ）が利用でき、抽象化が進んでおり、煩雑なメモリ管理が不要で、危険な機能を制限した高水準言語のほうが学習・習得しやすいが、コンピュータの動作原理やハードウェア仕様を理解するには、Cのような原始的な言語を用いたほうがかえって分かりやすいケースもある。
C言語 規格
米国国家規格協会（ANSI）による標準化が行われるまで、1978年出版のデニス・リッチーとブライアン・カーニハンの共著『The C Programming Language』が実質的なC言語の標準として参照されてきた。この書籍は、著者らのイニシャルを取って「K&R」とも呼ばれている。C言語は発展可能な言語で、K&Rの記述も発展の可能性のある部分は厳密な記述をしておらず、曖昧な部分が存在していた。そのためC言語が普及するとともに、互換性のない処理系が数多く誕生した。
そこで、ISO/IEC JTC1とANSIは協同でC言語の規格の標準化を進め、1989年12月にANSIがANSI X3.159-1989, American National Standard for Information Systems -Programming Language-Cを、1990年12月にISOがINTERNATIONAL STANDARD ISO/IEC 9899：1990（E） Programming Languages-Cを発行した。ISO/IEC規格のほうが章立てを追加しており、その後ANSIもISO/IEC規格にならって章立てを追加した。それぞれC89（ANSI C89）およびISO/IEC C90という通称で呼ぶことがある。
C言語 規格
日本では、これを翻訳したものを『JIS X 3010-1993 プログラム言語C』として、1993年10月に制定した。
最大の特徴は、C++と同様の関数プロトタイプを導入して引数の型チェックを強化したことと、voidやenumなどの新しい型を導入したことである。一方、「処理系に依存するものとする」に留めた部分も幾つかある（int型のビット幅、char型の符号、ビットフィールドのエンディアン、シフト演算の挙動、構造体などへのパディング等）。
規格では以下の3種類の自由を認めている部分がいくつかある。
これにより、プラットフォームやプロセッサアーキテクチャとの相性による有利不利が生じないような仕様になっている。
C言語 規格
8ビット/16ビット/32ビットなど、レジスタ幅（ワードサイズ）の異なるプロセッサ（CPU）に対応・最適化できるようにするため、組み込み型の情報量（大きさ）や内部表現にも処理系の自由を認めている。型のバイト数はsizeof演算子で取得し、各型の最小値・最大値はlimits.hで定義されているマクロ定数で参照することとしている。ただし、1バイトあたりのビット数は規定されていない。sizeof(char) == 1すなわちchar型が1バイトであることは常に保証されるが、8ビット（オクテット）とは限らない。実際のビット数はCHAR_BITマクロ定数で取得できる。とはいえ、現実の多くの処理系ではchar型は8ビットである。また、その他の整数型については、sizeof(int) >= 2、sizeof(int) >= sizeof(short)、sizeof(long) >= sizeof(int)、という大小関係が定められているだけである（符号無し型も同様）。多くの処理系ではshort型のサイズは2バイト（16ビット）であるが、intやlongのサイズはCPUのレジスタ幅などによって決められることが多い。int型、short型、long型で符号を明示しない場合はsignedを付けた符号付き型として扱われる。しかしchar型に関しては、signed（符号付き）にするか、それともunsigned（符号無し）にするかは処理系依存である。char型、signed char型、unsigned char型はそれぞれ異なる型として扱われる。
C言語 規格
規格上には、BCPLやC++形式の1行コメント（//…）は無いが、オプションで対応した処理系も多く、gccやClangはGNU拡張-std=gnu89でサポートしている。
GNU Cコンパイラ や Clang では、-std=c89（または-ansiもしくは-std=c90）をつけることにより、GNU拡張を使わないC89規格に準拠したコンパイルを行うことができる。加えて、-pedanticをつければ診断結果が出る。商用のコンパイラではWatcom Cコンパイラが規格適合の比率が高いと言われていた。現在Open Watcomとして公開している。
C89には、下記の追加の訂正と追加を行った。
1999年12月1日に、ISO/IEC JTC1 SC22 WG14 で規格の改訂を行い、C++の機能のいくつかを取り込むことを含め機能を拡張し、ISO/IEC 9899:1999(E) Programming Language--C（Second Edition）を制定した。この版のC言語の規格を、通称としてC99と呼ぶ。
日本では、日本産業規格 JIS X 3010:2003「プログラム言語C」がある。
主な追加機能：
C99は下記の訂正がある。
2011年12月8日にISO/IEC 9899:2011（通称・C11）として改訂された。