EUC-JP (文字コード)

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

仕様書

[54] Encoding Standard (2015-11-18 18:50:25 +09:00 版) https://encoding.spec.whatwg.org/#euc-jp

符号化文字集合

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

0x00-0x7F (C0、G0 他) ASCII
0xA1A1-FEFE (G1) JIS X 0208
8x8EA1-8EFE (G2) JIS X 0201片仮名用図形文字集合
0x8FA1A1-8FFEFE (G3) JIS X 0212

文脈

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

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

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

<meta http-equiv="Content-Type" content="text/html; charset=EUC-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) が規定したのは

... となっていたようです。

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

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

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

[23] 石井晴久氏による EUC 前史 (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 の 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

G0 = GL : ASCII >>29 / 旧IRV >>32
G1 = GR : JIS X 0208-1990
- 旧IRVと重複する文字は使用しない >>32
G3 (SS3 + GL) : JIS X 0212 (使用するかどうかは応用依存)

[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)

[21] 革命の日々! IEがEUCのJIS X 212をサポートしていないのは規格違反なのか (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であるとみなせます。 (名無しさん 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] EUC-HJ (Extended UNIX Code HITACHI) は 0xA121-FE7E を利用者定義 (外字) に使っていました。

DEC漢字と同じ方式。

[44] OCMP (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., 2012-12-21T13:28:17.000Z, 2022-05-05T09:31:01.382Z https://lists.x.org/archives/xorg-devel/2012-December/034661.html

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

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

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

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 との対応関係が規定されていました。

[67] eucJP-ms, 2009-03-29T07:45:14.000Z, 2022-05-04T08:01:17.437Z http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html

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

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:

CL = C0 : JIS X 0211 C0
SP
GL : ISO/IEC 646 IRV
DEL
CR = C1 : JIS X 0211 C1
GR : JIS X 0213:2000 第1面
SS2 / G2 : 使用しない、ただし代替名称
SS3 / G3 : JIS X 0213:2000 第2面
- IRV との重複は使用しない、ただし代替名称
- 実装水準3では原則、使用しない

[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, 94²集合

[81] ucm/euc-jp.ucm - metacpan.org, 2022-04-07T03:18:23.000Z, 2022-05-08T00:58:52.058Z 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)の使用, 2022-02-09T18:54:35.000Z, 2022-05-08T01:40:25.443Z https://www.orca.med.or.jp/receipt/use/jisx0213/

[90] 文字セットについて - 超漢字ウェブサイト, 2010-11-10T00:23:26.000Z, 2022-09-03T06:57:23.660Z http://www.chokanji.com/ckv/manual/06-05-07.html

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

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と明記されていますが、こちらでは明記されていないのが気に掛かります。)

CP51932

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

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

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

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

Encoding Standard

[72] 7444 – EUC-JP and ISO-2022-JP also need replacement encodings: CP51932 (or eucJP-ms) and CP50221., 2019-04-02T04:11:06.000Z, 2022-05-04T08:19:53.361Z 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 ( (2010-09-30 04:14:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=5559&to=5560

[25] ブログオンラインサービス - Infoseekディレクトリ (2007-08-02 22:05:24 +09:00 版) 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">

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