[1] [DFN[幽霊文字コード名]]は、
[[文字符号化]]の名称として説明されることがあるものの、
実際には利用も実装も確認できないものです。

* [CH[1]]付き

[2] 
[DFN[[CODE[HZ-GB-23121]]]],
[DFN[[CODE[X-ISO-10646-UCS-4-21431]]]],
[DFN[[CODE[X-ISO-10646-UCS-4-34121]]]]
は、
[CODE[HZ-GB-2312]],
[CODE[X-ISO-10646-UCS-4-2143]],
[CODE[X-ISO-10646-UCS-4-3412]]
が低品質なソフトウェアの[[ドキュメント]]において雑に[[コピペ]]されて生じた架空の[[文字コード]]の呼称です。


[4] 
発生源となった (がそれ自体には'''罪はない''') のは、
[CITE[juniversalchardet]]
というソフトウェアのドキュメントです。

[5] 
元々次のように書かれていました。 [SRC[>>3]]

>
-Chinese
--[SNIP[]]
-- HZ-GB-2312[SUP[1]]
-[SNIP[]]
-   Unicode
--[SNIP[]]
--        UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-3412[SUP[1]] / X-ISO-10646-UCS-4-2143[SUP[1]]
- [SNIP[]]
>
[B[1]] Currently not supported by Java

[6] 
すなわちこれら3つの[[文字符号化]]の名前の直後に脚注を表す「[SUP[1]]」がありました。
[[HTML]] の [CODE[sup]] [[要素]]で記述されていました。

[REFS[

- [3] 
[CITE@en[[[Google Code]] Archive - Long-term storage for Google Code Project Hosting.]], [TIME[2025-05-18T03:54:50.000Z]] <https://code.google.com/archive/p/juniversalchardet/>

]REFS]

[7] 
[CITE[juniversalchardet]]
は直接または間接に多くのソフトウェアの派生源となりました。
[SEE[ [[juniversalchardet]] ]]
派生時に[[ドキュメント]]も転用されました。
'''多くの派生物は[[文字コード]]の名称を適切に書いています'''が、
一部は誤った形で処理してしまいました。

[FIG(quote)[
[FIGCAPTION[
[8] 
[CITE[Release notes for Gerrit 2.1.2]], [TIME[2015-12-22T02:18:05.000Z]], [TIME[2025-05-18T04:01:15.750Z]] <https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.1.2.html>
]FIGCAPTION]

>
-
Improved character set detection
[BR[]]
Gerrit now uses the Mozilla character set detection algorithm when trying to determine what charset was used to write a text file. For UTF-8 or ISO-8859-1/ASCII users, there should be no difference over prior releases. With this change, the server can now also automatically recognize source files encoded in:
--a. Chinese (ISO-2022-CN, BIG5, EUC-TW, GB18030, HZ-GB-23121)
--[SNIP[]]
--g.Unicode (UTF-8, UTF-16BE / UTF-16LE, UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431)
--[SNIP[]]

]FIG]

[FIG(quote)[
[FIGCAPTION[
[CITE@ja[uchardet / uchardet · GitLab]], [TIME[2025-05-18T04:25:04.000Z]] <https://gitlab.freedesktop.org/uchardet/uchardet>
]FIGCAPTION]

>UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431

>HZ-GB-2312
]FIG]



[FIG(quote)[
[FIGCAPTION[
[9] 
[CITE@en[GitHub - PyYoshi/uchardet: uchardet is an encoding detector library, which takes a sequence of bytes in an unknown character encoding and attempts to determine the encoding of the text. Returned encoding names are iconv-compatible.]], [TIME[2025-05-18T04:03:37.000Z]] <https://github.com/PyYoshi/uchardet>
]FIGCAPTION]

>UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431

>HZ-GB-2312


]FIG]

[FIG(quote)[
[FIGCAPTION[
[10] 
[CITE@en[GitHub - PyYoshi/cChardet: universal character encoding detector]], [TIME[2025-05-18T04:04:23.000Z]] <https://github.com/PyYoshi/cChardet>
]FIGCAPTION]

>UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431

>HZ-GB-2312

]FIG]


[FIG(quote)[
[FIGCAPTION[
[11] 
[CITE@en[GitHub - CharsetDetector/UTF-unknown: Character set detector build in C# - .NET 5+, .NET Core 2+, .NET standard 1+ & .NET 4+]], [TIME[2025-05-18T04:05:30.000Z]] <https://github.com/CharsetDetector/UTF-unknown>
]FIGCAPTION]

>[B[Encodings with BOM]]: [CODE[utf-7]], [CODE[utf-8]], [CODE[utf-16be]]/[CODE[utf-16le]], [CODE[utf-32be]]/[CODE[utf-32le]], [CODE[X-ISO-10646-UCS-4-34121]]/[CODE[X-ISO-10646-UCS-4-21431]], [CODE[gb18030]].

>
,Chinese 	,"[CODE[iso-2022-cn]], [CODE[big5]], [CODE[euc-tw]], [CODE[gb18030]], [CODE[hz-gb-2312]]"

>
[B[Remarks]]: For some aliases of encoding not available: [CODE[cp949]], [CODE[iso-2022-cn]], [CODE[euc-tw]], [CODE[iso-8859-10]], [CODE[iso-8859-16]], [CODE[viscii]], [CODE[X-ISO-10646-UCS-4-34121]]/[CODE[X-ISO-10646-UCS-4-21431]]. [SNIP[]]


]FIG]

[FIG(quote)[
[FIGCAPTION[
- [12] 
[CITE@ja[Microsoft PowerPoint - MLTP_2010_9_6 - MLTP_Manual.pdf]], [TIME[2018-10-30T03:13:27.000Z]], [TIME[2025-05-18T04:13:39.428Z]] <https://www.tufs.ac.jp/ts/personal/corpuskun/pdf/2018/MLTP_Manual.pdf>
- [13] [CITE@ja[Microsoft PowerPoint - MLTP_2010_9_6 - MLTP.pdf]], [TIME[2010-11-05T12:43:40.000Z]], [TIME[2025-05-18T04:14:14.427Z]] <http://textdata.web.fc2.com/MLTP.pdf>
]FIGCAPTION]

>HZ‐GB‐23121

>UTF‐8, UTF‐16BE/16LE, UTF‐32BE/32LE/[BR[]]
X‐ISO‐10646‐UCS‐4‐34121/4‐21431

]FIG]


[14] 
これら現在までに確認されている用例は、いずれも[[ドキュメント]]にのみ出現するのであって、
実際のコードでは正しい名称が使われています。

[15] 
つまり開発者が内容をよく理解することなく雑に[[コピペ]]したために、
[[コード]]と[[ドキュメント]]が乖離しているのです。

* 幽霊文字コード

[16] [DFN[幽霊文字コード]]かもしれない: 
[[HKU]],
[[Unicode Consortium]] 版 [[Big5]]


[17] 
[CODE[X-ISO-10646-UCS-4-2143]], 
[CODE[X-ISO-10646-UCS-4-3412]]
ももしかすると[[幽霊文字コード]]かも。
おそらく [[XMLにおける文字コード]]に関する [CITE[XML]]
の[[附属書]]が根源で[[文字コードの判定]]の[[プログラム]]で [CN[BOM]]
の検出が実装されていることがあるものの、
この系統の資料と実装以外で全く見当たりません。
[[プラットフォーム]]の都合でそのような変則的な[[エンディアン]]の [[UCS-4]]
が[[内部符号]]などの形で使われた事例はもしかするとあったかもしれませんが、
そのようなデータが流通したとは到底思われませんし、
実装情報が出てこないので、対応プログラムがあったとしても当該[[プラットフォーム]]の極めて限られた範囲でのみ使われ得るものに限られると思われます。


;;
[18] もしそうだとするならこれも1つの「幽霊が幽霊を呼ぶ」の事案ですな。

* 関連

[SEE[ [[幽霊文字]] ]]

* メモ