hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
文字コード 類似の用語
文字エンコーディングに関わる用語は頻繁に誤解・誤用される。下記では、用語の実際の使われ方と意味を紹介する。
「文字コード」という呼称は、頻繁に「符号値」と同じ意味で用いられる。つまり、文字と番号を対応させる体系だけではなく、"文字に与えられた数値・番号そのもの"を指した言葉としても使用される。一方、W3Cでは、文字コードを「文字エンコーディング」と訳しており、英語「character encoding」の直訳に近い表現となっている。また、IBMは「文字エンコード」という訳を使用している。
この語はたとえば、ソフトウェアの実装において、任意の文字コードが扱えるよう実装すること（たとえばruby 1.9のStringオブジェクト）を指してコードセット独立（CodeSet Independent, CSI）といったように使われる。
文字コード 類似の用語
MIMEではキャラクタセット（英語: charsetまたはcharacter set）という概念が用いられる。言葉通りには「文字集合」であるが、実際に意味しているものは文字コードに近い。
この「キャラクタセット」は「オクテットの並びを文字の並びに変換する方式」などと定義されている。MIMEで実現する電子メールメッセージなどの処理を主眼に置いた概念である。
インターネット上で用いることのできる「キャラクタセット」の登録と公開はIANAが行っている（「外部リンク」参照）。
Unicode文字符号化モデルでは、文字列をバイト列に変換する4段階の操作を総称して文字マップ（英: character map; CM）と呼ぶ。
IBMやマイクロソフトは独自に文字コードに番号（コードページ）を振って管理している。
文字コード 外字
外字とは表外字（規格表の外の文字）の略であり、ユーザがデザインして用いるユーザ定義文字や、メーカーなどが定義した環境依存文字（いわゆる機種依存文字）もしくはベンダ拡張漢字のことを指す。
外字というユーザが独自に文字を登録できる領域がある文字コードは複数存在する。Unicodeにおいては6,400+131,072文字の「PUA（Private Use Area=私用領域）」があり、Windows-31J（Microsoft Windows Codepage 932）にも1,880文字の外字領域がある。ユーザが独自にフォントを登録した文字（ユーザ定義文字）は、文書の交換時に配慮しない限りは他の環境で読むことができないため、互換性の上で重大な問題を引き起こす場合がある。ベンダ拡張文字の場合は、ユーザが表外字でないことを認識せずに利用してしまうことがあるため、より重大な問題を引き起こす（例として挙げれば、Windows環境（CP932）のローマ数字がMac環境では化けて表示されるなど）。
文字コード 外字
JIS規格においては、JIS X 0208で定義された文字集合に対してEUC-JPまたはShift_JISによる符号化を行う際、1〜94区に対応しない領域（EUC-JPやShift_JISでは94区に94点をかけた8,836を超える文字が定義可能であるため）や、1〜94区の範囲内であっても文字が定義されていない箇所（JIS X 0208には、そのような空き領域が複数存在している）に外字を入れる実装が存在した。1997年改正（JIS X 0208:1997）ではShift_JIS符号化およびEUC-JP符号化も規格で規定することにより、空き領域を外字として使用することが原則禁止された。またJIS X 0213:2000では、主要なベンダ外字の文字を規格に入れて94区までの空き領域をなくしたことで、94区までの区間内の外字を扱える箇所をなくし、2面を使用した実装水準4を選択する場合にはShift_JIS-2004符号化の場合、94区外の領域も埋まるため、外字を入れることが可能な領域がなくなった。
文字コード 文字コードの一覧（一部）
1バイト系文字コードは、俗に「半角文字」と呼ばれることもある。
ISO/IEC 8859（ISO/IEC 8859-1 〜 ISO/IEC 8859-16）
ISO-8859-1（ISO/IEC 8859-1 対応）
ISO-8859-5（ISO/IEC 8859-5 対応）
ISO-8859-6（ISO/IEC 8859-6 対応）
ISO-8859-7（ISO/IEC 8859-7 対応）
ISO-8859-11（ISO/IEC 8859-11 対応）
ISO-8859-15（ISO/IEC 8859-15 対応）
2バイト系文字コードは、俗に「全角文字」と呼ばれることもある。
文字コード 文字コードの一覧（一部）
ISO/IEC 2022系（ISO/IEC 2022自体は文字符号化方式というより、そのフレームワークのようなものである）
ISO-2022-JP（RFC 1468、俗に「JISコード」と呼ばれる文字コード。JIS X 0208対応）
ISO-2022-JP-1（RFC 2237、JIS X 0208とJIS X 0212に対応）
ISO-2022-JP-2（RFC 1554、多言語拡張。JIS X 0208、JIS X 0212、GB 2312、KS X 1001、ISO/IEC 8859-1、ISO/IEC 8859-7対応）
ISO-2022-JP-3（JIS X 0213:2000対応）
ISO-2022-JP-2004（JIS X 0213:2004対応）
ISO-2022-CN（RFC 1922、GB 2312、CNS 11643［第一字面・第二字面］対応）
ISO-2022-CN-EXT（RFC 1922、GB 2312、ISO-IR-165、CNS 11643［第一字面から第七字面］対応）
ISO-2022-KR（RFC 1557、KS X 1001対応）
文字コード 文字コードの一覧（一部）
EUC……拡張 UNIX コード（EUC）文字符号化方式を用いた8ビットの文字コード。ISO/IEC 2022の8ビット符号化表現に相当する。
EUC-JP（JIS X 0208 対応）
EUC-JISX0213（JIS X 0213:2000対応）
EUC-JIS-2004（JIS X 0213:2004対応）
EUC-KR（RFC 1557、KS X 1001対応）
GB2312（別名EUC-CN。GB 2312対応）
GBK（Microsoft Windows Codepage 936対応）
GB18030（GB 18030対応）
EUC-TW（CNS 11643対応）
シフト符号化表現の文字符号化方式を用いた8ビットの文字コード。
Shift_JIS（JIS X 0208対応）
Shift_JISX0213（JIS X 0213:2000対応）
Shift_JIS-2004（JIS X 0213:2004対応）
Windows-31J（Microsoftコードページ932対応）
x-Mac-Japanese（MacJapanese対応）
文字コード 文字コードの一覧（一部）
ISO/IEC 10646（UCS、JIS X 0221）※ISO/IEC 10646-1とISO/IEC 10646-2はISO/IEC 10646:2003で統合された。同様にJIS X 0221-1はJIS X 0221:2007で改訂された。JIS X 0221のうち、「日本文字部分レパートリ」はJIS X 0221 附属書JAという制限部分集合として定義する。
印刷業界においては、公的な文字コード規格では包摂されている異体字やグリフの相違を厳密に区別したいというニーズが強く存在する。そのため、そのようなニーズに応える文字集合が企業主導で策定されている。一般的な情報交換に用いられることはない。
Adobe-Japan1文字コレクション
Adobe-Japan1-0
Adobe-Japan1-1（JIS X 0208-1990、MacJapanese対応）
Adobe-Japan1-2（IBM拡張文字に対応）
Adobe-Japan1-3（OpenType Std）
Adobe-Japan1-4（OpenType Pro）
Adobe-Japan1-5（OpenType Pr5、JIS X 0213にほぼ対応）
Adobe-Japan1-6（OpenType Pr6、JIS X 0212・U-PRESS対応）
Adobe-Japan1-7（「令和」元号の合字対応）
以下は、主にメインフレーム・オフコンなどのプロプライエタリな古いレガシーコンピュータやレガシーなシステム、特殊な環境において利用される文字コードを含む。レガシーなものとの連携を目的とする場合を除き、パソコンで利用されることがないものが多い。
官公庁
戸籍統一文字（戸籍統一文字番号） - 日本の戸籍システムで使用される文字。
住基統一文字（住基ネット統一文字コード） - 日本の住民基本台帳ネットワークシステムで使用される住民基本台帳ネットワーク統一文字を符号化したもの。
登記統一文字（登記統一文字番号） - 日本の登記情報システムで使用される文字（戸籍統一文字と登記固有文字からなる）。
MJ文字（MJ文字図形名） - 日本の文字情報基盤の文字、IPAの文字情報基盤整備事業で整備された文字集合（戸籍統一文字と住基統一文字をもとに整備）。
入管正字（入管正字コード） - 日本の在留カードおよび特別永住者証明書の氏名に使用できる漢字。
京都市営地下鉄
京都市営地下鉄（きょうとしえいちかてつ）は、京都市交通局が運営する地下鉄。烏丸線・東西線の2つの路線があり、西京区を除く京都市内10区と宇治市を通っている。条例上の正式名称は京都市高速鉄道である。
京都市営地下鉄 路線
以下の2路線がある。日本全国の地下鉄事業者で唯一、全ての地下鉄路線が他社線と直通運転を行っている。
京都市営地下鉄 歴史
1931年11月に、当時の高木景・京都市土木局長は、京都駅につながる堀川線、または西大路線の「高速度軌道」建設を盛り込んだ都市計画を示した。この時は、地下鉄、モノレール、専用軌道のいずれともはっきりしていなかったが、1939年には市都市計画課長が「空中戦もあるので」と地下鉄の研究を示唆した。同年7月には、大京都振興審議会の第四部会で、「路面電車は時代遅れの交通機関で早晩、廃止される運命にある」「路面交通は速い方がいいが、必須条件ではない。低廉で多くの乗客を安全に運べる長所がある」などの論争があった。
1965年12月に京都市交通事業審議会（会長：米谷栄二・京都大学名誉教授）が出した答申では、「長期的な構想としては、現在の交通体系を高速鉄道（引用者注：地下鉄）とバスに改め、基本的に路面電車は撤去されるのが望ましい」とされた。1966年8月に京都市が発表した長期開発計画案では、市電が道路交通の支障になっていると分析し、高速鉄道南北縦貫線（北山橋 - 巨椋）、東西線（山科 - 西大路御池）など計5路線を大量輸送機関に、バスを補助手段とする交通体系を打ち出した。
京都市営地下鉄 歴史
市営地下鉄のルートは、市内にいろいろな形で入ってくる国鉄、私鉄をつなぐ観点から「南北十字構想」となり、これをもとに、烏丸線、東西線が建設された。京都市の広報紙『市民しんぶん』1969年5月号に掲載された構想では、京都市営地下鉄の路線は、銀閣寺 - 北野白梅町 - 西大路九条 - 久世橋間の「東西外郭線」、上鳥羽口駅付近 - 久世橋  - 洛西ニュータウン間の「洛西線」も盛り込まれており、さらなる路線も考えられていたようだが、その後は計画が進捗しなかった。
京都市営地下鉄 歴史
京都市経済局長を務めた清水武彦の証言によると、地下鉄の具体的なルートは、計画局〜都市開発局で比較検討が行われた。南北線は烏丸通と堀川通が比較され、新しい都心形成と南部開発のためには堀川通 - 油小路通が良いという意見もあった。九条通以南宇治川に至る油小路通は南部開発の大動脈という位置づけなので、地下鉄もここを通すべきという意見が有力だった。しかし、市営交通事業は1967年に財政再建団体に指定され、運輸省は赤字の京都市電撤去と引き替えでないと地下鉄建設を認めないという方針だったので、京都駅以北は烏丸通しか選択肢がなかった。そこで、京都駅以南は油小路通にということで国鉄と交渉したが、東海道新幹線・在来線の保安上、線路下の斜め横断は認められず、京都駅南部も烏丸通に通すことになった。東西線では、御池通、四条通、五条通が比較検討された。五条通は洛西ニュータウンにも乗り入れられることで有力視されたが、既成都心との距離や、国道9号線バイパス計画との調整問題などから、京阪電気鉄道京津線と乗り入れできる御池通経由が決まった。
京都市営地下鉄 歴史
1968年11月に京都市交通対策協議会（会長：米谷栄二）が出した答申では、烏丸線と御池線（のちの東西線）の具体的な経由地は、烏丸線は「北山橋付近から京都市の中心街路である烏丸通を南下して、京都駅で国鉄・私鉄と連絡し、上鳥羽付近を経て、宇治川南岸にいたるものとする」、御池線は「天神川付近から御池通を東行して、国鉄二条駅と連絡し、蹴上・国鉄山科駅・山科・醍醐地区を経て、六地蔵にいたるものとする」とされた。そのなかで輸送需要などを考慮し、烏丸線の北山橋付近 - 京都駅 - 上鳥羽口付近と御池線の天神川付近 - 国鉄二条駅 - 蹴上 - 国鉄山科駅の計21 kmを第1次建設計画とし、残りの区間を第2次計画とすることが適当とされた。
1971年12月には、運輸省の都市交通審議会答申第13号として、新設すべき路線として① 北山大橋 - 烏丸通 - 竹田 - 三栖、② 六地蔵 - 山科 - 御池通 - 太秦 - 洛西ニュータウン - 長岡、③ 三条 - 出町柳の3路線が提示された。
その後、1972年10月24日に運輸大臣（当時）から地方鉄道事業（地下鉄烏丸線、北山 - 竹田間）の事業免許を取得。当初計画では、1978年3月に北山 - 竹田の全線を開業する予定だったが、京都市の財政悪化や、北山 - 北大路間および京都 - 竹田間の用地買収交渉遅れといった事情により、ひとまず北大路 - 京都間を重点整備区間として先行着手することにした。1974年11月29日に起工式が行われ、1981年5月29日に地下鉄烏丸線（北大路駅 - 京都駅間）の営業を開始した。
開業当時の京都市営地下鉄の特色は、主要4駅にエレベーターを備えたことで、当時の日本の地下鉄では先進的であった。バリアフリーが広まる前の1972年頃から、車椅子常用者、障害者支援団体が運動を起こして京都市に請願し、京都市会と舩橋求己市長を動かした成果である。京都市は、相対式で設計されていた駅を急遽島式に変更し、将来的に全駅にエレベーターを設置することにした。なお、御池駅（現：烏丸御池駅）は当初から東西線の連絡駅に予定されていたため、相対式ホームで設計された。
京都市営地下鉄 運賃
烏丸線・東西線を合わせた乗車距離に応じた区間制運賃を採用している。2019年10月1日改定。
乗継割引
烏丸線京都駅 - くいな橋駅間と近鉄京都線 伏見駅 - 向島駅間の各駅を直通乗車もしくは乗り継いだ場合に市営地下鉄・近鉄の運賃合算額から10円または20円の割引がある。
東西線三条京阪駅 - 御陵駅間と京阪大津線（京津線・石山坂本線）各駅との間を直通乗車もしくは乗り継いだ場合に市営地下鉄・京阪の合算運賃から20-90円の割引がある。京阪電気鉄道#運賃の項を参照。
以下の乗継割引はポイントサービス導入に伴い2023年4月1日に廃止された。
ICカードで京都市バス（100円循環バスを除く）・京都バスと地下鉄を当日中に乗り継いだ場合、2乗車目の運賃を60円（小児30円）割引く。
「トラフィカ京カード」で京都市バス（100円循環バスを除く）・京都バスと地下鉄を当日中に乗り継いだ場合（複数回可）、偶数回乗車目の運賃を120円（小児60円）割引く。
京都市バス・京都バス・京阪京都交通の市内均一区間（230円区間）と地下鉄を乗り継いだ場合に120円（小児60円）引きで利用できる「バス・地下鉄（地下鉄・バス）連絡普通券」を販売。地下鉄駅などで販売していたが、バス車内では販売していなかった。また、現金精算時には乗継割引が適用されなかった。
京都市営地下鉄 運賃
特定割引
身体障害者ならびに知的障害者とその介助者（第一種・第二種小学生未満限定）、児童福祉施設等に入通所する児童と介助者は「特定割引普通旅客運賃」の対象となる
回数券・回数割引
以下の回数券を販売している。いずれも大人用・小児用があり、販売額は対象区間運賃の10倍相当。
回数券：普通運賃相当の区間券11枚。終日利用可能
特定割引回数券：特定割引相当の区間券11枚。特定割引対象者のみ利用可能。
以下の回数券は販売終了した。いずれも大人用・小児用があり、販売額は対象区間運賃の10倍相当。
昼間割引回数券：普通運賃相当の区間券12枚。平日の午前10時から午後4時までに乗車（改札）した場合のみ利用可能（日祝日の利用不可）。2021年10月1日発売停止。
また、PiTaPaでの月間利用額が京都市交通局（地下鉄・バス）と京都バスの合算で3,300円（小児1,650円）を超える場合に、請求額を9.09%割引（利用額が3,000円（1,500円）を超え3,300円（1,650円）までの場合は請求額を3,000円（1,500円）に据え置き）する。2023年4月1日廃止。
京都市営地下鉄 運賃
団体券
25人以上の団体が同一区間を利用する場合、運賃の10%引き（学生団体は20%引き）で販売する。事前申し込みが必要。
このほか、地下鉄一日券、地下鉄・バス一日券も発売されている。
2023年4月1日時点で、6キロ以下の距離の運賃が日本の地下鉄で最も高い。普通運賃は乗車距離によって大阪地区に比べ−8%〜+16%、東京地区に比べ−5%〜+44%の差がある。
京都市営地下鉄 車両
烏丸線
烏丸線の車両は20 m級車体に両開き4扉を備え、ラインカラーの緑色の帯が巻かれている。
10系
20系（2022年 - ）
烏丸線開業当初から運用している10系電車のうち更新時期を迎える9編成を置き換える予定で2021年度から2025年度に投入が計画されている新型車両。京都市交通局の「経営ビジョン」で明言されている。烏丸線に導入予定の可動式ホーム柵に対応すべく自動列車運転装置 (ATO) 対応とされた。
2017年8月31日に「高速鉄道烏丸線新造車両デザイン検討業務」の入札が行われ、総合車両製作所が1円（予定価格500万円）で落札している。
2019年3月5日から18日にかけて外装・内装の最終デザイン案の一般投票が行われ、外装は「前面の造形に曲面を多用した、より近未来的なイメージのデザイン」が、内装は「華やかで雅なカラーデザイン」が選定された。
なお、製造は近畿車輛が6両編成9本54両を受注している。この車両は2022年3月26日から運行開始、近鉄直通運転は4月12日から運行開始している。
東西線
東西線の車両は16 m級車体に両開き3扉を備える準小型車両 で、オレンジ色のラインカラーの帯が車体に巻かれている。
50系
烏丸線
東西線
京都市営地下鉄 経営状況
2024年度決算は一般会計からの補助金を含んで26億円の経常黒字であり、287億円の営業収益に対し支払利息などの営業外費用に28億円を計上している。東西線開業後は収支が改善していたが、2009年度から9年間は経営健全化団体となり、また新型コロナウイルス感染症の流行による乗客減少も影響し、2020年度からの3年間も経営健全化団体となった。企業債の残高は3,131億円。
この経営の厳しさの一因には、地下鉄建設の計画時の予算に比べ、実際の建設費が大幅に増大したことが挙げられる。一例として、東西線の二条 - 醍醐間の建設費は、事業免許を取得した時点での建設費が2450億円と想定されていたのに対し、実際の建設費は2倍近い4537億円だった。当該区間は工事時期がバブル景気と重なったことや、難工事により工期が当初見込みより3年間遅れたことも建設費高騰の原因で、京都市営地下鉄は他都市と比較してキロあたりの建設費が最も高い。
このような問題に対して京都市交通局では、駅業務の一部民間委託や高金利企業債の借換え、京都高速鉄道の直営化などによる各種コストの削減を進めている。また、駅ナカビジネスの展開などによる収益増にも取り組んでいる。なお、この一環で2010年4月より駅に掲示している駅名標付近に「駅名表示板下広告」の掲示を開始した。
符号化方式
符号化方式（ふごうかほうしき）は、デジタル処理・伝送・記録のための、情報のデジタルデータへの変換方式のことである。変換されたデータを符号と呼び、符号から元の情報へ戻すことを復号と呼ぶ。
情報をデジタルデータ化すると、コンピュータ（処理）や光ケーブル（伝送）、メモリ・ディスクなどの記録媒体（蓄積）で扱いやすい。
符号化方式 情報源符号化
情報源符号化（source coding）とは文字・画像・音声などの元情報の符号化である。符号化の対象となる情報の性質に応じた符号化方式が選択される。
例えば、音響であれば人間の聴覚の特性に基づいたサンプリング周波数の選択や、心理聴覚理論に基づいた高効率符号化（高能率符号化あるいは圧縮とも）などが行われる。
一般にコンピュータはバイト単位でデータにアクセスするため、ほとんどの符号化方式では文字や画像などを最終的にバイト列として表現できるようにしている。
映像には次のような特性がある。
高い自己相関性
写真や絵画などの自然画像の場合、ある1点の状態（明るさや色）は周囲の状態との類似性が高い。つまり画像を画素で表現した場合、任意の点の上下左右・斜め四方に隣り合う画素の状態とはほぼ同じということである。また、画像を走査線により表現した場合、ある走査線は前後の走査線の状態と類似する。さらに、動画像の場合にはあるフレームの画像は全体として前後のフレームの画像とよく似ている。こうした性質を利用することにより予測符号化を行うことが可能である。
人間の視覚特性が利用できる
符号化方式 情報源符号化
人間の視覚の性質上、明るさの変化に対し色彩の変化のほうが感知しにくい。言いかえれば輝度の解像度は色彩の解像度よりも高い。また、ゆるやかな明るさや色の変化の途中に不連続的な変化があると知覚しやすい反面、複雑な変化をする部分は細かく見分けにくく、多少の違いを感知することは難しい。このような視覚の性質を考慮して、違いを感知できない範囲であれば情報を簡略化することが可能である。予測符号化の精度を決定するに当たりこの性質を利用すると無駄なく符号化が行える。
人間の聴覚特性には周波数特性（フレッチャーマンソン曲線など）のほか、心理音響モデルによれば、ある周波数の音が響いている時には近い周波数の音は聞こえにくくなる。これをマスキング効果という。この性質を利用することにより効率良い符号化を行うのがMPEGオーディオ規格(MP3等)である。
日本語の 文字コード を符号化するときに問題となるのが文字の種類の多さである。1文字に対して1バイトを使うと256種類の文字までしか表現できない。英語であれば文字の種類は数十種類と少ないため、古くは 1文字 = 1バイトの形式が主流であった。しかし漢字はこの範囲におさまらないため、いくつかの符号化方式が提案された。現在は複数の方式が混在する状態になってしまっている。
日本語を表記するための符号化方式として代表的なものは ISO-2022-JPやShift_JIS、EUC-JPなどであるが、最近徐々に UTF-8 などの符号化方式も利用されるようになってきている。
符号化方式 通信路符号化
通信路符号化（Channel Coding）とは、情報を送る通信路の帯域、雑音や妨害などの性質に応じて、すでに情報源符号化された情報を再度符号化するものである。
たとえば、データの信頼性を高めるための誤り検出、誤り訂正符号の付加や、畳み込み符号化などがある。
GB 2312
GB 2312-80（あるいはGB 2312-1980）は、中華人民共和国の国家規格として定められた簡体字中国語の符号化文字集合（いわゆる文字コード）で、主に中国大陸などで使われる。規格名は《信息交换用汉字编码字符集・基本集》という。GB0とも呼ばれ、GBコードといったときには、多くの場合この規格を指す。漢字を含む文字集合規格の基本となっていることや構造など、日本のJIS X 0208と共通点が多い。
GB 2312 概要
中華人民共和国国家標準総局（当時）により1981年5月1日に実施された。GBは“国家标准”（拼音: Guójiā Biāozhǔn＝国家標準）の略で、日本のJISに当たる中華人民共和国国家規格の略称である。なお、中国の標準化機関は、数回に亘る改称・改組などを経て、2001年に国家標準化管理委員会となった。
JIS X 0208とよく似た構造を持つ94×94の文字集合で、漢字の他に各種記号、丸数字、ローマ数字、英数字、仮名（ただし長音符「ー」を除く）、ギリシア文字、キリル文字、声調符号付き拼音字母、注音符号といった非漢字682字を含んでいる。漢字は一級漢字（3755字）と二級漢字（3008字）に分かれ、前者が読みの順、後者が部首の順である点もJIS X 0208と似ている。
GB 2312 概要
GB 2312をEUCで符号化したものを簡体字中国語EUC (EUC-CN) という。他の符号化方式としては、1990年代半ばに、インターネットメールやネットニュースなど7ビットの経路で使用されていた非公式な方式であるHZ（Hanzi〈漢字〉の略、IANAへの登録名は “HZ-GB-2312”）がある。ISO-2022-CN というものもあるが、ほとんど使われていない。今日ではもっぱらEUC-CNのみが使われるため、単にGB 2312といっただけでEUC-CNを意味している場合が多い。IANAの登録名もGB2312となっている。
GB 2312 派生・後継規格
GB/T 12345-90
規格名を《信息交换用汉字编码字符集 第一辅助集》といい、GB 2312の繁体字版といえるもの。「GB1」ともいう。「T」は、“推荐”（拼音: tuījiàn＝推奨）を意味し、強制性がないことを示す。GB 2312に収録された2112字の漢字を対応する繁体字に入れ換え、62字を追加し、GB 2312に収録されていた41字は対応する繁体字に符号位置を明け渡すために追加領域に移動している。このようになっているのは、簡体字の中には複数の繁体字・異体字を一つに統合したものがあるという漢字の簡化の経緯による。
GBK
→詳細は「GBK」を参照
GB 2312 派生・後継規格
Kは“扩展”（拼音: kuòzhǎn＝拡張）を意味する。正式には《汉字内码扩展规范》という。国家技術監督局標準化司（当時）と電子工業部科技与質量監督司（当時）が発布実施した「技術規範指導性文件（文件＝文書）」であり、正式な規格ではない。ISO/IEC 10646.1:1993（UCS）＝Unicode 1.1の中国語翻訳規格といえるGB 13000.1-93（日本でいえばJIS X 0221-1995に相当する）の中国語サブセットで、GB 2312 EUC-CNを拡張したもの。UCSからGB 2312にない漢字を追加し、漢字2万1003字（当時のCJK統合漢字全2万0902字、追加漢字101字）を収録した。繁体字・日本漢字・韓国漢字だけでなく“啰”（「囉」）や“镕”（「鎔」）のようにGB 2312の制定後に簡化され「規範漢字」となった字も取り込まれた。中国大陸向けのMicrosoft Windows 95簡体中文版に採用されたことにより普及した。マイクロソフト・コードページ936。
GB 18030
→詳細は「GB 18030」を参照
規格名は《信息技术 中文编码字符集》。GBKをさらに拡張し、少数民族言語の文字なども含む大規模な文字セットで、GBKに取って代わる正式な国家規格。2000年3月17日に国家質量技術監督局（当時）によって《GB 18030-2000 信息交换用汉字编码字符集基本集的扩充》として発布・実施され、2001年8月以降、中国大陸で流通するコンピュータ製品は原則としてこれを実装することが定められた強制規格である。2005年11月8日に現行の新版に置き換えられ、2006年5月1日に実施された。これを使った文字符号化方式には “GB18030” （IANA登録名）がある。
Big5
Big5（ビッグファイブ、中国語名：大五碼あるいは五大碼）は、繁体字中国語の文字コード（文字集合）で、台湾・香港・マカオといった繁体字圏で最も一般的に使われている。
Big5 特徴
1984年5月1日に台湾の資訊工業策進会（Institute for Information Industry）が制定したもので、「電腦用中文字型與字碼對照表」として発行したものである。5大パソコンメーカーであったエイサー（宏碁）、マイタック（神通）、佳佳、ゼロワン（零壱）、FIC（大衆）が共同で策定したことによりこの名がある。このオリジナルのBig5の文字セットは、後の拡張と対比してBig5-1984と呼ばれることがある。
ローマ字、アラビア数字、蘇州号碼、記号類、注音符号のほか、漢字1万3062字を収録するが、そのうち2字は重複しているため、実際の漢字の文字集合は1万3060字である。台湾や香港、マカオなどの繁体字地域で普及しているが、MS-DOS時代の「中国語システム（中文系統）」、WindowsやMac OSといったオペレーティングシステムで採用されたことにより定着したデファクトスタンダードである。2003年にCNS 11643の附属書で追認され公的規格となった。
Big5 特徴
2バイトで約1万3000字を収容し、第一バイトは0xA1〜0xC6および0xC9〜0xF9、第二バイトは0x40〜0x7Eおよび0xA1〜0xFEの範囲をとる。大きく分けて、非漢字、常用漢字、次常用漢字の3つのブロックで構成され、漢字は総画数順、次いで部首順に配列されている。これはJIS X 0208やGB 2312の第2水準の「部首・画数順」とは逆になる。なお一部、重複している漢字や、配列の誤りがある。
符号空間がシフトJISと似ており、第二バイトに0x5Cが含まれるため、シフトJISの抱える円記号問題と同様の問題をも抱えている。ただし、シフトJISはJIS X 0208文字集合の符号化方式の一つであるのに対して、Big5は文字集合と符号化方式が一体化しており、通常これ以外の符号化方式で利用されない点が大きく異なる。
Big5 拡張
Big5に対しては、これまでさまざまな拡張が行われている。代表的なものについて以下に挙げる。
民間の独自拡張としては、Windows 95以前に最も普及していた中国語システムである倚天中文系統のものが古くから知られている。「碁銹恒裏墻粧嫺」の7字（倚天拡張字）のほか、罫線素片やキリル文字、丸数字などが採用されている。また倚天の拡張には仮名が含まれ、Big5ベースのシステムで日本語を表現する方法として盛んに用いられた。この拡張は、時に「Big5-Eten」とも呼ばれ、独自拡張としては最も重要なものの一つといえる。
Microsoft Windowsで使われている繁体字文字集合である「コードページ950」は、オリジナルのBig5に、倚天拡張字7字と罫線素片を取り入れたものである。Windows MEからは、「€（ユーロ記号）」が追加された。
Big5+
Big5 拡張
中文數位化技術推廣基金會（Chinese Foundation For Digitization Technology, CMEX, 中推会）が「BIG-5碼字集擴編計畫」により1997年7月に策定したもので、ISO/IEC 10646:1993 (Unicode 1.1) の漢字をすべて取り入れたもの。追加部分は、一般の文書で常用される「標準字集」の4670字と、「推薦字集」の3250字からなる。この文字コードセットは、従来のBig5のコードの範囲を超えていることから、Windowsなどのパーソナルコンピュータ・オペレーティングシステムで使用することができず、ほとんど普及しなかった。Unicodeの漢字をすべて取り込んだことと、文字符号化の手法の2点において中国のGBKによく似ている。
Big-5E
「BIG-5碼補充字集 (BIG-5 Extension Character Set)」の略称。Big5の外字エリアに収まるようにBig5+の「標準字集」から政府機関で常用される3954字を選び出したもの。
Big5 拡張
Big5-2003
中華民国国家標準を所管する経済部標準検験局の委託を受けた中推会は、国内の業者・専門家を招集して Big5の対照表を作成し、CNS 11643に附属書として盛り込んだ。これにより Big5は正式に公的規格の一部分となった。
Big5-2003には、Big5-1984の全ての文字のほか、マイクロソフト・コードページ950のユーロ記号、倚天拡張の0xA3C0-0xA3E0、0xC6A1-0xC7F2、0xF9D6-0xF9FE の範囲の文字が追加された。Big5-2003には、CNS 11643にないという理由で、「行列輸入法」の特殊符号や0xC7F3-0xC875のキリル文字は収録されなかった。それ以外の倚天拡張の文字は全て取り込まれた。
香港増補字符集 HKSCS
香港政府によって当初Big5の拡張文字セット（外字）として制定された文字集合。Big5に収録されなかった広東語方言字、固有名詞や科学技術に用いる漢字、仮名、漢字の部品などを補充したもの。
Shift JIS
Shift_JIS（シフトジス）は、コンピュータ上で日本語を含む文字列を表現するために用いられる文字コードの一つ。シフトJIS（シフトジス）と表記されることもある。
かつてはベンダーによる独自拡張を含む文字コード群を指した曖昧な名称であったが、1997年にJIS X 0208で標準化された。
Shift JIS 構造
JIS X 0201を1バイトで、JIS X 0208を2バイトで符号化する可変幅文字符号化方式。2バイト文字は、第1バイトに8116-9F16またはE016-EF16の47通り、第2バイトに4016-7E16または8016-FC16の188通りを用いる。
さらに、JIS X 0213に拡張したShift_JIS-2004では、第１バイトの未使用領域であるF016-FC16を利用している。
Shift JIS 歴史
1980年代、パソコン用16ビットCPUの普及もあいまって、漢字やひらがな・カタカナを表示可能なハードウェアを備えた情報機器が続々と発売された。これらの製品では、日本語を表現できる文字符号化方式が模索されており、先行してJIS C 6220（現在のJIS X 0201）の8ビット符号（以下「英数字・半角カナ」）と、JIS C 6226（現在のJIS X 0208、以下「漢字」）がよく利用されていた。この両文字集合の混在にあたっては、ISO 2022によるエスケープシーケンスで文字集合を切り替える設計となっていた。
Shift_JISの設計では、ファイルサイズ節約や処理時間短縮を図るため、これら文字集合をエスケープシーケンスなしで混在可能にすることを企図した。 ISO 2022では、英数字・半角カナ・漢字はそれぞれ、8ビット符号空間の中のGL(2116-7E16)・GR(A116-FE16)のいずれか1領域を使うことで表現する。このうち英数字・漢字だけの混在であれば英数字をGL、漢字をGRに割り当てることもできるが、既にGLに英数字、GRに半角カナを割り当てた実装が普及しており、既存のGL・GR領域に漢字を混在させることは困難だった。
Shift JIS 歴史
1982年、漢字の符号位置をこれら符号空間の隙間に押し込む形でShift_JISが実装された。これを実現するためには、漢字の1バイト目として、ISO 2022において不使用のCR（8016-9F16）領域に加え、半角カナに割り当てられていたGR領域に約3分の1残されていた未使用領域から捻出することとした。さらに2バイト目には、ISO 2022とは異なり、英数字・半角カナに使用済みの領域をも含む、GL、CR、GRにあたる各領域のほぼ全てを使う必要があった。ただし、GL領域においては、JIS X 0201の記号に当たる部分は極力避けた。
マイクロソフト日本法人元会長の古川享によると、Shift_JISの制定にはアスキー、マイクロソフト（米）、三菱電機、マイクロソフトウェア・アソシエイツ、デジタルリサーチ（米）が関わり、特にアスキーの山下良蔵が中心となって行われたという。これに対する異説として、京都大学助教授の安岡孝一は、マイクロソフトウェア・アソシエイツと三菱電機のみの共同開発だと主張していたが、山下本人の発言により安岡は自説を撤回する発言をしている。また古くはLife with UNIXの訳書 (ISBN 4-7561-0783-4) の「UNIX人名事典」翻訳版加筆部分 (p.45) で、深瀬弘恭に「MS漢字コードの作者の一人」という紹介文が書かれていた。
Shift JIS 歴史
Shift_JISはマイクロソフトのMS-DOSに「MS漢字コード」（および後のMicrosoftコードページ932）、デジタルリサーチのCP/M-86に「SJC-26」として採用された。両者はほぼ同じだが、全角スペースの扱いに違いがある。全角スペースにMS-DOSは814016を割り当てているが、CP/M-86は半角スペース2文字分と同等の202016を割り当てている。CP/M-86での実装は文字列からスペースを探索する処理が簡単になるというプログラミング上の利点があった。一方、MS-DOSは全角スペースに別のコードを割り当てることで、半角入力モードでスペースキーが2回押されたのか、全角入力モードでスペースキーが1回だけ押されたのかをプログラムが判別できるようにした。これは当時のアプリケーションソフト（Multiplanなど）でメニュー選択にスペースキーを使用していたためであった。また、プリンターでは全角スペースと半角スペースの幅の比が2対1でない場合があるため、スペースの区別は帳票設計に影響があった。
Shift JIS 歴史
Shift_JISは ISO 2022の符号化の範囲外にあるベンダー独自の実装として誕生しており、普及後もしばらく標準化されずにいたが、JIS X 0208:1997において附属書1で「シフト符号化表現」という名前で仕様が定義された。また、IANAにおいても「Shift_JIS」の名称が登録されている。
JIS X 0208の拡張規格であるJIS X 0213では、2000年制定時に附属書1で上位互換仕様のShift_JISX0213が定められ、2004年改定時にShift_JIS-2004と名称が変更された。
その後は更新は停止したが、日本語版Windowsが長らく標準をShift_JISに定めていたことで使用され続けた。不都合が多いためUnicodeへの移行が呼びかけられている。
Shift JIS 符号化方式
JIS X 0208では文字集合が区点番号として94×94の文字表の行と列の番号の組で表現される。これら区点番号をShift_JISでは以下のような対応で符号化している。
JIS X 0213では94×94の文字表が2つあり、それぞれ第1面・第2面と表現される。第1面(第1・2・3水準)は上記符号化の範囲に収まる。第2面(第4水準)は区番号が1・3・4・5・8・12-15・78-94区と不連続に構成されており、この26区分を収録するためにShift_JIS-2004では以下のように対応している。
面区点番号  から Shift_JISの 第1バイト・第2バイトは以下の式で求められる。は床関数。
初期のShift_JISでは、第1バイトが47通り、第2バイトが188通りの符号があるため、 47 × 188 = 94 × 94 = 8836 の2バイト文字を表現することができ、これはJIS X 0208で規定された区点番号のすべてを収められるように設計されている。ここに158字の英数字・半角カナ（スペース含む、DEL除く）を加えると、計 8994 文字となる。
Shift JIS 符号化方式
さらに、第1バイトはF016-FC16を用いることで60通りまで拡張されており、 60 × 188 + 158 = 11438 文字を表現することができる。Microsoftコードページ932のIBM拡張文字やShift_JIS-2004の第4水準文字の符号化ではこれらの領域を動員している。
Shift JIS 特徴
利点
全角文字と、JIS X 0201で定義したいわゆる半角カナ文字を同一のコード体系で表現できる。
日本語環境においては、MS-DOSで日本語用文字コードとして採用されて以来、パソコンにおいて圧倒的な普及度があり、その他の文字符号化方式に比べてデータ交換可能性が高い。
UTF-8などに比べてサイズが小さい。UTF-8では半角カナや漢字の多くは3バイトを要する。
欠点
Shift JIS 特徴
半角カナのための領域を確保した関係上、区点番号と符号の相互演算には前述のように煩雑な条件分岐が必要である。
2バイト目に8016未満（ASCIIのコード領域）が現れる。このため、文字の区切りの判定に手間がかかる。ファイルや電文の先頭から文字コードの判定をする場合はよいが、後ろから判定をしようとすると、最悪の場合、先頭までたどらないといけないことがあるため、プログラムの作り方に工夫が必要になる。また、この領域に含まれる一部の文字の扱いのため、マルチバイトのEUC-JP、UTF-8などに比べ、プログラミング上の扱いが難しい（次項を参照）。
JIS補助漢字が表現できない。
文字集合については実装ベンダがJIS X 0208で規定されていない機種依存の拡張を施していることが多く、こういった拡張部分に関してはデータ交換可能性が低い。特に広く普及しているMicrosoftコードページ932はJIS X 0213で拡張されたShift_JIS-2004と併用できない。
Shift_JISでは、カタカナの「ソ」、漢字の「噂」など一部の文字の2バイト目に、5C16を使用している。この符号はJIS X 0201では円記号、ASCIIなどではバックスラッシュに該当し、多くのプログラミング言語（C、Perl、Bourne Shellなど多数）ではエスケープ文字と扱う。したがって、ソースコードや文字データの処理においてShift_JISを想定していないプログラミング環境では問題が起こる。この問題は、同じように2バイト目の範囲に5C16を含むBig5や、まれではあるがGBKなどの文字コードでも発生しうる。
また、5C16以外についても類似の問題が発生することがある。
このようなASCII約物と同じ符号を含むためにプログラム上で不具合を起こしうるマルチバイト文字を俗に「だめ文字」あるいは「ダメ文字」と呼ぶ。
この問題を回避する伝統的な方法として、以下のようなものがある。
文字化け例
マルチバイト非対応環境では、Shift_JISの「構わない」という文字列は「高墲ﾈい」または「高筲ﾈい」に文字化けすることがある。後の文字の2バイト目が半角カナ「ﾈ」として認識されるため、「い」でデコードが再同期され、後の文字列は正常に表示される。
また、同様に「芸能界」という文字列は「芸矧E」に文字化けする。
Shift JIS 名称
Shift_JISの「シフト」とは、JIS X 0208の文字集合を分割したうえで8ビット符号空間内に“ずらして配置”して符号化していることを意味する。
他の符号化方式においても、複数の文字集合をシフトコードで切り替える操作を「シフト」と呼ぶが、これとは異なる。例えば、ISO-2022-JPはエスケープシーケンスで漢字と英数字を切り替えることを、EUC-JPは補助漢字と半角カナをシングルシフトで切り替えることを指す。
また、ビット演算の「ビットシフト」とも関係がない。
「MS_Kanji」は、IANAによりShift_JISの別名として割り当てられている。
「x-sjis」は、IANAに「Shift_JIS」が登録される以前にNetscape Navigator 2.0において使っていたエンコーディングの指定子名である。HTMLドキュメントの「charset」の指定にShift_JISの別名として使えるブラウザエンジンがある。
ECMAScript
ECMAScript（エクマスクリプト）は、Ecmaインターナショナルにおいて標準化されたJavaScriptの国際規格である。また、ISO/IEC JTC 1においてはISO/IEC 22275:2018、日本産業規格においてはJIS X 3060:2000として規格化されている。
ECMAScript バージョン
ECMAScript仕様は、Ecma InternationalにてECMA-262という規格番号で標準化されている。改訂にあたっては版 (edition) が更新されている。
6th editionから、「ECMAScript 2015」仕様の名称に発行年が付加されることになった。以降、ECMAScriptは毎年改訂されることになり、以降特定の版を指す場合は、edition名ではなく年号つきの仕様書名で呼ばれることが推奨されている。
ECMAScriptにはいくつかの拡張が存在する。
EcmaはECMAScriptのための "Compact Profile" も定義した — ES-CP、あるいはECMA 327として知られる — リソースの厳しいデバイス用にデザインされている。ECMAScriptのいくつかの動的な機能(『eval』関数など)はオプションにされている。これにより、処理系はプログラムの振る舞いに対してより多くの仮定ができるようになり、その結果、より良いパフォーマンス・トレードオフを実行時に得ることができるようになる。
HD DVD standardはECMAScript Compact Profileに準拠し、完全なECMAScriptの支援をより少ないメモリのデバイスで実行できるよう採用している。
ECMAScript 方言およびその呼称
ECMAScript は、ウェブブラウザをはじめとする多くのアプリケーションでサポートされている。DOMとの連携はドキュメントの操作を可能にする。
ECMAScript ECMAScript 4
ECMAScript 4は過去2回仕様作成が挑戦されたが、仕様がまとまらず、失敗に終わっている。
2000年〜2003年ごろ行われた。主に、旧Netscape社とマイクロソフトによって行われたが、意見がまとまらずに、打ち切りとなった。この時の案はActionScriptへと引き継がれた。
2007年〜2008年ごろ、2回目の仕様作成が行われた。大きく機能を追加される予定であったが、意見がまとまらず、2008年8月13日に、小規模の改善にとどまる、ECMAScript 3.1を進めることとなった。
以下のような予定があった。
EUC-JP
EUC-JP（Extended UNIX Code Packed Format for Japanese、日本語EUC）は日本語の文字を扱う場合に利用されてきた文字コード（符号化方式）のひとつである。
1980年代中頃、当時UNIXのライセンス事業を展開していたAT&TがUNIXの日本語化に向けて、日本のUNIXベンダーをメンバーとする日本語UNIXシステム諮問委員会を設置。ここでUNIXで日本語を扱うための文字コードについて議論が行われ、議論の結果をもとに同委員会から報告書がAT&T側へ出され、AT&Tにより定められた日本語機能のガイドラインがEUC-JPの起こりである。この時、AT&TからExtended Unix Code (EUC) として日本語に限らず多言語に対応できるように定められ、EUCのうち日本語を扱うものを特にEUC-JPなどと呼ぶ。他に、EUC-KR（韓国語）、EUC-CN（簡体中国語）等がある。
EUC-JPはEUCのエンコード方式上にASCIIとJIS X 0208文字集合を配置したもので、半角カナ (JIS X 0201) とJIS補助漢字 (JIS X 0212) も含むことができる。半角カナと補助漢字を使用しない場合は、JIS X 0208で規定されている符号化方式「国際基準版・漢字用8ビット符号」と同一となる。ISO/IEC 2022に適合する。
EUC-JP
日本語文字はJIS X 0208をGR領域に表現したものを基本としており、2バイトで表現され、1バイト目、2バイト目ともに0x80 - 0xFFの範囲内にある。このため英数字と日本語文字の区別がしやすく、プログラム上での扱いが楽である。ただし、半角カナはISO-2022-JPやShift_JISと異なり制御文字SS2（シングルシフトツー、0x8E）に続けて現れるので都合2バイト、補助漢字は制御文字SS3（シングルシフトスリー、0x8F）に続けて現れるので都合3バイトを要する。
JIS X 0213:2004に対応するEUCコードはEUC-JIS-2004（2000年初版時はEUC-JISX0213）。
UNIX系OSの標準的な文字エンコードとして使用されてきた。かつて、WebサーバにUNIX系OSが多く用いられていたことから日本語のウェブサイトではShift_JISと並んでEUC-JPが多く使われていたが、2006年頃から世界的にUTF-8が普及し始めている。全言語の主要なウェブサイトに占めるEUC-JPのシェアは、2010年から2019年にかけて0.7%から0.1%に低下している。
EUC-JP 制定経緯
1984年7月、当時UNIXのライセンスを販売していたAT&Tが東アジア・太平洋地域でライセンス事業を展開するため、子会社のAT&Tインターナショナル・ジャパンにUNIXシステム東京事務所（AT&Tユニックス・パシフィック）を設立。最初に日本で事業を展開するにあたり、UNIXの日本語化に向けて石田晴久を委員長に、日本電信電話公社、沖電気工業、東芝、日本電気、日立製作所、富士通、三菱電機といった当時のUNIXベンダーをメンバーとする日本語UNIXシステム諮問委員会を設置した。ここでUNIXで日本語を扱うための文字コードや機能について議論が行われ、その結果をもとに1985年4月30日付けで同委員会から報告書『UNIXシステム日本語機能の提案にあたって』がAT&T側へ提出された。日本語EUCとしてのベースはこの報告書で概ね出来上がっていたが、AT&Tはこれを国際的に通用するよう、国際機能と各国語機能に分けて定義した。そして1986年2月にアナハイムで開催されたUNIXカンファレンス UniForum にて、各国語機能のサポート第1弾として Japanese Application Environment (JAE; 日本語アプリケーション・エンバイロメント) を発表。この中に文字コードの構造 (EUC) と日本語機能で使用される文字セットが定められた。
EUC-JP 制定経緯
1990年にJIS X 0212で補助漢字が制定されたことを受けて定義を拡張する必要が生じたため、1991年12月、Open Software Foundation (OSF) とUNIX International (UI)、UNIXシステムラボラトリーズ・パシフィック (USLP) はUNIX上の共通日本語文字コードとして日本語EUCを定義した。
EUC-JP EUC-JPの亜種
EUC-JPには亜種が存在する。二種類を以下に解説する。
eucJP-msは、オープン・グループ及び日本ベンダ協議会が策定した文字符号化方式。実装例はMySQL v5.0以降等。
CP51932はマイクロソフトがWindowsで使用しているWindows-31JのEUC-JP互換表現。実装例はInternet Explorer4.0以降、EmEditor、秀丸エディタ等。このコードはNECのPC-9800シリーズの漢字コード（9区から12区の特殊文字を除外したもの）をGR表現したような体裁を持つ。ただし、PC-9800シリーズの漢字コードはJIS C 6226-1978をベースにするのに対して、CP51932はJIS X 0208-1990をベースとする点が異なる。
クロード・シャノン
クロード・エルウッド・シャノン（Claude Elwood Shannon, 1916年4月30日 - 2001年2月24日）はアメリカ合衆国の電気工学者、数学者。
情報理論の考案者であり、「情報理論の父」と呼ばれた。情報、通信、暗号、データ圧縮、符号化など今日の情報社会に必須の分野の先駆的研究を残した。アラン・チューリングやジョン・フォン・ノイマンらとともに今日のコンピュータ技術の基礎を作り上げた人物として、しばしば挙げられる。
20世紀科学史における、最も影響を与えた科学者の一人である。
クロード・シャノン 生涯
シャノンが生まれたとき、家族はミシガン州ゲイロードに住んでおり、クロードは近くのペタスキーの病院で生まれた。 父のクロード・シニア（1862-1934）は実業家で、ゲイロードの検認判事を務めたこともある。母のメイベル・ウルフ・シャノン（1890-1945）は語学の教師で、ゲイロード高校の校長も務めた。父方の祖先はニュージャージーへの入植者であり、母はドイツ系移民の子供だった。
シャノンはゲイロードで育ち、1932年にゲイロード高校を卒業した。シャノンは機械や電気に興味を持っていた。得意科目は理科と数学だった。家では、飛行機の模型やラジコンボートを作ったり、半マイル離れた友人の家まで電線を張って電信システムを構築したりしていた。高校時代には、ウエスタンユニオン社の電報配達のアルバイトや百貨店でのラジオ修理などをしていた。
シャノンは子供時代にトーマス・エジソンに憧れていたが、後に自身の遠縁に当たることを知った。どちらの家系も、植民地時代の指導者で多くの著名人の祖先であるジョン・オグデン（1609-1682）の子孫である。
1932年にミシガン大学に入学し、そこでジョージ・ブールの研究に触れた。1936年、電気工学と数学の学士号を取得して卒業した。
クロード・シャノン 生涯
ミシガン大学を卒業したシャノンは、マサチューセッツ工科大学の電気工学科に進んだ。そこでヴァネヴァー・ブッシュの下、微分解析機の保守に携わった。1937年の夏、ベル研究所でブール代数とスイッチング回路の融合を考えつき、同年、修士論文「リレーとスイッチ回路の記号論的解析」としてまとめた(詳細は#デジタル回路設計の創始者を参照)。翌年、この論文はアメリカ電気学会報に掲載され、1940年には、35歳未満の研究者による優れた工学論文に贈られるアルフレッド・ノーブル賞を受賞した。
1938年の末、ブッシュの助言によりMITの電気工学科から数学科に移籍した。そこで遺伝学の研究を行い、博士論文「理論遺伝学のための代数学」で博士号を取得した。
1940年の夏をベル研究所で過ごしたのち、学術研究会議の研究費を得てプリンストン高等研究所に1年間滞在し、ヘルマン・ワイルの下で研究した。その後再びベル研究所に戻り、数学研究部門の常勤専門職員となった。
1956年に電子工学研究所(RLE)の研究員としてMITの教員となった。1978年までMITの教員として務め続けた。
後年、シャノンはアルツハイマー病を発症し、晩年をナーシングホームで過ごした。2001年に、妻と息子と娘、そして2人の孫娘を遺して亡くなった。
クロード・シャノン 功績
1937年のマサチューセッツ工科大学での修士論文「リレーとスイッチ回路の記号論的解析」において、電気回路（ないし電子回路）が論理演算に対応することを示した。すなわち、スイッチのオン・オフを真理値に対応させると、スイッチの直列接続はANDに、並列接続はORに対応することを示し、論理演算がスイッチング回路で実行できることを示した。これは、デジタル回路・論理回路の概念の確立であり、それ以前の電話交換機などが職人の経験則によって設計されていたものを一掃し、数学的な理論に基づいて設計が行えるようになった。どんなに複雑な回路でも理論に基づき扱えるということを主張したのは、コンピュータの実現に向けた大きなステップである。
ハーバード大学教授のハワード・ガードナー（Howard Gardner）は、この論文について「たぶん今世紀で最も重要で、かつ最も有名な修士論文」と評した。ただし、わずかな時間差であるが、中嶋章による発表の方が先行しており（論理回路#歴史を参照）、独立な成果か否かは不明とされている。
1948年ベル研究所在勤中に論文「通信の数学的理論」を発表し、それまで曖昧な概念だった「情報」(information)について定量的に扱えるように定義し、情報についての理論（情報理論）という新たな数学的理論を創始した。