幽霊文字コード名

Edit New

幽霊文字コード名

[1] 幽霊文字コード名は、 文字符号化の名称として説明されることがあるものの、 実際には利用も実装も確認できないものです。

1付き

[2] HZ-GB-23121, X-ISO-10646-UCS-4-21431, X-ISO-10646-UCS-4-34121 は、 HZ-GB-2312, X-ISO-10646-UCS-4-2143, X-ISO-10646-UCS-4-3412 が低品質なソフトウェアのドキュメントにおいて雑にコピペされて生じた架空の文字コードの呼称です。

[4] 発生源となった (がそれ自体には罪はない) のは、 juniversalchardet というソフトウェアのドキュメントです。

[5] 元々次のように書かれていました。 >>3

  • Chinese
    • HZ-GB-23121
  • Unicode
    • UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431

1 Currently not supported by Java

[6] すなわちこれら3つの文字符号化の名前の直後に脚注を表す「1」がありました。 HTML の sup 要素で記述されていました。

[7] juniversalchardet は直接または間接に多くのソフトウェアの派生源となりました。 juniversalchardet 派生時にドキュメントも転用されました。 多くの派生物は文字コードの名称を適切に書いていますが、 一部は誤った形で処理してしまいました。

[8] Release notes for Gerrit 2.1.2, , https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.1.2.html
  • Improved character set detection 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)
    • g.Unicode (UTF-8, UTF-16BE / UTF-16LE, UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431)
uchardet / uchardet · GitLab, https://gitlab.freedesktop.org/uchardet/uchardet

UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431

HZ-GB-2312

[9] 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., https://github.com/PyYoshi/uchardet

UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431

HZ-GB-2312

[10] GitHub - PyYoshi/cChardet: universal character encoding detector, https://github.com/PyYoshi/cChardet

UTF-32BE / UTF-32LE / X-ISO-10646-UCS-4-34121 / X-ISO-10646-UCS-4-21431

HZ-GB-2312

[11] GitHub - CharsetDetector/UTF-unknown: Character set detector build in C# - .NET 5+, .NET Core 2+, .NET standard 1+ & .NET 4+, https://github.com/CharsetDetector/UTF-unknown

Encodings with BOM: utf-7, utf-8, utf-16be/utf-16le, utf-32be/utf-32le, X-ISO-10646-UCS-4-34121/X-ISO-10646-UCS-4-21431, gb18030.

Chineseiso-2022-cn, big5, euc-tw, gb18030, hz-gb-2312

Remarks: For some aliases of encoding not available: cp949, iso-2022-cn, euc-tw, iso-8859-10, iso-8859-16, viscii, X-ISO-10646-UCS-4-34121/X-ISO-10646-UCS-4-21431.

HZ‐GB‐23121

UTF‐8, UTF‐16BE/16LE, UTF‐32BE/32LE/ X‐ISO‐10646‐UCS‐4‐34121/4‐21431

[14] これら現在までに確認されている用例は、いずれもドキュメントにのみ出現するのであって、 実際のコードでは正しい名称が使われています。

[15] つまり開発者が内容をよく理解することなく雑にコピペしたために、 コードとドキュメントが乖離しているのです。

幽霊文字コード

[16] 幽霊文字コードかもしれない: HKU, Unicode Consortium 版 Big5

[17] X-ISO-10646-UCS-4-2143, X-ISO-10646-UCS-4-3412 ももしかすると幽霊文字コードかも。 おそらく XMLにおける文字コードに関する XML の附属書が根源で文字コードの判定のプログラムで BOM の検出が実装されていることがあるものの、 この系統の資料と実装以外で全く見当たりません。 プラットフォームの都合でそのような変則的なエンディアンの UCS-4 が内部符号などの形で使われた事例はもしかするとあったかもしれませんが、 そのようなデータが流通したとは到底思われませんし、 実装情報が出てこないので、対応プログラムがあったとしても当該プラットフォームの極めて限られた範囲でのみ使われ得るものに限られると思われます。

[18] もしそうだとするならこれも1つの「幽霊が幽霊を呼ぶ」の事案ですな。

関連

幽霊文字

メモ

Updated: