AYU さん:
会議中につらつら書いていたら，長文になってしまいました．ご容赦下さい．
AYU wrote:
> まず、「クッキー」についてですが、クッキーが使用できない携帯電話などのブラウザからはアクセスできないのでしょうか？
>
> セッションのドキュメント読む限りでは、クッキーは必須のようではありますが、しかし、セッションをオフにする方法も載っていましたので、例えば「URL
> の設定」でステート状態を代替させるような方法はあるのでしょうか？
Django のセッション (を自動的に管理するセッションミドルウェア) は，HTTP Cookie
によってセッションを識別します．また，Django の認証機構を担当する auth や，管理
画面で使われる admin といったアプリケーションは，リクエストオブジェクト (ビュー
の最初の引数として渡されるオブジェクトです) に session というオブジェクトが
存在しなければ動作しません．従って， Cookie の使えない環境では，
0. Cookie を使えない
1. Cookie がないので SessionMiddleware を使えない．
2. SessionMiddleware がないので request.session が設定されない．
3. request.session がないので django.contrib.auth を使えない
4. django.contrib.auth を使えないのでログインできない
5. ログインできないので管理画面を使えない
というように不便さが波及してゆきます．Django の開発者たちは，URLにセッションID
を埋め込むのは安全でないと考えており，クッキーのある世界で生きているので，
SessionMiddlewareがステートレスクライアントをサポートする方向には進まなそうです．
とはいえ，全くお手上げかというとそうではありません．ソースコードを読む限り，セッ
ションデータを管理している Session モデル自体は，セッション ID にあたるキーとセッ
ションデータの２つのカラムからなる単純なストレージで，クッキー処理はもちろん，
リクエスト／レスポンス処理には一切カップリングしていません．
セッションデータとリクエスト処理を繋いでいるのは 2. の SessionMiddleware
(django/contrib/session/middleware.py) です．SessionMiddleware はリクエストのクッ
キー情報をもとに SessionWrapper というオブジェクトを作成して，このラッパを介して
クッキーベースのセッション管理を行っています．例えば，このミドルウェアをリクエスト
URL からセッション ID を取得するようなミドルウェアに差し替えてやれば，URL の一部に
埋め込まれたセッションキーを使えます．おそらく，hiddenフィールドを使ったGET/POST
データ経由でもセッションIDをやり取りできるでしょう．
ちょっとミドルウェアを書く所まで手が回っていないのですが，そんなに難しい問題では
ないと思います．もうあるかもしれません．あるいは，（潜在的な需要もありそうだし）
だれかやってみませんか？ :)
# セッションデータは辞書オブジェクトに入ったセッションデータをpickle化し，base64で
# ascii文字列にエンコードして保存しているだけのようです．
>
> あと、「文字コード」についてですが、Shift_JIS や
> ECU-JP は使用できないのでしょうか？
> 試しに setting.py の DEFAULT_CHARSET
> を変更してみたのですが、runserver
> 実行後に、エラーが表示されてしまいました。
インストールして，DEFAULT_CHARSETを設定して，runserverを動かしただけで文字コード
関連のエラーが出ているのなら，
1. Djangoを動かしているPythonのバージョンが
- 2.3.Xで，JapaneseCodecsやCJKCodecsが入っている
- 2.4以降である
かどうか確認してみて下さい．
2. また，バックエンドDBの文字コードとDEFAULT_CHARSET が一致しているかどうかも
確認してみてください．(ただし，MySQLやSQLiteの場合，バックエンドが行データ
の出力を全て utf-8 エンコードしてしまうので，残念ながらいじりようがありません．)
テンプレートやビューを作成してレンダリングした時にエンコード周りのエラーが
生じるのなら，
1. テンプレートの文字コードが DEFAULT_CHARSET と一致しているか
2. CharFieldやTextFieldから取り出した文字列を utf-8 でデコードした後，
DEFAULT_CHARSETでエンコードして渡しているか
3. views.py の中に文字列リテラルを埋めているのなら， views.py の文字コードは
DEFAULT_CHARSETと一致しているか．また，コンテキストに文字列を渡すときに，
DEFAULT_CHARSET にエンコードしているか
を確認してください．こんなことを言うとびっくりされそうですが，
*DjangoはまだUnicode化されておらず，utf-8 前提で書かれている部分がある* ので，
もっとも最良の選択は「全てを utf-8 で扱う」です．
どうしてもビューに shift_jis や euc-jp を使いたい場合，二つの選択肢があります．
1. DEFAULT_CHARSET を設定する代わりに，adminサイトとSQLite/MySQLサポートを捨てる．
2. DEFAULT_CHARSET は触らず，デフォルトの utf-8 にしておく．この場合，
a. ビューをレンダリングするときに，明示的にエンコードする．例えば，shift_jisの
ページを表示したいなら，
return HttpResponse(unicode(template.render(context),
'utf-8').encode('shift_jis'),
mimetype='text/html; charset=shift_jis')
b. POSTデータから文字列を取り出したら，明示的にデコードする．
post_data = request.POST.copy()
title = unicode(post_data.get('title', ''), 'shift_jis')
私は 2. を勧めます．
そこで、HTML
> を送り出す前に、Python 自体か、あるいは NKF
> などのコマンドを間に挟んで変換した後、レスポンスオブジェクトに渡す方法を思いついたのですが、このようなやり方は可能なのでしょうか？
>
> なにやら、まだまだ Django
> 初心者ですので、的外れな質問をさせていただいているかも知れませんが、大変美しいフレームワークですので、ぜひ本格的に使ってみたいと思っております。
>
> どなたかご存知の方がいらっしゃれれば、大変お手数ではございますが、ご教授のほどを賜われれば、幸いでございます。
>
--
Yasushi Masuda
http://ymasuda.jp/
--~--~---------~--~----~------------~-------~--~----~
----------------- http://www.djangoproject.jp/
-----------------
You received this message because you are subscribed to the Google Groups
"django-ja" group.
To post to this group, send email to django-ja@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-ja
-~----------~----~----~----~------~----~------~--~---
