好きな文字化け発表ドラゴンが好きな文字化けを発表します
あわせて、好きな文字化け解説人間が好きな文字化けを解説します。
Pok駑on
【個人的暫定読み: ポクドオン】
大半が正常な英字で構成された文字列の中にたまに漢字などが混じるのは、ほぼ全体がASCII内の文字で書かれた欧文からの文字化けである。ASCII文字はあまり化けないので、わずかに混じった特殊文字のみ化けることで特徴的な見た目になる。
中でも化け部が主に漢字1文字なのはLatin-1→Shift_JIS。
Latin-1は俗称で正式にはISO/IEC 8859-1だったり実際にはそれの亜種のWindows-1252だったりするが、覚えられないのでいつもLatin-1と呼んでいる。8xと9xの列に文字がある方がWindows-1252。
Latin-1は古くから欧米で主流の文字コード、Shift_JISは古くから日本で主流の文字コードであるから、非常によくある文字化けである。
特殊文字がShift_JISでは2バイト文字に相当する場合が多く、その場合後続の1文字を巻き込んで化ける。
元は「Pokémon」。
他に好きなのが
Français→Fran軋is 【フランキシリス】
“Company→鼎onpany 【カナエァンパニー】
あたり。
特殊文字がShift_JIS側で1バイト文字だった例としては有名どころの
SUPER©→SUPERｩ 【スーパーウ】
もはやこのソフト名は「SUPERｩ」と言ったほうが通りがいいと思う。
ﾁｬｽﾓﾊｧｰﾜ｣｡
【チャスモハアーワ】
連続する半角カナはEUCからShift_JISへの化けの特徴。
ただしEUCにも複数あり、日本人におなじみなのはEUC-JPだがこれは中国の文字コード、EUC-CN…とはあまり呼ばず、文字集合名のGB 2312やGBKで呼ばれる。
国家標準GuojiaBiaozhunでGB。拡張KuozhangしたのがGBK。
元は「连接失败！」。ニュースで話題になった。
ｱｼｸｲ
【アシクイ】
同様にEUCからShift_JIS、これはEUC-KR。化け後の文字列から元がEUC-何だったかの判別は難しい。日中韓全部試してみるしかないだろう。
元は「글림」、Windows標準搭載のフォント名で他国語表記は「Gulim」。
アシアナ航空を見るとｱｼｸｲを思い出していたのだが無くなってしまった。
コードが数文字ズレてるやつ
PDFで見られるものだ。
一例を上げると「エンティティ」→「エンテゖテゖ」になっているものを見たことがある。
どうズレてそう化けたか分からないようなものも多い中、これはわりとわかって、
JIS X 0208とJIS X 0213で定義されている文字を並べると、
～んァア[ィ]イゥ…
～んゔゕ[ゖ]ゟァアィイゥ…
というようになっており、平仮名に「ゔゕゖゟ」が追加された分4文字ズレていると考えると実物に合致する。
似た理屈で化けているものに「ヒテッマン」がある。
これはドラゴンクエスト4のバグ動画で有名な文字化けなのだが、これが起こる原因は次のようなものだ。
ドラクエ4の文字コードはひらがなモードとカタカナモードをシフトする構造になっている。
ここでバグにより文字列データを想定外の場所から読むとシフト状態が崩れることがあるが、
ドラクエ4のカタカナは全種類揃っていないため次のような詰めた並びになっているため、文字がズレる化け方になる。
あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよらりるれろわをん
アイエオカキクコサシスソタテトナニヌネノハヒフホマミムメモラルレロンッャ
「ヒテッマン」は「にせものめ」であったことが分かる。
正式名称が分からない文字コードも好き好き大好き
ところでこのPDFで使われてる文字コードは何なんだろう。
AdobeJapan1のたぐいなのかとも思うが、それでは説明の付かないようなズレ方もよく見るので、使われている文字だけを含んでいるのかとも思う。
好きな文字化け発表ドラゴンが好きな文字化けを発表します
します。
ふわ㍉
【ふわミリ】
こちらのTogetterで話題になった文字化けである。
『木内印刷は凄かった』コミケを出禁になった伝説の印刷所（倒産済み）の思い出話「独特の匂いがしたので木内か、とわかる」 - Togetter [トゥギャッター]
「ふわぁ」→「ふわ㍉」
「ああっ」→「ああ㍇」
などと化けている。
推測される原因であるが、MacJapaneseコードにおいて縦書き用の文字が古いバージョンでは11,14,15区に割り付けられていたもが途中から84区以降に変わったらしく、縦書き用の字形のある小書き仮名が化けたものだろう。
�ｿｽ
【ハテナそす】
化け方は化け元と化け先の文字コードだけでは決まらんそす。読むソフトに依存する場合もあるそす。
U+FFFD「�」をUTF-8で保存したものをShift_JISで読んだとき、不正な2バイトシーケンスを不正な1文字と解釈して2バイト消費すると「・ｽ」になるそすが、
最近ではセキュリティー面から不正なバイト列は1バイトづつ消費するのが適切だと考えられているそす。そのタイプのソフトで読むと「�ｿｽ」になるそす。
余談
「そす」は『メイドインアビス』作中の数千年前の先住民の言語において話の区切りに付ければしとやかとなるとされている言葉そす。作中の姫がしとやかになろうとして使っていることで知られるそす。たぶん標準語に混ぜているせいで不自然になっているそす。
恕ﾘがる
【じょリがる】
InternetExplorerに特有の文字化け…だと思っていたが今ググっても結構存在する。他のソフトでも起こるようだ。
元は「繫がる」
これは何かというと、「繫」の文字はJIS X 0208に含まれずJIS X 0212(補助漢字)に含まれる文字であり、EUC-JPではシフトを含めた3バイトで表現されるのだが、この3バイトの文字を解釈できるソフトがあまり無く、読めないだけならまだしも何故かこの3バイトだけShift_JISとして解釈してしまうという不思議な挙動をするためにこのように化けている。
なお怒りっぽいが「恕」の字の意味は「ゆるす」。熟語としては「寛恕」などに使われる。
他にIE固有の文字化けとして「ｩ」がある。
これはSymbolフォントで「♥」を表示させようとしたものである。
SymbolフォントはUnicodeの無い昔に特殊文字を表示するために使われたフォントで、普通の英字に対応する字形がギリシャ文字になっていたり、Latin-1領域に様々な記号を含むものだ。
その中で「©」には「♥」の字形が割り当てられている。なので「©」を書いてフォントをSymbolにすれば非Unicode環境でも「♥」が表示できるというわけだ。
ただ、英語圏ではLatin-1コードが普通なので問題ないが、日本語環境では「©」は素のままでは入力できない。文字実体参照をするのが正当な方法なのだが、
しかしIEに限っては、Latin-1以外の文字コードであってもSymbolフォントで表示するときはLatin-1として解釈するという不思議な仕様がある。
上のSUPERｩでも述べたが©に対応する(Shift_)JISの文字は「ｩ」であるため、日本では「ｩ」と書いてSymbolフォントにすると「♥」が表示されると理解されてしまった。
結果としてIE以外のブラウザで見ると「ｩ」になる。
半角ハングル出てくるやつ
実物は記録していなかったので再現なのだが、例えばこんな感じだったような。
￥ﾍﾊ￨ﾧﾒ￣ﾃﾏ￣ﾃﾳ￣ﾂﾰ￣ﾃﾫ
化けの法則が分からない文字化けも好き好き大好き
これが長い間分からなかったのだがある時気づいて、おそらく符号拡張で問題が起こったものと思われる。
半角ハングルはUnicodeのU+FFxxのあたりにある。この数値が出てくる理由として思いつくのは符号拡張だ。
何らかの文字コードを1バイトごとに見て、0x80超えのバイトをint8として見たものをint16に符号拡張する処理が入っていたのではないかと思っている。
好きな文字化け発表ドラゴンが好きな文字化けを発表します
ます。
臼NG
【うすング】
これは文字化けと言ってよいのか微妙だが、元はPNGファイルであったものがShift_JISの文字として解釈されてしまったものである。
個人的には元々文字列だったものが文字コードの解釈の違いによって別の文字列として表示されてしまうものを文字化けと呼んでいるが、文字列でないデータを文字列として読んでしまうものもわりと文字化けと呼ばれているように思う。
PNGのシグネチャの先頭バイトは文書ファイルと区別がつくようにとASCII外の「0x89」となっているのだが、Shift_JISでは文字として使われているバイトで、次のPを巻き込んで「臼」の1文字として読めてしまう。
電屍ミネー
【でんしミネー】
こちらのTogetterで話題になった文字化けである。
自販機の表示のバグり具合がもうどうかしていて爆笑「どうしたらそうなる(笑)」「異界かと」→真相は? - Togetter [トゥギャッター]
当該の投稿は削除されてしまっているが、次のような文字列が自販機のVFD画面に表示されている画像であった。
電屍ミネー!!!!!!
さ吏用ににろみす
感嘆符が勢いがあってよい。
元の文字列は次のとおりであろう。
電子マネー
ご利用になれます
これはJISコードとして見ると、化けている文字の化け元と化け先が最下位bitが0から1になっただけの違いであり、化けていない文字は最下位bitが1であることが分かる。
45 45 3B 53 25 5F 25 4D 21 3C 21 21 21 21 21 21 電屍ミネー!!!!!!
24 35 4D 79 4D 51 24 4B 24 4B 24 6D 24 5F 24 39 さ吏用ににろみす
45 45 3B 52 25 5E 25 4D 21 3C 20 20 20 20 20 20 電子マネー
24 34 4D 78 4D 51 24 4B 24 4A 24 6C 24 5E 24 39 ご利用になれます
ここから考えられる原因としては、漢字ROMのアドレス線の最下位bit部分だけが1に張り付いているなどの回路の故障ではなかろうか。
ﾌﾌﾌﾌ
【フフフフ】
プログラムが異常になったときによくﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌと大量にﾌが並んで出ることがある。バイトで言うと0xCC。
これはソフトがよくメモリの未使用領域を埋めておく値である。コンパイラによって、またオプションによっても違うだろうが、少なくともVisualStudioのデバッグビルドで出た。
この0xCCというのはx86における「INT3」命令であり、1バイト命令で割り込みを発生させられるためデバッグによく用いられるものだ。
プログラムのバグで想定外の場所を実行してしまったときにすぐ止められるようにこの値が使われている。
縺れと繧繝出てくるやつ
縺(もつ)れと繧繝(うんげん)。
こんなやつね
・ｿ繝｡繝ｭ繧ｹ縺ｯ豼諤偵＠縺溘ょｿ・★縲√°縺ｮ驍ｪ譎ｺ證ｴ陌舌・邇九ｒ髯､縺九↑縺代ｌ縺ｰ縺ｪ繧峨〓縺ｨ豎ｺ諢上＠縺溘・
UTF-8かな、それってUTF-8だね
Latin-1→Shift_JISと双璧をなす定番。UTF-8→Shift_JISの文字化け。
UTF-8で日本語を書くとひらがなカタカナのあるU+304x～U+30Fxあたりが
0011 000001 000001 : 3041
11100011 10000001 10000001 : E3 81 81
0011 000011 111111 : 30FF
11100011 10000011 10111111 : E3 83 BE
と変換されて「0xE3」「0x81～0x83」「0xXX」という形の3バイトになり、
前2バイトの「0xE3」「0x81～0x83」をShift_JISで解釈するとどうなるかというと、
E3+
7C7D7E808182838485868788
縹繃縷縲縺繧繝繖繞繙繚繹
となっているうちの縺・繧・繝の3つが相当するわけだ。(最近の等幅フォントは英字と和字が2:1で揃わないようだが適宜察してほしい)
またU+3000～3040の部分にも「。」など記号類がちょっと入っているので、対応する「縲」もちょっと出る。
残った3バイトめは0x80～0xBFとなるが、このうち半分のA1～BFは半角カナに相当して1バイトで1文字になるため、3バイトの区切りが崩れにくい。
BOM付き大好き
化けないからね。
文字化けは好きだけど化けないに越したことはないよ。
好きな文字化けがまた出てきたそのときは発表したい 発表したい
発表したい。