- Re:URLのページNoの後ろに付いた%27のアクセス 2024-10-26 20:22:23 flipflop 返信 編集
早速のご回答 ありがとうございます。
どちらも警告エラーが出ないことを両方で確認しました。
先に示されたほうでは、余計なものを除外ということで、ページ(記事)は表示されます。
後者のほうは、余計なものが付くと記事が表示されないという結果でした。
私としては、正規のURLでなければ表示する必要はないと思いまして、後者(1行の修正)のほうを使うことにしました。
>これも本来なら対応不要だと思います・・
ご見解ごもっともだと思います。
そんな問い合わせにお付き合いいただき感謝に堪えません。
今後ともよろしくお願いいたします。
- Re:URLのページNoの後ろに付いた%27のアクセス 2024-10-26 14:36:44 管理人 返信 編集
if (!is_numeric($page) || $line_nmb < $page * $option['page_line'] || $line_nmb >= ($page + 1) * $option['page_line']) {
のほうが簡単ですね。
$line_nmb++;
continue;
}
- Re:URLのページNoの後ろに付いた%27のアクセス 2024-10-26 11:09:26 管理人 返信 編集
pageのクエリパラメーターからは数値しか送られてこないことになっているので
エラーが発生しているということでしょうね。
これも本来なら対応不要だと思いますが、エラーログが気になるなら$page = preg_replace('/[^0-9]/','',$page);
のように修正して$pageに含まれる数値以外を削除してしまうという方法が考えられます。
if ($line_nmb < $page * $option['page_line'] || $line_nmb >= ($page + 1) * $option['page_line']) {
$line_nmb++;
continue;
}
- URLのページNoの後ろに付いた%27のアクセス 2024-10-25 15:23:08 flipflop 返信 編集
いつもお世話になっています。
今回も意図的に発生させる警告エラーの件で申し訳ありません。
手作業なのか、何のためにやるのか 皆目見当もつかないのですが、
最近URLのページ数の後ろに「'」を付け足してアクセスしてくるログをかなり見かけるようになりました。
当たり前の閲覧であれば
id=[こちらのID]&page=15&noform=[こちらのID]
のようになるわけですが、下のようにページ数の後ろに「%27」を付けてアクセスしてきます。
id=[こちらのID]&page=15%27&noform=[こちらのID]
そうすると1回のアクセスで警告エラーログが数百件も生成されてしまうので 鬱陶しいというのが本音です。
以前ご相談した id2 でのスラッシュのようなものですが、方法があれば(そう難しくないのであれば)お教えいただければありがたいです。
お手すきのときで結構ですので、よろしくご指導ください。
【アクセスログ】※こちらで意図的に「'」を付け足してアクセスしたときのログです。
[こちらのIPアドレス] - - [25/Oct/2024:13:29:42 +0900] "GET /*****_php/bbs.php?id=[こちらのID]&page=15%27&noform=[こちらのID] HTTP/2.0" 200 16528 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0"
【エラーログ】※この内容と同じログが数百行 イッキに生成されます。
[Fri Oct 25 13:29:42.253170 2024] [fcgid:warn] [pid 3159058:tid 140171513931520] [client [こちらのIPアドレス]:21611] mod_fcgid: stderr: PHP Warning: A non-numeric value encountered in /var/www/clients/client492/web914/web/*****_php/bbs.php on line 1435
■line 1435 付近の記述
if ($line_nmb < $page * $option['page_line'] || $line_nmb >= ($page + 1) * $option['page_line']) {
$line_nmb++;
continue;
- Re:投稿フォームを隠した状態での表示 2024-09-16 21:46:29 flipflop 返信 編集
早速のレス ありがとうございます。
>init.phpに
>$hide_form=1;
>を追記するとデフォルトが非表示にできるようです。
早速追記しました。
>ただしフォームの表示/非表示はクッキーに保存されているので、前回フォームを表示していたら、次に開いた時も表示されることになります。
了解しました。
閲覧者が投稿フォームを開いた状態でブラウザを閉じるってことも ほとんどないでしょうから、この状態で使用します。
リンクは URLの後ろに ?hide_form=1 を追加したものを使うことにします。
今後ともよろしくお願いします。
- Re:max_log のお礼と投稿フォームを隠した状態での表示 2024-09-16 16:55:49 管理人 返信 編集
フォームを非表示にするならやはりリンクを
>URLを
>https://****/〇〇/bbs.php?hide_form=1
にするのが簡単だと思いますが、試しにinit.phpに$hide_form=1;
を追記するとデフォルトが非表示にできるようです。
ただしフォームの表示/非表示はクッキーに保存されているので、前回フォームを表示していたら、次に開いた時も表示されることになります。これは逆も同じです。
- Re:max_log のお礼と投稿フォームを隠した状態での表示 2024-09-16 08:09:44 flipflop 返信 編集
アドバイス ありがとうございます。
>dataディレクトリの共有ですか。想定していませんした。
暇に飽かせて、知識もないのに試してみるのが好きな性分です。
おかげさまで一つのデータを複数の掲示板で利用できました。
このスレッドで申し訳ないのですが、もう1点 お教えください。
https://****/〇〇/bbs.php
で掲示板にアクセスした際、常に投稿フォームが隠れて表示されるようにしたいのです。
URLを
https://****/〇〇/bbs.php?hide_form=1
とすればいいだけなのですが、簡単な修正で可能であればと思い お聞きしました。
もし 面倒な修正であれば諦めます。
よろしくお願いします。
- Re:php掲示板でmax_log が効かない 2024-09-14 22:41:24 管理人 返信 編集
dataディレクトリの共有ですか。
想定していませんしたが、init.phpの$datadirを設置場所に応じて変更し
$idを共通のものに指定すれば共有できそうですね。
その際に合わせておいた方がいいのは$max_logと$max_past ぐらいでしょうか
- php掲示板でmax_log が効かない 2024-09-13 14:31:18 flipflop 返信 編集
いつもお世話になっています。
php掲示板の ver.1.071 を2つ使っています。
両方の掲示板とも max_log=500 に設定していますが、現行スレッドが ぴったり100を超えると過去ログが生成されてしまいます。
元々のレシポンシブな掲示板を勝手にパソコン画面用にアレンジしているものですから、data ディレクトリを別の掲示板ver.1.071(レシポンシブとして)に参照させているのですが、それと関係しているということはないでしょうか。
気が付いた時期と重なるので、それが原因ではないかと心配です。
当方の使い方に原因があるのかもしれませんが、対処方法がありましたらお教えいただければありがたいです。
よろしくお願いします。
【2024.09.13追記】
いろいろやってみたところ、原因がわかりました。
やはり同じ data ディレクトリを2つの掲示板で共用したときのミステイクでした。
data ディレクトリを別のレシポンシブ掲示板に参照というか取り込む設定をしたときに、レシポンシブ掲示板のほうの設定が デフォルトの max_log=100 のまま参照させていました。
たぶんそのせいで max_log=100 が反映されて過去ログのファイルが生成され、それが元の掲示板にも反映されたようです。
両方の掲示板の設定を max_log=500 にして、過去ログの bbs_1.cgi のログを bbs.cgi に取り込んで統合したところ、これまでのように過去ログなしに修正できました。
お手数おかけしました。今後ともよろしくお願いいたします。
- Re:PHP掲示板の記事順 2024-07-24 22:29:25 管理人 返信 編集
ver1.061以降
過去ログがある状態で、投稿記事に指定した編集パスワードを使って再編集すると現行ログの内容が消えてしまうというバグがあったようです。
ver1.061、ver1.062を使っている方は必ず修正版のver1.07に更新していただくようお願いします。bbs_ver1.07.zip 18dl
>こうなっていると思っていたら、なっていなかったので修正したver1.061をアップしました
>ついでにタイトルに固定リンクを表示するオプションも追加しました。
PHP/掲示板PHP
- Re:PHP掲示板の記事順 2024-06-13 13:45:47 管理人 返信 編集
>bbs.php?id2=記事ID#bbs_記事ID
>というようなURLを使えば過去ログに移行した記事も引用可能で、
こうなっていると思っていたら、なっていなかったので修正したver1.061をアップしました
ついでにタイトルに固定リンクを表示するオプションも追加しました。
PHP/掲示板PHP
- Re:PHP掲示板の記事順 2024-06-07 16:35:16 flipflop 返信 編集
ご回答 ありがとうございます。
>ただ投稿数が$max_logに指定した数を超えると古い記事から過去ログに移行するので、同じURLで記事を引用できるということにはならないと思います
現行ログを多めに設定しているので、そのあたりは大丈夫かと思います。
今後とも よろしくお願いします。
- Re:PHP掲示板の記事順 2024-06-06 20:40:05 管理人 返信 編集
bbs.php の1313行
$log = array_reverse($log);
部分は、投稿記事の表示で、もともと投稿順になっているログの順番を
逆転させる処理で、これをコメントアウトすると投稿順に表示されることになりますが、
ログファイル本体への影響はないので特に問題はないと思います
ただ投稿数が$max_logに指定した数を超えると
古い記事から過去ログに移行するので、同じURLで記事を引用できるということにはならないと思います
bbs.php?id2=記事ID#bbs_記事ID
というようなURLを使えば過去ログに移行した記事も引用可能で、記事の表示を逆転する必要もありませんが、返信リンクなどから個別に記事IDを取得するのが手間ですね。
- PHP掲示板の記事順 2024-06-05 18:32:15 flipflop 返信 編集
いつもお世話になっています。
PHP掲示板の記事順についてお伺いします。
記事をストックして、いつでもURLで引用できるようにしたいと考えています。
そのため ページを固定したいので、新規の記事が上ではなく 下に付くようすることは可能でしょうか。
できればこれまでの記事も昇順?(古い記事ほど上に表示)になればいいのですが、これまでの記事はそのままで、これからの記事から下に付くようなことでもかまわないです。
こちらのスキルからして かなりの修正であれば諦めますので、よろしくお願いします。
■2024.06.05 18:30 追記
bbs.php の1313行
$log = array_reverse($log); // 新しい順に表示するのに固定
をコメントアウトしたら 既存記事も昇順に並び変わり、新規で投稿した場合は下に付くようになりました。
お手数をおかけしました。
この処置で スクリプト上で不備であればご指摘ください。
今後ともよろしくお願いします。
- Re:PHP掲示板の警告エラーログ 2024-07-18 16:19:47 flipflop 返信 編集
>これは target=\"_blank\" ごと消せばOKです
削除は盲点でした。動作を確認しました。
ありがとうございます。
今後ともよろしくお願いします。
- Re:PHP掲示板の警告エラーログ 2024-07-18 12:14:26 管理人 返信 編集
>浅知恵で _blank を検索し、3,384行目を _top にしてみたんですが、ダメでした。
これはtarget=\"_blank\"
ごと消せばOKです
- Re:PHP掲示板の警告エラーログ 2024-07-18 11:28:27 flipflop 返信 編集
>発生するはずのないエラーに対応するというのも変ですね。
おっしゃるとおりです。何でそうなるのかを知りたいと思っても、知識がないので諦めます。
エラーは ほうっとこうかなと思ったのですが、昨日のログにも500もの警告エラーがあったので、ご提案の3行に書き替えてみました。
たとえば下記のリファラですが、これにアクセスするとエラーが出ていたことは確認しています。
https://flipflop.ie-t.net/flipflop_php/bbs.php?id=s1yBiFzkwt&id2=Http%3a%2f%2fWww.Google.Com&res=1&noform=s1yBiFzkwt&item=thread
ご提案の3行を書き替えてみましたら、エラーが出ませんでした。(他のリファラも同じでした)
お忙しいところ ありがとうございます。
警告エラーとは言え、一度で何百行の生成するログなのでスッキリしました。
今後ともよろしくお願いします。
■何度もお聞きするのも気が引けますので、このスレッドで勘弁してください。
記事のリンクを同じ窓(タブ)で開きたいのですが、簡単な書き替えで済むのであれば お手すきのときにでも お教えください。
浅知恵で _blank を検索し、3,384行目を _top にしてみたんですが、ダメでした。
よろしくお願いします。
- Re:PHP掲示板の警告エラーログ 2024-07-18 01:09:07 管理人 返信 編集
やはりid2の値がURLのようなものになっていたようですね。
少なくともbbs.phpの動作ではid2の値になるのは英数字のみで構成される記事IDということになります。
手動で編集すれば可能ですが...
id id2 res noform item をGET送信しているということはおそらく返信リンクをクリックしたときのURLだと思われますが、
外部からロボットで投稿しようとしたわけでもなさそうですね。if (req('id2') && preg_match('/^' . req('id2') . '/',$file)) {
を$req_id2 = req('id2');
$req_id2 = preg_replace('|/|','\/',$req_id2);
if ($req_id2 && preg_match('/^' . $req_id2 . '/',$file)) {
などに変更すればid2内に/が含まれていた時のエラーは回避できると思いますが、
発生するはずのないエラーに対応するというのも変ですね。
- PHP掲示板の警告エラーログ 2024-07-17 18:30:09 flipflop 返信 編集
ご迷惑をおかけします。
line 2789 で [fcgid:warn] が出た 7月15日のログをお送りします。
こうしてみると、変な URL のような気がします。
「id2=Http%3a%2f%2fWww.Google.Com」のように通常の閲覧アクセスだと見かけない URLが記載されています。
WEBで調べてみると、IP自体は「Low Risk」ということなんですけど、イレギュラーなアクセスなんでしょうか?
■7月15日のエラーログ
[Mon Jul 15 02:59:10.540541 2024] [fcgid:warn] [pid 3255896:tid 140007645886208] [client 185.***.***.**:27322] mod_fcgid: stderr: PHP Warning: preg_match(): Unknown modifier '/' in /var/www/clients/client492/web914/web/flipflop_php/bbs.php on line 2789, referer: https://flipflop.ie-t.net/flipflop_php/bbs.php?id=s1yBiFzkwt&id2=Http%3a%2f%2fWww.Google.Com&res=1&noform=s1yBiFzkwt&item=thread
なお、7月12日と15日のログをピックアップして こちらのサポート掲示板に投稿しようとしたのですが、URL個数の関係で投稿できませんでしたので、必要であれば以下のURLでお目通しください。
(追記)12日のアクセスログのリクエストの中にも変なURLが紛れ込んでいました。
https://flipflop.ie-t.net/ffphp_v1062/bbs.php?id2=uCmCnOc7ZUAH#bbs_uCmCnOc7ZUAH
counter:45,801
名前は "Shade検索"Wiki となっていますが、Shade関係の記事はほとんどなくて、自作のCGIなどをひっそりと紹介するサイトになってます。
CGIについてのお問い合わせはCGIサポート掲示板へ
最近更新した記事
2024年11月12日
2024年08月06日
2024年07月30日
公開しているCGIなど
2024年11月12日
2024年08月06日
2024年07月30日
2022年10月03日
2022年03月22日
2021年08月18日
2023年02月26日
2018年03月01日
2016年08月26日
2016年08月16日
counter:13,485
最近の更新
2024年11月12日
2024年08月06日
2024年07月30日
公開しているスクリプト
PHP
2024年11月12日
2024年08月06日
2024年07月30日
2022年10月03日
2022年03月22日
2021年08月18日
CGI
2023年02月26日
2018年03月01日
2016年08月26日
2016年08月16日
counter:22,751
- プラグインヘルプ(59,202)
- CGIサポート掲示板(45,801)
- PHP/ブルートフォース対策モジュール(36,642)
- Sidebar(31,960)
- CGI/マルチアップローダ(29,819)
- Perlアップデートとjacode.pl(29,269)
- PHP/PerlからPHPへ書き換え補助PHP(29,193)
- PHP8.1.2(28,151)
- PHP/Calendar Plus(28,024)
- 改行コードについて(25,688)
- PHP/用語集作成(25,657)
- CPANメモ(25,482)
- PerlからPHPへ書き換え(25,052)
- ユーザーの負担が少ないスパム投稿対策4(24,852)
- メインブラウザをVivaldiに乗り換え(24,537)
- PHP/サブネット計算(24,533)
- Menu(22,751)
- Xamppが64bit化(21,118)
- メニューとトップページについて(20,776)
- CGI/詳細予定表(19,926)
- CGI/疑似偏差値計算機(19,908)
- bbsプラグイン改修(19,741)
- PHP/掲示板PHP(19,564)
- 日本語のパスワード(19,518)
- ユーザーの負担が少ないスパム投稿対策(19,288)
- CGI/タイムスタンプ変更CGI(19,066)
- マルチアップローダ設置(18,779)
- PHP7.2(18,593)
- パスワードの暗号化についての覚書(18,160)
- CGIの利用について(17,850)
- ユーザーの負担が少ないスパム投稿対策3(17,822)
- Perl5.26(17,090)
- Xampp8.0.3(16,942)
- PHPの時間ログについて(16,872)
- Shade検索CGI改修(15,947)
- 更新履歴(15,314)
- ユーザーの負担が少ないスパム投稿対策2(15,301)
- mpdfの文字化け対策(15,197)
- 文字列の切り詰め(14,820)
- プラグイン・スクリプト検索CGIについて(14,663)
- PHPメモ(14,128)
- FrontPage(13,485)
- PHPでハッシュ化(13,091)
- トレンドマイクロの検索ロボット(12,839)
- PHP8.2.4(12,733)
- XamppのPerlをアップデート(12,718)
- マルチアップローダのベーシック認証(12,415)
- ヘルプ(12,354)
- Shade8.5/PythonリファレンスCGI(11,346)
- access(154)
- 暗号化とハッシュ化(139)
counter:154
インストールされているプラグインの一覧です。
[A]
- access
- アクセスの多い順にページ名を一覧表示
- bbs
- 掲示板を作成する
- bbs_count
- bbsプラグインの最新投稿をチェックして、投稿数をカウント
- calendar
- カレンダーを表示し、予定などを保存します。
- categories
- カテゴリーの一覧を表示する
- comment
- 1行コメントフォームを表示
- comment2
- commentプラグインに記事の再編集機能を追加
- comment3
- comment2プラグインにファイル添付機能を追加
- diff
- 差分表示
- edit
- 編集リンクを表示する
- footnote
- 脚注を表示する
- get_id
- 記事のIDを取得
- help
- 記事の入力ルールを簡単に説明します
- history
- 更新履歴を表示する
- listup
- 記事の一覧を表示する
- navi
- 同じカテゴリーまたは同じタイトルの前後の記事のリンクを表示する
- readmore
- 「続きを読む」を表示する
- recent
- 最近更新された記事の一覧を表示する
- search
- 検索フォームを表示して検索する
- search_image
- 記事に添付された画像のサムネールを一覧表示する
- show_load_time
- 読み込み時間を表示
- show_new
- ファイルが更新されたらnew!表示する。
- spam_check
- bbsプラグインのスパム投稿をチェック
counter:59,202
基本的にテキスト装飾はhtmlのタグで直接記述します。管理者設定で許可されたタグが使用できます。
<abc>ABC</abc>のように登録されていないタグは文字参照で表示されます。
preタグ内では許可されているタグを含めてすべてのタグが文字参照で表示されます。
<abc>許可されていないタグ</abc>
「投稿」ボタンを押してファイルをアップロードすると、ファイルのサムネールの上にそのファイルの埋め込みタグが表示されるので、それをコピーして貼り付けます。
画像ファイルの場合、imgタグにwidth属性を指定しますが、オリジナルの画像の幅となっています。大きすぎてはみ出すような場合は、適当な数値に変更してください。
添付ファイルは記事ごとに管理されますが、埋め込みタグは記事に関連づけられたディレクトリへ保存されたファイルのパスを指定しているだけなので、他の記事に埋め込んでもそのまま使えます。
見出し
見出しはh1、... h4タグを使うことを想定しています。見た目の変更はbbs.cssで行うことになります。<h1>h1タグによる見出し</h1>
<h2>h2タグによる見出し</h2>
<h3>h3タグによる見出し</h3>
<h4>h4タグによる見出し</h4>
h1タグによる見出し
h2タグによる見出し
h3タグによる見出し
h4タグによる見出し
タグ
許可されているタグはすべて有効になります。文字参照で記述しても有効になるので、ご注意ください。<abc>ABC</abc>のように登録されていないタグは文字参照で表示されます。
preタグ内では許可されているタグを含めてすべてのタグが文字参照で表示されます。
<div style="color:red;">許可されているタグ</div>同じものをpreタグの外に出すと
<font style="color:blue;">許可されていないタグ</font>
<abc>許可されていないタグ</abc>
許可されているタグ
<font style="color:blue;">許可されていないタグ</font><abc>許可されていないタグ</abc>
改行
「改行を<br />に変換する」をチェックしていると、フォーム中の改行を
<br />に変換して記事の改行に反映させます。ただし、行の最後が閉じタグ ">" あるいはプラグインの記述に使う "]]" の場合は変換されません。
<table>が
<tr><td>テーブル</td></tr>
</table>
<table><br />のようになると変だからです。
<tr><td>テーブル</td></tr><br />
</table><br />
添付ファイル
画像などの添付ファイルは記事ごとにアップロードします。「投稿」ボタンを押してファイルをアップロードすると、ファイルのサムネールの上にそのファイルの埋め込みタグが表示されるので、それをコピーして貼り付けます。
画像ファイルの場合、imgタグにwidth属性を指定しますが、オリジナルの画像の幅となっています。大きすぎてはみ出すような場合は、適当な数値に変更してください。
添付ファイルは記事ごとに管理されますが、埋め込みタグは記事に関連づけられたディレクトリへ保存されたファイルのパスを指定しているだけなので、他の記事に埋め込んでもそのまま使えます。
counter:12,354
- 左側に表示されるメニューをカスタマイズしたい場合は、タイトルが「Menu」という名前のページを作って下さい。
Menuにはたとえば[[recent]]
などと記載すると新着順に記事が表示されます。そのほかlistupプラグインなどを使ってメニューに表示されるインデックスをカスタマイズすることができます。 - プラグインの詳細を見るには、「プラグインヘルプ」などのタイトルのページを作成し、
[[plugins]]
と記述して下さい。 - ページ記述のヘルプは「ヘルプ」というタイトルのページに
[[help]]
と記述して下さい。 - 初期設定では最新の記事がトップページに表示されますが、トップページを固定するには「FrontPage」というタイトルのページを作ってください。
- 「Sidebar」というタイトルのページに書かれた内容はサイドバー部分に表示されます。
- 「Footer」というタイトルのページに書かれた内容はフッター部分に表示されます。
counter:20,776
改行コードってあまり気にしていなかったが、あまり無頓着だとトラブルになるようだ。
Linuxサーバー上での動作をチェックするために久しぶりにCGIファイルをWebサーバーにアップロードしてみたのだが、
500エラーで動作しないという問題が発生した。パーミッションをいじっても動くようにならず、なんでだと思っていたら
CGIファイルの改行コードがCRLFになっていたのが原因だった。
以前はCRLFでもエラーは出ていなかったはずと思ったが、どうも以前はFTPソフトでテキストモードでアップロードしていたので、自動的に改行コードがサーバーにあったものに変換されていたようだ。最近はテキストモードではなくバイナリモードでアップロードしているので、CRLFのファイルはCRLFのままアップされる。
整理しておくと改行コードはLF、CR、CRLFとあって、OSによって使う改行コードが違う。
LinuxなどUNIX系はLF、MacはCR、WindowsはCRLFを使う。プログラムでは、LFは"\n" CRは"\r" CRLFは"\r\n"と記述する。
でWeb上のサーバーはLinux系が多いので、そこで使用するCGIファイルはLFを使わなければならないということなのだろうが、不思議なことにPHPはCRLFのままでも問題なく動いている。
それとWindowsにインストールしたXamppでは、WindowsなのでCRLFで動くのは当然として、LFでも問題なく動く。
Webサーバー上のCGIファイルの改行コードは、OSで使用する改行コードを使うことが望ましいが、使わないと絶対ダメというほどではないということか。いずれにしても、WebプログラムのファイルはLFで統一しておくのが無難かもしれない。
ちなみにWindows標準のテキストエディタ「メモ帳」は、以前はLF改行コードでは改行されなかったが、最近のはちゃんと改行されるようだ。
Linuxサーバー上での動作をチェックするために久しぶりにCGIファイルをWebサーバーにアップロードしてみたのだが、
500エラーで動作しないという問題が発生した。パーミッションをいじっても動くようにならず、なんでだと思っていたら
CGIファイルの改行コードがCRLFになっていたのが原因だった。
以前はCRLFでもエラーは出ていなかったはずと思ったが、どうも以前はFTPソフトでテキストモードでアップロードしていたので、自動的に改行コードがサーバーにあったものに変換されていたようだ。最近はテキストモードではなくバイナリモードでアップロードしているので、CRLFのファイルはCRLFのままアップされる。
整理しておくと改行コードはLF、CR、CRLFとあって、OSによって使う改行コードが違う。
LinuxなどUNIX系はLF、MacはCR、WindowsはCRLFを使う。プログラムでは、LFは"\n" CRは"\r" CRLFは"\r\n"と記述する。
でWeb上のサーバーはLinux系が多いので、そこで使用するCGIファイルはLFを使わなければならないということなのだろうが、不思議なことにPHPはCRLFのままでも問題なく動いている。
それとWindowsにインストールしたXamppでは、WindowsなのでCRLFで動くのは当然として、LFでも問題なく動く。
Webサーバー上のCGIファイルの改行コードは、OSで使用する改行コードを使うことが望ましいが、使わないと絶対ダメというほどではないということか。いずれにしても、WebプログラムのファイルはLFで統一しておくのが無難かもしれない。
ちなみにWindows標準のテキストエディタ「メモ帳」は、以前はLF改行コードでは改行されなかったが、最近のはちゃんと改行されるようだ。
counter:25,688
今更ですが、暗号化とハッシュ化をごっちゃにした記事がいくつかあったので、修正しておきます。
暗号化もハッシュ化も元のデータがわからないように変換することですが、暗号化は元のデータに戻す方法があり、ハッシュ化は元のデータに戻せないという大きな違いがあります。
ハッシュは元のデータに戻すことはできませんが、元のデータから生成されたものであるかどうかは判定することができるので、それを利用してパスワード認証によく利用されています。
ユーザーがパスワードを登録する際に、パスワードそのものではなくパスワードのハッシュを保存します。
ユーザーがパスワードを入力した際には、パスワードのハッシュが入力されたパスワードから生成されたものであるかどうか判定することによって、正しいパスワードかどうかを判断します。
生のパスワードを保存しないことによって、万一データが漏洩した際の安全性も上がります。
暗号化もハッシュ化も元のデータがわからないように変換することですが、暗号化は元のデータに戻す方法があり、ハッシュ化は元のデータに戻せないという大きな違いがあります。
ハッシュは元のデータに戻すことはできませんが、元のデータから生成されたものであるかどうかは判定することができるので、それを利用してパスワード認証によく利用されています。
ユーザーがパスワードを登録する際に、パスワードそのものではなくパスワードのハッシュを保存します。
ユーザーがパスワードを入力した際には、パスワードのハッシュが入力されたパスワードから生成されたものであるかどうか判定することによって、正しいパスワードかどうかを判断します。
生のパスワードを保存しないことによって、万一データが漏洩した際の安全性も上がります。
counter:139