856.txt

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

* 仕様書

[REFS[
- [54] [CITE@en-US[Encoding Standard]] ([TIME[2015-11-18 18:50:25 +09:00]] 版) <https://encoding.spec.whatwg.org/#euc-jp>
]REFS]

* 符号化文字集合

[55] 次の[[符号化文字集合]]を組み合わせたものです。
[FIG(list)[
- 0x00-0x7F ([[C0]]、[[G0]] 他) [[ASCII]]
- 0xA1A1-FEFE ([[G1]]) [[JIS X 0208]]
- 8x8EA1-8EFE ([[G2]]) [[JIS X 0201片仮名用図形文字集合]]
- 0x8FA1A1-8FFEFE ([[G3]]) [[JIS X 0212]]
]FIG]

* 文脈

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

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

* 関連

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

* 歴史

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

** 最初の日本語 EUC

[34] 日本語 UNIX システム諮問委員会が1985年に
[CITE[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)
が規定したのは
[FIG(list)[
- [[G0]] [[ASCII]]
- [[G1]] [[JIS X 0208-1983]]
- [[G2]] [[JIS X 0201片仮名用図形文字集合]]
- [[G3]] [[外字]] (予約領域)
]FIG]
... となっていたようです。

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

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

[22] [CITE[日本語EUCの歴史]] ([TIME[2009-03-10 09:51:02 +09:00]] 版) <http://d.hatena.ne.jp/nurse/20090308#1236517235>

[23] [CITE[石井晴久氏による EUC 前史]] ([TIME[2009-03-10 09:53:01 +09:00]] 版) <http://d.hatena.ne.jp/nurse/20090310#1236625695>

** 補助漢字の拡張

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

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

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

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

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

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

[21] [CITE@ja[革命の日々! IEがEUCのJIS X 212をサポートしていないのは規格違反なのか]] ([CODE[2007-06-24 19:43:01 +09:00]] 版) <http://mkosaki.blog46.fc2.com/blog-entry-260.html>

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

** その他の拡張

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

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

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

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

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

[56] [[富士通]]の [DFN[[[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 に対応付ける実装もあったようです。

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

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

** DEC の拡張

[27] [DFN[DEC漢字コードセット]] ([DFN[deckanji]]) は、
[[ASCII]] または [[JIS X 0201ラテン文字用図形文字集合]]と [[JIS X 0208-1983]]
に加えて、 0xA121-0xFE7E に「DEC拡張漢字文字集合」を追加したものでした。

;; [28] これは [[ISO/IEC 2022]] や [[EUC]] に違反する拡張方法です。

[29] 拡張のうち、1〜31区は利用者定義 ([[外字]]) とされました。1〜26区は [[DEC]]
版[[シフトJIS]]の 0xF040-0xFCFC に対応するとされていました。

[30] 拡張のうち、32〜94区は「DEC確保領域」とされていました。

[31] [DFN[Super DEC 漢字コードセット]] ([DFN[sdeckanji]]) は、
DEC漢字コードセットを更に拡張したもので、
[[EUC-JP]] と同様の [[JIS X 0201片仮名用図形文字集合]]と [[JIS X 0212-1990]]
がありました。ただし [[JIS X 0212]] 自体は未実装でした。
[[JIS X 0208]] 部分の85〜94区と [[JIS X 0212]] 部分の78〜94区は、
利用者定義 ([[外字]]) とされました。

[32] [DFN[DEC 漢字 2000 コードセット]] ([DFN[deckanji2000]]) は、
[[EUC-JISX0213]] を拡張したもので、
0xA121-0xFE7E が利用者定義 ([[外字]]) とされていました。
ただし [[JIS X 0213]] 第2面は未実装でした。

** [CODE[eucJP-open]]

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

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

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

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

[REFS[
- [52] <http://www.opengroup.or.jp/jvc/cde/sjis-euc.html>
]REFS]

** JIS X 0213 による拡張

[17] そして [[JISX0213]]:2000 の附属書が定義する [[EUC-JISX0213]]。

** IANA charset [CODE(MIME)@en[EUC-JP]]

[5] [[IANA]]の[[charset]]登録簿には、2006年3月現在
[PRE[
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)
]PRE]

とあります。

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

** 文字符号化[CODE(XML)@en[EUC-JP]] (XML)

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

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

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

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

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

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

[9] 更に厳密には、その[Q@en[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]]と解釈する方が適当だと思われます。
[WEAK[(ただし、7.2には[[IRV]]と明記されていますが、こちらでは明記されていないのが気に掛かります。)]]

** CP51932

[26] [CITE[Registration of new charset CP51932]]
([TIME[2010-04-05 03:44:39 +09:00]] 版)
<http://mail.apps.ietf.org/ietf/charsets/msg01877.html>

** Encoding Standard

[24] [CITE@en[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]]
( ([TIME[2010-09-30 04:14:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=5559&to=5560>

[25] [CITE@ja[ブログ オンラインサービス - Infoseekディレクトリ]] ([TIME[2007-08-02 22:05:24 +09:00]] 版) <http://directory.www.infoseek.co.jp/Topic/14/180/22633>

>
[PRE(HTTP example code)[
Content-Type: text/html;charset=eucJp-open
]PRE]

>
[PRE(HTML example code)[
<meta http-equiv="content-type" content="text/html; charset=euc-jp">
]PRE]


- [1] [[Mozilla]] で「&#169;」が含まれた文章を copy & paste
で貼り付けてこの [[SuikaWiki]] に送ると、なぜかちゃんと保存・表示されました。
[[WinIE]] で見ても''ちゃんと''文字化けしてるのに。変だなあと思って考えてみると、
SuikaWiki の出力・保存形式は [CODE[EUC-JP]] で、 [CODE[EUC-JP]] の [[G3]]
は [[JISX0212]]-1990 で、その JIS X 0212-1990 には [CODE(CHARNAME)[COPYRIGHT SIGN]]
が規定されているので、きちんと保存・表示出来て当たり前なのでした。
- [2] >>1 つまり Mozilla はちゃんと EUC-JP に対応しているということです。
WinIE は EUC-JP 対応と見せかけて、実は [[CP20932]] にしか対応していませんね。
- [3] ちなみに [[ClassicMozilla]] も未対応っぽいです。
- [4] >>2 ちがうよ、WinIE が対応しているのは [[CP51932]] だよ

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

[10] [CITE[Bug 600715 – Remove JIS X 0212 support from EUC-JP encoder]]
( ([TIME[2011-12-20 23:53:05 +09:00]] 版))
<https://bugzilla.mozilla.org/show_bug.cgi?id=600715>

[11] [CITE@en[Bug 16689 – consider a flag for euc-jp]]
( ([TIME[2013-09-25 02:59:36 +09:00]] 版))
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=16689>

[12] [CITE@en[Treat U+2022 as U+FF0D in Japanese encoders. Fixes https://www.w3.org… · whatwg/encoding@a7ab97e]]
([TIME[2015-08-21 18:14:36 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd>

[60] [CITE@en[Fix #21: Japanese encoders have special treatment for U+2212, not U+2022 · whatwg/encoding@95f85a6]]
([TIME[2015-12-16 12:32:17 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/95f85a63ad4d6b6331f21ff60f9244b3bcbe6d84>