物語の始まり
事の発端は納品後。
先方からメッセージが届きました。
クライアント様「このファイルの文字コードがShift_JISになっておりますので、UTF-8で再納品をお願いいたします。」
拙者（あれ…UTF-8にしてたと思うんだけどな）
拙者「確認いたします。」
文字コードを確認する
本案件はいわゆる更新案件で、今回の納品時に言われていたのは、「文字コードがUTF-8ではないものは変換して納品してくれ」ということ。
そして、ご指摘いただいたのは、今回の更新案件で中身はいじらなかったJavaScriptファイル。
本来ならば納品するファイルではないのですが、文字コード変換という要件があったため、納品ファイルとして加えられたものでした。
一括で文字コードを変えたので作業漏れかなぁと思っていました。
ファイルの中身は記事用にかなり適当につくったものですが、まあだいたいこんな感じです。
const outputMessage = function () {
console.log('sample');
};
エディタで確認する
私はVSCodeでコーディングを行っておりましたので、まず見るところはウィンドウの右下です。
確かにUTF-8にはなっています。
ターミナルで確認する
Macで作業しておりましたので、ターミナルで文字コードを確認します。
まず、fileコマンドを使用してみます。
--mimeオプションをつけて、Web屋さんにはおなじみであろうMIMEタイプで出力してもらいます。
$ file --mime sample.js
sample.js: text/plain; charset=us-ascii
あれ？
nkfコマンドでも試します。(homebrewから導入しました)
$ nkf -g sample.js
ASCII
文字コードはASCII（アスキー）だった
改めてsample.jsを見返してみると、ASCIIと互換性のある1バイト文字しか使っていませんでした。
互換性のある文字コード部分しか使っていないために、コンピュータにはASCIIもUTF-8もShift_JISも同じに見え、閲覧環境のデフォルトエンコーディング設定によってはUTF-8と表示されたり、Shift_JISと表示されるのだろう、クライアントの閲覧環境はデフォがShift_JISなんだろうと予測しました。
つまり、納品したファイルは、互換性がある文字のみを含んでいるため、文字コードをShift_JISからUTF-8に変換しようとしても変換できないファイルだったということです。
検証
このままお返しするにはエビデンスが足りない気がしたので、本当にUTF-8にしてもShift_JISにしても同じデータなのか確認します。
文字コード表を確認
まずは、UTF-8とShift_JISの文字コードを確認します。
便宜上16進数で説明を進めます。
ビット・バイト・16進数などの説明は省きます。
ASCII
ASCIIは7ビットコードです。
00〜1Fは制御文字、20は空白となっており、その次が印字可能文字、つまり記号やABC...が始まります。
表を全部書くのは大変なので一部抜粋します。（フルバージョンはWikipedia）
| -0 | -1 | -2 | -3 | -4 | -5 | -6 | -7 | -8 | -9 | -A | -B | -C | -D | -E | -F | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 4- | @ | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O |
| 5- | P | Q | R | S | T | U | V | W | X | Y | Z | [ | \ | ] | ^ | _ |
つまり、16進数で表した時、0x41→A、0x5A→Zとなります。(0xは16進数であることを表す)
UTF-8
UTF-8は、ASCIIと互換性をもたせるため、ASCIIと同じ部分は1バイトで表現し、その他は2〜6バイトで表現します。
つまり、ASCIIで定義されている記号や英数字部分は全く同じです。
Shift_JIS
Shift_JISは、JIS X 0201部分を1バイトで表現し、JIS X 0208部分を2バイトで表現します。
平たく言えば、JIS X 0201は半角英数とカタカナを表現し、JIS X 0208がその他日本語を表現する部分です。
この、JIS X 0201の英数字部分はASCIIと全く同じ、というわけではなく、実は印字した際に変わるものが2つあります。
それは、0x5Cと、0x7Eになります。
ASCIIでは、それぞれ「\（バックスラッシュ）」「~（チルダ）」と表示されますが、Shift_JISでは「¥（円マーク）」「‾（オーバーライン）」と表示されます。
このバックスラッシュが厄介で、文字化けの原因になったりしますが、それはまた別のお話。
ただし、表示されるものが変わるというだけで、バイナリとしてはASCIIと同じなので、Shift_JISかそれ以外かという判断はできないということになります。
バイナリを確認する
これらを言葉で説明するのはなかなか面倒なので、実際にバイナリを確認して差分をとれば立派なエビデンスになるのでは！？と考えた私はバイナリを覗きました。
今回はxxdコマンドを使います。（odとかhexdumpでもヨシ、癖がない気がするのでxxdがすこ）
xxdは、ファイルや標準入力から受け取ったものを2進数、もしくは16進数でダンプできるコマンドです。
厳密に言えばバイナリ（2進数）ではないですが。。。
ASCII
まずはASCIIのまま。
$ xxd sample.js
00000000: 636f 6e73 7420 6f75 7470 7574 4d65 7373 const outputMess
00000010: 6167 6520 3d20 6675 6e63 7469 6f6e 2028 age = function (
00000020: 2920 7b0a 2020 636f 6e73 6f6c 652e 6c6f ) {. console.lo
00000030: 6728 2773 616d 706c 6527 293b 0a7d 3b g('sample');.};
UTF-8
これをnkf -wで文字コードをUTF-8に変換して、もう一度xxdで見てみます。
$ nkf -w sample.js > sample_utf8.js
$ xxd sample_utf8.js
00000000: 636f 6e73 7420 6f75 7470 7574 4d65 7373 const outputMess
00000010: 6167 6520 3d20 6675 6e63 7469 6f6e 2028 age = function (
00000020: 2920 7b0a 2020 636f 6e73 6f6c 652e 6c6f ) {. console.lo
00000030: 6728 2773 616d 706c 6527 293b 0a7d 3b g('sample');.};
パッと見同じです。ダンプして差分を取ってみます。
$ xxd sample.js > sample_b
$ xxd sample_utf8.js > sample_utf8_b
$ diff sample_b sample_utf8_b # 出力なし
ですよねー。
ちなみに、文字コードを確認しても、
$ file --mime sample_utf8.js
sample_utf8.js: text/plain; charset=us-ascii
Shift_JIS
続いて、Shift_JIS。
nkf -sで文字コードをShift_JISに変換します。
$ nkf -s sample.js > sample_sjis.js
$ xxd sample_sjis.js
00000000: 636f 6e73 7420 6f75 7470 7574 4d65 7373 const outputMess
00000010: 6167 6520 3d20 6675 6e63 7469 6f6e 2028 age = function (
00000020: 2920 7b0a 2020 636f 6e73 6f6c 652e 6c6f ) {. console.lo
00000030: 6728 2773 616d 706c 6527 293b 0a7d 3b g('sample');.};
$ xxd sample_sjis.js > sample_sjis_b
$ diff sample_b sample_sjis_b # 出力なし
$ file --mime sample_sjis.js
sample_sjis.js: text/plain; charset=us-ascii
こちらも差分なし、ということでバイナリ的にも全く一緒のデータであることが分かりました。
おまけ：日本語だとちゃんと差分が出ることを確認する
const outputMessage = function () {
console.log('サンプル');
};
$ file --mime sample_jp.js
sample_jp.js: text/plain; charset=utf-8 # 日本語を含んだのでutf-8と認識されている
$ xxd sample_jp.js
00000000: 636f 6e73 7420 6f75 7470 7574 4d65 7373 const outputMess
00000010: 6167 6520 3d20 6675 6e63 7469 6f6e 2028 age = function (
00000020: 2920 7b0a 2020 636f 6e73 6f6c 652e 6c6f ) {. console.lo
00000030: 6728 27e3 82b5 e383 b3e3 8397 e383 ab27 g('............'
00000040: 293b 0a7d 3b );.};
$ xxd sample_jp.js > sample_jp_b
$ nkf -s sample_jp.js > sample_jp_sjis.js
$ file --mime sample_jp_sjis.js
sample_jp_sjis.js: text/plain; charset=unknown-8bit # unknown-8bit = SJISの意
$ nkf -g sample_jp_sjis.js # 念の為nkfコマンドで確認 (-g もしくは --guess)
Shift_JIS
$ xxd sample_jp_sjis.js
00000000: 636f 6e73 7420 6f75 7470 7574 4d65 7373 const outputMess
00000010: 6167 6520 3d20 6675 6e63 7469 6f6e 2028 age = function (
00000020: 2920 7b0a 2020 636f 6e73 6f6c 652e 6c6f ) {. console.lo
00000030: 6728 2783 5483 9383 7683 8b27 293b 0a7d g('.T...v..');.}
00000040: 3b ;
$ xxd sample_jp_sjis.js > sample_jp_sjis_b
$ diff sample_jp_b sample_jp_sjis_b
4,5c4,5
< 00000030: 6728 27e3 82b5 e383 b3e3 8397 e383 ab27 g('............'
< 00000040: 293b 0a7d 3b );.};
---
> 00000030: 6728 2783 5483 9383 7683 8b27 293b 0a7d g('.T...v..');.}
> 00000040: 3b ;
報告
拙者「確認いたしましたが、英数字（一部記号）のみ含まれているファイルでして、UTF-8とShift_JISでバイト表現は共通ですので、納品させていただいたファイルで問題ありません。」
クライアント様「文字コードを変換して納品してください。」
拙者「…あ、変換してもバイト表現が一緒なのｄ」
クライアント様「文字コードを変換して納品してください。」
拙者「……承知いたしました。」
〜変換（全く同じファイルを納品）〜
拙者「データとしては同じものですので、文字コードを確認する環境のエンコード設定がShift_JISになっている可能ｓ」
クライアント様「文字コードの変更が確認できませんでした。今回は、本ファイルに関して本番アップロードをしない運びといたします。」
拙者「はい。
」
まとめ
私が完全敗北した理由として、
- 文字コードについて、私がうまく表現できなかった
- クライアント（のIT担当部署）様に話が届くまで、数社（数人）を介さないと言葉が届かない伝言ゲーム案件だった
- バイナリの話をしても伝わらない気がしたので、エビデンスのためにあれこれ出力したファイルは提出しなかった
- 出力したファイルも伝言ゲームしてもらう必要があるためちょっと躊躇した
当たり前だろと思われる内容だったかもしれませんが、また同じ状況になったとき、同様の検証や伝達がスムーズに行えるようにまとめた記事でした。
追記：半ば無理やりUTF-8にしてしまう方法
2021/04/01: コメントを受け追記しました。コメントありがとうございます！
今回は案件の特性上突っ込まれそうだったのでやりませんでしたが、ファイルにマルチバイト文字を含ませることで文字コードを指定することができます。
// コメント
const outputMessage = function () {
console.log('sample');
};
このように適当に日本語でコメントを追加してしまえば、
$ file --mime sample_comment.js
sample_comment.js: text/plain; charset=utf-8
というように、UTF-8になりました。
（今思えば無理やりコメント追記すればよかったなぁ。。）
コメント
@math-oh24 ![heeroo_ymsw](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@heeroo_ymsw1 
@saitofjp5 ![heeroo_ymsw](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@heeroo_ymsw1 
@fujitanozomu1 ![libraplanet](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@libraplanet（編集済み） 2 ![kishibashi3](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@kishibashi3（編集済み） 0 
@felis6 ![libraplanet](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@libraplanet（編集済み）
「文字コードを自動判別する」と言う幻想を打ち砕く👊 - Qiita https://qiita.com
1 
@nakamchi2 ![kishibashi3](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@kishibashi3（編集済み） 0 ![libraplanet](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@libraplanet（編集済み） 0 ![kishibashi3](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@kishibashi3（編集済み） 0 
@kenichiro_ayaki2 ![a_k_](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@a_k_0 ![libraplanet](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@libraplanet（編集済み）
バイト順マーク - Wikipedia https://ja.wikipedia.org
FAQ - UTF-8, UTF-16, UTF-32 & BOM http://www.unicode.org
FAQ - UTF-8, UTF-16, UTF-32 & BOM http://www.unicode.org
1 ![a_k_](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>)
@a_k_0 
@otaks0
私はそういうのを分かっていない相手に説明するのも面倒(というか時間の無駄)なので、適当にマルチバイト文字を含んだコメントを追記して保存し直して渡してます。
既にファイル中に既存のコメントがあるなら、どこか適当なコメントの行末に全角スペースでも追加しておけば見た目は変えず文字コードは固定できます。
要は、ファイル中のコード実行内容に影響しない部分にマルチバイト文字を含めてしまえばいいのです。
@math-oh
閲覧＆コメントありがとうございます。
今回は案件の特性を考えて、コメントは諦めてしまいました。。。
ご指摘の手法、邪道だったりするのかな…とも思ったのですが、やっぱりやられている方いらっしゃるんだなぁととても参考になりました！
記事にも追記しておこうと思います。
ありがとうございます！
https://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4%E3%83%88%E9%A0%86%E3%83%9E%E3%83%BC%E3%82%AF
かも
@saitofjp
実はBOM付き求められていたオチ…！
その可能性も拭えませんね。。。
BOM付きを避けた理由が知りたい
円記号問題を引き合いに出すなら。
本来
ASCIIには円記号 (¥)は収録されておらず。UTF-8もLatin1がベースなので。SJISの0x5C (¥)はUTF-8ならU+5C (\)ではなくU+A5 (¥)に変更されていないといけない、っていうのはありますね。。。。(
ASCIIもUTF-8も0x5C (U+5C)はBACKSLASH (\)なので )あなたがお使いのエディタのバグです。
エディタのメーカーにバグ報告してください。ではダメですかね？
正直コメントを入れるなんて本質とは関係のない対策はしたくないと思ってしまいます。
バイナリ比較までやったのにそれを提示しなかったのは悪手かと思います。
客からすれば「何日も待ったのに何も変わってないものだけを突き返された」と見える訳で、落胆さえされるでしょう。
文字エンコーディングは「どの文字集合でエンコードを行ったか」ではなく「どの文字集合として正しくデコード可能なのか」が重要になります。
この記事の話であれば「ご指摘のファイルはASCII文字集合、いわゆる半角英数字のみが含まれるファイルですのでUTF-8としてもShiftJISとしても正当です。お使いのソフトによっては自動検出でShiftJISと見なす可能性があります。」と返すべきでした。
余談ですが、似た事例として「ファイル毎に文字集合を記憶しているエディタ（SakuraEditor等）を使っているが、一部のファイルで急に文字化けする様になった原因が分からない」というものがあります。
そうでしょうか？私は前者の方が重要であり、そこにアイデンティティがあると考えております。そのため文字化けのなどの問題は『作成時のエンコーディングが悪い』のではなく。『作成されたエンコーディングを理解して、正しくデコードしていないことが悪い』と思っております。
ZIPファイルや実行ファイルしかりそうですが。作成時の文字コードで実行(展開する)ことが、最低限の鉄則です。なので大事なのは、デコードではなくエンコードと考えます。
※ ただし、OSのシステム文字コードに依存する仕組みは国際対応が難しいため、近年 (と言っても随分と経つが) では世界の文字を収録することを目的としたUNICODEがニュートラルな文字集合として扱われてます。
なお手前味噌ではありますが、類似ケースを記事にしたものがございます。
デコードに焦点をあてる危うさの参考になるかと思います。
実際、ZIPコンテナやID3Tagなどでは、エンコード情報を宣言する仕様が追加されております。
@kishibashi3
マルチバイト文字を含まないファイルをどのエンコードと認識するかはエディタにもよりますし設定でデフォルトを変更できるものも多いので、エディタのバグとしてしまうあなたの対応のほうが問題ではないでしょうか。
そもそもクライアントの要求が「ファイルの文字コードをUTF-8にすること」ですし。
そうでしょうか。私はasciiはasciiであってsjisでもutf8でもないと思いますけど。
私なら「このファイルはasciiで、asciiはutf8のサブセットです。asciiをsjisと判断したエディタは誤検知です。お疑いなら御社のエンジニアにご確認下さい。」とでも返しますね。
@kishibashi3 さん
Latain-1、UTF-8などは、そもそもASCIIと互換性を明示的に持った文字コード (エンコード) です。ことASCII領域に於いては排他ではなく、識別は出来ません。それをソフトウェアのバグと言うのは無理があります。
(そもそも宣言子なしにソフトウェアに文字コード (エンコード) を認識させると言う考え方自体が破綻してますが。)
バグという言葉にそんなにこだわるなら、asciiコードの自動検知は環境によって換わってしまうのです。とでも添えるといいのではないでしょうか。
いや、私が言いたいこと、すでに書いてあったようです。失礼しました。
＞本案件はいわゆる更新案件で、今回の納品時に言われていたのは、「文字コードがUTF-8ではないものは変換して納品してくれ」ということ。
自分ならばクライアントに、
「文字コードがShift_JISであると判定された方法をお教えください」
「文字コードがUTF-8であるという定義をお教えください」とヒアリングします。
@heeroo_ymswさんのコメントのように、
もしかすると、クライアントは、BOM付きのUTF-8テキストを欲していたのかもしれません。
みなさん BOM BOM 言ってますけど、BOM (ファイルの先頭)だと bash 等々は受け付けてくれないんですよね。
BOM と同じバイト列になるはずですけど Zero Width No-Break Space である U+FEFF (UTF-8 では 0xEF 0xBB 0xBF)を末尾に付けるのがいいのではないかと思いました。
Unicode の仕様通りに対応しているプログラムなら、これがどこかにあってもほぼ何もないのと同じ扱いにしてくれるはず。
(といいつつも、ファイルを連結したファイルで途中にこれが入っている事が理由で発覚しづらい問題に遭遇した事はありますし、最初に言った通りメジャーな物ですら「実際はそうは扱ってくれない」のですけど)
@a_k_ さん
BOMは宣言子であり、その後の逐次処理に大きく関わる内容なので先頭でなければならないと思うのですが。決して 「テキスト ファイルの文字コードを総合的に判断するための目印」 ではありません。また、
UTF-8のBOM (0xEF 0xBB 0xBF)とZERO WIDTH NO-BREAK SPACE (U+FEFF)はバイト列が同じだけで、全くの別物です。(
data streamと表現されているので、基本的には逐次処理のためのものだと思います。)(
BOMとZWNBSPは別物であり、 データ ストリームの途中のU+FEFFは テキスト コンテンツ である。BOMではなく、ZWNBSPとして解釈されなければならない と明記されております。)そもそも、シェル スクリプトのシェバンなどの仕組みに於いて、ASCIIは共通言語の様なものです。その共通言語を求めるシーンで、UNICODE固有のBOMの解釈を求めるのは、本来の前方互換性が矛盾しています。BOMは、あくまでもUNICODEの仕様であり、UNICODE内のエンコードの目印です。他の文字コードの相互運用のためのものではないため、他の文字コードを意識し始めた段階で UTF-8のASCII互換性への期待 が破綻します。(もっとも、シェバンを使わずインタプリタで直接するのであれば処理系依存の話なので、テキスト エディタなどと同様にソフトウェア単位で会話は出来ますが。XMLもソフトウェアによってBOMの解釈の有無は異なりますし。)
※
ZWSPと記述ミスの指摘を頂きましたので、一応修正しました。@libraplanet さん
お返事ありがとうございます。
ここ私の認識とは少しだけ違いました。BOM は "バイト順序の目印 (byte order mark)" です。
先頭でなければならないのは、最初の数十バイトないし数行でエンコーディングを決めるプログラムが多いからですね。
そして用途は 「テキスト ファイルの文字コードを総合的に判断するための目印」だと思っています。
当時, UTF-16 では little endian と big endian の判別の問題に苦慮していました。
(更に当時まだ現役だった国毎の多様なテキストエンコーディングとの間の判別にも)
そこで「じゃあこの仕様通りにしたら、ほぼいるんだかいないんだかわからない稀有な存在になる文字をバイト順が逆になるパターンは予約して存在させない事にして、それ先頭に置いたらすぐに little endian なのか big endian なのかわかるんじゃね。これヘッダみたいな扱いとかにすれば中の方では本当に気にしなくてよくなるし先頭がいいよね。俺ら天才じゃんワロｗ 」
みたいな経緯だったと想像(妄想)します。
というわけで, バイト単位で処理される UTF-8 にはそもそも BOM は不要であるので付けるべきではないというのが, UTF-8 で BOM を認めない人達の主な主張だったりします。
でもその場合はそれはただの ZWNBSP として、いるんだかいないんだかよくわからない扱いで居てもいいと私は思うんですよねぇ。
あとシェバンの例はわからん事はないのですが、実際には Java のソースコードとかも各種 IDE も純正のコンパイラも BOM は食ってくれなかったような気がします (昔試してダメで以降は素直に BOM なしでやってるので状況は変わってる可能性も)。
それに「そちらを立てるとこちらが立たなくなる」みたいな機能では敢えてどちらも入れないというのもありだと思いますが, ZWNBSP への対応で両立しない機能って特にないと思うんですけどねぇ。
特に読み込むだけのプログラムは。
エディタは「この文字にはカーソル合わせちゃダメなのかー」とか面倒だとは思うんですが、Unicode は割と初期から「この文字とこの文字はくっついて一文字になるから」みたいなのが沢山あったし、そのあたりは実際に問題なく使えるレベルの実装が増えてきてますから、やればできるんでしょう。
(あとですが、ZWNBSP と ZWSP はコードポイントとしても役割としても違うと思います。
もし libraplanet さんが ZWNBSP の事を ZWSP だと思ってたら、すれ違いの度合いが大きくなると思ったので念のため)
大変な状況でしたね、お疲れ様です。
「報告」で記載の内容はメールでのやりとりのみですか？そうならば
自分なら相手側が理解していないと判断したあたりで、電話で以下を話します。
・技術に詳しい人間が周りにいないか確認し、いればサポートに入ってもらう
・ASCII部分はどの文字コードでも共通で、ASCIIしか含んでいないファイルの文字コードは気にする必要ない
等
それで解決に向かわないようなら、マルチバイト文字を含むコメントの追加かなあ、、必要ない修正は加えたくないけど(今回の場合、技術に疎い人のために、ある意味必要な修正)