  |
はてなキーワード: 文字コードとは
拡張子については、例えば Excel の拡張子が変わったとき一括対応できる、とか？
あとは普通に".txt" で取り扱ってるファイルはどれだ、って時にその定数の参照箇所を見ればもれなく分かるとか、
取り扱うファイルの種別を段階的に変えようってときも、どのファイルは変え終わっててどのファイルはまだ、とかも同じように分かる
あとはあれだ、どのスコープにおける分類なんだって話を明確にする事も出来るだろうな。
とか。
パラメータについては、複数の選択肢から選ぶ奴は enum にしろよ、とは思うが、
文字コードも大体同じような話か。
ここに定義したもの以外は登場しないよ、という保証をする事は出来るわな。
いろんなアプリケーションのメンテ(バグ取りとか細かい機能追加とか)を何度か経験してきた。
主にテキストファイルとかCSVファイルとかExcelファイルとかを入出力するものばかりだったんだが、その大半がファイルの拡張子をグローバル変数化していた。
こんな感じ
const TxtFileExt = ".txt"; const CsvFileExt = ".csv"; const ExelFileExt = ".xlsx";
outFileName = 〇〇 + ×× + "ABCDEFG" + TxtFileExt;
みたいな指定をしなきゃならない。
あと、プログラム言語の標準的なメソッドのあらゆる引数も全部変数で定義されてて、そのまま渡すのは禁止、みたいな規約になってる。
たとえば引数が三種類(true、false(未指定時のデフォルト値)、任意の数値(ただし当該プログラムでは0、10、25以外指定不可))しかないやつはこんな感じ。
const 〇〇ParamTrue = true; const 〇〇ParamFalse = false; const 〇〇ParamIntMin = 0; const 〇〇ParamIntMid = 10; const 〇〇ParamIntMax = 25;
const charCodeSJIS = "Shift_JIS"; const charCodeUtf8 = "UTF-8";
以前関わった改修内容に「××の処理は開始時と終了時にそれぞれUTF-8(BOMなし)形式でログを出力する」みたいなのがあって、普通に文字コード指定する部分に「UTF-8」で直に書いたら、規約に従ってないからとコードレビューで指摘されて差し戻されたんだけど、そもそもこういう規約って何の意味があるの？
この時代の文字コード体系では太陽系統一言語の表示が不可能のようで、おじいちゃんの家にあった古文翻訳ソフトを通してになりますが、うまく書き込めていますでしょうか??
（追記）
お前はUnicodeを舐めている！
あっ！お返事ありがとうございます。レスバ？っていうんでしょうか？
私たちの世界では争いというものが禁止されているので、なんだかとってもウニです！！！あーーおじいちゃん私やったよ昔の人とお話してる！！
あっウニだとわかんないですか？「新鮮」って意味で、ウニっていうのが流行ってるんですよねー
といってもウニって生き物はもう絶滅しちゃってるんですけどね。
ソイプリンにソイ汁をかけたものが味が近いらしくて、それはとっても新鮮で……もうまさにウニ！って感じの味なんです。
すみません脱路しちゃいましたね。あ、脱線というんでしたっけ。
えっと、Unicodeというものは今もあるんですが、地球のみなさんが使っていらっしゃる言語のほうが今はもう誰も喋ってなくて……保護区では何名か暮らしてらっしゃるんみたいなんですけどね。
今日、Pomeara DM250という機械が届いたので、それを使って試し打ちのためにこの文章を書いている。知っている人もいるかと思うが、Pomearaというのは、キングジムという会社が作っている文字入力専用の機械だ。いってみれば昔のワープロだ（昔とはどれぐらいのことかというと、昭和の末ぐらいから平成の初期ぐらいのことをぼんやりと考えている）。
じつはこのPomeraのシリーズを買うのは４台目だ。たしか、一番最初のモデルが出たときに頑張って買ったのを覚えている。あの機械はどうなったのだろうか。まだ処分していないはずだからどこかにあるはずだ。本体のその軽さにときめいたものだが、なんか使いにくくて結局使うのをやめてしまった。あと本体の一部が加水分解してベトベトになっていたような気がする。
２台目はこのDM 250と同じ形式の、キーボード折りたたみ式じゃない、クラムシェル型の最初のモデルだったと思う。書き心地は軽快でかなり気に入っていたが、当時は文章を書くといえば論文がメインだったので、Pomeraがどんなに使いやすくてもcitationを入れる役に立たないという問題があった。で結局iPadのWordを使ってドラフトを書いていたことを覚えている。この機種もまだ捨てていないはずだがどこかにいってしまった。
３台目は、はじめて画面にEインクを採用したモデルだ。はじめて、というかこれ以降Eインクのモデルはなくなってしまったので、最後のモデルでもある。これは夜中に液晶画面を見たくないが、文章は書きたいというニーズがあって買ったものだ。Eインクの画面で文字入力ができることに購入当初は感動したものだが、このモデルには複数の問題があった。まず文字入力の遅延。キーボードを打って画面に文字が表示されるまでに少しの遅延があるのだ。これは我慢しているとある程度慣れてくるが、まったく気にならないレベルには至らなかった。
次にEインクの画面の汚さ。これはEインクに固有の問題だが、画面を定期的にリフレッシュしないと、先に入力した文字の残像が表示されたままになるというか、画面上に変な縞縞がずっと表示されているのだ。これも文字入力に集中していると気にならないが、あるときハッと我に返ると、汚い画面だなあと思ってしまった。
最後に文字コードの問題。このモデルは文字コードがShift JISしか使えない。最近のPomeraにはPomera Linkというアプリで本体からスマートフォンにQRコード経由でテキストデータを転送する機能がある。これを使えば、Pomeraで入力したテキストをスマートフォンやPCで利用できるのだが、文字コードがShift JISだと使い勝手が悪かった。そのままでファイルを開くと文字化けしてしまうケースがけっこうあり、文字コードを変換してから流用するのが大変な手間だった。これが最大の理由で使うのをやめてしまった。
このモデルはまだ手元にある。売ってしまおうと思っていたが、Eインクで文字入力の機械を作るという発想自体は好きなので、取っておこうと思い直している。
４台目のDM 250を思い切って買ったのは、上記の問題がこのモデルでは解決されていると思ったからだ。まず、文字コードはデフォルトがUTF-8なので、今度はストレスなくPomeraから他のデバイスへテキストデータを流用できるようになった。Pomera Linkのアプリも気づけばかなり改善されており、データの読み取りがとてもスムーズになったと感じる。
あとはなんといっても画面がきれいで、文字が読みやすい。初期のモデルに比べるとまったくの別物だと感じる。
それから日本語入力（Atok）がとても改善されたと感じる。思うように変換ができなくて変換候補を探し続ける、ということがほぼなくなった。これは大きな改善ポイントだと思う。
ただしこのモデルにも問題がないわけではない。まず、キーボード。PCのキーボードに比べるとどうしてもひとつひとつのキーが小さいので、タイプミスをしやすい。これは指がこのキーボードの大きさに慣れるまでの問題なのかもしれない。だがキーボードの質感じたいがどこか玩具っぽいという感じには慣れそうにない。この値段にしてみればキーボードの質感はもうちょっとなんとかならなかったのだろうかと思う。あとは打鍵感。音が静かなのはたいへんよいが、このキーボードで何時間も文字を打ち続けると、指の関節が痛くなりそうだ。そこまで長時間この機械で文章を書き続けられればだが。
あとは本体がやっぱり重い。知ったうえで買ったが、このサイズで620gという重さは、手に持つとかなりずっしりくる。手元にあるPanasonicのLet's noteは本体重量が800g台だったと思うが、これより小さく軽いPomeara DM250を手に持った時の方がずっしり感があるのは不思議だ。PCを持ち運ぶよりはましだといえばそうなのかもしれないが、あまり気軽に持ち運ぶことに適した機種ではない。少なくともPCと一緒に持ち運ぶのはつらいので、外出するときにはPCかPomeraか選ぶことになるのだろう。
意気込んで買ったわりにはすぐに使わなくなるものナンバーワンがPomeraだ。なのだが気がつけば４台も買い続けているのは、集中して長い文章を書き続けることに自分が憧憬を持ち続けているせいだと思う。シンプルに、集中したいという願いをPomeraに込めてしまうのだ。で、気づけばPCに戻ったり、スマートフォンにBluetoothキーボードを接続して文章を書いたりしている。直感的に、道具としての納得感があれば自分はPomeraを使い続けるだろう。今回のモデルはそうなるだろうか。気づけば約2400文字を30分程度で打ち込んでいるので、まずまずの生産性なのかもしれない。それが続くかどうか、試してみたいと思う。
ひらがな部分を長押しすると、ひらがな部分だけ選択される気がする。
これって、長押し一発でコピーしたい区間に収まって、とても便利でありがたい機能なんだけど、そもそもどういう機構で成立してるんだろうか。
長押し最中に、付近の一文字ごとに文字コードを読み込んで、選択区間を判定しているんだろうか。
システムエンジニアをしているけどお客の自称大企業のシステム管理経験ありの役職者が要求仕様で意気揚々とExcel方眼紙で資料出してきて頭抱えている。
せめて内容がまともなら良いが書かれている内容も要求仕様からは程遠いメモ書きでこちらから細かい質問を投げては社内で確認して回答貰うメッセンジャーにしかなっていない。これで社内システムの責任者？
ほんとマジでExcel方眼紙は止めろ。餅は餅屋で表計算だけにしろ。馬鹿でExcel方眼紙しか出来ないならPDFに出力してよこせ。どうせファイル名馬鹿みたいに日付とリビジョン付けんだろうな。
ExcelはA4横に綺麗に罫線ひいて見栄えよく書類作るツールじゃないわ。あとcsvをExcelで開くな。Excelに合わせてShift-JISに文字コード要求すんな。システム担当がUTF-8のファイルをExcelで開いて「文字化けしてます。バグですね！」とか言うな。あと郵便番号データ開いて0消してはがきデータ印刷で失敗して焦んな。
こんなこと書くと何故かExcel方眼紙肯定派が出てくるけど一度も納得できる理由を聞いたことが無い。結局馬鹿が色んなツール覚えられないだけでしょ。そういう人はシステムの仕事から離れろよ。Office365もまともに使えない奴がいっちょ前にシステムエンジニアに意見言うな。レガシーシステムの改変に文句言うな。工数に口出すな。っていうかこっちが言ってること大半理解せず金の時だけ発言すんな。あとアジャイルなんでそんなに好き？アジャイルの前に自社の業務理解しろ。そのうえでExcel方眼紙やめろ。
暗黙的にJSTとして時間を使ったせいでUTCで作った場所で盛大にバグる
応急処置でバグったところを+9とかやってしまうと、それ以降に逆に誰も気付かずに更に影響範囲が拡がったりする
海外展開しようとしたときにバグに気付くがどうしようもなくなって途方にくれて海外だけは別アプリになったりする
UNIXTIMEを使えば楽なんだけれど、そうすると生データぱっと見で時間を判別できないので困ることも多い
素直にUTCでISO8601が良い
とりあえずUTF-8にしとけば大丈夫、ってことで実装を進めた結果、Mac/Winでハマる
他にもBOMでハマったりして、むしろSJISの方が良かったんじゃ無いか、とか言い出す
DBが統一的になっている場合はまだ後からどうにかできるが、変なところでキャッシュされてたりすると凄い困ることになる
MySQLなりPostgreSQLなりでUTF-8を正しく扱う方法はいろんな記事があるのでちゃんと読んでおけば問題無い
とかよく分からないことを言い出して価格を浮動小数にしてしまう
確かに米国なら$2.43みたいな感じで価格を使ったりするし、むしろ小数点以下が無い通貨の方が珍しいのだけれど
丸め誤差を考えないで作ってしまってバグが見つかりめちゃくちゃ揉める
