2010/02/24
2010/02/05
Mysql Dumpの不具合
ラベル:
Mysql4
Warning: reset(): Passed variable is not an array or object in /home/httpd/vhosts/ほげほげ.com/httpdocs/admin/includes/classes/object_info.php on line 17
Warning: Variable passed to each() is not an array or object in /home/httpd/vhosts/ほげほげ.com/httpdocs/admin/includes/classes/object_info.php on line 18
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
なので、データのエクスポート時にはMySql互換モードでこの一言を入れる
compatible=mysql323
もいっちょCREATE TABLE構文より
Warning: Variable passed to each() is not an array or object in /home/httpd/vhosts/ほげほげ.com/httpdocs/admin/includes/classes/object_info.php on line 18
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
NO_AUTO_VALUE_ON_ZERO は、AUTO_INCREMENT カラムの処理に影響を与える。通常、NULL または 0 のいずれかをカラムに挿入することにより、カラムの次のシーケンス番号を生成する。 NO_AUTO_VALUE_ON_ZERO を指定すると、0 のこの働きが抑制されるため、NULL だけが次のシーケンス番号を生成することになる。このモードは、0 がテーブルの AUTO_INCREMENT カラムに保存されている場合に役に立つ（これは推奨されている方法ではないが）。
たとえば、mysqldump でテーブルをダンプしてから再読み込みした場合、MySQL は通常、0 値に遭遇したときに新規シーケンス番号を生成するため、ダンプされたテーブルと再読み込みしたテーブルの内容が異なる結果になる。この場合、ダンプしたファイルを再読み込みする前に NO_AUTO_VALUE_ON_ZERO を有効にするとこの問題が解決する（このオプションが使用可能になった MySQL 4.1.1 以降、mysqldump によるダンプ出力には、自動的に NO_AUTO_VALUE_ON_ZERO を有効にするためのステートメントが含まれている）。
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
なので、データのエクスポート時にはMySql互換モードでこの一言を入れる
compatible=mysql323
もいっちょCREATE TABLE構文より
整数型カラムは追加属性 AUTO_INCREMENT を持つことができる。 インデックス付きの AUTO_INCREMENT カラムに NULL（推奨）または 0 を挿入すると、そのカラムには連続値の次の値が設定される。 通常、これは value+1 になる（value はテーブルに現在格納されているそのカラムの最大値）。 AUTO_INCREMENT は 1 から開始される。 項11.1.3.32. 「mysql_insert_id()」。
MySQL 4.1.1 以降では、--sql-mode サーバオプションまたは sql_mode サーバ変数に対して NO_AUTO_VALUE_ON_ZERO フラグを指定することによって、新しい連続値を生成する代わりに、AUTO_INCREMENT カラムに 0 を 0 として格納することができる。 項4.1.1. 「mysqld コマンドラインオプション」。
AUTO_INCREMENT カラムの最大値が入ったレコードを削除した場合、その値は ISAM テーブルや BDB テーブルでは再利用されるが、MyISAM テーブルや InnoDB テーブルでは再利用されない。DELETE FROM table_name（WHERE 節なし）を AUTOCOMMIT モードで実行してテーブル内のすべてのレコードを削除した場合、InnoDB を除くすべてのテーブル型で、連続値が初めから開始される。項7.5.12.5. 「InnoDB での AUTO_INCREMENT カラムの仕組み」。
注意: AUTO_INCREMENT カラムはテーブルごとに 1 つだけ存在できる。このカラムにはインデックスを付ける必要があり、また DEFAULT 値は設定できない。 MySQL バージョン 3.23 では、AUTO_INCREMENT カラムは、正の値だけを持つ場合にのみ正しく機能する。負の数値が挿入されると、その値はきわめて大きな正数としてみなされる。 これは、数値が正の数から負の数に ``折り返す'' ときに発生する精度の問題を回避するためと、0 が入った AUTO_INCREMENT カラムが誤って取得されないようにするためである。
MyISAM テーブルと BDB テーブルでは、複合インデックスで AUTO_INCREMENT セカンダリカラムを指定できる。 See 項3.6.9. 「AUTO_INCREMENT の使用」。
2010/02/04
2010/02/03
RSS2に対応する為に文字コードの統一
フィードのチェックはfeedanalizerから
URL : http://フィーダーのURL
ステータス : OK (200)
サーバー : Apache/2.0.52 (CentOS)
更新時間 : 不明
ファイルサイズ : 不明
コンテンツタイプ : application/xml ("charset" は "us-ascii" になります)
スペック : RSS2.0 encode=utf-8
タイトル : タイトル
警告 このサーバー(または拡張子)は If-Modified-Sinceに対応しません。
警告 サーバーの "charset" と フィードの "encode" を一致させることをお薦めします。
構文を確認したところ問題はありませんでした。
となったらhtaccessで制御
8. HTTP 1.1によるXML文書構成単位の配送
サーバがXML文書構成単位を配送するときの文字符号化スキームとしては，UTF-16又はUTF-8のいずれかを使用する。
参考 1 ISO-2022-JP及び日本語EUC(圧縮形式)も許容する予定であったが， [JIS X 0221]及び [Unicode 2.0]への変換表を一つに決定できないため, 現在はそれを見合わせている。変換表を一意に確定させてこれらを許容する可能性は残されている。この標準情報(TR)で導入した複数の名前をそのまま許容する可能性も残されている。
参考 2 交換性が保証されないことを了解した上で， ISO-2022-JP及び日本語EUC(圧縮形式)を使用するのは利用者の自由である。
HTTP 1.1([IETF RFC 2068])による配送では，メディアタイプtext/xml又はapplication/xmlを用い，charsetパラメタを正しく付ける。メディアタイプがapplication/xmlであり，XML文書中の BOM又は符号化宣言で文字符号化スキームを明示してある場合だけは, charsetパラメタを省略できる。
参考 1 [IETF RFC 2376]はcharsetパラメタを強く推奨している。text/xmlの場合は，charsetパラメタとして指定されたcharset名がBOM及び符号化宣言より優先する。省略した場合はUS-ASCIIであると見なされる。
参考 2 US-ASCIIで符号化されたXML文書の場合は，メディアタイプが text/xmlの場合でもcharsetパラメタを省略できるが，US-ASCIIの文書は日本語文字を含んでいないので，この標準情報(TR)の適用範囲外である。
参考 3 サーバの設定によって，XML文書構成単位を格納したファイルと，メディアタイプ(text/xml又はapplication/xml)及び文字符号化スキームを表すcharset名とを関係付けなければならない。正しく設定されていれば，サーバがXML文書構成単位を配布するとき，設定されたメディアタイプがcontent-type フィールドの値として利用され，設定されたcharset名がメディアタイプのcharset パラメタの値として利用される。
クライアントは，このcharsetパラメタに従って文字符号化スキームを判定する。text/xmlのcharsetパラメタが省略された場合はUS-ASCIIであると判定する。 application/xmlのcharsetパラメタが省略された場合は情報交換用ファイルと同様に自動検出する。
参考 この規定は[IETF RFC 2376]にある。
URL : http://フィーダーのURL
ステータス : OK (200)
サーバー : Apache/2.0.52 (CentOS)
更新時間 : 不明
ファイルサイズ : 不明
コンテンツタイプ : application/xml ("charset" は "us-ascii" になります)
スペック : RSS2.0 encode=utf-8
タイトル : タイトル
警告 このサーバー(または拡張子)は If-Modified-Sinceに対応しません。
警告 サーバーの "charset" と フィードの "encode" を一致させることをお薦めします。
構文を確認したところ問題はありませんでした。
となったらhtaccessで制御
#サーバーの "charset" と フィードの "encode" をUTFで一致させる忘れがちな最後の改行。忘れると機能しない。
AddType "application/xml; charset=UTF-8" xml
#xmlのIf-Modified-Sinceに対応
AddHandler default-handler xml
8. HTTP 1.1によるXML文書構成単位の配送
サーバがXML文書構成単位を配送するときの文字符号化スキームとしては，UTF-16又はUTF-8のいずれかを使用する。
参考 1 ISO-2022-JP及び日本語EUC(圧縮形式)も許容する予定であったが， [JIS X 0221]及び [Unicode 2.0]への変換表を一つに決定できないため, 現在はそれを見合わせている。変換表を一意に確定させてこれらを許容する可能性は残されている。この標準情報(TR)で導入した複数の名前をそのまま許容する可能性も残されている。
参考 2 交換性が保証されないことを了解した上で， ISO-2022-JP及び日本語EUC(圧縮形式)を使用するのは利用者の自由である。
HTTP 1.1([IETF RFC 2068])による配送では，メディアタイプtext/xml又はapplication/xmlを用い，charsetパラメタを正しく付ける。メディアタイプがapplication/xmlであり，XML文書中の BOM又は符号化宣言で文字符号化スキームを明示してある場合だけは, charsetパラメタを省略できる。
参考 1 [IETF RFC 2376]はcharsetパラメタを強く推奨している。text/xmlの場合は，charsetパラメタとして指定されたcharset名がBOM及び符号化宣言より優先する。省略した場合はUS-ASCIIであると見なされる。
参考 2 US-ASCIIで符号化されたXML文書の場合は，メディアタイプが text/xmlの場合でもcharsetパラメタを省略できるが，US-ASCIIの文書は日本語文字を含んでいないので，この標準情報(TR)の適用範囲外である。
参考 3 サーバの設定によって，XML文書構成単位を格納したファイルと，メディアタイプ(text/xml又はapplication/xml)及び文字符号化スキームを表すcharset名とを関係付けなければならない。正しく設定されていれば，サーバがXML文書構成単位を配布するとき，設定されたメディアタイプがcontent-type フィールドの値として利用され，設定されたcharset名がメディアタイプのcharset パラメタの値として利用される。
クライアントは，このcharsetパラメタに従って文字符号化スキームを判定する。text/xmlのcharsetパラメタが省略された場合はUS-ASCIIであると判定する。 application/xmlのcharsetパラメタが省略された場合は情報交換用ファイルと同様に自動検出する。
参考 この規定は[IETF RFC 2376]にある。
2010/02/02
oscommerce - EUCからUTF-8に移行
ラベル:
oscommerce、カスタム
oscommerceはデフォルトでEUC推奨なので全てEUCだ。
データベースにMySql4を使っているので、MySql5に移さないと使えない。
作業的にはこんな順序かな？
oscommerceのファイルバックアップ
データベースのバックアップ
スクリプトの修正Mysql4=>MySql5
../catalog/default.php
../catalog/advanced_search_result.php
言語ファイルのCHARSETをUTF化と全ての書類のUTF化
（書類の文字コードもUTF-8のLF改行で統一）
../catalog/includes/languages/japanese.php
サーバー設定をlocalhostからMySql5のサーバーに変更（UTF-8）
バックアップしたsqlファイルを開きデータを確認。日本語等が文字化けしてsyntaxエラーを引き起こすのですが、出たら出たでエラーレポートを見てエラーの周辺の行をチェックして修正または削除。¥r¥nの削除または『¥』を『\』（バックスラッシュ）に置き換え
DBをドロップしてMySQL5へ切り替え（照合順序はutf_general_ci）
DBにUTFのsqlファイルをインポート15MBまでならphpMyadminでGO
修正したファイルをアップロード
カテゴリーが文字化けする場合はキャッシュが効いているので、管理画面より
[各種ツール]=>[キャッシュコントロール]=>カテゴリーボックスのキャッシュブロックを削除
フッターの文字化けは大概日付。
データベースにMySql4を使っているので、MySql5に移さないと使えない。
作業的にはこんな順序かな？
oscommerceのファイルバックアップ
データベースのバックアップ
スクリプトの修正Mysql4=>MySql5
../catalog/default.php
../catalog/advanced_search_result.php
言語ファイルのCHARSETをUTF化と全ての書類のUTF化
（書類の文字コードもUTF-8のLF改行で統一）
../catalog/includes/languages/japanese.php
サーバー設定をlocalhostからMySql5のサーバーに変更（UTF-8）
バックアップしたsqlファイルを開きデータを確認。日本語等が文字化けしてsyntaxエラーを引き起こすのですが、出たら出たでエラーレポートを見てエラーの周辺の行をチェックして修正または削除。¥r¥nの削除または『¥』を『\』（バックスラッシュ）に置き換え
DBをドロップしてMySQL5へ切り替え（照合順序はutf_general_ci）
DBにUTFのsqlファイルをインポート15MBまでならphpMyadminでGO
修正したファイルをアップロード
カテゴリーが文字化けする場合はキャッシュが効いているので、管理画面より
[各種ツール]=>[キャッシュコントロール]=>カテゴリーボックスのキャッシュブロックを削除
フッターの文字化けは大概日付。
../catalog/includes/languages/japanese.phpの以下の箇所
define('DATE_FORMAT_LONG', '%Y年%m月%d日(%a)'); // this is used for strftime()
これを
define('DATE_FORMAT_LONG', '%Y年 %m月 %d日'); // this is used for strftime()
こう（半角開けただけ）
OscommerceにTwitterボタン
ラベル:
oscommerce、カスタム
まずtwitterで呟くからには文字コードがutf-8でなければならない。
oscommerceの文字コードはEUC-JP
UTF-8に移行する方法は後にして、、
投稿するにはこうする
なので書き込みたい事に商品タイトルを入れてみる
リンクが欲しいのでそのページのURLを取得する
そしてページのURLを組み込んでボタンを作ってみる
たとえばtwitter.gifなんてしてみて、、
../catalog/includes/language/japanese/images/button/
にアップロードして次のファイルを編集
../catalog/includes/language/japanese.phpに
で、以下のコードをproduct_info.phpに貼付けて完成
oscommerceの文字コードはEUC-JP
UTF-8に移行する方法は後にして、、
投稿するにはこうする
http://twitter.com/home?status=RT:@ユーザー 書き込みたい事
なので書き込みたい事に商品タイトルを入れてみる
echo "<a href=\"" . "http://twitter.com/home?status=RT:@ユーザー " . $product_info['products_name'] . "\" target=_blank>\n";?>
リンクが欲しいのでそのページのURLを取得する
そしてページのURLを組み込んでボタンを作ってみる
たとえばtwitter.gifなんてしてみて、、
../catalog/includes/language/japanese/images/button/
にアップロードして次のファイルを編集
../catalog/includes/language/japanese.phpに
define('IMAGE_BUTTON_TWEET', '呟く');と一行挿入してアップロード
で、以下のコードをproduct_info.phpに貼付けて完成
<!-- Twiter Button BEGIN -->
<?php
$url = $_SERVER['REQUEST_URI'];
echo "<a href=\"" . "http://twitter.com/home?status=RT:@ユーザー " . $product_info['products_name'] . " http://dubfactory.com" . $url . "/" target=_blank>\n";?><?php echo tep_image_button('button_twitter.gif', IMAGE_BUTTON_TWEET); ?></a>
<!-- Twitter Button END -->
現在のページ（カレントURL）をphpで取得する
ラベル:
php
ヘッダやフッタなど、ほぼ全ページに渡って同じ内容だと思うのだが、これを更新するときはどのようにしているだろうか。私は Dreamweaver 嫌いなので、テンプレート機能は使わない。テンプレートを更新すると、テンプレートを使っているページ全てをアップロードしなければならないので、面倒だし危険性（先祖返り）の可能性もある。
もうお気づきだろうが、私は ssi を使用している。これならば ssi だけをアップロードすれば良いし、php を ssi にすればレイアウトは同じでページ毎にやや違うといった、メニューやパンくずリストにも使える。
まず、php で現在ページを取得する。
これで ssi として php を読み込んでいる側の html の url を取得できる。そしてこの取得した url を使って条件分岐を行う。
その前に、/index.html と / を分岐させなくてもいいように、置換しておく。
もしこの ssi がタイトルやメタ情報など、ページごとに違う用途に使うのであれば、$url に対する switch で分岐を行い、メニューのようにディレクトリごとに違う用途であれば、$url にディレクトリ名を strpos で探し、分岐を行う。
これでメタ情報だろうがメニューだろうがパンくずだろうが ssi にすることができ、更新が楽になる。
もうお気づきだろうが、私は ssi を使用している。これならば ssi だけをアップロードすれば良いし、php を ssi にすればレイアウトは同じでページ毎にやや違うといった、メニューやパンくずリストにも使える。
まず、php で現在ページを取得する。
$url = $_SERVER['REQUEST_URI'];
これで ssi として php を読み込んでいる側の html の url を取得できる。そしてこの取得した url を使って条件分岐を行う。
その前に、/index.html と / を分岐させなくてもいいように、置換しておく。
$url = str_replace("index.html", "", $url);
もしこの ssi がタイトルやメタ情報など、ページごとに違う用途に使うのであれば、$url に対する switch で分岐を行い、メニューのようにディレクトリごとに違う用途であれば、$url にディレクトリ名を strpos で探し、分岐を行う。
これでメタ情報だろうがメニューだろうがパンくずだろうが ssi にすることができ、更新が楽になる。
登録:
投稿 (Atom)
