APIのレスポンスに日本語を含むと、良くわからない文字列になってしまう

Question

概要

POSTで指定したディレクトリ内のファイル一覧を返すAPIをDjangoで構築しています。
どうも、日本語を含むとファイル名が全て文字化けしてしまうようです。

実現したいこと

1. ユーザが/api/get_listへPOSTする
2. djangoは送信された文字列と合致するディレクトリ内のファイル一覧をdjango.http.JsonResponseで返す。

get_list関数(views.py)

from django.http import HttpResponse
from django.http import JsonResponse
import os


def get_list(request):
    if request.method == 'POST':
       try:
          if request.POST['type'] == 'images':
             media_type = 'images'
          elif request.POST['type'] == 'movies':
             media_type = 'movies'
       except KeyError:
          HttpResponse.status = 403
          return HttpResponse('You are Hentai.')
       else:
          path = os.path.join('/PATH/TO/DIR/media', media_type)
          result = os.listdir(path)
          return JsonResponse(result, safe=False)
    else:
       HttpResponse.status = 403
       return HttpResponse('You are Hentai.')

api/get_listのレスポンス結果

["\udce3\udc83\udc86\udce3\udc82\udcb9\udce3\udc83\udc881",
 "test1.mp4",
 "test2.mp4", 
 "\udce3\udc83\udc86\udce3\udc82\udcb9\udce3\udc83\udc882",
 "\udce3\udc83\udc86\udce3\udc82\udcb9\udce3\udc83\udc884",
 "\udce3\udc83\udc86\udce3\udc82\udcb9\udce3\udc83\udc883"]

0: "���������1"
1: "test1.mp4"
2: "test2.mp4"
3: "���������2"
4: "���������4"
5: "���������3"

このように、聞いたことのない文字コード("\udce3\udc83...")になってしまいます。
pythonの文字コードが間違っているのかと思い、シェルでの確認とついでにos.listdir()を実行して見ましたが、普通に取得出来ています。

shellでの確認

[kiwi ~]$ py manage.py shell

Python 3.6.5 (default, Apr 10 2018, 17:08:37)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import sys
>>> sys.getfilesystemencoding()
'utf-8'
>>> import os
>>> os.listdir('media/movies')
['テスト1', 'test1.mp4', 'test2.mp4', 'テスト2', 'テスト4', 'テスト3']

不可解なのが、os.listdir()の結果ではなく、以下のようにするとちゃんと日本語で取得出来ます...

return JsonResponse(['あ', 'い', 'う', 'え', 'お'], safe=False)

os.listdir()が原因で文字化けするというのはあり得るのでしょうか？os.scandir()も試してみましたが、同じ結果でした...。
どなたか、ご教授下さい...もう3日ほど悩んでおります。

開発環境

• CentOS7
• apache2.4.35
• django2.1.3

Comments

[can110]

django環境で「ls -l」などした場合も文字化けしますか？
あ、失礼、シェル上では文字化けしてないですね。

Answer 1

興味を持ち私も（環境は kiwibird さんと異なり macOS ですが）ファイル名が日本語のファイルで試してみました。結果、 kiwibird さんと同様の現象を確認することができました。

結論としては、 can110 さんらがおっしゃられているとおり UTF-8 で表現されているの（＝適切なエスケープ）ではないかと思います。

念のため、なぜこの挙動になるかを確認するために JsonResponse のコードを見てみました。 JsonResponse の __init__() の中で、第 1 引数（ kiwibird さんのコードだと result ）が標準ライブラリの json.dumps() を使って JSON シリアライズされています。

• https://github.com/django/django/blob/2.1.3/django/http/response.py#L558

ここではエンコーダとして django.core.serializers.json.DjangoJSONEncoder という Django 独自のエンコーダが使われますが、これは今回の問題とは関係が無いので掘り下げずにおいておきます。

json.dumps() のドキュメントを見ると、 json.dumps() はデフォルトで non-ascii 文字を ascii 文字にエスケープする挙動になっているとのことですので、これがおおもとの原因ではないかと思います。

• https://docs.python.org/3/library/json.html#character-encodings

以下、該当する箇所 2 箇所の抜粋です:

抜粋1:

If ensure_ascii is true (the default), the output is guaranteed to have all incoming non-ASCII characters escaped. If ensure_ascii is false, these characters will be output as-is.

抜粋2:

The RFC requires that JSON be represented using either UTF-8, UTF-16, or UTF-32, with UTF-8 being the recommended default for maximum interoperability.

As permitted, though not required, by the RFC, this module’s serializer sets ensure_ascii=True by default, thus escaping the output so that the resulting strings only contain ASCII characters.

試しに次のようにすると、 json.dumps() だけでエスケープされることが確認できましたので、ほぼこれが原因と見て間違いないのではないかと思います。

+         import json
+         return HttpResponse(json.dumps(['あ', 'い', 'う', 'え', 'お']))
        return JsonResponse(result, safe=False)

このレスポンスを JS 等で利用される分には特に問題は無いのではないかと思いますがいかがでしょうか。ご確認されてみてください。

ちなみに私の環境で次の式を試したときのレスポンスは kiwibird さんのものとは違っていて

return JsonResponse(['あ', 'い', 'う', 'え', 'お'], safe=False)

次のようにエスケープされていました。

["\u3042", "\u3044", "\u3046", "\u3048", "\u304a"]

ご参考になれば幸いです :)

Comments

[ikadzuchi]

> can110 さんらがおっしゃられているとおり UTF-8 で表現されているの（＝適切なエスケープ）ではないかと思います。
いいえ、少なくとも私は適切なエスケープだとは言っていません。
「\u3042」などは正しく特定の文字を表すUnicodeコードポイントですが、
「\udce3」などはサロゲートペアの片割れであり、文字を表さないUnicodeコードポイントです。

[gh640]

なるほど、失礼しました。ご丁寧にありがとうございます。その部分の問題が大きい可能性もあるのですね。

[gh640]

kiwibird さん: 私のコメントのポイントだけでは問題が解消しないかと思いますので、 can110 さんのご回答をご参考にしてください。 can110 さんが過去にご回答された https://teratail.com/questions/106297 もヒントになるものと思います。

[can110]

私の回答に追記しましたが、ikadzuchiさんの指摘どおりかと思います。
そのように変換されるよう仕様(PEP383)で定められています。
しかし分かりにくいエラー（動き）ですね。

[gh640]

can110 さん、ありがとうございます。 PEP383 でそういう仕様になっているのですね。勉強になります。これはわかりにくいですね。。

[gh640]

kiwibird さん、追記ありがとうございます。

これは困りますね。なぜこうなるかの仕組みはわかったような気がしますが、どう解決すればよいかわかりませんね。

よろしければ、通常の Python のインタラクティブコンソールと `manage.py shell` で別々に確認してみていただきたいのですが、次の a) b) を実行するとそれぞれどのようになるでしょうか。

```
import os
import sys

# a)
result = os.listdir('media/movies')
print(result)
print(json.dumps(result, ensure_ascii=False))

# b)
result = os.listdir(b'media/movies')
entries = [e.decode(sys.getfilesystemencoding()) for e in result]
print(entries)
print(json.dumps(result, ensure_ascii=False))
```

[gh640]

kiwibird さん、追記 2 の件お試しいただきありがとうございます。

CASE B の `print(json.dumps(result, ensure_ascii=False))` は失敗して当然でしたね。。すみません。。

状況を理解しきれていませんが、「追記」「追記 2 」の結果をあわせると「 Python のシェルも Django の `manage.py shell` でも問題は無いけれど、 Django のリクエスト・レスポンス処理の流れの中で `json.dumps(os.listdir(path))` を実行したときにだけ `UnicodeEncodeError` が出る」という状況だと解釈できるかなと思いました。この理解で正しいでしょうか？

例えば、次のコードが `manage.py shell` では問題なく動くのに view の中で実行するとエラーが出るのであれば、そのことの確認になると思います。

c):

```
import os, sys, json
result = os.listdir(b'media/movies')
entries = [e.decode(sys.getfilesystemencoding()) for e in result]
print(json.dumps(entries, ensure_ascii=False))
```

Answer 2

"\udce3\udc83\udc86\udce3\udc82\udcb9\udce3\udc83\udc881"

珍しい文字化けですね。
最後の「1」は文字化けしていないので除くと、
「テスト」をUTF-8で表したバイト列
「e3 83 86 e3 82 b9 e3 83 88」
を1バイトづつU+DCxxに対応させて文字コード表記したものに見えます。
U+DCxxはUnicodeにおいて下位サロゲートと呼ばれる領域で、UTF-16では上位サロゲートとペアになってサロゲートペアという1文字を表すのに使われます。
UTF-8では使われません。

風のうわさで不正なバイト列を表すのに片割れのサロゲートのコードポイントを使う環境があると聞いたことがあったような気がします。
これだとすると、変換前が正しいUTF-8のバイト列なので不正扱いされるのがなぜかということになりますが、
バイト列がまとめてでなく、1バイトづつ個別に渡されているとするとこのような出力になりそうです。

can110さんの言うロケールの問題なのでしょうかね。

Comments

[can110]

下位サロゲートに変換されるのはPythonの仕様(PEP383)のようです。
ちょっとお行儀悪い仕様かと思いますが…

Answer 3

文字化け結果から、日本語パスはUTF-8で表現されています。
Django動作環境のロケールがCなど日本語に対応していないと現象が発生するようです。
未検証ですがexport LANG=ja_JP.UTF-8またはC.UTF-8とロケール設定してあげると正常に動作する可能性あります。

参考：
Python3.1の Unicode ファイル名
LANGやPYTHONIOENCODINGを設定してもUnicodeDecodeErrorが出る時の更なる確認ポイント

以下は細かいことなので読み飛ばしてかまいません。

ちなみに、動作環境のロケールで表現できない（日本語などの）バイト列は\udc??のようなサロゲートペアの下位ワード表現するとPEP 383 -- Non-decodable Bytes in System Character Interfacesで定められています。
通常、下位ワードのみで構成される文字列はない（はず）なのでこの動作はお行儀悪いですが、UNICODEから元のエンコーディングに逆変換できるように、あえてこのような仕様になっているものと思われます。

Answer 4

皆様、数々のご助言、ご教授ありがとうございました...。
ようやく、原因？というか元凶が分かりました...ｗ

私はIUSリポジトリからpython3.6.5とmod_wsgiをyumでンストールして使っていましたが、どうやらこの子達が悪さをしていたようです...

先日pyenvを知った私は、python3.7.1を利用して遊んでいました。その過程でpipが使えることがわかったので、pyenvのpython3.7.1とmod_wsgiをインストールしてdjangoを動かせるようにしました。

するとなんの問題もなく、日本語が返ってきました...。
今まで特に日本語の利用に問題がなかったのでなかなか気づきませんでした。ご相談に乗ってくださりありがとうございました！

結論

djangoを使いたいなら、システムのpythonではなく、pyenvを使って構築したほうが良いのかもしれません...

P.S.

pyenvでpip install したmod_wsgiを利用する場合、以下のオプションを使ってpythonをインストールしないと動きません！

CONFIGURE_OPTS="--enable-shared" pyenv install 3.7.1

Comments

[gh640]

お疲れさまでした。ご解決されたとのことでよかったです :)

[kiwibird]

gh640さん、ご親切にありがとうございました！
ikadzuchiさん、can110さんも素晴らしいアドバイスありがとうございます！

文字コードは奥(闇)が深い世界ですね...