投稿

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

キーボード修理

イメージ
前回 調子が悪くなったと書きましたが、部品が手配できて時間が取れたので直しました。 茶軸のスイッチを購入 Cherryの茶軸は 10個で1,399- ということで購入。 本当は1個で充分なんだけど、仕方なく残りは予備部品として保管。 作業手順 キーボードの裏側ネジを3箇所外します。 左右と中央の丸シールの下。 左右はパッドを貼っているので、少しめくって外します。 (あとで綺麗に戻るので心配なしです) ケーブルが出ている方は、スッと外れ、手前(下側)は、内部に爪が有るので、ピックやカード、マイナスドライバなどで少し隙間を開けるようにして広げれば外れます。 自分は親指の爪で空きました。 今回は「E」が調子悪いので、該当のピン2箇所をハンダ吸いで綺麗に取り除いて、裏側から引き抜いて完了。 基板にしっかりとどのキーかがプリントされているので分かりやすいですねぇ 入手した新品の茶軸を差し込んでハンダ付けします。 この時点で動作確認が可能になるので、直したキーとその周辺が正しく入力できるのをチェック。 問題なく、無事に動作しました。 最後にカバーを取り付けて完了! 残ったのは9個の茶軸…。 今回の費用 Cherryの茶軸10個セット :1,399- キーキャップ引き抜き工具 : 475-  ちなみに10個セットには、簡易引き抜きがついてきますが、ちゃんとしたもののほうが楽に作業できます。(昔買ったのに、どこかに行ってしまったので再購入)  ということで、1900円ほどで完治しました。  手間賃考えると買ったほうが安いかも(笑)

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で保存する時に、そういったメッセージは出ないしなぁ。 エディタで、特定の文字を置換して切り抜けましたゎ~