hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
JPEG 2000 符号化手順
プリシンクトのサイズは2のべき乗の整数でなければならず、最大でのサイズを取ることができる。同一番号のプリシンクトは画像の部分領域を構成するDWT係数と考えることができ、後述するパケットおよびプログレッション順序の構成要素となる。
Part 1では、スカラー量子化のみがサポートされている。Part 2ではTCQ(Trellis Coded Quantization)と呼ばれる量子化方法も使用可能である。
サブバンドのDWT変換係数を、ステップサイズをとおくと、スカラー量子化後の変換係数は次式で表される。
ロスレスモードでは、量子化による情報の損失は許されないため、で固定である。ロッシーモードにおけるステップサイズは、各DWTレベル、各サブバンドごとに異なる値を指定できる。
画像中の特定の領域を興味領域(ROI)として、他の領域（背景領域）と比べて符号化の優先度を高めるための処理である。興味領域内のDWT係数をMAXSHIFTと呼ばれる方法でシフトアップすることで、符号化の優先度を高めることができる。サブバンドのDWT係数のダイナミックレンジを(bit)とすると、MAXSHIFT法によるシフト量は次式で表される。
MAXSHIFT法によるROI機能では、優先度の調節は不可能であるものの、デコーダに際してROIの形状に関する情報が不要という特長がある。
JPEG 2000 符号化手順
下図に示すように、EBCOTでは、各サブバンドは、コードブロックと呼ばれる矩形領域に分割される。コードブロックはEBCOTにおける最小符号化単位であり、各コードブロックはそれぞれ独立に符号化可能である。
コードブロックのサイズは、水平・垂直方向それぞれのサイズが4以上1024以下、面積が4096以下の条件を満たす2のべき乗の整数から自由に選ぶことができる。一般に64x64や、32x32のサイズが用いられることが多い。メインヘッダに記録されるコードブロックのサイズは一つであるが、実際のコードブロックサイズは画像サイズやDWTレベル数、プリシンクトサイズなどの様々なパラメータによって決定され、かならずしも全てのコードブロックで同一とはならない。コードブロック内の量子化されたDWT係数は、符号絶対値表現（符号付数値表現）で表される2進数として表現され、以後の処理はビットプレーンごとに進められる。
上図は、EBCOTにおけるビットプレーンの概念を示している。なお、図中のは、各コードブロックごとに計測されたゼロビットプレーン数である。ゼロビットプレーンとは、符号ビットを除く振幅係数において、プレーン内の係数ビットがすべて0であるプレーンが最上位ビットから連続する数である。このゼロビットプレーンに対する処理はスキップされ、その数のみが後述するパケットヘッダに記録される。
JPEG 2000 符号化手順
各コードブロックは、ビットプレーンに分割される。各ビットプレーンは、最上位ビットに位置するプレーンから順に最下位ビットプレーン至るまで処理される。各ビットプレーン内のDWT係数ビットは、周辺係数ビットの状態に応じて、最大3つの符号化パスに分割される。各符号化パスは、Significance Propagation(SP), Magnitude Refinement(MR), Cleanup(CU)と呼ばれる。各係数ビットは、必ずこれらの符号化パスのいずれかに一度だけ属する。
各ビットプレーンのスキャンパターンを下図に示す。スキャンの際には係数ビットからなるstripeという単位が存在し、各stripe内は上から下へと順にスキャンされる。
最上位ビットプレーンをスキャンする際には、上位のビットプレーンに関する情報が得られないため、必ずCleanupパスとして処理される。最上位のすぐ次のビットプレーンからは、SP→MR→CUの順に属する符号化パスが決定される。
符号化パスの決定には、現在の係数ビットと、その周辺8近傍の係数ビットの状態が用いられる。係数ビットは"1"か"0"の値をとるが、それぞれ"有意"および"非有意"状態とみなされる。
JPEG 2000 符号化手順
SPパスは自身が非有意かつ周辺にすでに有意となった係数ビット存在する係数ビットが属する。このとき、現在の係数ビットは非有意から有意の状態へと更新される。
MRパスは、上位ビットプレーンですでに有意となっている係数ビットが属する。
CUパスは、SPパスにもMRパスにも属さない係数ビットが属する。
なお、それぞれの符号化パスは、さらにその周辺係数ビットの有意状態の情報に、コンテクスト(CX)と呼ばれるラベルが付けられる。規格で規定されたコンテクストの数は19である。
SP、MR、CUの各符号化パスに属する係数ビットは、そのコンテクストCXの値と共に2値算術符号化器であるMQ-coderへと送られ、算術符号化される。MQ-coderは、各コンテクストごとに独立した確率遷移テーブルを持つ。この確率遷移テーブルのエントリ数は46である。
JPEG 2000 符号化手順
MQ-coderは、係数ビットの正負を表す符号ビットと、値ビットから計算されるディシジョンビットDと、CXを入力として、出力ビットを計算する。符号ビットが入力されるのは、初めて有意となる係数ビットが符号化されるときに限られる。MQ-coder内には5つのレジスタが存在し、そのうちの出力ビットを蓄えているレジスタ上でバイト境界に達すると、バイトストリームとして1バイトが新たに出力される。この際、デコーダにとって重要なマーカとなるFF90h〜の値がバイトストリーム内に出現するのを回避するため、直前のバイト出力がFFhであった場合には、レジスタ内における次のバイト境界の先頭1ビットをスキップし、データを書き込まないようにする処理が追加される。これはビットスタッフィングと呼ばれる。
コードブロック内の全ての係数ビットを符号化した後でも、通常、MQ-coder内のレジスタにはバイト境界に満たない符号語が残っているため、終端処理によって全ての係数ビットをデコードするのに必要な長さの符号語を出力する。
MQ-coderには、符号化モードとして、以下の6つのモードがオプションとして用意されている。
JPEG 2000 符号化手順
EBCOTでは、MQ符号化後のバイトストリームに対して、符号化パスを最小単位として符号切り捨てを行うことで圧縮後のレート歪最適化(PCRD-opt)を行うことが可能である。レート制御については、エンコーダにおける処理であるため規定された技術はないが、一般的に以下の処理によって実現されることが多い。
コードブロック内の切り捨て点として、符号化パスを考える。までのデータ量を、そのパスでバイトストリームを切り捨てることで増加する歪みの推定量をとおく。所望のビットレートをとして、の条件のもと、を最小化するを各コードブロックごとに決定する。この一連の手順はラグランジュの未定乗数法を用いることで実現できる。
また、上述のレート制御処理は、コードストリームのプログレッション順序の構成要素の一つであるレイヤを形成するためにも用いられる。レイヤとは、SNR(Signal-to-Noise Ratio, SNR)スケーラビリティを実現するための概念である。
レイヤを用いたSNRスケーラビリティとは。最上位レイヤから最下位レイヤにデコード処理が進むにしたがって、段階的にデコード画像の画質が向上する（SNRが向上する）機能を意味する。レート制御処理によって、各コードブロックの符号化パスがどの程度画質に寄与するかが予測できるため、この情報を用いてレイヤを生成する。具体的には、各コードブロックにおいて、どのレイヤに符号化パスがいくつ属するかをレート制御によって得られる情報をもとに決定する。このレイヤごとのパス数は、パケットヘッダ生成アルゴリズムによってパケットヘッダに記録される。
MQ-coderからの出力バイトストリームは、プリシンクトを単位とした「パケット」として整列される。各パケットには、パケットヘッダとして以下の情報が付加される。
各パケットヘッダの先頭1bitは、そのパケットのデータが空である場合には0、それ以外には1となるフラグである。
2. 3.については、タグツリーと呼ばれるデータ構造によって符号化される。
生成されたパケットヘッダは、各パケットの先頭あるいは、メインヘッダ内、あるいはタイルパートヘッダ内のいずれか一つの場所に格納される。
各パケットは、指定されたプログレッション順序に応じて並べ替えられる。指定可能なプログレッション順序は、
の5つである。
JPEG 2000 動向
デジタルシネマ、公文書や芸術作品のアーカイブ、医療用画像の圧縮、業務用途の画像配信システム、監視カメラ、PDFファイル内の画像フォーマットなどでは既に広く使われている。高い圧縮効率や豊富な機能を備えていることから、発表当初はコンシューマ向け分野でも急激に普及することが期待されたが、JPEGと比較すると計算負荷が高くバッテリー消費が激しいことや、またスループットを稼げず連写速度の向上が難しいことから、デジタルカメラ用途での採用は進んでいない。
Part 15(High Throughput JPEG 2000)では、EBCOTの弱点であった計算負荷の高さとそれに起因する低スループットおよびバッテリー消費量の問題を解決するべく、新しいブロック符号化アルゴリズムが標準化された。若干の圧縮効率の低下と引き換えに、10倍以上のスループット向上が達成されている。また、決して並列化向きのアルゴリズムではなかったEBCOTとは異なり、GPUなどによる並列化を強く意識したアルゴリズムとなっており、並列化によるスループットのさらなる向上が期待できる。
郵便記号
郵便記号（ゆうびんきごう、〒）または郵便マーク（ゆうびんマーク）は、日本の郵便事業・郵便局の記号・シンボルマーク。明治20年（1887年）に逓信省が徽章として考案・発表し、後身の郵政省・郵政事業庁・日本郵政公社へと引き継がれ、民営化後の日本郵政グループのブランドマークとなっている。
郵便（日本郵政グループ）以外では、旧郵政省の電気通信関連部門を引き継いだ総務省の技術基準適合マークとして使用されている。過去には旧通産省の電気用品取締法の合格マークとしても使用された。→後述
郵便マーク（ゆうびんマーク）と呼ばれることが多いが、日本産業規格（JIS）において「〒」は「郵便記号」（ゆうびんきごう）と呼称されており、「郵便マーク」は「〠」（顔郵便マーク）を指す。Unicode のコードポイントは、郵便記号（〒）が U+3012、郵便マーク（〠）が U+3020 である。
郵便記号（〒）は日本国独自のものであり、日本国外では郵便記号として利用することはできない。また、郵便番号を表示するときにもしばしば用いられ、はがきや封筒に郵便番号と併せて郵便記号も書いているケースがあるが、日本郵便が定めている「内国郵便約款」では不可となっている。
郵便記号 丸に一引き（明治17年6月第15号布達郵便徽章）
明治4年4月20日（1871年6月7日）に日本の郵便事業が始まったが、当初は特に定められた徽章はなく、「郵便」の文字だけであった。明治10年（1877年）頃から、大きな赤丸（いわゆる「日の丸」的な徽章）に太い横線を重ねた赤い「丸に一引き」が郵便マークとして用いられ始めたとされている。「丸に一引き」は郵便配達員の制帽・制服・郵便旗などに記されており、明治17年（1884年）6月23日太政官布達第15号により、正式に「郵便徽章」と定められた。その後、後述のように明治20年（1887年）に「〒」が逓信省の徽章に定められた際、この郵便徽章は自然消滅に属するとされ、新調するまでの間は、そのまま使用できるものとした。
なお、郵便等の所管官庁として逓信省が創設されるのは、その翌年、明治18年（1885年）である。
郵便記号 郵便マークの日と誕生までのいきさつ
2月8日は郵便マークの日となっている。
明治20年（1887年）2月8日、当時の逓信省は「今より (T) 字形を以って本省全般の徽章とす」と告示（明治20年2月8日逓信省告示第11号）した。ところが、2月14日に「〒」に変更し、2月19日の官報で「実は「〒」の誤りだった」ということで訂正されてしまった。
この経緯に関しては、諸説あることで知られている。
どれが有力か、ということはないが、一般には 2. のほうが多く語られている。また、「Tの上に棒を一本加える」というアイディアは、初代逓信大臣であった榎本武揚が出したとも言われている。
なお、「T」マークの由来にも諸説あり、漢字の「丁」（てい）を図案化したもので、これは「甲乙丙丁」の「丁」が逓信（ていしん）の「てい」の読みに合うからだという説や、「逓信」をローマ字で表した「Teishin」の頭文字だという説もある。
いずれにせよ、これ以降は「〒」の徽章が、郵便配達員が身につける帽子（丸笠）の正面や制服上着の袖口、郵便旗、あるいは書状集め箱（現在の郵便ポスト）につけられるようになった。また、当初は上述の「丸に一引き」や封筒をモチーフにしていた「郵便局」を示す地図記号も、「〒」を丸で囲んだものと定められた。
なお、郵便記号の縦横比は、昭和25年（1950年）の郵政省告示第35号により幅のほうが広く高さが低いのが正しい記号である。
郵便記号 顔郵便マーク
顔郵便マーク（〠）は「ナンバーくん」という名前で、かつては切手にも登場したことがある。しかし、1996年に新キャラクターの「ポストン」が登場したことから郵政の場では公式には使われなくなった。さらに民営化により、日本郵政グループでは「撤去が望ましい」扱いとされた。なお、ポストンは引き続き使用可能となっている。
郵便記号 郵便以外の〒マーク
郵便以外で利用される〒マークとして、次のようなものが存在する。
家庭用電気製品やその他の電気器具について、電気用品取締法に基づく試験に合格した証印として、逆三角形（甲種）や円形（乙種）の中に「〒」を描いたマークが使われていた。その由来はかつて「逓信省電気試験所」が電気製品に関する試験を行っていたためとされている。なお、逓信省電気試験所は商工省に移管の後、電気試験業務は日本電気計器検定所（経済産業省所管）に引き継がれている。
なお、2001年（平成13年）に電気用品取締法が電気用品安全法に改称され、同義のマークもひし形や円形の中に「PSE」を描いたものに変更され、これ以降に製造された電気製品に「〒」は使われていない。
1985年（昭和60年）より電話機やファックスなどの端末機器について電気通信事業法の技術基準適合認定として、
また、1987年（昭和62年）より携帯電話端末やPHS端末などの無線機器について電波法の技術基準適合証明として、
「〒」を用いた円形マークを用いていたが、1991年（平成3年）に統一され、1995年（平成7年）より稲妻のデザインと「〒」を組み合わせた円形の技適マークが使用されている。
なお、2010年（平成22年）からは、印刷やラベル貼付以外にディスプレイ表示させることも認められた。
ルドヴィコ・ザメンホフ
ラザーロ・ルドヴィコ・ザメンホフ（エスペラント: Lazaro Ludoviko Zamenhof 、ポーランド語: Ludwik Łazarz Zamenhof 1859年12月15日 - 1917年4月14日）は、ユダヤ系ポーランド人で、職業としては眼科医。人工言語エスペラントの創案者。
本名はエリエゼル・レヴィ・ザメンホフ（ヘブライ語：אֱלִיעֶזֶר לֵוִי זאַמענהאָף 、ドイツ語転写：Eliezer Lewi Samenhof ）。ファーストネームは、少年時代はエリエゼルのイディッシュ語形レイゼル（Lejzer）とそのロシア語形ラーザリもしくはラーザリ・マルコヴィチ（Лазарь (Маркович)）を併用し、大学以降はレヴィの欧州語代用名ルードヴィク（Ludwik）とリュードヴィク（Людвик）、そして1901年にエスペラントでルドヴィーコ（Ludoviko）と名乗り、"Dr. L. L. Zamenhof"と署名するようになった（Lを重ねたのは弟のレオン・ザメンホフ（1875年-1934年）も医師であったため）。
弟のフェリクス・ザメンホフ（1868年-1933年）もエスペランティストとなり、"FEZ"の筆名で兄を助けた。
ルドヴィコ・ザメンホフ 来歴
ザメンホフは1859年にポーランド北東部のビャウィストクで生まれた。当時、ポーランドは帝政ロシア領で、町の人々は4つの主な民族（ロシア人、ポーランド人、ドイツ人、イディッシュ語を話す大勢のユダヤ人）のグループに分断されていた。ザメンホフはグループの間に起こる不和に悲嘆し、また憤りを覚えていた。彼は憎しみや偏見の主な原因が、民族的・言語的な基盤の異なる人々の間で中立的なコミュニケーションの道具として働くべき共通の言語がないことから起こる相互の不理解にあると考えた。
ワルシャワの中等学校に通いながら、ザメンホフはある種の国際語を作ろうと試みた。それは文法が非常に豊富な一方で、大変複雑なものでもあった。ザメンホフは（ドイツ語、フランス語、ラテン語、ギリシャ語と共に）英語を学んだ際に、国際補助語には動詞の人称変化は必要ではなく、比較的簡単な文法を持ちながら、語の新しい形を作るのに接頭辞・接尾辞を幅広く用いるようなものでなくてはならない、という構想を固める。
1878年までにザメンホフの「リングヴェ・ウニヴェルサーラ」（普遍語）はほとんど完成しかけていたが、若すぎたために著書を出版することができなかった。卒業後すぐにザメンホフは医学を、最初はモスクワで、次にワルシャワで学び始める。1885年には大学を卒業し、眼科医として開業する。患者を治療する傍ら、ザメンホフは国際語の計画を進める。
ルドヴィコ・ザメンホフ 来歴
ザメンホフは国際語を述べた著書を出版すべく、2年にわたって基金を設立しようと試みるが、後に妻となる女性クララ・ジルベルニクの父親から経済的な援助を受けることで、その必要はなくなった。1887年には "Doktoro Esperanto. Lingvo internacia. Antaŭparolo kaj plena lernolibro"（「エスペラント（希望する人）博士、国際語、序文と完全なテキスト」）と題された著書が出版されることになる。ザメンホフにとってこの言語は単なるコミュニケーションの道具ではなく、異なる人々や文化の平和的な共存という自らの理念を広げる手段でもあった。
ザメンホフは1917年にワルシャワで心臓病のために亡くなった。
ザメンホフは妻クララとの間に一男二女（アダム、ゾフィア、リディア）に恵まれたが、いずれもホロコーストのために命を落としている（アダムの息子は死体のふりをしたため無事に生還できた）。特に二女のリディアはバハイ教徒として布教活動をする傍らエスペラントの翻訳活動を行った。ザメンホフの家族のその後については、家族の中でただ一人ホロコーストから生き延びた孫（アダム・ザメンホフの息子）のルイ・クリストフ・ザレスキ＝ザメンホフの著書『ザメンホフ通り―エスペラントとホロコースト』（原書房、2005年、ISBN 4-562-03861-6）に詳しい。
ルドヴィコ・ザメンホフ 著書
ザメンホフの著作全集（PVZ）はいとうかんじ（筆名Ludovikito）らの編集により出版されている。
ザメンホフは、エスペラントの文学的表現を高めるために積極的に文学作品を翻訳した。
ZIP (ファイルフォーマット)
ZIP（ジップ）は、データ圧縮やアーカイブのフォーマット。Windowsでよく使用されるフォーマットである。
ZIP (ファイルフォーマット) 概要
ZIPファイルフォーマット（以下ZIPフォーマット、またはZIP）は複数のファイルを一つのファイルとしてまとめて取り扱うアーカイブフォーマットであり、1つ以上のファイルが格納されているものである。必要に応じて各種ある圧縮アルゴリズムを選択・使用し、ファイルサイズを圧縮して格納することも可能である。
ZIPフォーマットは1989年にフィル・カッツが考案したもので、トム・ヘンダーソンが考案したそれまでのARCフォーマットに置き換わるものとして、PKWAREのPKZIPユーティリティ
に実装された。
ZIPフォーマットは現在多くのユーティリティによってサポートされている（ファイルアーカイバのリストを参照）。オペレーティングシステムでのサポートとしては、マイクロソフトがWindows 98以降の各バージョンに「圧縮フォルダー」という名前でZIPの機能を組み込んでいるほか、AppleもMac OS X v10.3以降に他の圧縮フォーマットも含めてZIPの機能を組み込んでいる。
ZIP (ファイルフォーマット) 概要
ZIPファイルは一般的に ".zip" か ".ZIP" といった拡張子が付けられる。MIMEタイプはapplication/zip。ZIPフォーマットは、圧縮伸長を主目的としない多くのアプリケーションでも使用されているが、その際、拡張子には個々のアプリケーション固有に ".zip" とは異なる名前が用いられていることが多い。例えば、Java Archiveの拡張子は ".jar"であるが、このフォーマットの実態はZIPフォーマットである。他の具体例については「#ソフトにおける固有の拡張子」節を参照のこと。
ZIP (ファイルフォーマット) 歴史
「zip」（「速さ」を意味する）という名前はフィル・カッツの友人であるロバート・マホーニーの提案によるものであり、従来から有るARCやその他の圧縮フォーマットの圧縮時間よりも、自分たちのプロダクトの方が速いということをほのめかすという意図を持っていた。
ZIPファイルフォーマット仕様は、PKZIP0.9のパッケージに同梱されていたファイルで初めて公開された。
ZIPフォーマットはオープンフォーマットとしてパブリックドメインでリリースされたものであり、ZIPフォーマットは誰しもが自由に利用でき、個人、団体、組織、あらゆる形態の利用において法的にもモラル的にも全く制約はない。
PKWAREもまた基本フォーマットをパブリックドメインとしており、誰でもZIPファイルを扱うアプリケーションを開発することができる。同じ見解がFOSS Info-ZIPバージョンのプロダクトに付属するUNIX/Linuxドキュメント内でも見られる。そのドキュメントではzipファイルフォーマット、圧縮フォーマット、.ZIPの拡張子やファイルフォーマットへの小さな変更をパブリックドメインに置いたフィル・カッツへの感謝の念を示している。
ZIP (ファイルフォーマット) 起源
ZIPファイルフォーマットはPKWAREのフィル・カッツが考案し、PKZIPで実装された。ちなみにカッツは以前に「PKXARC」なるアーカイブ・ユーティリティーを公開していたが、システム・エンハンス・アソシエイツ社のARCというユーティリティの著作権を著しく侵害しているとして民事訴訟を起こされている。
ZIP (ファイルフォーマット) よく似た名前のフォーマット
名前の一部に「zip」という名前を使った標準化仕様やフォーマットがたくさんある。同じDeflate圧縮アルゴリズムを使用していながら、ヘッダー・フッターの異なる物としては、gzip (RFC 1952) や zlib (RFC 1950) などがある。その他、よく似た名前の異なるファイルフォーマットや圧縮アルゴリズムとして7z、bzip2、rzipなどがある。
ZIP (ファイルフォーマット) バージョン履歴
.ZIPファイルフォーマット仕様にはバージョン番号がある。しかし、それは必ずしもPKZIPツールのバージョン番号とは対応せず、特にPKZIPバージョン 6以降がそれに該当する。PKWAREは、 PKZIP製品が先進的な機能を利用してアーカイブを展開できるように予備的な機能を幾度も追加している。しかし、そのようなアーカイブを作成するPKWARE仕様はPKZIPの次の主要なリリースまで公開されない。他の会社や組織は自分たちのペースでPKWAREの仕様をサポートしている。
PKWARE仕様による各バージョンの主な機能は以下の通り。
WinZipのバージョン12.1からDeflateよりも新しい圧縮メソッド、特にBZipやLZMA、PPMd、Jpeg、Wavpackのメソッドを使用したファイルの拡張子に.zipxが使用されている。JpegとWavPackは「最適メソッド」圧縮が選択されたときに適切なファイル種別に対して適用されている。
ZIP (ファイルフォーマット) 標準化
2010年4月ISO/IEC JTC 1で、ZIP互換のISO / IECの国際標準フォーマットを作成するために開始されるプロジェクトを決めるための投票が行われた。「ドキュメントパッケージング」という表題で提案されたプロジェクトはOpenDocument、Office Open XMLやEPUBを含む既存の標準規格の利用に適したZIP互換の最小圧縮アーカイブフォーマットと考えられる。そして2015年、ISO/IEC 21320-1:2015 Information technology — Document Container File — Part 1: Coreが制定された。
現在のZIPフォーマットはオープンフォーマットの要求仕様にあわないことがある。それは目に見える形で公開されたコミュニティ駆動開発を通して開発されていないからである。オープンな産業機構や標準化団体が賛同してメンテナンスされているものでもない。現在の ZIP フォーマットの一部は 自由 なファイルフォーマットの要求仕様にあっていない。誰もが ZIP フォーマットを、如何なる目的であっても金銭的な負担がなく利用できるようにするため、著作権、特許、商標などの制約がない。  PKWARE サイトにある最新の資料は、著作権表示があるが、フォーマット仕様とその機能拡張がパブリックドメインに置かれていることを認めている。
ZIP (ファイルフォーマット) 技術的な情報
ZIPは複数のファイルを格納するシンプルなアーカイブフォーマットである。圧縮はzipアーカイブのオプションであり、圧縮が行われる場合はファイル単位に圧縮される。
ZIPは、データの破損に備えて優れた保護機構を提供するため、32ビットのCRCアルゴリズムを利用し、またアーカイブのディレクトリ構造を2箇所に含んでいる。
ZIP (ファイルフォーマット) 技術的な情報
ZIPファイルはファイルの最後に置かれるセントラルディレクトリの終端レコード（EOCD）の存在によって正しく認識される。この仕組みにより、新たなファイルを追加することが容易である。ZIPファイルに格納されているエントリ（ファイルまたはディレクトリ）数がゼロで無い場合、格納されている各エントリの名前、エントリに関するその他のメタデータ、ZIPファイル内でエントリデータが位置するオフセットが、セントラルディレクトリエントリに記載される。これにより、ファイルリストを参照するためにアーカイブ全体を読み込む必要がないため、アーカイブのファイルリストを比較的速く表示することが可能である。また冗長性の確保のため、各エントリも、エントリ情報をローカルファイルヘッダとして保持している。zipファイルには後からファイルが追加されることもあるため、ファイルの最後にあるセントラルディレクトリに載っているファイルだけが、正しいファイルである。セントラルディレクトリが、いくつかのファイルは削除された、あるい更新された、と宣言していることもありうるため、ZIPファイル全体を検索してローカルファイルヘッダを探しても、正しい情報は得られない（ただし、アーカイブが破損している場合は、そのような探索は役に立つだろう）。
ZIP (ファイルフォーマット) 技術的な情報
セントラルディレクトリ内でのファイルエントリの順番は、アーカイブの中での実際のファイルエントリの順番と同じである必要はない。
ZIPファイル内のそれぞれのエントリは、ローカルファイルヘッダ（コメント、ファイルサイズやファイル名などの情報を含む）と、オプションの 「拡張」 データフィールドと、ファイルデータそのもの（圧縮されたり暗号化されている場合もある）で構成されている。「拡張」フィールドは、ZIP64フォーマット、WinZip互換のAES暗号化、ファイル属性やより詳細なNTFSやUnixファイルのタイムスタンプをサポートするために使用される。その他にも「拡張」フィールドを使用して機能拡張することが可能。認識しない拡張フィールドを無視するための機能をZIPツールに組み込む必要がある。
ZIPフォーマットはファイル内の様々な構造を表すために、特定の4バイトの「シグネチャ」を使用する。それぞれのファイルエントリは、ある特定のシグネチャによって目印が付けられる。セントラルディレクトリの終端レコードは、それ用のシグネチャでマークされ、セントラルディレクトリ内の各エントリは別の特定の4バイトシグネチャによって目印が付けられる。
ZIP (ファイルフォーマット) 技術的な情報
ZIPの仕様にはBOFもしくはEOFといった目印がない。慣例として、ZIPファイルの最初にはZIPエントリが置かれ、そのシグネチャによって簡単にそれとわかる。しかし、ZIPの仕様においては、ZIPエントリで始まる必要はなく、特に、自己解凍型のアーカイブは、実行可能なファイルヘッダで始まる。
ZIPアーカイブを正しく読み込むには、まず初めにセントラルディレクトリの終端レコードのシグネチャを探し、次に、適宜、他のセントラルレコードを探索する必要がある。ファイルチャンクが開始する場所を特定するのはセントラルディレクトリのみであるため、ZIPファイルの頭からエントリを検査すべきではない。ZIPフォーマットは、チャンク間に他のデータを含めることや、シグネチャと同じ4バイト列を含むようなデータを禁止していないため、そのようなスキャンは誤検出（フォールス・ポジティブ）を起こすだろう。  ただし、破損したZIPアーカイブからデータを修復するためのツールは、ローカルヘッダシグネチャを探索するのが普通である。この場合、ファイルチャンクの後ろにファイルチャンクの圧縮サイズが格納されることが、シーケンシャルな処理を困難にしている。
ZIP (ファイルフォーマット) 技術的な情報
また ZIPの仕様では、複数のファイルシステムにまたがって分散したアーカイブを扱うこともサポートしている。もともとは、複数の1.44MBフロッピーディスク にまたがった大きなzipファイルの格納を目的としていた。現在この機能は、ZIPアーカイブを分割してメールなどで送ったり、リムーバブルメディアで持ち運ぶのに使用されている。
DOSのFATファイルシステムは2秒単位でタイムスタンプを保持し、ZIPファイルレコードはこれを模倣している。結果として、ZIPアーカイブ内にあるファイルのタイムスタンプも2秒単位で丸められる。但し、より正確なタイムスタンプを格納するために拡張フィールドを使用することができる。なお、ZIPフォーマットにはタイムゾーンという概念がないため、タイムスタンプが意味を持つのは、作成されたタイムゾーンを知っている場合だけである。
2007年9月にPKZIPは、UTF-8のファイル名を格納するための仕組みを含むZIP仕様のリビジョンをリリースした。それは最終的にZIPに対するユニコード互換を追加するものである。
全てのヘッダ内の複数バイトの値は、リトルエンディアンで格納される。全ての長さを示すフィールドは、バイト単位で数える。
拡張フィールドはOSに特化した属性のような様々なオプションデータを含む。それは16ビットIDと16ビット長のチャンクに分割される。
ZIP (ファイルフォーマット) 技術的な情報
このヘッダの直後には圧縮データのデータが続く。
汎用目的のビットフラグフィールドの3ビット目がセットされている場合、ヘッダの書き込み時にはCRC-32とファイルサイズが不明である。ローカルヘッダのCRC-32とファイルサイズのフィールドにはゼロが書き込まれ、CRC-32とファイルサイズは圧縮データの後ろに12バイトのデータとして追加される。（オプションの4バイトのシグネチャが前に付く場合もある。）
セントラルディレクトリエントリはローカルファイルヘッダを拡張したものである。
全てのセントラルディレクトリエントリの後に、ZIPファイルの終わりを表すセントラルディレクトリの終端レコードが続く。
この順番により、ZIPファイルをワンパスで作成することができるが、通常、展開では最後のセントラルディレクトリを最初に読み込むことになる。
現在のZIPファイルフォーマット仕様では次のメソッドの詳細が記載されている。
最も一般的な圧縮メソッドはDEFLATEでIETF RFC 1951に記載されている。
圧縮メソッドに挙げられていても、PKWARE Data Compression Library (DCL) Imploding (old IBM TERSE), IBM TERSE (new), IBM LZ77 z Architecture (PFS) の仕様の詳細は記載されていない。
ZIP (ファイルフォーマット) 技術的な情報
ZIPはシンプルなパスワードベースの共通鍵暗号をサポートすると仕様に記載されている。但し、重大な脆弱性があることが知られている。特に、既知平文攻撃に対して脆弱性があり、貧弱なランダム数生成器の実装によってさらに安全性が低くなる場合もある。
バージョン5.2以降の.ZIPファイルフォーマット仕様には、圧縮 と 暗号化 (例えば AES) を含む新しい機能のメソッドが追加されている、と記載されている。WinZipはAESベースの標準規格を使用し、それは7-Zip、XCeedやDotNetZipでも使用されている。しかし、ベンダによっては他のフォーマットを使用するものである PKZIP また、SecureZIP は RC2, RC4, DES, Triple DES 暗号メソッド, 電子証明書ベースの暗号 / 認証 (X.509) やアーカイブヘッダ暗号化をサポートする。
ZIP (ファイルフォーマット) 技術的な情報
オリジナルのZIPフォーマットは、ZIPアーカイブ内のエントリに 65535 の制限があるのと同様に、様々なサイズ（ファイルの圧縮/非圧縮サイズ、アーカイブの合計サイズ）に4 GiBの制限があった。仕様のバージョン4.5（それは特定ツールのバージョン4.5と同じではない） では、PKWAREはこういった制限を回避するために16 EiB（264 バイト）まで増加させた "ZIP64" フォーマット拡張を導入した。ZIP64サポートは新規に発生したものである。例えば、Windows XPのファイルエクスプローラーはZIP64をサポートしないが、 Windows Vistaのエクスプローラーではサポートする。同様にDotNetZipやPerlのIO::Compress::Zip、PythonのzipfileのようなライブラリはZIP64をサポートする。Javaの組み込みモジュールjava.util.zipは 2010年9月現在ではサポートしていない。今後、OpenJDKに追加されてJava 7への同梱を予定している。
ZIP (ファイルフォーマット) 技術的な情報
ZIPファイルのようにファイルを分割して圧縮するとランダムアクセスが可能である。他のデータを読み込むことなく個々のファイルを取り出すことができる。DEFLATE圧縮の可能性を限定するときでさえ、それぞれのファイルのために違う辞書圧縮を利用するとアーカイブ全体のサイズをより小さくできることがある。
この圧縮の手法は一般的に小さなファイルが大量にあるときのアーカイブとしては適切ではない。ZIPアーカイブフォーマットでは、個々のエントリに関する情報を持つメタデータは圧縮しない。これは、特に個々のエントリのサイズを小さくして、そのエントリ向けのメタデータのサイズを扱うようにアーカイブ可能な最大圧縮比率を設けて制限されているためである。
別の手法としては 圧縮されたtarアーカイブ（.tar.gz または .tgz） が使用される。それはファイルデータとメタデータがgzipで圧縮される1つの単位として圧縮される。この手法の欠点はランダムアクセスの効率が悪くなってしまうことである。
ZIP (ファイルフォーマット) 技術的な情報
ZIPファイルフォーマットでは、セントラルディレクトリの後（ファイルの末尾）に、65,535バイト以下のデータを入れることのできるコメント欄がある。また、セントラルディレクトリがアーカイブ内の各ファイルの開始位置を表すオフセットを指定しているため、最初のエントリがオフセットゼロの位置から開始していなくてもよい。（gzipのようないくつかのツールでは、ファイルエントリがオフセットゼロで始まらないようなZIPファイルを処理できないが。）つまり、ZIPアーカイブの前や後に任意のデータを配置しても、ZIPアプリケーションはそのアーカイブを読み込むことができる。
この事実を利用すると、ZIPアーカイブとしても、別のフォーマットとしても扱えるようなファイルを作成することができる。ただし、別のフォーマットでは、ファイルの最初か末尾かあるいは中ほどに任意のデータを配置できる必要がある。WinZipやDotNetZipがサポートするSelf-extracting archives (SFX) はこの利点を活用している。そういったファイルはPKZIP AppNote.txtの仕様に準拠した.exeファイルであり、規格に準拠したzipツールやライブラリで読み込むことができる。
ZIP (ファイルフォーマット) 技術的な情報
ZIPフォーマットやZIPの亜種であるJARフォーマットが持つこのような特性は、一見普通のファイルに見えるが、コンピューター内部に害を及ぼすJavaクラスを隠すことに悪用できてしまう。例えば、ウェブにアップロードされるGIFイメージがある。これはGIFARと呼ばれる手法で、Facebookのようなウェブアプリケーションに対して効率的な攻撃として知られている。
多くのZIPツールとZIPライブラリは様々なプログラミング環境の上で利用できる。ライセンスは商用やオープンソースのものがある。例えば、WinZipはWindows上で動作する有名なZIPツールである。他にも様々なプラットホームでWinRAR、IZarc、Info-ZIP、7-Zip、PeaZipやDotNetZip等が利用できる。これらのツールのいくつかはライブラリ、またはプログラミングインタフェースを持つ。
オープンソースで開発されているライブラリの例としてはGNUプロジェクトのgzipやInfo-ZIPがある。JavaではJava Platform, Standard Editionに標準的なzipファイルを扱う java.util.zip パッケージがある。Zip64Fileライブラリは特別に4GBを超える巨大なファイルをサポートして、ランダムアクセスを使用してZIPファイルを扱う。Apache AntツールにはApache Software Licenseでより完全なツールが実装されている。
.NETアプリケーションでは、.NET Framework 4.5で追加されたSystem.IO.Compression名前空間のZipArchiveクラスやZipFileクラスなどが使用できる。それ以前の場合、Microsoft Public License  でソースとバイナリが利用できる DotNetZipと呼ばれる無償のオープンソースライブラリがある。従来のパスワードを用いたZIP暗号化、WinZip互換のAES暗号化、ユニコード、ZIP64、コメント、分割アーカイブ、自己展開アーカイブといった多くのZIP機能をサポートする。Microsoft .NET 3.5 ランタイムライブラリはZIPフォーマットをサポートするクラスSystem.IO.Packaging.Packageを含む。主としてISO/IEC国際標準Open Packaging Conventionsを使用するドキュメントフォーマットのために設計されている。
ZIPフォーマットのInfo-ZIP実装は、ユーザやグループID、ファイルパーミッション、シンボリックリンクのようなUnixファイルシステムの機能のサポートを追加する。Apache Antの実装はUnixパーミッションが事前に定義されたファイルを作成できる範囲に対して注意を払っている。Info-ZIPの実装もZIP圧縮フォーマットに組み込まれたエラー訂正機能の使用方法が分かっている。（IZarcのような）一部のプログラムはエラーがあるファイルの処理中に失敗する可能性がある。
また Info-ZIP WindowsツールもNTFSファイルシステムパーミッションをサポートする。展開時にNTFSパーミッションをUnixパーミッションへ、もしくはその逆へ変換しようとする。これは潜在的な意図しない結果をもたらすことがある。例として、NTFSボリューム上で実行権限を付けて作成された.exeファイルは拒否されることなどが挙げられる。
ZIP (ファイルフォーマット) Windows 圧縮フォルダー
Windowsでは、Windows 98のためにリリースされたPlus!パック以降、エクスプローラーからZIP形式の圧縮と展開をサポートしている。マイクロソフトはこの機能を「圧縮フォルダー」と呼んでいる。圧縮フォルダーはZIPの機能を全てサポートしているわけではなく、例えばWindows 10ではAES暗号化、分割アーカイブ、パスワード付き圧縮などが行えない。また圧縮時にはシステムロケールが日本語に設定されたWindowsではファイル名にMicrosoftコードページ932を使用している。（Windows NT系の内部文字コード及びファイルシステムの文字コードはUnicodeであるが、互換性のためにMicrosoftコードページ932に変換している。変換できない文字が含まれるファイル名は圧縮できない。）展開時はhotfixを適用したWindows 7もしくはWindows 8以降でUTF-8に対応したため、ファイル名がMicrosoftコードページ932とUTF-8のどちらであっても問題なく展開できる。
ZIP (ファイルフォーマット) パスワード付きZIPファイルの脆弱性
パスワード付きZIPファイルの暗号化方式として、最も標準的なのは Traditional PKWARE Encryption (ZipCrypto) であり、Windows 11のファイルエクスプローラで復元できるのもこの方式だけである。しかし、Traditional PKWARE Encryption (ZipCrypto) は暗号化方式としては脆弱であり、bkcrack などのツールを使うと、普通のパソコンで数分程度で暗号が解けてしまうので、暗号化方式としては無意味である。
ZIP (ファイルフォーマット) 強力な暗号化についての議論
2003年にWinZip 9.0パブリックベータをリリースしたとき、WinZipは独自のAES-256暗号を導入した。それは違うファイルフォーマットを用いた新たな仕様としてドキュメントに記載された。暗号の標準規格はプロプライエタリでは無いが、 PKWARE は2001年以降、PKZIP 5.0や6.0では使用されていた強力な暗号化仕様 (SES) を含めるようにAPPNOTE.TXTを更新しなかった。WinZipの技術コンサルタント Kevin KearneyやスタッフイットプロダクトマネージャMathew CovingtonはSESを差し控えるようにPKWAREを非難。これに対し、PKZIPチーフ技術オフィサーのJim Petersonは承認に基づく暗号化規格はまだ完全ではないと主張。しかし、バージョン 4.5の頃（PKWARE の FTP サイトで確認できる）に公開された最新のAPPNOTE.TXTには、SESだけではなく、同時期に存在したPKZIPプロダクトで作成された.ZIPファイルが用いたDeflate64、DCL Implode、BZip2も除外された。
ZIP (ファイルフォーマット) 強力な暗号化についての議論
この欠点を克服するためにPentaZipのような同時期に存在したプロダクトは違うファイルフォーマットにZIPアーカイブを暗号化する強力なZIP暗号化を実装した。
また別の議論では、PKWAREは2003年7月16日に安全な.ZIPファイルを作成するために強力な暗号と.ZIPを組み合わせるための方法を記載した特許を適用した。
結局PKWAREとWinZipはお互いのプロダクトをサポートすることに同意した。2004年1月21日にPKWAREはWinZipベースのAES互換フォーマットをサポートするとアナウンスした。WinZipベータの次のバージョンではSESベースのZIPファイルのサポートが行われた。PKWAREは最終的にSESを記載した.ZIPファイルフォーマット仕様のバージョン 5.2を公式にリリースした。自由ソフトウェア プロジェクト 7-Zipも（そのPOSIX 移植された p7zip が行うことで）ZIPファイルのAESをサポートしている。
ZIP (ファイルフォーマット) ソフトにおける固有の拡張子
アプリケーション固有のファイル形式のなかには、あるファイルを一定のディレクトリの階層構造に格納しZIP形式で圧縮したものが存在する。そのようなファイルの大半はそのアプリケーション固有の物であることを示すために専用の拡張子を定義しており、以下に示す例はその一部である。ただし、圧縮アルゴリズムにzlibを使っているものでも、ZIP互換の格納方式を使っていないものは掲載しない。
apk
Android のアプリケーションアーカイブ
crx
Google ChromeやChromiumの拡張機能のアーカイブファイル
docx, xlsx, pptx
Microsoft Office（2007以降）の文書フォーマット (Office Open XML)
epub
IDPFが提唱する電子書籍の標準フォーマット
ipa
iPhoneシリーズをはじめとしたiOS搭載デバイス向けのアプリケーションアーカイブ
ipg
iPodゲームのアーカイブファイル
jar
Javaのアーカイブファイル
kmz
Google Earthの標準ファイル形式。kmlをZIP圧縮したもの。
ZIP (ファイルフォーマット) ソフトにおける固有の拡張子
nar
伺かのINSTALL/1.x仕様に準拠したアーカイブファイル
odt, ods, odp, odb, odg, odf
OpenDocumentの文書フォーマット
smzip
StepManiaの各種の自動インストール型パッケージファイル
wgt
W3C Packaged Web Apps (W3C Widgets) のパッケージファイル。Bada widget、Tizen Web application、Opera widget など。
wsz
Winamp用のスキンファイル
wmz
Windows Media Player用のスキンファイル
xpi
Mozilla Firefox（及びそれをベースとするNetscapeシリーズのウェブブラウザなど）やMozilla Thunderbirdなどの拡張機能（アドオン）のインストーラファイル (XPInstall)
3mf
3Dプリンター向けの3Dファイル
記号
記号（きごう、英: sign）とは、それ自身ではなく、それを解釈することによって理解される意味を伝える媒体のことである。身近な例では、交通信号機や交通標識、非常口を示す印（アイコンやピクトグラム）などがある。信号機の青色（緑色）の電球そのものに「進め」の意味はないが、そのルールを解釈することで「進め」の意味が理解される。狭義には、文字やマーク、絵など、意味を付された図形を指すが、広義には表現物、ファッションや様々な行為（およびその結果など）までをも含む。
記号 概説
記号それ自体は、紙の上のインクや造形された物体、空気の振動などでしかないが、人間がこれらを何らかの意味と結び付けることにより、記号として成立する。そして記号は、他の記号と共にまとまった集合体となったり、あるいは相互に作用し合ったりして、何かを指し示す。
19世紀後半から20世紀にかけて、人類は、科学や技術、政治・経済、思想などの面で大きな飛躍を遂げたが、その中で記号の使用は重要な役割を果たした。とりわけ自然科学においては、自然現象を記号化し操作できるようにすることが、新たな認識を深めることにつながった。
これにより、あらゆる認識は記号によってのみ実現するとまで言われた。今日に通じる記号論も同時期に研究が始まった。記号論は言語学の中から出てきたものであるが、単に言語における記号の働きを研究しただけでなく、記号（なお、記号論や記号学でいう「記号」は sign でも symbol でもなく、semiosis である）が人類にもたらす諸作用をも研究対象としていき、哲学における大きな柱の一つとなった。
具体の記号・標識の例としては、次のものがある。
同一の主題を元に類似した作品が多数作成された宗教画などでは、約束事に従って書き込まれたアトリビュートによって作品を読み解く。図像学や図像解釈学は伝統化された絵画や図像の中から記号を読み解く学問である。
記号 概説
アニメや漫画などの評論では登場人物の象徴的なものを記号と呼ぶことがある。また、作品が違ってもキャラクターデザインが似たり寄ったりになる状況を「記号化が進んだ」と言うことがある。1980年代の現代思想ブームの影響を受けた評論家が使うことが多い（大塚英志、岡田斗司夫など）。またアニメ監督や作品などでもこの言葉は使われるようになってきている（谷口悟朗など）。
記号論における記号過程 (semiosis) とは、記号がそれを解釈する人に意味を教えることをいい、記号により指し示されるものを所記 (signified)、指し示す記号を能記 (signifier) と呼ぶ。日本の言語学では伝統的にフェルディナン・ド・ソシュールが用いたフランス語の音訳であるシニフィアンとシニフィエが用いられる場合が多い。
所記はその部体から連想されることをいい、能記は物体が存在している特徴をいう。例えば、りんごで考えると、前者は、果物や企業のApple、後者は赤いがあげられる。
7z
7z（セブンゼット）とは、コンピュータで使用するデータ圧縮形式およびファイルフォーマットである。
7z 概要
7z形式ではZIP形式に比べ高圧縮のファイルが作成できるほか、様々な圧縮アルゴリズムを組み合わせて使うことができる。また、Unicodeで全てのデータを格納しているため文字体系の違う名前のファイルを混在させることができる。
当初、7-Zipアーカイバに実装される形で登場した。7-ZipのプログラムはGNU LGPLの下で公開されている。7zファイル形式の仕様は、2015年以降、7-Zipのソースコードとともに配布されている。
7z 対応ソフト
2010年3月現在、7z形式に対応している主なファイル・アーカイバは次の通り。
完全対応（圧縮および展開）
対応（展開のみ）
海軍記念日
海軍記念日（かいぐんきねんび）は、海軍を祝う記念日。
海軍記念日 日本
日本では、第二次世界大戦以前に5月27日を海軍記念日としていた。1905年（明治38年）5月27日に行われた日本海海戦を記念して制定された。1945年（昭和20年）を最後に、日本の太平洋戦争敗戦により廃止された。
日露戦争は、日本が欧州の大国ロシアに勝利を収めた。その中でも、ヨーロッパ・バルト海から回航された強力なバルチック艦隊（ロシア名：第2・第3太平洋艦隊）を迎え撃ち、これを撃滅した日本海海戦（ロシア名：ツシマ海戦）は、陸上での奉天会戦の勝利（3月10日の陸軍記念日）と並んで日本国民が記念すべき日とされ、海軍記念日として祝われた。
現在の海上自衛隊も、この日の前後に基地祭などの祝祭イベントを設けている。主なものに、例年金刀比羅宮で行われる掃海殉職者慰霊祭がある。
また、1952年（昭和27年）4月26日に海上自衛隊の前身である海上警備隊が創設されたことを記念し、「海上自衛隊の歴史と伝統を考える日」として、2013年（平成25年）に4月26日が「海上自衛隊の日」に制定された。
一方で海上保安庁には旧海軍記念日を祝う文化は無い。海上保安庁における祝祭の日は5月12日の海上保安の日、9月12日の水路記念日、11月1日の灯台記念日である。
海軍記念日 アメリカ合衆国
アメリカ合衆国では、海軍に理解のある大統領であったセオドア・ルーズベルトの誕生日を記念して、1922年に10月27日に制定された。1949年に国防総省の指示により、合衆国海軍は海軍記念日を取りやめ、5月の第3土曜日の軍隊記念日（Armed Forces Day）を祝うようになった。民間団体などは、その後も引き続き海軍記念日の祝賀行事を行っている。
海軍記念日 インド
インドでは12月4日。1971年の第三次印パ戦争において、カラチ港爆撃に成功したことにちなむ。
海軍記念日 オーストラリア
王立オーストラリア海軍では、3月中に行われる。
海軍記念日 チリ
チリでは、Día de las Glorias Navalesとして、5月21日に祝われる。太平洋戦争におけるイキケの海戦での勝利を記念して制定された。
LHA
LHAとは、ファイルの圧縮とアーカイブを行うソフトウェアのひとつ。また、圧縮ファイルの形式はその拡張子からLZHと呼ばれる。ここではLZH形式についても述べる。
LHA プログラム
LHAの、アルゴリズムは奥村晴彦と吉崎栄泰により、実装は吉崎栄泰による。1988年にパソコン通信で公開した。
登場当時はLHarc（エルエイチアーク）という名前で、1991年頃に全面的に作り直したのに併せLHAに改称した。当初はLHに改称の予定で、実際にバージョン2.00はLHとして公開したが、MS-DOSバージョン5.0の内部コマンドLOADHIGHの略称LHと被ったためLHAとした。ごく初期には「LHx/LHa」という名称・表記だった。
発音は、初期バージョンではLHAを「ラー」とすると作者による説明があったが、後期バージョンではその説明はない。また、RARとの混同を避けるためにも、「エルエイチエー」「エルハ」等といった発音が大勢である。
LHA フォーマット
LZH形式の圧縮アルゴリズムは、LZSS法で圧縮したデータをさらにハフマン法を用いて圧縮するLZHUFアルゴリズムを用いる。LZHUFは奥村晴彦のLZARI（LZSS + 算術符号）の効率を向上するために吉崎栄泰が考案したものである。
LZSS法ではスライド窓や最大一致長を大きく取るほどに圧縮率の向上が見込めるが、一方でむやみに大きくすると最長一致列の探索に時間がかかり、また多くのメモリも必要になる。このため初期の版ではスライド窓や最大一致長の大きさは小さくとられていたが、探索アルゴリズムの改良やコンピュータの性能向上などにより、次第に大きな値が採用されるようになった。
LZH圧縮形式は大きくlh0、lh1、lh4/5/6/7に分けられる。
圧縮率を高めたlh6/7方式が公開されているが、開発途中ということで同形式を使ったファイルの配布は推奨されていない。
lh0形式は一切の圧縮を行わない。可逆圧縮では圧縮前よりも圧縮後のデータの方がサイズが大きくなる場合があり、lh0形式はそれを避けるために使用される。ユーザーが意図してこの形式を使う場合は、ファイルの破損のチェックに使ったり、複数のファイルをまとめるだけのアーカイバとして利用される。
LHA フォーマット
lh1形式のスライド窓の大きさは4Kバイト、最大一致長は60バイト。文字と一致長は動的ハフマン法で符号化されるが、一致位置はハフマン法を用いずに符号化される。LHarc 1.xではこの形式。
各形式はスライド窓の大きさのみが異なり、それぞれ4K/8K/32K/64Kバイトである。最大一致長は256バイト。
圧縮データの展開速度の向上を目的として、符号化がlh1形式の動的ハフマン法から静的ハフマン法に変更されている。また、一致位置も、文字、一致長とは別にハフマン法で符号化される。