投稿

ラベル(utf-8)が付いた投稿を表示しています

SSHで接続できない

イメージ
 Ubuntuを24.04→26.04 時間があったので、メインマシンのUpgradeを実施。 とはいえ、とはいえ、システムディスク(/)とデータディスク(/home)を分けているのでクリーンなインストールを実施。 (1) USBでUbuntu26.04を起動 (2) /home/user → /home/user_old にリネーム (3) 26.04をインストール これで、/home/user_oldにこれまでの環境が残ったまま、新規userでインストールすれば完了。もともとのuserが使用していたuser_id:1000のままなので、どちらのフォルダも見ることができる。 あとは、使用するソフトをインストールし  /home/user_old 以下から、利用する設定ファイル等をコピーして動作確認するだけ。 Dropbox MEGA などは、先にコピーしてから、フォルダ同期設定をすることで、ダウンロードなどはチェックのみで完了する。 thunderbird brave browser vscode dbeaver-ce typora obsidian LMStudio ollama あたりを移行してほぼ終了 .sshはそのままコピーして完了。 と思っていたら、何故かサーバによっては接続できない場合があることに気づいた。 $ ssh vps 何も返ってこず、接続できない。 でこれまで接続できていたのに、うまく行かない?? 詳細を確認しながら、チェックすることに。 $ ssh -vv vps debug1: OpenSSH_10.2p1 Ubuntu-2ubuntu3.5, OpenSSL 3.5.5 27 Jan 2026 debug1: Reading configuration data /home/user/.ssh/config ︙ debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: /home/user/.ssh/id_rsa RSA SHA256:n5ocPbCvMV4FGFof … … … … … pBuJ/8r/kHGANY explicit agent のように、 認証完了後にシェルが起動せず、応答がない状態になっている。 具体的には ...

UTF8の指定ではまった

MariaDB+PHPにて PHPでDB上のデータを大量に処理するプログラムを書いていて、おかしな現象に出くわした。 1万件+42万件+43万件のjoinで、必要なもののみ取り出して、updateをかけるという手作業ではやる気にならない処理なので、サクッと書いてぶん回すしかない…。 ローカルでmysqlモニタを使用してSQLを叩くと、問題なく結果が返ってくる。 でもって、サーバ上で実行すると、結果がEmpty…。 あれれ? 試しに、phpmyadmin上でSQLだけ叩いてみる。 ローカルと同じ結果になる。 何かがおかしい。  :  : $mysqli = new mysqli("localhost",$username,$password); if($mysqli->connect_error){   print('<p>データベースへの接続に失敗しました</p>'.$mysqli->connect_error);   exit(); } $mysqli->select_db($dbname); $mysqli->set_charset("utf-8"); $sql="SELECT bill.bill_id,bill_item.bill_item_id,bill_item_detail.bill_item_detail_id,              bill.billing_id,bill.bill_month,bill.bill_date,bill.deposit_receive_date   FROM `bill_item_detail`   join bill_item on bill_item_detail.bill_item_id=bill_item.bill_item_id   join bill on bill.bill_id=bill_item.bill_id   WHERE `bill_item_detail`.`name` LIKE '繰越残高' AND  :  :   order by bill.b...

Macのdiff

イメージ
WindowsでもLinuxでもMacでも使いたい 設定や、ソフト書いた時とか必要なツールはだいたい決まっている。 エディタにコマンドライン用の各種ツール…。 当然、好き嫌いはあるだろうし、良い物も使いにくいものもある。 その中でも定番なのは、lessやdiff、grepなんかは必須です。 でも、diffに関して言えば、GUIも使いやすのは事実。 WindowsだとExamDiffなんかはお世話になった。 UbuntuではMeldを使っていた。 Macは? よく考えたら、Macでは使っていない。 Virtualboxを常備しているので、中のUbuntuで作業することが多いせいだろうか… 気になったので、調べてみた。 「ソフトアンテナブログ」の「 Mac用日本語GUI diffを検討する 」なんて記事があったので、参考に試してみる。 Xcodeは入れたはあるが、起動に時間がかかりすぎて、サッと使うには適していない。 しかも、日本語でエラーって…。この記事自体が2010年のものなので、今は改善しているかもしれないけれど…。 次に行ってみる。 DiffMerge も日本がダメらしい。 今度は、単純なツールっぽいので、試してみることに。 DiffMergeのサイトに行って、早速ダウンロードする。 スクリーンショットを見る限りは、良さそう。 アイコンが少しかっこいい。 起動してみると、画面はいたってシンプル。 アイコン左から、フォルダのDiff、ファイルのDiff、ファイルのmergeとこれだけ。 試しに、テキストファイルを食わせてみる。 問題なく、表示もいい感じ。 さて、日本語だけれど、デフォルト設定では文字化けする。 でも、環境設定を見ると、使用するフォントなどが選べるようになっているので、大丈夫なんじゃ?と思わせる。 設定を変えて試してみたら、ちゃんと日本語でもOKじゃないですか!! 設定を変更したのは、文字コードと、使用フォントのみ。 まずは、一番上のDefault Rulesを編集する。 でもって、UTF-8を使うように設定する。 フォントは、好きな日本語フォントを選べばOK。僕はOsakaにした。 ...

PostgreSQLでEUC_JPのテーブル

イメージ
今さらEUC_JPって感じだけど すでにサーバ環境がUTF-8をデフォルトとするようになって、随分経っているので必要となるケースは少ないんだけど、今回はハマりました。 通常であれば、UTF-8でDBを構築していけば、特に問題もなく引っかかるようなところは何もないのだけれど…。 サーバの移行のため、仕方なくEUC_JPを使うことに。 旧データベースは、プログラムもEUC_JPで構築されている。 プログラムの書き換えは動作検証に時間がかかるので、そのまま動かしたい。 まぁPostgreSQLは文字コードを選べるので、問題ないだろうと…。 サーバにPostgreSQLをインストール これは問題なく、いつも通りapt-getで入れてオシマイ。 何も引っかかるところはありません。 ついでに、phppgadminも入れておく。 これで作業が簡単になる。 旧サーバにも入っているので、確認がしやすいですな。 若干、バージョンが異なっているので、その点だけ要注意と。 さてphppgadminを使ってDBをEUC_JPで作ろうとしたら、上手くいかない。 createdb: database creation failed: ERROR:  encoding EUC_JP does not match locale en_US.UTF-8 見慣れぬエラーですね…。しかもDBは作成してくれない。 何か操作を間違えたのかと、見直すが、特に手順に問題はない。 「ERROR:  encoding EUC_JP does not match locale en_US.UTF-8」でググってみると 、最初に答えが見つかった。 「 名称未設定:Ubuntu12.04LTSのPostgreSQLでEUC_JPのデータベースを作る 」とまんま同じ内容だった。 これによると、 createdb -T template0 -E EUC_JP --locale=C dbname と、localをCで作りなさいということらしい。 試しに、コンソールから試してみると、確かに文句も言われず作成してくれる。 phppgadminでもできるはず  この方法は、postg...

文字コードで…

文字コードではまる wordのデータを整形して、csvにして欲しいと頼まれた。これ自体無茶な話しではあるんだけれど…。リストになっているものを表形式に…。 とりあえず、テキストエディタにコピーして、正規表現で何とか整形する事ができた。 作業は全てUTF8で行っていた。 さて、そのデータをExcelに貼り付けて、カラム数が合っているか等チェックして、CSV形式で保存した。 ここに、失敗があった。word→テキストエディタは意識して文字コードutf8を気にかけていたものの、Excel→CSVの確認を忘れていた。 officeは内部コードをUTFで処理するようになったというのが、変に意識に残っていたのかもしれない。 cp932では表現できない文字コードが含まれていたため、後の処理で引っかかってしまった。 ExcelもCSVで保存する時に、そういったメッセージは出ないしなぁ。 エディタで、特定の文字を置換して切り抜けましたゎ~