hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
日本の仏尊 一覧
救火難観世音
救水難観世音
救獅子難観世音
救象難観世音
救刑難観世音
救龍難観世音
救空行難観世音
救盗賊難観世音
金剛藏観世音
獅吼観世音
佛海観世音
三字半観世音
救八難観世音
不空鉤観世音
不空供養宝観世音
大悲勝海紅観音（一面四臂具明妃）
香王観音
忿怒鉤観自在菩薩
一髻羅刹観音
数珠手観音（数珠観音）
【威猛馬頭金剛·男性本尊佛の相】
馬首蓮花舞主十七尊（略）
赤色馬首蓮花舞主三面八臂十八尊（略）
独雄双身馬頭金剛（具明妃）
四行空囲繞之馬頭金剛
白色馬頭金剛
【威猛勝楽金剛·男性本尊佛の相】（《藏密真言宝典》参照）
勝楽金剛（《藏密真言宝典》第50、195ページ参照）
白勝楽一面二臂単身二十九尊（略）（《藏密真言宝典》第94、195ページ参照）
総撮輪四面十二臂十三尊（略）
青色双身勝楽一面二臂金剛空行等囲繞五尊（略）（具明妃）（《藏密真言宝典》第95、195ページ参照）
白色贖死勝楽四面十六臂八門隅母囲繞九尊（略）
藍勝楽三面六臂八尊（略）（《藏密真言宝典》第97、195ページ参照）
総撮輪四面十二臂六十二尊（略）
青色勝楽一面二臂六十二尊（略）
黄色勝楽一面二臂六十二尊（略）
勝楽転輪常佛空行七十二尊（略）
勝楽転輪金剛日宝空行七十二尊（略）
勝楽転輪蓮花舞主蓮花空行七十二尊（略）
勝楽転輪嘿汝嘎金剛空行七十二尊（略）
勝楽転輪良馬種種空行七十二尊（略）
日本の仏尊 一覧
双身勝楽金剛（具明妃）（《藏密真言宝典》第187、195ページ参照）
披甲黒色勝楽金剛
白色勝楽金剛（《藏密真言宝典》第194、195ページ参照）
長寿白色勝楽金剛（《藏密真言宝典》第194、195ページ参照）
双身争論金剛（具明妃）（《藏密真言宝典》第206、195ページ参照）
【度母の相】（度母は観世音菩薩の明妃、或は観世音菩薩の女性の化身とされる。藏伝佛教には観音を父とし、度母を母とする説もある。藏伝佛教では観世音菩薩は藏伝佛教の根源、根本と見なされ、観世音菩薩がいなければ藏伝佛教はない。藏伝佛教において、観音は男性、度母は女性とする。）
聖度母
縁度母
白度母
金剛度母十一尊（略）
六支度母
持財母（持宝母）
六字母
忿怒母
昼善夜怒度母
鳥仗那度母処之自在母
如意宝度母
赤度母
施財度母
黄度母
宝度母
蓮花度母
佛度母
金剛度母
花度母
香度母
灯度母
味度母
夢示度母
救度母
随求佛母
具光佛母
独髻母（一髻佛母）（《藏密真言宝典》第247、326ページ参照）
八臂度母
至尊嘎巴哩度母
準提聖母
持針線具光佛母
吉祥心金点母
至尊嘎巴拉荘厳母
秘密智慧母
白色準提佛母
馭緑馬具光佛母
聖圓度母
最勇救度母
白色朗月度母
金顔救度母
頂髻尊勝度母（《藏密真言宝典》第323ページ参照）
吽音叱咤度母
勝三界度母
破敵救度母
勝施王救度母
担木救度母
最勝撮授度母
除憂度母
解厄度母
吉祥光救度母
卒竟成熟度母
顰眉度母
大寂静度母
除貪度母
引楽度母
増盛度母
焚灰諸苦度母
出生悉地度母
卒竟圓満度母
随求佛母五尊（略）
【威猛大黑天·摩訶迦羅·男性護法の相】（瑪哈嘎拉：藏伝佛教の第一護法、観音の化身）
六臂護法（六臂瑪哈嘎拉）
四臂護法（四臂瑪哈嘎拉）
具徳大黒金剛四臂九尊（略）
除中断護法
雄威護法
宜帝護法
白色如意護法
黄色増慧護法
赤色自在王護法
緑色寿主護法
宝空行護法
佛陀空行護法
蓮花空行護法
事業空行護法
二法合一四臂護法
鳥鴉面羯磨護法
双身宝帳護法（具明妃）
宝帳護法八尊（略）
宝帳橛足護法
有陰体宝帳護法
単身宝帳護法
騎虎護法
持除難梃護法
梃藏護法
具善護法三兄弟
昂果惹護法
吉祥熾炎護法
独雄持鉞刀護法
西南方持赤色鉞刀護法
四和合護法
持鉞刀護法
持銅刀護法
黒衣持銅刀護法
裸形持銅刀護法
獅子座部衆主護法
騎獅雄威護法
歩行雄威護法
氂牛面雄威護法
密修雄威空行面護法
閉関時所修四面吉祥護法
成就時所修四面吉祥護法
四面事業加行護法
白色四面増寿護法
黄色四面増財護法
赤色四面自在護法
四忿面護法
食肉狼面護法
役魔黒閻羅王
鉞刀護法
【女性護法の相】
白色妙音佛母（《藏密真言宝典》第147ページ参照）
披甲簪芝嘎
金剛鉤母
金剛索母
鉄鏈金剛母
金剛鈴母
羯磨金剛母
羯磨閻羅母
羯磨龍母
羯磨薬叉母
鉄剣馬頭金剛母（女性本尊佛、馬頭金剛の明妃）
金剛空行母
宝空行母
蓮花空行母
羯磨空行母
八大薬叉母（略）（《藏密真言宝典》第336ページ参照）
除中断天母
簪咫嘎天母
持鉞刀和合成就護法母
雄威黄門護法母
青色四面救衰敗母
烟黒天母
熱嘛提魔母
披虚空衣佛母（瑪哈嘎拉の女性眷属）
【金剛亥母の相】（金剛亥母：勝楽金剛の明妃）
金剛亥母
赤亥母三面六臂十三尊（略）
赤亥母右側亥面藍色二面二臂十三尊（略）
義成金剛亥母一面四臂十三尊（略）
赤黄色断首金剛亥母二臂十三尊（略）
赤色金剛亥母一面二臂十三尊（略）
赤亥母四面十二臂三十七尊（略）
黒金剛亥母亥首一面二臂五尊（略）
赤色金剛亥母三十七尊（略）
青色金剛亥母三十七尊（略）
黄色金剛亥母三十七尊（略）
披甲金剛亥母
納若空行母
弥勒空行母
因陀羅空行母（帝釈空行母）
不空亥母
断首母
金剛密咒母
毗盧仏母
天足亥母
咕日瑪巴底亥母
黒色忿怒亥母
明慧白色亥母
赤色亥母
滑落忿怒炎触母
【其他の財神、鬼王、薬叉等の相】
白財神
黄財神（《藏密真言宝典》第243ページ参照）
多聞天王（《藏密真言宝典》第243ページ参照）
面然大士（焦面鬼王）
馬頭金剛金翅鳥
勝楽金剛金翅鳥
八大薬叉（略）（《藏密真言宝典》第335ページ参照）
十二天
梵天 - インド神話の神ブラフマーに由来
帝釈天 - インド神話の神インドラに由来
火天 - インド神話の神アグニに由来
焔摩天（閻魔） - インド神話の神ヤマに由来
羅刹天 - インド神話の鬼神ラークシャサに由来
水天 - インド神話の神ヴァルナに由来
風天 - インド神話の神ヴァーユに由来
毘沙門天 - インド神話の神ヴァイシュラヴァナに由来
伊舎那天 - インド神話の神シヴァに由来
地天 - インド神話の神プリティヴィーに由来
日天 - インド神話の神スーリヤに由来
月天 - インド神話の神チャンドラに由来
四天王
持国天（東方を守護）
増長天（南方を守護）
広目天（西方を守護）
多聞天（北方を守護）
兜跋毘沙門天
刀八毘沙門天
八大夜叉大将
宝賢夜叉（ほうけんやしゃ）
満賢夜叉（まんけんやしゃ）
散支夜叉（さんしやしゃ）
衆徳夜叉（しゅうとくやしゃ）
応念夜叉（おうねんやしゃ）
大満夜叉（だいまんやしゃ）
無比力夜叉（むひりきやしゃ）
密厳夜叉（みつごんやしゃ）
毘沙門天二十八使者
プロトン
プロトン（proton）は英語で陽子のことを指す。
プロトン 水素原子
軽水素の陽イオン(1H+)を指す呼称。また、しばしば（同位体組成を問わない）水素の陽イオン全般に対して「プロトン」の語が用いられるが、正式にはヒドロンと呼ぶことが推奨されている。
詳細は、陽子、ヒドロン、水素イオン、水素分子イオン、プロトン化水素分子、ラジカル (化学)を参照。
釈迦如来
釈迦如来（しゃかにょらい）、梵名ヴァジュラアーサナ（Vajrāsana）は、仏教の開祖である釈迦の如来としての名。釈迦牟尼仏、釈迦牟尼如来、釈迦牟尼世尊とも呼ばれる。
本項では、仏教教義の観点から見た、開祖としての釈迦如来、信仰対象としての釈迦 如来について述べる。歴史上存在した人物としての釈迦（ゴータマ・シッダールタ、史的ブッダ）については「釈迦」の記事を参照のこと。
釈迦如来 釈迦如来の教義上の解釈
仏教では、キリスト教の三位一体論や両性説（神の子イエスは人間を救うため受肉してこの世に現れた存在であるという教義）のように宗派を超えて正統とされる教義が存在しないため、釈迦如来の教義上の認識解釈は多種多様である。
上座部仏教では、仏陀は釈迦如来ただ一人であり釈迦如来のみを信仰の対象とする。釈迦は悟りを得て仏陀となり輪廻から解脱したため、入滅後は仏陀が現世に現れることはありえないとする。また大乗仏教の毘盧遮那仏や大日如来のように釈迦如来より上位に位置する仏を想定しない。釈迦如来の前世については『パーリ仏典』のジャータカに詳しい。
大乗仏教では一般に三身説をとるが、姿・形をもたない宇宙の真理たる法身仏、有始・無終の存在で衆生を救う仏である報身仏（人間に対する方便として人の姿をして現れることもある）に対して、応身仏である釈迦如来は衆生を救うため人間としてこの世に現れた仏であると説明される。
『華厳経』では、釈迦如来は衆生を救うため法身の毘盧遮那仏によって遣わされた存在、または毘盧遮那仏の化身と解釈される。『華厳経』では悟りの奥義や、仏の世界観、また自ら（釈迦如来）の他にも毘盧遮那仏の化身として複数の如来が存在していることが語られている。
釈迦如来 釈迦如来の教義上の解釈
『法華経』では、釈迦は現世に現れる前から既に仏陀であり、衆生を救うため受肉し人間としてこの世に現れたが（応身仏）、入滅後も法身仏として存在していると解釈する（久遠常住）。「方便して涅槃を現わす」という言葉で表されるように、釈迦如来の生涯は人間に教えを説くための方便としてそのように演じてみせたと解釈される（仮現説）。
『阿弥陀経』は釈迦如来が阿弥陀如来と西方浄土について説くという内容だが、阿弥陀如来への帰依を最重視する浄土真宗では、釈迦如来は阿弥陀如来の存在を説くために現れた存在だと解釈される。
真言宗では全ての仏の本地仏は大日如来であり、釈迦如来は人間を救うために現世に現れた大日如来の化身であると解釈する。
釈迦を単なる人間ではなく超人的存在と捉える三身説は、キリスト教の三位一体論や両性説とよく比較研究されることが多いが、キリスト教では「イエスは人間である」という説や三位一体論を否定する教派は異端として完全に排斥されたが、仏教では「釈迦は人間である」という教派が完全に消滅することはなく、大乗仏教の各教派内でも「釈迦は何者であったか」という認識が教派ごとに異なることから、植田重雄は三身説と三位一体論を単純に比較することは難しいと論じている。
釈迦如来 伝承による釈迦如来の過去世
スメーダ（『ブッダワンサ（仏種生経）』『ジャータカ』）
燃燈仏のもとで修行していた行者。燃燈仏から、未来に仏陀になると予言される。
浄幢菩薩（『ラリタヴィスタラ（方広大荘厳経）』）
スメーダが輪廻転生を繰り返し、兜率天に生まれた姿。釈迦の前世。
長邦（『観世音菩薩往生浄土本縁経』）
バラモン僧。早離（そうり）、速離（そくり）という子がおり、それぞれ観音菩薩、勢至菩薩となる。
釈迦如来 仏像としての釈迦如来
釈迦如来は、インド以来、広く仏教の流布した地域で造像されるようになった。その中心は、実在の釈迦の伝記としての仏伝を絵解き風に造形化したもの、あるいは、その一場面を単独で造像したものなどであった。
日本では、誕生像、苦行像、降魔像、説法像、涅槃像などとして造像が行なわれた。なかでも説法像が一番一般的な造形であり、説法印などによって、釈迦が法を説く姿を表現している。
作例としては、奈良の法隆寺金堂、京都の蟹満寺の銅像、奈良の室生寺金堂、京都の大報恩寺の木像などが著名となっている。また、京都清凉寺の瑞像を模した清凉寺式釈迦如来も広範に流布している形式である。
釈迦三尊として祭壇に置かれる場合が多く、脇侍は文殊菩薩と普賢菩薩が多い。法華宗・日蓮宗では三宝尊（一塔両尊）の形式がとられることが多い。これは中心が題目の書かれた多宝塔（宝塔）で両脇に釈迦如来と多宝如来が祭祀者から見て左右に並び、その下に僧としての日蓮像がある。
密教において釈迦如来の身色は黄金色で表され、面数は1、臂数は2、持物はなく、右手は触地印、左手は腰につけ、四魔の囲む獅子上の蓮華に置かれた金剛杵の上で結跏趺坐を組む。脇侍として弥勒菩薩が右に、観音菩薩が左に立つ。
国宝
重要文化財・その他
釈迦如来 舎利信仰
日本では、タイあるいはスリランカ政府より公式贈呈された遺骨が、浅草寺、道成寺、覚王山日泰寺、釈迦山大菩提寺に祀られている。
毘盧遮那仏
毘盧遮那仏（びるしゃなぶつ、梵: Vairocana）は、大乗仏教における信仰対象である如来の一尊。華厳経において中心的な存在として扱われる尊格である。密教においては大日如来と同一視される。
尊名は華厳経では「舎」の字を用いて毘盧舎那仏、大日経では「遮」の字を用いて毘盧遮那仏と表記される。
毘盧遮那仏 概要
毘盧遮那とはサンスクリット語の「ヴァイローチャナ」(Vairocana) の音訳で「光明遍照」（こうみょうへんじょう）を意味する。仏であることを明示するために、「仏」字を付して毘盧舎那仏と表現されることが一般的である。頭の文字を略して盧遮那仏（るしゃなぶつ）、遮那仏（しゃなぶつ）とも表される。
大乗仏教の教義では三身(説)における法身仏で、宇宙の根本仏であるとされる。『華厳経』では、釈迦如来は衆生を救うため法身の毘盧遮那仏によって遣わされた存在、または毘盧遮那仏の化身と解釈される。
仏像では、聖武天皇の発願により造られた東大寺盧舎那仏像（奈良の大仏、東大寺大仏）が有名。現存しないが、豊臣秀吉の発願した方広寺大仏（京の大仏）も毘盧遮那仏であった。
鑑真が開創した唐招提寺金堂の中尊も、天平時代の脱乾漆像として有名であり、鑑真が中国からもたらした盛唐様式の作風を伝える彫刻として貴重な存在である。
毘盧遮那仏 密教
真言宗などの密教における「摩訶毘盧遮那仏」（大毘盧遮那仏、Mahāvairocana、マハー・ヴァイローチャナ）は、大日如来と呼ばれ、成立の起源を、ゾロアスター教の善の最高神アフラ・マズダーに求める学説がある。
仏語
仏語
「ふつご」と読む ⇒ フランス語。仏蘭西語の略。
「ぶつご」と読み、
仏（ぶつ、ほとけ）の語った言葉、仏の教え ⇒ 仏教
仏教に関する言葉 ⇒ 仏教用語一覧
大仏
大仏（だいぶつ）は、大きな仏像を指す通称。中国などアジアの仏教圏では、天然の岩壁を彫刻した磨崖仏などが古くから造られてきた。日本においては、奈良時代に聖武天皇が、国家の安寧と民の幸福を祈願して東大寺に奈良の大仏（東大寺大仏）を造立したのを嚆矢とする。以降、現代に至るまで、大きな功徳を求めた願主によって各地に大きな仏像が造られてきた。
釈迦の背丈が1丈6尺あったという伝説から、その高さで造られた仏像を丈六仏（じょうろくぶつ）という。背丈を基準としているため坐像の場合は、約半分の大きさになる。一般的には「丈六仏」より大きい仏像を「大仏」というが、その定義より小さくても「大仏」と称するものもある。
また、大仏を安置する仏堂を大仏殿（だいぶつでん）と呼ぶことがあり、東大寺の大仏殿（金堂）が有名である。
大仏 主な大仏
日本三大仏は、日本にある大仏の中から代表的な3尊を選んだものである。うち2尊は、上記のうち奈良の大仏と鎌倉大仏が挙げられる。残る1尊は時代とともに変遷しており、第二次世界大戦後以降は富山県高岡市の大佛寺にある高岡大仏や岐阜県岐阜市の正法寺にある岐阜大仏、兵庫県神戸市の能福寺にある再建された2代目の兵庫大仏など諸説ある。
538年
538年（538 ねん）は、西暦（ユリウス暦）による、平年。
ISO/IEC 10646
ISO/IEC 10646 (UCS; 英: Universal Coded Character Set) は、符号化文字集合や文字符号化方式などを定めた、文字コードの国際標準のひとつで、業界規格のUnicodeと概ね互換である。日本の対応規格はJIS X 0221（国際符号化文字集合）。
文字空間(0 - 10FFFF16)、収録されている文字、それらの符号位置、英語でつけられた文字の名前、文字符号化方式(UTF-8, UTF-16, UTF-32)はUnicode規格と全く同じである。ただし、文字空間は古い規格では21ビットのUnicodeをベースにして文字空間を31ビットに拡張したものとされ、Unicodeの最大値であるU+10FFFFより大きなコードも使用できるという点でUnicodeと異なっていた。しかし、2006年の改訂によりUnicodeで使用できない領域には文字が「永久に定義されない」こととされ、2011年の改訂では明確に0 - 10FFFFと定義され同一となった。
ISO/IEC 10646
面 (plane)、区 (row)、点 (cell) として分けられ、Unicodeと同じ第0面の基本多言語面 (BMP; 英: Basic Multilingual Plane) と追加面の第1 - 16面までの範囲で文字が定義されている。古い規格では群 (group) という分類もあったが2011年の改訂で廃止された。
ISO/IEC 10646 制定の経緯とその影響
この規格は制定の一歩手前の段階までは、現在の姿とはかなり異なる仕様だった。4オクテットの符号であり、各オクテットをそれぞれ群、面、区、点とする。各面には従来のコントロール領域を避けた0x20 - 0x7Fと0xA0 - 0xFFの範囲に文字を割り当てる。その範囲にISO/IEC 2022に従った構造の各国コード（ISO/IEC 8859やJIS X 0208、GB 2312など）を平行移動してそっくり収容するという、従来のコード系との互換性を最大限に尊重した構成をとっていた。
この案は1990年に国際標準の一歩前の段階のDIS (Draft International Standard) として作成されたが、1991年6月の投票で否決された。その理由は、同じ時期にアメリカの企業群がUnicode仕様を作成したため、同じ目的の規格が2つ作られることを避けることだった。
ISO/IEC 10646 制定の経緯とその影響
その後、DIS 10646とUnicodeとを一本化する作業が行われた。既存規格との整合性を重んじたDIS 10646に対して、Unicodeは各種アルファベット類は新規割り当て、漢字は日中韓を統合、符号位置はコントロール領域まで全て使って2オクテット固定という、全く異なる方針で設計されていた。結果として、「群・面・区・点」という用語は残しながら、第0群第0面を基本多言語面 (BMP) と称し、BMPにUnicodeをそっくり入れてその他の群・面は未使用という、実質2オクテットの符号となった。
結局、Unicodeに乗っ取られ第1版とは似ても似つかぬ符号になったDIS 10646第2版が、そのままInternational Standardとして制定されることとなった。1993年のことである。
このような経緯をたどり、既存規格との対応が不明確な定義になってしまったため、既存規格とのコード変換において、似たような形の多い記号のどれに対応させるのかの判断が困難となる問題が生じた。これにより、製品によってコード変換が異なる問題が常態化し、この問題に起因する文字化けは今に至るまで解決の目処が経っていない。ただし漢字については、元になった各国規格の符号位置が明示されているため変換の違いは生じていない。
ISO/IEC 10646 制定された規格群
※ 1999年9月以降、2000年9月までに成立したAmendmentおよびTechnical Corrigendumは、発行されずそのままISO/IEC 10646-1:2000に組み込まれた。
ISO/IEC 10646 文字符号化方式
Unicodeの『UTF』が『Unicode Transformation Format』を意味するのに対し、ISO/IEC 10646の『UTF』は『UCS Transformation Format』を意味する。
UTF-1
初期に提案されていた、8ビットコードによる方式。ほとんど利用されることなくUTF-8にとって代わられた。
UCS-2
2オクテット固定のUCS (Universal Coded-Character Set) である。BMP（基本多言語面）以外の文字を使うことはできず、すべての文字を符号化できるUTF-16にとって代わられた。2011年の改訂ではdeprecated（廃止予定）とされた。
UTF-8
UnicodeのUTF-8と同じ。
UTF-16
UnicodeのUTF-16と同じ。
UTF-32 (UCS-4)
UnicodeのUTF-32と同じ。
ISO/IEC 10646 実装レベル
古い規格では実装レベルというものが考えられていたが2011年の改訂で廃止され、Level3の実装のみを扱う事となった。
Level 1
合成列などを扱わない
Level 2
必要な合成列を扱える
Level 3
全て扱える
Unicodeは、Level 3の実装である。
Extended Unix Code
Extended Unix Code(EUC)は、UNIX上で使われてきた文字コードの符号化方式である。
などがある。
Extended Unix Code 概要
1980年代、UNIXを開発していたAT&Tはアメリカ合衆国以外の国へUNIXを展開するにあたって各国固有の要求に対応するため、UNIXシステムを世界共通の機能となる国際機能と、各国固有の処理に必要な機能となる各国語機能に分けて定義した。この国際機能において、1つの基本コードと3つの拡張コードから構成される4つのコードセットを使用できる文字コードをExtended UNIX Code (EUC; 拡張UNIXコード) として定義した。
厳密にはEUCのコード体系にはバイト単位の可変長コードである「パックフォーマット」と、2バイト固定長の「完全2バイトフォーマット」がある。前者は情報交換用、後者は内部処理用で、一般にEUCという場合前者を指す。ここでも前者について解説する。
EUCのパックフォーマットはISO/IEC 2022を基に、以下のようなサブセット化を行った体系である。
補助コードセットが0x80-0xFFの範囲で表されるため、主コードセットと衝突することがない。すなわちShift_JISにおける2バイト目が5C等になりうることによる問題が起きないというメリットがある。
各国向けに局所化した各国語機能のそれぞれの版について、日本語では「 - 語EUC」や「 - 語版EUC」のように呼ばれることが多い。
Extended Unix Code 日本語EUC
日本語EUCはG1-G3に日本産業規格 (JIS) の文字集合を割り当てている。
一般に日本語EUCという場合こちらを指す。EUC-JPともいう。ここで、JPは日本国を表す国・地域コードであって、日本語を表す言語コード (ja) でない。
1986年にAT&Tによって定義されて以来、UNIXの標準的な日本語コードとして広く使われてきた。1990年にJIS X 0212（補助漢字）が新たに策定されたが、1992年にUNIX Internationalが発行した『UNIX System V リリース 4 (SVR4) 日本語環境共通規約』において、JIS X 0201 カタカナとJIS X 0212 補助漢字は実装が必須ではないとされていた。このため、特にJIS X 0212は実装されていないことも多い。通信などで用いる場合はこの点に注意が必要である。
なお、G2とG3を使わない場合はJIS X 0208:1997の「国際基準版・漢字用8ビット符号」と同一となる。
JIS X 0213:2004ベースのものをEUC-JIS-2004という（2000年版はEUC-JISX0213）。JIS X 0213の附属書3に記載がある。フリー/オープンソースソフトウェアなどで使われていることがある。
Extended Unix Code 韓国語EUC
1987年にAT&Tユニックス・パシフィックよりリリースされた Korean Application Environment Release 1.0 (KAE 1.0) で規定され、1992年に韓国標準協会によってKS X 2901（旧KS C 5861）『ハングルUNIXエンバイロメント』として標準化された。EUC-KRともいう。ここで、KRは韓国の国・地域コードであって、朝鮮語の言語コード (ko) ではない。単にKS C 5601といった場合でも、文字集合としてのKS C 5601でなく、EUC-KRのことを指している場合が多い。
EUC-KRを拡張したUHC (Unified Hangul Code) という体系も存在する。
Extended Unix Code 簡体字中国語EUC
中国で広く使われていた。EUC-CNともいう。ここで、CNは中国の国・地域コードであって、簡体字の用字系コード (Hans) でも中国語の言語コード (zh) でもない。単にGB 2312といった場合でも、文字集合としてのGB 2312でなく、EUC-CNのことを指している場合が多い。
EUC-CNを拡張したGBKという体系も存在する。
Extended Unix Code 繁体字中国語EUC
EUC-TWともいう。ここで、TWは台湾の国・地域コードであって、繁体字の用字系コード (Hant) でも中国語の言語コード (zh) でもない。台湾の規格であるが、あまり使われておらず、一般にはBig5が使われる。
G2の文字は以下の4バイトで構成される。
Extended Unix Code 課題
EUCの利用は、すべての文字コードを包含したり、複数の文字コードを切り替えて表示する機能の必要性を否定する場合があり、多くの文字を表示する流れに対して後ろ向きであった点が課題である。これは、文字コード自体の課題ではなく、EUCを利用しているプログラマ、利用者の課題である。
名前
名前（なまえ、希: όνομα、羅: nomen、英: name）とは、人間の身分や門地を示し生き物や物体に与えられる名称のことである。
名前をつけることを「名付ける」「命名（めいめい）する」という。
名前は一概にすると氏名を指す全名と個人を指す個人名に対して名前と呼ぶ二通りの意味合いがある。
一般的に日本では、姓を「上の名前」と呼び個人名に対しては「下の名前」と呼ばれることもある。
名前 一般論
すべての事象には名がある。我々は先ずその対象に名前を付ける。そのためには対象の概念を明確にし、またそれ以外の事象との区別を持たなければならない。この過程で名前を付けた対象が明確になる。名前がないものは、他人にその対象を説明できないため存在を認識させるのが難しく、自らもその対象を明確にできなくなる。ただし必ずしも固有の名前を持つ必要はなく、限られた人びとの間で認識が明確になるのであれば対象を説明する語を使い、「右側の○○」・「白い○○」・「○○にいる人」・「昔の○○」などで足りることはある。しかし、より多くの人々に他とは区別して認識してもらうためにはやはり固有名が必要となってくる。
自然観察の際に、まず生き物の名前を覚えることから始めることが多いが、これは覚える行為に価値があるのではなく、名前を覚えることで、それまでどれも同じに見えていたものの区別がつくようになるからである。たとえばハコベの名を覚えれば、雑草として区別せずに一緒にしていたものの中から、それが見分けられるようになるし、さらにウシハコベやコハコベを知れば、ハコベの中にもさらに違いがあることもわかるようになる。
名前 一般論
名前は元々あるものではなく、人間がそれを個別に把握すべき対象として認識した際に与えるものである。したがってどの範囲で名を与えるかは人間とそれとの関わりによって変わる。たとえば文化が違えば個々の物に対する関わりの深さも異なり、これが名前にも影響するため、言語によって名の扱いも異なる。たとえば日本語において、ウシという動物の名は「牛」である。それに含まれる差異については雄牛・雌牛・仔牛と接頭語をつけ、あるいは牛肉と語尾をつけて説明的に扱う。だが英語では牛は総称としては 「cattle」、雄牛は 「bull」、雌牛は 「cow」、仔牛は 「calf」、牛肉は 「beef」 と、すべて全く異なった語を当てる。
名前 人名
個人を特定するために附けられる名前は、その方法として名の中に祖先から受け継ぐ「ミタマ」や血統を表す名を含める。これを「姓」といい、個人を血統という共通の要素でグループ化して区別できるようになる。血統を受け継ぐ一族の中心となる家系を「宗家」という。しかし日本においては古くから上位権力による支配のため、地位で区別する「氏」があり、宗家の継承には血族を継ぐ「嫡流継承」と、能力や資格、官位を継ぐ「氏的継承」の2つの解釈があった。さらに財産としての土地を相続する惣領という考え方や、養子や猶子の制度が加わり、複雑化してもとの血統を意味が失われた経緯がある。後世はこれらが混同して使われ、グループである家系や相続の関係が不明となる場合もあった。
個人の特定には家系（英: family name , last name , surname)を表す「氏」・「姓」に加え、「名」・「字」・「諱」・「諡」が使われる。「名」は「名字」というときは「姓」と同様にグループを指すが、「姓名」というときは「姓」に続けて記すことで個人を特定する名前を指す。以下では「名字」として説明する。
名前 人名
諱：「諱（いみな）、本名、実名、英: given name , first name」。元服によって附けられる。個人を指すのに普段は使われずに「字（あざな）」で呼ぶ。これを実名敬避俗という。少人数の中で個人が特定できる場合に行われた が、権力者である場合は大人数の中にあっても存在が「唯一」になることから、後に崇敬が理由に加わって常態化し、後世ではその諱を他人が使うことが避けられた。本人が自分で使う場合があり、これを「名乗り（なのりな）」という。
これらを全て並べて用いる習俗を複名という。徳川家康に当てはめると『「源」「朝臣」「徳川」「次郎三郎」「家康」』 となる。
また朝廷からは「正一位」「大相國 一品」が贈位され、これを名に冠する場合もある。
この他、立場、年齢、職業、目的などで自ら別名を名乗ったり、ほかから名付けられたりすることもあり、遂には本来の目的である個人の特定に至らないことがある。
日本においては、戸籍法によって戸籍として使用できる漢字は簡単な人名用漢字から使用するよう決められている。問題になるような命名がなされると、命名権の濫用として出生届を拒否される。外国においては、アイスランド人の名前などのように事前のリストから選ばれたり、問題がある命名に罰金刑が制定されている場合がある。
名前 人名
多くの国では、父方の姓を引き継ぐ父称である。また、名前を親以外の他人、名付け親、キリスト教では代父母、ユダヤ教ではサンダークが付ける場合もある。
英語
イギリスの王族は、生まれた後ロイヤル・ハイネスを意味する称号 HRH が姓として与えられる。君主や王位継承者が姓を称することは法律上義務付けられていない。1917年以前は、王族は姓を持っておらずジョージ5世が第一次世界大戦の反ドイツ感情の高まりをうけて1917年7月17日付勅令でイギリス男系の王族がウィンザー姓を名乗るようになった。エリザベス2世は、女系なので1960年の枢密院令によって結婚相手のマウントバッテン家と合わせてマウントバッテン＝ウィンザーを名乗り、以後はエリザベス2世女王の家系は必要ないなら姓を名乗らず、必要なら『HRH』か『マウントバッテン＝ウィンザー』のどちらかを名乗る。
個人が死亡した後は「諡、おくりな(贈り名)」、あるいは「戒名」や「諡号」が附くことがある。家康の場合、『「東照大権現」・「安国院殿」・「徳蓮社崇譽」・「道和」・「大居士」』となる。
結婚、元服、帰化などの節目で改名する事がある。
職業上使われる
名前 プログラムにおける名前
プログラムにおいては、スコープが異なる限り一意性（唯一無二であること）を保証することは要件とされていない場合が多い。一意性を保証するために名前空間を導入することもある。
名前 学問
自然科学では、星や化学物質等を一定の法則によって命名する。
名前 商業の名前
商号・社名の由来一覧・ブランド・商標
商品名については、関連があるとイメージが結びつきやすいが、全く関係がない名前を付けることも珍しくはない。多くの商品や役務では仕様違いを区分するために英数字などによる正式名称（型番）が付けられ、販売促進上それらをまとめて「ペットネーム（愛称）」と呼ばれる名称で呼ぶことがある。
他には、球場などの名前を期間限定で自由に付ける権利を売買する事例もある。
名前 芸術
西洋美術史において、作家が作品に『題名』を付ける文化となったのは18世紀頃のことである。そのため、それ以前の作品は美術館が変わると同一作品でありながら別の名前を用いられる。また、日本においてベートーヴェンの『運命』と呼ばれる交響曲第5番は、生みの親のベートーヴェン、ドイツでは『運命』という語は使われていない。
名前 動物
イルカやテリルリハインコは、親などから命名され、名前を呼び合う習性がある。
また、猫や犬などのペットは、人間から付けられた名前を自分の名前として認識する能力がある。また、猫は人間に付けられた同居猫の名前も認識している。
UTF-8
UTF-8（ユーティーエフはち、ユーティーエフエイト）はISO/IEC 10646 (UCS) とUnicodeで使える8ビット符号単位（1–4バイトの可変長）の文字符号化形式および文字符号化スキーム。
正式名称は、ISO/IEC 10646では “UCS Transformation Format 8”、Unicodeでは “Unicode Transformation Format-8” という。両者はISO/IEC 10646とUnicodeのコード重複範囲で互換性がある。RFCにも仕様がある。
2バイト目以降に「/」などのASCII文字が現れないように工夫されていることから、UTF-FSS (File System Safe) ともいわれる。旧名称はUTF-2。
UTF-8は、データ交換方式・ファイル形式として一般的に使われる傾向にある。
当初は、ベル研究所においてPlan 9で用いるエンコードとして、ロブ・パイクによる設計指針のもと、ケン・トンプソンによって考案された。
UTF-8 エンコード体系
ASCII文字と互換性を持たせるために、ASCIIと同じ部分は1バイト、その他の部分を2–6バイトで符号化する。4バイトのシーケンスでは21ビット (0x1FFFFF) まで表現することができるが、Unicodeの範囲外となる17面以降を表すもの（U+10FFFFより大きなもの）は受け付けない。
また、5–6バイトの表現は、ISO/IEC 10646による定義とIETFによるかつての定義で、Unicodeの範囲外を符号化するためにのみ使用するが、Unicodeによる定義とIETFによる最新の定義では、5–6バイトの表現は不正なシーケンスである。
後述のセキュリティの項に詳細はあるが、符号化は最少のバイト数で表現しなければならない。そのため、バイト数ごとにUnicodeの符号位置の最小値（下限）も設けている。
例えば、1バイトで表現するASCII文字は2バイト以上でも表現できるが、バイト数ごとの下限によってこれを回避している。
ビットパターンは以下のようになっている。
UTF-8 エンコード体系
* 第1バイトがE0のときに第2バイトが80-9Fの範囲を、または同F0のときに80-8Fの範囲を取るものは冗長な符号化となるため許されない。第1バイトがEDのときに第2バイトがA0以上となるものはサロゲートペアのための符号位置にあたり、また同F4のときに90以上となるものはUnicodeの範囲外となるため、UTF-8ではやはり許されない。
Unicodeの符号位置を2進表記したものを、上のビットパターンのx, yに右詰めに格納する（最少のバイト数で表現するため、yの部分には最低1回は1が出現する）。符号化されたバイト列は、バイト順に関わらず左から順に出力する。
1バイト目の先頭の連続するビット "1"（その後にビット "0" が1つ付く）の個数で、その文字のバイト数がわかるようになっている。また、2バイト目以降はビットパターン "10" で始まり、1バイト目と2バイト目以降では値の範囲が重ならないので、文字境界を確実に判定できる。すなわち、任意のバイトの先頭ビットが "0" の場合は1バイト文字、"10" の場合は2バイト以上の文字の2番目以降のバイト、"110" の場合は2バイト文字の先頭バイト、"1110" の場合は3バイト文字の先頭バイト、"11110" の場合は4バイト文字の先頭バイトであると判定できる。
7バイト以上の文字は規定されないため、0xFE, 0xFFは使用されない。このため、バイト順マーク (BOM) に0xFEと0xFFを使用するUTF-16やUTF-32が、UTF-8と混同されることはない。
UTF-8 特徴
文字列の検索を単なるバイト列の検索として行っても、文字境界と異なる個所でマッチしてしまうことがない。たとえばShift_JISで「¥」(0x5C) を検索すると「表」(0x95 0x5C) の2バイト目にマッチしたり、EUC-JPで「海」(0xB3 0xA4) を検索すると「ここ」(0xA4 0xB3 0xA4 0xB3) にマッチしたりするのと同様のことが起きない。このため、マルチバイト文字を意識せず、ISO 8859-1などの8ビット文字向けに作られた膨大なプログラム資産を、比較的少ない修正で再利用できる。
ただし、他のUnicodeの符号化と同様に、単にバイト列の比較では文字列が同一か判断できない場合がある。詳細は、Unicodeの等価性および正規化を参照のこと。
複数のUTF-8文字列を、単なる符号なし8ビット整数の配列とみなして辞書順ソートした結果は、Unicodeの符号位置の辞書順のソート結果（すなわちUTF-32に変換した後にソートした結果）と等しくなる。これに対して、サロゲートペアを含むUTF-16文字列を符号なし16ビット整数の配列とみなしてソートした結果は、Unicodeの符号位置の辞書順のソート結果と異なりうる。
UTF-8 特徴
UTF-8による符号化では、漢字や仮名などの表現に3バイトを要する。このように、東アジアの従来文字コードではマルチバイト符号を用いて1文字2バイトで表現されていたデータが、1.5倍かそれ以上のサイズとなる。同様に、ISO/IEC 8859-1では1バイトで表現できた非ASCIIのラテン文字（ウムラウト付きの文字など）も2バイトとなるし、その他のISO/IEC 8859シリーズに属する文字符号ではデータ量がさらに増大しうる。
なお、1バイトが9ビットである処理系では、この問題をあまり発生させずに符号化できるはずである。このアイディアに基づいたジョークRFCがRFC 4042 "UTF-9" として2005年のエイプリルフール（4月1日）に公開された。
UTF-8 サロゲートペアの扱い
UTF-16ではサロゲートペアで表されるような、基本多言語面外の符号位置をUTF-8で表す時は、変換元がUTF-16でサロゲートペアの時には U+D800–U+DBFF, U+DC00–U+DFFF を表すUTF-8にそのまま変換したりはせず、U+10000–U+10FFFF の符号位置にデコードしてから変換する。そのままUTF-8で符号化したような列は不正なUTF-8とされる。
サロゲートペアのままUTF-8と同等の符号化を行う符号化は、CESU-8 (Compatibility Encoding Scheme for UTF-16: 8-Bit) として別途定義されている。実用に供されている例としては、Oracle Databaseのバージョン8以前において、UTF-8として3オクテットまでのオクテット列しか扱えなかったために定義されたものである。本来のUTF-8における4オクテット列の代わりに、サロゲート符号位置を表す3オクテット列のペア（上位が ED A0 80–ED AF BF、下位が ED B0 80–ED BF BF）で表現される。
UTF-8 サロゲートペアの扱い
現在のOracle Databaseでも、CESU-8を「UTF8」として、「普通のUTF-8」を「AL32UTF8」として扱っているため注意を要する。MySQLでも「utf8」を指定した場合は4オクテット列が扱えず、CESU-8相当の符号化を必要とする（4オクテット列対応のUTF-8は「utf8mb4」として別途定義されているが、MySQL 5.5.3以降でないと使用できない）。
また、Javaの一部の内部実装で用いられているModified UTF-8も、サロゲートペアをそのまま残す仕様となっている。ただし、NULL文字をC0 80とエンコードする（これもUTF-8規格外）点で、CESU-8とも異なる実装となっている。
UTF-8 セキュリティ
UTF-8のエンコード体系には冗長性があり、同じ文字を符号化するのに複数の表現が考えられる（例: スラッシュ記号である「/」を 0x2F という1バイトで表現するのではなく、0xC0 0xAF という2バイトもしくはそれより大きなバイト数で表現する）。かつてはそのような表現も許容されていたが、ディレクトリトラバーサルなどの対策として行われる文字列検査を冗長な表現によりすり抜ける手法が知られるようになったため、現在の仕様では最少のバイト数による表現以外は不正なUTF-8シーケンスとみなさなければならない。
ISO/IEC 10646の定義が5バイト以上の表現を許容していることにより、正しくない実装を行ったバグのあるシステムにおいてエンコード時にバッファオーバーフローが発生する可能性も指摘されている。
UTF-8 バイト順マークの使用
UTF-8で符号されたテキストデータはバイト順マーク (BOM) の付加は不要である（エンディアンに関わらず同じ内容になるので）。
しかし、テキストデータがUTF-8で符号化されていることの標識として、データの先頭にEF BB BF（16進。UCSでのバイト順マーク U+FEFFのUTF-8での表現）のシーケンスをBOMとして付加することが許される（推奨はされない）。
BOM付きには対応しないプログラムは標準的ではある。それらは、BOMを余分なデータとみなすので、問題も生ずる。
例えば、Unix系OSにおける実行可能スクリプトは、ファイル先頭が「#!」から始まるとき、それに続く文字列をインタプリタのコマンドとして認識するが、多くのシステムでは、このシーケンスが存在するとこの機能が働かず実行できない。PHPでは、<?PHPの前に出力されるため、header()関数の実行に失敗する原因となる。HLSLやGLSLのシェーダープログラムコンパイラ（fxcやglslangValidator）はBOMを処理できず、コンパイルエラーとなる。
UTF-8 バイト順マークの使用
一方、一部のテキスト処理アプリケーション（テキストエディタなど）ではBOMを前提とした動作をする。同様にこのシーケンスがない場合、UTF-8と認識できないプログラムも存在する。たとえば、Microsoft Excelでは、CSVファイルを開くとき、このシーケンスが付加されていないUTF-8の場合は正常に読み込むことができず文字化けを生ずる。Microsoft Visual C++は既定でBOMなしUTF-8を認識せず、システムロケール設定に応じたマルチバイトエンコーディングとみなすが、Visual C++ 2015以降ではコンパイルオプションを指定することでBOMなしUTF-8を認識することができるようになった。
Windows 10のメモ帳アプリは、2019年の19H1アップデートからBOM無しUTF-8がデフォルトになった。
また、BOMがなくともエンコード自動推定によってUTF-8とShift_JISなどを区別することのできるプログラムもあるが、ASCII部以外の文字が少ない場合に誤認することが多い。
プロトコルが常にUTF-8であることを強制しているものである場合はこのシーケンスを禁止するべきで、この場合ファイル先頭にこのシーケンスが現れると “ZERO WIDTH NO-BREAK SPACE” と見なされる。逆にプロトコルがそれを保証しない場合このシーケンスは禁止されずファイル先頭のそれはバイト順マークと見なされる。
UTF-16
UTF-16 (UCS/Unicode Transformation Format 16) とは、UnicodeおよびISO/IEC 10646の、符号化フォームおよび符号化スキーム（文字符号化方式を参照）のひとつである。
UTF-16では、1文字が、16ビットの符号単位が1つまたは2つで符号化される。これが「-16」の名の由来である。基本多言語面（BMP）内の文字は、符号単位1つの16ビットで表される。BMP以外の文字は、符号単位2つの32ビットで表される。なお、UTF-16は2バイトコードだと誤解されることがあるが、このように4バイトのこともあるため間違いである。
Unicodeにおいては、厳密には、文字符号化フォーム（英: Character Encoding Form）の1つの名称であり、かつ、UTF-16符号化形式のための文字符号化スキーム（英: Character Encoding Scheme）の1つの名称でもある。UTF-16符号化フォームのための文字符号化スキームには、UTF-16の他にUTF-16BE、UTF-16LEがある。
UTF-16 符号化
UTF-16では、Unicodeの代用符号位置を除いた符号位置（Unicodeスカラ値という）を、16ビット符号なし整数を符号単位とした符号単位列で表す。符号単位列は1つまたは2つの符号単位からなる。すなわち、合計は16ビットまたは32ビットである。
BMPに含まれるU+0000–U+D7FFとU+E000–U+FFFFは、そのまま符号単位1つで表す。BMP以外のU+10000–U+10FFFFは、表のようにビットを配分して、符号単位2つで表す。
このとき使われる、U+D800–U+DFFF の符号位置を、代用符号位置（Surrogate Code Point）と呼び、BMP外の1つの符号位置を表す連続した2つの代用符号位置のペアをサロゲートペアと呼ぶ。代用符号位置に使うため、BMPのこの領域には文字が収録されておらず、UTF-16以外のUTF-8、UTF-32では使用されない。
Unicodeの符号位置の最大値がU+10FFFFなのは、それがUTF-16で表せる最大値だからである。
UTF-16 符号化
UTF-16符号化フォームで表現された文字は、16ビット符号なし整数の符号単位列であり、プログラム内部での処理には都合がよいが、それでもって情報交換のためにファイルの読み書きや通信を行う場合は、適当な符号化スキームにより、バイト直列化する必要がある。
符号化スキームには、UTF-16、UTF-16BE、UTF-16LEの3種類ある。UTF-16BEは、16ビット整数をビッグエンディアンで直列化する。UTF-16LEは、リトルエンディアンで直列化する。UTF-16BE、UTF-16LEの場合は、バイト順マーク (BOM) の付与は許されない。UTF-16の場合は、BOM でエンディアンを明示するか、上層のプロトコルで指定されておらずBOMも付与しない場合はビッグエンディアンにするよう決められている。
UTF-16 比較
UTF-8、UTF-32と比較して、一般的な日本語が主体の文章ではUnicode符号化方式の中では最小サイズとなる。追加面の文字が含まれる場合、バイト順にソートしても符号位置順とはならない。また、UTF-8と違いASCII互換ではない。
Shift_JISと比較して、Shift_JISでは1バイト文字と、2バイト文字の1バイト目と2バイト目の値範囲が一部重複しているが、UTF-16では1符号単位文字、サロゲートペアの前半の符号単位、後半の符号単位がすべて異なる値範囲を取る。そのため、Shift_JISであった、例えば「a」で検索すると2バイト目にマッチする場合がある、途中から読みこむと文字の区切りがわからないときがある、1バイト目や2バイト目が欠落した場合、後続の文字すべてが文字化けする可能性がある、などの問題は発生しない。UTF-16では欠落があっても影響を受けるのはその文字だけである。
UTF-16 利用
UTF-16符号化フォームは、Windows や Java（J2SE 5.0以上）で、内部表現に使われている。Windowsの内部表現では、16ビット符号なし整数を符号単位とするUTF-16符号化フォームとして扱い、ファイルなどでは、BOMあり（リトルエンディアン）のUTF-16符号化スキームが主である。
TCP/IPネットワークでは、プロトコルヘッダやMIME等の手段で文字符号化スキームを指定しない場合は、ビッグエンディアンに決められている。
Internet Engineering Task Force
The Internet Engineering Task Force（頭字語：IETF、インターネット技術特別調査委員会）は、インターネット、わけてもインターネット・プロトコル・スイート（TCP/IP）の技術面に関するNPOで標準化団体である。
アメリカ合衆国連邦政府の支援のもと活動を開始した。1993年以降は国際的な会員制の非営利組織であるインターネットソサエティの支援のもと、その標準化開発部門として活動している。ボランティアで運営を担う要員の経費は、一般にそれぞれの職業上の雇用主もしくは助成団体など後援者から受けている。
Internet Engineering Task Force 団体の構成
この団体はそれぞれ固有の主題ごとに、多数のワーキンググループ（作業部会（英語））と同好の士が集まるくだけた雰囲気の協議グループで構成される。どのタスクに取り組むか、主にそれらのグループからボトムアップで提言する方式を用いて活動する。グループ単位で座長ないし数名の共同座長を置き、グループの活動の趣旨ならびに期待される成果と達成時期を憲章にまとめている。
会員に参加要件や資格審査、年会費などはなく、メーリングリストに登録するか、団体主催の会議に出席して活動に参加する。会議参加費は2014年7月時点で1名650ドル、2018年半ばに全日程参加は一般875ドル（早期割引で700ドル）、1日券375ドル、学生150ドルであった。
会議では、最終的に何か決定を下さなければならない場合にハミングによる表決（ラフコンセンサス）を取るという特徴があり、票決は行わない。またほとんどの作業はメーリングリストを介して実施され、会議への出席は任意である。メーリングリストを介した作業も具体的な目標単位で組まれるため、達成するとワーキンググループを解散するか、憲章を更新して新しいタスクへ移行する。
Internet Engineering Task Force 団体の構成
取り組む主題はそれぞれのグループ内で協議し、主題を「エリア」と呼び互選の管理者（AD＝area director）を置く体制で、ほとんどのグループは共同管理者2名で進行している。ADはそのグループの代表を推薦し、ADとIETFチェアが構成する「インターネット開発運営グループ IESG（英語）」が団体全体の運営に責任を負う。2014年時点に扱った主題は、アプリケーション、全般（General）、インターネット、オペレーションと管理、リアルタイム・アプリケーションとその基盤、ルーティング、セキュリティ、トランスポートにわたった。
外部機関ならびにRFC編集者とIETFの交渉はインターネットアーキテクチャ委員会（IAB）が監督し、インターネット開発の長期的な技術の方向性を決める。またIETFにロジスティクス他のサポートを提供する部門を「IETF経営サポート活動」（IETF Administrative Support Activity＝IASA）（英語）といい、IABと「IETFオーバーサイト委員会」（IETF Administrative Oversight Committee＝IAOC）はその監督を担う。IABはさらにIETFがさまざまな企画で連携するプロジェクト特化型のInternet Research Task Force（IRTF）運営にも参画する。
Internet Engineering Task Force 団体の構成
ここに列挙したIESG、IAB、IAOCは、その役職の任命と再任、罷免を#推薦委員会（NomCom）に委任し、同委員会は、IETF会員10名と委員長1名で成り立つ。同委員はIETF会議の常連のボランティアから選ぶ。これまでNomCom裁定の罷免は発生していないものの、辞任に伴う再選は何度かあった。
IETFが政府管掌を離れた1993年以降、その活動の予算ならびに法律上の枠組みはインターネットソサエティから供与を受け、IETFとその姉妹組織のIAB、IRTFは存続してきた。IETFの活動資金には同ソサエティがIETF企業会員として参加費を支弁し、会議参加費と会議のスポンサー収入を組み入れるほか、公益団体としてen:Public Interest Registry（インターネットソサエティの傘下）から補助金を受給している。
2005年12月に設立したIETF評議会は、当団体が著作権を保有する著作物の管理を担当する。
インターネット開発運営グループ（IESG）を構成するIETFのエリア管理者とチェアパーソンは、インターネット標準の技術査定の最終判断を下し、IETFの日常管理の責任を負う。ワーキンググループから提言される決議要請を諮り、解説文書を標準のトラック（英語）に加筆するかどうか裁定する。
IESG委員長はIETFチェアパーソンを兼務し、前述のエリアのうち「全般」に属する。次のエリアはADを2名ずつ、この委員会に送り出す。
姉妹組織との窓口となる連絡員（リエゾン）と、兼務者として次の役割を設ける。
Internet Engineering Task Force 歴代の要職
チェアパーソンは推薦委員会によって選ばれ、任期2年で再選を認める。1993年に政府管掌を離れるまでは代表はIABが指名していた
以下の人々が代表を務めている。
Internet Engineering Task Force 主な出版物
機関誌
Internet Engineering Task Force ; Corporation for National Research Initiatives. Proceedings of the ... Internet Engineering Task Force. バージニア州レストン : en:Corporation for National Research Initiatives, 1986. OCLC 714735724. 発足前の会議録。オンライン版は検索のみ可能。
Internet Assigned Numbers Authority
Internet Assigned Numbers Authority（IANA、アイアナ、インターネット番号割当機関）とは、インターネットに関連する識別子を管理する機能である。IPアドレス・ドメイン名・トップレベルドメイン・ポート番号等の割り当て・管理などを行う。
アメリカの南カリフォルニア大学のISI所属のジョン・ポステルが中心となって始めた。当初は運営費用の一部がアメリカ政府により援助されていたが1998年にICANNが発足するなどインターネットの管理体制が変化し、2000年にその役割はICANNに引き継がれ、IANAはICANNにおける機能の名称となった。2016年からはICANNの子会社であるPublic Technical Identifiers (PTI) がその機能を担っている。
XML宣言に記述するエンコーディングの名前は、IANAに登録されたキャラクタセット名が使用される。
阿弥陀三尊
阿弥陀三尊（あみださんぞん）は、仏教における仏像安置形式の一つである。
阿弥陀如来を中尊とし、その左右に左脇侍の観音菩薩と、右脇侍の勢至菩薩を配する三尊形式である。根拠は『無量寿経』・『観無量寿経』である。
観音菩薩は阿弥陀如来の「慈悲」をあらわす化身とされ、勢至菩薩は「智慧」をあらわす化身とされる。
脇侍の観音菩薩は、頭上の髻の正面に阿弥陀の化仏（けぶつ）を表し、勢至菩薩は同じ位置に水瓶を表すので、両脇侍は比較的区別がつけやすい。
日本では、東京国立博物館が収蔵する「銅造阿弥陀如来及両脇侍像（法隆寺献納）」（重要文化財、飛鳥時代）や、橘三千代の念持仏と伝えられる法隆寺の「銅造阿弥陀如来及両脇侍像（伝橘夫人念持仏）」（国宝、飛鳥時代、大宝蔵院収蔵）などが古い作例である。
阿弥陀三尊 形式
主に下記の形式がある。
中尊は坐像、脇侍は跪坐とするものは、来迎形式の阿弥陀三尊像である。この場合、左脇侍の観音菩薩は往生者を迎え取るための蓮台を捧げ持ち、右脇侍の勢至菩薩は合掌する例が多い。
中尊は右手を施無畏の印、左手を刀印を結んだ像が一般的である。
また、地蔵菩薩と龍樹菩薩を含めて五尊像とした作例もみられる。