日本語EUC

EUC-JP (文字コード)

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

仕様書

符号化文字集合

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

文脈

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

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

関連

[16] 日本国内では外にシフトJISISO-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) が規定したのは

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

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

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

[22] 日本語EUCの歴史 ( 版) <http://d.hatena.ne.jp/nurse/20090308#1236517235>

[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版にも定義が含まれていると言われます。

[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] UJISIBM拡張漢字を加えたものが IBM-eucJP と言われています。

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

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

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

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

[56] 富士通U90 と呼ばれる拡張は、 G0JIS X 0201ラテン文字用図形文字集合 (!)、 G1JIS X 0208-1990G2JIS 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] DEC漢字コードセット (deckanji) は、 ASCII または JIS X 0201ラテン文字用図形文字集合JIS X 0208-1983 に加えて、 0xA121-0xFE7E に「DEC拡張漢字文字集合」を追加したものでした。

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

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

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

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

eucJP-open

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

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

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

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

JIS X 0213 による拡張

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

IANA charset EUC-JP

[5] IANAcharset登録簿には、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-JPSHOULD 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 2022JIS 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 SOLIDUSYEN SIGNの問題があります。 (図形文字の一意な符号化の項を参照。)

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

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

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

CP51932

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

Encoding Standard

[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">
  • [1] Mozilla で「&#169;」が含まれた文章を copy & paste で貼り付けてこの SuikaWiki に送ると、なぜかちゃんと保存・表示されました。 WinIE で見てもちゃんと文字化けしてるのに。変だなあと思って考えてみると、 SuikaWiki の出力・保存形式は EUC-JP で、 EUC-JPG3JISX0212-1990 で、その JIS X 0212-1990 には 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] Bug 600715 – Remove JIS X 0212 support from EUC-JP encoder ( ( 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=600715>

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