Webサービスのフォームに住所を入力するとき、丁目や番地などを入れる欄について、数字やハイフンを全角で書かなければいけない「全角縛り」をやっているフォームをよく見ます。半角文字を入力してしまってエラーになったり、咄嗟に変換方法を思い出せなかったり、全角と半角の見分けが付きづらかったり、「全角縛り」であることが明示されていなかったり、「ハイフン」としてどの文字を使うべきかわからなかったり……と、鬱陶しさを感じることが多くあります。 「住所は全角のみ」（数字やハイフンも絶対に半角を受け付けない）という仕様がどういう経緯で生まれて、どう広まっていったのかが気になってる。いま存在しているのは過去の仕様や慣習の踏襲として理解できても、そもそもなぜそれらが生まれたのかが理解できない。 https://t.co/ZLz0Pw9GOK — ymrl (@ymrl) July 29, 2024 これについて
NFCではそのまま「パ」として表されますが、NFDでは「ハ」（基底文字）と「゜」（結合文字）の組み合わせとしての「パ(UTF-8でe3 83 8f e3 82 9a)」（合成文字）で表されます。試しにNFDで正規化された「パ(e3 83 8f e3 82 9a)」を任意のテキストエリアに貼り付けて削除してみると、半濁音のみが取れて「ハ」のみになると思います。 このように文字列の正規化形式が異なる場合、単純な比較演算子での評価は困難であり、文字列によっては想定外の挙動を引き起こす可能性があります。 特にMacファイルシステムではNFDを正規化方式と採用しているため、NFC/NFD問題が度々引き起こされています。先日(2023年03月27日)リリースされた「macOS 13.3 Ventura (22E252)」では、ファイル名に濁音や半濁音が含まれるファイルがFinderから開けなくなる
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 中国では、2023年8月1日に強制力のある国家標準規格「GB 18030-2022」（信息技術中文編碼字符集）が施行される。中国で「強制」という言葉が出ると「また締め付けが強化される」と反射的に考えてしまうかもしれないが、これは文字コードの標準規格を新たに導入するという話だ。珍しい名字などに使われ、既存の文字コードに未登録の漢字に対応しようというものになる。 中国の面積は日本の国土の約25倍で、約14億人の人口を擁している。一部の地域限定で使われている漢字や、少数民族の固有名詞でのみ用いられている漢字もある。文字コードに含まれない漢字を使っている人は約6000万人もいるそうだ。例えば、山東省青島市郊外にシュイユー村という地元ではまあまあ
電子メール、ネットワーク機器集中管理、異常検知、分散処理、クラウド基盤などのシステム開発に従事。古代Rubyist。 CLI や TUI なアプリケーションを使っていると、端末の画面が崩れてしまうことがよくあります。 たとえば、こんな TUI が、 環境によってはこんな感じで崩れます。 スクロールなどをしながらしばらく使っているとさらにどんどん崩れていきます。 こうなってしまった場合、とりあえず Ctrl-l で画面を再描画することで、大抵はなんとか読める程度にリセットできますので、ことあるごとに Ctrl-l を連打することになります。 ですが、どうしようもないケースもままあります。 例えば、私の場合は以下のようなシチュエーションで困ります。 w3m でテーブルなどを表示するとレンダリングが崩れる less でログの閲覧の際に表示されるべき文字が表示されず見落としが発生する Wander
物語の始まり 事の発端は納品後。 先方からメッセージが届きました。 クライアント様「このファイルの文字コードがShift_JISになっておりますので、UTF-8で再納品をお願いいたします。」 拙者（あれ…UTF-8にしてたと思うんだけどな） 拙者「確認いたします。」 文字コードを確認する 本案件はいわゆる更新案件で、今回の納品時に言われていたのは、「文字コードがUTF-8ではないものは変換して納品してくれ」ということ。 そして、ご指摘いただいたのは、今回の更新案件で中身はいじらなかったJavaScriptファイル。 本来ならば納品するファイルではないのですが、文字コード変換という要件があったため、納品ファイルとして加えられたものでした。 一括で文字コードを変えたので作業漏れかなぁと思っていました。 ファイルの中身は記事用にかなり適当につくったものですが、まあだいたいこんな感じです。
そもそも、波ダッシュと、全角チルダって? 波ダッシュ 〜 0x8160(Shift_JIS) 0x301C(UTF-8) WAVE DASH(ユニコードポイント : U+301C) 日本語の文字 範囲を表す : 大阪 〜 東京 など 省略記号 : 〜 からの 全角チルダ ～ Shift_JIS には無い 0xFF5E(UTF-8) FULLWIDTH TILDE(ユニコードポイント : U+FF5E) いろんな意味がある文字 アルファベットの上につけて、鼻音を表す : ñ 数学記号 (ほぼ等しいの意味) ホームディレクトリを表す記号 : ~/download Unicode 側での波ダッシュ割り当てミス Shift_JISの波ダッシュ を Unicode に割り当てるときに、 波ダッシュの形を間違えて、"下がって上がる" ように表記してしまった ※ unicode 8.0 で修正されました
文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！ 文字コードには、どのような種類があり、それぞれどのような意味を持つのか、といった、文字コードの基本的な概念、従来の文字コードを紹介し、現在のUnicodeの構成を概説し、プログラミングにおいて注意すべき箇所をいくつか取り上げます。 ソフトウェア開発に携わる方の多くは、何らかの形で文字コードに触れることがあるでしょう。文字や記号をコンピュータ上でデータとして扱うには、文字コードの知識が必要不可欠です。 本稿では、書籍『プログラマのための文字コード技術入門』の著者である矢野啓介さんが、知っておきたい基礎知識を分かりやすく解説します。 文字コードとは？ Unicode以前の文字コード Unicodeとその主な符号化形式 UTF-16 UTF-32 UTF-8 Webで文字コードを指定する仕組み
hGetContents: invalid argument (invalid byte sequence) hPutChar: invalid argument (invalid character) commitBuffer: invalid argument (invalid character) Oh no! Bad news: something is wrong. Good news: it is not necessarily an issue with your code, it can be one of the libraries or build tools that you depend on. Yes, really. Haskell tools you are using every day have a problem that can cause this
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
srad.jp こういうニュースがあった。世界のWebサイトの90％がutf-8を使用している、という。 昔、シフトJISでエンコードされたPHPファイルを編集させられた時、「表示」が表示できず（文字通りの意味である）バイナリリテラルを書いていたことを思い出す。 文字コード断絶の歴史を乗り越え、世界はようやくUnicodeの元に集結したのである。 日本の上場企業のcharset指定状況 さて、美しいニッポンである我が国はどうであろうか、 www.pathfindergate.com 私は上記のサイトより早速日本の上場企業のHPのリストをダウンロードさせていただくと、さらっとクローラーを書いてHTTPヘッダのcharsetとmetaタグのcharset、ついでにDOCTYPE宣言を集計することにした。 というのは実は嘘で、去年の12月頃にクローラーは出来上がっていたのだ。この記事が出る前にと
さよならレガシーエンコーディング。 文字エンコーディング宣言が存在するかどうかにかかわらず、文書のエンコードに使用される実際の文字エンコーディングはUTF-8でなければならない。 4.2.5.5 文書の文字エンコーディングを指定する - HTML Standard 日本語訳 Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/htmlにより、HTMLで使用できるエンコーディングはUTF-8のみとなりました。これにより、古いHTMLでは許容されていた、Shift_JIS、ISO-2022-JP、EUC-JP、UTF16LEといった文字エンコーディングは適合するHTMLではなくなりました。すでにNu Html CheckerでUTF-8以外の文字エンコー
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
Home Product Sakti123 : Barudak Slot Judi Online Bet Receh Depo 25k Di Zeus X1000 Sakti123 : Barudak Slot Judi Online Bet Receh Depo 25k Di Zeus X1000 Situs judi online dengan permainan bet receh depo 25k paling gacor hanya di SAKTI123. Banyak manfaat yang pasti kalian dapatkan bermain di Sakti123, contohnya mendapatkan uang kaget dengan nominal sangat banyak anda hanya perlu merogoh kocek sebesar
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
MySQL 5.5.11 unicode_ci で同一視される文字 Unicode 002000A02000200120022003200420052006200720082009200A202F205F3000 Character Unicode 0021FE57FF01 Character !﹗！ Unicode 0022FF02 Character "＂ Unicode 0023FE5FFF03 Character #﹟＃ Unicode 0024FE69FF04 Character $﹩＄ Unicode 0025FE6AFF05 Character %﹪％ Unicode 0026FE60FF06 Character &﹠＆ Unicode 0027FF07 Character '＇ Unicode 0028207D208DFE35FE59FF08 Character (⁽₍︵﹙
JIS X 0213の第3・4水準漢字の一部が4バイトとなる。マイナーな文字ですね。 例えば、第1・2水準漢字だけ対応していればよい案件などでは考慮しなくてよいでしょう。 MySQLではこのUTF-8で4バイトになる文字を扱えないのだとか（MySQL6なら対応したそうだ）。 数値文字参照で全部書いてみた。 （パッチのあたっていないWindowsXPなどでは表示されないです。） 𠀋 𡈽 𡌛 𡑮 𡢽 𠮟 𡚴 𡸴 𣇄 𣗄 𣜿 𣝣 𣳾 𤟱 𥒎 𥔎 𥝱 𥧄 𥶡 𦫿 𦹀 𧃴 𧚄 𨉷 𨏍 𪆐 𠂉 𠂢 𠂤 𠆢 𠈓 𠌫 𠎁 𠍱 𠏹 𠑊 𠔉 𠗖 𠘨 𠝏 𠠇 𠠺 𠢹 𠥼 𠦝 𠫓 𠬝 𠵅 𠷡 𠺕 𠹭 𠹤 𠽟 𡈁 𡉕 𡉻 𡉴 𡋤 𡋗 𡋽 𡌶 𡍄 𡏄 𡑭 𡗗 𦰩 𡙇 𡜆 𡝂 𡧃
Ruby 1.9.3でbom付きUTF8ファイルを出力する方法 使用しているrubyのバージョンはRuby 1.9.3p194です。 ソースコードは下記になります。 require 'kconv' io = open("出力したいファイル名.csv","w") doc = File.read("読みたいファイル名") io.puts Kconv.toutf8(doc) io.puts doc io.close これを実行するとwindows上のExcellで開くと日本語が文字化けしてしまいますが、 cotEditorで"UTF-8のときBOMも保存"のチェックボックスを入れて保存し直すと、 文字化けがなおります。"UTF-8のときBOMも保存"をruby上で処理するにはどうすればよろしいでしょうか？よろしくお願いします。 web上でいろいろ解決法を探しましたが、ruby 1.8がほとんどで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
