「パスポートは本人確認に使えない」「身分証ではなくなった」は大嘘

X(旧Twitter)を見ていると「パスポートから住所欄が消えて本人確認に使えなくなったという投稿を目にすることがある。

こちらの投稿に寄せられた反応を見ていても同様の勘違いをしている人が多い。

 

また、Web検索すると司法書士を名乗る人物までもが同じような記事を書いている。

実は、2020年2月4日以降に発行されたパスポートには、「住所」が記載されていません。

そして、「住所」が記載されないパスポートは、身分証明書とは認められないことになってしまいました。

「パスポート」は、身分証明書ではなくなりました

これをそのまま鵜吞みにすると「もうパスポートは身分証として使えなくなったんだな」と勘違いすることだろう。

 

パスポートで本人確認できないならパスポートの役目は?

しかしちょっと待ってほしい。

もしパスポートが身分証明に使えないのであれば、もはやパスポート自身の意味を成さないではないか。

というか海外渡航時の出国審査や帰国時の入国審査でパスポートを提示して「本人確認」をしているではないか。

よく考えてほしい。パスポートには「顔写真」「本名」「生年月日」「性別」といった本人を特定できる情報が記載されている。少なくとも顔写真のない保険証よりは身分証としての要件を満たしているではないか。

「住所欄がなくなったパスポートは身分証明に使えない」は本当なのか?(結論から言うと大嘘です)

[MySQL] MariaDB 文字コードの不一致によりINDEX検索が激遅に

前回までの記事でMariaDBをいろいろと弄っていた所、INDEX作成済み項目でJOINやWHEREをしているにもかかわらず結果取得にめちゃくちゃ時間がかかるケースがあった。

SQLのイメージはこんな感じ。

select * from TABLE1
LEFT JOIN TABLE2 ON TABLE1.KEYCOL1 = TABLE2.KEYCOL1 AND TABLE1.KEYCOL2 = TABLE2.KEYCOL2
WHERE EXISTS (SELECT 1 FROM TABLE3 WHERE KEYCOL1 = TABLE1.KEYCOL1 AND KEYCOL2 = TABLE1.KEYCOL2)

各テーブルのデータ件数がかなり多いため、時間がかかるのは仕方がないのかな...と当初は思っていた。

 

EXPLAINで調査

SQL速度に困ったらまず実行計画を確認。

実行しようとしているSQL文の頭に「EXPLAIN」を追加すると、SQL文の実行計画を取得することができる。

Xiaomi Power Bank 10000mAh 22.5W Liteを買った(レビュー)

愛用していたモバイルバッテリーが壊れた。

20000mAhの大容量と60W充電対応で安心感の塊だった反面、持ち歩くには微妙に重くて使いにくかったので、これを機に10000mAhのものに買い替えることに。

初めはAnkerを候補にしていたが、最終的にXiaomiのモバイルバッテリーを購入した。

 

候補① Anker Power Bank (10000mAh, 22.5W)

まず候補に挙がったのがAnker Power Bank (10000mAh, 22.5W)

001.png

コンパクトでストラップケーブルつき。22.5W対応で200gと軽量、スペック的に申し分なしで万人にお勧めできる一品。

Amazon価格3500円。

 

候補② Xiaomi 22.5W Power Bank 10000mAh (Integrated Cable)

もう一つの候補がXiaomi 22.5W Power Bank 10000mAh (Integrated Cable)

51mK+kCehmL._AC_SY450_.jpg

こちらはケーブル内蔵モデル。22.5W対応で213gと①とほぼ同性能でコスパ良。

ただし厚みが26.9mmある。①の厚み16mmと比べて11mmも厚く、スマホに重ねて充電しながら持つにはちょっと厳しい。

Amazon価格2200円。

 

候補③ Xiaomi Power Bank 10000mAh 22.5W Lite

そして最後の候補がXiaomi Power Bank 10000mAh 22.5W Lite

003.jpg

22.5W対応で214gと①②とほぼ同性能で、コスパは3つの中で一番(Amazon価格1660円)。

他と比べると寸法が縦長だけど厚さが15mmなのでスマホに重ねて持つのも問題なさそう。

[AWS] MariaDB+unixODBCでCONNECT接続時に文字化けする問題

前々回前回の記事でMariaDBからOracleやSQL Serverのデータを取得するため、unixODBCとCONNECTストレージエンジンを使って環境を構築した。

一部動作が怪しい所はあるものの概ね問題なく動いているのだが、一つ困ったこととして「エラーメッセージが文字化けする」という問題がある。

 

エラーメッセージ文字化け問題(Oracle編)

Oracleのビューに対してCONNECTでCREATE TABLEし、そのテーブルに対して編集しようとした(つまりビューを編集しようとした)らこのようなエラーメッセージが出た。

#HY000Got error 122 'Remote SQLExecDirect: [Oracle][ODBC][Ora]ORA-01732: ã\0081"ã\0081®ãƒ"ューã\0081§ã\0081¯ãƒ‡ãƒ¼ã‚¿æ"\008D作ã\0081Œç„¡åŠ¹ã\0081§ã\0081™
ヘルãƒ--: https://docs.orac' from CONNECT

↑ビューは編集できないのは分かるし、ORA-xxxxxの番号があるのでWeb検索すればエラー内容は理解できるんだけど、見事に文字化けしてる...。

まず調べてみた所、OracleのエラーメッセージはNLS_LANGに依存するとのこと。

確かに前々回の記事でSQL取得結果(日本語文字列)が「?」に文字化けしてしまうことから、環境変数に下記を設定した。

NLS_LANG=JAPANESE_JAPAN.JA16SJISTILDE

これによりエラーメッセージも日本語で表示されるようになったわけだ。

そこまではいいのだが、肝心の文字化けしてしまう原因については、どうやらUnixODBCがコード変換時に誤ってISO-8859-1でエンコードしてしまっているらしい。うーんポンコツ。困った。

[AWS] MariaDBからSQL ServerにCONNECTエンジンでDBリンクを張る方法

前回の記事ではMariaDBから同一ネットワーク上にあるOracleにCONNECTストレージエンジンを使って接続してみた。

今回はその続きで、MariaDBからSQL Serverにリンクしてみた。

 

参考記事

今回はこちらの記事を参考にした。

【MySQL】MariaDB使用connect引擎直接访问SQLServer数据库 - abce - 博客园

使用するODBC Driver for SQL Serverのバージョンが違うことを除けば、ほぼこの手順のとおりで完了する。

その他の細かい設定などは前の記事で実施済みなので割愛する。