[13] euc-jp は、日本でかつてよく使われていた文字コードでした。

仕様書

符号化文字集合

[55] 次の符号化文字集合を組み合わせたものです。

[121] 外字 (独自拡張) については、 JIS X 0208, JIS X 0212, JIS X 0213 を参照。

[123] 文字コードの判定の補助のために特定の文字を signature として使うことがあります。 文字コードの判定

文脈

[35] 20世紀に UNIX 系の OS では日本語の標準文字コードとして用いられていました。

[36] ASCII のバイトが常に ASCII を表す特徴から、 Perl などの ASCII ベースのプログラミング言語のソースコードの記述に適切とされていました。 90年代末から00年代初頭には CGIスクリプト等の Webアプリケーションの内部コードおよび入出力用コードとしてよく採用されていました。

[96] DTI ユビキタスプロバイダ | My DTIログイン, https://oc.dti.ne.jp/cgi-bin/uss/index.cgi

<meta http-equiv="Content-Type" content="text/html; charset=EUC-JP" />

実利用例

[122] goo, , https://web.archive.org/web/19981212034346/http://www2.goo.ne.jp/

特殊な事例

Webブラウザーによる文字コード判定の失敗事例集

関連

[16] 日本国内では外にシフトJISや ISO-2022-JP がよく使われていました。

歴史

[14] 歴史的に無数の変種があります。

最初の日本語 EUC

[34] 日本語 UNIX システム諮問委員会が1985年に UNIX システム日本語機能提案書で日本語 EUC の内部コードを定義したといわれています。

[37] AT&T の System V Interface Definition が、それに基づき SCS (Supplementary Code Set) を規定したといわれています。

[38] 更に、 AT&T UNIX Pacific が SCS のことを EUC と呼んだと言われています。

[15] AT&T UNIX Pacific の JAE (Japanese Application Environment) が規定したのは

  • G0 ASCII
  • G1 JIS X 0208-1983
  • G2 JIS X 0201片仮名用図形文字集合
  • G3 外字 (予約領域)
... となっていたようです。

[39] 日本語EUC、AT&T code、eucjis、JA16EUC、EUC-jis、euc などと呼ばれました。

[33] UJIS (Unixnized extended JIS) は、 Σ OS が採用した文字コードとされています。 実際には当時の日本語EUCと同じものだったようです。

[23] 石井晴久氏による EUC 前史 ( 版) http://d.hatena.ne.jp/nurse/20090310#1236625695

補助漢字の拡張

[45] 1993年5月21日の UI-OSF Japanese Localization Group の UI-OSF 日本語環境実装規約 Version 1.1 は、 附属書Cで「UI-OSF共通日本語EUC」を規定していました。 これは1991年12月12日のUI-OSF-USLP 共同技術資料: 日本語EUC の定義と解説と同じもので、 AJEC (Advanced Japanese EUC) を規定していました。

[46] AJEC は、 G1 の 85〜94区と G3 の 78〜94区を共通自由領域としていました。

[47] この AJEC に対して eucJP という名前が定義されていました。

[59] 1992年に出版された UNIX インターナショナルの UNIX SYSTEM V リリース 4 日本語環境共通規約 第1版にも定義が含まれていると言われます。

[30] CALS 「共通符号の案」 >>29, NCALS共通文字符号 >>32

[31] G3 を左側に呼び出すところだけEUCと違います (古い ISO/IEC 2022 に忠実な仕様)。 理由は SGML の具象構文との整合性 >>32。

[19] numa's diary:補助漢字と日本語 EUC - livedoor Blog(ブログ) (2007-06-09 05:12:05 +09:00 版) http://blog.livedoor.jp/numa2666/archives/50236450.html (名無しさん 2007-06-24 10:28:35 +00:00)

[20] Linux における日本語ロケールに関する指針 (2001-10-28 23:57:31 +09:00 版) http://www.linux.or.jp/JF/JFdocs/Japanese-Locale-Policy.txt (名無しさん 2007-06-24 10:40:34 +00:00)

[18] JIS X 0208:1997の附属書にはシフト符号化表現とRFC1468符号化表現のみが定義されており、日本語EUCに相当するものはありません(おそらくなかったことにする予定だったJIS X 0212に触れたくなかったのでしょう)。 ただし本体の国際基準版・漢字用8ビット符号はJIS X 0201 片仮名とJISX0212-1990を含まない日本語EUCであるとみなせます。 (名無しさん )

[102] >>101

[116] bug 4873 – EUC-JPエンコーダは補助漢字を変換すべきではない, http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4873

その他の拡張

[40] UJIS に IBM拡張漢字を加えたものが IBM-eucJP と言われています。

[41] UJIS の G1 に利用者定義領域 (外字) を加えたものが S90 と言われています。

[42] Data General が用いたものが IKIS code といわれています。 UJIS とは JIS X 0201片仮名用図形文字集合が異なっていたそうです。

[43] EUC-HJ (Extended UNIX Code HITACHI) は 0xA121-FE7E を利用者定義 (外字) に使っていました。

DEC漢字と同じ方式。

[44] OCMPOpen Computing environment for MIPS Platform (NEC + SONY) は、 OCMP-ABI 「日本語共通アプリケーションバイナリ規約」 で G3 の空き領域に共通外字を規定していました。

[56] 富士通の U90 と呼ばれる拡張は、 G0 に JIS X 0201ラテン文字用図形文字集合 (!)、 G1 に JIS X 0208-1990、 G2 に JIS X 0201片仮名用図形文字集合を採用し、 JIS X 0208 の61〜93区 (?) は利用者定義 (外字)、 85〜94区は OASYS の独自の非漢字としています。 更に G3 の1〜48区は JEF の独自の漢字、 49〜60区は JEF の独自の非漢字としているようです。

[58] G3 の1-26区をシフトJISの 0xF040-FCFC に対応付ける実装もあったようです。

[73] DOCS も参照。

[74] [PATCH libX11 4/5] i18n: Remove ja.S90 and ja.U90 locales., , https://lists.x.org/archives/xorg-devel/2012-December/034661.html

[97] DAL-データ・アプリケーション|リリースノート|RACCOON V2.6.1 リリースノート情報, https://www.dal.co.jp/release-notes/raccoon/20240411_0.html

[57] インフォミックスの拡張は、 0x8DF040-8DFCFC をシフトSJIS 0xF040-FCFC に相当するものとして使っていました。

ISO/IEC 2022 に反する独自の拡張です。

[110] 外字 - 機能|帳票ツールのCreate!Form, , https://www.createform.jp/function/external-char.html

  • 日本語EUC環境(Linux)においても、0xF5A1~0xFEFEの領域(940文字)を外字領域として使用することができます。

Windows外字エディターでの外字は、SJISのユーザ外字領域(F040からの1880文字)やUnicodeの私用領域(E000からの6400文字)で作成、管理されます。

Create!Formでは入力データの文字コードはSJIS、EUC、Unicodeで使用することができますので、いずれの文字コードでもWindows外字エディターの外字を利用することができるようになっています。

DEC の拡張

[27] DEC の製品は日本語EUCの独自拡張を実装していました。何種類かありました。 DEC漢字

eucJP-open

[48] eucJP-open は、 UI-OSF 日本語環境実装規約の eucJP の共通自由領域に IBM拡張漢字を追加したものでした。

[49] G1 は JIS X 0208-1990 で、85-94区が共通自由領域でした。

[50] G3 は JIS X 0212-1990 で、78-94区が共通自由領域でしたが、 そのうち83区と84区に IBM の拡張が割り当てられていました。

[51] SJIS-open との対応関係が規定されていました。

  • [52] http://www.opengroup.or.jp/jvc/cde/sjis-euc.html
    • [93] 消滅確認
    • [94] 日本語 EUC とシフト JIS との間のコード変換について, , https://web.archive.org/web/20051130033920/http://www.opengroup.or.jp/jvc/cde/sjis-euc.html
  • [95] Unicode とユーザ定義文字・ベンダ定義文字に関する問題点と解決策, , https://web.archive.org/web/20061012032720/http://www.opengroup.or.jp/jvc/cde/ucs-conv.html

[67] eucJP-ms, , http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html

[75] eucJP-open ‐ 通信用語の基礎知識, https://www.wdic.org/w/WDIC/eucJP-open

[101] 日経データプロワークステーション, 日経マグロウヒル社, , , https://dl.ndl.go.jp/pid/13148732/1/646 (要登録)

JIS X 0213 による拡張

[17] JIS X 0213:2000 は EUC-JISX0213 を定義しています。

[85] JIS X 0213:2000 本体に国際基準版・漢字用8ビット符号なるものがあり、 その拡張と書いてあります。

[86] 実装水準3であることを明示するため EUC-JISX0213-plane1 と呼んでもよいとされます。 EUC-JISX0213 は実装水準3と実装水準4の両方を含むようです。 実装水準4と明示する方法はなさそうです。

[87] EUC-JISX0213:

[88] 国際基準版・漢字用8ビット符号との違いは G2。 G2 は JIS X 0201 片仮名用図形文字相当 (代替名称)。

[89] G2, G3 は EUC なら右側に呼び出すべきだが、 左か右か明記されていない。 (インデント的に直前の GR 領域云々の箇条には含まれなそう。)

[82] x-euc-jisx0213-packed は、 EUC-JISX0213 の空き領域に JIS X 0212-1990 を割り当てたものです。

[80] Perl の Encode.pm の euc-jp は、 一般的な EUC-JP の相互変換に加え、 JIS X 0213:2000 の第1面、第2面の復号に対応しています。 JIS X 0212 の TILDE も復号のみ対応しています。 >>81

JIS X 0212, JIS X 0213, DOCS, 942集合

  • [81] ucm/euc-jp.ucm - metacpan.org, , https://metacpan.org/release/DANKOGAI/Encode-3.17/source/ucm/euc-jp.ucm

[83] JIS X 0213:2004 では第1面が改正されました。 JIS X 0213 それに伴い符号の名前が変更されました。 構造は変更されていません。 名称は正誤票で再改正されました。

[84] ORCA Project: 拡張漢字(JISX0213:2004)の使用, , https://www.orca.med.or.jp/receipt/use/jisx0213/

[90] 文字セットについて - 超漢字ウェブサイト, , http://www.chokanji.com/ckv/manual/06-05-07.html

[91] 超漢字メールはEUC-JPJISX0213 (+ テキスト形式TRONコード) の送受信に対応していました。 >>90 EUC-JISX0213 のことでしょう。

[108] >>107 は >>106 が配信されたもの。 >>106 は UTF-8 だが >>107 は EUC-JP。 >>106 で﨑となっていた部分が >>107 では &#31932; に変換されており、 粼 と表示されている。

[109] NEC選定IBM拡張文字の 﨑 と JIS X 0213 の 粼 の面区点位置が同じことによる誤変換文字化け。

IANA charset EUC-JP

[5] IANAのcharset登録簿には、2006年3月現在

Name: Extended_UNIX_Code_Packed_Format_for_Japanese
MIBenum: 18
Source: Standardized by OSF, UNIX International, and UNIX Systems
        Laboratories Pacific.  Uses ISO 2022 rules to select
               code set 0: US-ASCII (a single 7-bit byte set)
               code set 1: JIS X0208-1990 (a double 8-bit byte set)
                           restricted to A0-FF in both bytes
               code set 2: Half Width Katakana (a single 7-bit byte set)
                           requiring SS2 as the character prefix
               code set 3: JIS X0212-1990 (a double 7-bit byte set)
                           restricted to A0-FF in both bytes
                           requiring SS3 as the character prefix
Alias: csEUCPkdFmtJapanese
Alias: EUC-JP  (preferred MIME name)

とあります。

[6] >>5 EUC-JPという名前は後から付け加えられたようです。最初の登録者は一体何を考えていたのでしょうか。

文字符号化EUC-JP (XML)

[4] XML 1.0およびXML 1.1の仕様書 IW:XML1:"#charencoding" では、 符号化宣言 (encoding擬似属性) の値EUC-JPは SHOULD be used for the various encoded forms of JIS X-0208-1997とされています。

これをどう解釈するべきかははっきりしません。 JIS X 0208:1997にはEUC-JPとよばれる符号化文字集合は規定されていないようです。 だとすると、一般にEUC-JPと呼ばれている符号化文字集合の亜種で JIS X 0208:1997を採用したものと考えるべきでしょうか。

[7] JIS X 0208:1997 の解説には、EUC と呼ばれるISO/IEC 2022とJIS X 0208を用いた文字コードが実装されていることが指摘されています。 従って、JIS X 0208:1997の制定当時一般にEUCと呼ばれていたものを、 JISでは本来新旧版が並存することはなく、最新版だけが有効だという原則 (同解説の別の箇所にそうあります。) に従い、JISを最新の規格に改めたものがJIS X 0208:1997のEUC-JPではないかと考えられます。

[8] ISO/IEC 2022に従った文字コードだとすると、 図形文字の一意な符号化に関する制限 (JIS X 0202:1998 7.5) が適用される可能性がありますが、 JIS X 0208:1997 9.2 によればこれまでの慣用的な利用との互換のために代替名称を用いても構いません。

その場合、REVERSE SOLIDUSとYEN SIGNの問題があります。 (図形文字の一意な符号化の項を参照。)

また、ASCIIとJIS X 0212‐1990 が含まれるので、 TILDEも問題があります。 (図形文字の一意な符号化の項を参照。)

[9] 更に厳密には、そのEUCの1バイト左半分がASCIIなのかISO/IEC 646なのか、 という問題があります。JIS X 0208:1997はISO/IEC 646と併用する際に代替名称を認めていますが、 ASCIIとは認めていません。 (ASCIIとISO/IEC 646 IRVはたまたま1997年の時点では (少なくても文字名称によって比較すれば) 同じ符号化文字集合を規定しています。)

注意して読むとJIS X 0208:1997の規定はISO/IEC 646に関するもので、 ISO/IEC 646 IRVとは書いていませんから、 IRVに対するものとも、ISO/IEC 646の版いずれに対するものとも読めますが、 ISO/IEC 646とJIS X 0201が併記されていることから、 IRVと解釈する方が適当だと思われます。 (ただし、7.2にはIRVと明記されていますが、こちらでは明記されていないのが気に掛かります。)

x-euc

[124] TRONコードの概要, , https://web.archive.org/web/20000520133059/http://www2.tron.org/troncode.html

	<meta name="GENERATOR" content="Symantec Visual Page 1.0.1 Japanese">
	<meta http-equiv="Content-Type" content="text/html">
	<title>TRONコードの概要</title>

[125] TRONコードの概要, , https://web.archive.org/web/20030217041743/http://www2.tron.org/troncode.html

<meta http-equiv="Content-Type" content="text/html">
<meta http-equiv="Content-Type" content="text/html;CHARSET=x-euc">

	<meta name="GENERATOR" content="Symantec Visual Page 1.0.1 Japanese">
	<meta http-equiv="Content-Type" content="text/html;CHARSET=x-euc">
	<title>TRONコードの概要</title>

w3m-euc-japan

[103] Re: w3m-euc-japan (Re: User specified content type / w3mmee support), , http://emacs-w3m.namazu.org/ml/msg00872.html

[104] >>103 w3m の内部符号 w3m-euc-japan。 euc-japan (日本語EUC) に内部用の制御符号を足したもの。

[105] 関連: w3m-m17n の内部符号 内部符号

CP51932

[77] Windows の CP51932 は Unicode ←→ CP932 の変換に シフトJIS ←→ EUC変換を組合せたものらしい。

Unicode → CP932 → CP51932 の途中で EUC に変換できないものが出てもそのまま素通しする。 (変換できない EUDC と変換できる NEC選定IBM拡張文字の一部がだぶるなどして復元不可、 CP51932 自身も復号できないらしい。)

[26] Registration of new charset CP51932 ( 版) http://mail.apps.ietf.org/ietf/charsets/msg01877.html

[68] Firefox は CP51932 + JIS X 0212 を実装していました。 復号だけでなく符号化にも使っていました。 >>69, >>70, >>71

  • [69] bug 4873 – EUC-JPエンコーダは補助漢字を変換すべきではない, http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4873
  • [71] bug 5184 – EUC-JPで、CP51932とJIS X 0212で重複定義されている文字がある場合、エンコーダがCP51932を優先してしまう, http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5184
  • [70] 革命の日々! プロジェクト「セーブ・ザ・鷗外」, , http://mkosaki.blog46.fc2.com/blog-entry-154.html

[111] Web上の日本語EUCデータに指定すべきエンコーディングは何か - なるせにっき, https://naruse.hateblo.jp/entry/20090722/1248255783

Encoding Standard

[72] 7444 – EUC-JP and ISO-2022-JP also need replacement encodings: CP51932 (or eucJP-ms) and CP50221., , https://www.w3.org/Bugs/Public/show_bug.cgi?id=7444

[24] Web Applications 1.0 r5560 Canonical mapping for EUC-JP for compat reasons.Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=7444 ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5559&to=5560

[25] ブログ オンラインサービス - Infoseekディレクトリ ( 版) http://directory.www.infoseek.co.jp/Topic/14/180/22633

Content-Type: text/html;charset=eucJp-open
<meta http-equiv="content-type" content="text/html; charset=euc-jp">

[53] なお、JIS X 0212 エンコーダの削除が Mozilla では提案されている http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5184

[10] Bug 600715 – Remove JIS X 0212 support from EUC-JP encoder ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=600715

[117] bug 5184 – EUC-JPで、CP51932とJIS X 0212で重複定義されている文字がある場合、エンコーダがCP51932を優先してしまう, http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5184

[118] 7444 – EUC-JP and ISO-2022-JP also need replacement encodings: CP51932 (or eucJP-ms) and CP50221., , https://www.w3.org/Bugs/Public/show_bug.cgi?id=7444

[11] Bug 16689 – consider a flag for euc-jp ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=16689

[12] Treat U+2022 as U+FF0D in Japanese encoders. Fixes https://www.w3.org… · whatwg/encoding@a7ab97e ( 版) https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd

[60] Fix #21: Japanese encoders have special treatment for U+2212, not U+2022 · whatwg/encoding@95f85a6 ( 版) https://github.com/whatwg/encoding/commit/95f85a63ad4d6b6331f21ff60f9244b3bcbe6d84

[61] Editorial: avoid upsetting lazy compilers (#55) ( (annevk著, )) https://github.com/whatwg/encoding/commit/9f7252a08211a623cabc5fe6b03dda7f0cc9ef11

[62] Note >8835 pointers in index jis0208 cannot be reached (annevk著, ) https://github.com/whatwg/encoding/commit/fb87552bfa03cc93a1077c8f13e2f58535d0e97c

[63] EUC-JP decoder: only unwind ASCII bytes (annevk著, ) https://github.com/whatwg/encoding/commit/a85149b9eb973e3ec543690fa1b8d5c441e8b3c0

[64] Editorial: check non-null before null (annevk著, ) https://github.com/whatwg/encoding/commit/4e53e160b9e0ade6e33a25d21580106a0db2c47f

[65] Comments on XML Part 1 from Japanese experts (Murata Makoto著, ) https://lists.w3.org/Archives/Public/w3c-sgml-wg/1997May/0612.html

[92] 超漢字4の新機能・変更点, , http://www.chokanji.com/support/ck4/chokanjians/vupguider4.html

EUC-JISX0208(補助漢字なし)の出力変換の機能を追加しました。

[100] 33220127 - Japanese_EUC.pdf, , https://public.dhe.ibm.com/as400/products/clientaccess/win32/files/globalization/Japanese_EUC.pdf