| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
文字サイズ変更：
トップページ ＞ Perlについて
●Perlについて●
2025-03-04 22:18:49Perlのバージョンが変わるとプログラマーは苦労する -DB編-
以前のサーバーからデータベースで記事を登録しているので、今回もデータベースで環境を整えております。
MariaDB & MySQLを使用しております。
そこで、一番苦労したのが文字化け、でした。
それに、別レンタルサーバーだけど同じデータベースなのに、接続方法で振舞いが変わってDBへの接続もおぼつかない感じでした。
以前は、こんな風にしておりました。
my $dbh = DBI->connect($data_source，$username，$password，
{mysql_enable_utf8 => 1
}) or die $DBI::errstr;
色々探した結果、以下のようにしました。
my $dbh = DBI->connect($data_source，$username，$password，{
mysql_enable_utf8mb4 => 1，
mysql_auto_reconnect => 1，
RaiseError => 1，
AutoCommit => 1，
}) or die $DBI::errstr;
※全角カンマ（，）を使用しております。
※またコードを便宜上全角文字にしております。
今回、「RaiseError」を設定するのが必要だったようです。
また、「utf8mb4」と、文字コードを設定したことで、文字化けが解消できたことも挙げておきたいと思います。
それから、ファイルをUTF-8に保存する事。
それと、HTML出力する時に、「<meta http-equiv="Content-type" content="text/html; charset=UTF-8">」と指定する事。
データベースから記事を以前のサーバーからエクスポートする時も、UTF-8にする事。
データベースに記事を今のサーバーへインポートする時も、UTF-8にする事。
データベースの文字コードをなるべくutf8mb4になっているか確認する事。
「show variables like "chara%";」は、ターミナルで確認すると別サイトでありましたが、私は、DBの「PHPMyAdmin」画面上のSQL入力画面で確かめました。
こんな風に表示されます。
Variable_name Value
----------------------------------------------
character_set_client：utf8mb4
character_set_connection：utf8mb4
character_set_database：utf8mb4
character_set_filesystem：binary
character_set_results：utf8mb4
character_set_server：utf8mb4
character_set_system：utf8
character_sets_dir：/usr/share/mysql/charsets/
各項目の意味：
character_set_server：デフォルトのサーバー文字コード。
character_set_database：デフォルトのデータベース文字コード。
テーブルやカラムの文字コードを確認するには、以下のコマンドを使用します。
テーブル単位：SHOW CREATE TABLE table_name;
カラム単位：SHOW FULL COLUMNS FROM table_name;
データベース単位の設定変更
変更コマンド：ALTER DATABASE database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
* utf8とutf8mb4の違い *
技術的な違い
utf8：MySQLのutf8は実際にはUTF-8のサブセットで、最大3バイトまでしかサポートしていません。このため、絵文字や一部の特殊文字（例：?）を扱うことができません。
utf8mb4：UTF-8の完全な実装で、最大4バイトまでの文字をサポートします。
* なぜutf8mb4が推奨されるのか *
互換性：現代のWebアプリケーションやモバイルアプリケーションでは、絵文字や特殊文字を扱う場面が増えています。
標準化：多くのCMS（例：WordPress）では、デフォルトでutf8mb4が推奨されています。
* 移行時の注意点 *
utf8からutf8mb4に移行する際には、以下の点に注意してください。
データベースサイズ：utf8mb4では1文字あたり最大4バイトを使用するため、データベースサイズが増加する可能性があります。
既存データ：変更前にデータのバックアップを取ることを強く推奨します。
アプリケーション設定：アプリケーション側で使用する文字コード（例：クライアント接続文字コード）もutf8mb4に設定する必要があります。
※「MariaDB perl MySQL 文字化け」で検索したら、有用な情報に辿りつけました。
出典「MySQL & MariaDBの世界 - MySQLの文字コード確認方法を徹底解説！【設定・変更手順と文字化け対策】」
|
Print
Twitter(test)
short URL
いいね:49 back to the TOP |
Perlのバージョンが変わるとプログラマーは苦労する -導入編-
今回、レンタルサーバーの引越しに伴い、使うPerlのバージョンが変わりました。
今まで5.16だったのが5.26にかわったようです。
それで、かなりロジックの振舞いが変わり、また新しい画面でお披露目しようと作っておりますので、苦労の連続です。
そこで、メモ代わりにどんなところで苦労したのか、書こうと思います。
まず、いつもアテにしているKCatch.pmが全く使えない点。
中のロジックが今のPerlのバージョンに合わずにいるようです。
それから、@INCに対する振舞いも変わっておりますので、requireするファイルを読み出させるだけでも苦労しました。
BIGINで、最初に読み込ませることに成功しましたので、サンプルで載せようと思います。
BEGIN {
require ’./db_sample1.pl’;
require ’./sample2.pl’;
}
※全角カンマ（，）を使用しております。
BEGINで最初に処理したい内容を書きます。
外部ファイルを呼んだ場合として、sample1.plと書きました。
ローカルで使っているパソコンのパスを書いたまま、サーバーにアップデートしていますが、大丈夫そのまま動きます。
また、以前のバージョンのPerlで処理しようとも思いました。
その方法は、「#!/usr/bin/perl516」と、「516」と付け加えるか、もしくは「use 5.24.2;」と、useして呼ぶ方法です。
「516」と付け加える方は、Perl ver5.16で動くようです。
「use 5.24.2;」と書く方は、Perl ver5.24.2で動くようです。
ちなみに今は、最新のサーバーでのPerl ver5.26で動かしています。
それから、ローカルのパソコンはActivePerl5.38をインストールしました。
そうしたら、「Locale ’Japanese_Japan.932’ is unsupported，and may crash the interpreter.」とコマンドプロンプトで「Perl -c filename.pl」とシンタックスエラーを探す度に表示されるようになりました。
恐ろしい文言が表示されるので、戦々恐々なんですが、今の所アンインストールを模索している暇はないので、放っといています。
まだ続きます。
それでは。
|
Print
Twitter(test)
short URL
いいね:7 back to the TOP |
 |
 |
 |
