File: 1696433397814.png ( 96.94 KB , 1888x1562 , yu-hi.sakura.ne_dtp_231005002645_008494.png )
No.649
>>648>試にpreset.cgiをEUCに変換してみますこれだったー！
申しわけないありがとうございます
2通届かなかったのも化けてるせいだった…？
一応連続拍手の中身メールで届いたっぽいです
最初のと何が違ったんだろう…
No.650
>>649ok
>2通届かなかったのも化けてるせいだった…？なんの話です
メール形式が不正だと弾かれる可能性はあります
同じ拍手文言に対しては同じメールが生成されるから、再現出来ないなら原因不明
元はshift-jisをiso-2022-jpにしてバイナリのまま送る実装だったから、異常な入力に対して異常な出力をしてそれによってメールが不正になった可能性はある
>最初のと何が違ったんだろう…preset.cgiの文字コードでは？
No.651
>>650>>650>1743520793078.txtだと連続拍手が届いた（subject文字化け）のに
>1743657139038.txtだと連続拍手1通目しか届かなかった(subject文字化け)
なのです
No.652
>>651moji_modosu関数(変更前)の代わりにdecode_entities関数(変更後)を使ってるところ
"utf-8?b"(変更前)、"UTF-8?B"(変更後)
大きくはこの2点
拍手送ったときに500番台エラーが出てるならスクリプトが原因の可能性あります
どうもdecode_entitiesが失敗することがあるみたい
これがないと特殊文字は使えないのだけど需要なければ1743520793078.txtを使えばよいです
No.654
File: 1743687812598.png ( 97.24 KB , 1095x651 , 受信トレイ (9) - hin_dtp_250403223835_010619.png )
>>653直接gmailに届けたメールは読めるようになった！
sakuraのIMAPの仕様の違い！だろうか
No.655
>>653subjectだけ読めてるのが謎
IMAPインポート今まで試してなかったから
さっきまでのバケバケに戻したらどうなるかは分からない
No.656
>>655動作させてるのはどれでしょう
subjectとbodyはエンコード指定とエンコードが別々だからそういうことも起きます
Content-Transfer-EncodingとContent-TypeのどっちかをiOSが無視してるか理解出来ない組み合わせであるのか
No.657
>>656>動作させてるのはどれ1743657139038.txt
です、折角なので新しい方が良いかなと…
No.658
>>657一応聞いたのだけど本文のエンコードはどれもutf-8だからなぜiOSが解釈出来ないのかよく分からない
最新版のclapならsubjectもutf-8だから本文との差異で文字化けもおきなさそうだし
それにIMAPはエンコードに介入しないはずだから謎です
例えばgmailに届いたものを転送(メールを添付ファイルとして)でiOSに送るとどうなりますか
No.659
>>653半角文字が送れるかどうか試してみてください
No.660
iOSやMacのメールプレビューでだけ文字化けするという中韓露の発言あり
どうも言語設定で添付ファイルや部分部分のエンコーディングを決め打ちしている
ということはISO-2022-JPで送れば読めるか
No.662
>>659思いっきり寝落ちてたすみません
そして半角は遅れている模様
No.663
>>661>>1743691308889.txtこちらでも化け方変わるけれども化けてますね
IMAP
No.664
メール転送の設定をしていて気づいたのですが
leophone02@gmail.com→futami@atariya.dojin.com→hinabita@gmail.com
というgmail→sakura→gmail転送をしていて
leophoneに拍手飛ばしても全く反応がなく
今まで通りfutamiに飛ばすと
futamiとhinabita両方に届くようです…
gmailがsendmail直送信非対応なのかな？
そういえばなんかgmail受信メールのセキュリティが変わったとか聞いた記憶が…
No.665
>>664>gmailがsendmail直送信非対応なのかな？>そういえばなんかgmail受信メールのセキュリティが変わったとか聞いた記憶が…たぶんそれです
ドメインを持ってるなら必要な認証すれば送れるようになるとは思う(ちゃんと確認してない情報)
どこかに送信失敗通知が来てます(linuxなら /var/mail/ とかなのだけどsakuraは知らない)
別に張り付いていなくてもよいのです
BBSは非同期通信だから
>>662>>663どちらもbase64デコードまでは上手くいってるけどchaset解釈がされてない
特に
>>663 は表示する前に処理しておくべきiso-2022のエスケープシーケンスがそのまま載っちゃってる
うーｎ
文字列に関する変換を1段階しかやってないのか・・・？
となるとやっぱりbase64をなくしてしまうしかないかも
No.668
諦めようか
>>653>iosのgmailでatariya鯖のimapインポートすると化け化けだ…>>654>sakuraのIMAPの仕様の違い！だろうかこれもうちょっと詳しく説明してもらえますか
atariyaがIMAPサーバーで、それをiOS(iPhoneかiPad)のデフォルトメーラーで閲覧しているということでしょうか
gmailはどこに挟まって来ますか
No.669
>>668ios版gmailにはIMAPインポート機能があって
web版と違ってsakuraのatariya.dojin.comの
IMAP受信が可能なのですが、そこから見ると
web拍手のメールが化けてて読めないのですね…
iphoneからメール受信するのにgmailアプリのみで
全部可能になるので利用していました
No.670
>>669？！
leophone@atariya.dojin.comを新設
leophone02@gmail.comへ転送
にしたら英文メールとして勝手に和訳二重に挟まって日本語おかしくなるけど
ちゃんと和訳消すともとの日本語メールで読めるメールがfutami@atariyaに届くようになった！
…どういう事なんだ？
直接sendmailでatariyaに飛ばすと読めないが
atariyaからgmailへ転送した物はgmailで読めて
更にそれをatariyaへ再転送掛けると読める
という事っぽい？
leophone@atariya（転送専用アドレス）→leophone02@gmail→futami@atariya→hinabita@gmail
の転送状態にしたらfutami@atariyaがIMAPで読めた
No.672
テストしようと思ったけど古いiPhoneやiPadしか手元にないのであった
>>669>>670その文字化け状態のメールは、メールを開いても文字化けてますか
化けていてなおかつ、保存するかソースを表示が出来るなら、その内容をここに貼ってください
出来なさそうなら転送用メールアドレスをそっちに送ります
No.674
投稿に信頼性がなさそうだからメールアドレスはmodder用のnoticeboardの方に書き込みました
No.675
>>674sendmail直送と
sakuraのメール転送両方で送ってみました
No.676
>>675期待に反して文字化けしていない・・・
iOSのgmailアプリもメールの個別画面だと文字化けなしですか？
No.677
>>676？！
sendmail直送の方は化けてないですか？
atariya転送と2種類送りました
sendmail直送という奴は個別で開いても
化けたままですね…
あれ…？
No.678
>>6773通届いてます
>直接sendmailテスト１>atariya転送設定テスト１>atariya転送設定テスト２どれも化けていない
>sendmail直送という奴は個別で開いても>化けたままですね…うーｎどうして・・・
No.680
>>678sakuraのIMAP鯖が何かおかしい…？のか…？
tskさんが受けてるメール鯖はsakuraではないのでしょうか？
No.681
>>680転送ならeml形式でメールソースコードが送られるかと思ってたのだけどそうではなかったみたい
場所場所で再解釈が入ってる可能性を否定出来ない
提示したメールアドレスはfirefox relayっていう実メールアドレスをマスクするやつです
実際の宛先はgmailで、そこで文字化けメールのメールソースコードを読むつもりだった
けどそもそも文字化けしていないこちらでは正しく解釈出来るメールが来てる
IMAPはメールヘッダの変更は行わないけど、ヘッダを解釈してパースした結果をメールクライアント(MUA)に伝えるからそこが何かおかしい可能性はあります
前提の質問なんですがこの以前のpatipatiでは文字化けしていましたか
それとpatipati以外から送られた日本語メールは文字化けしますか
No.682
>>680因みに確認しておくと
iosのgmailのIMAPで化けているだけで
直に届いたfutami@atariyaでも
atariya鯖に受信しに行ってみると読めます！
化けてるのはiosのgmailのIMAPだけです
iosの標準メールは迷惑メールが面倒なので使ってません
そしてfutami@atariyaは結構普段からIMAPでメール読んでて
多くの受信されてるメールは普通にされている…と思います
（仮に同様に化けて受信してると気づかないから何とも言えない）
No.683
>>682>>iosの標準メールは迷惑メールが面倒なので使ってません今回だけでも取り敢えずと試しにインストールした所、読めました
iosのgmailのIMAPでだけ読めないっぽいです
No.684
>>682>iosのgmailのIMAPで化けているだけで把握してます
>そしてfutami@atariyaは結構普段からIMAPでメール読んでて>多くの受信されてるメールは普通にされている…と思いますじゃあ何かが足りてない可能性がある
ということでMIME-Versionヘッダ追加
>>683余計に分からない
iOS版gmailアプリが何か妙な規則で動いているんじゃ・・・
No.685
>>684読めるようになった！！
ありがとうございます！！！！
No.686
>>685まあなんと
確かにContent-TypeとContent-Transfer-EncodingはMime-Version: 1.0からの規格だし、Mime-Version行が含まれない場合は旧メール仕様(asciiのみ)とするのが正しいか(でもそれならsubjectも化けてるべき)
しかしIMAPサーバーが原因かiOS版gmailアプリが原因かは分からないのでありました
No.687
続けて申し訳ない
赤の他人が書き込む時が来たらミスらないように
Verification失敗するのを何とかしたいのでした
クイックレスポンスだけじゃなく
一度書き込んだあと続けて書き込もうとして
時間内に再利用するのも失敗する気がする…
No.688
>>687覚えとります
quick replyがフォームのhtml elementを複製するのが原因っぽいのだけどよく分からない
なんなら2つとも両方が動くときもあるのがさらによくわからない
まあまずは複製じゃなくて移動するようにしてみます
No.689
>>688もうしわけない
>2つとも両方が動くときもある2つではないけれどもそのページをリロードして
トップのテキストボックス部分を一度も表示しない状態で
Quick Replyだけ先に表示するとそっちが優先されて
逆にトップのボックスの方が使えなくなりますね
No.690
reCAPTCHAを移動する方法が(でっち上げ内では)ベストだと思ってたけどダメだ
動作はするけどcaptchaがやりなおしになる
これなら両方が動くようにしたほうが(でっち上げ内では)良いや
真っ当はreCAPTCHAをフォーム外に置いて浮かせた方がいいが
この真っ当な方法が一番労力少ない気がしてきた
ところでしばらく時間取れないです
No.691
>>690色々お手間をお掛けします
ろっしー辺りに伝えてくれたら
discord経由で気づくと思いますので
またその内都合が良い時にお願いします
ありがたい…
No.693
>>692ありがとうございます！
置いてみた！けれど何が変わったのか…？
No.694
>>693ちゃんと動いてます
キャプチャ認証が動かなくなる(無限待機になる)のはメインフォームのキャプチャを解決した状態でquick replyにキャプチャ要素を複製したあとにquick reply側のキャプチャにトライするとそうなる
だからキャプチャを複製するのではなくquick replyを表示・非表示するたびにキャプチャを移動させればまずは解決する
というコードです
キャプチャにトライしていない状態でquick replyを作成すれば両方のキャプチャが動作するようになるけど、そういうのはまだ組んでないです
No.695
>>694ありがたい…☑を入れる前なら両方のどちらかは使えるようになった感じですか？
とおもったらだめだった…でも何か変わってるらしい！
No.696
>>695元の状態:
上の方のフォームでチェックを入れてからquick replyを表示するとquick reply側が無限待機になる
>>692 のスクリプトを導入した状態:
両方のフォームでreCAPTCHAが使えるが、quick replyが表示・非表示されるたびにキャプチャ認証がやり直しになる
です。
でもまだ他の理由で無限待機が起きるっぽい
Shift-F5でページ更新をしてみてください
ページキャッシュでスクリプトが読み込まれていないかも知れないから
No.697
>>696だめですねー変わらないですねー
firefoxだからだろうか…
No.698
>>696>上の方のフォームでチェックを入れてから自分の環境だとチェックを入れる前でも
上フォームのreCAPTCHA部分一度表示されてしまうと
quick replyのreCAPTCHAはグルグルになるようになってしまいますね
No.699
>>697>>698こちらもメインはfirefoxなんだけれどもgoogle chromeで確認したら読み込み順によって動作しない場合があったから直しました
そもそもユーザーにチェックボックスを入れさせるんじゃなくて「返信する」ボタンをきっかけでキャプチャ認証を動作させればいいかもしれない
