回答編集履歴
2
誤記訂正
answer
CHANGED
@@ -61,4 +61,4 @@
|
|
61
61
|
- serverからtest.csvを受信した際のcharset
|
62
62
|
上述の実験コードのようにリクエストオブジェクトに対して`getResponseHeader("content-type")`メソッドの呼び出しで文字セットが確認できます。
|
63
63
|
|
64
|
-
|
64
|
+
補足しますと、自分はwebアプリケーションの知識に乏しいため、「どういう確認ができるか」を考え上記のような実験をしてみた次第です。まず上記を確認して「推測した通りの不整合がみつかったなら」その先を調査するようにしたほうがよいでしょう。サーバーからの応答の**charsetがutf-8になっていないかも知れない**という推測のままで前へ進むのは時間を無駄にする可能性があると思います。
|
1
追記
answer
CHANGED
@@ -43,4 +43,22 @@
|
|
43
43
|
|
44
44
|
また、サーバーはちょっといい加減なものを使っており応答の際にcharsetを無条件にutf-8にしているのですが、firefoxのテキストエンコーディングを「unicode」「自動判別:解除」にするとHTMLドキュメント上の文字列やalertの「データ1」などは文字化けしますが、受信したcsvデータ自体は文字化けしません。
|
45
45
|
|
46
|
-
つまり「サーバーから応答されたtest.csvのレスポンスがcharset=utf-8になっていないかまたはサーバー上にあるtest.csv自体がutf-8でないかのいずれかではないかと思いました。
|
46
|
+
つまり「サーバーから応答されたtest.csvのレスポンスがcharset=utf-8になっていないかまたはサーバー上にあるtest.csv自体がutf-8でないかのいずれかではないかと思いました。
|
47
|
+
|
48
|
+
---
|
49
|
+
|
50
|
+
追記:まず事実を確認してみるとよいと思います。
|
51
|
+
|
52
|
+
- server上のtest.csvはutf-8になっているか
|
53
|
+
|
54
|
+
小さなテストデータなので確認は容易だと思います。例えばlinux/unix上であれば下記と同じ結果になればutf-8であることは確実です。(通常はLANG=ja_JP.UTF-8となっている端末上でcat test.csvとして文字化けしてなければutf-8であるといった確認をするでしょうけども)
|
55
|
+
```
|
56
|
+
$ od -c test.csv
|
57
|
+
0000000 2 0 1 7 0 4 0 4 , 343 202 244 343 203 201 343
|
58
|
+
0000020 203 255 343 203 274 , 343 201 204 343 201 241 343 201 224 \n
|
59
|
+
0000040
|
60
|
+
```
|
61
|
+
- serverからtest.csvを受信した際のcharset
|
62
|
+
上述の実験コードのようにリクエストオブジェクトに対して`getResponseHeader("content-type")`メソッドの呼び出しで文字セットが確認できます。
|
63
|
+
|
64
|
+
捕捉しますと、自分はwebアプリケーションの知識に乏しいため、「どういう確認ができるか」を考え上記のような実験をしてみた次第です。まず上記を確認して「推測した通りの不整合がみつかったなら」その先を調査するようにしたほうがよいでしょう。サーバーからの応答の**charsetがutf-8になっていないかも知れない**という推測のままで前へ進むのは時間を無駄にする可能性があると思います。
|