Tarayıcıdan ZPL baskısı

Yayın tarihi: 2026-08-27

Er ya da geç bir web uygulamasının termal yazıcıya etiket basması gerekir ve ilk deneme hep aynıdır: JavaScript'ten yazıcıya soket açmak. Bu mümkün değildir; nedenini anlamak ise doğrudan işe yarayan desenleri gösterir.

Doğrudan yol neden çalışmaz

Ham termal baskı, TCP 9100 portuna bayt yazmak demektir. Tarayıcılar keyfi TCP soketleri için bilerek API vermez — sayfa JavaScript'i HTTP, WebSocket ve WebRTC konuşur; üçü de karşı tarafta iş birliği yapan bir sunucu ister. 9100'de yanıt veren bir etiket yazıcısı böyle bir sunucu değildir: HTTP konuşmaz, el sıkışma yapmaz. Bu kısıt eksik bir özellik değil güvenlik sınırıdır; hiçbir kütüphane etrafından dolaşamaz.

Desen 1 — sunucu aktarır

Tarayıcı etiketi sizin sunucunuza gönderir; sunucu yazıcıya soketi açar ve baytları iletir. Depo ve arka ofis uygulamalarında varsayılan cevap budur; yazıcılarla sunucular aynı ağdadır.

• İyi tarafı: operatörün makinesine yazılım kurulmaz, kayıt ve yeniden deneme tek yerdedir, yazıcı bilgileri tarayıcıya hiç gitmez.
• Bedeli: sunucunun yazıcıya erişebilmesi gerekir — yazıcı müşterinin yerel ağındayken ve servisiniz bulutta çalışırken bu deseni eler.

Desen 2 — operatörün makinesinde yerel yardımcı

Tarayıcının yanında küçük bir program çalışır, localhost'u dinler; sayfa etiketi ona HTTP ile gönderir, yardımcı da 9100'e yazar. Üreticilerin "web baskı" araçlarının çoğu böyle çalışır ve sunucunun göremediği bir yazıcıya ulaşan tek desendir.

• İyi tarafı: kullanıcının kendi ağındaki yazıcılarla çalışır, bulutta barınan uygulamalarda da ayakta kalır.
• Bedeli: her iş istasyonuna bir şey kurulup güncel tutulmalıdır; localhost'a giden sayfanın CORS'u, HTTPS sayfalarda ise karışık içerik kurallarını yardımcının çözmesi gerekir.

Desen 3 — render edip tarayıcının baskı penceresini kullanmak

ZPL'i görüntüye ya da PDF'e çevirin, gösterin ve operatör normal sürücüden bassın. Soket yok.

• İyi tarafı: her yerde çalışır, kurulum istemez; ara sıra baskı için ya da "yazıcı" aslında ofis lazeriyse doğru cevaptır.
• Bedeli: sayfayı sürücü rasterleştirir; barkod kenarları o rasterleştirmeye bağlıdır ve sayfa ölçekleme ayarları etiketi sessizce yeniden boyutlandırabilir. Hacimli ve okunması gereken barkodlarda 1. ve 2. desen daha güvenlidir — gerekçesi PDF ile ZPL karşılaştırmasında.

Hangisini seçerseniz seçin, önce etikete bakın

9100 portunun geri alması yoktur: iş ulaştığı anda yazıcı medyayı hareket ettirmeye başlar. İşi göndermeden önce tarayıcıda render etmek bedava ve yapısal sorunları yakalıyor — etiket dışına taşan alanlar, eksik sonlandırıcı, kodlanamayan barkod verisi. İşi ZPL önizleyiciye yapıştırın ya da göndermeyi yapacak sunucudan render API'sini çağırın. Baytları işletim sistemi tarafında iletmenin yolları ağ yazıcısına ZPL göndermek yazısında.

Sık sorulan sorular

JavaScript doğrudan yazıcıya ZPL gönderebilir mi?

Hayır. Ham termal baskı TCP 9100 portuna bayt yazmaktır ve tarayıcılar keyfi TCP soketleri için API vermez — yalnız HTTP, WebSocket ve WebRTC, üçü de iş birliği yapan bir sunucu ister. 9100'deki yazıcı bunların hiçbirini konuşmaz. Bu bir güvenlik sınırıdır; hiçbir kütüphane etrafından dolaşamaz.

Peki web uygulamaları ZPL'i nasıl basıyor?

Üç desen: sunucu işi 9100'e aktarır (ağdan erişim gerekir), operatörün makinesinde localhost'u dinleyen küçük bir yardımcı yazıcıya iletir (her iş istasyonuna kurulum gerekir) ya da etiket görüntüye/PDF'e render edilip normal sürücüden basılır (kurulum yok ama barkodu sürücü rasterleştirir).

İlgili yazılar

Kendi ZPL kodunuzu deneyin →